Những việc cần làm khi hệ thống bị LỖI

Hà Trọng Trung 4 phút đọc

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é!

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

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ọ!

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

Nguồn: Sưu tầm