Nâng caoHướng dẫnClaude ChatNguồn: Anthropic

Claude cho Engineering: Incident Response workflow

Nghe bài viết
00:00

Điểm nổi bật

Nhấn để đến mục tương ứng

  1. 1 Bước thực hành then chốt trong bốn phase của incident response: Phase 1: Triage Phân loại mức độ Ngay khi nhận alert, câu hỏi đầu tiên: severity là gì? Level Tiêu chí Response Time SEV1 Service down, toàn bộ users bị ảnh hưởng Ngay lập tức — nắm vững điều này giúp bạn triển khai nhanh hơn và giảm thiểu lỗi thường gặp.
  2. 2 Góc nhìn thực tế về prompt mẫu: bắt đầu incident mới: Tôi đang xử lý incident. Hãy giúp tôi triage và tạo incident document ban đầu. Thông tin: - Alert: "Payment service error rate 25%, threshold 1%" - Thời gian phát hiện: 02:15 SA - Stack: Node — hiệu quả phụ thuộc nhiều vào cách triển khai và ngữ cảnh sử dụng cụ thể.
  3. 3 Kết quả đo lường từ ví dụ status update claude tạo ra: ## Incident Update: Payment Service Degraded Severity: SEV2 | Status: Monitoring Impact: Khoảng 15% payment transactions bị lỗi Last Updated: 02 — các chỉ số cụ thể này giúp bạn đánh giá chính xác hiệu quả trước khi đầu tư nguồn lực.
  4. 4 Bước thực hành then chốt trong prompt mẫu: viết blameless postmortem: Incident đã được resolve. Hãy giúp tôi viết blameless postmortem. Incident summary: - Tên: Payment Service Degraded - 2026-03-20 - Duration: 02:15 - 03:30 SA 75 phút - Severity: SEV2 - Impact: 15% payment transactions fail — nắm vững điều này giúp bạn triển khai nhanh hơn và giảm thiểu lỗi thường gặp.
  5. 5 Góc nhìn thực tế về mẹo xử lý incident hiệu quả: Bắt đầu document ngay: Đừng chờ đủ thông tin. Update document liên tục khi biết thêm. Cập nhật có cấu trúc: What we know, what we've done, what's next. Không speculation. Postmortem blameless: Tập trung vào systems và processes — hiệu quả phụ thuộc nhiều vào cách triển khai và ngữ cảnh sử dụng cụ thể.
black and brown bee on brown wooden surface

Production down lúc 2 giờ sáng là tình huống mà không developer nào muốn gặp nhưng tất cả đều phải sẵn sàng xử lý. Sự khác biệt giữa incident được xử lý tốt và tệ không nằm ở việc có sự cố hay không — mà nằm ở quy trình: bạn có communicate rõ ràng không, có document timeline không, và quan trọng nhất, bạn có học được gì để ngăn tái diễn không. Claude có thể đồng hành cùng bạn trong suốt incident lifecycle — từ triage ban đầu đến blameless postmortem cuối cùng.

Bốn phase của Incident Response

Phase 1: Triage (Phân loại mức độ)

Ngay khi nhận alert, câu hỏi đầu tiên: severity là gì?

Level Tiêu chí Response Time
SEV1 Service down, toàn bộ users bị ảnh hưởng Ngay lập tức, all-hands
SEV2 Tính năng chính bị degraded, nhiều users Trong vòng 15 phút
SEV3 Tính năng phụ bị lỗi, một số users Trong vòng 1 giờ
SEV4 Cosmetic hoặc low-impact Next business day

Phase 2: Communicate (Thông báo)

Communication rõ ràng, đúng lúc là yếu tố phân biệt team SRE chuyên nghiệp. Cần cập nhật thường xuyên dù chưa có resolution.

Phase 3: Mitigate (Xử lý)

Document mọi action đã thực hiện và timeline events. Không phụ thuộc vào memory — viết real-time.

Phase 4: Postmortem (Phân tích sau sự cố)

Blameless postmortem: tập trung vào hệ thống và quy trình, không đổ lỗi cá nhân.

Prompt mẫu: Bắt đầu incident mới

Tôi đang xử lý incident. Hãy giúp tôi triage và
tạo incident document ban đầu.

Thông tin:
- Alert: "Payment service error rate 25%, threshold 1%"
- Thời gian phát hiện: 02:15 SA
- Stack: Node.js payment service, Stripe integration
- Monitoring: Datadog alert kích hoạt
- Ảnh hưởng ban đầu: Không rõ, đang kiểm tra

Hãy:
1. Suggest severity level và justify
2. Tạo incident document ban đầu
3. List 5 câu hỏi đầu tiên cần trả lời ngay

Prompt mẫu: Update status mid-incident

Cần viết status update cho incident đang xảy ra.

Incident: Payment service degraded
Severity: SEV2
Đã xảy ra từ: 02:15 SA (45 phút trước)
Timeline đã biết:
- 02:15: Alert kích hoạt
- 02:20: Incident Commander paged
- 02:30: Xác định root cause: third-party API timeout
- 02:45: Mitigation: switch sang backup payment provider
- 02:58: Error rate giảm xuống 3%, đang theo dõi

Hãy viết:
1. Internal Slack update cho team
2. External status page update cho customers
(Tone: factual, không speculation, reassuring)

Ví dụ status update Claude tạo ra

## Incident Update: Payment Service Degraded
Severity: SEV2 | Status: Monitoring
Impact: Khoảng 15% payment transactions bị lỗi
Last Updated: 02:58 SA

### Tình trạng hiện tại
Chúng tôi đã xác định nguyên nhân và đang trong quá
trình phục hồi. Error rate đã giảm từ 25% xuống 3%.

### Hành động đã thực hiện
- 02:30: Xác định root cause: timeout từ provider X
- 02:45: Kích hoạt backup payment provider
- 02:55: Verify transactions đang được xử lý bình thường

### Bước tiếp theo
- Tiếp tục monitor 30 phút
- Nếu ổn định, resolve incident và bắt đầu postmortem

### Timeline
| Thời gian | Sự kiện |
|-----------|---------|
| 02:15 SA  | Alert kích hoạt |
| 02:20 SA  | IC on-call được paged |
| 02:30 SA  | Root cause identified |
| 02:45 SA  | Mitigation applied |
| 02:58 SA  | Update này |

Prompt mẫu: Viết blameless postmortem

Incident đã được resolve. Hãy giúp tôi viết
blameless postmortem.

Incident summary:
- Tên: Payment Service Degraded - 2026-03-20
- Duration: 02:15 - 03:30 SA (75 phút)
- Severity: SEV2
- Impact: 15% payment transactions fail, ~500 users bị ảnh hưởng

Timeline:
- 02:15: Datadog alert payment error rate 25%
- 02:20: On-call Minh được paged
- 02:30: Confirmed root cause: Stripe timeout >30s
  do Stripe có incident riêng ở US region
- 02:45: Switch sang backup provider VNPay
- 02:58: Error rate giảm xuống 3%
- 03:30: Fully resolved, Stripe recovered

Root cause: Upstream dependency (Stripe) incident
ảnh hưởng đến API calls của chúng tôi.

Không có circuit breaker, nên requests bị queue
cho đến khi timeout. Không có fallback tự động.

Hãy viết postmortem đầy đủ với 5 Whys analysis
và action items cụ thể.

Ví dụ postmortem Claude tạo ra

## Postmortem: Payment Service Degraded
Date: 2026-03-20 | Duration: 75 phút | Severity: SEV2
Authors: Minh Nguyen | Status: Draft

### Summary
Lúc 02:15 SA ngày 20/3/2026, payment service
bắt đầu timeout do upstream incident từ Stripe.
Do thiếu circuit breaker và automatic fallback,
khoảng 15% transactions bị fail trong 75 phút
trước khi team switch thủ công sang VNPay backup.

### Impact
- ~500 users không checkout được trong 75 phút
- Estimated revenue impact: ~50 triệu VND
- Không có data loss

### 5 Whys
1. Tại sao payment fail? -> Stripe API timeout
2. Tại sao Stripe timeout gây outage? -> Không có circuit breaker
3. Tại sao không có circuit breaker? -> Chưa được implement
4. Tại sao chưa implement? -> Không có trong technical roadmap
5. Tại sao không có trong roadmap? -> Chưa có incident cần thiết trước đây

Root cause: Thiếu resilience pattern (circuit breaker + fallback)
cho external payment dependency.

### Điều làm tốt
- Alert phát hiện nhanh (2 phút từ khi degraded)
- Team on-call response time tốt
- Communication internal rõ ràng

### Điều cần cải thiện
- Không có automatic fallback sang backup provider
- Detection time vs mitigation time quá dài (30 phút)
- Chưa có runbook cho payment provider failure

### Action Items
| Action | Owner | Priority | Deadline |
|--------|-------|----------|----------|
| Implement circuit breaker cho Stripe | Nam | P0 | 1 tuần |
| Auto-failover sang VNPay khi Stripe down | Hoa | P0 | 2 tuần |
| Viết runbook payment provider failure | Minh | P1 | 1 tuần |
| Load test với Stripe bị timeout | DevOps | P1 | 3 tuần |

Mẹo xử lý incident hiệu quả

  • Bắt đầu document ngay: Đừng chờ đủ thông tin. Update document liên tục khi biết thêm.
  • Cập nhật có cấu trúc: What we know, what we've done, what's next. Không speculation.
  • Postmortem blameless: Tập trung vào systems và processes. "Hệ thống thiếu circuit breaker" không phải "Minh quên implement".
  • Action items có owner: Mỗi action item phải có người chịu trách nhiệm và deadline cụ thể.

Bước tiếp theo

Incident response tốt là nền tảng của SRE mature:


Bài viết liên quan

Tính năng liên quan:Incident ResponseRoot Cause AnalysisPostmortem

Bai viet co huu ich khong?

Bản quyền thuộc về tác giả. Vui lòng dẫn nguồn khi chia sẻ.

Bình luận (0)
Ảnh đại diện
Đăng nhập để bình luận...
Đăng nhập để bình luận
  • Đang tải bình luận...

Đăng ký nhận bản tin

Nhận bài viết hay nhất về sản phẩm và vận hành, gửi thẳng vào hộp thư của bạn.

Bảo mật thông tin. Hủy đăng ký bất cứ lúc nào. Chính sách bảo mật.