Một buổi postmortem thì dễ tổ chức và khó làm cho hữu ích. Cuộc họp diễn ra, một tài liệu được viết ra, bốn hạng mục hành động được ghi lại, rồi sáu tháng sau chính sự cố đó lặp lại trong lúc ai đó tình cờ tìm thấy tài liệu cũ khi đang kiếm một thứ khác.

Cụm từ không đổ lỗi chiếm gần hết sự chú ý trong các cuộc thảo luận về chủ đề này, và nó thật sự quan trọng, nhưng thất bại không nằm ở đó. Rất nhiều tổ chức tiến hành những buổi rà soát tuyệt đối không đổ lỗi mà chẳng thay đổi được gì, bởi buổi rà soát đã được xem là sản phẩm cuối, thay vì là thứ tạo ra sản phẩm cuối.

Phép thử xem quy trình của bạn có hiệu quả hay không đơn giản đến mức ngượng ngùng: bao nhiêu phần trăm hạng mục hành động của sáu tháng qua đã hoàn tất? Nếu câu trả lời là phần lớn, quy trình đang chạy tốt, dù nó trông ra sao. Nếu dưới một nửa, bạn đang tổ chức các cuộc họp chứ không vận hành một quy trình, và thêm biểu mẫu đẹp hơn cũng không sửa được. Ít hạng mục hơn, có người chịu trách nhiệm và có hạn chót, luôn hơn một danh sách đầy đủ mà không ai có thời gian làm.

Postmortem thực chất dùng để làm gì

Không phải để giải thích chuyện gì đã xảy ra. Những người có mặt thường đã biết điều đó từ trước khi sự cố khép lại.

Nó tồn tại để tìm ra các điều kiện đã cho phép một vấn đề nhỏ trở thành vấn đề lớn, và để thay đổi vài điều kiện trong số đó. Đó là một câu hỏi khác với câu hỏi cái gì đã hỏng, và sự khác biệt lộ ra ngay khi viết báo cáo. “Cơ sở dữ liệu hết kết nối” là cái đã hỏng. “Không có cảnh báo nào cho tình trạng bão hòa connection pool, và bảng điều khiển lẽ ra cho thấy điều đó lại không nằm trong runbook trực ca” là một điều kiện, và điều kiện thì xử lý được.

Thứ thứ hai mà nó tạo ra, thường bị đánh giá thấp, là một bản tường thuật chung về sự việc. Thiếu nó, mỗi người giữ một phiên bản riêng, và các phiên bản ấy trôi dần về phía điều mà từng người vốn đã tin về hệ thống. Một năm sau, hai nhóm tranh cãi về một sự cố mà họ cùng trải qua.

Không đổ lỗi có một nghĩa rất cụ thể

Nó không có nghĩa là không ai mắc lỗi. Nó có nghĩa là phân tích giả định rằng một người hành động hợp lý với thông tin sẵn có đã đưa ra một hành động về sau hóa ra sai, rồi hỏi vì sao hành động ấy trông đúng vào thời điểm đó. Cuốn sách SRE của Google trình bày cách làm này cùng những kiểu thất bại đi kèm.

Lý do đây không chỉ là sự tử tế là vì việc quy lỗi phá hủy thông tin. Trong một tổ chức mà sự cố dính vào cá nhân, người ta mô tả sự việc một cách dè dặt, bỏ đi chi tiết trông có vẻ bất lợi, và trì hoãn báo cáo cho đến khi hiểu đủ rõ để trình bày an toàn. Buổi rà soát khi đó làm việc trên một bản tường thuật đã được biên tập để tự bảo vệ, tức là đầu vào tệ nhất có thể.

Trên thực tế, không đổ lỗi là một thuộc tính của ngôn ngữ. “Tại sao bạn khởi động lại dịch vụ?” mời gọi sự phòng thủ. “Bảng điều khiển hiển thị gì lúc bạn quyết định khởi động lại?” mời gọi thông tin. Câu hỏi thứ hai cũng hữu ích hơn, vì câu trả lời là một dữ kiện về hệ thống giám sát của bạn chứ không phải về một đồng nghiệp.

Nếu thật sự tồn tại vấn đề về năng lực cá nhân, hãy xử lý riêng và trực tiếp. Làm việc đó ngay trong buổi rà soát sự cố sẽ làm hỏng buổi rà soát, và dù sao đi nữa đó cũng là cách tệ để có cuộc trò chuyện ấy.

Dựng một dòng thời gian dạy được điều gì đó

Dòng thời gian là phần giá trị nhất của tài liệu và cũng là phần bị viết dở nhiều nhất, dưới dạng một chuỗi sự kiện kỹ thuật đã bị lược bỏ hết con người.

Hãy ghi lại mọi người biết gì và biết vào lúc nào. Không chỉ “dịch vụ được khởi động lại lúc 14:32”, mà cả những gì người đó nhìn thấy được lúc 14:32 và điều họ tin là đang xảy ra. Đó là nơi chứa chất liệu có thể hành động, vì một độ trễ mười lăm phút do bảng điều khiển mơ hồ gây ra là vấn đề sửa được, còn một độ trễ mười lăm phút ghi lại như một khoảng trống thì không.

Hãy đánh dấu những thời điểm có ý nghĩa: khi nó bắt đầu, khi có người đầu tiên nhận ra, khi đúng người được kéo vào, khi nguyên nhân được hiểu, khi nó được giảm nhẹ, khi nó được xử lý dứt điểm. Khoảng cách giữa những mốc đó là nơi cải thiện nằm lại, và thời gian phát hiện rất thường là khoảng lớn nhất.

Hãy viết khi mọi thứ còn tươi mới, lý tưởng là trong vòng một hai ngày. Ký ức về điều một người tin vào một khoảnh khắc cụ thể phai đi nhanh hơn nhiều so với ký ức về điều đã xảy ra.

Hiếm khi chỉ có một nguyên nhân gốc rễ

Cách nói ấy khuyến khích dừng lại ở lời giải thích hợp lý đầu tiên, trong khi sự cố ở bất kỳ quy mô nào cũng là những chuỗi mà nhiều điều kiện phải cùng đúng một lúc.

Một buổi rà soát hữu ích thay vào đó liệt kê các yếu tố góp phần: thay đổi đã kích hoạt sự cố, bài kiểm thử lẽ ra bắt được nó nhưng không tồn tại, cảnh báo bắn vào một kênh không ai theo dõi, runbook vốn chính xác cho một kiến trúc trước đó. Mỗi thứ là một cơ hội riêng, và bạn có thể sửa hai thứ rẻ nhất thay vì thứ tình cờ đứng đầu chuỗi.

Điều này cũng làm giảm một méo mó phổ biến. Khi một buổi rà soát nêu ra một nguyên nhân gốc rễ duy nhất, nguyên nhân đó rất thường là “lỗi con người”, vốn là một mô tả chứ không phải một lời giải thích, và nó đóng cuộc điều tra đúng ngay chỗ lẽ ra phải bắt đầu.

Làm cho việc theo dõi thực sự xảy ra

Đây là nơi postmortem sống hoặc chết, và cách chữa không hào nhoáng.

Ít hạng mục hơn. Hai việc làm xong hơn tám việc bỏ dở. Xếp hạng theo mức giảm thời gian phát hiện, phạm vi ảnh hưởng hay xác suất, rồi cắt phần còn lại.

Người chịu trách nhiệm có tên và một hạn chót, trong công cụ theo dõi công việc thường ngày chứ không phải trong tài liệu. Hạng mục chỉ sống trong postmortem thì vô hình khi lập kế hoạch, tức lúc xếp lịch.

Rà lại hạng mục còn mở ở buổi postmortem kế tiếp. Riêng thói quen này hơn mọi biểu mẫu: nó làm việc chưa xong hữu hình và biến chuỗi họp rời rạc thành quy trình.

Trung thực chấp nhận một số hạng mục. Nhóm chỉ làm xong một nửa cam kết thì nên cam kết ít đi một nửa. Ghi một ý định không ai cấp nguồn lực còn tệ hơn ghi quyết định không làm, vì cái sau là thật.

Cải thiện từ đây cùng họ với hướng dẫn khôi phục sau thảm họa và chiến lược kiểm thử phần mềm: phát hiện nhanh hơn, phạm vi nhỏ hơn, hệ thống người khác vận hành được.

Mecanik rà soát sự cố trên hệ thống chúng tôi bảo trì, trong dịch vụ phân tích bảo mật máy chủ. Nguyên nhân kỹ thuật thường được hiểu nhanh; khoảng trễ phát hiện mới đắt.

Câu hỏi thường gặp

Postmortem để làm gì? Để tìm ra các điều kiện đã cho phép một vấn đề nhỏ trở thành lớn và thay đổi vài điều kiện trong số đó, vốn là câu hỏi khác với câu hỏi cái gì đã hỏng. Nó cũng tạo ra bản tường thuật chung về sự việc, thiếu nó thì mỗi người giữ một phiên bản riêng trôi dần về phía điều họ vốn đã tin về hệ thống.

Không đổ lỗi thực chất nghĩa là gì? Là phân tích giả định rằng một người hành động hợp lý với thông tin sẵn có đã làm một việc về sau hóa ra sai, rồi hỏi vì sao việc đó trông đúng vào lúc ấy. Nó quan trọng vì quy lỗi phá hủy thông tin: người ta biên tập lời kể để tự bảo vệ, và buổi rà soát khi đó làm việc trên đầu vào đã hỏng.

Postmortem có nên chỉ ra một nguyên nhân gốc rễ duy nhất không? Không. Sự cố ở bất kỳ quy mô nào cũng là chuỗi mà nhiều điều kiện phải cùng đúng một lúc, nên liệt kê các yếu tố góp phần hữu ích hơn. Nó cho phép sửa hai thứ rẻ nhất thay vì thứ đứng đầu chuỗi, và tránh kết luận bằng “lỗi con người”, vốn là mô tả chứ không phải lời giải thích.

Dòng thời gian sự cố nên có những gì? Mọi người biết gì và biết lúc nào, không chỉ hệ thống đã làm gì. Hãy ghi khi nó bắt đầu, khi có người đầu tiên nhận ra, khi đúng người được kéo vào, khi nguyên nhân được hiểu, khi nó được giảm nhẹ và khi được xử lý dứt điểm. Khoảng cách giữa các mốc là nơi cải thiện nằm lại, và thời gian phát hiện thường là lớn nhất.

Vì sao hạng mục hành động của postmortem không bao giờ xong? Vì chúng sống trong tài liệu chứ không trong công cụ theo dõi công việc, nên vô hình khi lập lịch. Hãy sửa bằng cách giảm số hạng mục, giao người chịu trách nhiệm có tên và hạn chót trong công cụ thường ngày, và rà lại các hạng mục còn mở ở đầu buổi postmortem kế tiếp để việc chưa xong trở nên hữu hình.