My Awesome Project

Appearance

Chapter 54: Incident Response & Post-Mortems ​

Tại sao chapter này khác Chapter 42 và Chapter 53? ​

Đây là câu hỏi đầu tiên cần trả lời, vì cả ba chapter đều chạm vào "incident response" và "postmortem" — nếu không phân định rõ, người đọc sẽ cảm giác đang đọc lại cùng một nội dung ba lần.

Chapter 42 — SRE Practices giới thiệu incident response như một phần của bức tranh SRE lớn hơn: SLO, error budget, resilience patterns, chaos engineering. Phần incident response ở đó (file 03, 04) chỉ là giới thiệu nhanh về levels/roles và khái niệm blameless — đủ để biết nó tồn tại, chưa đủ để vận hành nó dưới áp lực thật.

Chapter 53 — Production GKE Debugging Framework đi sâu vào cơ chế kỹ thuật của việc tìm ra cái gì đang sai trong một cụm GKE cụ thể: pod nào crash, packet nào bị drop, node nào bị pressure. Phần cuối chapter đó (Five Whys, fishbone) là kỹ thuật phân tích nguyên nhân ở mức factual, technical.

Chapter 54 đứng ở một tầng khác: đây là cơ chế vận hành tổ chức (operational machinery) bao trùm toàn bộ vòng đời một incident — từ giây phút alert đầu tiên nổ ra cho đến khi action item cuối cùng trong postmortem được đóng. Nó trả lời những câu hỏi mà kỹ thuật thuần túy không trả lời được:

  • Ai có quyền quyết định trong incident, và quyền đó lấy từ đâu?
  • Vì sao "dừng chảy máu" (mitigate) phải tách rời khỏi "sửa tận gốc" (resolve), và tách rời như thế nào về mặt cơ chế?
  • Rollback, feature flag, circuit breaker — chúng hoạt động khác nhau ở tầng nào, và vì sao chọn cái này thay vì cái kia sẽ thay đổi hoàn toàn blast radius?
  • Một bản postmortem thực sự thay đổi hành vi tổ chức được cấu trúc như thế nào, và vì sao 90% postmortem viết ra không có tác dụng gì?

Nói cách khác: Chapter 42 cho bạn biết "có những khái niệm này". Chapter 53 cho bạn biết "làm sao tìm ra root cause kỹ thuật trong GKE". Chapter 54 cho bạn biết "làm sao vận hành toàn bộ quy trình incident như một cỗ máy có thiết kế, có chủ đích, và có thể lặp lại được ở scale" — dựa trên incident command model mà Google tự vận hành nội bộ và mô tả trong SRE Book.

Điều kiện tiên quyết ​

Folder Structure ​

chapter-54-incident-response-postmortems/
├── index.md                                                      ← File này
├── 01-severity-classification-incident-command-system.md         ← Severity levels + IC/Ops/Comms/Planning Lead
├── 02-incident-lifecycle-detection-triage-mitigation-resolution.md ← State machine của một incident
├── 03-mitigation-engineering-rollback-featureflag-circuitbreaker.md ← Cơ chế kỹ thuật của mitigation
├── 04-incident-communication-stakeholder-management.md            ← Comms Lead, status page, update cadence
├── 05-blameless-postmortem-timeline-root-cause-analysis.md        ← Văn hoá blameless + cấu trúc document
└── 06-action-item-governance-knowledge-sharing.md                 ← Đóng vòng lặp học hỏi

Các file trong chapter ​

1. Phân Loại Severity & Incident Command System ​

Severity không phải nhãn mô tả — nó là cơ chế kích hoạt quyết định bao nhiêu người bị kéo vào, ai có quyền gì, và tốc độ escalation. Internal model của Incident Command System (ICS) mà Google áp dụng cho incident kỹ thuật: bốn vai trò Incident Commander, Operations Lead, Communications Lead, Planning Lead — vai trò nào làm gì, vì sao chúng phải tách biệt nhau (đặc biệt là tách IC khỏi người trực tiếp sửa hệ thống), live incident document như bộ nhớ dùng chung, và cơ chế handoff khi đổi ca.

2. Vòng Đời Incident: Detection → Triage → Mitigation → Resolution ​

Mô hình hoá incident như một state machine với entry/exit criteria rõ ràng cho từng trạng thái. Vì sao alert phải dựa trên triệu chứng (symptom-based) chứ không phải nguyên nhân nội bộ. Funnel triage thực dụng bằng bộ ba Cloud Monitoring (impact) → Cloud Logging (nguyên nhân) → Cloud Trace/Error Reporting (điểm lỗi chính xác) — và vì sao thứ tự này không phải ngẫu nhiên. Nguyên tắc cốt lõi của SRE Workbook: không bao giờ trì hoãn mitigation để chờ root-cause analysis đầy đủ.

3. Mitigation Engineering: Rollback, Feature Flag, Circuit Breaker ​

Ba cơ chế giảm blast radius nhanh nhất, và vì sao chúng hoạt động ở ba tầng hoàn toàn khác nhau: rollback (Cloud Deploy, Cloud Run revisions, kubectl rollout undo) hoạt động ở tầng deployment artifact; feature flag (kill switch, Firebase Remote Config rollout) hoạt động ở tầng runtime configuration, tách rời deploy khỏi release; circuit breaker (outlier detection trong Cloud Service Mesh) hoạt động ở tầng network call giữa các service, tự động, không cần con người can thiệp. Trade-off ẩn: mitigation nhanh có thể che khuất tín hiệu cần cho root cause analysis nếu không được ghi log lại.

4. Incident Communication: Status Page & Stakeholder Management ​

Cơ chế giao tiếp trong incident tách thành hai kênh với mục tiêu khác nhau: kênh nội bộ (live doc, chatops channel) tối ưu cho tốc độ và độ chính xác kỹ thuật; kênh bên ngoài (status page) tối ưu cho lòng tin và kỳ vọng. Dùng chính mô hình Personalized Service Health / Cloud Service Health của Google Cloud làm case study cho cadence và cấu trúc update. Vì sao im lặng trong incident gây hoảng loạn hơn cả tin xấu.

5. Blameless Postmortem: Timeline Reconstruction & Root Cause Analysis ​

Blameless không phải là thái độ đạo đức, mà là một cơ chế thu thập thông tin trung thực — giả định "mọi người đều làm điều đúng với thông tin họ có tại thời điểm đó" để loại bỏ động lực che giấu. Cấu trúc năm bước của một postmortem theo Google Cloud Architecture Framework: create → capture facts → analyze root cause → plan → execute. Timeline reconstruction ở tầng tổ chức (khác với cross-layer correlation kỹ thuật ở Chapter 53) — kết hợp system events với quyết định con người. Tiêu chí khi nào một incident bắt buộc phải có postmortem.

6. Action Item Governance & Knowledge Sharing ​

Một postmortem không tạo ra giá trị — action item được thực thi mới tạo ra giá trị. Cơ chế khiến action item không "chết" trong backlog: ownership, severity-linked priority, tracking qua issue tracker thay vì document tĩnh. Knowledge sharing như một hệ thống: incident readout, runbook như living document, review gate trước khi publish rộng, và vì sao "học được bao nhiêu người" mới là thước đo giá trị thật của một postmortem.

Learning Path ​

01 (ai có quyền, incident được tổ chức thế nào)
  → 02 (incident vận hành qua các trạng thái nào)
  → 03 (công cụ kỹ thuật để thoát khỏi trạng thái mitigation)
  → 04 (giao tiếp trong lúc incident đang chạy)
  → 05 (sau khi incident đóng: viết lại sự thật, tìm root cause)
  → 06 (biến bài học thành thay đổi thật, không chỉ là tài liệu)

File 01–02 là nền tảng tư duy về cấu trúc và vòng đời. Files 03–04 là kỹ năng vận hành trong lúc incident đang "nóng". Files 05–06 là phần hậu-incident — thường bị xem nhẹ nhất nhưng quyết định liệu tổ chức có thực sự tránh lặp lại lỗi hay không.

References ​