Phân tích hậu sự cố về vụ việc Kagi tuần trước
(status.kagi.com)Khắc phục sự cố mất ổn định dịch vụ Kagi.com
- Đang điều tra - Sự cố phát sinh sau khi triển khai và đội ngũ đang xử lý. (12 tháng 1, 16:45 UTC)
- Đang giám sát - Đã hoàn tác thay đổi cấu hình được cho là nguyên nhân của sự cố và đang tiếp tục giám sát để dịch vụ trở lại bình thường. (12 tháng 1, 18:30 UTC)
- Cập nhật - Để khôi phục hoàn toàn tính ổn định, sẽ tạm thời ngắt lưu lượng và chuyển hướng người dùng đến trang này. Sẽ cung cấp thêm chi tiết khi tình hình tiến triển trong lúc khôi phục tải cho dịch vụ theo cách có kiểm soát. (12 tháng 1, 20:26 UTC)
- Đang giám sát - Lưu lượng đã được khôi phục và đang tiếp tục theo dõi để dịch vụ trở lại hoàn toàn bình thường. (12 tháng 1, 21:14 UTC)
- Đã giải quyết - Tất cả dịch vụ đang hoạt động bình thường. Bày tỏ lời cảm ơn tới người dùng đã chờ trong lúc sự cố được khắc phục.
Phân tích hậu sự cố
- Zac, lãnh đạo kỹ thuật của Kagi, đã chia sẻ bản phân tích hậu sự cố chi tiết về đợt gián đoạn dịch vụ tuần trước.
- Để ứng phó với sự cố này, kỹ sư cấp cao Seth và kỹ sư DevOps Luan đã cùng phối hợp xử lý.
- Có những tác nhân lạm dụng dịch vụ và khai thác các điểm nghẽn của hạ tầng; nhóm đã thực hiện các biện pháp giảm thiểu ngay lập tức và đang cải thiện nhiều khía cạnh trong mã nguồn cũng như truyền thông.
Diễn biến sự cố
- Khoảng 5 giờ 30 chiều ngày 12 tháng 1, nhóm nhận biết có vấn đề hạ tầng thông qua giám sát nội bộ và các báo cáo sự cố từ người dùng.
- Bản chất của sự cố khiến người dùng ở nhiều khu vực gặp tình trạng tải chậm hoặc hết thời gian chờ trang.
- Việc xử lý mất khá nhiều thời gian, và bài viết giải thích bối cảnh, diễn tiến cũng như kế hoạch sắp tới.
Quá trình khắc phục sự cố kỹ thuật
- Ban đầu, sự cố xảy ra trùng với việc vô tình nâng cấp thêm tài nguyên RAM cho VM.
- Hệ thống giám sát báo cáo độ trễ cao và vấn đề với connection pool cơ sở dữ liệu của ứng dụng.
- Connection pool đã đạt trạng thái bão hòa, nghĩa là tổng số kết nối đã vượt quá giới hạn kết nối tối đa được cấu hình.
- Trong lúc đánh giá tình trạng nội bộ của cơ sở dữ liệu và hiệu năng truy vấn, nhóm đã thử thay thế một số instance để xem có giúp giảm tắc nghẽn hay không.
- Việc thay thế một phần instance có vẻ hữu ích, nên nhóm đã tạm dừng lưu lượng người dùng để đặt lại hoàn toàn tất cả connection pool cùng lúc.
- Khi xem xét trạng thái cơ sở dữ liệu, nguyên nhân gốc đã trở nên rõ ràng: mức độ tranh chấp cao trên các hàng trong bảng người dùng.
- Sự tranh chấp này làm tăng mạnh độ trễ ghi, tạo backpressure lên connection pool của ứng dụng, và cuối cùng làm cạn kiệt toàn bộ các kết nối khả dụng.
- Từ trước đến nay, Kagi sử dụng cơ sở dữ liệu single-core rẻ nhất có trên GCP, điều này luôn tiềm ẩn nguy cơ khiến cơ sở dữ liệu dễ bị tê liệt.
- Nhóm đã xác định được các tác nhân xấu, bao gồm những tài khoản được tạo trong vòng 24 giờ và một tài khoản người dùng duy nhất đã thực hiện hơn 60.000 lượt tìm kiếm trong thời gian ngắn.
- Nhóm đã gỡ quyền tìm kiếm của tài khoản đó và phát hành một hotfix để vô hiệu hóa thao tác ghi cụ thể gây ra vấn đề.
- Đến nửa đêm, sự cố đã được giải quyết hoàn toàn, và nhóm tiếp tục giám sát chặt chẽ các tín hiệu cho thấy những tác nhân này quay trở lại.
Hành động tiếp theo
- Nhóm đã rút ra nhiều bài học từ sự cố này và đã bắt đầu triển khai ngay các kế hoạch nhằm tăng cường hệ thống hơn nữa cũng như cải thiện quy trình truyền thông khi xảy ra sự cố.
- Trước hết, nhóm thừa nhận rằng các cập nhật trên trang trạng thái đã không đủ nhanh.
- Nhóm sẽ chuyển sang một nền tảng trang trạng thái cho phép công khai giám sát nội bộ tự động tới người dùng dễ dàng hơn, ताकि người dùng có thể nắm tình trạng sức khỏe của nền tảng theo thời gian thực.
- Nhóm đang trực tiếp giảm thiểu các truy vấn gây ra vấn đề và chạy kiểm thử tải để xem còn các điểm yếu tương tự nào khác hay không.
- Nhóm sẽ cài đặt thêm giám sát để nhanh hơn trong việc chỉ đúng vị trí cần chú ý trong hạ tầng, tránh lãng phí thời gian đuổi theo tín hiệu sai như lần này.
- Nhóm đang tăng cường các hệ thống phát hiện kiểu lạm dụng này; vì chúng không chỉ ảnh hưởng hiệu năng mà còn trực tiếp làm phát sinh chi phí, nên cần thiết lập các giới hạn tự động để thực thi.
- Các giới hạn mới đã được áp dụng ngay tại thời điểm bài viết này được đăng, và nhóm sẽ theo dõi tác động của chúng cũng như tiếp tục điều chỉnh khi cần.
- Nếu bạn cho rằng quyền truy cập vào Kagi của mình bị chặn nhầm, hãy liên hệ support@kagi.com.
Ý kiến của GN⁺
- Kagi đã gặp vấn đề độ trễ ghi do tranh chấp hàng trong bảng người dùng, điều này tạo backpressure lên connection pool của ứng dụng và dẫn đến gián đoạn dịch vụ.
- Vấn đề này là hệ quả của rủi ro phát sinh từ việc Kagi sử dụng cơ sở dữ liệu single-core rẻ nhất trên GCP.
- Thông qua sự cố này, đội ngũ Kagi cho thấy nỗ lực nâng cao tính ổn định và minh bạch của dịch vụ bằng cách tăng cường hệ thống, cải thiện giao tiếp với người dùng và thiết lập các giới hạn tự động để ngăn chặn lạm dụng. Những nỗ lực này phản ánh cam kết của Kagi trong việc cung cấp một dịch vụ đáng tin cậy hơn cho người dùng.
1 bình luận
Ý kiến trên Hacker News
Ban đầu, việc nâng cấp hạ tầng bằng cách thêm RAM cho VM và sự cố xảy ra đúng cùng thời điểm hóa ra hoàn toàn là ngẫu nhiên, nhưng những “trùng hợp” như vậy thực sự xảy ra rất thường xuyên và khiến người ta nghi ngờ chính sự tồn tại của chúng trong lúc truy tìm vấn đề
Nếu hoảng loạn trong trạng thái đó, cuối cùng bạn sẽ đẩy vào một bản sửa khẩn cấp (hotfix) làm hỏng thứ khác, và từ đó mọi chuyện trở nên đau đớn hơn nhiều
Định luật Murphy thật tàn nhẫn với quản trị viên hệ thống và lập trình viên
Tôi có một câu rất thích: “Nếu bạn không biết vì sao/bằng cách nào mình đã sửa được, thì có khi thực ra bạn chưa sửa được gì cả”
“May mắn là” nó không liên quan đến truy vấn của tôi, nhưng hai sự trùng hợp kiểu này chồng lên nhau thì thật sự đáng sợ
Sau khi trải qua đủ nhiều chuyện như thế, tôi hình thành thói quen nghi ngờ nhiều giả định hơn và không đánh dấu những thứ chưa được kiểm chứng là dữ liệu đã xác nhận
Nó không loại bỏ hoàn toàn thiên kiến và kết luận vội vàng, nhưng có ích; giữ được tư duy cởi mở là việc khá khó
Một năng lực quan trọng của kỹ sư là khả năng suy luận phản biện về các thay đổi ứng phó sự cố, debug và “kiểm thử trong trạng thái cô lập”. Việc này khó hơn vẻ ngoài rất nhiều và thường gần với năng lực của kỹ sư senior
Tôi là một trong những người đã báo vấn đề này trên Discord. Tôi thích Kagi, nhưng khá thất vọng khi trang trạng thái lại hiển thị mọi thứ bình thường
Trong một sự cố có ảnh hưởng đến người dùng thực tế, việc trang trạng thái dường như không phải ưu tiên khiến tôi thấy bất an, và hy vọng về sau nó sẽ được cập nhật chính xác
Những dịch vụ mà trước đây tôi phụ thuộc nhiều, chẳng hạn GitHub, cập nhật trang trạng thái ngay lập tức, nên tôi có thể yên tâm rằng vấn đề không nằm ở thiết bị của mình mà là vấn đề phía dịch vụ đã được nhận biết
Lần này, hôm đó tôi cần tìm một cửa hàng tạp hóa gần đó còn mở trước khi tuyết rơi, nhưng cuối cùng phải dùng Google nên hơi thất vọng
Dù vậy, 99,9% thời gian dùng Kagi vẫn tốt hơn Google, nên tôi sẽ tiếp tục sử dụng, và hy vọng họ chuyển mã trang trạng thái sang dịch vụ/nền tảng khác như đã nói trong phân tích hậu sự cố
Cuối cùng, việc đăng gì đó lên trang trạng thái tự nó trở thành một cuộc trao đổi, và cuộc trao đổi đó tiêu tốn thời gian cùng sự chú ý của kỹ sư, khiến việc khắc phục sự cố bị chậm lại tương ứng
Cần cân bằng giữa truyền thông và khôi phục thực tế, nhưng không phải lúc nào đáp án đúng cũng rõ ràng
Nếu có đủ người, một Technical Incident Manager có thể phụ trách liên lạc và bổ sung thêm kỹ sư cho phần truyền thông, nhưng không phải lúc nào cũng làm được. Một số hệ thống đặc thù, thiếu tài liệu và cũng thiếu đo lường
Cá nhân tôi thích cách ngay khi thấy dấu hiệu vấn đề thì đăng một thông báo lớn nhưng mơ hồ kiểu “đang điều tra vấn đề có thể xảy ra”, rồi sau đó bổ sung chi tiết hoặc rút lại. Nhưng các công ty tôi từng làm không thích ý tưởng đó
Khi đó tôi bị Kagi thu hút mạnh, và đã thử dùng qua lại cho một số truy vấn, nhưng khi LLM, Perplexity và Google ngày càng thường trả lời ngay trên trang tìm kiếm, không còn nhiều truy vấn để tôi dùng Kagi
Nếu Kagi bằng cách nào đó hợp nhất với Perplexity thì có lẽ sẽ khá thú vị
Thậm chí nhiều trường hợp còn không hiển thị cho đến hết
Sự cố này quen thuộc đến mức đáng ngạc nhiên
Cá nhân tôi đã xử lý đúng kiểu sự cố này nhiều lần hơn mức tôi muốn thừa nhận, và giống đội Kagi, tôi cũng từng sa vào hang thỏ mang tên trạng thái connection pool cơ sở dữ liệu, thử cùng các biện pháp giảm nhẹ như ném thêm instance mới vào hoặc tin rằng “reset” lưu lượng sẽ giải quyết được, nhưng đều vô ích
Trong những sự cố kiểu này, các chỉ số bão hòa thông thường của cơ sở dữ liệu như mức dùng CPU, IOPS... không dao động nhiều, điều đó cũng chẳng giúp ích gì. Độ trễ truy vấn trông có vẻ cao, nhưng bạn lại nghĩ “CPU và IOPS vẫn còn dư...”, rồi như mọi khi, bỏ lỡ việc đang có tranh chấp khóa ẩn bên dưới
Theo kinh nghiệm, 98% dấu hiệu bất thường của connection pool DB bắt nguồn từ chính bất thường của DB. Tôi không biết Kagi dùng cơ sở dữ liệu quan hệ nào, nhưng tôi rất khuyên nên vẽ biểu đồ độ trễ I/O toàn cục của DB (giây/giây), thời gian lấy khóa toàn cục (giây/giây), và thời gian thực thi theo từng truy vấn đã chuẩn hóa (giây/giây)
Thêm biểu đồ mức dùng CPU vào đó sẽ thành một dashboard có thể nhanh chóng nhận diện phần lớn vấn đề hiệu năng quy mô lớn
Riêng việc truy vấn tìm kiếm lại gây ra ghi vào cơ sở dữ liệu quan hệ thì hơi bất ngờ. Tôi vốn nghĩ cơ sở dữ liệu quan hệ chỉ dùng cho những thứ như thiết lập người dùng, quản lý đăng nhập
Nếu Kagi đang làm tổng hợp mức sử dụng, ví dụ tăng counter, trong cơ sở dữ liệu quan hệ, thì đó là một chế độ lỗi rất điển hình sẽ bùng nổ khi quy mô tăng lên
Có thể có các thao tác ghi gián tiếp do tìm kiếm, như khi chặn kết quả tìm kiếm, và tất nhiên cũng có lịch sử truy cập hoặc phân tích
Dù vậy, vẫn không rõ thứ gì có thể gây ra tranh chấp khóa ghi cho mỗi lượt tìm kiếm
Đây là chuyện mà mọi startup rồi cũng sẽ gặp vào một lúc nào đó. Tôi từng trải qua và nó thực sự rất đau đớn
Đôi khi không có đủ thời gian hoặc tài nguyên để xây dựng năng lực ngăn chặn những vấn đề như vậy, và đôi khi thậm chí còn không nghĩ rằng một vấn đề cụ thể có thể xảy ra cho đến khi bị đánh úp
Tính minh bạch cũng quan trọng, học hỏi cũng quan trọng, nhưng đôi khi bồi thường cũng quan trọng. Kagi nên cân nhắc cung cấp credit tìm kiếm cho khoảng thời gian người dùng không thể sử dụng dịch vụ
Đặc biệt là khi họ tự thừa nhận rằng phản ứng theo thời gian thực còn thiếu sót
Sự cố của một dịch vụ trả phí không giống sự cố của một dịch vụ mà “người dùng là sản phẩm”
Nó cho thấy khá nhiều về mức độ khả năng quan sát đối với các hệ thống nội bộ
Nói rằng lẽ ra họ phải nhận ra sớm hơn thì dễ, nhưng nếu có dashboard Datadog và các truy vấn Splunk phù hợp thì vấn đề hẳn đã hiện rõ nhanh hơn nhiều
Hy vọng họ xem việc này là cơ hội học hỏi và đầu tư vào giám sát tốt hơn
Chuyện này 100% là một trải nghiệm để học hỏi, nhưng tôi có thể bổ sung thêm chút bối cảnh về khả năng quan sát
Kagi là một đội ngũ nhỏ; về thực chất chỉ có 3 người có thể ứng phó với các sự kiện kiểu này, lại phân tán ở 3 múi giờ. Với tôi và lập trình viên nòng cốt, đây là chặng đầu trong sự nghiệp web, nên chúng tôi không phải là những cựu binh Silicon Valley đã trải qua hết mọi thứ
Việc còn nhiều thứ phải học là điều hiển nhiên, nhưng vì đã xây dựng Kagi từ con số 0, tôi vẫn tự hào về chặng đường đã đi và hướng đi sắp tới
Khả năng quan sát là thứ chúng tôi bắt đầu xử lý nghiêm túc hơn từ khoảng 6 tháng trước. Hiện đã có nhiều dashboard, cũng như các cảnh báo đi thẳng vào kênh chat của công ty để gọi đúng người liên quan
Với tư cách người phụ trách chính về DB, Query Insights của GCP giúp ích rất nhiều. Trong lúc sự cố, hệ thống giám sát cũng đã báo động và Query Insights cũng chỉ ra truy vấn “thủ phạm”, nhưng dù có mọi hệ thống giám sát trên đời, bạn vẫn có thể thiếu kinh nghiệm để diễn giải nguyên nhân gốc rễ hoặc biện pháp giảm thiểu hiệu quả nhất
Nói cách khác, nếu không cẩn thận, chúng tôi vẫn còn thiếu sự khôn ngoan để không tự bị những gì hệ thống của mình hiển thị gaslight. Nhìn lại thì có thể nói GCP Query Insights đã chính xác 100% và đó không phải là lỗi trong không gian ứng dụng
Nhờ tăng trưởng, giờ chúng tôi đã có thể mở rộng đội ngũ đáng kể; trước đây chúng tôi cũng từng nhận tư vấn SRE và trong tương lai sẽ tiếp tục cải thiện bằng cách nhận thêm hỗ trợ toàn thời gian hoặc bán thời gian
Ý là một người dùng chạy scraper mà làm dịch vụ sập suốt 7 tiếng sao? Tôi biết từ bên ngoài thì rất dễ nói “lẽ ra phải dự đoán được”, nhưng thật kỳ lạ là trong quá trình kiểm thử không ai hỏi “nếu có cực nhiều lượt tìm kiếm thì chuyện gì sẽ xảy ra?”
https://news.ycombinator.com/item?id=39019936
Tóm lại, chúng tôi là một đội còn trẻ với rất ít nhân sự nòng cốt, và ai cũng kiêm nhiều vai trò cùng lúc. Hiện vẫn chưa có đội SRE chuyên trách
Về câu hỏi “nếu có cực nhiều lượt tìm kiếm thì chuyện gì sẽ xảy ra?”, nếu xem https://kagi.com/stats thì có thể thấy đã có “nhiều lượt tìm kiếm” đang diễn ra, gần 400 nghìn lượt mỗi ngày. Trong vận hành hằng ngày, hệ thống chạy với dung lượng dự phòng đủ lớn và cũng có một số biện pháp tự động mở rộng
Vấn đề nằm ở các chi tiết khi một số người dùng khai thác một trường hợp bệnh lý. Vì thiếu kinh nghiệm, chúng tôi không biết mình có thể dự đoán và mô phỏng trước loại lưu lượng tự nhiên hay lưu lượng bệnh lý nào
Mô phỏng tải với 20 nghìn người dùng tìm kiếm đồng thời nghe như một thử nghiệm đáng làm từ sớm, và chúng tôi cũng đã làm những thứ tương tự. Nhưng nhìn vào sự cố này thì kể cả vậy cũng khó bắt được vấn đề này
Từ trước đến nay đã có khoảng 10 người chạy trình quét bảo mật lên dịch vụ đang vận hành, và lưu lượng khi đó còn lớn hơn sự cố lần này
Cân bằng kiểu phát triển này trong lúc vẫn phải xây dựng tính năng là rất khó, và rõ ràng chúng tôi lẽ ra phải làm nhiều hơn. Như đã nói ở bài khác, trong thời gian tới chúng tôi sẽ mở rộng đội ngũ để không bị dàn trải quá mỏng cho những nỗ lực như vậy
Nhìn lại thì có rất nhiều điều có thể nói, nhưng tôi hy vọng đã truyền đạt minh bạch hơn một chút về việc chúng tôi đã đi đến đây như thế nào
Nhất là nếu đây là lần đầu có người đánh họ theo cách đó
Để so sánh, hệ thống tôi phụ trách không ở quy mô FAANG, nhưng xét theo tốc độ yêu cầu thì chắc chắn lớn hơn Kagi. Kagi rồi sẽ học rất nhanh, và trong lúc đó nếu các vấn đề như thế này còn xảy ra thì tôi nghĩ ở mức nào đó cũng không sao. Đó cũng là dấu hiệu cho thấy họ đang đi đúng hướng
Là người dùng trả phí của Kagi, sau khi trải qua downtime tôi mới nhận ra mình đã xem độ tin cậy của Google là điều hiển nhiên đến mức nào
Trong 20 năm qua, Google gần như chưa từng sập với tôi, ngoại trừ khoảng một lần. Mất quyền truy cập vào công cụ tìm kiếm là chuyện khá nghiêm trọng
Tôi thực sự thích Kagi nên mới trả tiền, nhưng gặp downtime ngay tháng thứ hai sử dụng thì khá khó chịu. Tôi thích các bản phân tích sự cố, nhưng hy vọng không phải đọc chúng
Dù vậy, tôi kỳ vọng trải nghiệm lần này sẽ giúp Kagi trở thành một dịch vụ linh hoạt và đáng tin cậy hơn
Công cụ tìm kiếm không phải là dịch vụ có hiệu ứng khóa chân như nhà cung cấp email hay ISP
Tôi rõ ràng đã phụ thuộc vào việc Kagi nhanh và hoạt động tốt ở mọi nơi
Tôi nhớ lần chạy proof of concept cho một công cụ networking mới tại một khách hàng. Khoảng 2 phút sau khi chạy, toàn bộ mạng của khách hàng sập
Chúng tôi ở trong một khu sandbox tách biệt nên sản phẩm của chúng tôi không có cách nào gây ra sự cố toàn mạng, nhưng trong đầu tôi cứ nghĩ “không thể nào đâu, đúng không… đúng không?!?!”
“Sau đó chúng tôi đã liên lạc được với tài khoản bị chặn, và tài khoản đó tuyên bố rằng họ đã dùng tài khoản để tự động scrape kết quả của chúng tôi; đây là việc không được điều khoản cho phép.”
Cần áp dụng giới hạn QPS cho mọi yêu cầu RPC/API/HTTP đầu vào có thể, đặc biệt là các yêu cầu công khai
Chúng tôi từng có một chức năng tìm kiếm kèm tự động hoàn thành, và để hỗ trợ người dùng gõ nhanh, chúng tôi đã cố ý gỡ bỏ một phần giới hạn tốc độ của endpoint đó
Một ngày nọ, khoảng 6 giờ sáng, có ai đó ở Tennessee đi làm và đặt ví lên bàn phím; chiếc ví đè giữ một phím, khiến mỗi lần nhập phím bắt đầu gọi API
Dĩ nhiên, sau khoảng 15 phút thì DB trở nên rất bất ổn, độ trễ DB tăng quá lớn đến mức một web server bị crash. Sự cố dây chuyền tiếp diễn và toàn bộ cụm vận hành bị sập
Khỏi phải nói, ngay trong ngày hôm đó giới hạn tốc độ đã được thêm lại