Có đợt, hệ thống của công ty mình crash vào lúc 2h sáng. Tất cả log đều ngưng cập nhật, service timeout toàn tập, còn cái alert Prometheus thì như mấy con mèo điên, cứ kêu be be lên mà không thằng nào hiểu chuyện gì xảy ra. Lúc đó, mình đang ngủ, bị gọi on-call dậy, vừa mở mắt đã thấy một cái dashboard Grafana toàn màu đỏ.
Mình nhớ lúc đó tay chân run thật sự. Cảm giác nó không phải vì lỗi nặng, mà là vì mình không biết bắt đầu từ đâu. Service down thì rõ rồi, nhưng nguyên nhân thì nằm đâu? Network? Disk full? Database chết? Docker bị treo?
Thực ra, toàn bộ hệ thống này đã từng có tài liệu vận hành, cũng có checklist khôi phục, nhưng cái vấn đề là nó nằm rải rác: một phần trong Notion, một phần ghi trong README repo, một phần nhớ trong đầu thằng SRE đã nghỉ việc cách đây 2 tháng :))))
Sau lần đó, mình mới ngộ ra một chuyện:
Viết playbook không phải để trình bày cho đẹp, không phải để thể hiện team mình chuyên nghiệp, càng không phải để đọc cho vui. Mà là để lúc production toang, mình mở ra, mình biết phải làm gì.
Anh em làm DevOps chắc cũng từng bị như mình — viết tài liệu cho có, viết checklist như thủ tục ISO, nhưng thực tế lúc lỗi xảy ra thì chẳng ai buồn đọc. Một phần vì nó viết quá chung chung, một phần vì nó không thực tế.
Ví dụ nha:
- Ghi là “Check service status” — ủa check bằng cái gì? systemctl hay curl endpoint?
- Ghi là “Restart DB nếu cần” — biết khi nào là “nếu cần”? Dựa vào metrics nào?
- Ghi là “Check error log” — log nằm đâu, filter ra sao, tìm từ khóa gì?
Chính vì vậy, mình đổi tư duy: từ viết cho người khác -> viết cho chính bản thân mình lúc ngu nhất, lú nhất. Mình tưởng tượng lúc 2h sáng bị gọi dậy, đầu còn chưa tỉnh, thì mở playbook ra, nó phải như GPS chỉ đường, từng bước rõ ràng, không cần suy nghĩ thêm.
Một playbook tốt, với mình, có vài tiêu chí:
-
Rõ ràng từng bước nhỏ nhất. Ví dụ: “ssh vào node X bằng user abc”, “dùng câu lệnh này grep log”, “khi thấy dòng
panic:thì làm tiếp bước 2″. -
Có context để phán đoán. Không phải chỉ làm theo, mà còn giúp người on-call hiểu “vì sao” làm bước đó.
-
Chỉ ghi những gì đã test qua hoặc từng dùng thật. Đừng lấy mấy đoạn từ StackOverflow rồi dán vào cho có.
-
Tập trung vào các lỗi recurring. Hệ thống nào cũng có vài loại lỗi hay xảy ra. Viết cho những cái đó trước, đừng cố bao quát hết.
Viết playbook, xét cho cùng, là một hình thức giữ tỉnh táo cho chính mình trong những lúc tệ nhất. Nó không cần phải đẹp, không cần Markdown fancy, chỉ cần search ra nhanh, đọc hiểu liền, làm theo được.
Và mình nói thật, từ khi mình viết lại toàn bộ playbook theo kiểu “cho chính mình dùng”, số lần panic khi on-call giảm hẳn. Mấy đứa trong team mới vô cũng follow được, và quan trọng nhất: Không ai còn ngồi nhìn nhau chết trân lúc hệ thống lỗi nữa.
Vậy đó anh em. Nếu đang chán viết tài liệu vận hành, thử nghĩ lại xem viết để sau này chính mình đỡ lú, thì chắc sẽ viết khác liền à.
