Giám sát chức năng người dùng nhìn thấy, thêm đủ bằng chứng tài nguyên và ứng dụng để chẩn đoán nó, và chỉ gọi khi các điều kiện yêu cầu hành động của con người kịp thời. Ghép mỗi cảnh báo với một người phụ trách, một bước đầu tiên và leo thang. Trong sự cố, điều phối giảm thiểu, bảo vệ bằng chứng và xác minh khôi phục thông qua hành trình người dùng thực tế.
Bắt đầu với chức năng quan trọng
Một máy chủ phản hồi ping không chứng minh rằng ứng dụng của nó hoạt động. Chọn một hành trình người dùng đại diện, vô hại, chẳng hạn như truy xuất một trang công khai hoặc truy cập một điểm cuối kiểm tra được kiểm soát. Xác định thành công trông như thế nào và tránh các kiểm tra tổng hợp tạo đơn hàng thật, xuất bản nội dung hoặc gửi thông báo khách hàng trong mỗi lần chạy.
Giám sát từ góc độ bên ngoài phù hợp cũng như bên trong ứng dụng. Quan sát bên ngoài có thể tiết lộ các vấn đề truy cập hoặc định tuyến mà máy chủ không thấy. Các phép đo bên trong có thể giải thích tại sao hành trình thất bại. Giữ cả hai góc nhìn kết nối với chức năng thay vì thu thập một bảng điều khiển lớn chỉ vì mọi chỉ số đều có sẵn.
Chọn tín hiệu có giá trị chẩn đoán
Hướng dẫn SRE của Google nhấn mạnh độ trễ, lưu lượng, lỗi và độ bão hòa là các tín hiệu hữu ích cho hệ thống hướng người dùng. Sử dụng chúng để mô tả hành vi: thời gian phản hồi, khối lượng yêu cầu, yêu cầu không thành công và áp lực lên tài nguyên bị hạn chế. Chọn các phép đo phù hợp với ứng dụng thay vì cho rằng một định nghĩa chỉ số phù hợp cho một trang web, một dịch vụ truyền tải và một trình xử lý nền.
Tách hành vi yêu cầu thành công và thất bại khi cần thiết, và xem xét kết quả đuôi chậm thay vì chỉ trung bình. Thêm áp lực bộ nhớ, dung lượng đĩa, độ sâu hàng đợi hoặc giới hạn đặc thù của ứng dụng khi chúng giải thích dịch vụ. Chỉ số CPU cao có thể là bình thường trong công việc hàng loạt hữu ích; hiệu ứng người dùng nhìn thấy quyết định liệu có cần hành động ngay lập tức hay không.
Cấp cho mỗi cảnh báo một hành động và một người phụ trách
Một cảnh báo nên nêu rõ chức năng bị ảnh hưởng, điều kiện quan sát được và kiểm tra đầu tiên hữu ích. Chỉ định một người phụ trách và một lộ trình leo thang trước khi triển khai nó. Phân biệt các điều kiện cần ngắt kịp thời với các mục phù hợp cho đánh giá theo lịch. Các cuộc gọi lặp lại giá trị thấp huấn luyện người vận hành bỏ qua hệ thống và làm cho các tín hiệu quan trọng khó nhận ra hơn.
Sử dụng một đánh giá cảnh báo nhỏ để loại bỏ sự mơ hồ. Bảng minh họa này mô tả các quyết định giám sát tiềm năng, không phải phạm vi hỗ trợ SwissOctet hay cam kết khả dụng. Các ngưỡng cần được kiểm tra dựa trên đường cơ sở thực tế của ứng dụng. Bao gồm một điều kiện khôi phục để người vận hành biết khi nào cảnh báo đã được xóa và những gì vẫn cần xác nhận.
| Điều kiện quan sát được | Phản hồi hữu ích | Ngữ cảnh cần bao gồm |
|---|---|---|
| Hành trình người dùng đại diện thất bại | Đánh giá tác động và giảm thiểu | Điểm cuối bị ảnh hưởng, thời lượng và thay đổi gần đây |
| Đĩa gần đạt giới hạn đã định | Xem xét tăng trưởng và lưu giữ | Khối lượng, tốc độ tăng trưởng và dự phòng an toàn |
| Xác minh sao lưu thất bại | Bảo vệ lộ trình khôi phục | Công việc, điểm sử dụng được cuối cùng và lỗi |
| Độ trễ tăng trong một bản phát hành | Kiểm tra hoặc khôi phục thay đổi | Đường cơ sở, thời gian phát hành và yêu cầu bị ảnh hưởng |
Chuẩn bị một cấu trúc sự cố nhỏ
Một quy trình phản hồi nên dễ hiểu dưới áp lực. Chỉ định một điều phối viên, một người xử lý công việc kỹ thuật và một người chịu trách nhiệm cập nhật khi sự cố đủ lớn để cần các vai trò riêng biệt. Một dự án nhỏ có thể kết hợp các vai trò, nhưng nó vẫn hưởng lợi từ một điểm quyết định rõ ràng. Thống nhất một kênh liên lạc trước khi dịch vụ gặp sự cố.
Tài liệu ứng phó sự cố của Google nhấn mạnh phối hợp và cách tiếp cận ưu tiên giảm thiểu. Áp dụng điều đó ở quy mô phù hợp với dự án: xác định tác động, chọn hành động an toàn và tránh nhiều người vận hành thực hiện các thay đổi xung đột. Ghi lại dòng thời gian và quyết định. Việc tìm kiếm lời giải thích hoàn hảo không nên trì hoãn một biện pháp an toàn khôi phục chức năng bị ảnh hưởng.
Đi qua một tình huống suy giảm cụ thể
Hãy tưởng tượng một trang web trở nên chậm sau một bản phát hành. Kiểm tra bên ngoài cho thấy thời gian hoàn thành tăng, trong khi các phép đo bên trong cho thấy lỗi ứng dụng và công việc cơ sở dữ liệu ngày càng tăng. Điều phối viên tuyên bố một sự cố có giới hạn, bảo vệ bằng chứng và giao một người so sánh bản phát hành với đường cơ sở. Một người khác chuẩn bị lộ trình khôi phục đã kiểm tra thay vì thực hiện các thay đổi cơ sở hạ tầng không liên quan.
Nếu khôi phục an toàn cho trạng thái dữ liệu của ứng dụng, hãy sử dụng nó và quan sát kết quả. Nếu không an toàn, chọn một biện pháp giảm thiểu hẹp hơn được kế hoạch vận hành hỗ trợ. Ghi lại những gì đã thay đổi và khi nào. Một VPS hoặc cổng lớn hơn có thể đáng đánh giá sau này, nhưng quyết định trước mắt nên giải quyết bằng chứng thay vì cho rằng kích thước cơ sở hạ tầng là nguyên nhân.
Bảo vệ bằng chứng và xác minh khôi phục
Nhật ký vận hành và ghi chú sự cố có thể chứa địa chỉ, mã định danh và thông tin khách hàng. Thu thập những gì cuộc điều tra cần, hạn chế quyền truy cập và giữ thông tin xác thực hoặc mã đơn hàng riêng tư ngoài báo cáo được chia sẻ. Đối với một sự cố bảo mật bị nghi ngờ, hãy bảo toàn bằng chứng phù hợp và tuân theo chính sách ứng phó của dự án thay vì phá hủy thông tin qua việc dọn dẹp vội vàng.
Hướng dẫn ứng phó sự cố của NIST đặt phản ứng trong quản lý rủi ro an ninh mạng rộng hơn. Khôi phục bao gồm kiểm tra chức năng dự định và giải quyết điều kiện khiến sự cố xảy ra. Kiểm tra hành trình người dùng, xem xét hành vi tài nguyên và kiểm tra công việc nền trước khi kết thúc phản hồi. Một cảnh báo đã xóa hoặc tiến trình đã khởi động lại một mình có thể không chứng minh sự trở lại hoàn toàn của dịch vụ hữu ích.
Biến sự cố thành cải tiến có thể đo lường
Viết một đánh giá ngắn về tác động, dòng thời gian, các điều kiện góp phần và các hành động đã thực hiện. Tập trung vào các thay đổi có thể xác minh: cải thiện một kiểm tra, sửa một quyền, diễn tập khôi phục hoặc thêm một phụ thuộc khôi phục còn thiếu. Chỉ định người phụ trách và tiêu chí hoàn thành. Tránh một danh sách dài các ý định mơ hồ mà sau này không ai có thể xác nhận đã được thực hiện.
Khi triển khai trên SwissOctet, hãy lập kế hoạch giám sát và phản hồi như một phần vận hành của ứng dụng, tách biệt với phần cứng đã chọn và bất kỳ thỏa thuận quản lý đã xác nhận nào. Danh mục không thiết lập một đội ứng phó sự cố có nhân sự hay giờ hỗ trợ liên tục. Quyết định ai nhận cảnh báo, ai có thể hành động và các điều khoản dịch vụ thực tế bao gồm những gì trước khi dựa vào một môi trường sản xuất.
Danh sách kiểm tra thực tế của bạn.
- Giám sát một hành trình người dùng đại diện vô hại.
- Chọn tín hiệu giải thích hành vi ứng dụng.
- Cấp cho cảnh báo một hành động, người phụ trách và điều kiện khôi phục.
- Thống nhất phối hợp và leo thang trước một sự cố.
- Bảo vệ bằng chứng và xác minh khôi phục hoàn toàn.
- Chỉ định các cải tiến có thể kiểm tra sau đánh giá.
Những chi tiết quan trọng.
Giám sát thời gian hoạt động của máy chủ có đủ không?+
Không. Một máy có thể truy cập được vẫn có thể chạy một ứng dụng bị hỏng. Giám sát chức năng người dùng phụ thuộc và thêm bằng chứng tài nguyên để chẩn đoán lỗi.
Mọi ngưỡng chỉ số có nên gọi ai đó ngay lập tức không?+
Không. Dành các ngắt khẩn cấp cho các điều kiện có thể hành động cần chú ý kịp thời. Đưa công việc ưu tiên thấp hơn vào một quy trình đánh giá với người phụ trách rõ ràng.
Khi nào một sự cố kết thúc?+
Sau khi chức năng bị ảnh hưởng và công việc nền liên quan được xác minh, các rủi ro trước mắt được xử lý và các hành động tiếp theo được ghi lại. Chỉ khởi động lại tiến trình là không đủ.
Đến nguồn.
Các tài liệu tham khảo này hỗ trợ các khái niệm kỹ thuật trong hướng dẫn này. Hãy theo dõi tài liệu hiện hành trước khi thay đổi hệ thống sản xuất.
- Google SRE: Giám sát hệ thống phân tán sre.google
- Sổ tay Google SRE: Ứng phó sự cố sre.google
- NIST SP 800-61 Rev. 3: Ứng phó sự cố csrc.nist.gov
Hướng dẫn biên tập bởi SwissOctet. Các ví dụ chỉ mang tính minh họa. Thông số dịch vụ, tùy chọn có sẵn và điều kiện hợp đồng phải được xác minh riêng.