Tác động của sự cố hệ thống lên con người và cách giảm thiểu áp lực trong DevOps

Trong giới công nghệ, đặc biệt là lĩnh vực DevOps và Site Reliability Engineering (SRE), chúng ta thường nói nhiều về các công cụ, quy trình và mã nguồn. Tuy nhiên, có một khía cạnh ít được đề cập hơn nhưng lại cực kỳ quan trọng: đó là tác động của các sự cố hệ thống (incidents) lên con người.

Kyle Lexmond, một kỹ sư sản xuất tại Meta (người từng làm việc tại những gã khổng lồ như Twitter, Amazon và Facebook), đã có một bài thuyết trình sâu sắc về chủ đề này. Ông chia sẻ không chỉ về kỹ thuật xử lý sự cố, mà còn về cách quản lý áp lực, quá tải nhận thức và cách xây dựng một văn hóa hỗ trợ đội ngũ kỹ thuật trong những khắc nghiệt nhất.

Định nghĩa lại về sự cố (Incident)

Trước khi đi sâu vào các câu chuyện, Lexmond đề cập đến việc định nghĩa thế nào là một sự cố. Theo ông, một sự cố thường bao gồm ba yếu tố: một sự kiện ảnh hưởng đến doanh nghiệp (các chỉ số đang đi sai hướng), yêu cầu phản hồi ngay lập tức, và cần được giảm thiểu (mitigation) để đưa mọi thứ trở lại bình thường.

Một điểm quan trọng mà ông nhấn mạnh là sự khác biệt giữa giảm thiểu (mitigation) và giải quyết nguyên nhân gốc rễ (root-cause resolution). Trong lúc xử lý sự cố, mục tiêu ưu tiên hàng đầu là dừng lại tác động đến người dùng, chứ chưa hẳn là sửa chữa triệt để vấn đề ngay lập tức.

Áp lực của một sự cố tỷ lệ thuận với mức độ nghiêm trọng của nó và mức độ trách nhiệm của bạn trong việc khắc phục. Áp lực này đến từ nhiều nguồn: lòng tự trọng cá nhân, trách nhiệm nghề nghiệp với các đồng nghiệp phụ thuộc vào dịch vụ của bạn, và cả uy tín của công ty trước công chúng.

Câu chuyện 1: Sự cố quá tải lan truyền (The Rolling Overload)

Lexmond kể lại một trong những sự cố đầu tiên trong sự nghiệp, một trải nghiệm để lại dấu ấn sâu sắc về mặt tâm lý.

Vào một buổi sáng, khi đang ở bờ Đông nước Mỹ chuẩn bị đi sân bay, anh nhận được cảnh báo trên IRC rằng một nửa số máy chủ trong một Availability Zone (AZ) đã bị sập. Ban đầu, anh nghĩ đó là sự cố mất điện và chạy theo runbook (sách hướng dẫn) để khắc phục. Tuy nhiên, mỗi lần sửa xong, hệ thống lại sập sau 5 phút.

Vấn đề thực ra không phải là mất điện, mà là một sự cố quá tải lan truyền. Khi các máy chủ mới được đưa lên lại, chúng ngay lập tức bị sập vì lượng truy cập quá lớn. Sự cố nhanh chóng lan sang các AZ khác và các khu vực khác.

Trong suốt 8 tiếng tiếp theo, Lexmond và đội ngũ đã vật lộn trong sự bối rối và tuyệt vọng. Anh nhớ lại khoảnh khắc ngồi ở ghế sân bay, nhìn những người đồng nghiệp là những chuyên gia xây dựng hệ thống, nhưng không ai hiểu tại sao hệ thống lại hoạt động như vậy. Áp lực lên đến đỉnh điểm khi anh phải gọi điện cho nhân viên hàng không để xin hủy chuyến bay vì đang xử lý sự cố khẩn cấp.

Cuối cùng, sau 8 tiếng, một người đã từng thiết kế hệ thống từ lâu (đã chuyển sang đội khác) được gọi vào. Ông ấy đã đưa ra một giải pháp bất ngờ: thay đổi health check để luôn báo cáo "healthy", ép lưu lượng phân bổ đều. Chỉ trong 15 phút triển khai, hệ thống đã hồi phục.

Bài học rút ra:

• Thiếu nhận thức về tình hình (situational awareness): Lexmond đã quá tập trung vào việc sửa chữa mà không nhận ra sự cố đang lan rộng.
• Chậm trễ trong việc leo thang (escalation): Nếu gọi người thiết kế ban đầu vào sớm hơn, sự cố có thể đã được giải quyết nhanh hơn nhiều.
• Cần chia sẻ trạng thái (shared state): Thời gian quý giá đã bị lãng phí để giải thích lại tình hình cho từng người mới tham gia.

Câu chuyện 2: Sự cố thất bại chỉ số (Metric Failure)

Một vài tháng sau sự cố đầu tiên, Lexmond gây ra một sự cố khác nhưng với kết quả tích cực hơn. Anh đã phê duyệt một Pull Request (PR) để chuyển đổi framework cho một dịch vụ. Sau khi triển khai, đội ngũ cân bằng tải toàn cầu (Global Load Balancer) đã khai báo sự cố vì các chỉ số metric họ dùng để phân phối lưu lượng đã biến mất.

Hệ thống của họ đã tự động chuyển sang chế độ mặc định, khiến một số khu vực bị quá tải trong khi các khu vực khác lại rảnh rỗi. May mắn là Lexmond đã nhận ra vấn đề ngay lập tức, tham gia vào kênh chat của sự cố và yêu cầu hoàn tác (revert) đoạn mã vừa triển khai.

Mặc dù gặp khó khăn với công cụ mới, nhưng nhờ sự hỗ trợ nhanh chóng từ đồng nghiệp, đoạn mã đã được hoàn tác trong vòng 30 phút. Sự cố được giải quyết.

Điều thú vị nhất là phản ứng của đội ngũ cân bằng tải. Thay vì đổ lỗi, họ đã xem xét lại hệ thống của mình để xem tại sao nó lại bị sập khi thiếu dữ liệu đầu vào. Họ đã cập nhật hệ thống để giữ lại giá trị cuối cùng đã biết nếu dữ liệu biến mất và gửi cảnh báo thay vì tự động chuyển sang chế độ xấu. Ba tuần sau, một sự cố tương tự xảy ra với một đội khác, nhưng lần này không có ảnh hưởng nào đến người dùng cuối nhờ bản cập nhật đó.

Bài học rút ra:

• Mỗi sự cố là một cơ hội để học hỏi và cải thiện hệ thống.
• Sự đồng cảm (empathy) và văn hóa không đổ lỗi (blameless culture) giúp mọi người tập trung vào giải quyết vấn đề thay vì tìm kiếm kẻ sai lỗi.

Cách làm cho cuộc sống với sự cố tốt hơn

Dựa trên kinh nghiệm của mình, Lexmond đưa ra một số đề xuất để cải thiện quy trình quản lý sự cố:

Trước khi sự cố xảy ra

• Mô hình phô mai Thụy Sĩ (Swiss Cheese Model): Thiết kế nhiều lớp bảo vệ cho hệ thống. Nếu một lớp thất bại, các lớp khác sẽ ngăn chặn sự cố lan rộng.
• Quản lý rủi ro một cách có ý thức: Xác định các nguồn dữ liệu phụ thuộc và tự hỏi điều gì sẽ xảy ra nếu chúng thất bại.
• Loại bỏ động cơ tránh khai báo sự cố: Đừng trừng phạt các đội ngũ khi họ khai báo sự cố. Khuyến khích khai báo sớm để có thể huy động thêm nguồn lực hỗ trợ. Tại Meta, họ thậm chí có tùy chọn đánh dấu sự cố là "dương tính giả" để tạo an toàn tâm lý.

Trong khi xử lý sự cố

• Phân định rõ vai trò: Cần có một Incident Manager (người quản lý sự cố) riêng biệt để xử lý việc giao tiếp và điều phối, giúp các kỹ sư tập trung hoàn toàn vào việc khắc phục kỹ thuật.
• Chia sẻ thông tin: Sử dụng các tài liệu cộng tác trực tiếp (như Google Docs) để cập nhật tiến trình thực tế. Điều này giúp mọi người nắm bắt tình hình nhanh chóng và hữu ích cho việc xem xét sau sự cố.
• Không đổ lỗi: Tập trung vào việc khắc phục sự cố. Lỗi của con người là điều không thể tránh khỏi, hãy thiết kế hệ thống để chịu đựng được lỗi đó thay vì trừng phạt con người.

Kết luận

Mục tiêu của quản lý sự cố không phải là đưa số lượng sự cố về 0, mà là giảm thiểu các sự cố nghiêm trọng. Chúng ta cần tập trung vào việc rút ngắn thời gian giảm thiểu (time to mitigation).

Quan trọng nhất, hãy luôn nhớ rằng phía sau các màn hình và dòng lệnh là con người. Hãy có sự đồng cảm với những người đang phải chịu áp lực trong "phòng chiến tranh" (war room). Những gì rõ ràng khi nhìn lại (hindsight) thường không hề rõ ràng chút nào trong khoảnh khắc đang xảy ra sự cố. Xây dựng một văn hóa hỗ trợ, không đổ lỗi và học hỏi liên tục là chìa khóa để sống sót và phát triển trong thế giới DevOps đầy biến động.