Server tự nhiên chết thì nên làm gì ?

Server tự nhiên chết thì nên làm gì ?

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

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ì?

nhớ lần đó tui phang bừa =)) , bừa nên không kể ra . 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. kể lại từ ngày 23/09 huyền thoại 1 thời =)) , nó giống ngày giải phóng vậy đó

Có một hôm nọ đang nằm chơi hưởng thụ , tự nhiên tin nhắn tới liên tục tưởng đâu Lương về , đm éo phải =))
vào check sms mà monitor thì thôi rồi vỡ trận , hàng trăm con server báo down , không con nào vào được, website bộ mặt cty cũng không vào được, website cho user thanh toán cũng không xong, trong đầu nghĩ

chắc là tận thế chẳng 😀

đúng lúc này thì bạn bè gần xa liền gọi nào là bạn thân như thằng SDK 24/7 , NOC, SNS, còn nhiều thằng thân lắm (lúc này thì thân ai nấy lo) nội dụng túm lượt như này

“alo anh Cường thằng xxx nó bị die rồi anh, anh online hỗ trợ giúp nha , gấp gấp gấp ” trùi đựu nghe xong như sét đánh mang tai =))

Lúc này tui nghĩ chắc là xong thật rồi , liền gọi cho 1 số tay anh chi giang hồ thân tính để nhờ vã và xem có bấu víu được gì không ( có đuổi thì đuổi chung cho vui )

Đây là một sự cố nghiêm trọng vì nó ảnh hưởng đến hầu hết đến “Chén cơm manh áo” của cả cty . Vì vậy phải triệu tập thêm nhiều tay anh chị có số má khác để hỗ trợ xử lý cho nhanh gọn , tránh bị phát hiện 😀 (nói nghe cho dữ chứ vụ này thì cả nước đều biết)
sau 1 lúc thời gian cũng dài thì toàn bô server nó cũng lên, rồi service, db của tui cũng lên ngon lành cành đào.

Tui mừng quá, nhưng không phải như vậy. đời đâu như là mơ user la làng vẫn không thanh toán Z*Xu được, sau 15p debug thì tui phát hiện 1 service (windows) chạy cả ngàn năm chưa được start lên làm cho user không thanh toán bằng Z*Xu được . ngay lập tức tui và đồng bọn phải bảo trì . tránh cho user phàn nàn (mà thật ra thì nó chửi luôn rồi =)) )

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

Cùng lúc đó tui bắt đầu tiến hành xem xét chuyện gì đang xảy ra, Lúc đầu, tui phán đoán chắc do thằng Z*Xu làm ăn sống nhăn. Giả thuyết nghe có vẻ hợp lý bởi chuyện này đã từng xảy ra nhỏ lẻ trước đó, Nhưng để nói có sách mách có chứng trước khi gửi mail chửi rủa thì tui check thông số trên monitor thì bình thường

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

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

mà thật ra là mọi người đã có mặt cả rồi , chỉ có mình tui cách đó 110km (tui đang hưởng thụ mà . huhu ) . tui đành bỏ lại niềm đam mê ăn ngủ để lên đường với đồng đội .sau 120p thì tui cũng lên tới nơi , Tôi chưa bao giờ nghĩ nó kinh khủng đến thế .

sau một hồi thì tui phát hiện tiếp ra là do thằng bạn thân NOC, firewall của nó khi start lên block gói tin từ Z*Xu APIs gọi đến thằng Wrapper API thông qua con LVS của tui . giận tím người

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

Tui liền alo sếp nó nhớ xử lý ngày . và Tui mail 1 cái mail dài 500 dòng chỉ ra lỗi là của mài nè . mài xử liền cho tao ngay . và tui cc cho sếp bự nhất của nó vào luôn . kaka giận quá mà

Bài học #4: 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 đó tui cũng 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 có tư liệu để viết blog.

Bài học #5: 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 kinh nghiệm 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.

Chúc ngày mới tốt lành .

Cường Nguyễn .

Trả lời

Email của bạn sẽ không được hiển thị công khai.