Claude cho Operations: Viết Runbook tự động

Tại sao runbook là tài sản quý giá của team Operations?

Khi sự cố xảy ra lúc 2 giờ sáng, người on-call không có thời gian để suy nghĩ — họ cần biết chính xác phải làm gì, từng bước một, không mập mờ. Một runbook tốt là sự khác biệt giữa incident được resolve trong 15 phút và incident kéo dài 3 tiếng vì không ai nhớ câu lệnh cụ thể cần chạy.

Nhiều team biết điều này nhưng vẫn không có runbook đầy đủ vì viết runbook tốt đòi hỏi thời gian và sự tỉ mỉ. Claude giúp bạn biến kiến thức tribal knowledge thành runbook có cấu trúc trong vài phút.

Nguyên tắc runbook tốt

• Painfully specific — "Chạy script" không phải là bước. "Chạy python sync.py --env prod --dry-run từ server ops1" mới là bước
• Bao gồm failure modes — Mỗi bước có thể fail, cần có "nếu bước này thất bại, làm gì tiếp"
• Test thực tế — Yêu cầu người chưa biết quy trình follow theo. Fix khi họ bị stuck
• Cập nhật sau mỗi lần dùng — Runbook cũ lạc hậu nguy hiểm hơn là không có runbook

Prompt tạo runbook từ mô tả

Tạo runbook cho quy trình: Database Failover
khi primary PostgreSQL instance bị lỗi.

Ngữ cảnh:
- Stack: PostgreSQL 15 trên AWS RDS, có read replica
- Công cụ: AWS Console, AWS CLI, psql
- On-call có quyền admin AWS

Các bước tôi biết (chưa có thứ tự cụ thể):
- Check health của primary và replica
- Promote replica lên primary
- Update DNS/connection string trong app
- Notify team về downtime
- Verify connections hoạt động
- Document incident

Hãy biến thành runbook đầy đủ với từng lệnh cụ thể,
expected output, và "nếu thất bại thì làm gì".

Cấu trúc runbook chuẩn

Claude sẽ tạo runbook theo cấu trúc:

Header

• Tên runbook và mục đích
• Owner: Team/người phụ trách
• Tần suất sử dụng: Daily/Weekly/As Needed/Emergency
• Ngày cập nhật cuối

Prerequisites (Điều kiện tiên quyết)

Tạo phần prerequisites cho runbook DB Failover:
- Quyền truy cập AWS IAM cần thiết
- Tools phải được cài sẵn (AWS CLI, psql version X)
- Thông tin cần có trước khi bắt đầu
  (endpoint addresses, credentials location, alert channel)

Các bước chi tiết với expected output

Đây là phần quan trọng nhất — mỗi bước phải cụ thể đến mức không cần đoán:

Bước 1: Xác nhận primary instance đang down

Chạy lệnh:
aws rds describe-db-instances   --db-instance-identifier prod-db-primary   --query 'DBInstances[0].DBInstanceStatus'

Expected output: "available"
Nếu output là "available": Primary vẫn hoạt động,
  kiểm tra lại alert — có thể là false alarm.
  Chạy bước diagnostic thay vì failover.
Nếu output là "failed" hoặc không kết nối được:
  Tiếp tục sang bước 2.

Runbook cho incident phổ biến

Runbook: Xử lý high CPU trên production server

Tạo runbook khi nhận alert "CPU > 90% trong 5 phút".

Infrastructure: 3 EC2 instances behind load balancer,
app viết bằng Node.js, database MySQL RDS.

Steps cần bao gồm:
1. Verify alert không phải false positive
2. Xác định nguyên nhân (query chậm, traffic spike, memory leak)
3. Short-term fix (restart process, scale up, kill query)
4. Rollback nếu vấn đề do deployment mới
5. Escalation criteria và contacts
6. Post-incident documentation

Runbook: Restore backup database

Tạo runbook restore database từ backup S3.
Environment: MySQL 8.0, backup daily lúc 2AM,
stored ở S3 bucket prod-db-backups.

Scenario: cần restore database dev từ backup production
(mask sensitive data trước khi restore).

Bao gồm:
- Tìm và download backup file đúng
- Restore vào instance dev
- Mask PII data (email, phone, CCCD)
- Verify data integrity sau restore
- Notify team khi hoàn thành

Incident Playbook

Incident playbook khác runbook thông thường ở chỗ bao gồm cả quy trình communication và escalation:

Tạo incident playbook cho P1 incident:
"Hệ thống payment không thể xử lý giao dịch"

Công ty: fintech, 100.000 transactions/ngày,
mỗi phút down = mất ~70 triệu VNĐ doanh thu.

Playbook cần bao gồm:

PHASE 1 - DETECTION (0-5 phút)
- Cách xác nhận đây là P1 thực sự
- Ai cần được notify ngay lập tức (PagerDuty roles)

PHASE 2 - INITIAL RESPONSE (5-30 phút)
- Incident commander là ai?
- War room setup (Slack channel, Zoom bridge)
- Triage: loại bỏ known issues trước

PHASE 3 - INVESTIGATION
- Checklist diagnostic theo từng component
- Escalation path khi không tìm ra root cause

PHASE 4 - RESOLUTION
- Fix options và trade-offs
- Communication to customers (cần không?)
- Rollback criteria

PHASE 5 - POST-INCIDENT
- Timeline: bao lâu sau khi resolve cần post-mortem?
- Template incident report
- Cách ngăn tái phát

Troubleshooting guide format

Tạo troubleshooting guide cho vấn đề phổ biến
nhất của hệ thống email delivery.

Format: symptom → likely cause → fix

Ít nhất 8 scenarios:
- Email gửi nhưng không đến inbox
- Bounce rate đột ngột tăng
- DKIM/SPF fail
- Rate limiting từ Gmail/Yahoo
- Attachment bị block
- Template rendering lỗi
- Unsubscribe link không hoạt động
- Email delay hơn 30 phút

Giữ runbook luôn cập nhật

Runbook không dùng đến thì cũng vô nghĩa. Sau mỗi lần sử dụng:

Tôi vừa sử dụng runbook DB Failover lần đầu trong production.
Ghi chú thực tế:
- Bước 3 mất 15 phút thay vì 5 phút vì cần chờ DNS propagate
- Bước 5 thiếu lệnh để verify connections từ app (không chỉ từ CLI)
- Tìm ra cần notify team Finance riêng vì họ có batch job chạy tối

Cập nhật runbook để phản ánh thực tế này.
Thêm phần History với ngày và ghi chú.

Runbook cho quy trình thường ngày

Runbook không chỉ cho emergency — các quy trình hàng ngày cũng cần được document:

Tạo runbook cho quy trình deploy code lên production hàng tuần:
- Thứ 4 hàng tuần, 7PM sau giờ cao điểm
- Stack: Docker containers trên Kubernetes
- Cần zero-downtime deployment
- Approval từ 1 senior engineer
- Rollback trong vòng 5 phút nếu error rate > 1%

Bước tiếp theo

Runbook tốt là đầu tư một lần, sử dụng nhiều lần. Cùng với process documentation và risk assessment, đây là ba trụ cột của operational excellence. Khám phá thêm:

Xem tất cả hướng dẫn ứng dụng Claude cho HR & Operations

Bài viết liên quan

• Claude cho Operations: Lập kế hoạch năng lực
• Claude cho Operations: Tài liệu hóa quy trình
• Claude cho Operations: Báo cáo tình hình hoạt động
• Claude cho HR: Onboarding nhân viên mới
• Claude Productivity: Bắt đầu ngày làm việc hiệu quả