Vận hành hệ thống công nghệ thông tin ngân hàng trong thời đại AI

Trong ngân hàng, đích đến của vận hành CNTT không còn là “ít sự cố hơn” theo nghĩa kỹ thuật thuần túy. Đích đến thực sự là duy trì được các dịch vụ trọng yếu khi khối lượng giao dịch tăng, cửa sổ bảo trì thu hẹp, phụ thuộc nhà cung cấp mở rộng và rủi ro an ninh mạng ngày càng cao. Trí tuệ nhân tạo (Artificial Intelligence – AI) có thể giúp đội ngũ vận hành làm việc nhanh hơn, thấy nhiều hơn và học nhanh hơn; nhưng AI không thể thay thế trách nhiệm điều hành, kỷ luật quy trình hay năng lực kiến trúc của một tổ chức.

1. Bối cảnh mới của vận hành CNTT ngân hàng

Nếu trước đây vận hành CNTT ngân hàng chủ yếu được xem là bài toán giữ hệ thống chạy ổn định, thì hiện nay trọng tâm đã dịch chuyển sang việc giữ cho dịch vụ kinh doanh trọng yếu tiếp tục hoạt động ngay cả khi môi trường kỹ thuật biến động. Đây là khác biệt rất lớn. Một ngân hàng có thể vẫn đạt tỷ lệ sẵn sàng hệ thống tương đối cao trên báo cáo tổng hợp, nhưng nếu khách hàng không đăng nhập được, giao dịch chuyển tiền bị treo, đối soát cuối ngày bị chậm hoặc kênh số liên tục suy giảm hiệu năng, thì tổ chức đó vẫn thất bại ở góc độ vận hành dịch vụ.

Ba áp lực mới đang làm thay đổi bản chất công việc của bộ phận vận hành. Thứ nhất là kỳ vọng phục vụ gần như liên tục 24/7. Khi khách hàng đã quen với giao dịch mọi lúc, vận hành không còn nhiều không gian cho cách bảo trì kiểu “đóng hệ thống vào ban đêm”. Thứ hai là độ phức hợp của kiến trúc. Các hệ thống lõi, kênh số, lớp tích hợp, hệ thống chống gian lận, kho dữ liệu, cổng kết nối đối tác và dịch vụ của nhà cung cấp bên ngoài ngày càng liên kết chặt. Thứ ba là yêu cầu quản trị rủi ro và bằng chứng kiểm soát ở cấp điều hành ngày càng cao: không chỉ biết hệ thống có chạy hay không, mà còn phải biết dịch vụ nào trọng yếu, rủi ro nằm ở đâu, phụ thuộc vào ai, và nếu có gián đoạn thì khôi phục bằng cách nào.

Điểm đáng chú ý nữa là AI đã đi vào cả hai phía: phía sản phẩm và phía vận hành. Một mặt, chính các dịch vụ ngân hàng ngày càng dùng AI để chấm điểm, phát hiện bất thường, cá nhân hóa hay hỗ trợ khách hàng. Mặt khác, AI cũng được đưa vào công cụ giám sát, điều tra và tự động hóa của bộ phận vận hành. Điều này làm xuất hiện thêm một lớp đối tượng phải quản trị: mô hình, dữ liệu, đường ống xử lý dữ liệu (pipeline – chuỗi bước xử lý tự động), cấu hình bảo vệ và chi phí suy luận. Nói cách khác, vận hành CNTT ngày nay không chỉ quản lý máy chủ và ứng dụng; nó còn phải quản lý năng lực quyết định của máy.

Bảng 1. Những chuyển dịch đang làm bài toán vận hành CNTT ngân hàng khó hơn

2. Vì sao bộ phận vận hành vẫn quá tải dù ngân hàng đã hiện đại hóa mạnh

2.1. Kiến trúc phức hợp làm tăng phạm vi ảnh hưởng của sự cố

Ở nhiều ngân hàng, “hệ thống CNTT” thực ra là một quần thể gồm core banking, thẻ, treasury, cổng thanh toán, ứng dụng kênh số, định danh và truy cập, kho dữ liệu, hệ thống chống gian lận, công cụ bảo mật, nền tảng tích hợp và hàng loạt dịch vụ phụ trợ khác. Vấn đề không nằm ở việc số lượng hệ thống nhiều, mà nằm ở chỗ ranh giới trách nhiệm và ranh giới kỹ thuật giữa chúng thường không rõ. Có nơi đã tăng số lượng dịch vụ nhưng chưa thực sự tăng năng lực cô lập lỗi; kết quả là “nhiều mảnh hơn nhưng chưa hề đơn giản hơn”.

Khi một hành trình nghiệp vụ như đăng nhập, chuyển khoản, xác thực, ghi sổ, chống gian lận và gửi thông báo phải đi qua nhiều lớp kỹ thuật, chỉ cần một mắt xích bất ổn là toàn bộ chuỗi có thể dừng lại. Trong vận hành hiện đại, người ta gọi đó là blast radius – phạm vi ảnh hưởng lan rộng của sự cố. Blast radius càng lớn thì mỗi sự cố càng tốn nhiều đầu mối phối hợp, thời gian điều tra càng dài và khả năng ra quyết định đúng trong vài phút đầu càng thấp.

2.2. Mô hình tổ chức và điều hành đi sau tốc độ thay đổi của hệ thống

Không ít tổ chức vẫn vận hành theo mô hình chia nhỏ trách nhiệm theo hạ tầng, mạng, cơ sở dữ liệu, an ninh, ứng dụng, tích hợp, trong khi dịch vụ kinh doanh lại chạy xuyên qua tất cả các lát cắt đó. Hệ quả là khi sự cố xảy ra, rất đông người tham gia nhưng không ai là người chịu trách nhiệm cuối cùng cho toàn bộ dịch vụ. Thiếu service owner (chủ sở hữu dịch vụ) khiến quyết định bị chậm ở đúng thời điểm cần nhanh nhất.

Nhiều quy trình quản lý dịch vụ CNTT (Information Technology Service Management – ITSM) vẫn tồn tại theo kiểu thủ tục nhiều hơn năng lực thực thi. Sự cố được ghi nhận nhưng quản lý vấn đề (Problem Management – xử lý nguyên nhân gốc và phòng ngừa tái diễn) chưa thực chất; quản lý thay đổi (Change Management – kiểm soát việc sửa đổi hệ thống) nặng phê duyệt hơn là đánh giá rủi ro; cơ sở dữ liệu cấu hình (Configuration Management Database – CMDB) có nhưng không phản ánh đúng hiện trạng. Kết quả là tổ chức duy trì được nhiều biểu mẫu nhưng không rút ngắn được thời gian khôi phục.

2.3. Dữ liệu vận hành rời rạc, chưa đạt mức observability thực thụ

Giám sát truyền thống chủ yếu trả lời câu hỏi “ngưỡng nào đang vượt ngưỡng”, trong khi observability lại phải trả lời sâu hơn: điều gì vừa thay đổi, thay đổi ở đâu, lan tới đâu và đang làm hỏng hành trình kinh doanh nào. Muốn làm được điều đó, tổ chức cần liên kết được metrics (các chỉ số đo), logs (nhật ký), traces (vết theo dõi luồng xử lý), sự kiện cấu hình và bản đồ phụ thuộc của hệ thống.

Nếu mỗi miền kỹ thuật dùng một công cụ riêng, đặt tên khác nhau, lệch múi giờ hoặc không có correlation ID (mã liên kết để theo dấu một giao dịch qua nhiều hệ thống), mọi điều tra nguyên nhân gốc đều sẽ chậm một cách tất yếu. Đây cũng là lý do nhiều sáng kiến AIOps thất bại: AI không thể tạo ra tri thức tốt từ tín hiệu lộn xộn. Dữ liệu bẩn thì mô hình càng mạnh cũng chỉ tạo ra khuyến nghị kém tin cậy.

2.4. Tự động hóa thấp, công việc lặp lại quá nhiều

Một phần lớn thời gian của đội vận hành đang bị tiêu hao bởi những việc lặp đi lặp lại: kiểm tra log, khởi động lại dịch vụ, đối chiếu batch, gia hạn chứng thư, cấu hình quyền truy cập, vá lỗi định kỳ, tổng hợp báo cáo, soạn thông báo và phối hợp thủ công giữa nhiều nhóm. Trong thuật ngữ SRE, đó là toil – công việc thủ công, lặp lại, ít tạo giá trị dài hạn nhưng vẫn chiếm nhiều thời gian và năng lượng của người giỏi.

Khi toil cao, tổ chức có hai tổn thất cùng lúc. Tổn thất thứ nhất là năng suất: nhân sự giỏi bị khóa vào các việc giá trị thấp và không còn thời gian xử lý nợ kỹ thuật. Tổn thất thứ hai là độ tin cậy: thao tác thủ công vừa chậm vừa dễ sai, đặc biệt trong giai đoạn căng thẳng khi xử lý sự cố lớn. Nếu không cắt giảm toil, mọi sáng kiến chuyển đổi vận hành đều có nguy cơ sa lầy.

2.5. Khả năng phục hồi và năng lực con người chưa được xây như một tài sản chiến lược

Nhiều ngân hàng vẫn lẫn lộn giữa việc “có sao lưu” và việc “phục hồi được”. Bản sao dữ liệu chỉ có ý nghĩa khi được khôi phục thành công trong một bài kiểm thử có đo thời gian, có tiêu chí đạt và có xác nhận dữ liệu thực sự sử dụng được. Tương tự, kế hoạch dự phòng thảm họa (Disaster Recovery – phục hồi sau thảm họa) đẹp trên giấy nhưng chưa từng diễn tập đầu-cuối thì chưa thể coi là khả năng chống chịu.

Ở chiều con người, tăng quân số mà không tái cấu trúc kỹ năng thường chỉ tạo thêm người trong cùng một sự hỗn loạn. Hệ thống hiện đại đòi hỏi hiểu biết về điện toán đám mây, container, tự động hóa, observability, an ninh, dữ liệu và AI. Nếu kỹ năng mới chưa được xây, tổ chức sẽ rơi vào phụ thuộc chuyên gia; chỉ cần thiếu vài cá nhân chủ chốt hoặc chậm phản hồi từ nhà cung cấp là toàn bộ tiến trình xử lý sự cố bị kéo dài.

3. Ứng dụng AI trong vận hành CNTT ngân hàng: nên dùng ở đâu và dùng đến mức nào

AI chỉ phát huy giá trị trong vận hành khi được sử dụng đúng chỗ. Nguyên tắc nên rất rõ: để máy làm phần đọc nhiều, sàng lọc nhiều, so sánh nhiều và nhắc việc nhiều; còn quyền ra quyết định trên dịch vụ trọng yếu vẫn thuộc về con người được ủy quyền. Cách tiếp cận này tránh hai thái cực đều nguy hiểm: một là quá dè dặt khiến AI không tạo ra giá trị; hai là giao quá nhiều quyền cho AI khi dữ liệu, quy trình và kiểm soát còn yếu.

Trong bài toán vận hành ngân hàng, AI hữu ích nhất không phải ở chỗ “tự sửa hệ thống” ngay lập tức, mà ở chỗ rút ngắn các khâu vốn làm con người tốn thời gian nhất: đọc biển cảnh báo, hiểu bối cảnh, tìm tri thức liên quan, hình thành giả thuyết nguyên nhân gốc, dự báo rủi ro thay đổi và chuẩn bị thông tin để người có trách nhiệm quyết định nhanh hơn. Nói cách khác, AI là bộ khuếch đại năng lực phân tích và phối hợp của đội vận hành.

Bảng 2. Những nhóm ứng dụng AI có giá trị thực tế cao trong vận hành ngân hàng

3.1. AI nên bắt đầu từ những điểm đau rõ ràng nhất

Thực tế triển khai cho thấy ba điểm đau dễ tạo hiệu quả sớm là: nhiễu cảnh báo, chậm điều tra và tri thức vận hành phân tán. Nếu AI giúp giảm 30–50% lượng cảnh báo trùng lặp, tóm tắt nhanh sự cố lớn trong vài phút đầu và tìm đúng runbook thay vì để kỹ sư lục lại tài liệu thủ công, tổ chức đã có thể giải phóng đáng kể thời gian và giảm áp lực tâm lý cho ca trực. Đây là những bài toán đủ cụ thể để đo hiệu quả, đồng thời ít rủi ro hơn so với việc trao quyền tự động can thiệp.

3.2. GenAI đặc biệt hữu ích ở lớp tri thức và phối hợp

GenAI có thế mạnh khi phải đọc nhiều tài liệu khác nhau và trả lời bằng ngôn ngữ gần gũi với người dùng. Trong vận hành ngân hàng, công dụng của GenAI nổi bật ở việc chuyển cơ sở tri thức tĩnh thành một trợ lý tra cứu linh hoạt: hỏi cách cô lập sự cố, tìm thay đổi gần nhất, gợi ý danh sách kiểm tra trước khi phát hành, soạn thông báo gửi đơn vị kinh doanh, tổng hợp đầu việc sau post-mortem (đánh giá sau sự cố) hoặc tạo bản nháp biên bản diễn tập phục hồi. Tuy nhiên, vì GenAI có thể sinh ra nội dung nghe hợp lý nhưng sai – thường được gọi là hallucination, tức “ảo giác” của mô hình – nên các câu trả lời phải luôn gắn với tài liệu nguồn và mức độ tin cậy.

3.3. Không nên vội dùng AI để tự động thay đổi hệ thống trọng yếu

Tự động hóa có sử dụng AI trong việc sửa lỗi hay thay đổi cấu hình là bước tiến hấp dẫn nhưng cũng là vùng rủi ro cao nhất. Với dịch vụ trọng yếu của ngân hàng, không nên để AI tự ý tắt dịch vụ, chỉnh thông số nghiệp vụ, chuyển hướng giao dịch hoặc sửa dữ liệu mà không có cơ chế human-in-the-loop (con người tham gia phê duyệt trong vòng xử lý), nhật ký kiểm soát và khả năng dừng khẩn cấp. AI có thể gợi ý, thậm chí chuẩn bị lệnh; nhưng người chịu trách nhiệm vận hành mới là người quyết định có chạy hay không.

3.4. Điều kiện tiên quyết để AI không phản tác dụng

Bốn điều kiện tiên quyết cần được làm trước hoặc làm song song với AI. Một là dữ liệu vận hành phải đủ sạch và đủ liên kết. Hai là trách nhiệm dịch vụ phải rõ để khuyến nghị AI có người sở hữu và đánh giá. Ba là runbook, quy trình thay đổi, phân loại mức độ nghiêm trọng và phân quyền truy cập phải được chuẩn hóa. Bốn là phải có cơ chế đo chất lượng AI: khuyến nghị nào được chấp nhận, khuyến nghị nào bị bác bỏ, tỷ lệ cảnh báo giả là bao nhiêu, mô hình có trôi lệch hay không và chi phí suy luận có tương xứng với giá trị mang lại hay không.

4. Mô hình vận hành đích cho giai đoạn 2026–2028

Muốn giải quyết tận gốc, ngân hàng không thể chỉ bổ sung thêm công cụ hoặc tuyển thêm người. Cần tái thiết mô hình vận hành theo hướng điều hành theo dịch vụ trọng yếu thay vì điều hành theo sơ đồ phòng ban. Nói ngắn gọn: dịch vụ phải có chủ, thay đổi phải có kỷ luật, dữ liệu vận hành phải nhìn được toàn cảnh, phục hồi phải được kiểm chứng, và AI phải bị đặt trong một khung kiểm soát rõ ràng.

4.1. Tổ chức lại quanh dịch vụ trọng yếu

Mỗi dịch vụ trọng yếu – chẳng hạn đăng nhập số, chuyển tiền, thanh toán thẻ, treasury, giải ngân, đối soát liên ngân hàng – cần có service owner chịu trách nhiệm đầu-cuối về mục tiêu dịch vụ, mức độ sẵn sàng, runbook, giám sát, diễn tập phục hồi, phối hợp nhà cung cấp và truyền thông trong sự cố. Khi trách nhiệm được neo vào dịch vụ, việc ra quyết định trong những phút đầu của sự cố sẽ nhanh và rõ hơn rất nhiều.

Song song, cần thiết lập mô hình chỉ huy sự cố lớn theo kiểu incident command (mô hình chỉ huy sự cố): có người chỉ huy, đầu mối kỹ thuật chính, đầu mối ứng dụng, đầu mối hạ tầng/an ninh, đầu mối truyền thông và đầu mối phối hợp nghiệp vụ. Cách tổ chức này giúp loại bỏ tình trạng họp đông nhưng không ai cầm trịch. Với các ngân hàng có độ phức tạp cao, nên xây năng lực trung tâm cho SRE, observability và platform engineering ở vai trò “enablement” – tức đội dẫn dắt chuẩn chung và nền tảng chung, không làm thay mọi việc của các đội ứng dụng.

4.2. Kỷ luật vận hành theo ITIL 4 kết hợp SRE

ITIL 4 cung cấp khung quản trị dịch vụ CNTT chặt chẽ, còn SRE cung cấp kỷ luật kỹ thuật để cân bằng tốc độ thay đổi với độ tin cậy. Khi kết hợp hai hướng tiếp cận này, ngân hàng có thể tránh được cả hai cực đoan: một bên là quy trình quá nặng giấy tờ, bên kia là thay đổi quá nhanh nhưng thiếu kiểm soát. Tối thiểu, bảy năng lực phải được làm thật chắc: Service Desk, Incident Management, Major Incident Management, Problem Management, Change Enablement, Configuration Management và Knowledge Management.

Đặc biệt, các dịch vụ trọng yếu cần được đo bằng SLI/SLO và error budget (ngân sách lỗi – mức sai lệch có thể chấp nhận trong một khoảng thời gian). Khi error budget còn dư, tổ chức có thể triển khai thay đổi nhanh hơn có kiểm soát; khi error budget bị đốt nhanh, ưu tiên phải chuyển sang ổn định hóa, xử lý nguyên nhân gốc và giảm nhịp thay đổi. Đây là cách biến “độ ổn định” từ khẩu hiệu thành cơ chế điều hành cụ thể.

4.3. Xây observability hợp nhất và nhìn theo hành trình kinh doanh

Trục kỹ thuật cốt lõi phải là khả năng liên kết được metrics, logs, traces, sự kiện thay đổi và bản đồ phụ thuộc dịch vụ trên một nền quan sát chung hoặc ít nhất là một lớp dữ liệu chung. Thay vì chỉ dựng dashboard cho từng máy chủ hay từng công cụ, ngân hàng cần nhìn được toàn bộ hành trình như đăng nhập, thêm người thụ hưởng, chuyển tiền, xác thực, tra soát, đối soát cuối ngày. Khi một hành trình có vấn đề, đội vận hành phải đi được từ triệu chứng ở cấp khách hàng xuống nguyên nhân ở cấp dịch vụ, phiên bản phát hành, truy vấn cơ sở dữ liệu hoặc cấu hình hạ tầng trong vài phút đầu tiên.

Đây chính là nền móng để AI làm việc có ích. Không có quan sát hợp nhất, AI chỉ đọc được các mảnh tín hiệu rời rạc. Có quan sát hợp nhất, AI mới có thể xâu chuỗi thay đổi gần nhất, sự kiện bất thường, mối phụ thuộc chéo và dữ liệu lịch sử để hỗ trợ con người điều tra chính xác hơn.

4.4. Đẩy mạnh tự động hóa và platform engineering

Ngân hàng cần đẩy nhanh tự động hóa ở những khâu có tần suất cao và rủi ro thao tác lớn: cấp phát môi trường, quản lý hạ tầng bằng mã lệnh (Infrastructure as Code – hạ tầng được mô tả và kiểm soát bằng mã), quản lý cấu hình bằng mã, gia hạn chứng thư, vá lỗi định kỳ, kiểm tra lệch cấu hình, triển khai phiên bản, rollback, xử lý ticket cấp 1 và tổng hợp báo cáo. Mỗi giờ toil được cắt giảm là mỗi giờ trả lại cho xử lý nợ kỹ thuật và cải tiến lâu dài.

Platform engineering giúp tổ chức tạo ra golden path – đường chuẩn đã được chuẩn hóa cho triển khai, logging, tracing, secret management (quản lý bí mật như mật khẩu, khóa), bảo mật, rollback và kiểm soát tuân thủ. Khi các đội đi trên cùng những đường chuẩn này, chất lượng vận hành sẽ đồng đều hơn, việc điều tra cũng nhanh hơn vì mọi dịch vụ chia sẻ một số quy ước chung.

4.5. Quản trị an ninh, nhà cung cấp và AI như một chỉnh thể

Độ tin cậy, an ninh và rủi ro bên thứ ba không thể tiếp tục được quản riêng rẽ. Với ngân hàng, một dịch vụ có thể “ổn định” theo nghĩa kỹ thuật nhưng vẫn không an toàn nếu phụ thuộc quá sâu vào một nhà cung cấp, không có quyền quan sát, không có phương án thoát phụ thuộc hoặc không kiểm soát được chuỗi cung ứng phần mềm. Do đó, vận hành hiện đại phải gắn với đánh giá mức độ trọng yếu của nhà cung cấp, quyền truy cập log, quyền kiểm thử, cam kết khôi phục và chiến lược thay thế khi cần.

Riêng với AI, cần thêm một lớp governance (quản trị) rõ ràng: dữ liệu nào được phép truy cập, loại quyết định nào AI chỉ được gợi ý chứ không được tự thi hành, ai chịu trách nhiệm rà soát, cách lưu vết và cách đánh giá sai lệch của mô hình. Trong môi trường ngân hàng, nguyên tắc thực dụng nhất là: AI hỗ trợ năng suất và phân tích; trách nhiệm cuối cùng vẫn thuộc về con người được ủy quyền.

5. Lộ trình triển khai khuyến nghị

Không nên triển khai chuyển đổi vận hành theo kiểu “làm tất cả cùng lúc”. Cách hiệu quả hơn là chia thành các giai đoạn có đầu ra rõ, có nhóm dịch vụ ưu tiên rõ và có sức chứa phù hợp với tổ chức. Lộ trình dưới đây ưu tiên làm chắc nền trước, rồi mới mở rộng AI và tự động hóa sâu.

Bảng 3. Lộ trình triển khai ba giai đoạn

6. Bộ chỉ số điều hành cốt lõi

Bộ chỉ số vận hành phải ngắn, sắc và dùng được để ra quyết định. Sai lầm phổ biến là đo quá nhiều nhưng không ai thật sự dùng. Ở cấp điều hành, ngân hàng nên theo dõi một bộ chỉ số lõi đủ để nhìn ra độ tin cậy dịch vụ, tốc độ phục hồi, chất lượng thay đổi, mức độ tự động hóa, năng lực chống chịu và hiệu quả thực tế của AI.

Bảng 4. Bộ chỉ số vận hành nên theo dõi ở cấp điều hành

7. Kết luận

Bộ phận vận hành CNTT ngân hàng bị quá tải không phải vì hệ thống hiện đại là điều xấu, mà vì cách điều hành chưa hiện đại tương xứng với chính hệ thống đó. Khi ngân hàng bước vào giai đoạn dịch vụ số gần như liên tục, kiến trúc phân tán, dữ liệu thời gian thực, phụ thuộc nhà cung cấp sâu hơn và AI hiện diện ở nhiều lớp, mô hình vận hành cũ chắc chắn bộc lộ giới hạn. Tăng người mà không tăng độ trưởng thành vận hành chỉ là kéo dài thời gian trước khi vấn đề quay lại.

Muốn đi xa, ngân hàng cần quay về một sự thật rất cơ bản nhưng bền vững: vận hành tốt được xây bằng kỷ luật. Kỷ luật trong kiến trúc để giảm phụ thuộc không cần thiết; kỷ luật trong quy trình để sự cố được kiểm soát và đúc rút bài học đúng cách; kỷ luật trong dữ liệu để observability và AI có nền làm việc; kỷ luật trong kiểm thử để phục hồi được chứng minh bằng diễn tập; và kỷ luật trong quản trị để lãnh đạo nhìn vận hành như một năng lực chiến lược thay vì một bộ phận hậu cần.

AI sẽ là lực đẩy đáng kể cho vận hành ngân hàng trong vài năm tới, nhưng chỉ với những tổ chức biết đặt AI đúng vị trí. AI không thay thế service owner, không thay thế hội đồng thay đổi, không thay thế bài test phục hồi và càng không thay thế trách nhiệm của người lãnh đạo. Giá trị thật của AI nằm ở chỗ giúp con người thấy nhanh hơn, hiểu sâu hơn, phối hợp gọn hơn và để dành nhiều thời gian hơn cho những quyết định quan trọng. Nếu triển khai nghiêm túc theo hướng đó, ngân hàng có thể chuyển dần từ mô hình “đội vận hành ôm tất cả” sang mô hình “dịch vụ có chủ, thay đổi có kiểm soát, sự cố có chỉ huy, phục hồi có bằng chứng và AI có kỷ luật”.

Phụ lục. Một số thuật ngữ tiếng Anh dùng trong bài

Bảng dưới đây chỉ nhằm tiện tra cứu nhanh. Trong nội dung chính, các thuật ngữ tiếng Anh đã được giải thích ngay ở lần xuất hiện đầu tiên.

Bảng 5. Thuật ngữ Anh – Việt

Tài liệu tham khảo gợi ý

1. Basel Committee on Banking Supervision. Principles for operational resilience.

2. Basel Committee on Banking Supervision. Principles for the sound management of third-party risk.

3. Digital Operational Resilience Act (DORA) và các tài liệu hướng dẫn liên quan của châu Âu.

4. ITIL 4 Foundation và các thực hành chính về quản lý dịch vụ CNTT.

5. NIST Cybersecurity Framework 2.0.

6. NIST AI Risk Management Framework (AI RMF 1.0).

7. NIST SP 800-218: Secure Software Development Framework (SSDF).

8. Các tài liệu cộng đồng và nhà cung cấp về SRE, OpenTelemetry, observability và platform engineering.