RBS Đã Khóa Tài Khoản Của 6,5 Triệu Khách Hàng Chỉ Vì Một Bản Cập Nhật Batch. Vấn Đề Không Phải Là Thay Đổi Đó — Mà Là Không Ai Biết Nó Ảnh Hưởng Đến Đâu.

Sự Cố Đó Không Phải Vì Mã Nguồn Cũ

Ngày 19 tháng 6 năm 2012, ai đó tại RBS đã áp dụng một bản cập nhật vốn được cho là thường lệ lên CA-7 — phần mềm lập lịch batch điều khiển việc xử lý các job qua đêm cho RBS, NatWest và Ulster Bank. Bản cập nhật đó đã thất bại. Một nhân viên vận hành còn khá thiếu kinh nghiệm, trong lúc rollback bản nâng cấp, đã vô tình xóa mất các file lưu lịch chạy batch của đêm hôm đó, khiến các job qua đêm không chạy — hoặc chạy sai. Kết quả: 6,5 triệu khách hàng bị khóa khỏi tài khoản của mình trong bốn ngày, lương và các khoản thanh toán không được ghi nhận, và cuối cùng RBS bị phạt 56 triệu bảng Anh sau khi FCA (Cơ quan Quản lý Hành vi Tài chính Anh) hoàn tất điều tra.

Các báo cáo hậu kiểm sau đó chỉ ra nguyên nhân là việc kiểm thử không đầy đủ và tài liệu hóa kém xung quanh quy trình cập nhật — chứ không phải bản thân COBOL, cũng không phải vì các batch job đã quá cũ. Hệ thống đó đã chạy đúng lịch trình này trong nhiều năm mà không gặp sự cố. Thứ thực sự thất bại là khả năng biết trước, trước khi thay đổi được triển khai, chính xác bản cập nhật scheduler đó sẽ ảnh hưởng đến những gì.

Cuộc Di Trú Năm 2018 Của TSB Kể Lại Câu Chuyện Tương Tự Ở Quy Mô Lớn Hơn

Thảm họa di trú hệ thống IT của TSB sáu năm sau đó cũng đi theo một mô típ tương tự, ở quy mô lớn hơn và trong khoảng thời gian dài hơn. Một cuộc điều tra độc lập của Slaughter and May phát hiện rằng nhà thầu IT Sabis đã khuyến nghị chỉ kiểm thử một trong hai trung tâm dữ liệu mới để tránh gián đoạn dịch vụ ATM cho khách hàng TSB. Hơn nữa, việc kiểm thử trong môi trường thực tế chỉ diễn ra sau khi toàn bộ dữ liệu khách hàng đã được di trú xong. Hai trung tâm dữ liệu, vốn được thiết kế để cấu hình giống hệt nhau, hóa ra lại không nhất quán theo những cách chỉ lộ ra khi có lưu lượng truy cập thực tế đổ vào. Trong khoảng 2.000 lỗi mà quá trình kiểm thử thực sự phát hiện được, chỉ có 800 lỗi được báo cáo lên hội đồng quản trị trước khi hệ thống chính thức vận hành. Cái giá phải trả: tổng chi phí 366 triệu bảng Anh, 80.000 khách hàng rời bỏ ngân hàng, và thêm khoản phạt 48 triệu bảng từ PRA và FCA — cùng với một khoản phạt cá nhân dành cho cựu CIO của ngân hàng vì đã không giám sát cuộc di trú đúng mức.

Cả hai sự cố đều không phải là câu chuyện về mã nguồn mà không ai còn đọc được nữa. Cả hai đều là câu chuyện về một thay đổi — một cấu hình scheduler, một lần chuyển đổi trung tâm dữ liệu — được triển khai ra thực tế mà không ai có được câu trả lời đáng tin cậy và đầy đủ cho câu hỏi “điều này thực sự ảnh hưởng đến những gì?”

Phân Tích Tác Động Vẫn Là Phần Chưa Được Giải Quyết Của Hiện Đại Hóa

Khoảng cách đó vẫn chưa được thu hẹp theo thời gian. Phân tích của Celent trên 127 dự án chuyển đổi hệ thống ngân hàng lõi được thực hiện từ năm 2015 đến 2025 cho thấy tỷ lệ thất bại tổng thể là 37%. Một nghiên cứu riêng của Gartner cũng chỉ ra rằng khoảng một nửa số dự án chuyển đổi hệ thống ngân hàng lõi không đạt được mục tiêu ban đầu hoặc bị bỏ dở hoàn toàn vì độ phức tạp. Sự phân hóa theo cách tiếp cận cũng rất đáng chú ý: các đợt chuyển đổi kiểu “thay thế toàn bộ một lần” (rip-and-replace) thất bại khoảng 58% số lần, trong khi các cuộc di trú theo từng giai đoạn thành công khoảng 71% số lần. Di trú theo giai đoạn hoạt động tốt hơn phần lớn vì nó buộc các đội ngũ phải hiểu và xác thực từng phần phụ thuộc một, thay vì đặt cược toàn bộ hệ thống vào một đêm chuyển đổi duy nhất.

Đó cũng chính là bài học mà RBS và TSB đã phải trả giá đắt để học được: rủi ro trong các hệ thống legacy không tập trung ở việc mã nguồn đã cũ. Nó tập trung ở việc không ai có một bản đồ đáng tin cậy và luôn cập nhật về việc cái gì phụ thuộc vào cái gì, trước khi ai đó thay đổi nó.

Vì Sao Đồ Thị AST Là Công Cụ Phân Tích Tác Động, Không Chỉ Là Công Cụ Hỗ Trợ Đọc Mã

Đây chính là vấn đề mà đồ thị AST tương tác của Legacy Dragon thực sự được xây dựng để giải quyết, vượt xa tốc độ thuần túy của việc phân tích một chương trình COBOL 1.200 dòng trong khoảng 6 mili giây. Một đồ thị ánh xạ luồng điều khiển và các phụ thuộc dữ liệu một cách có cấu trúc — chương trình nào gọi đoạn (paragraph) nào, job nào đọc file nào, trường dữ liệu nào trong copybook nuôi phép tính nào ở phía sau — chính là thứ bạn muốn có sẵn trong tay trước khi đụng vào một scheduler batch hay chuyển đổi một cuộc di trú dữ liệu, chứ không phải thứ mà một đội ngũ rà soát phải dựng lại thủ công sau khi sự cố đã xảy ra. Vì đồ thị này được sinh ra một cách tất định (deterministic) trực tiếp từ chính mã nguồn, thay vì từ tài liệu vốn đã lỗi thời ngay khi vừa được viết ra, việc tái tạo lại đồ thị sau mỗi lần thay đổi giúp bức tranh về phạm vi ảnh hưởng luôn được cập nhật thay vì trở nên cũ kỹ.

Không có gì ở đây khẳng định rằng chỉ riêng một đồ thị phụ thuộc có thể ngăn chặn hoàn toàn sự cố hỏng scheduler của RBS hay sự không nhất quán giữa các trung tâm dữ liệu của TSB — cả hai sự cố đó đều có nguyên nhân từ tổ chức và quy trình, chứ không chỉ từ kỹ thuật. Điều mà một bản đồ phụ thuộc có cấu trúc và luôn cập nhật thực sự thay đổi là liệu câu hỏi “điều này còn ảnh hưởng đến những gì khác” có phải là điều một đội ngũ thực sự có thể trả lời được trước khi thay đổi được triển khai hay không, thay vì để các nhà điều tra mất nhiều tháng trời để trả lời câu hỏi đó sau khi mọi chuyện đã xảy ra.

---

Đang muốn trả lời câu hỏi “điều này thực sự ảnh hưởng đến những gì” trước khi triển khai thay đổi legacy tiếp theo? Xem cách đồ thị AST của Legacy Dragon hoạt động tại dragon.aitytech.com, đọc thêm về thời hạn cấp bách khác: chuyển giao tri thức từ đội ngũ COBOL sắp nghỉ hưu, hoặc liên hệ với chúng tôi tại [email protected].