Định nghĩa health check phản ánh đúng khả năng phục vụ

Một điểm kiểm tra sức khỏe luôn trả thành công có thể khiến chức năng không dùng được trông vẫn ổn. Ngược lại, điểm kiểm tra thất bại mỗi khi bất kỳ thành phần phụ thuộc nào chậm cũng có thể gây vấn đề vận hành khác. Hãy bắt đầu từ điều mà phép kiểm tra điều khiển. Kiểm tra để khởi động lại tiến trình cần câu hỏi khác kiểm tra để quyết định có nhận yêu cầu khách hàng không.

Tách ba quyết định vận hành

Trong Kubernetes, Pod có container báo chưa sẵn sàng sẽ không nhận lưu lượng qua Kubernetes Services.[6] Vì vậy, readiness liên quan đến việc một phiên bản chạy có nên nhận lưu lượng đó không. Tài liệu cũng giải thích startup probe cho phép khởi tạo trước khi liveness probe tiếp quản.[6] Đừng gộp những quyết định khác nhau này thành một đèn xanh không có giải thích.

Với dịch vụ của mình, mô tả điều gì phải hoạt động trước khi một phiên bản chạy nhận được các yêu cầu thuộc phạm vi hỗ trợ. Sau đó xác định lỗi nào việc khởi động lại có thể xử lý hợp lý. Gắn mô tả với hành vi thật, không dùng danh sách chung chứa mọi thành phần đã kết nối.

Chủ động chọn thành phần cần kiểm tra

Nên chỉ kiểm tra thành phần phụ thuộc mà khi lỗi sẽ khiến phiên bản chạy không phục vụ được tải liên quan. Nếu nơi nhận phân tích tùy chọn hỏng, dịch vụ cốt lõi có thể vẫn làm nhiệm vụ chính. Nếu chức năng cấp quyền bắt buộc không hoạt động, quyết định nhận lưu lượng có thể khác.

Ghi chính sách thành phần phụ thuộc và chế độ hoạt động suy giảm dự kiến. Kiểm tra sâu mỗi lần có thể tốn tài nguyên, còn kiểm tra nông có thể bỏ sót lỗi thiết yếu. Thử mức cân bằng đã chọn trong điều kiện có kiểm soát và thống nhất ai được đổi ngưỡng hoặc thời gian.

Kết quả sẵn sàng mô tả phạm vi phép kiểm tra, không đại diện mọi hành trình khách hàng. Giữ kiểm chứng từ phía người dùng bên cạnh sức khỏe hạ tầng. Nếu khách hàng vẫn lỗi khi hệ thống báo xanh, xem phép kiểm tra hỏi sai hay lỗi nằm ngoài ranh giới của nó.

Kiểm tra phức tạp cũng khó duy trì. Ưu tiên quyết định nhỏ có giải thích thay vì điểm kiểm tra bao quát nhưng không ai tin. Chấp nhận thiết kế khi nhóm dự đoán được hành động điều khiển cho từng điều kiện đã thử và giải thích được điểm mù còn lại.

Ví dụ giả định: dịch vụ tìm kiếm khởi tạo

Trong ví dụ giả định này, một phiên bản tìm kiếm khởi động tiến trình trước khi chỉ mục sẵn sàng. Kiểm tra tiến trình cơ bản đạt, nhưng khách hàng chưa tìm kiếm được. Nhóm dành thời gian riêng cho khởi tạo và không đưa phiên bản vào phục vụ cho tới khi chỉ mục bắt buộc dùng được.

Nhóm thử riêng việc mất kết nối báo cáo tùy chọn. Lỗi đó không tự động khiến tìm kiếm bị coi là không sẵn sàng. Ví dụ minh họa lựa chọn chính sách, không đưa cấu hình dùng chung hoặc hứa rằng mọi tìm kiếm đều thành công.

Thử chuyển trạng thái, không chỉ kết quả đạt

Yêu cầu bằng chứng cho cách một phiên bản bắt đầu phục vụ, rời phục vụ và quay lại sau lỗi.

• Nêu mỗi kiểm tra điều khiển khởi tạo, khởi động lại hay lưu lượng.
• Liệt kê thành phần bắt buộc cho yêu cầu được hỗ trợ.
• Thử khởi tạo chậm và lỗi phụ thuộc tạm thời.
• Xác minh phục hồi đưa phiên bản về đúng trạng thái dự kiến.
• Không đưa chi tiết chẩn đoán nhạy cảm vào phản hồi sức khỏe công khai.