CapordiaMô tả tác động trước khi đề xuất nguyên nhân
Đưa ra một câu có thể quan sát được: một số công việc không còn tạo ra kết quả, một quyền truy cập được phép bị từ chối hoặc một bản xuất không còn đọc lại được. Nêu rõ phạm vi bị ảnh hưởng và cái gì vẫn còn hoạt động. “Máy chủ bị hỏng” nhanh chóng trở thành một kết luận quá rộng khi chỉ một đường ra bị lỗi. Hãy đếm các kết quả được chấp nhận, không đầy đủ và chưa chạy bằng các loại loại trừ lẫn nhau.
Chỉ định một người phụ trách điều phối và một người được phép can thiệp. Hướng dẫn quản lý sự cố của Google SRE phân biệt điều phối với vận hành và truyền thông. Trong một nhóm nhỏ, một người có thể đảm nhiệm nhiều vai trò, nhưng mỗi người phải biết ai là người quyết định. Ấn định mốc cập nhật thông tin tiếp theo trong nội bộ; cách tổ chức này không tạo ra bất kỳ thời hạn phản hồi được đảm bảo nào từ nhà cung cấp.
Giữ một dòng thời gian phân biệt các sự kiện
Ghi lại trạng thái đúng đắn cuối cùng được biết, triệu chứng đầu tiên và các thay đổi xảy ra giữa hai thời điểm đó. Nêu múi giờ và nguồn gốc của từng mốc thời gian: nhật ký, quan sát trực tiếp hoặc ký ức cần xác nhận. Một ngày sao chép trong ảnh chụp không nhất thiết có cùng hệ quy chiếu với nhật ký của ứng dụng. Nếu thiếu một mốc, hãy giữ khoảng bất định thay vì bịa ra một phút chính xác.
Với mỗi hành động, ghi lại người thực hiện, phạm vi, mục tiêu và kết quả. “Đã khởi động lại” là chưa đầy đủ nếu không biết tiến trình nào liên quan và liệu triệu chứng có thay đổi không. Giữ tách biệt quan sát, giả thuyết và quyết định. Sự tách biệt này sẽ cho phép tái dựng cái gì thực sự đã giúp ích và tránh việc nhiều người cùng lúc thử những cách khắc phục không tương thích.
Ví dụ hư cấu: một bản xuất một phần, không phải một sự cố GPU đã được chứng minh
Trong ô giả định « Bản đồ bờ biển », hai mươi tài liệu phải được giao. Mười bốn đầu ra đã được mở và chấp nhận, bốn tác vụ báo lỗi từ chối ghi và hai tác vụ còn chờ khởi chạy. Vì vậy sáu kết quả vẫn chưa thể giao được, nhưng sẽ là sai nếu tuyên bố hai mươi kết quả đã mất. Ví dụ này không mô tả bất kỳ sự cố thực tế nào cũng như máy chủ Capordia nào.
Trình tự thời gian dưới đây dẫn đến việc yêu cầu xem xét có mục tiêu đường dẫn đầu ra. Nó chưa chứng minh được nguyên nhân: thay đổi gần về mặt thời gian có thể liên quan đến triệu chứng mà không giải thích được triệu chứng. Đội ngũ giữ lại mười bốn đầu ra đã được chấp nhận và chỉ tạm dừng các yêu cầu gửi mới bị ảnh hưởng. Các mốc giờ là giả định và thuộc cùng một múi giờ, được chọn để tránh mọi nhầm lẫn khi đọc.
| Giờ | Sự việc được ghi nhận | Suy luận được phép |
|---|---|---|
| 9 giờ 40 | Đầu ra cuối cùng được mở thành công | Mốc hoạt động đã biết |
| 9 giờ 42 | Đích đầu ra được thay đổi | Thay đổi cần xem xét |
| 9 giờ 43 | Lỗi từ chối ghi đầu tiên được ghi nhận | Thời điểm bắt đầu quan sát được của triệu chứng |
| 9 giờ 48 | Tạm dừng các yêu cầu gửi mới bị ảnh hưởng | Biện pháp hạn chế ảnh hưởng |
| 10 giờ 05 | Cùng lỗi từ chối với một tệp giả định nhỏ | Bản tái hiện nhỏ hơn, nguyên nhân cần xác nhận |
Thu gọn bản tái hiện mà không xóa lỗi
Hãy tìm đầu vào nhỏ nhất vẫn giữ được triệu chứng và cùng đường dẫn liên quan: loại tệp, đích, danh tính kỹ thuật hoặc cài đặt. Thay nội dung nghiệp vụ bằng dữ liệu tổng hợp khi có thể. Nếu việc thay thế làm lỗi biến mất, hãy ghi lại giới hạn đó. Không được trình bày như một bản tái hiện trung thực một lệnh đã đơn giản hóa mà không còn đi qua phần bị nghi ngờ.
Hãy tiến hành theo các giả thuyết có thể kiểm chứng. Chương về khắc phục sự cố của Google SRE khuyến nghị các phép thử cho phép phân định nguyên nhân và nhắc rằng việc đo lường hoặc thử nghiệm có thể ảnh hưởng đến hệ thống. Vì vậy hãy ghi lại kết quả phủ định cẩn thận như ghi lại thành công. Tránh chạy lại liên tục một tiến trình vốn công bố đầu ra hoặc làm lưu trữ thêm trầm trọng; người phụ trách trước tiên xác định phạm vi thử nghiệm được phép.
Chuẩn bị bằng chứng dễ đọc và đã loại bỏ thông tin nhạy cảm
Hồ sơ chuyển giao gồm các phiên bản hữu ích, quy trình tối thiểu, các mốc giờ, thông báo lỗi chính xác và một đoạn nhật ký quanh thời điểm có triệu chứng. Hãy thêm mã tác vụ và mã tham chiếu của hồ sơ liên quan khi điều đó giúp đối chiếu dễ hơn. Loại bỏ phần còn lại của nhật ký nếu không ai cần để hiểu tình huống. Giữ lại bản gốc trong phạm vi được phép của đội ngũ.
OWASP nhắc rằng nhật ký không được để lộ đặc biệt là mật khẩu, mã truy cập hoặc khóa. Hãy đọc lại cả đường dẫn, tên tệp và đối số có thể tiết lộ dự án. Dùng các thay thế nhất quán, chẳng hạn PROJET_A, đồng thời giữ cấu trúc cần thiết cho chẩn đoán. Một bằng chứng đã loại bỏ thông tin nhạy cảm phải nêu rõ những gì đã bị lược bỏ; không được thay đổi thông báo lỗi quyết định cũng không được làm mất đi một điều kiện quan trọng.
Soạn yêu cầu chuyển cấp giúp có thể hành động
Hãy mở đầu yêu cầu bằng ảnh hưởng và câu hỏi cụ thể: xem xét lỗi từ chối truy cập, xác nhận một thuộc tính của việc cấp phát hoặc giúp định vị một sai lệch có thể tái hiện. Đính kèm trình tự thời gian và bản tái hiện đã loại bỏ thông tin nhạy cảm. Nêu rõ các hành động đã thử, những hành động không thay đổi được gì và những thao tác cần tránh. Người nhận phải có thể biết điều gì đang được mong đợi mà không cần khám phá một hồ sơ ảnh chụp không có chú thích.
Trong ví dụ, yêu cầu có thể là: « Đường dẫn đầu ra mới được sử dụng từ chối ghi dưới danh tính của tiến trình; xin vui lòng xem xét các quyền áp dụng cho đường dẫn này. Mười bốn đầu ra vẫn được xác nhận; bốn tác vụ đã báo lỗi từ chối ghi, và lỗi từ chối này đã được tái hiện với một đầu vào giả định. » Đoạn văn này không cáo buộc GPU cũng không cáo buộc một nhân viên vận hành. Nó trình bày những gì đã biết và để ngỏ nguyên nhân cho đến khi được xem xét.
Kiểm tra phản hồi trước khi kết thúc
Một lỗi không còn tái diễn chưa hẳn đã đủ. Hãy kiểm tra một kết quả hoàn chỉnh với cùng danh tính, cùng các điều kiện quyết định và một điểm đến được rà soát lại. Sau đó kiểm soát các phần tử bị ảnh hưởng: các kết quả đã được chấp nhận có được giữ nguyên không, các kết quả một phần có được tách riêng và các công việc còn lại có được xác định đúng không? Người phụ trách kết quả phải xác nhận việc khôi phục hữu ích, tách biệt với thành công của một lệnh kỹ thuật.
Di chuyển là một thay đổi có tổ chức trước khi chuyển công việc; sự cố bắt đầu bằng một sai lệch bất ngờ. Nếu việc xử lý nó đòi hỏi phải di chuyển dữ liệu hoặc tiếp tục một xử lý bị gián đoạn, thì hãy dùng hồ sơ di chuyển hiện có cho thao tác đó. Dòng thời gian sự cố giữ lại lý do của quyết định này; nó không viết lại phương pháp chuyển đổi hay sổ đăng ký các lô.
Giữ một kết luận có thể sử dụng được, ngay cả khi nguyên nhân vẫn còn bỏ ngỏ
Kết thúc bằng tác động cuối cùng, kết quả kiểm tra, nguyên nhân đã được chứng minh hoặc vẫn chưa rõ và các hành động đã quyết định. Một biện pháp lách có thể khôi phục một kết quả mà không giải quyết vấn đề gốc: hãy nói rõ điều đó và nêu tên người phụ trách theo dõi. Việc thiếu bằng chứng không được trở thành «không có sự cố»; một sự tương đồng với một trường hợp cũ không được trở thành một nguyên nhân chắc chắn.
Việc rà soát cuối cùng phải cho phép một người khác phân biệt được điều gì đã được quan sát, điều gì đã được thử và điều gì còn phải kiểm tra. Nó dùng để cải thiện một quy trình, một kiểm soát hay một thông báo lỗi, chứ không phải để dựng nên một câu chuyện không có chút bất định nào. Không số lượng ảnh chụp, khối lượng nhật ký hay mức độ khẩn cấp nào thay thế được chất lượng truyền đạt này.
Câu hỏi để quyết định
Có cần chờ biết nguyên nhân mới báo cáo sự cố không?
Không. Hãy báo cáo một tác động có thể kiểm chứng và phạm vi đã biết, rồi tách bạch rõ ràng các giả thuyết. Một dòng thời gian và một lần tái hiện có mục tiêu thường giúp ích trước khi nguyên nhân được chứng minh. Cũng nên nêu rõ các biện pháp đã thực hiện để hạn chế tác động.
Tôi có thể gửi toàn bộ nhật ký để tiết kiệm thời gian không?
Trước tiên hãy chuẩn bị các trích đoạn hữu ích và rà soát lại chúng. Nhật ký đầy đủ có thể chứa bí mật và dữ liệu dự án mà không giúp gì cho việc chẩn đoán. Giữ bản gốc trong một không gian được phép và giải thích các thay thế đã thực hiện trong bản được gửi đi.
Khi nào thì coi hồ sơ là đã khép lại?
Sau khi kiểm tra kết quả mong đợi và có quyết định rõ ràng của người phụ trách. Hãy phân biệt sửa chữa đã xác nhận với biện pháp lách tạm thời. Việc khép lại có thể vẫn giữ một nguyên nhân chưa rõ, với điều kiện nêu rõ các giới hạn, việc kiểm tra đã thực hiện và các hành động còn bỏ ngỏ.