Lý thuyết chắc chắn và Ứng dụng trong xây dựng hệ thống dự phòng core banking tại maritime bank việt nam

vii DANH MỤC CÁC TỪ TIẾNG ANH VÀ VIẾT TẮT Core Banking Core Banking System Hệ thống ngân hàng lõi CA Certificate authority Cơ quan cung cấp chứng thực số CD Certificate directory Kh

i

BỘ GIÁO DỤC VÀ ĐÀO TẠO

TRƯỜNG ĐẠI HỌC HÒA BÌNH

-

ĐOÀN MINH PHONG

LÝ THUYẾT CHẮC CHẮN VÀ ỨNG DỤNG TRONG XÂY DỰNG HỆ THỐNG DỰ PHÒNG CORE BANKING

TẠI MARITIME BANK VIỆT NAM

LUẬN VĂN THẠC SĨ KHOA HỌC CÔNG NGHỆ THÔNG TIN

Chuyên ngành Công nghệ Thông tin

Mã số 60 48 02 01

HÀ NỘI, 2017

ii

BỘ GIÁO DỤC VÀ ĐÀO TẠO

TRƯỜNG ĐẠI HỌC HÒA BÌNH

-ĐOÀN MINH PHONG

LÝ THUYẾT CHẮC CHẮN VÀ ỨNG DỤNG TRONG XÂY DỰNG HỆ THỐNG DỰ PHÒNG CORE BANKING

TẠI MARITIME BANK VIỆT NAM

LUẬN VĂN THẠC SĨ KHOA HỌC CÔNG NGHỆ THÔNG TIN

Chuyên ngành Công nghệ Thông tin

Mã số 60 48 02 01

Giáo viên hướng dẫn: Đỗ Trung Tuấn

HÀ NỘI, 2017

có thêm tài liệu viết luận văn

Trong thời gian thực hiện luận văn, tôi đã có nhiều cố gắng để hoàn thiện luận văn bằng tất cả sự nhiệt tình và năng lực của mình, tuy nhiên việc hoàn thiện thời gian hạn hẹp không thể tránh khỏi những thiếu sót, rất mong nhận được những đóng góp quý báu của quý thầy cô và các bạn

Nhân đây, xin chân thành cám ơn gia đình, đã chia sẻ và động viên tôi thực hiện luận văn, cũng như chu cấp điều kiện làm việc và tài chính để hoàn thành luận văn này

Đoàn Minh Phong

iv

MỤC LỤC

LỜI CÁM ƠN iii

MỤC LỤC iv

DANH MỤC CÁC TỪ TIẾNG ANH VÀ VIẾT TẮT vii

DANH MỤC CÁC HÌNH VẼ ix

MỞ ĐẦU 1

Tổng quan về nội dung luận văn 1

Cấu trúc của luận văn 6

Chương 1 7

Lý thuyết chắc chắn và ứng dụng cho bài toán ngân hàng 7

1 1 Tổng quan về lý thuyết chắc chắn 7

1 1 1 Lập luận không chính xác 8

1 1 2 Biểu diễn vấn đề không chắc chắn 8

1 1 3 Luật không chắc chắn 9

1 1 4 Lập luận không chắc chắn 9

1 1 5 Xử lí nhiều nguồn thông tin 9

1 1 6 Cơ sở của lý thuyết chắc chắn 10

1 2 Vấn đề không chắc chắn đối với bài toán ngân hàng 11

1 2 1 Dấu hiệu không chắc chắn 11

1 2 2 Các luật không chắc chắn 13

1 2 3 Lan truyền chắc chắn đối với các luật có giả thiết đơn 13

1 2 4 Các luật AND 13

1 2 5 Các luật OR 14

1 3 Lan truyền chắc chắn đối với các luật có cùng kết luận 14

1 4 Kết luận chương 15

Chương 2 17

Hoạt động ngân hàng và tránh rủi ro về dữ liệu 17

v

2 1 Rủi ro về dữ liệu trong hệ thống ngân hàng 17

2 1 1 Khái niệm và mục đích 17

2 1 2 Phạm vi 17

2 2 Hoạt động an toàn dữ liệu tại Maritime Bank Việt Nam 18

2 2 1 Chính sách nội bộ 18

2 2 2 Nhận diện lỗi 20

2 2 3 Qui trình xử lí lỗi chung 27

2 2 4 Qui trình xử lí lỗi thông thường, không nghiêm trọng 31

2 2 5 Qui trình xử lí các lỗi nghiêm trọng về rủi ro dữ liệu ngân hàng 40

2 3 Ứng dụng dữ liệu và lập luận chắc chắn trong quản trị thông tin 45

2 3 1 Tiêu chuẩn đầu vào/thoát ra của quy trình 45

2 3 2 Cơ sở đầu vào/Kết quả chuyển giao theo quy trình 46

2 3 3 Ma trận phân bố giữa các vai trò thực hiện trong quy trình 49

2 4 Kết luận chương 51

Chương 3 52

Giải pháp an toàn hệ thống dự phòng Core Banking với tri thức chắc chắn 52 3 1 Đặt vấn đề cho an toàn dữ liệu 52

3 1 1 Danh mục mức độ ảnh hưởng 52

3 1 2 Danh mục mức độ khẩn trương 53

3 1 3 Danh mục mã ưu tiên 55

3 3 Xây dựng hệ thống dự phòng Core Banking với lập luận chắc chắn 55

3 3 1 Tổng quan hệ thống Core Banking tại Maritime Bank 55

3 3 2 Mục tiêu triển khai BCP cho hệ thống Core Banking 57

3.3.3 Hiện trạng hệ thống Core Banking hiện tại 59

3.3 Các rủi ro gây gián đoạn dịch vụ Core Banking mô hình hiện tại 63

3.3.1 Đề xuất giải pháp 64

3.4 Các kịch bản xảy ra đối với hệ thống Core Banking tại Data Center 68

3.4.1 Trường hợp 1 68

vi

3.4.2 Trường hợp 2 68

3.4.3 Các rủi ro khác ảnh hưởng đến hoạt động của hệ thống 68

3.5 Bài toán về tri thức chắc chắn đối với hoạt động hệ thống dự phòng 69

3.5.1 Giả thuyết cần kiểm tra bằng lý thuyết chắc chắn 69

3.5.2 Các luật chắc chắn sử dụng trong bài toán 70

3.5.3 Giải bài toán 71

3.6 Kết luận chương 73

Kết luận 74

Kết quả đạt được của luận văn 74

Phương hướng phát triển luận văn 75

DANH SÁCH TÀI LIỆU THAM KHẢO 76

Tiếng Việt 76

Tiếng Anh 76

PHỤ LỤC TRIỂN KHAI TẠI MARITIME BANK VIỆT NAM 77

vii

DANH MỤC CÁC TỪ TIẾNG ANH VÀ VIẾT TẮT

Core Banking Core Banking System Hệ thống ngân hàng lõi

CA Certificate authority Cơ quan cung cấp chứng thực

số

CD Certificate directory Kho lưu trữ chứng chỉ

CNTT Information Technology Công nghệ thông tin

DR Disaster Recovery Trung tâm dữ liệu dự phòng

IT Information Technology Công nghệ thông tin

MIMIX

REPLICATION

Giải pháp đồng bộ dữ liệu qua MIMIX

MD Measure of Disbelief in Độ đo sự không tin cậy

Maritime Bank Maritime Bank Ngân hàng TMCP Hàng hải

Việt Nam

PKI Public key infrastructure Cơ sở hạ tầng khóa công khai

RTO Recovery Time Objective Mục tiêu thời gian khôi phục

ứng dụng

Point Objective Mục tiêu thời điểm khôi phục

viii

ứng dụng

RLO Recovery Level Objective Mục tiêu khả năng đáp ứng của

hệ thống sau khi khôi phục

RA Registration Authority Cơ quan quản lý đăng ký TMĐT Electronic commerce Thương mại điện tử

SWITCHOVER SWITCH OVER

Thực hiện chuyển sang hệ thống dự phòng khi hệ thống chính gặp sự cố

SAN

REPLICATION

Giải pháp đồng bộ dữ liệu qua SAN

VLAN Virtual Local Area

Enterprise

Ngân hàng các doanh nghiệp vừa và nhỏ

ix

DANH MỤC CÁC HÌNH VẼ

Hình 1 1 Một số biểu tượng ngân hàng 11

Hình 1 2 Chuyển giá trị tin cậy sang ngôn ngữ thực 12

Hình 1 3 Các giá trị không chắc chắn, từ -1 đến +1 12

Hình 2 1 Hoạt động tại Maritime Bank 18

Bảng 2 1 Qui trình nhận diện lỗi phát sinh 20

Bảng 2 2 Các vai trò trong hệ thống 24

Hình 2 2 Sơ đồ tổng quan 27

Bảng 2 3 Các bước xử lí sự cố 28

Hình 2 3 Các thủ tục xử lí sự cố không nghiêm trọng 31

Bảng 2 4 Mô tả các thủ tục của quy trình quản lý sự cố thông thường 31 Hình 2 4 Qui trình xử lí lỗi nghiêm trọng 40

Bảng 2 5 Các thủ tục của quy trình quản lý sự cố nghiêm trọng 41

Bảng 2 6 Cơ sở đầu vào về công nghệ 46

Bảng 2 7 Kết quả chuyển giao 47

Bảng 2 8 Ma trận phân công công việc 49

Bảng 3.1 Danh mục mức độ ảnh hưởng của rủi ro về dữ liệu 52

Hình 3.2 Mức độ khẩn trương đối với rủi ro 53

Bảng 3.3 Thiết lập ưu tiên 55

Hình 3.2a Core Banking và các ứng dụng lõi 56

Hình 3.2b Core Banking góc nhìn chuyên ngành mở rộng 57

Hình 3.1 Mô hình kiến trúc tổng quan DC-DR của hệ thống 58

Hình 3.2 Kiến trúc Core Banking 60

Bảng 3.4 Thành phần hệ thống 61

Bảng 3.5 Danh sách ứng dụng 61

Hình 3.3 Cấu hình máy chủ hiện tại 62

Bảng 3.6 Cấu hình chi tiết 62

Bảng 3.7 Gián đoạn dịch vụ 63

Hình 3.5 Triển khai hệ thống 65

Hình 3.6 Hạ tầng máy chủ 66

x

Bảng 3.7 Cấu hình hệ thống 67

Hình 3.8 Giải pháp an toàn mạng và bảo mật truyền thông 67

Bảng 3.8 Tiến độ triển khai 68

Hình 3.9 Quan hệ giữa các sự kiện 71

Bảng 3 9 Các hệ số chắc chắn CF 72

1

MỞ ĐẦU Tổng quan về nội dung luận văn

Hệ thống Core Banking là một trong những hệ thống trọng yếu của Ngân hàng, đây là hệ thống quản trị, phục vụ kinh doanh các sản phẩm & dịch vụ cốt lõi của Maritime Bank (MSB) Việt Nam, việc bảo vệ dữ liệu cũng như duy trì hoạt động liên tục của hệ thống Core Banking khi xảy ra sự cố, thảm họa nghiêm trọng là hết sức cấp thiết trong bối cảnh các cuộc tấn công

từ thế giới bên ngoài vào lĩnh vực tài chính, ngân hàng nói chung và Maritime Bank Việt Nam nói riêng đang gia tăng và phức tạp cả về số lượng và tần suất

Tìm hiểu về Core Banking, khái niệm về ngân hàng lõi là cần thiết Đây

là thuật ngữ thường được nhắc đến hiện nay trong hầu hết các ngân hàng Bản thân tôi, khi tìm hiểu về đề tài này, thấy đó chỉ là phần mềm hệ thống để thực hiện các nghiệp vụ thông thường Vấn đề là tại sao các ngân hàng đua nhau mua hay xây dựng cho được Core Banking

Trước việc ứng dụng ngày càng nhiều công nghệ hiện đại trong giao dịch thương mại điện tử, khái niệm về Core Banking, ngân hàng lõi, thực ra vẫn còn khá mới mẻ với nhiều người, đặc biệt với khách hàng trong nước Theo định nghĩa của nhiều cán bộ nghiên cứu trong ngành ngân hàng và của

các cán bộ Học viện Ngân hàng thì có thể hiểu ngân hàng lõi là một hệ thống các phân hệ nghiệp vụ cơ bản của ngân hàng như tiền gửi, tiền vay, khách hàng … Thông qua đó, ngân hàng phát triển thêm nhiều dịch vụ, sản phẩm và

quản lý nội bộ chặt chẽ, hiệu quả hơn Về bản chất đây là hệ thống phần mềm tích hợp các ứng dụng tin học trong quản lý thông tin, tài sản, giao dịch, quản trị rủi ro … trong hệ thống ngân hàng Về đặc điểm, Core Banking chính là hạt nhân toàn bộ hệ thống thông tin của một hệ thống ngân hàng Hệ thống thông tin ở đây bao gồm thông tin về tiền, tài sản thế chấp, giao dịch, giấy tờ,

sổ sách kế toán, dữ liệu máy tính và hệ thống thông tin, tức Core Banking

2

Tất cả các giao dịch được chuyển qua hệ thống Core Banking và trong một khoảng thời gian cực kì ngắn vẫn duy trì hoạt động đồng thời xử lý thông tin trong suốt thời gian hoạt động, hay có thể nói Core Banking là hệ thống để tập trung hóa dữ liệu ở bất cứ nơi đâu, hay lúc nào Cơ sở dữ liệu của ngân hàng được quản lý tập trung theo quan hệ và theo các khối chuyên doanh, khối chức năng: tiền gửi, thanh toán quốc tế, chuyển tiền, tài trợ thương mại, cho vay, thẩm định, nguồn vốn, Internet Banking… Để nâng cấp hệ thống công nghệ thông tin của ngân hàng có thể thay đổi module theo nghiệp vụ ngân hàng hoặc thay đổi theo giải pháp phần mềm

Hầu hết các hệ thống Core Banking hiện đại đều hoạt động không ngừng, để cung cấp dịch vụ Internet banking, những hoạt động giao dịch toàn cầu… thông qua ATM, POS, Internet, điện thoại và thẻ tín dụng Có thể thêm định nghĩa tham số để tạo sản phẩm mới thay vì sửa thẳng vào code chương trình, và nhiều chức năng khác tùy theo loại hệ thống Core Banking cũng như

sự điều chỉnh của ngân hàng triển khai

Lợi ích của ứng dụng Core Banking đã được nhìn thấy rõ nhất là trong

xu hướng hiện đại hóa công nghệ ngân hàng và sự hội nhập quốc tế hiện nay Khi đầu tư vào Core Banking tính bảo mật thông tin cao hơn, hạch toán sổ sách chứng từ kế toán thuận tiện hơn

Những lợi ích mang lại của một Core Banking hiện đại biểu hiện trong khai thác sản phẩm, dịch vụ cả về số lượng và chất lượng Có thể thấy, nhiều phần mềm mới còn chứa tham số rất lớn để mỗi khi ngân hàng muốn phát triển một dịch vụ, sản phẩm sẽ dễ dàng hơn, chỉ cần định nghĩa tham số là có thể tạo sản phẩm mới mà không phải sửa thẳng vào code của chương trình

Hệ thống T24 có thể tự động hóa lịch trình công việc, phục hồi nhanh các yêu cầu của khách hàng, có thể thực hiện tới 1.000 giao dịch/giây, quản trị tới 50 triệu tài khoản khách hàng và hỗ trợ thực hiện giao dịch qua hệ thống 24h/ngày

Ngoài ra, nhờ có Core Banking mà việc quản lý nội bộ chặt chẽ, hiệu quả hơn Trước đây, khi các ngân hàng chưa có core hiện đại hoặc dùng core lỗi thời, việc quản lý khách hàng rất rải rác và vô cùng bất tiện cho khách

3

hàng Tiền gửi ở đâu, phải đến đó, không thể rút ở điểm giao dịch khác, mặc

dù các điểm này đều trong cùng hệ thống một ngân hàng Thậm chí khách hàng muốn giao dịch ở bao nhiều điểm thì phải mở bấy nhiêu tài khoản Với

sự ra đời của Core Banking hiện đại, khách hàng chỉ cần có một mã duy nhất

ở ngân hàng là có thể giao dịch với rất nhiều sản phẩm, và ở bất cứ điểm giao dịch trong cùng hoặc không trong cùng một hệ thống

Đặc biệt, tiện ích của Core Banking là có thể quản trị rủi ro tốt hơn như giúp ngân hàng quản trị rủi ro thị trường, quản lý rủi ro tín dụng, thanh khoản

và tác nghiệp… với nhiều mức quản lý khác nhau Bên cạnh đó nhờ sự ưu việt tập trung hóa của Core Banking mà có thể nâng cao việc quản lý tài khoản khách hàng và cung cấp dịch vụ khách hàng

Tuy nhiên, yêu cầu của việc triển khai Core Banking hay việc hiện đại hóa ngân hàng còn có không ít khó khăn Một Core Banking hiện đại phải đáp

ứng việc quản lý chặt chẽ, đầy đủ, vận hành nhanh và đáp ứng tính mở khi

Ngân hàng muốn triển khai thêm một số dịch vụ khác nữa, chẳng hạn như Mobile Banking, Internet Banking, SMS, ATM… Chính vì vậy ngoài việc đòi hỏi một lượng vốn lớn để đầu tư triển khai Core Banking thì còn nhiều nhân

tố khác trong việc triển khai hệ thống công nghệ thông tin hiện đại

Hệ thống Core Banking mới phải thỏa mãn yêu cầu quản lý nhà nước có thể thay đổi theo từng thời kỳ, tình hình thực tế… của Ngân hàng nhà nước Việt Nam Quy trình nghiệp vụ từ ngân hàng nhà nước rót xuống các ngân hàng thương mại nhiều lúc không tương thích với hệ thống Core Banking của các ngân hàng, nhất là các ngân hàng nước ngoài Ví dụ khi phân loại tài khoản, có những loại thì phân loại theo tiền như đô la mỹ, nhân dân tệ, bảng anh, euro , có những loại thì gộp chung Với hệ thống tài khoản nước ngoài là

đa tệ và chỉ cần một tài khoản có thể áp dụng với nhiều ngoại tệ khác nhau, nhưng ở Việt Nam, hệ thống tài khoản, mẫu báo cáo thường thay đổi và các Core Banking nước ngoài rất khó đáp ứng

Trong bối cảnh ở Việt Nam đó là thói quen sử dụng tiền mặt rất phổ biến, cộng với hệ thống hạ tầng chưa tốt nên dù các ngân hàng rất mong muốn phát triển mạnh sản phẩm dịch vụ nhưng điều này gặp vô vàn khó khăn

4

Khi sử dụng hệ thống thông tin mới luôn gắn với việc làm mới ngân

hàng, phải cải tổ toàn bộ hoạt động từ tổ chức, đào tạo người, quy trình làm việc, và đó thực sự là quá trình khó khăn, mệt mỏi Để phát huy hết tính năng

và công hiệu của công nghệ thì trong mỗi ngân hàng từ giám đốc, phòng ban, nhân viên phải thay đổi lề thói, quy trình làm việc, tầm nhìn chiến lược và sản phẩm dịch vụ

Việc triển khai Core Banking phụ thuộc rất lớn vào vốn và kinh nghiệm

và đội ngũ nhân lực của mỗi ngân hàng Nhìn sang các ngân hàng nước ngoài

có thể thấy họ được trang bị hệ thống Core Banking cực kì hiện đại do họ mang từ ngân hàng mẹ sang, điển hình như ANZ, DeutscheBank, HSBC, Citibank

Việc ứng dụng giải pháp ngân hàng lõi tại các ngân hàng Việt Nam hiện nay gặp rất nhiều khó khăn và quản lý không đồng đều, bởi việc ứng dụng này phụ thuộc vào vốn và kinh nghiệm ở mỗi ngân hàng Có ngân hàng ứng dụng công nghệ thông tin ở mức thấp – chi phí khoảng 200 ngàn đến dưới

500 ngàn USD, chủ yếu để giải quyết các nghiệp vụ và giao dịch bình thường

Có ngân hàng ứng dụng công nghệ ở mức độ cao, chi phí trên 5 triệu USD, nhưng chưa sử dụng hết các tính năng Sự chưa đồng đều còn thể hiện ở việc quản lý dữ liệu và online toàn hệ thống vẫn chưa thực sự được phát triển mạnh

Thách thức cạnh tranh lớn nhất của ngân hàng Việt Nam khi hội nhập là chất lượng dịch vụ So với ngân hàng quốc tế, ngân hàng Việt Nam có thể cung cấp các dịch vụ tương đương như Mobile banking, Internet banking Nhưng vấn đề quản trị chất lượng dịch vụ của các hệ thống không phải đơn giản Ngân hàng Việt Nam hiện nay là chỉ lo sao cho có dịch vụ Nhưng để duy trì và duy trì tốt thì chưa được xem xét thỏa đáng Mặt khác, phần lớn hệ thống tại ngân hàng Việt Nam hiện nay mới chỉ dừng ở mức có sự cố thì khắc phục Trong khi, yêu cầu quan trọng đối với quản trị hệ thống là phải cảnh báo trước sự cố, khi đó ngân hàng Việt Nam cần có công cụ đánh giá, thống

kê thường xuyên

5

Core Banking đòi hỏi đồng bộ cả về mạng, bảo mật và các ứng dụng khác, nhưng hiện nay mới chỉ đồng bộ từng phần, mà chưa đáp ứng nhu cầu quản trị tập trung Tuy rằng các kiến trúc, mạng lưới chi nhánh, mạng lưới cung cấp dịch vụ, hệ thống mạng diện rộng, mạng cục bộ, Core Banking, bảo mật nhưng thiếu một thiết kế tổng thể

Bên cạnh đó, việc lựa chọn giải pháp Core Banking nào cũng làm nhiều ngân hàng đau đầu Trong quá trình hội nhập thì các ngân hàng giờ đây cần phải chỉnh lại các quy trình nghiệp vụ và dịch vụ cung cấp cho các khách hàng theo quy chuẩn quốc tế, để từ đó triển khai ứng dụng các giải pháp công nghệ thông tin Tuy nhiên các giải pháp của nước ngoài thì rất đắt và gặp khó khăn trong vấn đề thích ứng với các đặc thù của ngành ngân hàng Việt Nam Hiện nay, ở nước ta, một số phần mềm Core Banking đã được sử dụng tại các ngân hàng như: Siba; Bank 2000; SmartBank; Symbol System; Teminos; Iflex; Huyndai; Sylverlake; TCBS, tức giải pháp ngân hàng phức hợp

Core Banking chính là biểu hiện rõ nhất của cuộc chạy đua về công nghệ hiện đại hóa ngân hàng, giúp khách hàng có được nhiều tiện ích khi thực hiện các thanh toán thương mại và từng bước đưa Việt Nam hội nhập với kinh

tế thế giới Năm 2005, Việt Nam có 7 ngân hàng triển khai Core Banking, nhưng đến nay đã có 36 ngân hàng quốc doanh và cổ phần trong nước triển khai hệ thống này

Xây dựng quy trình quản lý sự cố phát sinh công nghệ thông tin trong quá trình hoạt động theo một cách chung nhất, chính thống là cần thiết và trong cấp độ nguy hiểm cao nhất với hoạt động của ngân hàng đã có phương

án sẵn sàng dự phòng trong tình huống thảm họa xảy ra với Ngân hàng bị tấn công Luận văn đề xuất các giải pháp kiến trúc dự phòng cho hệ thống Core Banking tại Maritime Bank Việt Nam

Nhận thức được (i) vai trò của Core Banking; (ii) nhu cầu hiện đại hóa công nghệ tổ chức của Ngân hàng TMCP Hàng Hải Việt Nam ( Maritime Bank); (iii) cần thiết của quản trị rủi ro trong hệ thống thông tin ngân hàng, tôi có nguyện vọng thực hiện luận văn tốt nghiệp cao học tại Trường Đại học

6

Hòa Bình về đề tài Lý thuyết chắc chắn và ứng dụng trong xây dựng hệ thống

dự phòng Core Banking tại Maritime Bank Việt Nam

Cấu trúc của luận văn

Luận văn chia thành các chương:

• Chương đầu đề cập lý thuyết chắc chắn, những vấn đề nảy sinh trong quá trình xử lí dữ liệu, như thiết dữ liệu, dữ liệu sai, rủi ro khi nhập dữ liệu… có thể được xử lí theo nguyên lí của lý thuyết chắc chắn;

• Chương 2 đề cập hoạt động ngân hàng và các nguy cơ rủi ro về

an toàn thông tin; từ đó đặt ra nhu cầu đối với quá trình công nghệ thông tin và sử dụng lý thuyết chắc chắn;

• Chương 3 là giải pháp đảm bảo an toàn dữ liệu tại Maritime Bank Việt Nam, trình bày các đề xuất của luận văn trong hệ thống thông tin ngân hàng mà học viên công tác Nội dung chương 3 là kết nối các kiến thức chương 1, đáp ứng nhu cầu tại ngân hàng như đã trình bày trong chương 2 Đề xuất của luận văn là ở các qui trình an toàn thông tin, tránh rủi ro, nhờ các biện pháp dự phòng, thực hiện tại Ngân hàng Học viên tham gia một phần trong quá trình thực hiện này

Luận văn có phần mở đầu và phần kết luận Cuối luận văn là danh sách các tài liệu tham khảo và trích dẫn

7

Chương 1

Lý thuyết chắc chắn và ứng dụng cho bài toán ngân hàng

Một dạng thông dụng của lí thuyết xác suất để lập luận không chính xác

trong hệ chuyên gia là lí thuyết chắc chắn Lí thuyết này phát triển trên hệ

thống chuyên gia trong y học MYCIN và liên quan đến các độ đo giám định

độ tin cậy, chứ không gắn chặt với các đánh giá xác suất một cách chặt chẽ Các kết quả nghiên cứu và ứng dụng dẫn đến việc phát triển mô hình chắc chắn

Mô hình này cho phép lập luận không chính xác trong nhiều ứng dụng;

ở đây là các hoạt động quản lí rủi ro trong dự phòng Core Banking ngân hàng

1 1 Tổng quan về lý thuyết chắc chắn

Theo [1], các chuyên gia thường đánh giá, suy xét khi giải vấn đề Thông tin về vấn đề có thể không đầy đủ và một vài tri thức có thể không xác thực Do vậy mà họ cần thích nghi với tình trạng này và tiếp tục lập luận thông minh Đây chỉ là một trong các khó khăn thôi, vì còn khó khăn khác nữa là việc quản lý lập luận không chính xác

Người ta có thể dùng lí thuyết xác suất Dù rằng chặt chẽ về toán học, kĩ thuật này đòi hỏi cơ sở thống kê mà ít loại bài toán trong hệ chuyên gia đáp ứng được Chẳng hạn khi xác định người bệnh có đau nặng không, người ta thu được kết luận với tin cậy 0 7 Do thiếu cơ sở thống kê nên những thông tin để giúp phán đoán không dùng được trong các luật của hệ chuyên gia mà chỉ dùng để giải thích; và vì vậy không thể suy luận xác suất bằng kĩ thuật Bayes được

Tuy nhiên nếu xem hệ chuyên gia như cơ chế giải vấn đề may rủi thì người ta có thể dùng các kĩ thuật lập luận không chính xác như trong MYCIN

8

1 1 1 Lập luận không chính xác

Theo [3] MYCIN là hệ chuyên gia được phát triển để cho lời khuyên khi chẩn đoán các bệnh nhân nhiễm trùng máu Đây là bài toán điển hình trong nhiều lĩnh vực, nhưng có ý nghĩa đặc biệt trong lĩnh vực y học do các ràng buộc về thời gian Trong phòng cấp cứu cần thiết có các hành động đúng và nhanh Đối với các bệnh đe doạ đến tính mạng, thầy thuốc có thể tiến hành xét nghiệm trước đó để có các thông tin đầy đủ và chính xác Nhưng đối với

ca cấp cứu, các bác sĩ buộc phải xử lý với tình trạng thông tin không chính xác và phải có chẩn đoán tốt nhất

Về suy luận không chính xác trong lĩnh vực y học, người ta thấy có nhiều luật không chính xác Một số ít luật có thể giúp chẩn đoán tốt cho ca bệnh, nhưng những luật này ít được dùng đến Phần lớn các luật dùng trong y học ở dạng không chính xác Chẳng hạn thầy thuốc phát biểu "nếu thấy triệu chứng A và B thì có vài chỉ định liên quan đến bệnh này, bệnh nọ"

Nhóm MYCIN ghi nhận rằng kĩ thuật lập luận không chính xác cần được tích hợp vào hệ thống Họ cũng thấy được tính không phù hợp của tiếp cận xác suất vì không đáp ứng được các thông tin thống kê về vấn đề Để quản lý tình trạng này, nhóm MYCIN quyết định nới lỏng các yêu cầu chặt chẽ của kĩ thuật xác suất cổ điển và tìm tiếp cận đơn giản hơn Trước tiên họ

quyết định đặt các câu hỏi liên quan đến điều họ muốn kĩ thuật lập luận không chính xác thực hiện, chứ không hỏi về cách thức thực hiện Họ cảm thấy việc

quan sát cách chuyên gia làm trên thông tin không chính xác sẽ nhìn thấu đủ

để phát triển các yêu cầu của kĩ thuật lập luận không chính xác

1 1 2 Biểu diễn vấn đề không chắc chắn

Nhóm MYCIN quan sát thấy thầy thuốc làm việc với ca cấp cứu thường dùng thông tin không chắc chắn, thậm chí không rõ Họ ghi nhận rằng dưới điều kiện như vậy, thầy thuốc thường phân tích thông tin sẵn có với thuật ngữ định tính như "có thể", "có vẻ như ", "hầu như chắc chắn rằng "

Đối với dấu hiệu không chắc chắn, nhóm MYCIN quyết định gán một nhân tố chắc chắn "CF" để thể hiện độ tin cậy của thầy thuốc vào dấu hiệu đó

Số này chạy từ -1, ứng với sai hoàn toàn, đến +1, ứng với đúng hoàn toàn Số

9

dương thể hiện sự tin cậy, số âm thể hiện sự không tin cậy Chẳng hạn thầy thuốc phát biểu rằng dấu hiệu nào đó có thể đúng, thì giá trị CF = 0 6 được gán cho dấu hiệu đó

1 1 3 Luật không chắc chắn

Theo [1, 3] nhóm MYCIN cũng quan sát thấy các thầy thuốc thường dùng suy luận không chính xác trên các thông tin có sẵn Tức là thầy thuốc chỉ tin một phần vào sự suy xét trên dấu hiệu nào đó Đối với suy luận không chính xác, cần gán giá trị CF cho mỗi luật

Thí dụ có luật: IF có dấu hiệu thương tổn AND hình thái khuẩn cầu AND hình thể trên vết thương là chuỗi THEN chỉ định bị khuẩn cầu chuỗi với

Người ta cũng thấy rằng khi độ tin cậy của thày thuốc vào dấu hiệu đang

có là nhỏ hơn sự chắc chắn thì độ tin cậy này trong suy luận liên quan cũng giảm đi Chẳng hạn luật đầu tiên kết luận về việc chỉ ra tổ chức bị viêm dạng hạt, người ta dùng giả thiết không chắc chắn, CF (Ei) <1 và mức độ tin cậy trong kết luận giảm, CF(H) <0 7 Hệ thống MYCIN áp dụng suy luận không chắc chắn theo kĩ thuật này

1 1 5 Xử lí nhiều nguồn thông tin

Khi người ta nhận thông tin trợ giúp để kết luận từ nhiều nguồn, người

ta thấy rằng kết luận có độ tin cậy lớn hơn Do vậy lí thuyết chắc chắn cần tăng độ tin cậy về kết luận khi nhận trợ giúp từ nhiều luật Thí dụ:

• Luật R1 IF A AND B THEN Z CF = 0 8

• Luật R2 IF C AND D THEN Z CF = 0 7

Cả hai luật đều kết luận về sự kiện Z, nhưng với giá trị CF khác nhau Nếu hai luật đều cháy thì người ta thu được hai độ tin cậy về Z Ở đây người

ta cần kết hợp hai luật, tức kết hợp hai nhận định "có khả năng" và "có thể"

Thuộc tính tráo đổi quan trọng ở chỗ tránh được sự phụ thuộc về thứ tự

áp dụng luật Chẳng hạn khi có hai luật có cùng độ tin cậy về quyết định cuối cùng, thì áp dụng luật nào đầu tiên cũng như vậy Còn thuộc tính thứ hai cho phép tổ hợp theo nghĩa tiệm cận về kết luận hợp lí, trừ phi người ta có giải pháp đưa ra lời giải đúng Với cách làm này, kết luận sẽ có độ tin cậy tăng từng phần

1 1 6 Cơ sở của lý thuyết chắc chắn

Phần trên đã nêu lên sự cần thiết về mô hình chắc chắn Nhu cầu này sinh ra một cách tự nhiên khi thày thuốc quản lý thông tin không chính xác

Dù vậy nhưng cần khẳng định rằng mô hình này không dựa y như lí thuyết xác suất mà chỉ theo lí thuyết này khi thành lập mô hình

Lí thuyết chắc chắn giả thiết rằng xác suất trước của giả thuyết H, p(H) thể hiện độ tin cậy được giám định của chuyên gia về H Độ không tin p(~H) của chuyên gia được coi là tuỳ theo ràng buộc xác suất truyền thống, tức p(H)

+ p(~H) = 1 Ngoài ra còn giả thiết rằng nếu chuyên gia quan sát dấu hiệu

thấy: xác suất về giả thuyết có dấu hiệu (tức xác suất có điều kiện p(H|E)) lớn

hơn xác suất trước (tức p(H)), tức là p(H|E) > p(H) đúng, thì độ tin cậy của

chuyên gia về giả thuyết tăng tỉ lệ thuận đến (p(H|E) - p(H))/ (1 - p(H)) Mặt khác nếu p(H|E) < p(H) thì độ tin cậy của chuyên gia về giả thuyết

sẽ giảm tỉ lệ thuận về (p(H) - p(H|E))/ p(H)

Cái chính của lí thuyết này là khi có một chút dấu hiệu, độ tin cậy của chuyên gia về giả thuyết có thể tăng hay giảm chút ít Ý này được phát triển gắn với độ đo MB và MD

Các giá trị này thoả mãn 0  MB, MD  1 Chúng được xác định hình thức theo xác suất trước có điều kiện theo các công thức sau:

• MB(H, E) = 1 nếu p(H) = 1, ngược lại thì MB(H, E) = (max{p(H|E), p(H)} - p(H))/ (1- p(H))

Giá trị -1 của CF thể hiện "sai chắc chắn" và +1 thể hiện "đúng chắc chắn" Giá trị 0 cho biết "không biết", giá trị âm thể hiện độ không tin vào giả thuyết trong khi giá trị dương ngược lại

1 2 Vấn đề không chắc chắn đối với bài toán ngân hàng

Nhiều năm qua, mô hình chắc chắn đã phát triển thành kĩ thuật thực tế

để quản lý lập luận không chính xác trong hệ chuyên gia Tuy các khái niệm

MB, MD và CF vẫn được sử dụng, nhưng mới ở mức đơn giản Sau đây là dạng sử dụng hiện thời của mô hình chắc chắn

Các thí dụ sử dụng ở đây gắn với bài toán của dự phòng Core Banking tại Ngân hàng TMCP Hàng Hải Việt Nam ( Maritime Bank) [5] Các xử lí dữ liệu thực sự sẽ được trình bày trong chương 3 của luận văn

Hình 1 1 Một số biểu tượng ngân hàng

1 2 1 Dấu hiệu không chắc chắn

Các hệ thống dùng lập luận không chính xác cần có cách thể hiện các dấu hiệu không chắc chắn Chẳng hạn "có thể máy chủ hỏng" là câu có độ không chắc chắn do "có khả năng "

Hình 1 2 Chuyển giá trị tin cậy sang ngôn ngữ thực

Các nhân tố chắc chắn không phải là xác suất, mà là các độ đo không hình thức về sự tin tưởng vào một phần dấu hiệu Chúng thể hiện mức độ mà người ta tin rằng dấu hiệu là đúng Để thể hiện độ tin cậy này trong hệ chuyên gia, người ta viết câu dưới dạng chính xác và thêm giá trị CF phù hợp Chẳng

hạn "có thể thay máy cá nhân cho Giám đốc" hay "thay máy cá nhân cho Giám đốc, CF = 0 6"

-1 -0.2 0 +0.2 +1

Không biết

Chắc chắn sai Chắc chắn đúng

Hình 1 3 Các giá trị không chắc chắn, từ -1 đến +1

13

1 2 2 Các luật không chắc chắn

CF dùng cho câu và cho cả các luật để thể hiện quan hệ không chắc chắn giữa dấu hiệu E trong giả thiết của luật và giả thuyết H trong phần kết luận của luật Cấu trúc cơ bản của luật dùng trong mô hình chắc chắn có dạng IF E THEN H CF (luật), trong đó CF (luật) thể hiện mức độ tin cậy H khi có E Tức là khi E là đúng thì người ta tin H theo CF (H, E) = CF (luật)

Thí dụ Luật 1 IF mất điện, E THEN kích hoạt hệ thống dự phòng điện,

H với CF = 0 8 sẽ được tham chiếu đến bản miêu tả để hiểu rằng "nếu xảy ra mất điện lưới, thì hầu chắc chắn bật hệ thống dự phòng điện"

1 2 3 Lan truyền chắc chắn đối với các luật có giả thiết đơn

Lan truyền nhân tố chắc chắn liên quan đến việc thiết lập mức độ tin cậy vào kết luận của luật trong trường hợp dấu hiệu trong giả thiết là không chắc chắn Đối với luật có phần giả thiết đơn, người ta tính CF (H, E) = CF (E) *

CF (luật)

Thí dụ trên nhưng có dấu hiệu thuận về E, tức CF (E) = 0 5 thì

CF (H, E) = 0 5 * 0 8 = 0 4 Điều này có nghĩa "Có thể mất điện" Nếu người ta có dấu hiệu không thuận về E, tức CF (E) = -0 5 thì CF (H, E) = -0

4; có nghĩa "có thể không mất điện "

Thí dụ cho thấy dấu hiệu bổ sung tính tin cậy hay không tin cậy về một giả thuyết

1 2 4 Các luật AND

Mô hình chắc chắn dùng các luật có dạng

IF E1 AND E2 AND AND En THEN H CF (luật)

CF (H, E1 AND E2 AND ) = min{CF (Ei)} * CF (luật)

14

CF (kích hoạt hệ thống dự phòng = min {1 0, 0 7} * 0 8 = 0 56; có

nghĩa "có khả năng kích hoạt hệ thống dự phòng"

1 2 5 Các luật OR

Các luật trong mô hình này có dạng

IF E1 OR E2 OR OR En THEN H CF (luật)

CF (H, E1 OR E2 OR ) = max {CF (Ei)} * CF (luật)

Thí dụ

IF mất điện OR ổn áp hư THEN hệ thống điện hư CF = 0 9

Giả thiết rằng CF (mất điện) = 1 0 và CF (ổn áp hư) = 0 7 thì

CF (hệ thống điện hư) = max {1 0, 0 7} * 0 9 = 0 9; có nghĩa "hầu chắc chắn là hệ thống điện hư"

1 3 Lan truyền chắc chắn đối với các luật có cùng kết luận

Trong một vài ứng dụng người ta có thể viết nhiều luật về cùng một kết luận Chẳng hạn để tin rằng trời sắp mưa, người ta căn cứ vào ý kiến của nhà

dự báo khí tượng hay vào nông dân

• Luật 1 IF máy chủ hư, E1 THEN thay máy chủ, H với CF (luật 1) = 0

Trong một vài ứng dụng, nên tính đến MD và MB như các trợ giúp khi

có thêm thông tin Nhưng trong vài ứng dụng khác, người ta chỉ quản lý một bản ghi về giá trị CF được cập nhật Trong các ứng dụng này, người ta có thể dùng đẳng thức:

1 CF kết hợp = CF 1 + CF 2 (1-CF 1 ) khi cả hai CFi là dương;

2 CF kết hợp = CF 1 + CF 2 (1+CF 1 ) khi cả hai CFi là âm; và

15

3 CF kết hợp = (CF 1 + CF 2 ) / (1 - min{|CF 1 |, |CF 2 |}), trong đó CFi thể hiện tin cậy vào H theo luật thứ i

Các đẳng thức tính MD, MB và CF trong mô hình chắc chắn có thuộc tính hoán đổi, tiệm cận

Mô hình chắc chắn cần tính chất này để thu thập các dấu hiệu theo trật

tự tuỳ ý Tức là nếu có nhiều luật thu thập thông tin thì giá trị tổng hợp CF không bị lệ thuộc vào thứ tự xử lý luật

1 4 Kết luận chương

Lí thuyết chắc chắn đảm bảo tiếp cận thực tế cho lí thuyết xác suất trong việc quản lí lập luận không chính xác trong hệ thống chuyên gia Nó dựa trên các giá trị tin cậy và phù hợp với các bài toán không nhiều dữ liệu thống kê Mặc dù thiếu nền tảng hình thức, kĩ thuật này cung cấp cho người ta một cách đơn giản và trong nhiều ứng dụng có thể thu được kết quả chấp nhận được

• Lí thuyết chắc chắn cung cấp tiếp cận kiểm chứng các suy luận không chính xác

• "Độ đo tin cậy" MB là con số phản ánh mức độ tin cậy tăng

về giả thuyết H khi có dấu hiệu E

• "Độ đo phản bác" MD là con số phản ánh mức độ không tin vào H khi có dấu hiệu E

• "Nhân tố chắc chắn" CF là số phản ánh mức độ tinh về độ tin cậy vào H, CF = MB-MD

• Lí thuyết chắc chắn dùng các luật có dạng IF E THEN H CF (luật)

• Với các luật đơn giản thì CF (H, E) = CF (E) * CF (luật)

• Với các luật AND thì CF (H, E1 AND E2 AND ) = min {CF (Ei)} * CF (luật)

• Với các luật OR thì CF (H, E1 OR E2 OR ) = max {CF (Ei)} * CF (luật)

16

• Đối với trường hợp nhiều luật kết luận về một giả thuyết thì các giá trị CF được kết hợp lại theo kĩ thuật "thu thập thêm dấu hiệu"

17

Chương 2 Hoạt động ngân hàng và tránh rủi ro về dữ liệu

2 1 Rủi ro về dữ liệu trong hệ thống ngân hàng

Mục tiêu chính của quy trình quản lý sự cố: nhằm tạo ra một quy trình quản lý và điều phối để khôi phục các dịch vụ IT bị sự cố trở về trạng thái bình thường trong thời gian ngắn nhất, và với sự ảnh hưởng ít nhất đối với hoạt động sản xuất kinh doanh của Ngân hàng

Mục tiêu khác là đo lường, đánh giá được hiệu quả công việc xử lý sự cố

từ các nhà cung cấp dịch vụ công nghệ

2 1 2 Phạm vi

Phạm vi áp dụng của các quy trình quản lý sự cố bao gồm tất cả các sự

cố xảy ra tại khu vực của người sử dụng dịch vụ IT tại các chi nhánh, hội sở, trang thiết bị hạ tầng IT trang bị cho các khu vực và các dịch vụ IT được triển khai tại Trung tâm dữ liệu và các trung tâm dự phòng

18

Hình 2 1 Hoạt động tại Maritime Bank

Các sự cố thông dụng thường xảy ra khi tác nghiệp có:

1 Một dịch vụ CNTT ngưng hoạt động hoặc hoạt động không

ổn định vì một lý do nào đó

2 Lỗi phát sinh từ các ứng dụng trong quá trình phát triển

3 Lỗi do đường truyền gián đoạn từ các nhà cung cấp dịch vụ

4 Lỗi do trục trặc phần cứng hệ thống (trong quá tình hoạt động)

5 Lỗi do các vấn đề bảo mật gây ra (hacker xâm nhập, bị nhiễm virus…)

6 Sự cố do trục trặc hệ thống cung cấp điện (ngoài ý muốn)

7 Sự cố do các nguyên nhân khách quan như cháy, nổ, thiên tai, khủng bố, phá hoại

2 2 Hoạt động an toàn dữ liệu tại Maritime Bank Việt Nam

2 2 1 Chính sách nội bộ

2 2 1 1 Chính sách quy định cho người dùng

Chính sách gửi yêu cầu qua Service Desk

Người dùng khi có các thông báo sự cố gửi đến Nhà cung cấp dịch vụ cần phải thực hiện bắt buộc thông qua các kênh hỗ trợ sau:

Các sự cố là lỗi của các ứng dụng nghiệp vụ, phần mềm văn phòng hay phần mềm tiện ích người dùng cần phải thông báo cho IT Service Desk qua địa chỉ email đã được cung cấp Trước khi email cần phải sao chụp lại màn hình thông báo lỗi và gửi đính kèm qua email đến IT Service Desk Việc sao chụp lại màn hình thông báo lỗi sẽ giúp các chuyên gia CNTT chuẩn đoán, phát hiện nhanh xử cố xảy ra, giúp giảm thiểu thời gian xử lý Trong trường hợp người dùng đã được hướng dẫn cách gửi thông báo sự cố qua Web Portal thì có thể sử dụng công cụ Web Portal như là một sự lựa chọn thứ hai

Các sự cố phát sinh do phần cứng không khởi động được, không kết nối được vào mạng nội bộ ngân hàng thì người dùng cần phải thông báo qua

19

điện thoại cho IT Service Desk theo các số điện thoại đã được Nhà cung cấp dịch vụ cung cấp

Chính sách chứng nhận kết quả xử lý yêu cầu

Người dùng sau khi thông báo sự cố đến IT Service Desk cần phải có trách nhiệm kiểm tra, xác nhận kết quả xử lý do các chuyên gia CNTT được giao xử lý thông báo thông qua email Việc kiểm tra và xác nhận kết quả xử

lý từ người yêu cầu là một thủ tục mang tính bắt buộc làm cơ sở cho đóng lại các yêu cầu và kiểm soát chất lượng Trường hợp người dùng không thể kiểm tra được kết quả vì một lý do nào đó cần phải ủy quyền cho người dùng khác kiểm tra và xác nhận kết quả

2 2 1 2 Các chính sách áp dụng cho cán bộ, nhân viên tin học (IT) Chính sách tiếp nhận yêu cầu một cửa thông qua Service Desk

Tất cả các cuộc gọi, email thông báo sự cố từ người dùng đến Nhà cung cấp dịch vụ đều phải được ghi nhận qua các nhân viên IT Service Desk Các trường hợp người dùng liên lạc trực tiếp lên các tuyến trên cần phải được hạn chế, nhắc nhở và hướng dẫn họ thực hiện qua IT Service Desk Chỉ có các nhân viên Service Desk mới được phép cập nhật các thông báo sự cố từ người dùng và tạo ticket cho việc giám sát, theo dõi tiến trình xử lý sự cố

Chính sách phân loại sự cố

Tất cả các sự cố đều phải được đánh giá, phân loại theo kiểu sự cố, mức

độ ảnh hưởng, mức độ khẩn cấp và thiết lập mức ưu tiên Việc thiết lập mức

độ ưu tiên của sự cố là cơ sở để phản hồi, xử lý sự cố đúng thời hạn cam kết theo Service Catalogue và là cơ sở để báo động sự cố đến các cấp lãnh đạo của nhà cung cấp dịch vụ Các đơn vị hỗ trợ dịch vụ thuộc Level 1 và Level 2 (gồm IT Service Desk, IT khu vực, các đơn vị vận hành Trung tâm Dữ liệu) chỉ được thiết lập mức ưu tiên của sự cố từ mức 7 đến mức 4 Các sự cố có mức ảnh hưởng lớn hơn và mức ưu tiên cao hơn từ mức 3 đến mức 1 thì phải chuyển ngay cho Incident Manager thẩm định, kiểm tra trước để thiết lập mức

ưu tiên

20

Chính sách xử lý và cập nhật tình trạng xử lý

Các cán bộ, nhân viên được phân công xử lý sự cố cần có trách nhiệm cập nhật tình trạng và ghi lại kết quả trong quá trình xử lý các ticket Sau khi

hoàn tất quá trình xử lý phiếu xác nhận, hay ticket, nhân sự được giao xử lý

có trách nhiệm thông báo kết quả đến người sử dụng Nhân viên cần chủ động liên hệ với người yêu cầu khi cần thêm thông tin hoặc cần bổ sung các thông tin trong quá trình xử lý

Bảng 2 1 Qui trình nhận diện lỗi phát sinh

Quy trình quản

lý

Bao gồm các bước thực hiện (gọi là activity) được phối hợp giữa

các đơn vị của nhà cung cấp dịch vụ nhằm chuyển giao một kết quả

cụ thể (gọi là deliverable) đến người dùng dịch vụ Mỗi bước thực

hiện bao gồm các thủ tục chi tiết (gọi là procedure)

Nhà cung cấp

dịch vụ

Nhà cung cấp dịch vụ được mô tả ở đây là Khối CNNH

Khách hàng Là các đơn vị kinh doanh/nghiệp vụ trên toàn hệ thống ngân hàng

Service Line

(Đơn vị quản lý

dịch vụ chuyên

trách)

Là một đơn vị quản lý dịch vụ chuyên trách của nhà cung cấp dịch

vụ Đơn vị quản lý dịch vụ chuyên trách có thể là:

• Đơn vị quản lý dịch vụ desktop cấp khu vực (IT khu vực)

• Đơn vị quản lý dịch vụ desktop cấp chi nhánh (IT chi nhánh)

• Đơn vị quản lý dịch vụ hạ tầng CNTT

• Đơn vị quản lý dịch vụ ứng dụng CNTT

Ticket Là một số định dạng được bộ phận cung cấp cho người dùng nhằm

nắm bắt, theo dõi tiến trình xử lý một yêu cầu dịch vụ hoặc sự cố gửi

Yêu cầu thay đổi có 02 dạng:

01/Thay đổi tiêu chuẩn – Là các yêu cầu thay đổi có mức độ rủi ro thấp, gần như không đáng kể và đã được chỉ định trước người phê duyệt Yêu cầu dịch vụ tiêu chuẩn có thể thực hiện theo quy trình quản lý yêu cầu dịch vụ

02/ Thay đổi ngoài tiêu chuẩn – Là các yêu cầu thay đổi phát sinh rủi ro, cần được đánh giá, thẩm định kỹ bởi các đơn vị của nhà cung cấp dịch vụ CNTT và/hoặc các cấp lãnh đạo đại diện cho các khách hàng

Mức độ ưu tiên

của sự cố

Mức độ ưu tiên của sự cố được thiết lập dựa trên sự tổ hợp giữa mức

độ ảnh hưởng của sự cố với mức độ khẩn cấp của sự cố

Phản hồi sự cố

Thời gian phản hồi sự cố tính từ lúc nhận được thông báo đến lúc nhà cung cấp phân công nhân sự đến vị trí (remote or on-site) để khắc phục

Là cơ sở dữ liệu, tập hợp các hướng dẫn, các chú ý, tập hợp câu hỏi

và trả lời cho những sự cố đã xác định (Known Errors) KB thường

là được tổ chức theo chủ đề, phân loại theo hệ thống hoặc các vấn đề

có liên quan, và KB thường phải có khả năng tìm kiềm theo từ khóa nhằm giúp nhân viên xử lý sự cố tìm ra câu trả lời nhanh nhất cho sự

Là các nhân tố được quy định nhằm xác định các mục tiêu quản lý

có thể đạt được CSF là đầu vào cho việc thiết lập các chỉ tiêu đánh giá hiệu suất KPI

RACI viết tắt của những từ sau:

• R (viết tắt của từ Responsible) là người chịu trách nhiệm thực hiện 01 công việc theo quy trình

• A (viết tắt của từ Accountable) là người có trách nhiệm xem xét, phê duyệt 01 công việc theo quy trình

• C (viết tắt của từ Consulted) là người có tri thức, kinh nghiệm cần được tham vấn trong quá trình xử lý các công việc theo quy trình (không tham gia trực tiếp)

• I (Informed) là người cần nhận được kết quả hoặc thông báo về tiến trình công việc

• Là người quyết định việc thông báo sự cố

là 01 vấn đề đến Problem Manager trong quá trình tiếp nhận, xử lý tại Level 1

• Là người quản lý bộ phận Service Desk, người có trách nhiệm xem xét phân công ticket cho các nhân viên Service Desk thực hiện các sự cố đơn giản (mức ưu tiên

từ P7->P6) nằm trong khả năng của Service Desk thuộc Level 1

• Quyết định việc chuyển cấp sự cố đến các

bộ phận chuyên trách có khả năng xử lý tốt nhất

• Điều phối các bộ phận chuyên trách để đảm bảo sự cố được xử lý, bàn giao đúng chất lượng và đúng thời hạn cam kết

• Tạo ticket (hoặc kết hợp ticket) để cập nhật thông tin yêu cầu

• Báo cáo cho Service Desk Manager và/hoặc Incident Manager để thiết lập mức độ ảnh hưởng, mức độ khẩn và mức

ưu tiên cho sự cố

25

• Xử lý các ticket được phân công

• Theo dõi, cập nhật kết quả xử lý sự cố cho người dùng

• Xác nhận với người dùng về kết quả xử

• Là người nhận ticket từ nhân viên Service Desk chuyển cấp đến

• Thực hiện phân công tiếp ticket cho các cán bộ chuyên trách trong đơn vị của mình xử lý yêu cầu

• Cập nhật cho Service Desk kết quả xử lý ticket

• Cập nhật, xác nhận với người dùng cuối

về tình trạng xử lý và kết quả xử lý ticket

5 Site IT Manager Level 1

• Là cán bộ quản lý dịch vụ CNTT cấp khu vực/chi nhánh Site IT Manager có trách nhiệm như sau:

• Phân công nhân viên chuyên môn xử lý các yêu cầu dịch vụ được Service Desk chuyển đến đúng thời hạn cam kết

• Quyết định việc tăng cấp cho các Level cao hơn xử lý hoặc trả ticket về lại Service Desk

• Hướng dẫn, tư vấn cách thức xử lý các ticket cho các nhân viên dưới quyền

• Phê duyệt kết quả xử lý của các nhân viên

• Đưa giải pháp xử lý vào KB

• Xem xét lại và đóng lại ticket

6 Site IT Operator Level

1

• Là nhân viên IT khu vực, IT chi nhánh có trách nhiệm nhận các ticket được phân công từ Service Desk Agent để xử lý tại chỗ người dùng như thay cable, thay mực

• Hướng dẫn, tư vấn cách thức xử lý các ticket cho các nhân viên dưới quyền

• Phê duyệt kết quả xử lý của các nhân viên

• Đưa giải pháp xử lý vào KB

• Xem xét lại và đóng lại ticket

9 Incident Manager

• Là cán bộ quản lý cấp cao nhất của Level

1 (phòng Hỗ trợ dịch vụ), có trách nhiệm trong quy trình quản lý sự cố như sau:

• Chịu trách nhiệm tiếp nhận, quản lý các

sự cố có mức ưu tiên cao hoặc các sự cố khó xử lý đòi hỏi sự phối hợp của một số đơn vị và nhà cung cấp công nghệ

• Quản lý, điều phối xử lý các sự cố trong phạm vi trách nhiệm được giao

• Thực hiện xem xét lại thường xuyên các

sự cố, đặc biệt là các sự cố chưa xử lý được

• Tạo hồ sơ vấn đề và thông báo cho Problem Manager nếu các sự cố là các vấn đề cần xử lý

• Đệ trình các yêu cầu thay đổi lên Change Manager, hoạch định thay đổi và tạo RFC cho các thay đổi đề xuất do sự cố

27

2 2 3 Qui trình xử lí lỗi chung

Qui trình xử lí lỗi phát sinh được thể hiện qua sơ đồ tổng thể Sơ đồ này được quán triệt trong các hoạt động ngân hàng, nêu trong chương 2 và chương 3 của luận văn

Hình 2 2 Sơ đồ tổng quan

Giải thích ý nghĩa của sơ đồ

Cơ sở đầu vào Thông báo sự cố từ người dùng/Quản lý giám sát các hệ thống tin học tại Trung tâm Dữ liệu và các trung tâm dự phòng Các thủ tục chi tiết

• Người dùng thông báo sự cố đến Service Desk

• Service Desk nhận yêu cầu, xác minh thông tin

• Service Desk xác định nếu là yêu cầu dịch vụ thì chuyển

sự cố thành yêu cầu dịch vụ và thực hiện theo quy trình quản lý yêu cầu dịch vụ

• Cập nhật thông tin sự cố vào CSDL quản lý

• Kết quả chuyển giao

• Thông tin sự cố được cập nhật vào CSDL quản lý

• Ticket được tạo và thông báo đến người yêu cầu

• Cơ sở đầu vào

• Sự cố được ghi nhận vào CSDL quản lý và ticket được tạo

• Các thủ tục chi tiết

• Phân loại sự cố theo dịch vụ bị sự cố

• Phân loại sự cố theo mức ảnh hưởng

• Phân loại sự cố theo mức độ khẩn

• Phân loại sự cố theo mức độ ưu tiên

• Nếu là sự cố nghiêm trọng thì xử lý theo hướng dẫn của quy trình quản lý sự cố nghiêm trọng

• Kết quả chuyển giao

• Sự cố được phân loại theo kiểu dịch vụ bị sự cố

• Sự cố được phân loại theo mức độ ảnh hưởng

• Sự cố được phân loại theo mức độ khẩn

• Sự cố được thiết lập mức ưu tiên

Mục tiêu: Mục tiêu của bước này là Service Desk sau khi

thực hiện phân loại sự cố, thiết lập mức ưu tiên và xác định sự

cố chỉ là mức độ bình thường thì thực hiện chuẩn đoán ban đầu và đánh giá khả năng xử lý, nếu sự cố nằm trong khả năng của Service Desk thì Service Desk sẽ thực hiện xử lý sự

cố, nếu sự cố vượt khả năng của Service Desk thì chuyển cấp lên tuyến cao hơn hoặc chuyển về cho IT khu vực/IT chi nhánh thực hiện điều tra và xử lý

Cơ sở đầu vào

• Sự cố được phân loại theo kiểu sự cố

• Sự cố được đánh giá mức ảnh hưởng, mức độ khẩn

• Sự cố được thiết lập mức ưu tiên

• Sự cố được xác định là nghiêm trọng hay thông thường

Các thủ tục chi tiết

• Khởi tạo chuẩn đoán và hỗ trợ ban đầu bởi Service Desk hoặc 01 đơn vị chuyên môn phù hợp nhất do Service Desk phân công

• Chuyển cấp xử lý nếu không đủ khả năng xử lý

• Nếu đủ khả năng xử lý thì thực hiện điều tra nguyên nhân

và chẩn đoán

• Xác định sự cố là một vấn đề (lỗi cần tìm nguyên nhân) hay không

• Nếu là một vấn đề thì Service Desk/Level 2 tạo hồ sơ vấn

đề và thực hiện theo quy trình quản lý vấn đề

Kết quả chuyển giao

• Sự cố được điều tra và xác định nguyên nhân

• Sự cố được chuyển cấp trong trường hợp cấp dưới không

Mục tiêu: Mục tiêu của bước này là Service Desk hoặc các bộ

phận chuyên môn thuộc tuyến trên thực hiện khắc phục sự cố bằng các giải pháp tình thế và giải pháp thay đổi Sự cố sau khi được xử lý sẽ được chuyển trạng thái thành “Đã xử lý” Người được phân công xử lý sự cố có trách nhiệm thông báo cho người dùng kết quả xử lý qua email/điện thoại Người dùng có trách nhiệm kiểm tra kết quả xử lý có đạt yêu cầu hay không Trong trường hợp không đạt yêu cầu người dùng cần gửi feedback cho Service Desk để thực hiện lại các thủ tục điều tra và chuẩn đoán

Cơ sở đầu vào

• Thông báo kết quả xử lý cho user

• Kiểm tra kết quả xử lý

• Kết quả xử lý đạt thì chuyển sang bước 5

• Nếu chưa đạt thì gửi feedback về Service Desk

Kết quả chuyển giao

• Sự cố được xử lý bằng giải pháp tình thế hoặc thay đổi

• Yêu cầu thay đổi được khởi tạo

5 Xem xét và

đóng lại

Mục tiêu: Tùy theo sự cố được giao cho tuyến nào xử lý mà

Service Desk Manager hoặc Service Manager sẽ chịu trách nhiệm xem xét toàn bộ tiến trình trước khi đóng Trong trường hợp giải pháp xử lý sự cố cần được đưa vào CSDL tri thức phục vụ cho nhu cầu tra cứu sau này thì Service Desk Manager hoặc Service Manager sẽ bổ sung giải pháp vào CSDL tri thức Với các sự cố nghiêm trọng thì Incident Manager sẽ làm các công việc này

Cơ sở đầu vào

Kết quả chuyển giao

• Sự cố được điều tra và xác định nguyên nhân

• Sự cố được chuyển cấp trong trường hợp cấp dưới không

xử lý được

• Sự cố xác định là một vấn đề

• Hồ sơ vấn đề được mở ra và thông báo cho Problem Manager