Sai lầm trị giá 500 triệu USD của tôi với xe tự hành Sao Hỏa
(chrislewicki.com)- Vào tháng 2/2003, trong phòng sạch của JPL, Spirit Mars Rover chỉ còn 2 tuần nữa là được chuyển đến bãi phóng, và một lỗi kết nối break-out-box có thể đã phá hỏng con tàu vũ trụ trị giá 500 triệu USD
- Spirit và Opportunity là nhiệm vụ xe tự hành Sao Hỏa song sinh mà NASA đã đầu tư gần 1 tỷ USD, với lịch trình gần như không còn dư địa để khắc phục sự cố lớn
- Ngay sau khi xung điện đi vào phía tàu vũ trụ thay vì động cơ, telemetry bị mất, nhưng chưa thể xác định ngay liệu có hư hại hay không và nguyên nhân là gì
- Ngày hôm sau, việc mất telemetry được xác nhận là do tháo dây đo của đồng hồ vạn năng Fluke 87III, còn cú surge thực tế vẫn là đối tượng phân tích của kênh driver động cơ H-Bridge
- Sau nhiều tuần phân tích, dự án kết luận phần cứng được Use As Is, sửa quy trình rồi tiếp tục thực hiện cùng bài kiểm tra; động cơ đó của Spirit đã hoạt động bình thường trên Sao Hỏa
Sự cố thử nghiệm xảy ra với Spirit ngay trước khi phóng
- Tháng 2/2003, trong phòng sạch Building 179 High Bay 1 của NASA JPL, Spirit Mars Rover chỉ còn 2 tuần nữa là được chuyển đến Cape Canaveral
- Spirit và Opportunity là hai nhiệm vụ xe tự hành Sao Hỏa song sinh, những tàu vũ trụ phức tạp mà NASA khi đó đã đầu tư gần 1 tỷ USD
- Ở giai đoạn lắp ráp và thử nghiệm, trước khi đóng kín tàu vũ trụ lần cuối trên Trái Đất, mọi hệ thống phải được kiểm tra kỹ lưỡng và xác nhận hoạt động bình thường
- Hai xe tự hành có tổng cộng 62 động cơ loại brushed
- Dẫn động và bẻ lái bánh xe
- Điều khiển cánh tay robot
- Ngắm camera
- Hướng ăng-ten về phía Trái Đất
- Các thao tác mở ra và triển khai sau khi hạ cánh
- Đối tượng thử nghiệm đêm đó là động cơ RAT-Revolve bên trong Rock Abrasion Tool(RAT) ở đầu cánh tay robot của Spirit
- Động cơ RAT-Revolve có nhiệm vụ quay grinder và brush trên đá Sao Hỏa
Quy trình kiểm tra trạng thái động cơ bằng tín hiệu điện
- Việc tháo rời động cơ để kiểm tra bên trong sau mỗi lần thử nghiệm môi trường là không thực tế
- Thay vào đó, động cơ được tách khỏi tàu vũ trụ và nối với nguồn điện ngoài cùng strip chart recorder để kiểm tra hiệu năng điện
- Một động cơ bình thường sẽ có dòng điện giảm mượt theo dạng hàm mũ trong lúc spin-up; nếu có bất thường, tín hiệu sẽ xuất hiện blip
- Bài kiểm tra dùng break-out-box, và nếu kết nối sai, dòng điện lớn có thể đi nhầm chỗ, gây hư hại nghiêm trọng
- Trong bước kiểm tra trước, giao diện kết nối, thiết lập nguồn điện, thiết lập strip chart và xung thử ngắn đối với động cơ chuẩn đều được xác nhận là bình thường
Xung điện đi sai hướng
- Ngay khi cấp năng lượng cho động cơ RAT-Revolve, strip chart hiển thị một tín hiệu lạ, cũng khác với tín hiệu điển hình của động cơ hỏng
- Lần theo dây dẫn để kiểm tra, nhóm phát hiện do lỗi break-out-box, xung điện đã đi vào phía tàu vũ trụ ở đầu đối diện của giao diện connector, thay vì vào động cơ
- Spirit khi đó chỉ còn 2 tuần nữa là được chuyển đi chuẩn bị phóng, nên nếu xảy ra vấn đề lớn thì sẽ không còn thời gian để khắc phục
- Sự cố được báo ngay cho test conductor Leo, đồng thời nhận được phản hồi rằng telemetry từ tàu vũ trụ đã bị mất
- Nhóm lập tức thực hiện quy trình shutdown khẩn cấp và được yêu cầu rời khỏi phòng sạch để phục vụ điều tra diễn biến sự cố cũng như đánh giá thiệt hại
Mất telemetry và nhận định ban đầu
- Ngay sau sự cố, có hai sự thật được xác nhận
- Một xung điện lớn đã đi vào nơi không được dự định
- Telemetry của tàu vũ trụ bị gián đoạn
- Mối liên hệ giữa hai sự kiện này chưa rõ ràng ngay lập tức
- Nhóm cho rằng nhiều khả năng surge điện đã đi vào mạch driver động cơ H-Bridge
- H-Bridge được xem là mạch điều khiển dòng điện
- Do back-EMF, đây là một trong những phần của rover được thiết kế để chịu thêm năng lượng
- Tàu vũ trụ khi đó đã tắt, và nhóm quyết định kiểm tra xem việc cấp nguồn lại có giải quyết được vấn đề hay không
- Gần nửa đêm, báo cáo sự cố được chuyển lên tới cả quản lý dự án Pete, với khả năng phải lập lại kế hoạch cho một dự án quy mô khoảng 1.000 người
Khởi động lại thất bại và nguyên nhân thực sự được phát hiện hôm sau
- Quy trình cấp nguồn tiêu chuẩn cho tàu vũ trụ được thực hiện lại, nhưng ngay cả sau khi thiết bị điện tử và phần mềm khởi động, telemetry vẫn không trở lại
- Trên rack thiết bị hỗ trợ mặt đất có một đèn báo đỏ bật sáng khi nhận được xung ở mỗi chu kỳ clock, được dùng như nhịp tim robot với tần suất 8 lần mỗi giây
- Bộ nguồn hiển thị các mức điện áp và thay đổi dòng điện quen thuộc, nhưng đèn báo không sáng và telemetry cũng không xuất hiện
- Ngày hôm sau, khi rà soát lại trình tự sự kiện, đồng hồ vạn năng số Fluke 87III trở thành manh mối then chốt
- Hôm trước, trong lúc tìm đồng hồ vạn năng cần cho bài kiểm tra, người viết đã tháo dây đo của một đồng hồ vạn năng gần tàu vũ trụ, vốn trông như đang giám sát điện áp bus
- Thực ra đồng hồ vạn năng này đang hoàn thành mạch nguồn telemetry thử nghiệm mặt đất của tàu vũ trụ
- Ngay khi tháo dây đo, kết nối nguồn telemetry bị ngắt
Spirit vẫn sống, và phần cứng được dùng nguyên trạng
- Nhóm đưa đồng hồ vạn năng trở lại vai trò ban đầu và bật nguồn tàu vũ trụ lại
- Telemetry hoạt động trở lại, xác nhận Spirit chưa chết
- Thiệt hại thực tế chỉ ở mức vài giờ, và thử nghiệm được tiếp tục
- Trong vài tuần sau đó, nhóm phân tích kênh H-Bridge của động cơ RAT-Revolve, với nhiều thảo luận chi tiết về khả năng thin-film demetallization
- Cuối cùng, dự án kết luận phần cứng đó được Use As Is
- Công tác chuẩn bị phóng rover tiếp tục, và sau khi Spirit đến Sao Hỏa, động cơ RAT-Revolve đã hoạt động bình thường
Cách đối diện với trải nghiệm thất bại
- Sự kiện này dẫn đến niềm tin rằng việc chia sẻ trải nghiệm thất bại có thể là bài học cho cả người kể lẫn người nghe
- Tại Planetary Resources, trong quy trình tuyển dụng và văn hóa đội ngũ, ứng viên được yêu cầu chia sẻ failure story của mình
- Trong khủng hoảng, Ernie để lại lời nhắn: “Lần tới khi phải phê duyệt rằng điều gì đó ổn, hãy nhớ cảm giác này”
- Sau sự cố, một số người cho rằng nên dừng bài kiểm tra nguy hiểm này, nhưng vì tầm quan trọng của việc xác nhận động cơ có hoạt động bình thường trên Sao Hỏa hay không, thử nghiệm vẫn được tiếp tục
- Quản lý dự án Pete để chính người đó tiếp tục dẫn dắt bài kiểm tra, với nhận định đại ý rằng “chúng ta đã trả học phí cho anh ấy, và anh ấy là người ít có khả năng lặp lại sai lầm này nhất”
- Sau đó, quy trình được sửa để không lặp lại cùng sai lầm, và cùng bài kiểm tra được thực hiện lại nhiều lần
- Trải nghiệm này trở thành một mốc tham chiếu khiến người viết nhớ lại nỗi sợ và sự hối tiếc khi phải đưa ra phê duyệt hoặc bảo đảm quan trọng
1 bình luận
Ý kiến trên Hacker News
Bài viết thật sự rất hay
Nó làm tôi nhớ lại một chuyện tương tự hồi đầu sự nghiệp kỹ sư phần mềm. Khoảng 10 năm trước, tôi làm tư vấn cho một khách hàng, xây dựng phiên bản mới của dịch vụ web của họ trong vài tháng và phụ trách triển khai vào ngày ra mắt. Khi đó quy trình phát triển và triển khai gần như hoàn toàn thủ công. Tôi đã tự động hóa những phần có thể bằng script và SQL, và ngay khoảnh khắc nhấn Enter để chạy bài kiểm thử cuối cùng trước khi triển khai, tôi nhận ra mình vừa chuyển sang dùng thông tin xác thực production
Khi lỗi dồn lại và dịch vụ không phản hồi, tôi tin chắc mình đã phá hỏng cơ sở dữ liệu, nhưng nhờ vài giờ trước đó có người đã hoàn tất backup để chuẩn bị ra mắt nên phần lớn đã được khôi phục. Từ đó về sau, khi xử lý cơ sở dữ liệu và hệ thống production, nói là cẩn thận thôi vẫn chưa đủ; tôi tự nhủ sẽ không bao giờ để chuyện đó xảy ra nữa
Bộ test trong lúc chạy sẽ xóa rồi tạo lại hoặc làm rỗng các bảng. Một ngày nọ, lead developer sau khi dò lỗi trên DB production đã chạy
make test. Code test cứ dùng nguyên các biến môi trường đó và kết nối vào production thay vì Docker, rồi lập tức xóa và tạo lại các bảng production đó hàng chục lầnMay mắn là mỗi site khách hàng đều có DB cục bộ được đồng bộ với DB trung tâm, nên sản phẩm vẫn chạy được khi mất kết nối; anh ấy đã làm việc căng trong 3–4 ngày, kết hợp backup cũ với dữ liệu của khách hàng để dựng lại DB master
Một giây sau chúng xuất hiện lại; hóa ra chỉ là view được refresh. Đúng là một UI kinh khủng
Tôi viết một truy vấn
UPDATEngắn để đổi câu chữ marketing của sản phẩm, và ngay khi nó không kết thúc tức thì, tôi biết mình tiêu rồi: tôi đã cập nhật toàn bộ mà không có điều kiện, làm thay đổi mô tả của hàng nghìn sản phẩm. DBA có quyền truy cập backup ở múi giờ khác đã tan làm, và sau hơn một giờ gọi điện chúng tôi mới có thể khôi phụcMột thay đổi nhanh trên đường ra về biến thành vài giờ xử lý hậu quả; người bạn bên marketing cứ xin lỗi mãi, nhưng lỗi là của tôi. Tôi cho rằng khách hàng không phàn nàn gì là vì lúc đó là 5 giờ chiều thứ Sáu trước cuối tuần lễ
sudo, trước khi nhấn Enter phải có một người khác kiểm tra lệnh. Có thể áp dụng một chính sách hoặc thông lệ tương tự cho mọi việc làm trên productionTôi nhớ đến câu: nếu một thực tập sinh xóa cơ sở dữ liệu production, thì đó không phải là thực tập sinh tệ mà là quy trình tệ
Việc đây là vấn đề quy trình hay vấn đề con người thì không dễ kết luận, vì người ta kỳ vọng nhiều hơn ở nhân viên chính thức. Nhưng khi đặt mình vào vị trí của anh ấy, tôi xúc động khi đọc thấy nỗi sợ và đau đớn ngay khoảnh khắc anh ấy nhận ra chuyện gì đã xảy ra. Cả cảm giác tia hy vọng vụt tắt rồi sống lại nữa; tôi chưa từng phụ trách một dự án mà nhiều người phụ thuộc đến thế
Theo tôi, tất cả họ đều là anh hùng
Trong cuộc gọi phân tích sau sự cố, câu đầu tiên là: “Chúng ta sẽ không đổ lỗi cho người đã tạo ra các giao dịch đó. Đó là một sai lầm trung thực. Thay vào đó, hãy thảo luận vì sao developer lại có thể gọi API giao dịch production mà không cần xác thực”
Nếu đổ lỗi cho cá nhân, chỉ người đó bị sa thải và cả tổ chức yếu đi. Như vậy chẳng khác nào đuổi đi người duy nhất đã học được một bài học đắt giá. Chỉ nên quy trách nhiệm cá nhân khi có ý định gây hại, và khi đó pháp luật có thể can thiệp
Vài năm sau, đến lúc tôi rời công ty, tôi đã biến site mong manh và bất ổn đó thành một hệ thống có test tự động, nhiều tầng backup, hệ thống failover qua nhiều data center, cùng quy trình đào tạo và onboarding cho developer mới. Đó là thời kỳ đầu của AWS, chưa phải thời mà site production có thể deploy bằng một cú nhấp chuột
Trải nghiệm đó khiến tôi học về quản lý phiên bản đúng cách, môi trường phát triển, Redis, sharding và clustering, VM, replication của Postgres và MySQL, wiki, monit, DNS, load balancer, reverse proxy, v.v. Vì tôi không bao giờ muốn làm sập site nữa
Đó là một công ty nhỏ giao website production cho một người bỏ học trung học chỉ có chút kinh nghiệm WordPress với mức 15 đô la/giờ, nhưng sau sai lầm họ không sa thải tôi; họ cho tôi sự tự do và niềm tin để học tại chỗ và cải thiện hệ thống. Đến giờ tôi vẫn biết ơn
Nhiều quy tắc hơn và quy trình tốt hơn không phải lúc nào cũng là điều tốt. Đôi khi quan liêu khiến NASA vốn đã chậm lại càng chậm hơn. Với những nhiệm vụ thuộc loại đầu tiên, có lúc phải dựa vào con người và chấp nhận rủi ro, chứ không phải dựa vào quy trình
Nói cách khác, có những phần được quyết định ngoài khả năng của tác giả, và khả năng anh ấy bị nhớ mãi như người đã phá hỏng rover, đúng như anh ấy lo sợ, cũng hoàn toàn có thể xảy ra
Điều này cũng rất gần với trải nghiệm của tôi. Ở một hãng hàng không lớn, tôi thường chọn nhận những dự án khó và rủi ro nhất; một trong số đó là nhanh chóng triển khai một nhà cung cấp thanh toán mới cho website. Trang đó bán vé trị giá hàng triệu euro mỗi ngày.
Chỉ vài giây sau khi triển khai, tôi nhận ra mình đã bỏ sót khác biệt giữa môi trường kiểm thử và môi trường production: một biến cốt lõi bị để trống trên production. Đó là điều lẽ ra có thể dự đoán nếu tôi đọc tài liệu kỹ hơn và chuẩn bị tốt hơn, nên khi việc bán hàng dừng hẳn, tim tôi như rơi xuống. Sau một quy trình rollback dài, doanh số bị gián đoạn trong vài giờ, khách hàng giận dữ đổ tới, và thiệt hại lên tới hàng triệu euro.
Tôi chặn CEO trong thang máy và nói rằng đó hoàn toàn là lỗi của tôi, tôi sẵn sàng chấp nhận mọi hậu quả kể cả bị sa thải. Ông ấy cười và đáp đại ý: “Tại sao tôi lại cho anh nghỉ? Chúng ta vừa chi hàng triệu để đào tạo anh. Giờ anh làm việc tốt hơn hôm qua rồi.” Trải nghiệm này đã định hình tôi ở nhiều mặt, trong đó có ý nghĩa của lãnh đạo thực sự, và sau đó tôi đã hoàn thành thành công nhiều dự án rủi ro cao.
Internet nói chung cũng hay hỏng. Khi thanh toán trên web shop của Nike vào Black Friday bị lỗi, giải pháp của helpdesk lại kiểu “hãy dùng ứng dụng”.
Trên thực tế, tôi không nghĩ thời gian gián đoạn được chuyển nguyên xi thành tổn thất. Twitter thời kỳ đầu thường xuyên sập vì độ phổ biến và kiến trúc, nhưng người ta đâu có ngừng dùng Twitter.
Với dịch vụ trực tuyến, downtime không nhất thiết là thảm họa hay dấu chấm hết của công ty. Nếu là thiết bị vũ trụ hoặc phần mềm giao dịch tần suất cao có thể làm công ty phá sản thì lại khác, và vì thế càng phải có cơ chế kiểm soát nghiêm ngặt hơn. Trên lý thuyết là vậy; còn thực tế, đôi khi chúng còn tệ hơn cả những web service CRUD lỏng lẻo được xây theo các thực hành tốt nhất học từ ngành vũ trụ và giao dịch tần suất cao.
Việc deploy lên production có thể cần một người cùng kiểm tra như cơ phó, có quyền dừng rollout, đồng thời kèm theo các biện pháp bảo vệ DevOps thông thường.
Những người nhận dự án rủi ro cao thường bị đánh giá thấp. Nhiều quản lý thích nhân viên ổn định nhưng không tạo ra giá trị gì hơn là nhân viên có kỳ vọng giá trị dương nhưng biến động.
Tôi làm trong ngành truyền hình. Ở công việc đầu tiên tại một đài địa phương nhỏ 30 năm trước, tôi được đào tạo làm người vận hành băng cho bản tin. Băng phát sóng được chất thành đống lớn, và có bốn đầu VTR để phát. Việc của tôi là nạp từng cuộn băng và căn đến điểm preroll trước 1 giây.
Khi một cuộn phát xong và đến lúc lấy ra, rất dễ bấm nút eject của đầu VTR đang phát sóng hiện tại thay vì đầu VTR vừa chạy xong. Người huấn luyện tôi mỗi khi thấy tôi đưa tay về phía nút eject đều nghiến răng hít vào một tiếng cảnh báo rất to; âm thanh đó khiến tôi dừng lại, kiểm tra hai ba lần rồi mới lấy băng ra.
Điều đó thật sự gây khó chịu, nhưng rất hiệu quả trong việc tạo phản xạ cẩn thận. Chính sách của đài là nếu lần đầu rút nhầm băng khi đang lên sóng trực tiếp thì bị nghỉ không lương một ngày; lần thứ hai là thử thách/kỷ luật theo dõi; lần thứ ba là sa thải. Một vài đồng nghiệp đã mất việc vì bất cẩn kinh niên và làm hỏng bản tin. Nhờ người huấn luyện khó chịu đó, tôi học được thói quen kiểm tra rồi kiểm tra lại, và chưa từng lấy băng ra khi nó đang phát sóng.
Đồng ý rằng người từng mắc lỗi như vậy sẽ không lặp lại đúng lỗi đó nữa. Vì thế, sa thải một người đã phạm sai lầm về mặt kỹ thuật và rõ ràng đang rất đau khổ thường là một lựa chọn tệ
Nhưng tôi không nghĩ đó là bài học “thật sự”. Xét đến chi phí và rủi ro, bài học là những bộ phận được kiểm thử bằng xung điện lớn nên có đầu nối kiểm thử chuyên dụng không tương thích với các bộ phận dễ bốc khói
Đây không phải một dự án breadboard nhỏ, mà là một dự án khổng lồ do rất nhiều người trong một cơ quan chính phủ thực hiện, nơi các quy trình chính thức tốn nhiều thời gian, tiền bạc và đôi khi còn bị chế giễu. Lập luận kiểu “hãy giao một robot 500 triệu USD có thể nổ tung nếu sơ suất cho một người 28 tuổi” nghe rất kỳ lạ
Đặc biệt trong khi kiểm thử, thường phải xử lý các cáp, đầu nối, mạch tùy chỉnh khác với “cấu hình bình thường”. Tôi cho rằng bài học là các công việc quan trọng nên áp dụng nguyên tắc 4 mắt nhiều nhất có thể. Cách một người thao tác, người còn lại kiểm tra từng bước rồi mới tiếp tục rất hiệu quả để bắt những “sai lầm ngớ ngẩn” như trong bài
Tuy nhiên, do áp lực lịch trình và các yếu tố khác, không phải lúc nào cũng có thể để hai người cùng theo dõi một bài kiểm thử, nên trong thực tế những lỗi như vậy vẫn xảy ra. Cần làm cho toàn bộ hệ thống vững chắc hơn
Trong lĩnh vực điện toán cũng có nhiều tác vụ tương tự chỉ thực hiện đúng một lần như một phần của nâng cấp hoặc migration trên cơ sở dữ liệu vận hành hay cấu hình router. Đôi khi chi phí tạo cơ chế bảo vệ còn lớn hơn việc cẩn thận ngay từ đầu. Chúng ta không phải lúc nào cũng cẩn thận hoàn hảo, nhưng cơ chế bảo vệ cũng không phải lúc nào cũng được làm hoàn hảo; đôi khi ta tin vào một cơ chế bảo vệ có lỗi rồi mắc sai lầm tương tự
Trong tình huống của câu chuyện, có lẽ nên có một người đồng hành giống pair programming phiên bản phần cứng, chỉ chuyên xác minh mọi việc người thực hiện làm có đúng hay không. Không phải một trợ lý hỗ trợ bằng cách chia vai như Mary, mà phải là người có nhiệm vụ duy nhất là theo sát và kiểm tra
Nếu nó đi vào các đường dữ liệu của bộ điều khiển động cơ thì rất có thể thứ gì đó đã cháy. Không thể loại trừ khả năng loại đầu nối khác nhau, nhưng đúng là hai đầu nối bị cắm nhầm đã được gán cùng một loại
Đặc biệt với đầu nối, có rất nhiều yêu cầu bảo thủ như phải là sản phẩm đã được chứng nhận, mức derating cụ thể, khoảng cách chân, backshell nối đất. Cuối cùng chỉ có vài dòng đầu nối được dùng và tồn kho, và dù tốn bao nhiêu chi phí thì việc làm cho chúng hoàn toàn không trùng nhau cũng không thực tế. Thông thường người ta sẽ chuẩn hóa các tín hiệu giống nhau, hoặc cố gắng làm chúng độc nhất để không bị trùng
Ví dụ, các đầu nối bên ngoài tàu vũ trụ cần là loại socket để tránh chập mạch trong quá trình thao tác, còn harness trung gian sẽ không bao giờ bị tháo ra và đầu nối dạng pin có thể được gắn đối xứng. Rồi khi cần breakout box để kiểm thử, sẽ xuất hiện cơ hội cắm ngược hộp
Hoặc một phía của breakout box là đầu nối 100 chân, còn phía kia phải nối với 25 thiết bị kiểm thử. Không có 25 loại đầu nối khác nhau để chọn, và cũng không thể ép yêu cầu tùy chỉnh lên mọi thiết bị kiểm thử
Tàu vũ trụ đang dần chuyển sang các vi điều khiển cục bộ và chẩn đoán cục bộ, nên các thiết bị kiểm thử kiểu này cho mọi tín hiệu analog đang giảm đi. Ngày nay động cơ cũng nhiều khả năng là brushless, và thay vì dùng breakout box như vậy, người ta có lẽ sẽ dựa vào telemetry của driver động cơ trong khi kiểm thử và bay
Đầu nối hàng không vũ trụ cũng đang trở nên cấu hình được nhiều hơn tại thời điểm đặt hàng, giống các ngành khác; có thể thêm key để dù có 10 đầu nối “giống nhau” thì chúng chỉ cắm được vào đúng vị trí. Dù vậy, yêu cầu mọi thiết bị kiểm thử đều được cấu hình như thế vẫn không thực tế
Để lưu lại, tôi cũng kể thêm câu chuyện của mình. Công việc đầu tiên sau khi tốt nghiệp đại học là ở một startup content marketing dùng PHP và PerconaDB(MySQL); tôi không có nhiều kinh nghiệm PHP nhưng có sự tự tin vô căn cứ của một người mới. Vì 6 tháng sau khi tốt nghiệp vẫn chưa kiếm được việc nên tôi cũng rất muốn tạo ấn tượng tốt
Tôi được giao cập nhật feature flag để bật một tính năng mới cho tất cả khách hàng, trừ những khách hàng đã yêu cầu tắt rõ ràng. Flag được lưu trong cơ sở dữ liệu dưới dạng các số nguyên 4 và 5 bên trong một mảng chuỗi
Để làm việc cần làm, tôi dùng hàm PHP array_reverse, nhưng vì không đọc tài liệu nên không biết rằng nếu không có tham số thứ hai thì nó chỉ đảo giá trị chứ không đảo key. Kết quả là cơ sở dữ liệu bị phá theo đúng hướng ngược lại với điều cần thiết, và kỳ lạ là vẫn qua QA
Vài giờ sau mới phát hiện ra; khi đó tôi đang đi làm với thời gian di chuyển gần 3 tiếng mỗi chiều, nên lúc ấy ban lãnh đạo cũng đã bị kéo vào. Có thể sửa dễ bằng một script chạy ngược, nhưng nó làm lộ ra nhiều vấn đề khác như QA và lỗi sao lưu DB
Tôi vẫn nhớ và biết ơn việc ngày hôm sau kiến trúc sư trưởng đến nói với tôi rằng đó giống như một nghi thức nhập môn khi làm việc với PHP, và bản thân ông ấy cũng từng mắc ở giai đoạn đầu sự nghiệp. Cuối cùng tôi bị sa thải; việc đó giúp tôi trưởng thành hơn với tư cách kỹ sư, nhưng khoảnh khắc ấy và vài tuần sau đó chắc chắn khiến tôi rất mất tinh thần
array_reverseđó à?Câu chuyện được viết rất cuốn hút nhưng cũng hơi khó hiểu
Nhóm này có vẻ đã mắc không chỉ một sai lầm mà là nhiều sai lầm. Cũng không rõ kết quả đó có thể thực sự gây hư hại cho tàu vũ trụ hay chỉ khiến họ lãng phí thời gian và rơi vào hỗn loạn khi tìm lý do vì sao tàu không bật lên
Sai lầm đầu tiên là họ không biết rằng đồng hồ vạn năng không chỉ đo, mà còn đang hoàn tất mạch điện. Nghe như một thiết kế thật sự tệ, và nếu nhất thiết phải làm như vậy thì tuyệt đối không được đụng vào cái đồng hồ vạn năng đó. Đây không phải lỗi của một người, mà là vấn đề liên quan đến ít nhất hai người, người quản lý họ, và cả người chịu trách nhiệm đã cho phép một hệ thống như vậy tồn tại
Sai lầm thứ hai nằm ở phía hộp breakout. Họ cho rằng đã cấp nhầm điện về phía tàu vũ trụ, và khi tàu không bật lên thì kết luận rằng một xung điện đã làm hỏng tàu, nhưng thực ra họ không chắc dòng điện đã đi đâu và cái gì đã bị hỏng, và cuối cùng kết luận đó là sai
Lý do tàu không bật lên là vì trước sự cố họ đã rút đồng hồ vạn năng ra khỏi mạch. Câu viết rằng đã có nhiều tuần phân tích về kênh H-bridge của động cơ RAT-Revolve và thảo luận về khả năng khử kim loại hóa màng mỏng vẫn khiến tôi bối rối: không rõ có phải họ đã phán đoán rằng xung điện cấp nhầm có thể đã chạy qua kênh đó và làm hỏng nó hay không
Điện thực sự đã đi vào mạch đó, và họ đang cố xác định xem nó có bị hư hại hay không. Tuy nhiên bộ điều khiển động cơ vốn phải chịu được dòng điện hồi ngược từ động cơ, nên có lẽ họ cho rằng nó không bị hỏng
Là một kỹ sư cơ khí/hàng không vũ trụ, tôi ước những câu chuyện đáng sợ nhất của mình chỉ ở mức suýt biến máy tính chính của một rover không người lái trị giá 500 triệu đô la thành cục gạch
Tôi từng là người cấp cao phụ trách phê duyệt an toàn trọng yếu cho những thứ chở mạng người. Sau một vụ rơi, khi nhìn ảnh các bộ phận vỡ nát, tôi phải gánh cảm giác kiểu “nếu đó là do tính toán của mình sai thì sao?”, “nếu khớp nối của mình bị trượt thì sao?”, “nếu là do quy trình thử nghiệm không phù hợp khi xử lý dự báo tuổi thọ mỏi gia tốc hoặc nứt ăn mòn ứng suất thì sao?”, “nếu vì vội đưa vào sản xuất mà đã không phát hiện trước khi xuất xưởng thì sao?”
Đọc những câu chuyện thất bại trong các lĩnh vực tương tự thì thú vị, nhưng những câu chuyện được chia sẻ công khai trên HN khiến tôi nghĩ rằng PTSD do công việc gây ra không phải là một cuộc thi. Với một số người, đơn giản là chi phí trị liệu sẽ cao hơn mà thôi
Thật may là có thể dùng năng lượng đó theo hướng giúp bản thân làm tốt hơn, nhưng không phải ai cũng phản ứng với sang chấn theo cùng một cách, và cũng không dễ so sánh những phản ứng như vậy. Chẳng hạn, tôi thấy dùng nó làm câu hỏi tuyển dụng thì có quá nhiều biến số xã hội
Ngay cả khi đó là một chi tiết mà quy trình không thể bắt được, vẫn phải có ai đó chịu trách nhiệm tạo ra quy trình tốt. Có thể có nhiều yếu tố, nhưng cuối cùng dường như vẫn sẽ có một người chịu trách nhiệm khá trực tiếp
Nghĩ trong bối cảnh kỹ nghệ phần mềm hay xã hội nói chung, nơi lỗi cá nhân được quy về tập thể, thì điều này khá thú vị
Nếu có khả năng đồng cảm và không giữ thái độ “tên lửa bay lên rồi rơi xuống đâu không phải việc của bộ phận tôi”, tôi nghĩ việc đó có thể khá nặng nề. Sẽ tốt nếu có các nhóm hỗ trợ đồng nghiệp dành cho những người xây dựng hệ thống an toàn trọng yếu hoặc xử lý hậu quả của chúng. Công ty không phải lúc nào cũng cung cấp tư vấn tốt
Các hội kỹ thuật hoặc tổ chức kỹ sư được cấp chứng chỉ có thể cung cấp dịch vụ như vậy bằng hội phí, nhưng cũng có khả năng người ta ngại sử dụng vì sợ mất giấy phép hoặc chứng nhận nghề nghiệp. Ngày xưa có lẽ họ đã xả với đồng nghiệp ở quán rượu trong lúc say, nhưng lệ thuộc rượu hoặc ảnh hưởng công việc ngày hôm sau thì không tốt, và văn hóa quán rượu cũng không còn như trước
Tôi nhớ đến vụ vệ tinh NOAA-N Prime bị đổ vì không có đủ bu lông để cố định vào bệ thử nghiệm.
Nguyên nhân gốc rễ, nếu tôi nhớ không chính xác thì mong được sửa, là các bu lông kiểm tra bằng tia X dùng để cố định vệ tinh quá đắt nên đã bị “mượn” sang dự án khác và chưa được trả lại. Khi lật vệ tinh sang tư thế nằm ngang, nó rơi xuống sàn, và chi phí sửa chữa là 135 triệu USD.
https://en.m.wikipedia.org/wiki/NOAA-19
Điều thú vị là nếu ngay từ đầu sắp xếp theo trình tự thời gian tốt hơn thì đã có thể tránh được nỗi lo. Nếu so sánh timestamp của kết quả đọc từ bài kiểm thử với timestamp cuối cùng của hệ thống telemetry, họ đã biết rằng telemetry đã hỏng trước khi chạy bài kiểm thử.
Việc không dùng timestamp chính xác mà dùng cách diễn đạt không chính xác kiểu “có vẻ như toàn bộ telemetry của tàu vũ trụ vừa bị mất một lúc trước” cũng là một phần nguyên nhân. Bài học là phải kiểm tra thật đúng xem các sự kiện trong sự cố liên kết với nhau chính xác như thế nào. Khi nhìn vào hai tín hiệu khác nhau, ta dễ giả định quan hệ nhân quả theo một hướng nhất định, nhưng trong thực tế có thể là ngược lại.