Sự Xuất Sắc Là Một Thói Quen: Bài Học Từ NASA Cho DevOps và Phần Mềm

“Chúng ta là những gì chúng ta liên tục làm. Sự xuất sắc, do đó, không phải là một hành động, mà là một thói quen.” -- Nhà sử học Will Durant, tóm lược một phần triết lý của Aristotle.

Khi tôi viết những dòng này, phi hành đoàn của Artemis II đã quay trở lại Trái Đất an toàn và thành công, trở thành những con người đầu tiên tiếp cận vùng lân cận Mặt Trăng sau hơn 50 năm. Đây cũng là kỷ niệm 56 năm ngày ra mắt của Apollo 13, một nhiệm vụ không chỉ nổi tiếng vì những sự cố thảm khốc trên đường đến Mặt Trăng mà còn vì những nỗ lực phi thường để đưa các phi hành gia trở về nhà an toàn.

Artemis II hạ cánh, ngày 11 tháng 4 năm 2026 (NASA)

NASA và Quy trình Lặp lại

Chuyến đi của NASA đến Mặt Trăng trong thập niên 60 và đầu 70 là câu chuyện về một hành trình dài được xây dựng từng bước một. Tàu vũ trụ một người lái Mercury đơn giản đã mở đường cho tàu Gemini hai người, vốn là bước đệm cho tàu vũ trụ Apollo và tàu hạ cánh Mặt Trăng.

Giữa tháng 5 năm 1961 và tháng 4 năm 1970, NASA đã thực hiện 25 nhiệm vụ có người lái, với tần suất trung bình khoảng 4-5 tháng giữa các nhiệm vụ, đạt đỉnh vào năm 1965-66 với chỉ 1-2 tháng khoảng cách. Các phi hành gia, kỹ sư và quản lý của NASA là một phần của một cỗ máy vận hành trơn tru, không chỉ đạt được mục tiêu của Tổng thống Kennedy là đưa con người lên Mặt Trăng và trở về an toàn đúng hạn, mà còn thực hiện thành công thêm năm lần nữa.

Cỗ máy này đã được kiểm tra dưới áp lực trong thực tế và do đó có thể cứu được nhiệm vụ định mệnh Apollo 13, biến một thảm họa tiềm tàng thành một câu chuyện hào hùng về sự chiến thắng.

Áp dụng vào Phát triển Phần mềm và DevOps

Nhiều khái niệm hiện đại về phát triển phần mềm và khả năng phục hồi (resilience) đều được xây dựng dựa trên ý tưởng rằng: bạn càng thực hành một quy trình, bạn càng thành thạo với nó. Đó là lý do tại sao các tuyến đường chuyển giao liên tục (continuous delivery pipelines) trong DevOps tự động hóa các nhiệm vụ triển khai có thể lặp lại, giúp việc đưa tính năng mới đến khách hàng trở thành một công việc kinh doanh như bình thường thay vì một trải nghiệm đầy hồi hộp và bất ngờ.

Đây cũng là lý do Cơ sở hạ tầng dưới dạng mã (Infrastructure-as-code) trở thành một khái niệm thuyết phục, vì nó cho phép cả sự lặp lại và tính linh hoạt.

Ngay cả khi mọi thứ diễn ra hoàn hảo, chúng ta cũng biết rằng cần phải thực hành xử lý sự cố thông qua Kỹ thuật hỗn loạn (Chaos Engineering), các bài tập phục hồi sau thảm họa (Disaster Recovery), và các ngày diễn tập (Game Days) cho các sự cố nghiêm trọng. Một cơ bắp không được tập luyện sẽ bị teo đi và không thể xử lý tình huống khẩn cấp khi đến lúc cần thiết. Các khách hàng mà tôi từng làm việc với hầu như luôn phát hiện ra một số thứ bị sai lệch trong bài kiểm tra DR (thường là DNS, nhưng cũng có thể là chuỗi kết nối hard-coded, thông tin xác thực bị thiếu, hoặc bộ nhớ chia sẻ không thực sự chia sẻ như mọi người nghĩ) – trừ khi bài kiểm tra được thực hiện thường xuyên đủ để các vấn đề được khắc phục nhanh hơn tốc độ xuất hiện của vấn đề mới.

Bài học từ Artemis II cho Khả năng Quan sát và Độ tin cậy

Mỗi chuyến bay của NASA, kể cả những chuyến thành công nhất, đều gặp nhiều vấn đề rắc rối. Một số chỉ là những bất thường "nhỏ", trong khi những cái khác là các vấn đề thực tế cần giải quyết ngay lập tức.

Việc NASA có thể tái tạo phần lớn các chương trình Mercury-Gemini-Apollo chỉ với hai chuyến bay Artemis là minh chứng cho việc học hỏi tổ chức, mô phỏng và cơ sở hạ tầng thử nghiệm được duy trì trong nửa thế kỷ qua.

Mặc dù nhiệm vụ Artemis II thành công rực rỡ, nhưng có hai vấn đề nhỏ nổi bật đối với tôi như những bài học trực tiếp cho độ bền và độ tin cậy của phần mềm truyền thống.

Trong giờ cuối cùng của quá trình đếm ngược, các kỹ sư đã điều tra một cảm biến trên bộ điều khiển pin động cơ kiểm soát thái độ của hệ thống hủy bỏ phóng cho thấy nhiệt độ cao hơn mong đợi. Nó được xác định là vấn đề về đo lường (nhiệt độ pin thực sự ổn định, chỉ có phép đo sai) và không ảnh hưởng đến việc phóng. Đây là bài học rằng chúng ta cần đo lường (instrument) càng nhiều càng tốt, nhưng vẫn phải hiểu ngữ cảnh của từng thông báo, tham chiếu chéo với các tín hiệu khác để hiểu đâu là rơm và đâu là kim trong núi thông tin mà chúng ta nhận được từ các hệ thống quan sát (observability systems).

Vấn đề thứ hai, tất nhiên, là sự cố của nhà vệ sinh không gian (vì một lý do nào đó, vấn đề vệ sinh và vệ sinh luôn thu hút sự chú ý của công chúng trong các câu chuyện chuyến bay không gian). Ở đây, bài học là đảm bảo loại bỏ các điểm lỗi đơn (single-points-of-failure) trong hệ thống của chúng ta và sẵn sàng các giải pháp khác nếu việc sửa chữa hệ thống chính thất bại. Trong trường hợp của Artemis II, các phi hành gia cùng với các kỹ sư mặt đất đã thực hiện khắc phục sự cố, lập kế hoạch và sửa chữa nhà vệ sinh. Điều này có nghĩa là các phi hành gia có thể sử dụng giải pháp hiện đại thay vì giải pháp dự phòng... kém thơm tho hơn.

Artemis 2 trong quá trình thử nghiệm trước chuyến bay (NASA)

Tương tự ở Trái Đất, khi chúng ta gặp sự cố hệ thống, chúng ta có thể kích hoạt một giải pháp dự phòng tạm thời, điều này có nghĩa là khách hàng của chúng ta sẽ có trải nghiệm bị suy giảm một cách êm đẹp (có thể chậm hơn một chút, có thể một số tính năng cụ thể không khả dụng), nhưng nhìn chung vẫn có thể tiếp tục sử dụng các hệ thống mà chúng ta cung cấp. "Suy giảm" không có nghĩa là "hỏng" – nó có nghĩa là chúng ta đã giành được một phần thành công từ một thất bại.

Kết luận

Và giống như NASA, chúng ta càng lặp lại và thực hành việc giải quyết vấn đề, chúng ta sẽ càng giải quyết nhanh hơn các vấn đề thực tế khi chúng chắc chắn xuất hiện.

“Chúng ta là những gì chúng ta liên tục làm. Sự xuất sắc, do đó, không phải là một hành động, mà là một thói quen.”

Để kết lại, hãy giống như NASA trên đường trở lại Mặt Trăng. Câu chuyện về Apollo, Artemis và mọi hệ thống thành công ở giữa không phải là câu chuyện về sự hoàn hảo, mà là sự chuẩn bị liên tục. Tiến bộ không xảy ra thông qua việc thực hiện hoàn hảo, mà thông qua sự lặp lại, mô phỏng và sự khiêm tốn để biết rằng điều gì đó sẽ sai. Cho dù bạn đang bay con người quanh Mặt Trăng hay vận hành phần mềm cho hàng triệu người dùng (hoặc bất kỳ số lượng nào), bài học vẫn giống nhau: sự bền bỉ được xây dựng từ lâu trước khi nó được cần đến.

Sự xuất sắc không phải là điều chúng ta làm khi mọi thứ hoạt động. Đó là điều còn lại khi mọi thứ không hoạt động, bởi vì chúng ta đã thực hành chính xác cho khoảnh khắc đó.