Dù phòng thủ tốt đến đâu, sự cố vẫn xảy ra: robot va vào kệ, drone rơi, xe phanh gấp sai. Cách một tổ chức điều tra sự cố quyết định nó học nhanh hay lặp lại sai lầm — và quyết định niềm tin của cơ quan quản lý. AS-PM thường là người điều phối điều tra, không phải để tìm người đổ lỗi mà để tìm lỗi hệ thống.
Nguyên tắc nền: Blameless (không đổ lỗi)
Điều tra hiệu quả bắt đầu từ văn hóa blameless. Nếu kỹ sư sợ bị phạt, họ sẽ giấu thông tin và bạn mất dữ liệu quý nhất. Giả định: người liên quan đã hành động hợp lý với thông tin họ có lúc đó. Câu hỏi không phải "ai sai?" mà "hệ thống nào cho phép sai lầm này xảy ra và lọt qua mọi lớp bảo vệ?".
Quy trình điều tra thực địa 7 bước
- Bảo toàn (Preserve): ngay lập tức khóa và sao lưu log, dữ liệu cảm biến, bản ghi camera, phiên bản phần mềm, cấu hình. Dữ liệu bay hơi rất nhanh — đây là bước dễ hỏng nhất. Nếu cần, dừng đội xe/robot cùng phiên bản.
- Ổn định & an toàn hiện trường: đảm bảo không có nguy cơ tiếp diễn (robot khác vẫn chạy vào vùng lỗi?). Cân nhắc grounding (dừng vận hành) toàn đội nếu nghi lỗi hệ thống.
- Dựng lại dòng thời gian (Timeline): ghép log đa nguồn thành một trục thời gian mili-giây: cảm biến thấy gì, hệ thống quyết định gì, cơ cấu chấp hành làm gì, con người can thiệp lúc nào.
- Tái hiện (Reproduce): nạp lại dữ liệu sự cố vào mô phỏng để tái tạo. Nếu tái hiện được, bạn có thể thử bản vá và xác nhận nó chặn được lỗi.
- Phân tích nguyên nhân gốc (Root Cause): dùng "5 Whys" và đặc biệt là cây lỗi (Fault Tree) — vì sự cố autonomy thường là chuỗi nhiều lỗi cộng dồn, không phải một nguyên nhân duy nhất (mô hình Swiss Cheese: nhiều lớp phô mai có lỗ thủng tình cờ thẳng hàng).
- Hành động khắc phục (CAPA): cả sửa ngay (mitigation) lẫn sửa gốc (corrective) + phòng ngừa tái phát (test hồi quy, cập nhật scenario library, sửa quy trình).
- Chia sẻ & báo cáo: viết báo cáo hậu sự cố (postmortem), báo cáo cơ quan quản lý nếu luật yêu cầu, chia sẻ bài học nội bộ.
Ví dụ minh họa
Một robot giao hàng đâm vào cột đèn lúc chạng vạng. Điều tra tệ dừng ở: "cảm biến không thấy cột". Điều tra tốt đi tiếp: Vì sao không thấy? → cột mảnh, ngược sáng → Vì sao không degrade? → ước lượng bất định không kích hoạt ở mức đó → Vì sao ngưỡng bất định đặt cao vậy? → vì team hạ ngưỡng để giảm số lần dừng oan làm phiền khách → nguyên nhân gốc là một quyết định đánh đổi UX vs an toàn không được review đúng. Bài học không chỉ là "sửa cảm biến" mà là "quy trình duyệt thay đổi ngưỡng an toàn".
Khung tư duy: Swiss Cheese
Mỗi lớp bảo vệ (cảm biến, thuật toán, degrade, giám sát con người, ODD) là một lát phô mai có lỗ. Tai nạn xảy ra khi các lỗ thẳng hàng. Điều tra tốt tìm mọi lỗ trên đường đi, rồi bịt càng nhiều lớp càng tốt — không chỉ lớp gần nhất.
Checklist ngay khi có sự cố
- [ ] Đã bảo toàn toàn bộ log/dữ liệu trước khi bất kỳ thứ gì bị ghi đè chưa?
- [ ] Có cần grounding đội xe/robot cùng phiên bản để chặn tái diễn không?
- [ ] Timeline mili-giây đã dựng đủ từ mọi nguồn chưa?
- [ ] Tái hiện được trong sim chưa? Nếu chưa, vì sao?
- [ ] Đã đào tới nguyên nhân hệ thống/quy trình, không dừng ở nguyên nhân kỹ thuật bề mặt?
- [ ] CAPA có cả sửa gốc lẫn phòng tái phát (test hồi quy)?
- [ ] Nghĩa vụ báo cáo pháp lý đã hoàn thành đúng hạn?
Sai lầm thường gặp
- Đổ lỗi cá nhân → mất dữ liệu, không sửa được gốc.
- Dừng ở nguyên nhân gần nhất: "phần mềm bug" mà không hỏi vì sao bug lọt qua review, test, staging.
- Không bảo toàn dữ liệu kịp: log bị xoay vòng ghi đè, hết cơ hội điều tra.
- Không tái hiện được nhưng vẫn tuyên bố đã sửa: nếu không tái hiện được lỗi, bạn không chắc bản vá có tác dụng.
- Sửa xong không thêm test hồi quy → vài tháng sau tái phát.
- Che giấu với cơ quan quản lý: mất niềm tin còn tốn kém hơn chính sự cố.