Cách xác thực tín hiệu đám đông cải thiện phát hiện sự cố gián đoạn

Những gì tín hiệu đám đông bổ sung cho việc phát hiện sự cố gián đoạn

Giám sát dịch vụ truyền thống là không thể thiếu, nhưng không có một điểm quan sát đơn lẻ nào quan sát được mọi chế độ lỗi. Hướng dẫn Site Reliability Engineering của Google phân biệt giám sát hộp đen — các triệu chứng được quan sát từ bên ngoài — với giám sát hộp trắng dựa trên thiết bị đo nội bộ. Hướng dẫn lưu ý rằng một góc nhìn chỉ hộp trắng có thể bỏ sót các yêu cầu thất bại trước khi đến đích, chẳng hạn bị chặn bởi lỗi DNS hoặc mất do sự cố máy chủ. Đối với paging, nó khuyến nghị các tín hiệu đơn giản, bền bỉ đại diện cho một lỗi rõ ràng hiển thị với người dùng. [1]

Các báo cáo từ đám đông bổ sung một góc nhìn bên ngoài: những người bị ảnh hưởng mô tả trải nghiệm khi nó xảy ra. Điều này có thể liên quan khi một triệu chứng có thể nhìn thấy mang tính khu vực, phụ thuộc vào mạng, phụ thuộc vào thiết bị, hoặc phụ thuộc vào một hành trình người dùng mà một kiểm tra tính sẵn sàng cơ bản không xét tới. Nó cũng có thể gợi ý việc điều tra do con người thực hiện khi một sự cố không rõ ràng.

Nghiên cứu so sánh các biện pháp tự báo cáo và tự động qua sáu sự kiện mất kết nối Internet lớn ở Đức đi đến kết luận có giới hạn tương tự. Các tác giả nhận thấy việc phát hiện tự động có thể khó khăn do khối lượng và sự thiếu chính xác vốn có; một khi một sự kiện được biết tới công khai qua tự báo cáo, đo lường khách quan có thể giúp nắm bắt các chiều thời gian và không gian của nó. Họ đề xuất thu thập từ đám đông như một sự bổ sung và điểm khởi đầu cho phân tích tiếp theo — không phải là sự thay thế. [2]

Sự phân biệt đó quan trọng. Sự tăng đột biến trong số báo cáo có nghĩa là mọi người đang gặp phải, hoặc tin rằng họ đang gặp phải, một vấn đề. Nó không tự nó chứng minh rằng một nhà cung cấp không khả dụng trên toàn cầu, xác định thành phần chịu trách nhiệm, hay cho thấy mọi người dùng đều bị ảnh hưởng.

Việc xác thực biến các báo cáo thành một tập bằng chứng

Xác thực là quy trình biến một tín hiệu ban đầu thành một đánh giá sẵn sàng để ra quyết định. Hướng dẫn ứng phó sự cố hiện tại của NIST nói rằng các sự kiện có khả năng bất lợi nên được phân tích để mô tả chúng và xác định khi nào một sự cố đã xảy ra. Nó cũng thừa nhận rằng độ trung thực của sự kiện thay đổi, các bất thường có thể có lời giải thích lành tính, và thông tin nên được tương quan từ nhiều nguồn. [3]

Khi áp dụng cho sự cố dịch vụ, điều này có nghĩa là tìm sự xác nhận có tính độc lập có ý nghĩa so với luồng báo cáo. So sánh thời điểm và mật độ báo cáo với tính sẵn sàng hoặc hiệu năng được quan sát từ bên ngoài, rồi đánh giá xem mô hình đó có bị giới hạn ở một vùng địa lý, mạng, thiết bị, tính năng hay hành trình của khách hàng hay không. Mục đích là phân biệt một tín hiệu tác động người dùng có cơ sở và có phạm vi cụ thể với nhiễu hoặc một điều kiện cục bộ.

Sách hướng dẫn ứng phó sự cố của CISA mô tả cùng một cách tiếp cận phân tích: loại bỏ mâu thuẫn giữa các sự cố bị nghi ngờ và các hoạt động được ủy quyền, thu thập dữ liệu cần thiết để xác minh và phân loại, tương quan thông tin, và đánh giá hoạt động bất thường so với một đường cơ sở đã biết. [4] Đối với vận hành khi có sự cố gián đoạn, điều này hỗ trợ sự tách bạch rõ ràng giữa phát hiện, xác thực, phân loại và phân tích nguyên nhân gốc rễ. Việc kết hợp các giai đoạn đó có thể dẫn đến cả tuyên bố sự cố quá sớm và chậm nhận ra tác động thực sự đến người dùng.

Một mô hình ra quyết định dựa trên bằng chứng

Các nhóm không cần một ngưỡng số lượng báo cáo chung cho mọi tình huống để sử dụng tín hiệu đám đông một cách có trách nhiệm. Ngưỡng và quy tắc leo thang nên phản ánh dịch vụ, lưu lượng bình thường, quy mô người dùng, và chi phí của báo động sai so với phản ứng chậm. Các câu hỏi sau đây cung cấp một mô hình minh bạch mà không quy định một phương pháp độc quyền.

Tín hiệu có độc lập và mạch lạc không? Các báo cáo lặp lại đến gần cùng thời điểm nhưng xuất phát từ một bối cảnh chung hẹp có thể mô tả một lỗi cục bộ. Một mô hình xuất hiện trên các bối cảnh khác nhau mang thông tin hơn. Tính độc lập nhằm tránh tự tin quá mức khi nhiều quan sát có thể có cùng nguồn gốc cơ bản.

Có bằng chứng kỹ thuật xác nhận không? Các kiểm tra uptime công khai có thể gửi yêu cầu từ nhiều địa điểm trên toàn thế giới và đánh giá thành công bằng mã HTTP và nội dung phản hồi yêu cầu. Các chẩn đoán lỗi được ghi nhận của chúng cũng có thể giúp phân biệt lỗi kết nối với hết thời gian chờ của ứng dụng. [5] Những kiểm tra này là bổ sung hữu ích, nhưng không phải là một bài kiểm tra trải nghiệm người dùng toàn diện: theo mặc định chúng không tải tài nguyên trang hay thực thi JavaScript. [5]

Phạm vi có thể là gì? Phạm vi nên được đánh giá, không nên giả định. So sánh khi báo cáo bắt đầu, nơi chúng xuất hiện, quy trình làm việc nào bị ảnh hưởng, và liệu các kiểm tra độc lập có cho thấy một triệu chứng liên quan hay không. Hệ thống Internet Outage Detection and Analysis của Georgia Tech minh họa giá trị của việc kết hợp các phép đo khác biệt: dữ liệu định tuyến BGP, lưu lượng nền Internet, và thăm dò chủ động. [6]

Quyết định nào theo sau? Phản ứng nên phù hợp với bằng chứng: giữ lại một tín hiệu yếu để quan sát, mở điều tra khi có bằng chứng xác thực có cơ sở, hoặc thông báo một sự gián đoạn có phạm vi khi bằng chứng hiện có hỗ trợ điều đó. Nguyên nhân gốc rễ, thời gian khôi phục và tác động tới toàn bộ người dùng nên vẫn được nêu kèm điều kiện cho đến khi được thiết lập độc lập.

Phương pháp luận và lưu ý

Bài viết này tổng hợp hướng dẫn hiện tại từ Google SRE, NIST, CISA, tài liệu Google Cloud, một nghiên cứu học thuật so sánh đo lường sự cố tự báo cáo và tự động, và phương pháp IODA của Georgia Tech. Nó sử dụng các nguồn này để mô tả các nguyên tắc bằng chứng chung, không nhằm tiết lộ hoặc suy diễn bất kỳ quy trình phát hiện, chấm điểm hay leo thang nội bộ nào của nền tảng nào.

Xác thực tín hiệu đám đông có giới hạn. Sự công khai, ngôn ngữ, quyền truy cập kênh báo cáo, và các nhóm tham gia tích cực có thể định hình khối lượng báo cáo. Một vấn đề nghiêm trọng cũng có thể bị báo cáo thiếu khi những người bị ảnh hưởng không thể tiếp cận kênh báo cáo. Các kiểm tra kỹ thuật bị giới hạn bởi vị trí, giao thức, trạng thái xác thực và đường dẫn thử nghiệm của chúng. Một đánh giá nên nêu rõ những gì đã được quan sát, phạm vi được đánh giá, cửa sổ thời gian, và những gì vẫn còn chưa biết.

Quan điểm SID Monitor

SID Monitor coi thông tin tình báo gián đoạn là một đầu vào thực tiễn cho năng lực uptime: bằng chứng rõ ràng hơn có thể giúp các đội kỹ thuật và điều hành phân loại mức độ ảnh hưởng, giao tiếp với mức độ tự tin phù hợp, và rút bài học từ khoảng cách giữa sức khỏe hệ thống và trải nghiệm người dùng. Status Is Down công khai báo cáo phạm vi bao phủ hơn 2 triệu website, hơn 13,500 dịch vụ, hơn 20,000 sự cố lịch sử được ghi nhận và hơn 60 hạng mục. [7] Đây là các số liệu tổng hợp công khai về phạm vi, không phải là thước đo của một quý cụ thể. Đối với bản tóm tắt Q3 này, SID Monitor không đưa ra khẳng định về các xu hướng quý không quan sát được, tần suất sự cố, hay thay đổi hiệu năng.

Mục tiêu không phải là nhiều cảnh báo hơn. Mà là những quyết định có nền tảng tốt hơn: sử dụng tín hiệu đám đông để xác định tác động người dùng có khả năng xảy ra, xác thực chúng một cách độc lập, giữ cho độ không chắc chắn luôn minh bạch, và hỗ trợ khôi phục cùng thiết kế dịch vụ có khả năng phục hồi tốt hơn.

Tài liệu tham khảo

1. Google SRE: Monitoring Distributed Systems — Google Site Reliability Engineering
2. Detecting a Crisis: Comparison of Self-Reported vs. Automated Internet Outage Measuring Methods — Gesellschaft für Informatik
3. NIST SP 800-61r3: Incident Response Recommendations and Considerations for Cyber Risk Management — National Institute of Standards and Technology
4. CISA Federal Government Cybersecurity Incident and Vulnerability Response Playbooks — Cybersecurity and Infrastructure Security Agency
5. Google Cloud: Create Public Uptime Checks — Google Cloud
6. IODA: Internet Outage Detection and Analysis — Georgia Tech IODA
7. Status Is Down — Status Is Down

Tiếp tục khám phá