Hạ gục Incident: Vội vàng xử lý tưởng đúng hóa ra lại sai ngay từ đầu!

Khi incident xảy ra, tư duy quen thuộc của hầu hết mọi người là tìm cách để xử lý nhanh chóng, ngay lập tức. Tuy nhiên, nếu bạn làm vậy, rất nhiều hệ quả có thể xảy ra. Hóa ra, có nhiều chuyện không phải nhanh đã là tốt.

Incident đang là từ khóa "hot" đối với nhiều Group Leader ở Sun*. Mỗi khi chatbox “incident report” sáng đèn, nhiều Group Leader lại cảm thấy toát mồ hôi. Vậy incident là gì mà ai cũng sợ hãi như vậy và cần làm gì để “xử đẹp” chúng?

Thông thường các bạn sẽ nghĩ rằng, incident mà đã xuất hiện thì mau mau chóng chóng mà xử lý đi, còn nghĩ gì nữa. Nhưng nếu các bạn ngay lập tức đọc hiện tượng của incident, rồi lao vào đọc source code để tìm xem xử lý sai ở chỗ nào, hoặc thử tái hiện các hiện tượng incident, rất nhiều tình huống xấu khác có thể xảy ra như:

  • Mất thời gian điều tra lòng vòng, trong khi khách hàng cứ giục điều tra xong chưa, tìm ra nguyên nhân chưa, khi nào xử lý xong?
  • Không thể tái hiện được đúng hiện tượng incident hoặc tái hiện nhưng mất nhiều thời gian.
  • Có lúc cuống quá mà operator restart cả production server, dẫn đến một loạt services khác của khách hàng bị đình trệ.
  • Có tình huống server của khách hàng tê liệt vì một câu querry SQL không được kiểm chứng, trong khi tình huống gấp nên chạy trực tiếp trên production và bị tràn bộ nhớ.

Tuy nhiên, đôi khi nhanh lại hóa chậm, để tránh những điều đáng tiếc xảy ra, chúng ta có thể thử làm theo các bước sau:

Bước 1: Khi phát hiện hoặc được khách hàng báo có incident, hãy tìm hiểu thông tin một cách cụ thể, càng nhiều càng tốt, càng chi tiết càng tốt. Sử dụng công thức 5W1H như một cách đơn giản để tìm hiểu thông tin.

Ví dụ: Khi khách hàng gửi cho chúng ta email như sau:

“Dear…, tôi thấy giá tiền của một số mặt hàng lạ lạ, có vẻ ai đó đã thay đổi chúng. Nhờ các bạn điều tra.”

Có thể có bạn sẽ làm: Anh A, điều tra ngay cho tôi vì sao lại có hiện tượng này. Hoặc anh B, kiểm tra xem những mặt hàng nào bị sửa giá,…

Tuy nhiên, nếu là tôi, tôi sẽ gửi lại một mail cho khách hàng:

”Dear…, cảm ơn anh đã thông tin cho chúng tôi khi phát hiện ra hiện tượng này. Chúng tôi sẽ cho điều tra ngay và liên lạc lại với anh ngay khi chúng tôi có kết quả điều tra. Tôi thực sự rất biết ơn nếu anh có thể giúp chúng tôi đẩy nhanh tiến độ điều tra. Nhờ anh có thể cung cấp thêm một số thông tin cụ thể hơn nữa:

  • Những mặt hàng nào anh thấy giá lạ?
  • Thời điểm anh phát hiện điểm nghi ngờ là khi nào?
  • Anh phát hiện trên hệ thống hay ở đâu?
  • Nếu có thể, nhờ anh chia sẻ vì sao anh lại có thể phán đoán giá cả đã bị thay đổi?

Mong anh giúp đỡ.”

Việc liên lạc cho khách hàng khiến họ biết rằng mình đã nhận được thông tin và sẽ xử lý, cùng với việc làm rõ thêm thông tin, họ có thể giúp chúng ta đẩy nhanh tiến độ điều tra vấn đề, tránh được sự lòng vòng trong phán đoán vùng gây lỗi.

Trước khi giao việc cho anh A hay anh B, chúng ta cần xác định thêm một số thông tin nữa như mức độ khẩn cấp và vùng ảnh hưởng của incident. Từ đó, chúng ta có thể xác định chính xác Code độ ưu tiên xử lý incident.

Mức độ khẩn cấp của incident nôm na là có những incident phải xử lý ngay lập tức, có incident thì không cần xử lý ngay. 3 mức độ khẩn cấp là [High, Normal, Low] và để phán đoán mức độ khẩn cấp thì chúng ta dựa trên 3 yếu tố:

  1. Thời gian chấp nhận Incident: Về nguyên tắc, những incident khiến cho hoạt động bị ngừng hoàn toàn hoặc một phần, không thể tiếp tục thao tác tiếp, bị treo máy,… thì thời gian chấp nhận incident càng gấp, mức độ khẩn cấp sẽ càng cao.
  2. Tính lặp lại của Incident: Thời gian một incident tương tự lại xảy ra, tần suất xảy ra càng lớn mức độ khẩn cấp sẽ càng cao. Ví dụ: Lâu lâu chúng ta mới nhận được một spam mail thì mức độ khẩn cấp sẽ thấp, nhưng 2-3h lại nhận được một spam mail thì mức độ khẩn cấp của incident sẽ tăng lên đáng kể (có thể lên mức High).
  3. Ảnh hưởng tới nghiệp vụ phải hoàn thành trong thời gian định trước: Về nguyên tắc, những nghiệp vụ có tần suất phải hoàn thành càng cao thì incident ảnh hưởng tới kết quả nghiệp vụ này sẽ có mức độ khẩn cấp càng cao. Ví dụ, đối với một product phục vụ cho việc mua bán cổ phiếu, tính năng cập nhật tin tức mua bán của một sàn giao dịch/ hoặc một cổ phiếu cụ thể theo ngày bị sai hỏng, dẫn đến cung cấp tin tức không chính xác thì độ khẩn cấp sẽ cao hơn tính năng báo cáo kết quả giao dịch theo tháng của product đó.

Khi cân nhắc 3 yếu tố trên, mức độ khẩn cấp cao sẽ bao trùm kết quả thấp hơn, cụ thể một incident có thời gian chấp nhận là high, và tính lặp lại là normal thì độ khẩn cấp vẫn là high.

Ví dụ: Có incident như sau: Khoảng 12h đêm, user submit một registration form thì bị lag và phải mất 50 phút quay mòng mòng thì hệ thống mới tiếp tục hoạt động lại. Như vậy, thời gian chấp nhận incident là high, trong khi tính lặp lại thì là low vì từ trước giờ chưa xảy ra incident này, ảnh hưởng tới nghiệp vụ là high, nghiệp vụ này cần phải kết thúc ngay khi user submit form. Như vậy, mức độ khẩn cấp sẽ được xác định là high.

Sau khi xác định mức độ khẩn cấp, chúng ta sẽ xác định vùng ảnh hưởng của incident. Incident có thể ảnh hưởng tới một số đối tượng sau:

  1. End-user: Số lượng người dùng cuối sử dụng dịch vụ, hệ thống bị tác động bởi incident
  2. Các stakeholders (bên liên quan): Gồm cả các công ty liên quan (Sun*, đối tác, khách hàng, nhà cung cấp) và các vị trí trong công ty liên quan tới incident như CxO (lãnh đạo công ty), PM, Operator (người quản trị hệ thống), Project Team Member…
  3. Chức năng hệ thống: số lượng chức năng bị ảnh hưởng
  4. Nghiệp vụ: Các tác nghiệp và kết quả của chúng
  5. Vốn: Liên quan đến tiền nhu bị mất tiền, số tiền bị sai khác so với mong đợi
  6. Chậm hoặc không thể delivery
  7. Dư luận, cộng đồng: phạm vi bị công khai incident cho cộng đồng
  8. Bị thương hoặc thiệt hại vật chất: Gây hỏng hóc thiết bị, bị thương con người
  9. Thông tin cá nhân bị rò rỉ: Lộ thông tin cá nhân cho các bên khác, internet một cách bất hợp pháp
  10. Thông tin dự án bị rò rỉ: Lộ thông tin phát triển, services của dự án ra bên ngoài internet

Về xác định vùng ảnh hưởng, chúng ta sẽ nghiên cứu ở bài tiếp theo về dấu hiệu nhận biết và cách đánh giá ảnh hưởng. Cũng giống như mức độ khẩn cấp, vùng ảnh hưởng cũng được xác định là [High, Normal, Low].

Sau khi xác định được mức độ khẩn cấp và vùng ảnh hưởng, chúng ta có thể phán đoán code ưu tiên xử lý incident dựa trên bảng sau:

UrgencyImpact PriorityThời gian cần trả lờiThời gian để giải quyết
HighHigh->1: ImmediateLập tức1 tiếng
HighNormal->2: Urgent1 tiếng2 tiếng
NormalHigh->
HighLow->3: High2 tiếng4 tiếng
NormalNormal->
LowHigh->
NormalLow->4: Normal4 tiếng24 tiếng
LowNormal->
LowLow->5: Low24 tiếng1 tuần

Bây giờ, bạn có thể thử phán đoán lại các Code ưu tiên xử lý incident dựa trên các tình huống, hoặc incident thực tế trong dự án của bạn. Nếu bạn đã nhận định được đúng hơn thì xin chúc mừng, bạn đã kết thúc bước đầu tiên để “xử lý incident một cách nhanh chóng và chính xác” rồi đấy.

Bài tiếp theo: Xác định vùng ảnh hưởng – Thông tin cần là những con số