Sập server, làm gì đây?

Bài viết được sự cho phép của tác giả Huỳnh Quán Cẩm

Phỏng vấn

Có nhiều lần đi phỏng vấn tui bị hỏi câu này.

Giả sử service tự dưng lăn đùng ra chết không còn gửi được request nữa, bạn sẽ làm gì?

Lần nào được hỏi tui cũng nghĩ một câu chuyện khoa học viễn tưởng rồi phang bừa. Cá nhân tui nghĩ đây là một câu hỏi nhằm đánh giá khả năng tiếp cận & giải quyết vấn đề của bạn, chứ không hẳn là có câu trả lời cụ thể.

Tuy nhiên đi làm thì cũng có lúc … server lăn ra chết thật. Vậy thì bạn sẽ làm gì?

Thực tế

Sau đây là một câu chuyện có thật của các nhân vật hư cấu.

Có một hôm trúng ngay lượt Quần Cam on-call, app của công ty tự nhiên load dữ liệu mới rất chậm, tài khoản Twitter của app được tag liên tục để phàn nàn.

Đây là một sự cố nghiêm trọng vì nó ảnh hưởng đến hầu hết app users. Vì vậy công ty đã quyết định nhanh là cần phải cập nhật lên Twitter để trấn an tình hình. Sau một lúc, lượng retweet tăng lên, lượng phàn nàn giảm xuống.

Ví dụ như tweet cập nhật status của Github mỗi lần con unicorn xuất hiện…

Bài học #1: Đánh giá mức ảnh hưởng và thông báo đến users.

Cùng lúc đó Quần Cam bắt đầu tiến hành xem xét chuyện gì đang xảy ra. Lúc đầu, Quần phán đoán chắc do bên dữ liệu làm ăn sống nhăn không bắn dữ liệu về. Giả thuyết nghe có vẻ hợp lý bởi chuyện này đã từng xảy ra trước đó. Nhưng để nói có sách mách có chứng trước khi gửi mail chửi rủa, Quần kiểm chứng lại thông số trên Grafana. Số liệu hiển thị traffic bên đó vẫn đổ về bình thường.

Bài học #2: Luôn xem bảng thông số sau khi đoán bừa.

Hình minh hoạ bảng thông số (nguồn: Wikimedia)

Tiếp theo Quần lại nghĩ: Có khi nào tắc nghẽn xảy ra ở load-balancer hay không?. Lần chết service gần nhất là do HAProxy không xử lý kịp các HTTPS handshake, lần này bảng thông số cũng cho thấy những triệu chứng tương tự: một số lượng concurrent session khá lớn. Nghĩ chắc là đúng, Quần đã giảm số lượng HTTPS request từ phía client đi một nửa.

Nhưng hướng tiếp cận đó không giải quyết được vấn đề. Truy hồi về cùng thời điểm ở các tuần trước, bảng thông số đều hiển thị lượng session tương tự. Tóm lại chỉ là do người truy cập vào đông thôi.

Bài học #3: (again) Số liệu có thể đánh lừa bạn.

Lúc này Quần Cam tự thấy là nên nhờ sự trợ giúp từ đồng đội. Năm cái quần vẫn hơn một cái quần.

Bài học #4: Kêu gọi đồng đội nếu cảm thấy cần thiết.

Lúc này Quần và đồng đội đã loại bỏ được giả thuyết là tắc nghẽn xảy ra từ phía traffic, bây giờ họ bắt đầu xem xét phần import dữ liệu. Họ có một con worker để ghi các dữ liệu từ phía cung cấp thông qua một queue. Thông số cho thấy queue đang hoạt động tốt, họ tự hỏi điều gì đó đang diễn ra ở chính con worker.

Đọc logs thì họ thấy các tác vụ diễn ra chậm hơn so với bình thường, đặc biệt là các SQL thực hiện query cực chậm ở một cái bảng. Đọc tới khúc đó, một dev khác là Đầm Cam lập tức nhân ra chị đã phạm một sai lầm trong tuần. Chị có viết một con worker có sử dụng chức năng lock bảng để import dữ liệu cũ vào cái bảng đó. Chị đã rất cẩn thận chạy nó vào 11 giờ đêm hôm trước để tránh ùn tắc nhưng không ngờ nó chạy lâu tới như vậy.

Sau khi biết được lỗi, họ liền tắt con worker đó. Mọi thứ lập tức trở lại bình thường.

Bài học #5: Chọn giải pháp nhanh nhất để phục hồi hệ thống.

Ngay hôm sau, Đầm đã tiến hành đưa toàn bộ các tác vụ của mình vào một con worker có độ ưu tiên thấp hơn, đảm bảo việc vận hành không gây ảnh hưởng đến những critical worker khác.

Bài học #6: Luôn tính toán các giải pháp lâu dài để phòng ngừa sự cố tương tự xảy ra.

Bên cạnh đó Quần Cam ghi ghép lại sự việc để những người khác trong team có thể đọc lại. Nhờ đó mà hôm nay anh ấy có tư liệu để viết blog.

Bài học #7: Note lại các sự cố để làm cơ sở học tập sau này.

Bài viết này có thể giúp tui tăng lương như thế nào?

Như thường lệ bài viết không có giúp bạn tăng lương, nhưng tui có thể rút ra một số điểm để giúp bạn trả lời câu hỏi trên.

Luôn dùng thông số để làm cơ sở tìm lỗi. Luôn thu thập các metrics hệ thống trong quá trình chạy, không có số liệu thì lúc gặp sự cố ta như mò kim đáy bể.

Truy đúng critical failure trước khi đưa ra giải pháp. Dùng kĩ thuật 5-whys hay bất kì cái gì để giúp bạn tìm ra ngọn nguồn sự cố. Tuỳ tiện đưa ra giải pháp dựa trên phán đoán chỉ tốn thời gian của bạn mà không giúp được gì cả.

Chọn giải pháp nhanh nhất để phục hồi hệ thống. Nếu bạn làm việc với hệ thống ảnh hưởng đến hàng triệu user, mỗi giây service không hoạt động đều ảnh hưởng đến việc kinh doanh của công ty, mà như vậy thì ảnh hưởng đến việc nhận lương của bạn chứ chưa nói đến tăng lương. Hãy tìm cách hồi phục hệ thống nhanh nhất có thể, nhưng luôn tính toán một giải pháp lâu dài.

Cái kết

Bạn đồng ý với Quần Cam hay cho rằng tui đang nói tầm bậy? Hãy bình luận ở phía dưới nhé.

Bài viết gốc được đăng tải tại quan-cam.com

Có thể bạn quan tâm:

• Các kĩ sư Grab thiết kế hệ thống “đàn hồi” sử dụng kĩ thuật Circuit Breaker như thế nào?
• Áp dụng Rate Limiting vào hệ thống như thế nào?
• Tester là gì? Lợi ích của Tester

Xem thêm Việc làm IT hấp dẫn tại TopDev