Mẫu phân tích sự cố kỹ thuật (không đổ lỗi, có thể hành động)

Vì sao phân tích sự cố biến thành buổi đổ lỗi

Phân tích sự cố thất bại theo một cách cụ thể: cả phòng bắt đầu gán nguyên nhân trước khi cả phòng có một dòng thời gian chung. Ai đó nói "việc triển khai gây ra chuyện này" trước khi thời điểm triển khai được xác nhận. Người khác nói "cảnh báo không kích hoạt" mà không biết liệu cảnh báo có được cấu hình cho tình huống đó hay không. Cuộc trò chuyện trở thành một cuộc tranh cãi về nguyên nhân trước khi bất kỳ ai xác lập được điều gì thực sự đã xảy ra, theo thứ tự nào.

Cách khắc phục mang tính cấu trúc: cùng nhau dựng dòng thời gian sự cố ngay từ đầu buổi phân tích, trước khi bất kỳ ai nêu tên nguyên nhân gốc rễ. Một khi cả phòng đã nhìn vào chuỗi sự kiện — điều gì thay đổi khi nào, ai thấy gì vào thời điểm nào — nguyên nhân trở nên dễ thảo luận hơn nhiều và ít có khả năng sụp đổ thành đổ lỗi hơn nhiều. Đây là lỗi sắp xếp thứ tự mà hầu hết các mẫu mắc phải: chúng đặt nguyên nhân gốc rễ trước dòng thời gian vì nguyên nhân gốc rễ mới là thứ mà mẫu hướng đến. Nhưng chính dòng thời gian mới làm cho nguyên nhân gốc rễ trung thực.

Chương trình họp (sao chép và dán)

Thời lượng: 60 phút cho một sự cố đơn giản; 90 phút cho các lỗi phức tạp liên quan nhiều hệ thống
Định dạng: Có người điều phối; tất cả người ứng phó và kỹ sư trực on-call có mặt; chuẩn bị bất đồng bộ với một tài liệu đọc trước

Phần 1 — Tóm tắt sự cố (5 phút)

Ngày tháng và thời lượng của sự cố
Phân loại mức độ nghiêm trọng và các hệ thống bị ảnh hưởng
Ai phát hiện ra và bằng cách nào (khách hàng báo, cảnh báo, kỹ sư, giám sát)
Phần này chỉ nêu sự kiện; chưa phân tích gì

Phần 2 — Dòng thời gian (20 phút)

Dựng dòng thời gian cùng nhau trên màn hình — không phải một tài liệu viết sẵn
Trình tự: điều gì thay đổi, điều gì được quan sát, ai hành động, điều gì được quyết định
Mỗi mốc thời gian đều phải có nguồn (dòng log, PagerDuty, tin nhắn Slack)
Khi dòng thời gian hoàn tất, hãy hỏi: mọi người có đồng ý đây là những gì đã xảy ra không? Giải quyết các bất đồng trước khi tiếp tục

Phần 3 — Tóm tắt tác động (5 phút)

Tác động đến khách hàng: ai bị ảnh hưởng, trong bao lâu, theo cách nào
Tác động đến kinh doanh: doanh thu, SLA, uy tín
Tác động nội bộ: số giờ on-call, sự gián đoạn của nhóm
Giữ phần này ở mức sự kiện; nó neo giữ câu hỏi "chuyện tệ đến đâu" mà không thêm bình luận cảm tính

Phần 4 — Nguyên nhân gốc rễ và các yếu tố góp phần (20 phút)

Nguyên nhân gốc rễ: thay đổi hoặc điều kiện gần nhất khiến sự cố có thể xảy ra
Các yếu tố góp phần: những điều kiện khiến nó tệ hơn, khó phát hiện hơn, hoặc chậm khắc phục hơn
Những bản phân tích sự cố hữu ích nhất xác định 3-5 yếu tố góp phần bên cạnh nguyên nhân gốc rễ; chỉ sửa nguyên nhân gốc rễ thường bỏ sót các điều kiện mang tính hệ thống
Với mỗi yếu tố, hãy hỏi: có cá nhân hay nhóm nào đã đưa ra một quyết định có vẻ hợp lý với thông tin sẵn có lúc đó không? Nếu có, yếu tố đó mang tính hệ thống, không mang tính cá nhân

Phần 5 — Điều gì đã diễn ra tốt (5 phút)

Việc phát hiện hay ứng phó nào đã hoạt động tốt hơn dự kiến?
Quy trình hay công cụ hiện có nào đã hạn chế phạm vi ảnh hưởng?
Đây là những thực hành đáng được chuẩn hóa — nếu runbook đã tiết kiệm 20 phút, hãy ghi lại để runbook được duy trì

Phần 6 — Đầu việc (15 phút)

Mỗi đầu việc giải quyết một nguyên nhân gốc rễ hoặc yếu tố góp phần — không phải một cải tiến chung chung
Một người phụ trách mỗi mục; một ngày hoàn thành phản ánh mức độ khẩn cấp
Phân loại: phát hiện sớm hơn / phục hồi nhanh hơn / ngăn tái diễn
Giới hạn ở những hành động mà nhóm có thể thực sự hoàn thành trước sự cố tiếp theo, không phải một lộ trình độ tin cậy toàn diện

Điều gì khiến các mẫu phân tích sự cố thất bại

Trình tự nguyên nhân-gốc-rễ-trước là vấn đề cấu trúc chính — đã nói ở trên. Vấn đề thứ hai là coi "đầu việc" như một hạng mục duy nhất. Cải thiện phát hiện, cải thiện phục hồi, và cải thiện phòng ngừa đòi hỏi những người phụ trách khác nhau và những khung thời gian khác nhau. Trộn lẫn chúng tạo ra một danh sách trải dài sáu tháng và ba nhóm, nghĩa là trách nhiệm bị phân tán và không mục nào được hoàn thành.

Kiểu thất bại thứ ba là bỏ qua "điều gì đã diễn ra tốt" vì nó có vẻ như một sự lạc quan không phù hợp sau một sự cố. Không phải vậy — đó là cách duy nhất có hệ thống để xác định và chuẩn hóa những thực hành đã hoạt động dưới áp lực. Nếu hệ thống giám sát bắt được vấn đề vốn không nằm trong lộ trình của ai để xây dựng, thì việc nhận ra nó quan trọng là điều đáng ghi lại. Nếu không, nó bị hạ ưu tiên sau khi sự cố lắng xuống và bạn lại mù thông tin vào lần tiếp theo.

Cái giá tích lũy của những sự cố mà các yếu tố góp phần không được xử lý, và những runbook đã phát huy tác dụng lại không được duy trì, dồn lại rất nhanh. Thuế họp hành trình bày cách gánh nặng họp hành định kỳ và món nợ rà soát sự cố tương tác với nhau.

Vì sao việc ghi nhận phân tích sự cố khó một cách đặc biệt

Các cuộc thảo luận phân tích sự cố sinh ra nội dung dày đặc, không có cấu trúc rất nhanh: tái dựng dòng thời gian, các cách diễn giải trái ngược, việc giao đầu việc cho nhiều người, chi tiết kỹ thuật sẽ vô nghĩa trong một bản ghi lời nếu thiếu ngữ cảnh. Một bản tóm tắt phân tích sự cố viết từ trí nhớ hoặc âm thanh đã cắt gọt thì gần như luôn không đầy đủ, và những bản ghi phân tích sự cố không đầy đủ thì vô dụng cho việc nhận diện quy luật xuyên suốt các sự cố.

Pavleur ghi lại toàn bộ cuộc thảo luận phân tích sự cố và tạo báo cáo tự động — dòng thời gian đúng như đã tái dựng, các yếu tố góp phần đúng như đã nêu tên, các đầu việc kèm người phụ trách và phân loại đúng như đã nêu trong cuộc họp. Nếu ai đó chia sẻ màn hình để hiển thị một đoạn log, một biểu đồ giám sát, hay cấu hình cảnh báo đã không kích hoạt, hình ảnh đó là một phần của báo cáo. Các công cụ chỉ có âm thanh bỏ sót hoàn toàn điều này; một bản ghi phân tích sự cố không có biểu đồ là một bản ghi thiếu bằng chứng. Bất kỳ ai trong nhóm — kể cả những kỹ sư gia nhập sau sự cố — đều có thể đọc bản ghi đầy đủ, kèm ngữ cảnh hình ảnh, mà không cần nhờ ai tái dựng lại. Để so sánh trực tiếp với các công cụ khác về điểm này: Pavleur so với các lựa chọn khác.

Về tần suất phân tích sự cố

Hãy thực hiện phân tích sự cố trong vòng 48 giờ sau khi sự cố được giải quyết, khi chi tiết còn tươi mới. Bạn càng chờ lâu, việc tái dựng dòng thời gian càng phụ thuộc vào trí nhớ thay vì log, và trí nhớ thì không đáng tin dưới áp lực. Với các sự cố mức nghiêm trọng cao, 24 giờ thì tốt hơn. Với các sự cố nhỏ, phân tích sự cố bất đồng bộ — một tài liệu chung với các câu hỏi có cấu trúc, được rà soát đồng bộ — có thể hiệu quả hơn một buổi họp đầy đủ. Định dạng họp có giá trị nhất khi sự cố mơ hồ hoặc rủi ro cao đến mức việc chia sẻ cách diễn giải chung trở nên quan trọng.