Câu chuyện về sự cố Elasticsearch kéo dài 6 ngày và những bài học đắt giá cho kỹ sư SRE
Molly Struve, Staff Site Reliability Engineer tại Netflix, chia sẻ câu chuyện về sự cố mất dịch vụ kéo dài 6 ngày tại Kenna Security do nâng cấp Elasticsearch. Bài viết đi sâu vào các bài học kỹ thuật quan trọng như FMEA, shadow traffic và kế hoạch rollback, đồng thời nhấn mạnh tầm quan trọng của yếu tố con người, sự an toàn tâm lý và vai trò của lãnh đạo trong việc vượt qua khủng hoảng.

Ai mà không thích một câu chuyện về sự cố (outage) trong thế giới công nghệ? Chúng giống như những bộ phim trinh thám, nơi mọi người cùng nhau tìm ra thủ phạm gây ra lỗi hệ thống. Là do code bị lỗi? Hay do thay đổi cấu hình? Hay lại là DNS - "kẻ thù" của mọi kỹ sư hệ thống?
Molly Struve, hiện là Staff Site Reliability Engineer (SRE) tại Netflix, đã có một bài thuyết trình đầy kịch tính tại QCon San Francisco, chia sẻ về một trong những sự cố lớn nhất trong sự nghiệp của cô: một sự cố kéo dài suốt 6 ngày tại công ty cũ Kenna Security. Câu chuyện không chỉ là những nỗ lực kỹ thuật điên rồ để cứu vãn hệ thống, mà còn chứa đựng những bài học sâu sắc về văn hóa kỹ sư và quản trị khủng hoảng.
Bối cảnh: Một nâng cấp "chết người"
Vào tháng 3 năm 2017, Kenna Security – một công ty an ninh mạng giúp các doanh nghiệp Fortune 500 quản lý rủi ro – quyết định nâng cấp cụm Elasticsearch khổng lồ của mình. Đây là thành phần cốt lõi của nền tảng, cho phép khách hàng tìm kiếm qua hàng terabyte dữ liệu an ninh trong vài giây.
Đội ngũ kỹ sư quyết định nâng từ Elasticsearch phiên bản 2 lên phiên bản 5. Mặc dù con số nhảy vọt 3 đơn vị, nhưng thực tế đây chỉ là một nâng cấp phiên bản lớn (major version bump) do Elasticsearch thay đổi quy tắc đặt tên. Việc chuẩn bị đã được thực hiện kỹ lưỡng trong nhiều tháng và mọi người đều rất hào hứng vì lần nâng cấp trước đã mang lại hiệu suất vượt trội.
Họ chọn thực hiện việc này vào tối thứ Năm để có cả ngày thứ Sáu xử lý các sự cố phát sinh. Quá trình nâng cấp diễn ra suôn sẻ. Tuy nhiên, ngay khi đưa ứng dụng ra khỏi chế độ bảo trì, vấn đề bắt đầu nhen nhóm.
6 ngày trong "địa ngục" kỹ thuật
Sáng thứ Sáu, CPU và tải (load) trên các node Elasticsearch bắt đầu tăng vọt và gây sập hệ thống. Đội ngũ kỹ sư đã bước vào chế độ gỡ rối (debugging) điên cuồng: đọc log, phân tích stack trace, thậm chí phải lấy heap dumps – một biện pháp cuối cùng khi đã tuyệt vọng.
Họ tìm kiếm trên Google, đăng bài lên diễn đàn hỗ trợ của Elastic, nhưng không có giải pháp nào hiệu quả. Trong suốt cuối tuần và sang đến thứ Ba, đội ngũ đã làm việc hơn 15 tiếng mỗi ngày. Khách hàng không thể truy cập dữ liệu, không thể tạo báo cáo. Nền tảng gần như vô dụng.
Cuối cùng, vào thứ Tư, ngày 29/3 – ngày thứ 6 của sự cố – Jason Tedor, một kỹ sư cao cấp của Elastic, đã tìm ra nguyên nhân. Đó là một lỗi (bug) trong mã nguồn của Elasticsearch. Ông cung cấp một bản vá tạm thời và ngay khi áp dụng, hệ thống đã ổn định tức thì. Đội ngũ kỹ sư đã khóc vì xúc động khi trận chiến kết thúc.
Bài học từ phía Kỹ thuật
Molly Struve đã rút ra 3 bài học kỹ thuật cốt lõi từ sự cố này:
1. Luôn có kế hoạch Rollback (Hoàn tác)
Khi thực hiện bất kỳ thay đổi nào, bạn phải biết rõ cách quay lại trạng thái cũ. Trong trường hợp của Kenna, họ không có kế hoạch rollback cho dữ liệu. Họ nghĩ rằng chỉ cần revert code là xong, nhưng quên mất việc dữ liệu trên Elasticsearch phiên bản mới không tương thích ngược với phiên bản cũ.
- Giải pháp: Sử dụng phương pháp FMEA (Failure Mode and Effects Analysis) hoặc "pre-mortem". Trước khi thay đổi, hãy ngồi xuống với đội ngũ, đội "mũ hỗn loạn" và liệt kê mọi cách mà hệ thống có thể thất bại. Hãy chuẩn bị cho kịch bản tồi tệ nhất.
2. Thực hiện kiểm tra hiệu năng (Performance Testing) thường xuyên
Đừng bao giờ tự tin rằng phần mềm phổ rộng sẽ hoạt động tốt với trường hợp sử dụng cụ thể của bạn. Kenna đã bỏ qua bước này vì nghĩ dữ liệu của họ không quá đặc biệt.
- Giải pháp: Sử dụng Shadow traffic (lưu lượng ẩn) hoặc Canary (chim ưng). Hãy mô phỏng lưu lượng thực tế tới hệ thống mới hoặc cấu hình mới để đo lường hiệu suất trước khi triển khai rộng rãi. Đừng chỉ test cho các thay đổi lớn, hãy áp dụng cho cả các cập nhật dependency nhỏ nhặt.
3. Cảnh giác với thiên kiến kinh nghiệm trước đây
Vì lần nâng cấp trước rất thành công, đội ngũ đã mặc định lần này cũng sẽ vậy. Họ cũng tin tưởng quá mức vào phần mềm phổ biến như Elasticsearch mà không nghĩ rằng nó có thể chứa lỗi nghiêm trọng.
- Giải pháp: Duy trì sự hoài nghi lành mạnh. Hãy thêm những lời nhắc nhở nhỏ trong quy trình deploy hoặc PR template để mọi người luôn tỉnh táo, không được chủ quan.
Bài học từ Yếu tố Con người
Molly nhấn mạnh rằng dù kỹ thuật quan trọng, nhưng các bài học về con người mới là thứ giúp họ sống sót qua sự cố này.
4. Mở rộng vòng tròn kết nối (Widen Your Circle)
Đừng ngại nhờ giúp đỡ. Ngay ngày thứ hai của sự cố, Kenna đã đăng bài lên diễn đàn cộng đồng Elastic. Dù việc này khiến họ cảm thấy yếu đuối, nhưng chính hành động đó đã đưa Jason Tedor đến để giải cứu họ.
- Lời khuyên: Hãy mở rộng vòng tròn hỗ trợ sớm nhất có thể. Đừng đợi đến khi lưng chạm tường mới tìm kiếm sự giúp đỡ từ cộng đồng, nhà cung cấp hoặc các đội nội bộ khác.
5. Đội ngũ của bạn quan trọng nhất
Trong 6 ngày khủng hoảng, đội ngũ 3 kỹ sư đã làm việc quên ngủ quên ăn. Thay vì đổ lỗi hay ghen ghét, họ đã cùng nhau chia sẻ mọi cảm xúc và hỗ trợ lẫn nhau.
- Lời khuyên: Khi tuyển dụng, hãy tìm kiếm những người có phẩm chất tốt. Kỹ năng có thể dạy được, nhưng tính cách thì không. Hãy tìm những người mà bạn muốn "chiến đấu" cùng khi lưng chạm tường.
6. Sự hỗ trợ từ Lãnh đạo là then chốt
Đây có lẽ là bài học quan trọng nhất. Giám đốc kỹ thuật (VP of Engineering) của Kenna lúc đó đã đóng vai trò như một "người bảo vệ" (defender). Ông ấy chịu trách nhiệm trả lời các cuộc gọi từ cấp trên, che chắn cho đội ngũ khỏi áp lực chính trị, và luôn tin tưởng rằng đội ngũ sẽ giải quyết được vấn đề.
- Lời khuyên: Các nhà lãnh đạo hãy làm "người cổ vũ" và "người bảo vệ" cho đội ngũ. Hãy tin tưởng vào kỹ sư của bạn. Như một câu nói nổi tiếng: "Mọi người không nhớ bạn đã làm gì, họ nhớ cảm giác bạn mang lại cho họ."
Kết luận
Sự cố Elasticsearch năm 2017 là một vết sẹo lớn nhưng cũng là nền tảng văn hóa kỹ sư vững chắc cho Kenna Security. Nó dạy họ rằng sự cố không phải là điều cấm kỵ cần giấu giếm, mà là cơ hội để học hỏi và đầu tư vào "ngân hàng sự sẵn sàng" của hệ thống.
Hãy ôm lấy những sự cố, học hỏi từ chúng và chia sẻ câu chuyện của bạn. Bởi vì khi mọi thứ đi sai, nếu bạn có đúng đội ngũ, đúng lãnh đạo và tư duy đúng đắn, bạn có thể sống sót qua bất kỳ cơn bão nào.
Bài viết liên quan

Công nghệ
Ai sở hữu mã nguồn do AI viết? Những rủi ro pháp lý khi sử dụng Claude Code và Copilot
28 tháng 4, 2026

Phần mềm
Ứng dụng theo dõi chu kỳ kinh nguyệt bị phát hiện bán dữ liệu nhạy cảm cho Meta
28 tháng 4, 2026

Phần mềm
Kỹ thuật PhantomRPC: Lỗ hổng kiến trúc Windows cho phép nâng đặc quyền chưa được vá
28 tháng 4, 2026
