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#
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.
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. Review 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 IT, mối đe doạ bên ngoài như thiên tai — và 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 IT. 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 stakeholder 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.