Margaret Hamilton thiết kế phần mềm Apollo để vẫn an toàn khi gặp lỗi, chứ không phải để không bao giờ có lỗi

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

Khoảng bảy phút trước khi Apollo 11 chạm xuống Mặt Trăng, máy tính của module hạ cánh bắt đầu hiện các cảnh báo chương trình.

Câu hỏi kỹ thuật quan trọng không phải là: máy tính có thể tránh mọi tình trạng quá tải hay không?

Mà là: khi quá tải xảy ra, phần mềm có nhận ra được, bỏ bớt việc ít quan trọng, giữ phần thiết yếu và phục hồi đủ nhanh để sứ mệnh tiếp tục hay không?

Điểm khác biệt đó nằm ở trung tâm câu chuyện của Margaret Hamilton tại MIT Instrumentation Laboratory.

Phần mềm trở nên sống còn với sứ mệnh trước khi nghề này thực sự trưởng thành

Khi NASA trao cho MIT hợp đồng Apollo đầu tiên vào năm 1961, phần mềm vẫn chưa được xem như một ngành kỹ thuật hoàn chỉnh theo cách chúng ta hiểu ngày nay. Apollo Guidance Computer có bộ nhớ và năng lực xử lý cực nhỏ nếu so với máy tính hiện đại, nhưng phần mềm của nó phải xử lý việc xác định vị trí, dẫn đường, hiển thị, tương tác với phi hành gia và những chuỗi thao tác sống còn theo thời gian thực.

Hamilton sau đó lãnh đạo Software Engineering Division của Instrumentation Laboratory. Nhóm của bà làm phần mềm điều khiển bay trên cả module chỉ huy và module Mặt Trăng. Bức ảnh nổi tiếng chụp Hamilton đứng cạnh những chồng code in cao gần bằng người tạo ấn tượng mạnh vì nó biến thứ vốn vô hình thành vật thể: phần mềm không phải phần phụ của Apollo. Nó là một phần trong hệ thống vận hành con tàu.

Thách thức không chỉ là viết các lệnh đúng. Phần mềm còn phải hoạt động hợp lý khi dữ liệu đến sai thời điểm, khối lượng công việc tăng đột biến, con người thao tác nhầm hoặc phần cứng phản ứng ngoài dự kiến.

Cảnh báo của Apollo 11 là bài kiểm tra khả năng phục hồi, không phải sự hoàn hảo

Trong quá trình hạ cánh ngày 20/7/1969, máy tính dẫn đường phát ra các cảnh báo 1201 và 1202. Báo cáo sứ mệnh của NASA cho thấy các ngắt phát sinh từ giao tiếp với radar phục vụ việc gặp tàu trên quỹ đạo (rendezvous radar) chiếm dụng thời gian xử lý, khiến một số công việc chưa kịp hoàn tất trước chu kỳ kế tiếp và làm quá tải bộ điều hành (executive).

Máy tính không đơn giản là treo. Phần mềm điều hành có thể restart rồi tiếp tục những chương trình có độ ưu tiên cao, đồng thời bỏ những công việc không thiết yếu đối với việc hạ cánh. Cơ chế này đã được thiết kế và test trước sứ mệnh.

Câu chuyện đại chúng đôi khi bị rút gọn thành “Hamilton viết đoạn code cứu Apollo 11”. Thành tựu kỹ thuật thực tế rộng hơn và mang tính tập thể. Hamilton lãnh đạo một tổ chức phát triển phần mềm lớn; nhiều kỹ sư cùng thiết kế, triển khai, test và hỗ trợ hệ thống. Sứ mệnh thành công vì kiến trúc phần mềm và đội ngũ vận hành đã được chuẩn bị cho những điều kiện bất thường.

Đóng góp của Hamilton vì thế nên được hiểu không phải như một bản vá duy nhất mang tính anh hùng, mà như vai trò lãnh đạo trong một hệ thống nơi độ tin cậy bao gồm khả năng phục hồi có kiểm soát.

Hệ thống đáng tin cậy phải giả định rằng rồi sẽ có thứ gì đó sai

Một hệ thống mong manh có thể chạy rất đẹp nếu mọi giả định đều đúng. Một hệ thống có khả năng chống chịu bắt đầu từ giả định ngược lại: rồi sẽ có ít nhất một giả định không còn đúng.

Hamilton về sau nhấn mạnh các khái niệm như phần mềm bất đồng bộ, lập lịch theo độ ưu tiên, hiển thị theo độ ưu tiên, end-to-end testing và khả năng ra quyết định có con người tham gia (human-in-the-loop). NASA ghi nhận những ý tưởng này như các thành phần nền tảng quan trọng của thiết kế phần mềm có độ tin cậy cực cao ngày nay.

Triết lý đó hiện lên rõ trong sự kiện Apollo 11. Máy tính biết phân biệt việc khẩn cấp với việc ít quan trọng hơn. Nó có thể restart. Nó giữ lại các task thiết yếu. Trung tâm điều khiển sứ mệnh có thể hiểu cảnh báo vì cách hệ thống phản ứng đã được test và nắm rõ từ trước.

Không tính năng nào khiến sự cố trở thành bất khả thi. Chúng giúp hệ thống vượt qua sự cố.

Bài học sâu hơn nằm ở kiến trúc

Các team thường nói về độ tin cậy như một bài toán đếm bug: loại bỏ đủ nhiều bug thì hệ thống sẽ an toàn. Apollo cho thấy một thực tế khó hơn. Một số sự cố đến từ những tổ hợp bất ngờ của các thành phần vốn riêng lẻ vẫn hoạt động đúng, thời điểm bất thường, tài nguyên bị quá tải hoặc quy trình tương tác không tốt với phần mềm.

Vì vậy độ tin cậy phải được tính đến ngay khi thiết kế kiến trúc và cách vận hành, không thể chờ đến cuối rồi thêm thật nhiều testing.

Một hệ thống tốt cần hỏi trước: việc nào thực sự quan trọng? Việc nào có thể bỏ? State nào phải được giữ lại qua restart? Người vận hành cần nhìn thấy gì? Khi vượt quá năng lực xử lý thì chuyện gì xảy ra? Team dựa vào đâu để biết việc phục hồi là an toàn?

Ngày nay những câu hỏi đó xuất hiện trong hệ thống phân tán, hạ tầng cloud, hàng không, thiết bị y tế, an ninh mạng và gần như mọi service phải tiếp tục hoạt động dưới áp lực.

Vì sao câu chuyện của Hamilton vẫn đáng nhớ

Năm 2016, Hamilton nhận Presidential Medal of Freedom vì đóng góp cho kỹ thuật phần mềm và chương trình Apollo. Đến thời điểm đó, phần mềm đã trở thành hạ tầng của gần như mọi ngành hiện đại.

Câu chuyện của bà hữu ích chính vì Apollo đã thật sự gặp cảnh báo. Một hệ thống chưa bao giờ chịu áp lực cho chúng ta rất ít thông tin về khả năng chống chịu của nó.

Bài test tốt hơn bắt đầu sau khi cảnh báo xuất hiện.

Hệ thống có nhận ra điều gì quan trọng, bỏ điều ít quan trọng, khôi phục một trạng thái đã biết, giao tiếp rõ với con người và tiếp tục an toàn hay không?

Phần mềm hoàn hảo là một khát vọng.

Phần mềm có thể phục hồi là một chiến lược kỹ thuật.

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