# Viết cập nhật sự cố cho khách khi chưa rõ nguyên nhân: bốn giai đoạn, một người phụ trách

> Ở phút đầu, khách không đòi bạn biết hết; họ cần biết cái gì đang hỏng, ai đang giữ việc và khi nào sẽ có tin tiếp.

Bản gốc: https://fdetimes.net/vi/bach-khoa/cap-nhat-trang-thai-su-co-cho-khach-hang/

Đơn hàng của khách bỗng không sang được hệ thống kho. Bạn mới mở log được ba phút thì kênh chat chung đã hiện câu hỏi: "Có chuyện gì vậy, bao giờ xong?"

Lúc đó bạn chưa biết nguyên nhân, càng không biết giờ xong. Phản xạ thường gặp của kỹ sư là im lặng cho đến khi chắc chắn, hoặc đoán đại một con số để khách yên tâm. Cả hai đều nên tránh: im lặng khiến khách không có gì để báo cho đội của họ, còn con số đoán đại là lời hứa bạn chưa có căn cứ để giữ.

Nếu là FDE, có thể bạn còn vừa phải chữa lỗi, vừa là người khách nhắn trực tiếp, như trong tình huống này. Tin tốt là viết cập nhật giữa cơn cháy không cần văn hay. Nó cần một người phụ trách, bốn trạng thái và vài câu viết sẵn.

## Ai nói với khách khi cả đội đang chữa lỗi?

Sách SRE của Google tách hai vai rất rõ. Incident commander nắm trạng thái tổng thể của sự cố, còn người phụ trách liên lạc thay mặt cả đội nói chuyện với bên ngoài, với nhiệm vụ gửi cập nhật định kỳ cho đội và các bên liên quan, chứ không chỉ chờ trả lời câu hỏi.

Sự tách vai đó có lý do rất thực dụng. Theo PagerDuty, khi các bên liên quan được cập nhật chủ động, đội chính có thể tập trung vào việc xử lý. Khách không phải hỏi, còn người đang đọc log không phải dừng tay để trả lời.

Đội của bạn chỉ có hai người? Một người chữa, một người viết. Chỉ có một mình bạn ở chỗ khách thì hãy nhờ ngay một đồng nghiệp ở công ty giữ việc viết, hoặc ít nhất đặt đồng hồ báo giờ gửi để không quên.

Khi đổi người, đừng để việc bàn giao diễn ra ngầm. Google yêu cầu người chỉ huy sắp rời vị trí phải nói thẳng: "Giờ bạn là incident commander, được chứ?" Việc liên lạc với khách cũng nên làm đúng như vậy: nói thành lời, chờ người kia xác nhận, rồi báo cho khách tên người mới.

## Bốn từ cho khách biết sự cố đang ở đâu

Mẫu của incident.io dùng một dòng trạng thái với bốn giá trị: Investigating, Identified, Monitoring và Resolved. Bốn từ này giúp khách biết sự cố đã đi đến đâu mà không cần hiểu kiến trúc của bạn.

Investigating là biết có lỗi nhưng chưa rõ nguyên nhân. Identified là đã tìm ra điểm hỏng và đang sửa. Monitoring là đã áp dụng cách sửa và đang quan sát xem có giữ được không. Resolved là khách đã hết bị ảnh hưởng.

Mỗi bản cập nhật nên có cùng một bộ khung sáu dòng: trạng thái, ảnh hưởng, việc đang làm, việc khách cần làm, giờ cập nhật tiếp theo, người phụ trách. Cấu trúc này phỏng theo mẫu cập nhật nội bộ của incident.io, và như Statuspal khuyên, mỗi dòng chỉ ghi sự thật.

Statuspal cũng nói thẳng rằng không cần chờ xác định được vấn đề rồi mới báo. Bản đầu tiên chỉ cần xác nhận: đã thấy lỗi, nó ảnh hưởng đến phần nào, ai đang xử lý.

**Điểm mấu chốt:** Hứa giờ cập nhật tiếp theo, đừng hứa giờ hệ thống hồi phục.

OneUptime cảnh báo rằng tự nghĩ ra ETA là tạo một lời hứa đội không đủ căn cứ để giữ. Giờ cập nhật tiếp theo thì bạn giữ được, miễn là viết rõ đó không phải giờ xong.

Về nhịp gửi, incident.io đặt mức trần: không để quá một giờ không có cập nhật trong sự cố đang ảnh hưởng khách; khi khách đang đứng việc, hãy chọn nhịp ngắn hơn, ví dụ 30 phút.

## Một sự cố, sáu bản cập nhật

Thử hình dung một khách bán lẻ. Bạn đã triển khai cho họ một connector đẩy đơn từ cổng bán hàng sang kho. Lúc 14:05 đơn mới ngừng sang kho, và 14:12 bạn gửi bản đầu tiên.

> **Trạng thái:** Investigating (14:12)
>
> **Ảnh hưởng:** từ khoảng 14:05, đơn mới không sang được hệ thống kho; đơn đã vào kho trước đó không bị ảnh hưởng.
>
> **Đang làm:** kiểm tra connector, chưa rõ nguyên nhân.
>
> **Quý công ty cần làm:** chưa cần thao tác gì.
>
> **Cập nhật tiếp:** 14:40, sớm hơn nếu có thay đổi lớn.
>
> **Phụ trách:** [tên bạn]

Không có nguyên nhân, không có lời xin lỗi dài, nhưng người vận hành của khách đã biết đủ để báo cho đội kho. Đến 14:40, đúng giờ đã hẹn, bạn có thêm thông tin.

> **Trạng thái:** Identified (14:40)
>
> **Ảnh hưởng:** hệ thống kho từ chối xác thực từ 14:05; 340 đơn đang xếp hàng, chưa mất đơn nào.
>
> **Đang làm:** chuẩn bị chạy lại hàng đợi khi có khóa mới.
>
> **Quý công ty cần làm:** IT cấp khóa API mới; trong lúc chờ, kho có thể nhập tay đơn gấp.
>
> **Cập nhật tiếp:** 15:10.

Chưa có giờ hồi phục.
>
> **Phụ trách:** [tên bạn]

Rồi 14:55 bạn phát hiện đơn nhập tay sẽ bị đẩy sang kho lần nữa khi hàng đợi chạy lại. OneUptime khuyên đăng ngay khi ảnh hưởng lan rộng, cách xử lý tạm trở nên không an toàn hoặc đánh giá về hồi phục thay đổi đáng kể. Đừng chờ đến 15:10.

> **Trạng thái:** Identified (14:55)
>
> **Ảnh hưởng:** đơn nhập tay có thể bị tạo trùng khi đồng bộ chạy lại.
>
> **Đang làm:** chờ khóa mới, chuẩn bị loại các đơn này khỏi hàng đợi.
>
> **Quý công ty cần làm:** dừng nhập tay ngay và gửi danh sách đơn đã nhập.
>
> **Cập nhật tiếp:** 15:10.
>
> **Phụ trách:** [tên bạn]

Đến 15:10, khóa mới vừa về nhưng chưa áp dụng xong. Bạn vẫn gửi, vì đó là giờ đã hẹn với khách.

> **Trạng thái:** Identified (15:10)
>
> **Ảnh hưởng:** đơn mới vẫn xếp hàng, chưa sang kho.
>
> **Đang làm:** đã nhận khóa API mới và đang áp dụng.
>
> **Quý công ty cần làm:** gửi nốt danh sách đơn nhập tay nếu còn.
>
> **Cập nhật tiếp:** 15:20. Chưa có giờ hồi phục.
>
> **Phụ trách:** [tên bạn]

Mười phút sau, khóa đã vào và đồng bộ chạy lại.

> **Trạng thái:** Monitoring (15:20)
>
> **Ảnh hưởng:** đồng bộ đã chạy lại, nhưng còn đơn trong hàng đợi chưa sang kho.
>
> **Đang làm:** khóa mới đã áp dụng lúc 15:12; đang xử lý nốt hàng đợi, tiếp tục theo dõi và chưa đóng sự cố.
>
> **Quý công ty cần làm:** chưa cần thêm gì.
>
> **Cập nhật tiếp:** 15:50.
>
> **Phụ trách:** [tên bạn]

Lúc này bạn có thể muốn viết "đã fix xong". Đừng vội. Khóa đã thay, nhưng kho của khách vẫn thiếu đơn, nên với họ sự cố chưa hết.

> **Trạng thái:** Resolved (15:50)
>
> **Ảnh hưởng:** từ 14:05 đến 15:31, tức 86 phút; tổng 412 đơn sang kho chậm, không mất đơn, không đơn trùng.
>
> **Đang làm:** đồng bộ đã bình thường, đội kỹ thuật đang hoàn tất phân tích nguyên nhân và sẽ gửi quý công ty sau.
>
> **Quý công ty cần làm:** không có.
>
> **Phụ trách:** [tên bạn]

Statuspal yêu cầu bản đóng sự cố nêu khoảng thời gian ảnh hưởng với giờ bắt đầu và giờ kết thúc. Trong ví dụ này, giờ kết thúc là 15:31, lúc đơn cuối cùng vào kho, chứ không phải 15:12, lúc bạn thay khóa. Hãy tính theo đồng hồ của khách, không theo đồng hồ của deployment.

## Khi việc sửa nằm trong tay IT của khách, ai nói?

Đây là chỗ công việc của FDE khác một ca trực thông thường. Lúc 14:40 trong ví dụ trên, bạn đã tìm ra điểm hỏng nhưng không tự sửa được, vì khóa API do IT của khách cấp. Người vận hành vẫn nhắn cho bạn, vì bạn là người họ gặp hằng ngày.

Nếu trả lời "chắc IT làm nửa tiếng nữa", bạn vừa hứa thay một đội mà bạn không điều hành. Nếu IT cũng tự gửi tin riêng, người vận hành sẽ nhận hai phiên bản của cùng một sự cố.

Vì thế, hãy tìm ngay đầu mối IT và chốt một câu: "Tôi tiếp tục gửi bản cập nhật chung cho bên vận hành. Khi khóa xong, anh/chị báo tôi để tôi ghi đúng thông tin đó, được chứ?" Giống lúc bàn giao, hãy chờ họ xác nhận.

Khách muốn đội của họ tự phát tin thì bạn nhường, rồi chuyển sang cấp dữ kiện cho người đó. Ai giữ việc viết không quan trọng bằng việc chỉ có một người.

Dòng việc cần làm cũng phải ghi rõ ai giữ bước tiếp theo mà không đổ lỗi: "IT của quý công ty ([tên đầu mối]) đang cấp khóa; giờ hoàn thành do IT xác nhận." Câu đó cho người vận hành biết phải hỏi ai, và không biến bạn thành người bảo đảm cho tiến độ của đội khác.

## Dựng sẵn trước khi có cháy

Việc đầu tiên ở khách mới là hỏi: khi có sự cố, ai cần nghe tin, nghe ở kênh nào, và nếu phần hỏng thuộc về đội của họ thì ai gửi? Hãy thống nhất câu trả lời từ tuần triển khai đầu, cùng với người gửi chính và người dự phòng ở phía bạn.

Khi lỗi xảy ra, gửi ngay bản Investigating từ bộ khung sáu dòng. Ghi giờ cập nhật tiếp theo vào đồng hồ báo, và đến giờ thì gửi, kể cả khi nội dung chỉ là "chưa có gì mới, vẫn đang kiểm tra X". Trước mỗi lần bấm gửi, tự hỏi điều gì đã thay đổi với khách, chứ không phải điều gì đã thay đổi trong code.

Kỹ năng này cũng nên hiện ra trong hồ sơ của bạn. Khi đọc mô tả công việc FDE, hãy để ý các cụm như incident response hay customer-facing; khi phỏng vấn, kể một sự cố bằng dòng thời gian cập nhật cụ thể, thay vì câu chung chung "giao tiếp tốt".

## Những câu nên xóa trước khi bấm gửi

Phần lớn lỗi nằm trong vài câu quen tay, và cách sửa đều giống nhau: thay phỏng đoán bằng điều đã quan sát được.

| Câu dễ buột miệng | Câu nên gửi |
|---|---|
| Khoảng 30 phút nữa sẽ xong | Chưa có giờ hồi phục. Cập nhật tiếp lúc 15:00 |
| Chắc do bên kho đổi cấu hình | Hệ thống kho từ chối xác thực từ 14:05, đang tìm nguyên nhân |
| Hệ thống gặp một số trục trặc nhỏ | Đơn mới không sang kho, đơn cũ không bị ảnh hưởng |
| Đã fix xong rồi nhé | Đã bình thường lại, ảnh hưởng từ 14:05 đến 15:31 |

Có ba lỗi không nằm trong câu chữ. Một là để hai người cùng trả lời khách với hai phiên bản khác nhau. Hai là im lặng vì "chưa có gì để nói", trong khi đó chính là lúc khách lo nhất. Ba là viết "không mất dữ liệu" khi chưa kiểm tra; nếu chưa chắc, ghi "đang kiểm tra".

## Viết lại một sự cố cũ trong tuần này

Chọn một sự cố mà đội bạn đã xử lý và mở lại dòng thời gian. Viết bốn bản cập nhật theo bộ khung, với điều kiện mỗi bản chỉ dùng những gì đội thực sự biết vào thời điểm đó, rồi đưa bản đầu tiên cho một đồng nghiệp không dính đến sự cố.

Nếu sau 30 giây họ nói được cái gì đang hỏng, ai đang giữ việc và khi nào có tin tiếp, bản đó đạt. Khi sự cố thật đến, bạn sẽ không phải học viết giữa lúc khách đang chờ.

**Thử ngay tuần này:**

- Lưu bộ khung sáu dòng (trạng thái, ảnh hưởng, việc đang làm, việc khách cần làm, giờ cập nhật tiếp theo, người phụ trách) thành snippet ở nơi bạn mở được trong vài giây.
- Với từng khách bạn đang phụ trách, ghi rõ ai sẽ gửi cập nhật, ai dự phòng và gửi qua kênh nào, rồi xác nhận với khách trước khi có sự cố.
- Thêm vào CV một dòng về sự cố bạn từng trực tiếp liên lạc với khách, kèm thời lượng ảnh hưởng và nhịp cập nhật đã giữ.

## Nguồn

- [Chapter 14 - Managing Incidents (Google SRE book)](https://sre.google/sre-book/incident-response/)

- [Is your incident communication hurting your MTTR? (Templates to fix it)](https://incident.io/blog/incident-communication-templates-for-mttr)

- [During Incident – Statuspal Incident Communication Handbook](https://docs.statuspal.io/incident-communication-handbook/during-incident)

- [How to Write Useful Incident Status Updates Without a Recovery ETA](https://oneuptime.com/blog/post/2026-09-29-status-updates-without-recovery-eta/view)

- [Communicate with Stakeholders – PagerDuty](https://docs.pagerduty.com/incident-management/communicate/communicate-with-stakeholders)