11.1 Danh mục
Đọc mỗi hàng theo cách: nếu thấy tín hiệu, hãy áp dụng cách khắc phục trước khi tín hiệu đó biến thành sự cố ngừng dịch vụ. Chương trong ngoặc là nơi cách khắc phục được xây dựng.
Hai bài học từ bảng.
- Mỗi lỗi này đều xuất hiện trên dashboard trước khi xuất hiện thành sự cố, nhưng chỉ khi bạn đã xây dựng đánh giá và khả năng quan sát từ Chương 7 và Chương 8. Bỏ qua chúng không giúp tránh được các lỗi này. Bạn chỉ gặp chúng mà không có công cụ đo.
- Dùng danh mục làm kịch bản phỏng vấn. Hỏi bất kỳ nhà cung cấp nào xem họ đã gặp lỗi nào trong mười hai lỗi này trên production và họ đã phát hành gì để ứng phó. Trong một lĩnh vực còn non trẻ như vậy, lịch sử sự cố thực là bằng chứng năng lực có giá trị.
11.2 Tự xây hay mua, phiên bản dành cho kỹ sư
Nhóm có năng lực hoàn toàn có thể tự xây agent vận hành. Chỉ cần một cuối tuần với mô hình frontier, một vòng lặp ReAct (suy luận, hành động, quan sát, lặp lại) vàkubectl sẽ tạo ra bản demo gây ấn tượng với lãnh đạo. Câu hỏi thực sự là bạn có nên sở hữu harness xung quanh nó hay không.
Đây là những gì cuốn sách này đã đặc tả vượt ra ngoài bản demo:
Bản demo là phần nhỏ nhất và thú vị nhất trong danh sách đó. Phần còn lại là công việc nặng nhọc không tạo khác biệt cho phần lớn công ty, và đó chính là nơi mười hai kiểu lỗi trú ngụ.
Dùng quy tắc quyết định này:
- Tự xây nếu vận hành agent là sản phẩm của bạn, hoặc ràng buộc của bạn khác thường đến mức không mô hình tin cậy nào của nền tảng phù hợp. Bố trí nhân sự như một nhóm sản phẩm có roadmap, không phải dự án phụ.
- Mua nếu lợi thế của bạn nằm ở chỗ khác. Dành nguồn lực kỹ thuật cho những gì không nhà cung cấp nào làm thay được: bộ kiểm thử, việc tuyển chọn ngữ cảnh, thiết kế chính sách và kỷ luật vận hành của bạn.
Trong thực tế: nơi CloudThinker cung cấp cơ chế kiểm soátNếu bạn đánh giá CloudThinker theo danh mục này, đây là cơ chế kiểm soát cho từng kiểu lỗi, hoặc cách bao quát kiểu lỗi đó khi không có cơ chế nào.