Quay màn hình cho Kỹ sư DevOps: Sự cố, Pipeline & Runbook

Công việc DevOps diễn ra nhanh, phân tán và liên tục bị gián đoạn bởi các cảnh báo (page). Bối cảnh dễ bị thất lạc giữa người đã chẩn đoán sự cố lúc 3 giờ sáng và đội ngũ xem xét lại vào sáng hôm sau. Quay màn hình giúp thu hẹp khoảng cách đó. Nó biến các phiên terminal thoáng qua, quá trình điều tra dashboard và gỡ lỗi pipeline thành những tư liệu mà cả đội có thể học hỏi — mà không ai phải tái dựng lại chuyện gì đã xảy ra từ trí nhớ.

Vì sao đội DevOps cần video, không chỉ log

Log và metric cho bạn biết điều gì đã xảy ra. Chúng hiếm khi ghi lại cách một kỹ sư điều tra vấn đề — họ kiểm tra dashboard nào trước, lệnh nào tiết lộ manh mối quyết định, hay vì sao họ loại trừ một hướng điều tra sai. Chuỗi lập luận đó chính là điều mà kỹ sư trực ca tiếp theo cần.

Các trường hợp sử dụng phổ biến trong DevOps:

• Điều tra sự cố: Ghi lại quá trình gỡ lỗi trực tiếp khi nó đang diễn ra, chứ không phải tái dựng sau khi mọi thứ đã xong
• Hướng dẫn pipeline CI/CD: Cho thấy vì sao một build thất bại và cách khắc phục hoạt động
• Review infrastructure-as-code: Đi qua từng bước của một plan Terraform hoặc Pulumi trước khi merge
• Bàn giao trực ca: Cập nhật cho kỹ sư tiếp theo về các vấn đề đang mở trong vài phút thay vì một tài liệu bàn giao dài dòng
• Demo triển khai: Ghi lại một quy trình rollout mới trước khi bàn giao cho đội khác
• Bằng chứng cho postmortem: Lưu giữ chính xác trạng thái dashboard trong lúc xảy ra sự cố để phục vụ buổi retro

Ghi lại quá trình điều tra sự cố

Thời điểm tốt nhất để quay không phải là sau khi bạn đã khắc phục xong vấn đề — mà là ngay khi bạn vẫn đang chẩn đoán nó. Một bản ghi điều tra trực tiếp nắm bắt được dòng suy nghĩ thực sự của bạn, bao gồm cả những ngõ cụt, và điều này thường hữu ích hơn nhiều so với một bản tóm tắt đã được chỉnh sửa gọn gàng.

Cách ghi lại một cuộc điều tra sự cố:

1. Bắt đầu quay ngay khi bạn bắt đầu điều tra, kể cả trước khi biết nguyên nhân gốc rễ
2. Nói to giả thuyết của bạn: “Độ trễ tăng vọt lúc 14:02, đang kiểm tra xem có tương quan với lần deploy lúc 14:00 không”
3. Ghi lại mọi dashboard, câu truy vấn log và lệnh bạn chạy
4. Khi tìm ra nguyên nhân gốc rễ, nói rõ điều đó trước camera để sau này dễ tham chiếu theo mốc thời gian
5. Tiếp tục quay trong suốt quá trình khắc phục và xác minh

Sau đó, cắt gọn video xuống còn những khoảnh khắc then chốt để phục vụ postmortem, nhưng vẫn lưu trữ bản đầy đủ, chưa chỉnh sửa — nó thường có giá trị hơn cả bản highlight khi một sự cố tương tự tái diễn.

Hướng dẫn pipeline CI/CD

Pipeline bị lỗi là một trong những nguồn gián đoạn phổ biến nhất đối với kỹ sư DevOps, và cũng là một trong những thứ dễ ghi lại tài liệu nhất một khi đã giải quyết xong.

Ghi lại một phiên gỡ lỗi pipeline:

• Ghi lại toàn bộ log build thất bại — đừng cắt bớt phần “nhiễu”, vì nó thường chứa manh mối
• Cho thấy sự khác biệt (diff) giữa lần build cuối thành công và lần build thất bại
• Nói rõ giai đoạn nào thất bại và vì sao (giải quyết dependency, test không ổn định, timeout, quyền truy cập)
• Trình diễn cách khắc phục và chạy lại pipeline trước camera để xác nhận nó đã “xanh”

Lưu những bản ghi này cùng với cấu hình pipeline của bạn để kỹ sư tiếp theo gặp lỗi tương tự có thể tìm ra cách khắc phục trong vài giây thay vì phải gỡ lỗi lại từ đầu.

Review các thay đổi Infrastructure-as-Code

Việc review một plan Terraform, manifest Kubernetes hay template CloudFormation qua bình luận trong pull request rất khó — người review phải hình dung toàn bộ đồ thị tài nguyên trong đầu. Một video hướng dẫn ngắn giúp phạm vi ảnh hưởng của một thay đổi trở nên rõ ràng ngay lập tức.

Bản ghi review IaC hiệu quả:

1. Hiển thị đầy đủ kết quả plan hoặc diff trước khi giải thích bất cứ điều gì
2. Đi qua từng tài nguyên được tạo mới, chỉnh sửa hoặc xóa
3. Chỉ ra bất kỳ thay đổi nào kích hoạt việc thay thế tài nguyên (thường là loại thay đổi rủi ro nhất)
4. Giải thích lý do đằng sau các quyết định không hiển nhiên, chẳng hạn vì sao một phiên bản module bị ghim (pin)
5. Nêu rõ các bước thủ công cần thực hiện sau khi apply (xoay vòng secret, lan truyền DNS, làm nóng cache)

Điều này đặc biệt hữu ích với các thay đổi liên quan đến networking hoặc chính sách IAM trên production, nơi một diff bị đọc sai có thể gây hậu quả lớn.

Bàn giao trực ca mà không cần họp

Tài liệu bàn giao trực ca dạng văn bản nhanh chóng lỗi thời, còn một cuộc gọi bàn giao trực tiếp thì không thể mở rộng quy mô qua nhiều múi giờ. Một bản ghi dài 5 phút thường là điểm cân bằng lý tưởng.

Những gì nên có trong một bản ghi bàn giao:

• Các sự cố đang mở và trạng thái hiện tại của chúng
• Bất kỳ cảnh báo nào đã kích hoạt nhưng là báo động giả, để kỹ sư tiếp theo không phải điều tra lại
• Những dashboard đáng theo dõi và trạng thái “bình thường” trông như thế nào trên đó
• Các đợt deploy hoặc thay đổi được lên lịch trong ca tiếp theo
• Các check không ổn định hoặc cảnh báo gây nhiễu đã biết mà có thể bỏ qua an toàn

Ghi lại video này vào cuối ca làm việc của bạn và thả liên kết vào kênh bàn giao của đội. Kỹ sư tiếp theo có thể xem xong trong khoảng thời gian pha một tách cà phê.

Ghi lại dashboard và output terminal một cách rõ ràng

Công cụ observability và output terminal đều có những thách thức riêng về độ dễ đọc khi lên video.

• Dashboard: Dùng hiệu ứng zoom để làm nổi bật đồ thị hoặc panel cụ thể mà bạn đang nói đến, thay vì để người xem tự tìm trong một bố cục dày đặc
• Terminal: Tăng cỡ chữ lên ít nhất 16pt và dùng theme độ tương phản cao để output lệnh vẫn dễ đọc ở tốc độ phát bình thường
• Nhiều màn hình: Nếu quá trình điều tra của bạn trải rộng trên một dashboard metric ở màn hình này và một terminal ở màn hình khác, hãy dùng chế độ quay cửa sổ và chuyển đổi giữa chúng gọn gàng thay vì quay toàn bộ desktop
• Lệnh chạy lâu: Tua nhanh hoặc cắt bỏ thời gian chết (chờ kubectl rollout status, một lệnh terraform apply dài) khi chỉnh sửa để bản ghi luôn tập trung

Che dữ liệu nhạy cảm trước khi chia sẻ

Các bản ghi liên quan đến hạ tầng thường chứa thông tin nhạy cảm. Trước khi chia sẻ ra ngoài nhóm trực tiếp của bạn:

• Làm mờ hoặc cắt bỏ hostname nội bộ, dải IP và account ID nếu bản ghi sẽ được chia sẻ ra bên ngoài
• Không bao giờ để lộ thông tin xác thực, token hay connection string — tạm dừng quay trước khi gõ các thông tin bí mật
• Rà soát lại các bản ghi dashboard xem có dữ liệu khách hàng nào xuất hiện trong log hoặc trace không
• Áp dụng chính sách phân loại dữ liệu của tổ chức bạn cho các bản ghi giống như cách bạn áp dụng cho báo cáo sự cố dạng văn bản

Xây dựng thư viện postmortem và runbook

Một bản ghi sự cố đơn lẻ chỉ hữu ích một lần. Một thư viện có thể tìm kiếm gồm nhiều bản ghi như vậy là một đòn bẩy mạnh mẽ cho cả đội SRE hoặc platform của bạn.

Tổ chức các bản ghi theo:

• Dịch vụ hoặc hệ thống (payments-api, database chính, ingress controller)
• Mức độ nghiêm trọng của sự cố để các cuộc điều tra mức độ nghiêm trọng cao dễ dàng được nổi bật
• Loại nguyên nhân gốc rễ (liên quan đến deploy, năng lực hệ thống, lỗi dependency, cấu hình bị trôi)

Liên kết mỗi bản ghi từ tài liệu postmortem và chỉ mục runbook của bạn để các kỹ sư đang điều tra một sự cố mới có thể nhanh chóng kiểm tra xem điều tương tự đã từng xảy ra hay chưa.

Kết luận

Kiến thức DevOps rất dễ mất đi và tốn kém để xây dựng lại. Quay màn hình ghi lại chuỗi lập luận đằng sau một phản ứng sự cố, một bản sửa lỗi pipeline, hay một thay đổi hạ tầng ngay tại thời điểm nó diễn ra — khi việc ghi lại tốn ít công sức nhất và có giá trị nhất đối với người tiếp theo cần đến nó. Hãy bắt đầu với sự cố tiếp theo của bạn: bấm quay trước khi bạn biết câu trả lời, chứ không phải sau đó.

Chúc bạn quay hình vui vẻ!