Chuyển đến nội dung chính
Ngày 02 của Prove It. Đến cuối buổi, bạn sẽ kết nối một agent chỉ đọc với cluster Kubernetes của chính mình, giữ ít nhất hai cách giải thích cho một sự cố đang diễn ra, chạy truy vấn loại trừ một trong số đó, và nộp một báo cáo sự cố cho mỗi nhóm. Buổi trực tiếp diễn ra vào ngày 12/09/2026. Bạn có thể tự làm lại bài lab trên bất kỳ cluster nào bạn kiểm soát. Ngày 01 hỏi trong một tài khoản có những gì. Ngày 02 hỏi điều gì đã gây ra sự cố này, ngay lúc này. Quyền truy cập không thay đổi: thông tin xác thực vẫn ở với chủ sở hữu, và agent vẫn không thể thay đổi bất cứ thứ gì.
Dùng trang này với CloudThinker. Dán URL của trang này vào một cuộc chat và thử:
  • “Explain the noise reduction section of this page like I’m new to on-call.”
  • “Quiz me on the difference between a trigger, a root cause and a contributing factor.”
  • “Help me outline my Day 02 incident report using the five blocks on this page.”

​
Quy tắc của buổi học

  • Bốn phần. Learn 35 phút, keynote 25 phút, Practice 30 phút không nghỉ, Share 20 phút.
  • Cluster Kubernetes của bạn được kết nối ở chế độ chỉ đọc. Dùng cluster staging nếu có thể. Agent có thể kiểm tra. Agent không thể khởi động lại, scale, deploy hay sửa bất cứ thứ gì, và không thể đọc secret.
  • Thông tin xác thực ở với chủ sở hữu. Chủ sở hữu cluster tự kết nối trên màn hình của mình bằng một kubeconfig chỉ đọc (get, list, watch).
  • Agent đề xuất. Con người quyết định. Hôm nay không áp dụng bản sửa nào.
  • Che thông tin. ID tài khoản, ARN, endpoint, hostname và dữ liệu khách hàng phải được loại khỏi báo cáo trước khi chia sẻ hoặc hiển thị trên màn hình.
  • Mỗi nhóm một tệp báo cáo, nộp trước khi phần Share bắt đầu.

​
Learn: 35 phút

Ngày 01 đã đặt ranh giới cho agent. Ngày 02 bắt đầu sớm hơn một bước, với ranh giới mà hầu hết các nhóm chưa bao giờ đặt: những tín hiệu nào thực sự đáng được chú ý. Ý tưởng 1 đến 4 là kiến thức nền về nhiễu cảnh báo. Ý tưởng 5 đến 8 là những gì bạn dùng trong bài lab.

​
1. Bạn không thể điều tra những gì bạn không thể xếp hạng

Một đêm tồi tệ không chỉ mang đến một sự cố. Bạn nhận cả một dòng cảnh báo: một cảnh báo truy cập trên role production, một loạt dòng AccessDenied trong audit log trong cùng phút đó, ba cảnh báo gần như giống hệt nhau từ ba dịch vụ, và năm lần page cho cùng một vấn đề. Vào giờ đó, điều tra không phải là phần khó. Chọn điều gì để điều tra mới là phần khó. Nhóm nào cũng đã có cách đối phó với khối lượng cảnh báo, và mỗi câu trả lời đều có cái giá: Mỗi cách là một quyết định về những gì bạn chấp nhận đánh mất, thường được đưa ra một lần, không chính thức, và không bao giờ được ghi lại. Đó lại là khoảng trống quản trị của Ngày 01, lần này hướng vào tín hiệu thay vì agent.

​
2. Nhiễu bị loại bỏ qua các lớp có thứ tự

Giảm nhiễu là một pipeline: thu nhận, loại bỏ, nhóm, rồi phân loại và định tuyến. Loại bỏ không phải là một bộ lọc. Đó là một chuỗi kiểm tra chạy theo thứ tự cố định, và kiểm tra đầu tiên khớp sẽ thắng, nên thứ tự chính là chính sách. Các lớp phổ biến, bất kể bạn dùng công cụ nào: Loại bỏ cascade loại được nhiều nhất, nhưng sẽ che giấu một sự cố thật nếu tín hiệu gốc được dùng để gộp là sai. Mức độ nghiêm trọng cũng chỉ là phỏng đoán: mức độ nghiêm trọng mà một công cụ gắn cho sự kiện chỉ là ý kiến của công cụ đó, và bạn được phép đánh giá lại. Trong CloudThinker, pipeline này là Pulse. Pulse chạy bốn kiểm tra theo thứ tự (dedup, rate limit, snooze, verdict), rồi phân loại những gì còn lại và loại bỏ các tín hiệu mà Pulse đánh giá là không cần hành động. Kiểm tra verdict là kiểm tra biết học: khi CloudThinker xác nhận một mẫu là nhiễu trong lúc điều tra, các lần lặp lại của mẫu đó sẽ bị loại bỏ. Chi tiết: Loại bỏ nhiễu.

​
3. Mọi quy tắc loại bỏ đều cần lối thoát

Việc tắt tiếng phải có hạn và phải ghi đè được, nếu không sẽ trở thành điểm mù. Kiểm tra verdict của Pulse thể hiện cả hai đặc tính:
Quy tắc không có lối vượt rồi sẽ che giấu chính sự cố mà quy tắc đó được viết ra để bắt. Cửa sổ có thời hạn buộc hệ thống xác nhận lại rằng một mẫu vẫn là nhiễu. Tắt tiếng vĩnh viễn là quyết định không ai xem lại.

​
4. Giảm nhiễu là điều giúp agent có chi phí hợp lý

Agent điều tra là bước tốn kém. Hãy hình dung một cảnh báo flapping suốt buổi sáng, mỗi lần kích hoạt lại mở một phân tích nguyên nhân gốc riêng: nhiều cuộc điều tra cho một vấn đề, nhiều câu trả lời cho cùng một câu hỏi, và một hóa đơn cho mỗi lần. Cho agent xử lý dòng cảnh báo thô thì đó chính là thứ bạn phải trả tiền. Ba cổng cần áp dụng trước khi một nhóm tín hiệu đáng được điều tra, dù có agent hay không: Trong CloudThinker, các cảnh báo liên quan có cùng nguyên nhân khả dĩ được nhóm dưới một sự cố cha với một cuộc điều tra duy nhất. Xem Điều tra và RCA.

​
5. Chia nhỏ câu hỏi, không chia nhỏ công việc

Cuộc điều tra tốt thu thập ngữ cảnh, rồi chia thành các giả thuyết: những cách giải thích được phát biểu đủ chính xác để một truy vấn có thể bác bỏ chúng. Mỗi giả thuyết được kiểm chứng với cùng bằng chứng, và cuối cùng chỉ viết ra một phán quyết. Kỹ năng cần mang về là câu hỏi mà mỗi lần chia nhỏ đang tìm kiếm: truy vấn có kết quả khác nhau tùy theo giả thuyết nào đúng. Đó là truy vấn loại trừ được một giả thuyết. Mọi truy vấn khác chỉ xác nhận những gì bạn đã tin. Trong CloudThinker, cuộc điều tra có thể giao các kiểm tra tập trung cho subagent tạm thời (agent trợ giúp ngắn hạn), và Investigation timeline của sự cố ghi lại từng cách giải thích đã kiểm chứng, cùng kết quả xác nhận hay loại trừ. Để xem, vào Resolve → Investigation, chọn một sự cố và cuộn đến Investigation timeline. Chỉ đọc cũng có nghĩa là agent không thể kiểm chứng một ý tưởng bằng cách thay đổi thứ gì đó. Agent phải suy luận, và bạn phải kiểm tra được suy luận đó, đó là lý do timeline quan trọng hơn câu trả lời.

​
6. Thứ tự thời gian không phải bằng chứng về nguyên nhân

Ba cách một timeline đầy tự tin không chứng minh được gì: Nếu bạn không vẽ được đường đi, bạn có một sự trùng hợp, không phải nguyên nhân. Dạng thứ ba là dạng không ai tin cho đến khi họ tận mắt thấy: Giờ đây các lần thử lại chính là tải. Timeout gây ra thử lại, thử lại gây ra tải, tải gây ra timeout. Hãy gọi tên ba phần riêng biệt:
  • Nguyên nhân kích hoạt (trigger): lần failover. Lần failover đã kết thúc, và không có gì để rollback.
  • Nguyên nhân gốc (root cause): chính sách thử lại không có giới hạn và không có backoff, được phát hành trong bản client tuần trước. Đó là tài nguyên mà bạn có thể xác định ngày thay đổi, và nó vẫn sai ngay lúc này.
  • Yếu tố góp phần (contributing factor): thiếu circuit breaker. Circuit breaker lẽ ra đã ngăn được sự cố, nhưng bạn không chứng minh được thành phần này từng thay đổi.

​
7. Nguyên nhân gốc là tài nguyên đã thay đổi

Đồ thị nhân quả có năm loại nút, và chỉ một loại là câu trả lời. Độ lệch là một khẳng định về thời gian, nên hãy giải quyết bằng cách xác định ngày cho từng ứng viên: thời điểm tạo, lịch sử phiên bản, cấu hình được áp dụng gần nhất. Đừng bao giờ dựa vào tài nguyên nào trông bất thường nhất lúc này. Tài nguyên có triệu chứng tệ nhất thường là nạn nhân, và sửa một nạn nhân chỉ là giải pháp tạm thời. Yếu tố góp phần là nhãn trung thực cho bất cứ thứ gì bạn nghi ngờ nhưng không xác định được ngày. Yếu tố góp phần không phải là nguyên nhân gốc kém chắc chắn hơn, mà là một loại khẳng định khác.

​
8. Hệ thống tự chấm điểm cho mình thì không chứng minh được gì

Hãy đòi hỏi mọi khẳng định, của agent và của chính bạn, phải có căn cứ: CloudThinker áp dụng cùng ý tưởng này. Mọi phán quyết đều mang một nhãn bằng chứng: Verified (đã xác nhận với dữ liệu từ hệ thống của bạn), Inferred (được suy luận, chưa xác nhận) hoặc Cause unproven (dựa trên một giả định). Trong báo cáo của bạn, Assumed tương ứng với Cause unproven, và Blocked không có nhãn tương ứng trong sản phẩm. Mọi thay đổi đều đi qua một runbook và thiết lập Approvals của bạn. Và khi On duty của Resolve đang tạm dừng, Pulse vẫn phát hiện và nhóm cảnh báo và vẫn ghi nhận sự cố với trạng thái Open, nhưng không cuộc điều tra nào tự bắt đầu cho đến khi có người nhấn Investigate. Sự cố do một người ghi nhận vẫn được điều tra ngay. Xem Điều gì khởi động một cuộc điều tra.

​
Keynote: 25 phút

The Integration Problem Was a Context Problem: vì sao agent chỉ điều tra tốt khi nó truy cập được dữ liệu.

​
Practice: 30 phút

Nhiệm vụ: một sự cố đang diễn ra trên một cluster Kubernetes. Một nhóm, một agent chỉ đọc, một báo cáo. Ba mươi phút, không nghỉ. Tại sự kiện, mọi nhóm đều xử lý sự cố bên dưới. Trên cluster của riêng bạn, hãy chọn một triệu chứng thật từ staging, chẳng hạn một endpoint chậm hoặc một cảnh báo gần đây, và chạy cùng các bước.
Hotel Search Degradation After Traffic Recovery
Đó là tiêu đề mà người on-call sẽ nhận được. Dashboard sẽ không khớp với người dùng, nên hãy bắt đầu từ những gì khách hàng mất. Các quyền này là thật. Nếu nhóm bạn gặp rào cản, rào cản đó là một phần của bài tập. Gắn nhãn blocked, như ở Ngày 01. Soạn khối 01 và 02 trong quá trình làm từ T+05. Năm phút đủ để hoàn thành một báo cáo, không đủ để bắt đầu viết. Lịch trình là nhịp độ, không phải quy tắc. Hai giả thuyết là mức tối thiểu, không phải mục tiêu. Nhóm nào đến T+18 mà chỉ có một giả thuyết là đã bỏ qua phần quan trọng.

​
Kết nối cluster Kubernetes

Dùng cluster của riêng bạn, lý tưởng là staging, qua một kubeconfig chỉ đọc. Chủ sở hữu cluster tự kết nối trên màn hình của mình, và muốn thêm kết nối cần vai trò Admin của workspace. Tài liệu tham khảo đầy đủ là Kết nối Kubernetes.
1

Tạo kubeconfig chỉ đọc

Làm theo Kết nối Kubernetes: áp dụng manifest cloudthinker-reader, rồi tạo cloudthinker-kubeconfig.yaml cho service account đó. ClusterRole chỉ cấp get, list và watch, và không bao gồm Secrets.Trạng thái thành công: kubectl --kubeconfig cloudthinker-kubeconfig.yaml get nodes liệt kê các node của bạn.
2

Tải lên trong Connections

Đăng nhập tại app.cloudthinker.io. Trên thanh bên, nhấn More → Workspace settings và chọn Connections. Chọn Kubernetes, tải tệp lên trường KUBECONFIG và nhấn Connect.Trạng thái thành công: Kubernetes hiển thị trạng thái Connected.
3

Mở một cuộc chat

Bắt đầu một cuộc chat mới và gửi “Give me an overview of this Kubernetes cluster.”Trạng thái thành công: agent trả lời với các namespace và workload mà nó nhìn thấy.
Không thêm được kết nối? Việc thêm kết nối cần quyền chỉnh sửa connector, mà chỉ vai trò Admin của workspace có. Hãy nhờ một Admin của workspace kết nối cluster, hoặc thay đổi vai trò của bạn. Xem Vai trò workspace.
Không ai nhập thông tin xác thực vào slide, chat hay tài liệu dùng chung. Chủ sở hữu cluster tự kết nối trên màn hình của mình.

​
Hỏi agent điều gì

Hầu hết các nhóm hỏi có gì sai và chấp nhận câu trả lời đầu tiên. Hãy đi xa hơn. Bắt đầu với những câu sau, theo thứ tự:
Câu trả lời hữu ích mô tả trải nghiệm của người dùng (tìm kiếm chậm hoặc thất bại), không phải tình trạng của pod. Danh sách “could not read” được đưa thẳng vào phần phạm vi của bạn.
Câu trả lời hữu ích đưa ra các cách giải thích dự đoán những điều khác nhau. Nếu cả hai đều cho cùng dữ liệu, hãy hỏi lại.
Đây là bước T+18. Dán đầu ra thô vào báo cáo làm bằng chứng đã loại trừ một cách giải thích.
Tài nguyên có thay đổi được xác định ngày là ứng viên nguyên nhân gốc của bạn. Mọi thứ không có ngày là yếu tố góp phần. Giữ lại đầu ra thô. Bạn cần nó cho mọi khẳng định trong báo cáo.

​
Bị mắc kẹt?

​
Đầu ra của bạn: một báo cáo

PDF, doc hoặc markdown. Không có template. Năm khối sau là mức tối thiểu.

​
Đầu ra mẫu

Nếu làm một mình, hãy đối chiếu báo cáo của bạn với mẫu này. Đây là minh họa cho định dạng, không phải kết quả thật: cluster, thời gian và nguyên nhân của bạn sẽ khác.
Kiểm tra ba điều: mỗi giả thuyết có bằng chứng riêng, giả thuyết thua nêu tên truy vấn đã loại trừ nó, và nguyên nhân gốc có ngày. Báo cáo ghi “không đủ bằng chứng” và trình bày log là báo cáo hoàn chỉnh. Câu trả lời tự tin mà không có đường đi thì giá trị thấp hơn. Không cần đề xuất bản sửa. Nộp mỗi nhóm một tệp trước khi phần Share bắt đầu. Che ID tài khoản, ARN, endpoint, hostname và dữ liệu khách hàng trước. Khi xong, kết nối vẫn ở trong workspace cho đến khi Admin của workspace gỡ bỏ: More → Workspace settings → Connections, chọn Kubernetes, rồi Disconnect.

​
Share: 20 phút

Các nhóm tình nguyện trình bày, mỗi nhóm 5 phút, nên khoảng bốn nhóm có thể trình bày. Mọi nhóm trình bày đều nhận giải thưởng. Không chấm điểm, xếp hạng hay bình chọn. Sau đó cả phòng so sánh: cùng cluster, cùng quyền truy cập, câu trả lời khác nhau. Chính phép so sánh đó là lý do các trường log và bằng chứng quan trọng hơn phán quyết.

​
Thuật ngữ

​
Đọc thêm

​
Bước tiếp theo

Ngày 03: Prove It Arena. Một môi trường xa lạ, một sự cố bất ngờ, và ban giám khảo. Hãy mang theo từ vựng của hôm nay: trigger, root cause, contributing factor, và khoảng trống bạn không thể lấp.

Ngày 03: Prove It Arena

Các vòng thi, cách chấm báo cáo, và cách tham gia cùng nhóm trong Arena.

Điều tra và RCA

Xem cách CloudThinker chạy và ghi lại một cuộc điều tra thực tế.