Không định nghĩa P1 cùng khách, lỗi nào cũng thành sự cố lớn

Mười một giờ đêm, điện thoại rung. Trưởng nhóm vận hành bên khách nhắn: “P1, nút xuất báo cáo bị lệch.” Bạn mở laptop, xác nhận nút lệch đúng vài pixel, và nhận ra đây đã là lần thứ ba trong tuần bạn bị gọi dậy vì một lỗi không ai cần sửa trước sáng mai.

Khách không cố tình làm khó bạn. Họ dùng chữ P1 theo cách hiểu của họ, còn bạn hiểu theo cách của đội mình. Rootly, một nền tảng quản lý sự cố, nói thẳng rằng không có chuẩn chung nào cho nhãn P1/P2/P3 hay SEV0/SEV1/SEV2.

Với FDE, chuyện này nặng hơn so với một đội SRE nội bộ, vì bạn đứng giữa hai tổ chức. OneUptime viết rằng nếu thiếu định nghĩa rõ ràng, sự cố nào cũng biến thành một cuộc tranh cãi.

Cách tránh là ngồi với khách trước ngày go-live, viết ra bốn mức từ P1 đến P4, rồi hai bên cùng ký.

Một chữ P1 chứa hai câu hỏi

Khi khách nói “P1”, họ đang trả lời hai câu cùng lúc: lỗi này tệ đến đâu, và phải xử lý nhanh đến đâu. Rootly tách hai thứ này ra. Severity đo tác động của sự cố, còn priority quyết định tốc độ hành động. Người ta hay gộp hai khái niệm làm một, và cuộc cãi nhau lúc nửa đêm thường bắt đầu từ chỗ gộp đó.

Severity nên đo bằng thứ đếm được. PagerDuty khuyên mỗi tổ chức tự định nghĩa thang mức của mình, thường dựa trên tỷ lệ phần trăm người dùng hoặc tài khoản bị ảnh hưởng. OneUptime đưa một ngưỡng mẫu cho mức tác động cao: hơn 25% người dùng bị ảnh hưởng, hoặc một chức năng tạo ra doanh thu bị suy giảm.

Nên có bao nhiêu mức? Theo kinh nghiệm của incident.io, 3-5 mức là vừa, vì ít hơn thì không phân biệt được các sự cố khác nhau. Bốn mức P1-P4 nằm gọn trong khoảng đó, và đủ để tách việc “gọi dậy ngay” khỏi việc “đưa vào sprint tới”.

Bảng cho một khách hàng cụ thể

Thử hình dung bạn đang triển khai một agent đọc hồ sơ bồi thường cho một công ty bảo hiểm, với 400 nhân viên giám định dùng hằng ngày. Ở khách này, ngưỡng 25% tương đương hơn 100 người. Bảng bạn mang vào buổi họp có thể trông như dưới đây, mỗi dòng ghi cả tác động lẫn tốc độ phản hồi.

Mức	Tác động	Phản hồi	Ví dụ ở khách bảo hiểm
P1	Agent ngừng chạy, hoặc hơn 100 trong 400 giám định viên không xử lý được hồ sơ	Bắt tay vào ngay, 24/7, gác việc đã lên kế hoạch, báo lãnh đạo hai bên	Mọi hồ sơ trả về lỗi sau một lần cập nhật model
P2	Một nhóm nhỏ hơn bị chặn ở chức năng chính	Phản hồi trong ngày làm việc, sau các việc P1	30 người không tải được một loại biểu mẫu scan
P3	Chất lượng giảm nhưng có cách đi vòng	Đưa vào lịch làm việc thường kỳ, không gọi ngoài giờ trừ khi tình hình xấu đi	Agent phân loại sai vài hồ sơ hiếm, người duyệt sửa tay được
P4	Lỗi nhỏ hoặc lỗi giao diện, không cản việc dùng sản phẩm	Mở ticket, không gọi người	Nút xuất báo cáo lệch vài pixel

Để ý cách bảng giữ hai câu hỏi tách bạch dù chỉ dùng một nhãn: cột Tác động trả lời câu hỏi severity, cột Phản hồi trả lời câu hỏi priority. Đặt chúng trên cùng một dòng nghĩa là hai bên đã thỏa thuận trước rằng tác động cỡ này đi với tốc độ cỡ kia, nên lúc nửa đêm không ai phải mặc cả lại.

Cột Phản hồi cũng không phải tự nghĩ ra: nó khớp với cách Rootly định nghĩa P1, P2, P3, với quy tắc không gọi ngoài giờ của OneUptime cho mức thấp, và với cách PagerDuty đẩy lỗi giao diện sang ticket.

Riêng việc báo lãnh đạo ở P1 tương ứng với SEV-1 của PagerDuty, mức sự cố phải thông báo công khai và trao đổi thẳng với ban lãnh đạo.

Bây giờ áp con số vào. Lỗi biểu mẫu chặn 30 người, tức 7,5% của 400, vẫn dưới ngưỡng 25%. Vì vậy nó là P2, dù với 30 người đó hôm nay là một ngày tệ.

Nếu cùng lỗi đó lan sang 120 người, tức 30%, nó vượt ngưỡng và lên P1. Mức sự cố do con số quyết định, không phải do giọng điệu của tin nhắn. Còn cái nút lệch lúc mười một giờ đêm là P4: một ticket, và không ai bị gọi dậy.

Buổi họp trước go-live

Bảng nháp chỉ có giá trị khi khách tự đặt các ngưỡng. Đừng hỏi “anh muốn mức P1 là gì”, vì câu đó mời khách trả lời “mọi thứ quan trọng”. Hãy hỏi về con người và về giờ giấc:

Bạn: “Nếu agent ngừng chạy lúc 3 giờ sáng Chủ nhật, anh muốn ai được gọi?

Chính anh có muốn bị gọi không?”

Khách: “Có chứ, cả phòng giám định sẽ đứng.”

Bạn: “Còn nếu chỉ một loại biểu mẫu bị lỗi và khoảng 30 người bị chặn, có cần gọi ai dậy giữa đêm không, hay để sáng thứ Hai?”

Khách: “Sáng thứ Hai được, miễn là trong ngày có người xử lý.”

Sau hai câu trả lời đó, khách đã tự vạch ranh giới giữa P1 và P2. Bạn chỉ cần ghi lại bằng con số.

Trình tự làm như sau. Trước buổi họp, bạn đếm người dùng thật và xác định chức năng nào gắn với doanh thu, rồi điền bảng nháp bằng ví dụ lấy từ chính hệ thống của khách. Trong buổi họp, bạn dùng kịch bản trên để chỉnh ngưỡng.

Trước khi ký, thêm hai quy tắc vào cuối bảng. Quy tắc thứ nhất lấy từ PagerDuty: chưa chắc sự cố ở mức nào thì xử lý như mức cao hơn, rồi xem lại ở postmortem. Quy tắc thứ hai lấy từ Rootly: phân loại ban đầu chỉ là tạm thời, và việc đổi mức cho thấy quy trình đang chạy đúng.

Vì sao nhiều bảng chỉ còn là giấy lộn?

Lỗi phổ biến nhất là chỉ có nhãn mà không có tiêu chí. Một dòng ghi “P1: nghiêm trọng” không giúp được ai lúc nửa đêm, vì “nghiêm trọng” lại là thứ hai bên đang tranh cãi. Mỗi mức phải có một con số hoặc một chức năng cụ thể mà người trực có thể kiểm tra trong vài phút.

Lỗi thứ hai là ngại hạ mức. Một sự cố mở ở P1, sau 20 phút hóa ra chỉ ảnh hưởng mười người, thì nên hạ xuống P2 và ghi rõ lý do để cả hai bên cùng thấy. Nếu không ai dám hạ, khách sẽ học được rằng cứ gắn P1 là có người chạy tới, và bảng sẽ mất tác dụng sau vài tuần.

Lỗi thứ ba là viết xong rồi cất đi. Bảng phải khớp với cấu hình alert và lịch trực. Nếu P3 vẫn kích hoạt page lúc 2 giờ sáng, bảng chỉ là lời hứa trên giấy. Cuối cùng, đừng vội thêm mức P5, P6 vì mỗi bên muốn một ngoại lệ, vì quá nhiều mức thì người trực mất thời gian chọn nhãn thay vì xử lý.

Biến bảng thành bằng chứng nghề nghiệp

Khi tin tuyển dụng FDE nhắc đến “on-call”, “incident response” hay “SLA”, đó là dịp tốt để hỏi lại trong buổi phỏng vấn: ai là người định nghĩa mức sự cố với khách, và định nghĩa ấy được viết ở đâu? Câu trả lời cho bạn thấy khá rõ những đêm trực của mình sẽ trông ra sao.

Trong CV, một dòng cụ thể có sức nặng hơn một tính từ: “Cùng khách xây dựng bảng P1-P4 dựa trên tỷ lệ người dùng bị ảnh hưởng, nối thẳng vào cấu hình paging.” Nếu có số liệu trước và sau về số lần bị gọi ngoài giờ, hãy đưa vào.

Khi phỏng vấn, kể lại một lần bạn hạ mức một sự cố và cách bạn giải thích với khách.

Bảng bốn dòng ấy không làm hệ thống ít lỗi đi. Nó chỉ bảo đảm rằng lần tới điện thoại rung lúc nửa đêm, đó là vì một chuyện thật sự đáng để bạn thức dậy.