Đây là phần 1 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

 

Đây là câu chuyện của Hùng, một developer quèn tại 1 công ty startup.

Một chiều thứ 6 đẹp trời nọ, Hùng đang thư thả về nhà, dắt gấu đi chơi cuối tuần, đi ăn khuya. Ăn uống no say, Hùng dắt gấu vào nhà nghỉ (tất nhiên là chỉ để nghỉ thui nha, blog này cho cả các bạn chưa đủ 18 tuổi).

Vào đến nhà nghỉ, Hùng vừa mới tuột quần, chuẩn bị … chạy thẳng vào toilet (chắc do nồi lẩu vừa ăn không sạch lắm). Bỗng dưng, di động reo, anh Sơn team leader trên công ty réo: Hùng ơi, hệ thống sập con bà nó rồi, khách hàng không vào được trang chủ, em lên công ty phụ anh và anh Kha kiểm tra với.

Vội vàng chưa kịp mặc quần, bỏ gấu nằm bơ vơ trong khách sạn, Hùng bắt vội chiếc Grab chạy thẳng lên công ty để tìm lỗi… Còn tiếp!

Hệ thống sụp là chuyện… bất khả kháng!

Câu chuyện này tuy không có thật, nhưng hẳn sẽ rất quen thuộc với những anh em SysAdmin/DevOps, anh em làm product và startup.

Hệ thống nào dù to đến nhỏ, trong quá trình chạy thể nào chả có vài lần xì hơi sổ mũi, nhẹ thì server bị down từ vài phút đến vài giờ, nặng thì … bay luôn database, mất sạch dữ liệu.

Nói thật, chúng ta không thể nào phòng chống 100% chuyện “sập bất ngờ” này. Đến AWS/Google cũng có lần bị down, khiến vài chục công ty khốn đốn; Gitlab cũng có lần xoá nhầm DB, mất 18h để khôi phục.

Do vậy, ta chỉ còn cách “sống chung với lũ”, sẵn sàng giải quyết khi hệ thống có vấn đề. Trong bài viết này, mình sẽ chia sẻ 1 số kinh nghiệm khi hệ thống bị sụp nha.

Chuyện của Hùng (phần cuối)

Quay lại câu chuyện của Hùng. Sau khi vác đít chạy lên công ty, Hùng thấy anh Sơn Lead và Kha Đép Ộp đã ở đấy. Hai người kiểm tra Database, kiểm tra network nhưng không thấy lỗi đâu.

Hùng bật log của web server lên, thấy toàn trả về 500. Truy vết 1 hồi, thì lòi ra là do chức năng recommend sản phẩm của công ty có dùng API của bên thứ 3. Nhưng do … chưa thanh toán tiền nên API họ quăng lỗi vì hết limit free, code của bên mình lại … quên xử lý trường hợp đấy nên crash.

Do tối, cả sếp lẫn kế toàn đều nghỉ, Hùng và anh lead quyết định tắt tạm chức năng này, không gọi API nữa, chỉ trả về danh sách trống. Sau khi sửa và deploy, hệ thống hoạt động lại bình thường.

Thở phào nhẹ nhõm, Hùng vội bắt taxi quay lại khách sạn, lấy quần và dắt gấu về. May quá, cả gấu lẫn quần vẫn còn đó, chưa bị ai ôm đi mất. Hùng thở phào nhẹ nhõm lần 2. Hết chuyện!

Những việc cần làm khi hệ thống bị sụp

Đấy, câu chuyện của Hùng có kết thúc khá có hậu. Nhưng không phải anh em nào cũng may mắn như vậy. Do vậy, mình chia sẻ một số kinh nghiệm xử lý khi hệ thống bị sụp nhé.

1. Hết sức bình tĩnh!

Với các hệ thống quan trọng, chỉ cần hệ thống sụp 1 giờ, công ty sẽ thiệt hại cả trăm triệu đồng, sụp 1 ngày là cả tỉ đồng. Do vậy, anh em rối và sợ là điều tất nhiên.

Tuy vậy, việc áp lực và hoảng loạn sẽ làm anh em rối trí, khó tìm được cách giải quyết phù hợp. Đôi khi “làm đại” sẽ còn gây ra hậu quả nghiêm trọng hơn.

Do vậy, đầu tiên ta phải hít sâu, thở nhẹ cho bình tĩnh rồi mới tiếp tục nhé!

2. Khôi phục hệ thống trước, điều tra sau

Trên lý thuyết, khi tìm được nguyên nhân làm hệ thống sụp, ta sẽ tìm được cách giải quyết đúng hơn, hợp lý hơn. Trên thực tế, đôi khi việc này sẽ tốn nhiều thời gian hơn, ảnh hưởng tới hình ảnh/doanh thu công ty.

Do vậy, người ta thường khôi phục hoạt động của hệ thống trước, rồi mới tìm nguyên nhân sau. Việc này giúp bạn có thêm thời gian để debug, tìm nguyên nhân.

Một số cách làm phổ biến:

• Nhiều khi chỉ cần restart server là đã giải quyết được phần lớn vấn đề
• Nếu gần đây có deploy bản mới của code, nhiều khả năng lỗi là do bản mới. Rollback lại code về phiên bản trước đó có thể giải quyết được
• Trường hợp xấu nhất, thay vì để server crash, có thể để 1 thông báo “Hệ thống đang bảo trì v…v” để hiện cho người dùng

 

3. Thu thập dữ liệu để “điều tra”

Nếu xui xẻo hơn, bạn không có cách nào để phục hồi hệ thống nhanh chóng, bạn sẽ phải tìm hiểu nguyên nhân gây lỗi và fix.

Quá trình này cũng giống như fix bug vậy, nhưng phải vừa chạy vừa fix. Theo kinh nghiệm của mình, đây là những thứ các bạn có thể “Điều tra”:

• Nhờ người dùng chụp màn hình bị lỗi, xem có gì lạ
• Nếu có dùng các tool như Sentry/LogRocket, lên đó kiểm tra xem có exception nào lạ lạ hay không
• Kiểm tra log hệ thống để tìm lỗi, kiểm tra các công cụ monitoring xem CPU/RAM có tăng đột biến hay không
• Nếu dùng Cloud thì lên Dashboard xem có warning gì lạ, có lỗi gì lạ hay không (AWS ngỏm, Google Cloud tèo).
• Kiểm tra service của các bên thứ 3 tích hợp với hệ thống có lỗi gì không, nhiều khi do lỗi của bên họ!

 

4. Cập nhật tình hình cho stakeholder

Khi hệ thống sụp, người sốt ruột nhất thực ra không phải là bạn mà là … sếp của bạn, hoặc sếp của sếp của bạn. Vì vậy, bạn nên báo cáo, cập nhật tình hình cho sếp, chứ đừng im im mà làm kẻo họ sốt ruột.

Bạn chỉ cần báo cáo tiến độ, dự đoán thời gian, thiệt hại:

• Đã khôi phục được DB, người dùng không ảnh hưởng gì, tầm 1 tiếng nữa xong | Không khôi phục được DB gần nhất, sẽ mất toàn bộ dữ liệu tháng này.
• Đã tìm ra nguyên nhân gây lỗi, team dev đang nghĩ cách fix
• Team dev đang test cách fix, sẽ deploy trong vòng 15 phút nữa | Bug khó hơn dự tính, sẽ mất tầm 2-3 tiếng để fix và khôi phục dữ liệu

Những báo cáo này không mất quá nhiều thời gian, nhưng sẽ giúp sếp của bạn có cái mà báo cáo, và các sếp trên cũng đỡ … sốt ruột.

Tạm kết

Ở phần 1, mình đã chia sẻ với các bạn một số kinh nghiệm xương máu để xử lý khi hệ thống bị sập. Hi vọng chúng sẽ giúp các bạn tự tin, đỡ căng thẳng để xử lý khi … server sập thật nhé!

Nếu trong quá trình đi làm, đã từng gặp tình trạng như vậy, hãy comment chia sẻ cách bạn xử lý cho bà con biết nha!

Ở phần 2, mình sẽ chia sẻ cách viết post-mortem, nhìn lại lý do hệ thống bị lỗi, tìm cách rút kinh nghiệm và cải thiện nha!