Buổi sáng sau một incident nhỏ, một lời mời họp xuất hiện trên calendar: failure celebration. Ai cũng hiểu ý định là tốt, nhưng căn phòng vẫn hơi dè dặt. Support đã dành cả buổi tối trả lời khách hàng. Engineer mệt. Manager muốn team học mà không sợ. Cụm từ đó đang cố giúp, nhưng đôi khi nghe như team được yêu cầu mỉm cười trước một thiệt hại mà người thật đã phải gánh.
Vì vậy tôi nghĩ celebrating failure cần một định nghĩa bình tĩnh hơn. Một team lành mạnh không mừng chính cái failure. Team mừng sự thành thật đã làm failure lộ ra, sự cẩn thận dùng để sửa nó, và những thay đổi hệ thống giúp failure sau ít xảy ra hơn. Đây không phải là vỗ tay cho một release hỏng. Đây là sự tôn trọng dành cho vòng học hỏi bắt đầu sau khi có chuyện sai.
Failure chỉ hữu ích khi nó trở thành thông tin. Một experiment thất bại có thể cho thấy giả định của team sai. Một production incident có thể làm lộ alert thiếu, runbook khó hiểu, hoặc thói quen deploy rủi ro. Một deadline trễ có thể cho thấy planning đã bỏ qua thời gian review hoặc dependency risk. Giá trị không nằm trong nỗi đau. Giá trị nằm ở tín hiệu bị giấu cho đến khi thực tế đẩy ngược lại.
Sự phân biệt này quan trọng vì slogan rất dễ trở nên cẩu thả. Nếu leader nói fail fast nhưng phạt người đầu tiên nói ra rủi ro, mọi người sẽ học cách giấu rủi ro. Nếu một postmortem nói là blameless nhưng âm thầm đi tìm người đã bấm sai nút, mọi người sẽ học cách viết câu chuyện an toàn hơn. Culture không phải điều team nói về failure khi mọi thứ ổn. Culture là điều xảy ra với người mang sự thật khó nghe vào phòng.
Một team đáng tin mừng tín hiệu sớm nhiều hơn những màn cứu nguy lớn. Engineer nói migration này chưa sẵn sàng có thể đã ngăn một incident không bao giờ xuất hiện. QA giữ một release lại vì một edge case thấy không ổn đang bảo vệ niềm tin theo cách rất lặng. Teammate ở support báo một pattern trước khi dashboard tăng vọt cũng đang làm một dạng engineering work. Những khoảnh khắc đó đáng được chú ý vì chúng làm failure nhỏ lại.
Khi failure thật sự xảy ra, sửa chữa nên đi trước reflection. Khách hàng cần được thông báo rõ. Data có thể cần sửa. Team có thể cần nghỉ. Sau đó việc học mới thành thật hơn. Một postmortem diễn ra quá sớm có thể trở thành màn trình diễn trưởng thành trong khi mọi người vẫn đang dọn dẹp. Học một cách bình tĩnh thường bắt đầu sau khi thiệt hại trước mắt đã được kiểm soát.
Một postmortem hữu ích hỏi những câu đơn giản. Chuyện gì đã xảy ra? Ta phát hiện bằng cách nào? Vì sao con đường này là hợp lý với những người liên quan ở thời điểm đó? Hệ thống của ta đã làm hành động sai trở nên dễ, hoặc hành động đúng trở nên khó, ở đâu? Ta sẽ thay đổi gì, ai sở hữu, và làm sao biết thay đổi đó có hiệu quả? Những câu hỏi này kéo team ra khỏi drama cá nhân và đi về phía default tốt hơn.
Blameless không có nghĩa là không ai chịu trách nhiệm. Nó nghĩa là trách nhiệm được dùng để cải thiện hệ thống, không phải để dựng một phiên tòa. Một người có thể owner một follow-up action. Một người có thể cần thêm support hoặc review rõ hơn. Một decision có thể cần sửa. Nhưng mục tiêu là hiểu những điều kiện đã tạo ra sai lầm, vì những điều kiện đó thường đang chờ người tiếp theo.
Cũng có lúc failure lặp lại không còn là can đảm nữa. Nếu cùng một incident xảy ra ba lần và team vẫn gọi đó là learning, nghi thức đã mất sự thành thật. Learning nên để lại bằng chứng: deploy process an toàn hơn, alert tốt hơn, blast radius nhỏ hơn, owner rõ hơn, checklist được đổi, shortcut rủi ro bị bỏ. Không có hành vi thay đổi, celebration trở thành cách né accountability.
Leader là người đặt nhiệt độ ở đây. Họ có thể giảm sợ hãi bằng cách chia sẻ những lần chính họ quyết định sai, cấp thời gian cho prevention work, bảo vệ thời gian follow-up, và không biến incident thành chuyện bàn tán. Họ cũng có thể tăng sợ hãi rất nhanh bằng một câu mỉa mai, một cuộc đổ lỗi riêng, hoặc một bài học công khai nhắc tên người nhiều hơn hệ thống. Người ta nhớ chuyện xảy ra sau lỗi gần nhất.
Những team lành mạnh nhất tôi từng thấy không lãng mạn hóa failure. Họ muốn tránh nó nếu có thể. Nhưng khi nó đến, họ xem nó là chất liệu chung để cải thiện. Họ cảm ơn người đã làm nó hiện ra, sửa thứ đã bị ảnh hưởng, nhìn lại con đường với sự kiên nhẫn, và thay đổi một điều thật. Việc đó lặng hơn một buổi celebration, nhưng hữu ích hơn nhiều.
Nếu team của bạn có một câu chuyện về một failure đã thật sự làm công việc an toàn hơn, phần thú vị có lẽ không phải failure đó. Phần thú vị là thay đổi nhỏ còn ở lại sau đó: alert giờ báo sớm hơn, câu hỏi review giờ được hỏi đều hơn, thói quen release bớt vội hơn. Đó mới là những thứ đáng nhớ, vì chúng biến một ngày khó thành nhiều ngày bình thường tốt hơn.