Đây là phần 2 trong series 3 phần “Sập Server có phải muôn đời”.

1. Làm gì khi hệ thống sập bất ngờ – Xách quần lên công ty
2. Viết post-mortem sau khi xử lý sự cố – Đừng chỉ trích hay đổ lỗi
3. Những phương pháp phòng chống/monitoring – Giúp anh em ngủ ngon không lo server sập

 

Ở kì trước, chúng ta đã cùng bạn Hùng xấu số tìm ra lỗi, khôi phục hệ thống chạy lại như thường. Ở kì này, chúng ta sẽ cùng tìm hiểu về những điều chúng ta nên làm, cách viết post-moterm sau khi sự cố xảy ra nha.

Những điều này tuy nhỏ nhưng vô cùng quan trọng, vì nó giúp chúng ta tránh được những sai lầm tương tự trong tương lại đấy.

Post-mortem là cái chi chi?

Nếu coi mỗi lần sập server là một vụ án mạng, tìm bug là quá trình điều tra, sửa bug là quá trình truy bắt hung thủ; thì việc post-motern chính là việc … viết cáo trạng, tóm tắt lại nguyên do án mạng, động cơ gây án, thủ phạm, nạn nhân v…v

Nói tóm lại, sau khi xử lý xong sự cố, chúng ta sẽ viết post-mortem ghi rõ những gì đã xảy ra, nguyên nhân server bị sập, thiệt hại về người và của, cách xử lý, cách phòng chống v…v

Tại sao lại phải viết post-mortem?

Ủa, cái gì qua rồi thì cho nó qua đi, còn nhắc lại quá khứ đau thương  mà làm gì??

Sai rồi, đằng sau mỗi lần hệ thống bị sụp là 1 … sai lầm của team (chưa test code, chạy script ẩu). Nếu như không có post-mortem, không nhìn lại sai lầm, không nghĩ cách cải thiện, thì những sai lầm này sẽ vẫn tiếp tục xảy ra nữa.

Chưa hết, viết post-mortem còn để cho team và các thành viên mới nhìn lại, để thấy sai lầm trong quá khứ, tránh lập lại ở tương lai. Ta cũng có thể viết post-mortem cho khách hàng/cấp trên, để họ hiểu hơn về lý do sập, cũng như tin tưởng chúng ta hơn khi thấy ta có các biện pháp phòng chống

 

Quay lại chuyện của Hùng, sau khi viết post-mortem, cả team nhìn lại mới thấy nguyên nhân sâu xa hơn là: Không ai quản lý tiền bạc/credit khi tích hợp với API bên thứ 3.

Tra kĩ hơn, hệ thống còn dùng Twillio để gửi SMS và SendGrid để gửi email, nhưng đã nợ tiền gần 1 tháng. Nếu không trả tiền thì tầm 1-2 tháng nữa là chức năng gửi SMS/Email sẽ … ngừng hoạt động luôn.

May thay, anh lead nhắn 1 phát để bên accounting thanh toán, rồi tạo task để nhắc nhở thanh toán 3 tháng/lần là xong. Mọi thứ lại chạy ngon lành.

Đừng đổ lỗi, đừng tìm thủ phạm, hãy tìm vấn đề

Điều quan trọng nhất khi viết post-mortem là: Ta viết ra để học, để rút kinh nghiệm, chứ không phải để trù dập hay đổ lỗi cho ai đó.

Có nhiều công ty rất lạ, có vấn đề thì cứ lo tìm người code lỗi, lôi người để sót bug ra chỉ trích trước. Đây là 1 nét văn hoá cực kì có hại, dễ ảnh hưởng đến tinh thần cả team.

Theo mình, 1 sự cố xảy ra là lỗi của cả team. Khi có vấn đề thì cùng nhau sửa, chứ không phải chỉ chăm chăm tìm ra thủ phạm! Văn hoá này giúp anh em tin tưởng lẫn nhau, làm việc thoải mái hơn.

Lúc viết post-mortem cũng thế, thủ phạm trong post-mortem chính là bug, là thiếu sót trong qui trình; chứ không phải là bạn Hùng code ẩu, hay bạn Kha quên test case A,B,C; hay do bạn Sơn chạy nhầm sciript xoá sạch database.

 

Đơn cử như có vụ bạn engineer bên AWS chạy script làm đi tong vài con server. Mới đầu, ta tưởng thủ phạm là bạn engineer đó, nhưng nhìn kĩ hơn, ta sẽ nhìn ra vấn đề thật sự:

• Lỗi qui trình: Script quan trọng vậy tại sao không có code review trước khi chạy?
• Lỗi hệ thống: Khi server bị xoá tại sao không ai biết
• Lỗi kĩ thuật: Tại sao không thể restore lại các server khi bị xoá. Tại sao backup lại mất vài tiếng mới chạy được.

Các bạn thấy đấy, tìm ra tận gốc vấn đề sẽ giúp ta phòng tránh chúng trong tương lại

Vậy, viết post-mortem như thế nào cho đúng?

Một bản post-mortem chuẩn thường bao gồm những phần sau:

• Timeline: Dòng thời gian những chuyện đã xảy ra: Lúc mấy giờ sự cố xảy ra, bao lâu khách hàng phát hiện, lúc mấy giờ khôi phục
• Ảnh hưởng: Những ai bị ảnh hưởng, trong bao lâu, thiệt hại về người và của là bao nhiêu
• Cách khôi phục: Team đã khôi phục hệ thống như thế nào, mất bao lâu, có gặp rắc rối hay khó khăn gì
• Tìm hiểu nguyên nhân: Nguyên nhân gây ra sự cố là gì? Đừng chỉ quan tâm nguyên nhân bề mặt, mà hãy đào sâu, tìm hiểu những sai sót trong qui trình làm việc, thiết kế hệ thống
• Cách phòng chống: Những biện pháp mà team đã làm/sẽ làm để tránh xảy ra vấn đề tương tự trong tương lai

 

Hầu như các công ty lớn đều bị … sập server có đôi vài lần. Đa phần họ đều công khai bản post-mortem cho khách hàng đọc nên các bạn có thể tham khảo và viết theo nha:

• https://about.gitlab.com/blog/2017/02/10/postmortem-of-database-outage-of-january-31
• https://blog.cloudflare.com/a-post-mortem-on-this-mornings-incident
• https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019
• https://aws.amazon.com/message/41926
• https://status.digitalocean.com/incidents/h6dtb5bj2r6l

 

Note nhẹ: Các bản post-mortem này viết cho đối tượng là user/khách hàng nên không đi quá sâu vào chi tiết hệ thống. Khi viết post-mortem cho team mình, bạn có thể đi sâu vào hệ thống, services, code, qui trình của team nha.

Tạm kết

Ở phần này, mình đã chia sẻ với các bạn việc cần làm sau khi hệ thống sụp. Mình cũng chia sẻ cách viết post-mortem thế nào cho phù hợp.

Tất nhiên, những việc như khôi phục hệ thống, viết post mortem chỉ là việc… chữa cháy. Ông bà ta đã dặn phòng bệnh hơn chữa bệnh. Một team engineer giỏi là một team giữ cho hệ thống hoạt động ổn định, không bị sập, nhờ có các biện pháp phòng chống.

Do vậy, ở phần 3, mình sẽ chia sẻ những biện pháp phòng chống này. Các bạn có thể áp dụng để giúp hệ thống ổn định và khoẻ mạnh hơn nha. Nhớ đón xem tuần sau nhé!