Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng lúc 2 giờ sáng, hệ thống thanh toán của bạn ngừng hoạt động. Người trực on-call đêm đó là một bạn kỹ sư mới onboard được ba tuần, chưa từng đụng vào service này. Bạn đó mở laptop, dụi mắt, và câu hỏi đầu tiên hiện ra trong đầu là: "Giờ mình phải làm gì?"
Có hai kịch bản. Kịch bản một: bạn đó lục lọi Slack, hỏi vọng vào không trung, gọi điện đánh thức ba người, và 45 phút sau mới bắt đầu hiểu chuyện gì đang xảy ra. Kịch bản hai: bạn đó mở một tài liệu tên là "Runbook: Payment Service Down", đọc từng bước, chạy đúng ba lệnh được ghi sẵn, và hệ thống phục hồi sau 8 phút — mà không cần đánh thức ai cả.
Sự khác biệt giữa hai kịch bản đó chính là process documentation — tài liệu quy trình vận hành. Khi team còn 5 người, mọi thứ nằm trong đầu vài người "biết tuốt". Nhưng khi team scale lên 50, 100, 200 người, kiến thức nằm trong đầu không còn là tài sản — nó trở thành rủi ro tổ chức. Người biết đi nghỉ phép, nghỉ việc, hoặc đơn giản là quên. Kiến thức ngầm (tacit knowledge) không scale được; chỉ kiến thức đã được viết ra (explicit knowledge) mới scale.
Bài này tập trung vào hai loại tài liệu vận hành cốt lõi mà bất kỳ tổ chức đang scale nào cũng phải làm chủ: Runbook và Playbook. Đây không phải chủ đề "sang chảnh" như chiến lược hay văn hóa, nhưng nó là thứ giữ cho tổ chức của bạn không sụp đổ vào lúc 2 giờ sáng.
Khái niệm cốt lõi
Runbook là gì
Runbook là tài liệu hướng dẫn từng-bước-một (step-by-step) để xử lý MỘT tác vụ vận hành cụ thể, xác định. Từ "runbook" xuất phát từ thời máy tính mainframe, khi các operator có một cuốn sổ ghi chính xác trình tự thao tác để "chạy" hệ thống.
Đặc điểm của một runbook tốt:
- Cụ thể và hẹp: giải quyết đúng một tình huống. Ví dụ "Khôi phục database từ bản backup gần nhất", "Xoay vòng SSL certificate sắp hết hạn", "Restart cụm Redis khi memory vượt 90%".
- Mang tính mệnh lệnh (imperative): viết dạng mệnh lệnh — "Chạy lệnh X", "Kiểm tra dashboard Y", "Nếu thấy lỗi Z thì làm bước tiếp theo". Người đọc không cần suy nghĩ, chỉ cần làm theo.
- Deterministic — kết quả xác định: nếu làm đúng các bước, bạn luôn ra cùng một kết quả.
- Ai cũng chạy được: mục tiêu vàng là một người chưa có ngữ cảnh (ví dụ kỹ sư on-call mới) vẫn thực thi được mà không cần hỏi ai.
Playbook là gì
Playbook là tài liệu chiến lược, rộng hơn, dành cho MỘT LOẠI tình huống chứ không phải một tác vụ đơn lẻ. Từ này mượn từ thể thao Mỹ (bóng bầu dục), nơi huấn luyện viên có một cuốn "playbook" chứa các chiến thuật để chọn tùy theo tình hình trận đấu.
Đặc điểm của playbook:
- Rộng và mang tính tình huống (situational): bao trùm cả một nhóm sự cố hoặc quyết định. Ví dụ "Playbook xử lý sự cố Sev-1", "Playbook ứng phó rò rỉ dữ liệu", "Playbook launch sản phẩm mới ra thị trường".
- Có yếu tố phán đoán (judgment): playbook không thể ghi cứng từng lệnh vì mỗi tình huống một khác. Thay vào đó nó cung cấp khung ra quyết định: ai làm vai trò gì, các nhánh xử lý, tiêu chí leo thang (escalation), cách giao tiếp.
- Định hướng vai trò và giao tiếp: playbook thường định nghĩa Incident Commander là ai, ai lo communication, khi nào thông báo cho khách hàng, khi nào gọi CEO.
- Có thể chứa nhiều runbook bên trong: một playbook thường trỏ tới các runbook cụ thể như những "công cụ" trong hộp đồ nghề.
So sánh nhanh để không nhầm lẫn
| Tiêu chí | Runbook | Playbook |
|---|---|---|
| Phạm vi | Một tác vụ cụ thể | Một loại/nhóm tình huống |
| Bản chất | Thao tác cơ khí, xác định | Chiến lược, cần phán đoán |
| Câu hỏi trả lời | Làm gì, theo bước nào | Tiếp cận thế nào, ai quyết |
| Người dùng điển hình | On-call engineer, operator | Incident Commander, team lead |
| Ví dụ | "Restart service thanh toán" | "Xử lý toàn bộ sự cố Sev-1" |
Vì sao cần cả hai, không phải một
Nhiều team mới scale hay mắc lỗi cực đoan: hoặc chỉ viết runbook chi li mà thiếu playbook (nên khi gặp sự cố ngoài kịch bản, cả team đứng hình vì không biết ai quyết); hoặc chỉ có playbook chiến lược đẹp đẽ nhưng không có runbook (nên đến lúc phải hành động cụ thể thì lại loay hoay). Một tổ chức vận hành trưởng thành cần playbook để điều phối và runbook để thực thi. Chúng bổ trợ nhau như bản đồ chiến dịch và cẩm nang thao tác.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT Việt Nam và runbook cứu đêm Flash Sale
Một sàn thương mại điện tử tầm trung ở TP.HCM (giả định tên "ShopNhanh", ~120 kỹ sư) từng gặp cảnh này mỗi mùa sale 11/11. Cứ đến giờ vàng 20h, lượng truy cập tăng gấp 15 lần, và database read-replica thường bị quá tải, latency vọt lên 8 giây. Trong hai năm đầu, mỗi lần như vậy team lại hoảng loạn: người mở dashboard, người đoán mò, người tự ý restart service khiến tình hình tệ hơn.
Sau mùa sale thứ hai thảm họa (downtime 40 phút, thiệt hại doanh thu ước tính hơn 2 tỷ đồng cho riêng khung giờ đó), team quyết định viết một runbook rất cụ thể: "Runbook: DB Read-Replica quá tải trong giờ cao điểm". Nó ghi chính xác: bước 1 kiểm tra metric replica_lag trên Grafana; bước 2 nếu lag > 5s thì kích hoạt read-replica dự phòng bằng đúng lệnh này; bước 3 bật feature flag degrade_recommendation để tắt tạm phần gợi ý sản phẩm tốn tài nguyên; bước 4 thông báo vào kênh #incident.
Mùa sale năm sau, khi sự cố tương tự xảy ra, kỹ sư on-call — một bạn mới vào 2 tháng — chỉ mất 6 phút để đưa hệ thống về ổn định, không cần đánh thức ai.
Bài học rút ra: Runbook phát huy giá trị lớn nhất với những sự cố lặp lại và dự đoán được. Nếu một loại sự cố xảy ra tới lần thứ hai, đó là tín hiệu bắt buộc phải viết runbook. Đừng để "trí nhớ của người senior" là điểm-đơn-lẻ-hỏng-hóc (single point of failure) của cả tổ chức.
Ví dụ 2 — Grab và playbook ứng phó sự cố khu vực
Ở quy mô lớn hơn, hãy hình dung một công ty như Grab vận hành across nhiều quốc gia Đông Nam Á. Khi một sự cố lớn xảy ra — chẳng hạn hệ thống định giá (pricing) tính sai giá cho hàng loạt chuyến ở Indonesia và Việt Nam cùng lúc — thì một runbook đơn lẻ là không đủ. Vấn đề ở đây không chỉ là "chạy lệnh gì", mà là "ai chỉ huy, giao tiếp với ai, quyết định hoàn tiền ra sao, khi nào thông báo cho cơ quan quản lý".
Đó là lúc Playbook Sev-1 (Incident Management) vào cuộc. Playbook này định nghĩa: ngay khi phát hiện, người đầu tiên trở thành Incident Commander (IC) cho tới khi bàn giao; IC không tự sửa code mà điều phối; một người được chỉ định làm Communications Lead để cập nhật status page và trả lời khách hàng; các nhánh quyết định như "nếu ảnh hưởng > 10.000 người dùng thì leo thang lên VP Engineering trong vòng 15 phút". Bên trong playbook có link tới các runbook cụ thể: "Rollback pricing service", "Kích hoạt hoàn tiền hàng loạt".
Kết quả là dù sự cố phức tạp và chưa từng gặp y hệt, team vẫn có một khung điều phối rõ ràng thay vì hỗn loạn. Vai trò được phân định, không ai giẫm chân ai.
Bài học rút ra: Playbook không cố ghi cứng mọi bước — vì tình huống lớn luôn có biến số mới. Giá trị của playbook nằm ở cấu trúc ra quyết định và phân vai, giúp con người phán đoán tốt hơn trong hỗn loạn, đồng thời trỏ tới runbook khi cần thao tác cụ thể.
Ví dụ 3 — Startup fintech và cái giá của việc KHÔNG có tài liệu
Một startup fintech ở Hà Nội (~30 kỹ sư) từng vận hành hoàn toàn dựa vào "anh Tuấn". Anh Tuấn là kỹ sư đầu tiên, biết mọi ngóc ngách của hệ thống đối soát giao dịch. Không ai viết runbook vì "cứ hỏi anh Tuấn là xong". Rồi anh Tuấn xin nghỉ để đi du học, báo trước đúng 3 tuần.
Ba tuần đó biến thành cơn ác mộng. Team cố ngồi cạnh anh Tuấn ghi lại mọi thứ, nhưng phát hiện có hàng chục quy trình ngầm mà chính anh Tuấn cũng không nhớ hết cho tới khi sự cố xảy ra. Sau khi anh nghỉ, trong hai tháng đầu tiên team mất trung bình gấp 3 lần thời gian để xử lý mỗi sự cố đối soát, và có một lần sai số đối soát không được phát hiện kịp trong 2 ngày.
Sau bài học đắt giá đó, công ty áp dụng nguyên tắc "chạm là ghi": bất cứ ai xử lý một tác vụ vận hành thủ công lần thứ hai đều phải viết ngay một runbook nháp. Sáu tháng sau, họ có một thư viện gần 40 runbook, và thời gian onboard người on-call giảm từ 6 tuần xuống còn 2 tuần.
Bài học rút ra: Kiến thức trong đầu một người là khoản nợ kỹ thuật ẩn (hidden liability). Ở quy mô nhỏ nó có vẻ tiện, nhưng khi scale, nó là quả bom hẹn giờ. Chi phí viết tài liệu luôn rẻ hơn chi phí mất người mang theo kiến thức.
Hướng dẫn từng bước
Dưới đây là quy trình xây dựng bộ tài liệu vận hành cho team đang scale.
Bước 1 — Xác định bạn cần runbook hay playbook. Hỏi: đây là một tác vụ cụ thể có thể ghi thành các bước xác định (→ runbook), hay là một loại tình huống cần phán đoán và phối hợp nhiều người (→ playbook)? Nếu bạn thấy mình viết chữ "tùy tình huống" quá nhiều lần, đó là playbook.
Bước 2 — Viết runbook theo cấu trúc chuẩn. Một runbook tốt nên có: (a) Tiêu đề rõ ràng, mô tả đúng tình huống; (b) Trigger — khi nào dùng runbook này; (c) Prerequisites — quyền truy cập, công cụ cần có; (d) Các bước đánh số dạng mệnh lệnh, kèm lệnh copy-paste được; (e) Verification — làm sao biết đã thành công; (f) Rollback — nếu hỏng thì hoàn tác thế nào; (g) Escalation — nếu runbook không giải quyết được thì gọi ai.
Bước 3 — Viết playbook theo cấu trúc chuẩn. Một playbook nên có: (a) Phạm vi — loại tình huống nào áp dụng; (b) Định nghĩa vai trò — Incident Commander, Comms Lead, Ops...; (c) Cây quyết định / các nhánh xử lý; (d) Tiêu chí leo thang (severity levels và ngưỡng); (e) Kế hoạch giao tiếp — nội bộ và khách hàng; (f) Danh sách runbook liên quan để trỏ tới thao tác cụ thể; (g) Post-mortem — cách rút kinh nghiệm sau sự cố.
Bước 4 — Đưa tài liệu vào nơi tìm-thấy-được. Tài liệu vô dụng nếu không ai tìm ra lúc cần. Đặt runbook càng gần điểm sử dụng càng tốt: link ngay trong alert của hệ thống monitoring, gắn vào từng service trong catalog. Không giấu tài liệu trong ổ đĩa cá nhân.
Bước 5 — Kiểm thử tài liệu bằng người thật. Đưa runbook cho một người CHƯA từng làm tác vụ đó và bảo họ làm theo y nguyên, không được hỏi. Chỗ nào họ khựng lại chính là chỗ tài liệu thiếu. Với playbook, hãy chạy game day / fire drill — diễn tập sự cố giả định.
Bước 6 — Gắn vòng đời bảo trì. Mỗi runbook và playbook cần một owner và một ngày review gần nhất. Sau mỗi sự cố thật, cập nhật lại tài liệu ngay trong buổi post-mortem — đây là thời điểm kiến thức còn nóng hổi nhất.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm runbook với playbook. Viết một tài liệu vừa cố ghi từng bước, vừa cố bàn chiến lược, cuối cùng không dùng được cho việc gì. Mẹo: tách bạch. Playbook trỏ tới runbook, không trộn lẫn.
Lỗi 2 — Runbook viết quá trừu tượng. Ghi "khôi phục dịch vụ" thay vì lệnh chính xác. Lúc 2 giờ sáng không ai muốn suy luận. Mẹo: mọi bước phải copy-paste và chạy được; nếu có biến, ghi rõ lấy giá trị biến ở đâu.
Lỗi 3 — Tài liệu "chết". Viết một lần rồi bỏ mặc; sáu tháng sau lệnh đã đổi, link đã hỏng, người đọc mất niềm tin và không bao giờ dùng lại. Mẹo: gán owner + ngày review; ưu tiên cập nhật ngay sau mỗi sự cố.
Lỗi 4 — Không ai tìm thấy tài liệu. Runbook nằm rải rác trong Google Docs, Confluence, Notion, tin nhắn Slack. Mẹo: một nguồn chân lý duy nhất (single source of truth), và link runbook thẳng vào alert.
Lỗi 5 — Viết cho người đã biết. Tác giả vô thức bỏ qua các bước "hiển nhiên" với mình nhưng lạ lẫm với người mới. Mẹo: luôn kiểm thử bằng người chưa có ngữ cảnh (fresh-eyes test).
Lỗi 6 — Cầu toàn nên không bao giờ viết. Chờ có "runbook hoàn hảo" nên chẳng viết gì. Mẹo: một runbook nháp 70% tốt gấp nhiều lần con số không. Viết trước, tinh chỉnh sau.
Mẹo vàng — nguyên tắc "chạm là ghi": bất kỳ tác vụ vận hành thủ công nào làm tới lần thứ hai đều phải sinh ra (hoặc cập nhật) một runbook. Đây là cách tự nhiên nhất để thư viện tài liệu lớn dần theo đúng nhu cầu thực tế, không thừa không thiếu.
Bài tập thực hành
- Chọn một sự cố lặp lại mà team bạn đã gặp ít nhất hai lần trong ba tháng qua. Viết một runbook đầy đủ cho nó theo cấu trúc 7 phần ở Bước 2 (tiêu đề, trigger, prerequisites, các bước, verification, rollback, escalation). Yêu cầu mọi bước phải copy-paste được.
- Kiểm thử fresh-eyes: đưa runbook vừa viết cho một đồng nghiệp chưa từng xử lý sự cố đó. Yêu cầu họ làm theo mà không hỏi bạn. Ghi lại mọi điểm họ khựng lại, rồi bổ sung vào tài liệu.
- Phác thảo một playbook cho một loại tình huống rộng mà team bạn có thể gặp — ví dụ "Playbook xử lý sự cố Sev-1" hoặc "Playbook khi service quan trọng down > 15 phút". Định nghĩa tối thiểu: các vai trò, ba mức severity kèm ngưỡng leo thang, và danh sách 2–3 runbook mà playbook này sẽ trỏ tới.
- Audit hiện trạng: liệt kê 5 quy trình vận hành quan trọng nhất trong team bạn hiện đang chỉ nằm trong đầu một người. Đánh dấu cái nào rủi ro nhất (người đó khó thay thế, sự cố hay xảy ra) và ưu tiên viết runbook cho chúng trước.
Tóm tắt
- Process documentation là thứ biến kiến thức ngầm trong đầu vài người thành tài sản có thể scale của cả tổ chức. Khi team lớn lên, đây không phải việc "làm cho có" mà là hạ tầng sống còn.
- Runbook = hướng dẫn từng-bước cho MỘT tác vụ cụ thể, xác định, ai cũng chạy được. Trả lời câu hỏi "Làm gì, theo bước nào?". Ví von: công thức nấu ăn.
- Playbook = khung chiến lược cho MỘT LOẠI tình huống, cần phán đoán và phối hợp, thường định nghĩa vai trò và tiêu chí leo thang, đồng thời trỏ tới các runbook. Trả lời "Tiếp cận thế nào, ai quyết?". Ví von: cẩm nang của bếp trưởng khi có tiệc lớn.
- Một tổ chức trưởng thành cần cả hai: playbook để điều phối, runbook để thực thi.
- Tài liệu chỉ có giá trị khi tìm-thấy-được, kiểm-thử-được, và được bảo trì. Gắn owner, gắn ngày review, cập nhật ngay sau mỗi sự cố.
- Nguyên tắc thực dụng nhất để bắt đầu: "chạm là ghi" — làm thủ công tới lần thứ hai là phải viết runbook.