Ra đời hơn 50 năm nay, các dòng code già cỗi này vẫn đang gánh vác tiền của bạn mỗi ngày

Bắt đầu nghỉ hưu từ năm 2007 ở tuổi 60 sau vài thập kỷ làm lập trình viên cho một ngân hàng lớn ở Canada, nhưng ông Thomas không vì thế mà được ngơi tay. Gần như một thói quen, mỗi khi tiếng chuông điện thoại nhà ông vang lên là có ai đó từ ngân hàng gọi đến nhờ ông, hoặc cập nhật phần mềm, hoặc bổ sung các tính năng mới.

Đơn giản là vì hiện tại không còn nhân viên nào hiểu được ngôn ngữ lập trình COBOL (Common Business-Oriented Language) – một ngôn ngữ lập trình đã hàng chục năm tuổi đang vận hành hầu như mọi hoạt động của ngân hàng này – như ông Thomas nữa. Hầu như không mấy coder trẻ hứng thú với nó, họ thích tìm đến những công nghệ đời mới hơn, như trí tuệ nhân tạo hay blockchain.

Xuất hiện lần đầu vào năm 1969, khi những cỗ máy tính vẫn đang to bằng cả căn phòng, còn các dòng code vẫn chạy trên các tấm thẻ đục lỗ, ngôn ngữ lập trình COBOL trở thành cốt lõi cho các phần mềm vận hành hoạt động ngân hàng. Cho đến tận bây giờ, nhiều thập kỷ đã trôi qua, khi Thomas và các đồng nghiệp đã về hưu, những dòng code mà ông và đồng nghiệp viết nên vẫn đang hoạt động và tạo ra hàng triệu bản ghi mỗi ngày.

Ngân hàng của ông Thomas không phải trường hợp duy nhất. Theo báo cáo của Reuters năm 2017, hơn 80% giao dịch thẻ tín dụng của người dùng được thực hiện bằng COBOL. Gần 95% số lần quẹt thẻ là nhờ COBOL xử lý đằng sau hậu trường. Các hệ thống dùng COBOL xử lý khoảng 3.000 tỷ USD trong giao dịch thương mại mỗi ngày.

Năm 2012, ngân hàng New York Mellon cho biết họ có 112.500 phần mềm dùng COBOL, với tổng cộng 350 triệu dòng code – con số này phổ biến trong hầu hết các tổ chức tài chính lớn khác. Hiện COBOL đang là nền tảng cho 43% hệ thống ngân hàng. Theo ước tính vào năm 2020, có khoảng 240 tỷ dòng code COBOL đang âm thầm vận hành những phần quan trọng nhất trong cuộc sống hàng ngày của bạn.

Tại sao khi công nghệ đang tiến bước vũ bão mỗi ngày, một ngôn ngữ lập trình 50 năm tuổi vẫn quan trọng với cuộc sống chúng ta đến vậy?

Cuối năm 50, máy tính mới chỉ ở giai đoạn thử nghiệm và các doanh nghiệp vẫn còn ngần ngại sử dụng chúng. Việc viết code rất khó hiểu và rối rắm. Các lập trình viên thường viết phần mềm bằng ngôn ngữ máy “asembly”, trong khi các câu lệnh lại trừu tượng một cách khủng khiếp. Ví dụ: câu lệnh “LXA A,K” nghĩa là “lấy số được tải vào vị trí trong bộ nhớ máy tính và tải nó vào thanh ghi chỉ mục K“.

Hơn nữa, các nhà sản xuất máy tính thường tự nghĩ ra ngôn ngữ đặc biệt cho sản phẩm của họ. Nghĩa là nếu bạn có một phần mềm chạy tốt trên máy tính này, nó lại không chạy được trên máy tính của công ty khác.

Nhưng rồi một thế hệ các lập trình viên mới với tham vọng lớn hơn quyết tâm thay đổi điều đó. Khởi đầu là Grace Hopper, một Thiếu tướng Hải quân Mỹ, phát minh ra ngôn ngữ “FLOW-MATIC” với các câu lệnh bằng tiếng Anh để dễ học và dễ đọc hơn. Ví dụ, nếu muốn chuyển một số từ vị trí A sang D, chỉ cần viết “TRANSFER A TO D”.

Tiếp đó, năm 1959, Mary Hawes, một lập trình viên khác muốn tạo ra một ngôn ngữ dễ viết như FLOW-MATIC và có thể chạy trên bất kỳ máy tính nào. Bà tập hợp một nhóm các chuyên gia, bao gồm cả những người đến từ các công ty máy tính và cả Bộ Quốc phòng để tạo ra một ngôn ngữ lập trình, giúp mọi quản lý tầm trung của các công ty đều có thể đọc và hiểu được, ngay cả khi họ không được đào tạo về lập trình.

Sau một thập kỷ nghiên cứu, COBOL ra đời. Cũng giống như FLOW-MATIC, nó rất dễ đọc và dễ hiểu với người biết tiếng Anh. Để cộng hai số với nhau, bạn có thể viết “ADD Num1, Num2 GIVING Result”. Để thực hiện một phép tính 3 lần, bạn chỉ cần viết “PERFORM 3 TIMES”.

Chính vì vậy, việc đào tạo lập trình viên cũng trở nên dễ dàng hơn. Các công ty có thể đào tạo và huấn luyện một nhân viên thành lập trình viên COBOL trong vòng vài tháng và trở thành chuyên gia trong 1-2 năm. Điều này đặc biệt cần thiết cho các công ty khi đang rất thiếu lập trình viên trong thời điểm đó.

Một ưu điểm quan trọng của COBOL là tốc độ nhanh, đặc biệt khi xử lý khối lượng lớn các giao dịch. Điều đó khiến nó đặc biệt phù hợp với các doanh nghiệp lớn, các chuỗi cửa hàng bán lẻ, các ngân hàng, tổ chức tài chính. Mỗi ngày họ phải liên tục xử lý các giao dịch nhập xuất hàng hay nộp rút tiền, và cuối ngày là thống kê hàng tồn, bảng cân đối kế toán, … tất cả chỉ trong vài giờ đồng hồ.

COBOL được thiết kế chính xác cho công việc này: xử lý hàng tỷ tỷ tỷ giao dịch trong thời gian ngắn. Hơn thế nữa, nó còn được tối ưu cho các máy tính mainframe, những máy tính được thiết kế đặc biệt cho việc xử lý hàng tỷ tỷ giao dịch, với việc đọc và viết dữ liệu chỉ trong chớp mắt.

Qua nhiều năm, bộ biên dịch COBOL – phần mềm biến các cú pháp tiếng Anh thành mã máy tính dạng 0 và 1 để máy tính hiểu – ngày càng được tinh chỉnh nhiều hơn nữa, để cuối cùng mang lại tốc độ xuất chúng cho nó. Xuất hiện ngay từ buổi bình minh của phần mềm và máy tính, nhưng COBOL có được chính xác những gì người ta cần: Tốc độ và khả năng xử lý. Đây là một phần nguyên nhân tại sao COBOL làm nên các hệ thống quan trọng nhất trong cuộc sống hàng ngày của chúng ta.

Khi đã trở thành một phần không thể thiếu trong cuộc sống của chúng ta trong hàng chục năm nay, COBOL lại có thêm một ưu điểm không ngờ tới so với các công nghệ mới: sự ổn định và chính xác. Là một công nghệ cũ kỹ hóa ra lại là lợi thế vì nó đã được sửa hết lỗi.

Khi một chương trình được viết lần đầu, các sai sót là điều không thể tránh khỏi. Đôi khi là một lỗi chính tả, một câu lệnh viết nhầm, hoặc một tình huống mà lập trình viên không ngờ tới trong khi sử dụng làm hỏng chương trình. Các vấn đề này thường phải mất nhiều ngày, nhiều tuần, hoặc nhiều năm mới có thể phát hiện ra.

Nhưng với các chương trình COBOL vẫn đang vận hành cả thế giới hiện nay? Các lập trình viên và người dùng đã có nhiều thập kỷ để phát hiện các vấn đề này và sửa nó. Các lỗi cú pháp, thậm chí tên người dùng làm hỏng chương trình, đều được phát hiện và sửa lại từ hàng chục năm nay, khiến các hệ thống dùng COBOL trở nên đặc biệt đáng tin cậy.

Quan trọng hơn, nếu một ứng dụng kiểu TikTok gặp lỗi – ví dụ số lượt like clip hiển thị sai – chẳng sao cả, thế giới vẫn vui vẻ. Nhưng nếu lượng hàng tồn kho bị tính sai, một ngân hàng đột nhiên không gửi được tiền, hệ thống trợ cấp xã hội không gửi tiền cho người về hưu nữa, … “Thế giới sẽ kết thúc.” Ông Philip Teplitzky, cựu giám đốc công nghệ của Citibank cho biết.

Ông Thomas nhớ lại, một trong các tiến trình mà ông từng phát triển bằng COBOL, hàng tháng sẽ chuyển chính xác tiền lương hưu của chính phủ vào tài khoản ngân hàng của 2,4 triệu người. “Chúng tôi xác minh chúng và kiểm tra sau mỗi 11 phút. Nó không bị hỏng trong 20 năm nay.”

Cái tên COBOL lại một lần nữa được người ta nhắc đến vào năm 2020 khi đại dịch Covid-19 bùng phát trên toàn cầu. Hàng loạt doanh nghiệp phá sản và lượng người thất nghiệp gia tăng đột biến đã nhấn chìm hệ thống chi trả phúc lợi và website của cơ quan chính phủ. Do hầu hết hệ thống này vẫn đang vận hành trên COBOL, thống đốc bang New Jersey đã phải kêu gọi những người biết về ngôn ngữ này giúp giải quyết các điểm nghẽn trong hệ thống để đáp ứng được nhu cầu xử lý tăng vọt.

Nhưng hóa ra vấn đề lại không nằm ở COBOL. Vấn đề là do các ứng dụng web nằm đằng sau các trang web của chính phủ. Chúng được viết một cách cẩu thả bằng Java và không đáp ứng nổi nhu cầu truy cập của người dùng. Còn các máy tính mainframe chạy trên “ông già” COBOL vẫn lao vun vút như những chiếc Ferrari.

Cho dù vậy, ổn định và cũ kỹ, lại tạo nên một nghịch lý – một lời nguyền của thành công. Khi các dòng code chạy ổn định đến mức mọi người không cần phải kiểm tra nó nữa, không giám sát nó nữa và cuối cùng không quan tâm, không hiểu nó hoạt động như thế nào – một cách chính xác nữa. Dần dần, COBOL trở thành một quái vật bí hiểm không ai hiểu được nữa. Điều đó gây ra một vấn đề lớn, khi giờ đây nếu ai đó muốn bổ sung một tính năng mới.

Đó là nghịch lý trong thành công của COBOL. Nó nhanh và ổn định, với vô số ngân hàng và chính phủ đang chạy trên nó – cũng vì vậy, không mấy người muốn thay đổi nó, họ cho rằng nó quá nguy hiểm để thử. Cũng vì vậy, thay vì viết lại các đoạn code đã cũ, các lập trình viên làm việc với COBOL đều chỉ bổ sung các đoạn code nhỏ, sửa một vài lỗi.

Nhưng điều đáng sợ hơn cả là khi một hệ thống ổn định lâu năm như vậy gặp lỗi, việc sửa chữa nó sẽ tốn kém khủng khiếp.

Và hóa ra, ngay cả một hệ thống đã chạy ổn định trong nhiều thập kỷ vẫn có thể phát sinh một lỗi không ai ngờ tới. Đó chính là lỗi “Y2K” nổi tiếng – nó kinh khủng đến mức khiến các ngân hàng và các công ty trên toàn thế giới trở nên hoảng loạn và phải lao vào đào bới những dòng code COBOL cũ và sửa chữa nó.

Lỗi Y2K xuất phát từ một quyết định sai lầm trong thiết kế ban đầu. Khi các lập trình viên viết ngày tháng vào phần mềm, thay vì ghi đầy đủ 1971, họ chỉ ghi là “71”. Đó là vì máy tính trong những năm 60-70 có rất ít bộ nhớ lưu trữ. Bớt được 2 ký tự là cả một bước tiến lớn – mỗi byte đều đắt tiền. Hơn nữa, các lập trình viên cũng không mơ về việc phần mềm họ viết vẫn được dùng trong hơn 30 năm sau đó – đến năm 2000.

Đến gần thiên niên kỷ mới, cách ghi năm bằng 2 con số phát sinh vấn đề lớn. Phần mềm COBOL sẽ không thể biết số “00” là năm 2000 hay 1900. Nếu một ngân hàng tính tiền lãi cho khoản tiền gửi được thực hiện vào ngày 01, phần mềm có thể nhầm rằng, khoản tiền này được gửi từ năm 1901 và tặng không cho khách hàng tiền lãi trong 99 năm.

Hàng tỷ giao dịch mỗi ngày của các ngân hàng, bảo hiểm, các tổ chức tài chính dựa vào ngày tháng trên đó, nghĩa là hàng tỷ dòng code phải được viết lại và cập nhật lại. Khi năm 2000 đến gần, các ngân hàng phải gọi trở lại các nhân viên nghỉ hưu, trả thêm tiền để họ mày mò trong codebase, tìm lại mọi ngày tháng trong đó và sửa chữa chúng.

Thời gian quá gấp gáp cùng khối lượng công việc quá lớn khiến một số ngân hàng không đủ thời gian để sửa chữa hoàn toàn. Thay vào đó, họ dùng mẹo để khắc phục vấn đề. Họ chọn một năm nào đó trong tương lai, ví dụ 2045 và biến nó thành điểm mốc. Vì vậy, nếu phần mềm thấy số năm nhỏ hơn 45, nó sẽ cho rằng, đây là những năm 1900 – ví dụ, số 87 sẽ có nghĩa là năm 1987. Còn nếu số đó nhỏ hơn 45, ví dụ 33, nó sẽ giả định đó là những năm 2000 – 2033.

Nghĩa là một ngày nào đó, vấn đề sẽ trở lại và sẽ lại cần các chuyên gia COBOL để sửa lại nó một lần nữa – nếu họ vẫn còn sống đến lúc đó.

Còn tầng lớp kế cận cho họ ư? Khó có hy vọng tìm được những người trẻ tuổi theo đuổi và thành thạo ngôn ngữ cổ điển này. Ngay cả trường Marist, một trong số ít nơi thường xuyên giảng dạy về COBOL cũng từng gọi điện trong tuyệt vọng để tìm kiếm được một chuyên gia có kỹ năng về ngôn ngữ này. Các nhà khoa học máy tính cũng không còn hứng thú với ngôn ngữ già nua này nữa, cho dù nó đang vận hành cho những hệ thống quan trọng nhất thế giới.

Xuất phát điểm của COBOL càng khiến nó trở nên không phù hợp với thời đại. Khi các máy tính PC giá rẻ xuất hiện vào những năm 80, chúng trở thành thiết bị chủ đạo để viết code. Trong khi đó, muốn học về COBOL, người học phải tiếp cận được các máy tính mainframe cỡ lớn – vốn chỉ có trong các ngân hàng hoặc công ty bán lẻ cỡ lớn. Đến khi smartphone xuất hiện, các sinh viên gần như hoàn toàn quên lãng COBOL để theo đuổi các nền tảng mới mẻ hơn, hấp dẫn hơn.

Một số công ty khác, lo ngại về khả năng tìm được các chuyên gia COBOL trong tương lai, đã quyết định sẽ viết lại toàn bộ hệ thống của họ bằng ngôn ngữ mới. Thời báo New York đã khởi đầu một nỗ lực như vậy từ năm 2006 đến 2009 và thất bại hoàn toàn. Phải đến năm 2015, họ mới khởi động lại nỗ lực này và cũng phải mất thêm 2 năm nữa mới hoàn tất việc chuyển đổi từ COBOL sang Java nhờ một phần mềm tái cấu trúc tự động, do đối tác của họ cung cấp.

Nhưng họ vẫn còn may mắn. Ngân hàng Commonwealth Bank of Australia đã cố gắng viết lại hệ thống lõi của họ bằng một ngôn ngữ mới. Dự án được triển khai từ năm 2012 và mất 5 năm mới hoàn thành, tiêu tốn hết 750 triệu USD, cao gấp đôi so với dự kiến ban đầu.

Ngân hàng của Úc đã gặp may trong trường hợp này. Một ngân hàng của Anh, TSB, cũng đã phải từ bỏ COBOL sau khi bị Sabadell mua lại. Quá trình chuyển đổi phần mềm kéo dài trong nhiều ngày khiến ngân hàng không thể hoạt động và thiệt hại đến gần 400 triệu USD. Công ty còn thiệt hại gần 60 triệu USD khác do một vụ lừa đảo xảy ra khi hệ thống mới bị sụp đổ.

Vì vậy, hầu hết các ngân hàng còn lại chỉ nhún vai và bỏ qua điều đó. Nếu nó không hỏng, đừng sửa gì cả. “Các chương trình này đã chạy 24/7 trong suốt 30, 40 năm qua. Tại sao phải thay đổi nó?” Trong khi đó, họ ra sức khuyến khích càng nhiều người học COBOL càng tốt với lời hứa về công việc trọn đời.

Nhưng vấn đề nằm ở chỗ, dù COBOL ổn định cho hoạt động của ngân hàng, kỳ vọng của khách hàng lại không như vậy. Internet và các ứng dụng di động đang khiến ngành công nghiệp tài chính toàn cầu biến đổi nhanh chưa từng thấy.

Các ứng dụng chuyển tiền dạng ví điện tử giúp bạn nhận được tiền trong tích tắc, các dịch vụ như Coinbase còn cho phép người dùng mua bán tiền mã hóa, còn cả các ứng dụng cho vay ngang hàng như Tala hay Upstart.

Đây lại là sân chơi mà các ngân hàng đang gặp nhiều khó khăn. Đến lúc này, “công nghệ thời kỳ đồ đá” của COBOL lại trở thành gánh nặng cho việc xây dựng các tính năng mới. Việc lưu trữ dữ liệu backend thành các phần khác nhau khiến việc mày mò trong đống code cũ trở nên nguy hiểm, khi có thể gây rủi ro cho các hoạt động hiện tại của ngân hàng.

Thế nhưng các startup công nghệ lại có thể làm bất cứ điều gì họ muốn. Không xây dựng trên hệ thống cũ, cũng không cần đến các trung tâm máy chủ khổng lồ, họ chỉ cần thuê một không gian trên hệ thống cloud như của Amazon để chạy được ứng dụng của mình. Họ có thể viết code bằng các ngôn ngữ mới, do vậy có thể tuyển dụng bất kỳ sinh viên ham học hỏi nào.

Dù vậy, vẫn quá sớm để dự báo về cái chết của COBOL trong thời gian tới, hoặc có lẽ nó sẽ không bao giờ chết. Cái chết của COBOL đã được nhiều lập trình viên dự báo hết lần đến lần khác, thậm chí một thành viên trong ủy ban tạo ra COBOL còn đặt sẵn một bia mộ cho nó chỉ một năm sau khi dự án được khởi động vì cho rằng, nó đang tiến triển quá chậm. Hơn 50 năm sau, khi tấm bia mộ này vẫn nằm trong một góc của Bảo tàng Lịch sử Máy tính ở California, COBOL đang điều hành thế giới.

Tham khảo Wealthsimple