Sự cố production tại khách hàng: phân vai trước, sửa sau, viết postmortem để không lặp lại

Thử hình dung: 9 giờ tối, kênh chat chung với khách hàng bỗng dồn dập tin nhắn. Job đồng bộ dữ liệu bạn deploy tuần trước đang ghi đè đơn hàng. Ba người bên khách hàng hỏi cùng lúc, một kỹ sư của họ đã tự vào server “thử restart”, còn bạn đang mở log trong khi trả lời điện thoại.

Ở khoảnh khắc đó, viết code giỏi chưa đủ để cứu tình hình. Thứ quyết định là bạn có biết điều phối hay không: ai được chạm vào hệ thống, ai nói chuyện với khách hàng, ai ghi lại chuyện đã xảy ra.

Với một FDE, sự cố hiếm khi xảy ra “trong nhà”. Bạn đứng giữa hai tổ chức, hai nhóm kỹ sư và hai bộ quy trình. Cách bạn xử lý giờ đầu tiên và bản postmortem viết sau đó sẽ quyết định khách hàng còn tin bạn đến mức nào.

Vì sao nên tuyên bố sự cố sớm?

Sách SRE của Google khuyên nên tuyên bố sự cố sớm, đừng đợi đến khi vấn đề đã phình to sau vài giờ. Bản năng của kỹ sư thường ngược lại: muốn tự sửa cho xong rồi mới báo, vì sợ làm to chuyện.

Tại khách hàng, cái giá của việc báo muộn còn cao hơn. Nếu khách tự phát hiện trước bạn, họ sẽ tự hành động theo cách của họ, và câu chuyện lúc này đã thành “nhà cung cấp giấu lỗi”. Tuyên bố sớm rồi hạ mức sau vẫn rẻ hơn nhiều so với tuyên bố muộn.

Tuyên bố ở đây không cần nghi lễ gì. Chỉ cần một tin nhắn rõ ràng trong kênh chung:

[SỰ CỐ] Job đồng bộ đơn hàng đang ghi đè bản ghi từ 20:50.
Tác động: một phần đơn hàng hôm nay có thể bị sai trạng thái.
Chỉ huy: Minh (FDE). Mọi thay đổi hệ thống đi qua Minh.
Cập nhật kế tiếp: 21:30, hoặc sớm hơn nếu có tiến triển.

Dòng thứ ba là dòng quan trọng nhất, vì nó chặn ngay tình trạng mỗi người tự sửa một kiểu.

Bốn chiếc mũ, kể cả khi chỉ có hai người

PagerDuty mô tả Incident Commander là nơi duy nhất nắm thông tin chính xác về những gì đang diễn ra. Google bổ sung một nguyên tắc cứng: trong lúc sự cố đang diễn ra, chỉ nhóm vận hành được thay đổi hệ thống, còn người chỉ huy giữ bức tranh tổng thể.

Hai vai còn lại hay bị quên. PagerDuty định nghĩa Scribe là người ghi timeline trong lúc sự cố diễn ra, và người liên lạc khách hàng là người trực tiếp trao đổi với khách. Sách của Google gọi vai tương tự là trưởng nhóm truyền thông, người đại diện phát ngôn cho cả đội ứng cứu.

Với sự cố nhỏ, PagerDuty cho phép một người gộp nhiều vai. Thực tế ở khách hàng, FDE thường kiêm chỉ huy kiêm liên lạc. Điều cần tránh là để vai nào đó không có ai giữ.

Vai	Ai giữ trong ví dụ	Việc chính	Không làm
Incident Commander	FDE	Quyết định, giữ trạng thái chung	Tự gõ lệnh sửa
Vận hành	Một kỹ sư được chỉ định	Thực hiện thay đổi đã thống nhất	Thử nghiệm ngoài kế hoạch
Scribe	Đồng nghiệp hoặc chính FDE	Ghi timeline có giờ phút	Phân tích nguyên nhân giữa chừng
Liên lạc khách hàng	FDE hoặc account lead	Cập nhật đúng giờ đã hứa	Hứa thời điểm khắc phục

Với kỹ sư bên khách hàng, đây là phần khó nói nhất. Bạn không có quyền ra lệnh cho họ, nhưng có thể đề nghị thẳng: “Anh giữ vai vận hành nhé, mọi lệnh mình thống nhất trong kênh này trước khi chạy.” Thường họ sẽ nhẹ nhõm vì có người cầm lái.

Giờ đầu tiên, nhìn qua timeline

Tiếp tục ví dụ giả định trên, timeline mà Scribe ghi lại có thể trông như sau. Hãy để ý mỗi dòng chỉ ghi sự kiện, không ghi lời phán xét.

20:50  Job đồng bộ chạy theo lịch. 21:04  Khách báo trạng thái đơn hàng sai. 21:07  Minh tuyên bố sự cố, chỉ định vai. 21:12  Vận hành tạm tắt job đồng bộ bằng cờ cấu hình. 21:20  Xác nhận không còn ghi đè mới. 21:30  Cập nhật khách: đã chặn lan rộng, đang đánh giá phạm vi dữ liệu.

22:15  Xác định nguyên nhân: thay đổi mapping khóa trong bản deploy gần nhất. ```

Thứ tự ở đây có chủ đích: chặn thiệt hại trước, tìm nguyên nhân sau. Lúc 21:12 chưa ai biết vì sao job hỏng, nhưng tắt nó đi đã đủ để dữ liệu ngừng bị ghi sai.

Nếu sự cố kéo sang ngày hôm sau, Google nhấn mạnh rằng vị trí chỉ huy phải được bàn giao rõ ràng vào cuối ngày làm việc. Một câu như "Từ 8 giờ sáng, Lan là chỉ huy, timeline ở link này" sẽ tránh được cảnh hai người cùng tưởng mình đang cầm lái, hoặc không ai cầm cả.

## Postmortem: sửa hệ thống, không sửa con người

Google định nghĩa postmortem là bản ghi chép về sự cố, tác động của nó và những hành động đã làm để giảm thiểu hoặc khắc phục. Lý do phải viết rất đơn giản: theo sách SRE, nếu không có quy trình chính thức để học từ sự cố, chúng có thể lặp lại mãi mãi.

Khi nào bắt buộc phải viết? Google khuyên đặt tiêu chí kích hoạt từ trước, và một ví dụ là mất dữ liệu dưới bất kỳ hình thức nào. Ví dụ đơn hàng bị ghi đè ở trên rơi thẳng vào tiêu chí này, nên không ai phải tranh luận có nên viết hay không.

Tinh thần của bản viết là blameless. Sách SRE viết rằng bạn không thể "sửa" con người, nhưng có thể sửa hệ thống và quy trình để hỗ trợ con người tốt hơn. Câu "Minh deploy sai mapping" không dạy được gì. Câu "pipeline deploy không kiểm tra mapping khóa trên dữ liệu thật" thì chỉ ra được việc cần làm.

<KeyPoint>Một postmortem tốt kết thúc bằng thay đổi trong hệ thống, không kết thúc bằng tên một người.</KeyPoint>

Postmortem công khai của Cloudflare về sự cố ngày 18/11/2025 là một mẫu đáng học. Bài mở đầu bằng lời xin lỗi trực tiếp từ lãnh đạo: thay mặt toàn đội, họ xin lỗi vì những thiệt hại đã gây ra cho Internet hôm đó. Nguyên nhân kích hoạt được nêu thẳng: một thay đổi quyền trên một hệ thống database.

Danh sách khắc phục cũng cụ thể, trong đó có việc bổ sung thêm global kill switch cho các tính năng.

Chi tiết kill switch đáng để FDE ghi nhớ. Trong ví dụ của bài, bước 21:12 chỉ nhanh được vì job có sẵn cờ tắt. Nếu không có, đó chính là hạng mục đầu tiên nên xuất hiện trong phần hành động của postmortem.

Một bản postmortem gửi khách hàng có thể chỉ dài một trang: tóm tắt và lời xin lỗi, tác động (bao nhiêu bản ghi, trong khoảng thời gian nào), timeline, nguyên nhân kích hoạt, những gì đã làm để khắc phục, và các hạng mục phòng ngừa, mỗi hạng mục có người phụ trách cùng hạn chót.

Một bài tập nhỏ để luyện phản xạ blameless: lấy câu "kỹ sư của khách tự vào server restart" trong tình huống mở đầu và viết lại thành một khiếm khuyết của hệ thống.

Gợi ý: hãy hỏi điều gì đã khiến hành động đó trở nên khả thi và có vẻ hợp lý lúc ấy, chẳng hạn chưa có kênh thống nhất lệnh hay chưa ai được chỉ định vai vận hành. Câu trả lời của bạn chính là một hạng mục phòng ngừa.

## Khách hàng chưa từng viết postmortem thì sao?

Đây là tình huống phổ biến. Sổ tay SRE Workbook của Google thừa nhận rằng đưa postmortem vào một tổ chức là thay đổi văn hóa không kém gì thay đổi kỹ thuật. Lời khuyên của họ là bắt đầu nhỏ với một quy trình thật cơ bản, rồi điều chỉnh dần cho hợp với tổ chức.

Với FDE, bắt đầu nhỏ có nghĩa là tự viết bản đầu tiên, mời khách đọc và góp ý, thay vì đề xuất cả một quy trình mới. Khi khách thấy bản viết không đổ lỗi cho ai mà lại sinh ra việc cụ thể, lần sau họ sẽ chủ động hỏi bạn có viết không.

## Những lỗi hay gặp

Lỗi thường gặp nhất là để nhiều người cùng sửa. Kỹ sư của khách restart dịch vụ trong lúc bạn đang rollback, và lúc này không ai còn biết thay đổi nào có tác dụng. Lỗi thứ hai là không có Scribe: đến khi viết postmortem, cả đội phải ngồi dựng lại timeline từ trí nhớ và lịch sử chat.

Lỗi thứ ba nằm ở khâu giao tiếp: hứa giờ khắc phục khi chưa biết nguyên nhân. Chỉ nên hứa giờ cập nhật kế tiếp, rồi giữ đúng lời hứa đó. Lỗi cuối cùng là viết postmortem xong rồi cất đi, không gắn hạng mục nào với người phụ trách, nên sự cố cũ lại quay về đúng như sách SRE đã cảnh báo.

Nếu đang nhắm tới vai trò FDE, bạn nên đọc kỹ những JD có nhắc đến on-call, incident response hay làm việc trực tiếp với hạ tầng khách hàng. Trong CV, đừng chỉ viết "xử lý sự cố production". Hãy viết rõ bạn đã chỉ huy sự cố, chặn thiệt hại trong bao lâu, viết postmortem và hạng mục phòng ngừa nào đã được triển khai.

Nhà tuyển dụng cần thấy bạn biết điều phối, chứ không chỉ biết đọc log.

Sự cố nào rồi cũng sẽ xảy ra với hệ thống bạn deploy. Điều khách hàng còn nhớ sau đó là ai đã cầm lái lúc 9 giờ tối và tài liệu nào đã khiến lỗi ấy không xảy ra lần thứ hai.

<TryThisWeek>
  <ul>
    <li>Soạn sẵn mẫu tin tuyên bố sự cố bốn dòng (chuyện gì, tác động, ai chỉ huy, giờ cập nhật kế tiếp) và lưu vào kênh chung với khách hàng.</li>
    <li>Cùng khách hàng thống nhất danh sách tiêu chí bắt buộc viết postmortem, bắt đầu bằng 'mất dữ liệu dưới mọi hình thức'.</li>
    <li>Chọn một sự cố cũ của chính bạn và viết lại thành postmortem một trang theo cấu trúc trong bài.</li>
  </ul>
</TryThisWeek>