5 Sai Lầm Phổ Biến Của Lập Trình Viên Trong Khủng Hoảng (và Cách Tránh)
Giới thiệu
Thứ Sáu, 17:55. Bạn đang đóng máy tính xách tay, tâm trí đã hướng về pizza. Và rồi: TRIM TRIM, chuông điện thoại vang lên. Nếu bạn là lập trình viên, chắc chắn bạn đã từng cảm thấy cái lạnh sống lưng:
“Chuyện gì lại xảy ra nữa đây?”
Trong ngành phát triển phần mềm, không có gì đáng sợ hơn một phòng khủng hoảng, đặc biệt là vào tối thứ Sáu. Chúng ta đều đã trải qua điều này. Tôi cũng đã từng nhiều lần. Và từ những sai lầm của bản thân cũng như quan sát sai lầm của nhóm, tôi đã học được những bài học quý giá.
1. Đừng Hoảng Loạn
Như đã được viết trong "Hướng Dẫn Du Hành Giữa Các Hành Tinh": đừng hoảng loạn. Điều này không chỉ áp dụng cho việc cứu lấy các thiên hà mà còn cho việc duy trì các hệ thống đang hoạt động.
Trong một cuộc khủng hoảng, rất dễ bị chi phối bởi lo âu: hàng trăm tin nhắn trong Slack, thông báo cảnh báo liên tục, người dùng hoảng loạn... và nỗi lo lắng rằng bạn đã làm hỏng mọi thứ. Cám dỗ để nhấp chuột một cách hoảng loạn, khởi động lại pods hoặc thay đổi cấu hình trực tiếp trên môi trường sản xuất rất lớn. Tuy nhiên, gần như lúc nào cũng... làm mọi thứ tồi tệ hơn.
Giữ bình tĩnh không phải là phớt lờ vấn đề, mà là hành động một cách rõ ràng.
Hít thở sâu. Tập hợp đội ngũ lại. Kiểm tra các log. Ưu tiên công việc. Và nếu có thể, hãy cười một chút (hài hước cũng là một công cụ sống sót, như Ford Prefect từng nói).
🧠 Hoảng loạn tạo ra vội vàng. Vội vàng tạo ra lỗi. Và lỗi... tạo ra nhiều khủng hoảng hơn.
2. Cố Gắng Giải Quyết Một Mình (và Trong Im Lặng)
Đặc biệt là trong giai đoạn đầu sự nghiệp, nhiều người cố gắng “gánh vác” một mình. Do sợ bị đánh giá hoặc không nhận thức được tác động của vấn đề. Nhưng sự im lặng chỉ làm cho khủng hoảng leo thang.
Hãy làm khác đi:
- Cung cấp thông tin cho lãnh đạo về sự cố và tác động đến doanh nghiệp;
- Mở một phòng chiến tranh (khi cần thiết) với những người phù hợp;
- Đặt một “người dẫn dắt khủng hoảng”, giúp tránh xung đột trong hành động và quyết định.
3. Tìm Kẻ Đáng Trách Giữa Cuộc Hỏa Hoạn
Không gì cản trở việc giải quyết hơn là bắt đầu cuộc săn lùng kẻ gây ra sự cố giữa lúc hỗn loạn.
Thay vì phán xét, hãy hợp tác:
- Tập trung vào giải pháp, không phải vào ai đã gây ra sự cố.
- Tin tưởng rằng mỗi người đã hành động với kiến thức và bối cảnh mà họ có.
- Nhớ rằng: một cuộc khủng hoảng hiếm khi xảy ra vì một lỗi đơn lẻ. Nhiều mắt xích bị đứt gãy, giống như một tai nạn hàng không.
4. Tìm Nguyên Nhân Gốc Trước Khi Ổn Định Hệ Thống
Đi vào chế độ “Sherlock Holmes” ngay từ đầu? Không phải lúc nào cũng là con đường tốt nhất.
Trước tiên hãy ổn định, sau đó điều tra.
- Hiểu những gì đang bị ảnh hưởng ngay bây giờ;
- Lập kế hoạch phản ứng ban đầu;
- Nếu cần khởi động lại dịch vụ, áp dụng một lệnh DML trên cơ sở dữ liệu hoặc thậm chí sửa lỗi nhanh trong mã... hãy làm. Nhưng hãy xử lý nguyên nhân gốc sau, với sự bình tĩnh.
5. Bỏ Qua Bước Tổng Kết Sau Khủng Hoảng
Khủng hoảng đã được giải quyết? Tuyệt vời. Bây giờ là phần quan trọng nhất: học hỏi từ nó.
Xem xét các sự cố như tai nạn hàng không, không phải như va chạm xe hơi:
- Trong giao thông, mỗi người chỉ nhìn vào thiệt hại của mình và tiếp tục cuộc sống.
- Trong hàng không, mỗi yếu tố góp phần đều được nghiên cứu, tài liệu và sửa chữa.
Tổng kết sau khủng hoảng là vắc-xin chống lại các lỗi tái diễn. Nếu không ai ghi lại những gì đã xảy ra, điều đó sẽ lại xảy ra. Và lại...
Checklist cho một Tổng Kết Tốt:
- Làm thế nào mà lỗi được phát hiện? Khách hàng? Giám sát?
- Các tác động thực tế là gì?
- Điều gì đã được thực hiện trong phản ứng ban đầu?
- Các yếu tố nào đã góp phần vào sự cố?
- Làm thế nào để ngăn chặn điều này xảy ra lần nữa?
- Sự quan sát có thất bại không? Có cảnh báo không? Dashboard?
👊 Hít Thở. Học Hỏi. Tiến Bộ.
Nếu bạn đang ở giữa một cuộc khủng hoảng, hoặc vẫn đang tiêu hóa cuộc khủng hoảng trước đó, hãy bình tĩnh. Ai cũng có lúc mắc sai lầm. Nhưng mắc sai lầm một cách có ý thức và sửa chữa cùng nhau là điều tạo nên sự khác biệt.
