Ứng phó sự cố: severity, comms, rollback

Lần đầu bạn bị page lúc 3 giờ sáng vì một sự cố production, ranh giới giữa một outage 30 phút và một outage 3 giờ thường nằm ở runbook. Không phải ở sự anh hùng của engineer, cũng không phải ở kinh nghiệm của team - mà ở chính cái tài liệu nói rõ phải check cái gì, gọi ai, và khi nào nên roll back. Chương này giới thiệu hình dạng của runbook và quy trình sự cố sử dụng nó.

Khi nào quy trình sự cố thật sự mang lại giá trị?

Có ba tín hiệu.

Production có user bên ngoài. Một tool nội bộ có thể tha thứ cho một outage kéo dài cả giờ; nhưng một service hướng khách hàng thì không.

On-call có nhiều hơn một người tham gia. Khi chỉ có một người vận hành duy nhất, họ có thể giữ ngữ cảnh trong đầu. Nhưng vừa đến lúc hai người chia rotation, một runbook viết ra bắt đầu trở thành thiết yếu.

Có cam kết SLA / SLO. Dù là cam kết hợp đồng hay nội bộ, việc vi phạm đều có chi phí đo được. Quy trình tồn tại để cho việc vi phạm hiếm xảy ra.

Nếu hệ chỉ phục vụ nội bộ, được dùng nhẹ, và bạn có thể fix ở tốc độ con người, thì một quy trình sự cố chính thức chỉ là gánh nặng.

Cái giá khi quy trình sự cố yếu là gì?

Có ba kiểu lỗi thường gặp.

Phục hồi kiểu anh hùng, không có học hỏi. Một engineer senior fix sự cố lúc 4 giờ sáng, sau đó không có post-mortem. Sáu tuần sau cùng sự cố ấy lại xảy ra, vì chẳng có gì thay đổi.

Mất tiếng comms. Engineer fix; chẳng ai cập nhật cho khách hàng. Khách rời đi trong sự im lặng đó.

Do dự khi rollback. "Sắp xong rồi" - và 30 phút biến thành 2 giờ. Trong khi đáng lẽ rollback chỉ tốn 5 phút.

Hình dạng ứng phó sự cố trông thế nào?

flowchart TB
    Page[Page nổ] --> Tri[Triage<br/>0-5 phút]
    Tri --> Sev{Severity?}
    Sev -->|P1| P1[Production down<br/>cả team page<br/>comms 30 phút]
    Sev -->|P2| P2[Xuống cấp<br/>on-call + lead<br/>comms giờ]
    Sev -->|P3| P3[Mỹ phẩm<br/>ticket backlog]
    P1 --> Decide{Fix trong 30 phút?}
    P2 --> Decide
    Decide -->|Có| Fix[Fix forward]
    Decide -->|Không| Roll[Roll back]
    Fix --> AllClear[Verify metric<br/>all clear]
    Roll --> AllClear
    AllClear --> Post[Post-mortem<br/>trong 48h]

P1 nghĩa là production down hoặc xuống cấp nghiêm trọng đối với khách hàng; P2 nghĩa là xuống cấp nhưng vẫn còn chạy được; P3 là sự cố nhỏ. Mức severity sẽ quyết định ai bị page, nhịp comms ra sao, và mức độ quyết liệt khi rollback.

Template runbook sự cố cụ thể là gì?

# Runbook Sự Cố — {{ Tên Service }}

## Định nghĩa severity
- **P1**: Service down HOẶC error rate > 5% HOẶC latency p99 > 5x
  baseline. Page mọi người. Cập nhật khách mỗi 30 phút.
- **P2**: Xuống cấp - error rate 0.5-5% HOẶC latency p99 2-5x
  baseline. Page on-call + lead. Cập nhật giờ.
- **P3**: Mỹ phẩm, một user, hay không chặn. Ticket; phản hồi
  trong 4 giờ giờ làm việc.

## Phản ứng on-call (5 phút đầu)
1. Acknowledge page
2. Mở channel sự cố: #incident-{{ timestamp }}
3. Mở dashboard: {{ link Grafana }}
4. Xác định severity từ định nghĩa trên
5. Nếu P1, page backup incident commander; kích comms lead

## Vai trò trong sự cố
- **Incident commander** (IC): chạy channel, ra quyết định
- **Comms lead**: viết cập nhật khách + stakeholder
- **Engineer**: điều tra và fix
- IC và comms lead KHÔNG phải cùng người

## Cây quyết định (check theo thứ tự)

- Deploy gần đây trong 6 giờ? -> Roll back deploy trước (5 phút)
- Query database chậm? -> Check pg_stat_activity; kill query dài
- Dependency ngoài lỗi? -> Check status page; kích fallback
- Cache stampede? -> Pre-warm key hot; xem chương cache

## Template báo stakeholder

**P1 hướng khách**: Chúng tôi nhận biết vấn đề ảnh hưởng
{{ tính năng }}. Team đang điều tra. Sẽ cập nhật trước
{{ thời gian + 30 phút }}.

**P1 nội bộ**: [P1] {{ Service }} - {{ dấu hiệu }} - IC:
{{ tên }} - Channel: #incident-{{ id }}

## Checklist sau all-clear

- Báo khách: đã giải quyết
- Channel sự cố: tóm tắt đăng
- Doc post-mortem tạo (link template)
- Slot lịch đặt review không đổ lỗi (trong 48h)

Phần hữu dụng nhất chính là cây quyết định. Vào lúc 3 giờ sáng, engineer on-call không nên phải tự bịa ra cách ứng phó

• họ chỉ nên đi theo cây đã có sẵn.

Ứng phó sự cố scale lên đa team ra sao?

flowchart TB
    Page[Page nổ] --> OnCall[On-call service<br/>P1 trong 5 phút]
    OnCall --> Multi{Chạm nhiều<br/>service?}
    Multi -->|Có| WarRoom[Mở war room<br/>page IC + comms]
    Multi -->|Không| Single[Một team xử]
    WarRoom --> Other1[On-call service khác<br/>vào channel]
    WarRoom --> Other2[Customer support<br/>vào channel]
    WarRoom --> Other3[Comms lead<br/>viết cập nhật khách]

War room là pattern dùng cho sự cố đa team: một channel Slack duy nhất, IC có thực quyền xuyên team, và on-call của mỗi team đều vào. Comms lead viết một bản cập nhật chung gửi tới mọi đối tượng (xem plan stakeholder để biết danh sách).

Quy trình có thể tự tạo ra những lỗi nào?

• Lạm phát severity. Mọi sự cố đều bị gán P1. Cách phòng: review hàng tuần các sự cố P1 - hồi tố downgrade nếu thực tế không đạt tiêu chí; theo dõi tỉ lệ lạm phát.
• IC kiểu anh hùng. Một người luôn được giao làm IC vì họ giỏi nhất. Cuối cùng họ burnout. Cách phòng: xoay vai IC; bắt engineer senior shadow 2 sự cố trước khi tự command.
• Stigma quanh rollback. Team né rollback vì sợ "trông tệ". Cách phòng: theo dõi time-to-recovery làm metric chủ đạo; thưởng cho rollback nào đánh bại fix forward về thời gian.
• Bỏ post-mortem. Sự cố được giải quyết vào tối thứ Sáu, PM đi nghỉ phép, và không ai viết post-mortem. Cách phòng: đưa doc post-mortem vào checklist all-clear, kèm owner cụ thể.

Khi nào quy trình sự cố chính thức là quá liều?

Có hai trường hợp.

Service do một engineer sở hữu. Một người sở hữu hệ, bị page, tự fix, rồi viết một tin nhắn Slack ngắn về chuyện đã xảy ra. Thêm runbook 5 trang vào tình huống này chỉ là gánh nặng.

Beta nội bộ. Một tính năng đứng sau flag chỉ-nội-bộ bị vỡ không phải là sự cố khách hàng. Cứ triage trong giờ làm việc.

Quy trình đầy đủ chỉ scale tương ứng với mức tác động tới khách hàng và quy mô team. Dưới ngưỡng đó, nhịp nhẹ vẫn chạy được.

Đi tiếp từ đây như thế nào?

Chương tiếp theo: retrospective và post-mortem

• artifact biến các sự cố và kết quả sprint thành bài học chung của team. Sau đó, các chương về con người và lãnh đạo (bắt đầu với 1-on-1) sẽ nói về những gì xảy ra giữa các sự cố.