Sập Server có phải muôn đời – Phần 1: Làm gì khi hệ thống sập bất ngờ?

Đâ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!

Vui chơi nhưng không quên nhiệm vụ, hãy như Hùng!

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.

Có lần AWS toang tới mức cái trang show incident status cũng.. sập luôn!!

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.

Chuyện tiền nong là 1 trong những lý do khiến hệ thống crash nhiều nhất!

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
Đôi khi chỉ cần restart server là đã sửa được 69.96% các lỗi!

 

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ọ!
Nhắc lại, nhớ bình tĩnh mà điều tra nhen!

 

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!

3 thoughts on “Sập Server có phải muôn đời – Phần 1: Làm gì khi hệ thống sập bất ngờ?”

  1. Bài viết rất hay. Khác với “lũ” thiên nhiên, software cho ch/ta khả năng rẽ cho lũ chảy theo những hướng song song. Giả như giàn production nó sụp, nếu bạn đề phòng trước, có đôi khi bạn có thể mang những giàn máy khác ra thay thế tạm thời trong thời gian phục hồi máy chính. Mục đích như vầy ta gọi chơi là minimizing downtime. Một dev fullstack giỏi nên tự thu thập thêm kiến thức để lấn sân biết về sysadmin, database, và networking. Chi cho khổ vậy? Để sau khi meet deadline xong, bạn có thể lảm giả (simulating) như cái API/cloud nó fail, database nó sổ mũi, firewall nó hắt xì, vv và vv, code của bạn nó handle chướng ngại vật giả do bạn tự chế ra làm sao. “Quân trường đổ mồ hôi – chiến trường bớt đổ máu” – mang câu này ra áp dụng vào software dev ra sao? Quân trường là test environment mà chiến trường là prod. Test cho nó phù mỏ, may ra lúc prod nó dở trò, trong đầu bạn đã có ch/trình kế hoạch tác chiến hẳn hòi rùi.

    Like

  2. Chắc ông admin ăn nhậu say lại đi đái vào server đây mà, tôi còn lạ gì 🤣
    – Trích vozer, “Nghìn năm văn vở, lỗi tại thiên 😂”

    Like

Leave a Reply to Quang Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s