VietTechiesHIỂU CÔNG NGHỆ. MỞ GÓC NHÌN.
☰ Chuyên mục

Joe Armstrong xây Erlang quanh một quy tắc lạ lùng: Cứ để nó crash. Con số “chín con số chín” nổi tiếng của nó cần một chú thích.

09/10/2026 · VietTechies · Biên tập

Joe Armstrong mỉm cười, đội mũ lưỡi trai tại một hội nghị, bên cạnh bảng đèn có sơ đồ supervision tree với một process bị crash và tên ông.


Lời khuyên về xử lý lỗi trong lập trình thường gói gọn trong một chữ: phòng ngừa. Kiểm tra input, canh chừng con trỏ, bọc lời gọi hàm lại. Lời khuyên của Joe Armstrong, viết trong luận án tiến sĩ năm 2003, nghe lại như ngược hẳn: “Nếu bạn không làm được điều mình muốn, hãy chết đi. Cứ để nó crash. Đừng lập trình phòng thủ.”

Ông không nói về code viết cho vui. Ông nói về cách Ericsson xây tổng đài điện thoại, những cỗ máy phải chạy liên tục suốt nhiều năm. Cụm “let it crash” trở thành khẩu hiệu nổi tiếng nhất của Erlang, và cũng là một trong những khẩu hiệu bị hiểu sai nhiều nhất. Con số nổi tiếng đi kèm với nó cũng vậy: độ tin cậy “chín con số chín”.

Một cỗ máy không bao giờ được phép dừng

Armstrong gia nhập Phòng thí nghiệm Khoa học Máy tính của Ericsson tại Stockholm năm 1985. Sếp của ông, Bjarne Däcker, giao cho ông một nhiệm vụ mà sau này Armstrong trích lại trong bài viết về lịch sử ngôn ngữ này: “giải quyết bài toán phần mềm của Ericsson”. Mục tiêu của phòng lab, như ông mô tả, là “tạo ra một cách lập trình tốt hơn cho các ứng dụng viễn thông”.

Viễn thông là một bài toán khó. Theo Armstrong, một tổng đài phải xử lý “hàng chục hoặc hàng trăm nghìn giao dịch đồng thời”. Phần mềm của nó phải được thay đổi ngay khi đang chạy, “mà không làm gián đoạn dịch vụ”. Và có một nguyên tắc đến thẳng từ các tổng đài AXE của Ericsson: lỗi của một process “chỉ nên ảnh hưởng đến giao dịch trực tiếp liên quan”. Một cuộc gọi hỏng không được phép kéo theo mọi cuộc gọi khác sập cùng.

Khi Armstrong và đồng nghiệp Robert Virding hỏi các nhà nghiên cứu tại các hội nghị rằng nếu một node của họ crash thì chuyện gì xảy ra, câu trả lời chẳng mấy khích lệ. Armstrong nhớ lại, họ thường đáp: “hệ thống sẽ không chạy” hoặc “mô hình của chúng tôi giả định là không có lỗi”.

Từ mô hình Smalltalk chậm chạp đến một ngôn ngữ mới

Ban đầu Armstrong mô hình hóa viễn thông bằng Smalltalk, nhưng “Smalltalk rất chậm”. Khi ông đưa ký hiệu của mình cho một đồng nghiệp, Roger Skagervall, câu trả lời rất ngắn: “đó là một chương trình Prolog.” Theo lời Armstrong, Erlang bắt đầu như việc “thêm tính đồng thời vào Prolog”, chạy dưới dạng một interpreter viết bằng chính Prolog. Việc phát triển bắt đầu năm 1986.

Nó nhanh chóng không còn là dự án của một người. Virding viết bản triển khai thứ hai. Mike Williams tìm ra những người dùng nội bộ đầu tiên vào năm 1987 và sau đó viết C emulator cho máy ảo của Erlang. Williams cũng đóng góp ý tưởng về process link, mà Armstrong cho là lấy từ “cơ chế ngắt kết nối trong các máy điện thoại analog cũ”. Chi tiết này rất đáng chú ý: lõi của cơ chế xử lý lỗi trong Erlang được mượn từ chính loại phần cứng mà nó sinh ra để thay thế.

“Let it crash” thực sự có nghĩa là gì

Đọc riêng lẻ, “let it crash” nghe như giấy phép để lờ lỗi đi. Luận án nói điều cụ thể hơn. Danh sách đầy đủ các khẩu hiệu của nó mở đầu bằng “Để một process khác lo việc khôi phục lỗi.” Armstrong giải thích mô hình này là hai máy tính canh chừng nhau: “Chúng ta dùng đúng phương pháp đó trong Erlang, chỉ khác là thay vì máy tính, ta dùng từng cặp process.”

Trên thực tế, một worker process làm việc, còn một supervisor process riêng thì theo dõi nó. Các process của Erlang không dùng chung bộ nhớ, nên một worker bị crash không thể làm hỏng những process bên cạnh. Khi nó chết, link báo tin cho supervisor, và supervisor khởi động lại nó. Supervisor thậm chí có thể nằm trên một máy khác, vì như Armstrong nói, “bạn không thể xây một hệ thống chịu lỗi nếu chỉ có một máy tính.”

Luận án cũng vạch ra một ranh giới mà đa số bản tóm tắt bỏ qua. Nếu lập trình viên “biết phải làm gì để sửa điều kiện gây ra exception, thì đó không phải là lỗi”. Một file bị thiếu có thể được bắt và xử lý ngay tại chỗ. Crash được dành cho những trường hợp “lập trình viên không biết phải làm gì”, những trạng thái bất ngờ mà code phòng thủ thường chỉ đoán mò rồi làm mọi thứ tệ hơn. Armstrong cũng thẳng thắn về giới hạn: ông viết rằng sự cô lập giữa các process “không hoàn hảo”, và một process vẫn có thể thực hiện thứ chẳng khác gì một cuộc tấn công từ chối dịch vụ nhằm vào process khác.

AXD301 và “chín con số chín”

Ý tưởng này gặp phép thử lớn sau khi dự án AXE-N của Ericsson sụp đổ vào tháng 12/1995, một sự kiện Armstrong gọi là “sự kiện quan trọng nhất trong lịch sử Erlang”. Erlang được chọn cho tổng đài ATM mới AXD301, do hơn 60 lập trình viên Erlang xây dựng và tổ chức quanh các “supervision tree” của OTP. Một thống kê vào cuối năm 2001 đếm được khoảng 1,1 triệu dòng code Erlang.

AXD301 chính là nơi huyền thoại bắt đầu. Armstrong viết rằng nó “đạt độ tin cậy CHÍN con số chín”, tương đương khoảng 31 mili giây downtime mỗi năm. Con số này từ đó được lặp đi lặp lại như thể là thuộc tính của chính Erlang.

Các nguồn tư liệu kể một câu chuyện hẹp hơn. Chính luận án của Armstrong thừa nhận bằng chứng dài hạn duy nhất là “một bài thuyết trình PowerPoint” trong đó một khách hàng lớn báo cáo hệ thống 11 node đạt 99,9999999%, “dù các con số này được thu thập thế nào thì không được ghi lại”. Mats Cronqvist, kiến trúc sư hệ thống của AXD301, sau này giải thích rằng British Telecom “tuyên bố độ khả dụng dịch vụ chín con số chín, tính gộp trên khoảng 5 node-năm”. Ông cũng chỉ ra rằng có “nhiều C hơn Erlang rất nhiều trong hệ thống”, và Armstrong “không thuộc nhóm AXD 301”. Ông gọi tuyên bố này là “khá thiếu căn cứ”, nhưng bổ sung rằng so với các hệ thống tương tự, tổng đài này “đáng tin cậy đến kinh ngạc”. Ulf Wiger, người dẫn dắt thiết kế AXD301, xác nhận con số là một điểm dữ liệu có thật từ khách hàng và nói các triển khai khác “luôn tốt hơn 99,999%”.

Vì vậy, phiên bản có tài liệu thì bớt kỳ diệu hơn nhưng vẫn ấn tượng: độ khả dụng mà một khách hàng báo cáo cho một mạng, chứ không phải một quy luật đã được đo đạc của ngôn ngữ.

Bị cấm, rồi được giải phóng

Thành công không bảo vệ được Erlang bên trong Ericsson. Tháng 2/1998, Ericsson Radio Systems cấm dùng nó cho sản phẩm mới. Một văn bản chính sách nội bộ nêu lý do: một “ngôn ngữ độc quyền” đồng nghĩa với việc phải tiếp tục tốn công duy trì phần hỗ trợ và công cụ cho nó. Däcker sau này nhận xét về sự trớ trêu rằng chính sự “cằn nhằn về chuyện ‘độc quyền'” đã mở đường để phát hành Erlang dưới dạng mã nguồn mở, điều Ericsson làm vào tháng 12/1998. Armstrong và phần lớn nhóm cốt lõi sau đó rời đi lập startup Bluetail. Nhận định của ông về lệnh cấm: Ericsson “đã làm điều đúng (dùng đúng công nghệ cho đúng việc) vì những lý do sai”.

Mã nguồn mở đã cho Erlang một cuộc đời thứ hai. Năm 2012, các kỹ sư WhatsApp viết trên blog rằng Erlang là một phần then chốt trong hạ tầng của họ và cho thấy một server duy nhất giữ hơn 2 triệu kết nối TCP. Armstrong qua đời vào tháng 4/2019; cộng đồng Erlang tưởng nhớ ông như người cha của ngôn ngữ này.

Ý tưởng sống lâu hơn chiếc tổng đài

Ngày nay ít đội nào xây tổng đài điện thoại, nhưng nhiều đội xây những hệ thống tự khởi động lại service bị lỗi, cô lập workload và chấp nhận rằng ở đâu đó luôn có thứ gì đang hỏng. Đóng góp của Armstrong là biến giả định ấy thành điểm xuất phát thay vì chuyện tính sau.

Câu hỏi hữu ích mà công trình của ông để lại không phải là “làm sao để chỗ này không bị lỗi?” Mà là: khi bộ phận này hỏng, ai sẽ biết, và ai sẽ đưa nó trở lại?

Đọc bằng ngôn ngữ khác: English · Español · Deutsch · Français · Português (Brasil) · Tiếng Việt

Nguồn