Hồi còn ở New Zealand, tôi từng làm một năm ở bộ phận vận hành mạng (network operations) của nhà mạng Spark, và bài học đọng lại khá đơn giản: con người sẽ mắc lỗi, hệ thống sẽ hỏng, và chúng cứ theo lịch của riêng mình, chẳng thèm hỏi bạn đã sẵn sàng chưa. Thứ duy nhất bạn kiểm soát được là mình đã chuẩn bị đến đâu khi chuyện xảy ra.

Để mọi người dám nhận lỗi: blameless postmortem

#

Cải thiện lớn nhất lại không nằm ở kỹ thuật. Nếu mắc lỗi là bị phạt, người ta sẽ giấu lỗi, và một lỗi bị giấu sẽ được sửa muộn hơn đáng lẽ hàng giờ, thậm chí hàng ngày. Một đội mà ai đó dám nói “Tôi làm hỏng rồi, đây là chính xác những gì tôi đã làm” chỉ trong vài phút thì lúc nào cũng khắc phục nhanh hơn. Bước tiếp theo cũng quan trọng không kém: đừng dừng lại ở chỗ vá triệu chứng. Hãy đào đến tận nguyên nhân gốc, không thì cùng một lỗi sẽ quay lại dưới một hình dạng khác.

Bước tiếp theo đó chính là việc của một bản blameless postmortem. Sau mỗi sự cố đáng để rút kinh nghiệm, sẽ có người viết lại: chuyện gì đã xảy ra, thiệt hại ra sao, đã khắc phục thế nào. Bản viết này mặc định rằng ai cũng đã hành động với thiện ý, dựa trên những gì họ biết vào lúc đó, nên thay vì hỏi lỗi tại ai, nó hỏi điều gì đã khiến lỗi dễ xảy ra đến vậy: thiếu một bước xác nhận, bảng điều khiển (dashboard) dễ gây hiểu nhầm, hay tài liệu hướng dẫn xử lý (runbook) vốn chưa từng có. Câu “Một kỹ sư lỡ tay chạy migration trên production” sẽ trở thành “Script triển khai cho phép chạy migration trên production mà không cần xác nhận gì cả”. Sau đó bản viết được chia sẻ để các đội khác cũng học được, và kết thúc bằng danh sách việc cần làm (action item), mỗi việc có người phụ trách và hạn chót, để nó không biến thành một tài liệu chẳng ai làm theo. Nếu muốn đọc bản đầy đủ, chương về postmortem trong sách SRE của Google, Postmortem Culture: Learning from Failure, viết rất kỹ, kèm cả một ví dụ hoàn chỉnh.

Mẫu blameless postmortem

#

Lúc đầu chỉ cần chừng này là đủ. Hãy giữ nó đủ ngắn để mọi người chịu điền vào.

# Postmortem: <tiêu đề ngắn>
Ngày: YYYY-MM-DD · Người viết: <tên> · Trạng thái: bản nháp / đã rà soát

## Tóm tắt
Hai, ba câu: cái gì hỏng, hỏng bao lâu, khắc phục thế nào.

## Ảnh hưởng
Ai bị ảnh hưởng, bao nhiêu người, trong bao lâu. Có mất dữ liệu hay doanh thu không.

## Dòng thời gian
Dùng một múi giờ duy nhất.
- 14:02 bắt đầu triển khai
- 14:09 cảnh báo đầu tiên bắn ra
- 14:15 bắt đầu rollback
- 14:21 tỷ lệ lỗi trở lại bình thường

## Các yếu tố góp phần
Điều gì trong hệ thống, quy trình hay công cụ đã để chuyện này xảy ra. Không ghi tên người.

## Điều đã làm tốt

## Điều chưa tốt

## Việc cần làm
| Việc                                    | Người phụ trách | Hạn        |
|-----------------------------------------|-----------------|------------|
| Thêm bước xác nhận vào script migration | <tên>           | YYYY-MM-DD |

Giảm khả năng mắc lỗi ngay từ đầu

#

Ở phần này, ba việc nhàm chán gánh gần hết công sức. Một là giữ kỹ năng luôn được cập nhật — lỗi rất “ưa” kiến thức lỗi thời, nên đào tạo định kỳ là bảo trì chứ không phải phúc lợi. Hai là viết quy trình ra thành văn bản — rất nhiều “lỗi do con người” thực chất là lỗi do mơ hồ, ai đó phải đoán vì tài liệu vốn không tồn tại. Ba là tự động hoá những việc lặp đi lặp lại: con người cực kỳ kém khoản làm đúng một việc năm trăm lần liền, còn máy tính thì sinh ra chính là để làm việc đó. Ngoài ba việc này, hãy để thêm một người nữa soát lại mọi thứ có rủi ro. Rà soát chéo, hay thậm chí chỉ là một bước tự kiểm tra có bài bản, cũng bắt được một tỷ lệ lỗi nhiều đến đáng xấu hổ trước khi chúng kịp lọt ra ngoài.

Lên kế hoạch cho sự cố lớn trước khi nó ập đến

#

Hãy bắt đầu bằng một bản đánh giá rủi ro trung thực: điểm yếu bên trong như hạ tầng CNTT, mối đe doạ bên ngoài như thiên tai. Thiết lập giám sát theo thời gian thực làm hệ thống cảnh báo sớm. Sau đó viết ra các kế hoạch: kế hoạch duy trì hoạt động kinh doanh (business continuity plan) cho các sự cố gián đoạn nói chung, và kế hoạch khôi phục sau thảm hoạ (disaster recovery plan) dành riêng cho mảng CNTT. Kế hoạch khôi phục cần ghi rõ mỗi hệ thống được phép ngừng tối đa bao lâu và được phép mất tối đa bao nhiêu dữ liệu (thời gian khôi phục mục tiêu RTO và điểm khôi phục mục tiêu RPO).

Kế hoạch chưa thử thì chỉ là phỏng đoán, nên hãy tổ chức diễn tập. Quyết định trước ai sẽ báo gì cho bên liên quan nào, vì truyền thông khủng hoảng kiểu ứng biến chính là cách sự hoảng loạn lan ra. Và đừng bỏ qua những việc chẳng mấy hào nhoáng còn lại: giữ liên lạc với chính quyền địa phương, bảo trì đều đặn, mua đúng loại bảo hiểm.

Chẳng việc nào ở đây thú vị cả, có lẽ vì thế mà nó hiệu quả. Những công ty xử lý sự cố tốt không phải nhờ may mắn — họ đã lên kế hoạch cho sự cố từ khi mọi thứ còn yên ổn.