Bài đăng này được đồng viết với Marek Klatowicz, Kỹ sư Cloud DevOps tại Circle K. Nhiều nhóm DevOps biết mô hình phân loại sự cố: Một cảnh báo sẽ xuất hiện và trước khi bất kỳ ai có thể khắc phục sự cố, một kỹ sư sẽ dành 45–60 phút để tìm hiểu điều gì đã xảy ra. Họ lấy nhật ký, kiểm tra tình trạng dịch vụ và liên hệ các triệu chứng trên một số công cụ. Tất cả điều này xảy ra trước khi việc khắc phục có thể bắt đầu. Tại Circle K, thách thức này được mở rộng theo quy mô của doanh nghiệp. Công ty vận hành hơn 17.200 cửa hàng bán lẻ nhiên liệu và tiện lợi trên 27 quốc gia. Đằng sau mặt tiền cửa hàng, cơ sở hạ tầng dựa trên nền tảng đám mây hỗ trợ các hệ thống điểm bán hàng, ứng dụng khách hàng thân thiết và ứng dụng sạc xe điện (EV) chạy trên AWS. Khi công ty mở rộng hoạt động kỹ thuật số, chi phí phân loại cũng tăng theo. Nhiều dịch vụ hơn có nghĩa là nhiều cảnh báo hơn và mỗi dịch vụ đều yêu cầu điều tra thủ công giống nhau trước khi có thể bắt đầu khắc phục. Để giải quyết vấn đề này, Circle K đã xây dựng một hệ thống phân loại tự động bằng cách sử dụng Amazon Bedrock, một dịch vụ được quản lý hoàn toàn giúp cung cấp các mô hình nền tảng (FM) thông qua một API duy nhất. Để biết tính khả dụng của mô hình theo Khu vực AWS, hãy tham khảo Các mô hình được hỗ trợ theo Khu vực AWS trên Amazon Bedrock. Hệ thống sử dụng kiến ​​trúc AI tác nhân để điều tra từng sự cố một cách tự động và cung cấp bản tóm tắt có cấu trúc cho Slack trong vòng vài phút sau khi kích hoạt cảnh báo. Thay vì cảnh báo thô, các kỹ sư đang làm việc giờ đây nhận được ngữ cảnh có thể hành động để họ có thể hành động ngay lập tức thay vì mất một giờ để tìm hiểu chuyện gì đã xảy ra. Kể từ khi triển khai hệ thống này, Circle K đã giảm thời gian phân loại trung bình xuống dưới 15 phút, giảm 67–75 phần trăm dựa trên số liệu ứng phó sự cố nội bộ của nhóm. Trong bài đăng này, chúng tôi mô tả kiến ​​trúc cho cả quá trình triển khai Amazon Bedrock Flows ban đầu cũng như quá trình di chuyển sang Amazon Bedrock AgentCore, đồng thời chia sẻ các bài học rút ra từ việc mở rộng quy mô hệ thống. Thử thách của việc phân chia chi phí Nhóm DevOps của Circle K giám sát cơ sở hạ tầng trên nhiều tài khoản AWS bằng Grafana. Một điển hình hàng ngày đều đưa ra các cảnh báo về việc khởi động lại vùng chứa, tỷ lệ lỗi tăng cao, độ trễ tăng đột biến và quá trình triển khai không thành công. Mỗi cảnh báo là một tín hiệu hữu ích, nhưng khi hệ thống được mở rộng, nhóm muốn giúp các kỹ sư trực điện thoại nhanh chóng biết được tín hiệu nào cần chú ý với ngữ cảnh phù hợp. Khi có cảnh báo, quá trình phân loại bao gồm một chuỗi các bước thủ công quen thuộc: xem lại nhật ký gần đây trong Amazon CloudWatch, kiểm tra dấu vết cấp ứng dụng trong Amazon OpenSearch Service, kiểm tra trạng thái tác vụ của Amazon Elastic Container Service (Amazon ECS) và tham chiếu chéo các hiện tượng với sổ tay chạy nội bộ trong GitHub. Điều này cung cấp cho các kỹ sư thông tin họ cần, nhưng nó cũng cho thấy mức độ thu thập bối cảnh lặp đi lặp lại sẽ cần thiết khi có nhiều dịch vụ được triển khai hơn. Nhóm đã nhận ra hai lĩnh vực mà việc đầu tư chủ động có thể giúp ích. Đầu tiên, các truy vấn nhật ký, kiểm tra tình trạng và tra cứu sổ chạy tương tự sẽ được lặp lại cho mọi sự cố. Thứ hai, độ sâu và tốc độ phân loại có thể thay đổi tùy theo mức độ quen thuộc của kỹ sư trực ca với dịch vụ bị ảnh hưởng. Khi số lượng cảnh báo và quyền sở hữu dịch vụ tăng lên, việc chuyển đổi giữa nhiều công cụ cho mỗi cuộc điều tra có thể làm chậm phản hồi và khiến việc áp dụng các phương pháp hay nhất của nhóm một cách nhất quán trở nên khó khăn hơn. Do đó, nhóm DevOps của Circle K đã bắt đầu sáng kiến ​​nghiên cứu và phát triển (R&D) để khám phá cách AI có thể hỗ trợ giám sát và phân loại sự cố. Mục đích là để tự động hóa việc thu thập bối cảnh lặp đi lặp lại và cung cấp các phát hiện có cấu trúc, có thể hành động, đồng thời hỗ trợ đánh giá hoạt động của các kỹ sư trong quá trình điều tra. Tại sao Circle K chọn Amazon Bedrock Nhóm đã đánh giá một số cách tiếp cận trước khi xây dựng, bao gồm các khung tác nhân nguồn mở trên cơ sở hạ tầng tự quản lý. Cách tiếp cận đó có nghĩa là sở hữu mô hình lưu trữ, lập phiên bản nhanh chóng, điều phối công cụ và kiểm soát bảo mật. Với Amazon Bedrock, nhóm đã tránh được chi phí đó. Họ có thể truy cập các mô hình nền tảng thông qua một API duy nhất và trao đổi các mô hình nền tảng mà không cần viết lại mã. Beca sử dụng Circle K đã chạy trên AWS, Amazon Bedrock phù hợp với các chính sách AWS Identity and Access Management (IAM) hiện có, cấu hình Amazon Virtual Private Cloud (Amazon VPC) và quy trình ghi nhật ký. Hai khả năng được quản lý bao gồm việc điều phối và truy xuất. Amazon Bedrock đã hỗ trợ điều phối tác nhân, cho phép tác nhân sử dụng công cụ gốc để gọi API AWS, truy vấn cơ sở dữ liệu và truy xuất tài liệu mà không cần mã điều phối tùy chỉnh. Cơ sở kiến ​​thức Amazon Bedrock, khả năng Tạo tăng cường truy xuất (RAG) được quản lý hoàn toàn, xử lý việc nhập và truy xuất thẻ sản phẩm nội bộ, do đó nhóm không cần chạy cơ sở dữ liệu vectơ riêng. Điều này cho phép nhóm DevOps tập trung vào thiết kế nhanh chóng và định nghĩa công cụ. Quyền riêng tư dữ liệu đã hoàn thành bức tranh. Dữ liệu sự cố của Circle K bao gồm các số liệu vận hành, chi tiết cơ sở hạ tầng và nhật ký có thể chứa thông tin nhạy cảm. Amazon Bedrock không chia sẻ dữ liệu khách hàng với các nhà cung cấp mô hình hoặc sử dụng dữ liệu đó để đào tạo các mô hình nền tảng. Đối với một nhóm cung cấp nhật ký sản xuất và chi tiết dịch vụ nội bộ vào hệ thống, phương pháp xử lý dữ liệu này đáp ứng các yêu cầu bảo mật của Circle K. Tổng quan về giải pháp Phần này mô tả kiến trúc ban đầu mà nhóm đã xây dựng trên Amazon Bedrock Flows. Phần sau đề cập đến quá trình di chuyển sang AgentCore. Giải pháp này sử dụng Amazon Bedrock Flows làm lớp điều phối, điều phối một tập hợp các tác nhân chuyên biệt, mỗi tác nhân xử lý một phần khác nhau của quá trình phân tích. Quy trình bắt đầu khi cảnh báo Grafana xuất bản thông báo tới Dịch vụ thông báo đơn giản của Amazon (Amazon SNS), chuyển tiếp thông báo đó đến hàng đợi Dịch vụ hàng đợi đơn giản của Amazon (Amazon SQS). Hàm AWS Lambda thăm dò hàng đợi, trích xuất tải trọng cảnh báo và gọi Luồng. Bên trong Flow, hai tác nhân được gọi song song. AWSResourceExplorerAgent truy vấn cơ sở hạ tầng trên nhiều tài khoản khối lượng công việc được quản lý bằng AWS Organs. Nó kiểm tra trạng thái tác vụ của Amazon ECS, tình trạng mục tiêu của Cân bằng tải ứng dụng và Cloud số liệu và nhật ký dWatch. Đồng thời, OpenSearchExplorerAgent truy vấn Amazon OpenSearch Service để tìm nhật ký cấp ứng dụng và dấu vết được phân phối. Tác nhân này chạy riêng vì OpenSearch trả về khối lượng lớn dữ liệu nhật ký. Việc cô lập nó giúp cửa sổ ngữ cảnh của mỗi tác nhân có thể quản lý được. Nó cũng có quyền truy cập độc quyền vào cơ sở kiến ​​thức, trong đó có các thẻ sản phẩm mô tả từng dịch vụ và các phần phụ thuộc của nó. Sau khi cả hai tác nhân trả lại kết quả của mình, GitHubExplorerAgent sẽ chạy. Nó nhận đầu ra từ hai tác nhân trước đó và tìm kho lưu trữ GitHub của dịch vụ bị ảnh hưởng. Sau đó, nó tìm kiếm mã ứng dụng, định nghĩa cơ sở hạ tầng và các cam kết gần đây để xác định nguồn gốc của sự cố và đề xuất cách khắc phục cụ thể. Chạy nó sau các tác nhân song song có nghĩa là nó biết chính xác những gì cần tìm kiếm thay vì thực hiện một truy vấn rộng rãi. Tất cả ba đầu ra đều đưa vào nút AnalysisPrompt, đây là một lệnh gọi mô hình duy nhất không có công cụ nào được đính kèm. Nó nhận dữ liệu tài nguyên AWS, nhật ký OpenSearch và ngữ cảnh GitHub, sau đó tạo ra một bản tóm tắt có cấu trúc: nguyên nhân cốt lõi có thể xảy ra, bằng chứng hỗ trợ, dịch vụ và chủ sở hữu bị ảnh hưởng cũng như các bước khắc phục được đề xuất. Đầu ra lời nhắc sử dụng định dạng nhất quán mà nhóm trực điện thoại có thể quét trong vòng chưa đầy 2 phút. Flow trả bản tóm tắt này về hàm Lambda đang gọi, hàm này sẽ đăng nó lên kênh Slack. Toàn bộ quá trình từ cảnh báo đến tin nhắn Slack mất 5–15 phút tùy thuộc vào mức độ phức tạp của sự cố. Sơ đồ sau đây cho thấy kiến ​​trúc này từ đầu đến cuối, từ cảnh báo Grafana ban đầu đến bản tóm tắt Slack cuối cùng.

Hình 1: Kiến trúc phân loại sự cố tự động Circle K bằng cách sử dụng Amazon Bedrock Flows

Phân loại ví dụ Cảnh báo Grafana: Tỷ lệ lỗi HTTP 5xx trên một dịch vụ vượt quá 5% trong 3 phút liên tiếp. AWSResourceExplorerAgent kiểm tra tình trạng tác vụ ECS trong tài khoản mục tiêu và nhận thấy nhóm kết nối cơ sở dữ liệu đã cạn kiệt, trong đó dịch vụ ECS đang cố gắng khởi động lại. OpenSearchExplorerAgent trả về nhật ký ứng dụng hiển thị lỗi "từ chối kết nối" từ dịch vụ tới cơ sở dữ liệu PostgreSQL hỗ trợ của nó. Nó cũng truy xuất thẻ sản phẩm cho dịch vụ bị ảnh hưởng từ cơ sở kiến ​​thức, ghi lại sự phụ thuộc của nó vào cơ sở dữ liệu đó. GitHubExplorerAgent tìm kiếm các tệp cơ sở hạ tầng và kho lưu trữ của dịch vụ và tìm định nghĩa Dịch vụ cơ sở dữ liệu quan hệ Amazon (Amazon RDS). Nó thấy rằng dịch vụ sẽ mở một kết nối cơ sở dữ liệu mới theo yêu cầu thay vì sử dụng lại các kết nối hiện có. AnalysisPrompt nhận được cả ba kết quả. Nó tương quan thời gian với một chiến dịch tiếp thị đã lên lịch bắt đầu 10 phút trước cảnh báo. Nó kết hợp điều đó với phát hiện của GitHubExplorerAgent để đề xuất một bản sửa lỗi cấp mã cụ thể thay vì một bản vá tạm thời. Thông báo Slack cuối cùng có nội dung:

Tóm tắt: Lỗi Dịch vụ XYZ 5xx do cạn kiệt nhóm kết nối Nguyên nhân cốt lõi: Chiến dịch tiếp thị theo lịch trình đã khiến lưu lượng truy cập tăng đột biến; nhóm kết nối tối đa (50) không đủ để tải Bằng chứng: Nhật ký OpenSearch hiển thị "kết nối bị từ chối" lúc 14:32 UTC; ECS hiển thị 3 lần khởi động lại tác vụ kể từ 14:30 Chủ sở hữu: Nhóm XYZ (phụ trợ) Các bước tiếp theo: Thêm Amazon RDS Proxy vào nhóm kết nối hoặc cập nhật dịch vụ để sử dụng lại các kết nối hiện có thay vì mở kết nối mới theo yêu cầu; hãy xem xét quy tắc Tự động chia tỷ lệ cho các chiến dịch trong tương lai

Mở rộng quy mô sang Amazon Bedrock AgentCore Kiến trúc Amazon Bedrock Flows hoạt động tốt trong nhiều tháng và các sự cố đơn giản được xử lý trong vòng chưa đầy 10 phút. Theo thời gian, khối lượng dữ liệu và bối cảnh đằng sau mỗi cuộc điều tra ngày càng tăng, mặc dù tập hợp các dịch vụ vẫn giữ nguyên. Một số sự cố yêu cầu phân tích chạy lâu hơn mức mà một nút Dòng đơn lẻ có thể hoàn thành. Trước tiên, nhóm đã tối ưu hóa trong thiết kế hiện có bằng cách lọc nhật ký mạnh mẽ hơn, rút ​​ngắn cửa sổ ngữ cảnh và chia một số dịch vụ nhất định thành các Luồng riêng biệt. Các bước này đã giúp ích nhưng khối lượng nhật ký và cơ sở kiến ​​thức vẫn tiếp tục tăng lên. Amazon Bedrock AgentCore đáp ứng được nhu cầu này. AgentCore là một nền tảng để xây dựng, kết nối và tối ưu hóa các tác nhân AI trên quy mô lớn với bất kỳ khung hoặc mô hình nào. Đối với khối lượng công việc này, chức năng chính là AgentCore Runtime: Quá trình điều tra đầy đủ diễn ra trong một phiên duy nhất, vì vậy mỗi bước có thể mất thời gian mà dữ liệu của nó yêu cầu. AgentCore Runtime hỗ trợ các phiên lên tới 8 giờ, vượt xa những gì các cuộc điều tra hiện tại cần. Nhóm đã chứa logic tác nhân của họ và triển khai nó trên AgentCore Runtime. Sơ đồ sau đây thể hiện kiến ​​trúc sản xuất sau khi chuyển sang Amazon Bedrock AgentCore.

Hình 2: Kiến trúc sản xuất sử dụng Amazon Bedrock AgentCore Runtime và AgentCore Gateway

Logic phân tích vẫn giữ nguyên nhưng cách nó chạy đã thay đổi. Ba tác nhân chuyên dụng từ phiên bản Flows hiện được hợp nhất thành một tác nhân duy nhất chạy trong phiên AgentCore Runtime. Hàm Lambda bắt đầu phiên và tác nhân thực hiện các bước tương tự như trước. Nó truy vấn tài nguyên AWS trên các tài khoản, lấy nhật ký từ Amazon OpenSearch Service, tìm kiếm GitHub và truy xuất thẻ sản phẩm từ cơ sở kiến ​​thức. Tác nhân trả kết quả tìm thấy của mình cho hàm Lambda trong vòng 15 phút, nằm trong thời gian chờ tối đa của Lambda. Sau đó, hàm Lambda đăng bản tóm tắt có cấu trúc lên Slack. Amazon Bedrock AgentCore Gateway, một khả năng của Amazon Bedrock AgentCore, môi giới quyền truy cập của tác nhân vào các nguồn dữ liệu của nó, bao gồm Amazon OpenSearch Service, Cơ sở tri thức Amazon Bedrock và GitHub. Cổng hiển thị mỗi nguồn dưới dạng một công cụ mà tác nhân gọi ra, tập trung quyền kiểm soát truy cập và giúp nhóm thêm hoặc thay đổi nguồn dữ liệu đơn giản hơn. AgentCore Runtime đã hỗ trợ quy mô ngày càng tăng của nhóm như thế nào Ngoài các phiên chạy dài hơn, Amazon Bedrock AgentCore Runtime đã bổ sung thêm ba khả năng hỗ trợ quy mô ngày càng tăng của nhóm: tính bền vững của phiên, khả năng quan sát dựa trên OpenTelemetry và tính linh hoạt của khung. Tính kiên trì của phiên: Tác nhân giữ trạng thái trung gian trong suốt quá trình điều tra. Nếu lần chuyển đầu tiên qua nhật ký làm xuất hiện nội dung nào đó, tác nhân có thể chạy lần chuyển thứ hai, có mục tiêu hơn mà không làm mất bối cảnh mà nó đã tạo. Điều này phù hợp với cách lặp đi lặp lại mà các sự cố phức tạp, đa dịch vụ được điều tra. Khả năng quan sát: AgentCore ghi lại dấu vết từ mỗi phiên bằng cách sử dụng các tiêu chuẩn và bề mặt OpenTelemetry thông qua CloudWatch. Nhóm có thể xem mỗi bước mất bao lâu, cơ sở kiến ​​thức nào truy vấn mà tác nhân thực hiện và nơi xảy ra tắc nghẽn. Những hiểu biết sâu sắc này cung cấp trực tiếp vào việc điều chỉnh nhanh chóng. Tính linh hoạt của khung: Với AgentCore Runtime, nhóm có thể triển khai các tác nhân được đóng gói được xây dựng bằng nhiều khung . Họ có thể lặp lại logic của tác nhân, thêm các bước phân loại hoặc cơ cấu lại lý do của tác nhân khi yêu cầu của chúng thay đổi, tất cả đều trên cùng một Thời gian chạy. Kiến trúc AgentCore hiện đang chạy trong sản xuất và xử lý đầy đủ các sự cố, từ cảnh báo đơn dịch vụ đơn giản đến điều tra đa dịch vụ quy mô lớn. Kết quả Circle K đã triển khai phiên bản AgentCore của hệ thống phân loại vào tháng 4 năm 2026. Dựa trên các chỉ số ứng phó sự cố nội bộ của nhóm, thời gian phân loại trung bình đã giảm từ 45–60 phút xuống dưới 15 phút, giảm 67–75%. Các sự cố đơn giản sẽ nhận được bản tóm tắt sau 5–8 phút. Các sự cố đa dịch vụ phức tạp, trước đây phải mất hơn một giờ để xử lý theo cách thủ công, giờ đây đã hoàn tất trong vòng 15 phút. Các kỹ sư bây giờ bắt đầu từ một bản tóm tắt thay vì tự mình thu thập ngữ cảnh. Nhóm nhận thấy ba thay đổi trong cách xử lý sự cố: Phân loại nhất quán. Mọi kỹ sư đang làm việc đều nhận được bản tóm tắt có cấu trúc giống nhau, với cùng các đoạn trích nhật ký, tài liệu tham khảo cơ sở kiến ​​thức giống nhau và các bước tiếp theo được đề xuất, bất kể họ biết rõ về dịch vụ bị ảnh hưởng đến mức nào. Leo thang nhanh hơn. Khi một vấn đề cần sự hỗ trợ từ nhóm khác, bản tóm tắt sẽ cung cấp cho kỹ sư trực điện thoại bối cảnh liên quan để báo cáo kịp thời và đầy đủ thông tin. Xử lý nhanh hơn các báo động sai. Khi phân tích tìm thấy các dịch vụ tốt và không có lỗi tương quan, kỹ sư có thể xác nhận cảnh báo và tiếp tục. Bài học kinh nghiệm Việc xây dựng hệ thống này phải mất nhiều lần lặp lại. Bốn bài học nổi bật áp dụng cho các nhóm xây dựng giải pháp tương tự với Amazon Bedrock. Bao gồm nội dung nhật ký trực tiếp trong lời nhắc. Các phiên bản đầu tiên chỉ chuyển tên nhóm nhật ký và phạm vi thời gian, sau đó nhân viên cố gắng truy vấn CloudWatch thông qua các nhóm hành động. Điều này đã làm tăng thêm độ trễ và thường trả về quá nhiều dữ liệu để xử lý. Circle K nhận được kết quả tốt hơn nhờ các hàm Lambda truy vấn trước nhật ký và chuyển trực tiếp các dòng liên quan đến tổng đài viên. Tác nhân lý do nhanh hơn khi có thể đọc được thông báo lỗi thực tế. Truy xuất giai điệu thế hệ d cho các trường hợp sử dụng. Cấu hình truy xuất ảnh hưởng đáng kể đến chất lượng kết quả từ cơ sở tri thức. Sau khi thử nghiệm các tùy chọn có sẵn, nhóm Circle K nhận thấy rằng Cơ sở tri thức Amazon Bedrock với cấu hình mặc định hoạt động tốt nhất cho dữ liệu của họ. Amazon Bedrock xử lý toàn bộ quá trình nhúng, lập chỉ mục và lưu trữ vectơ nên nhóm có ít thành phần cần bảo trì hơn. Về phía thế hệ, lời nhắc hệ thống được thiết kế tốt và cài đặt nhiệt độ được điều chỉnh đã tạo ra các bản tóm tắt nhất quán trong Slack. Thu hẹp tìm kiếm mã với những phát hiện từ nhật ký. Tìm kiếm kho lưu trữ của dịch vụ mà không có khách hàng tiềm năng trả về quá nhiều kết quả hữu ích. Nhóm thực hiện tìm kiếm GitHub sau khi phân tích nhật ký và tài nguyên AWS, do đó, tổng đài viên đã biết lỗi, thành phần hoặc thay đổi gần đây nào cần tìm. Trong ví dụ phân loại, đây là cách nhân viên nhận thấy rằng dịch vụ đã mở kết nối cơ sở dữ liệu mới cho mọi yêu cầu. Giữ logic phân tích độc lập với lớp điều phối. Thời gian phân tích tăng lên cùng với khối lượng dữ liệu, vì vậy hãy lên kế hoạch cho việc điều tra sẽ mất nhiều thời gian hơn. Nhóm đã tách biệt các lời nhắc, định nghĩa công cụ và các bước phân tích khỏi cấu trúc quy trình. Điều này giúp có thể hợp nhất chúng thành một tác nhân duy nhất trên AgentCore Runtime mà không cần phải viết lại logic phân loại. Các bước tiếp theo Ngày nay, hệ thống phân loại tìm ra nguyên nhân cốt lõi có thể xảy ra và đề xuất cách khắc phục, sau đó kỹ sư sẽ tiến hành khắc phục. Tiếp theo, nhóm dự định tích hợp với AWS DevOps Agent để hệ thống cũng có thể xử lý các biện pháp khắc phục đơn giản. Các ví dụ bao gồm khởi động lại một tác vụ, mở rộng quy mô dịch vụ hoặc lùi quá trình triển khai. Kỹ sư sẽ phê duyệt từng hành động trong Slack trước khi nó chạy. Nhóm cũng có kế hoạch cung cấp cho nhân viên nhiều bối cảnh hơn để làm việc:

Jira, để liên kết từng sự việc với các yêu cầu liên quan và theo dõi công việc tiếp theo. Hợp nhất, để thêm tài liệu nội bộ vào mã và ghi nhật ký mà tác nhân đã đọc. Sách hướng dẫn trong cơ sở kiến ​​thức để nhân viên có thể khớp các triệu chứng với các chế độ lỗi đã biết và cách khắc phục đã hoạt động trước đó, thay vì chỉ dựa vào thẻ sản phẩm.

Kết luận Nhóm Circle K đã giảm từ 45–60 phút phân loại sự cố thủ công xuống còn dưới 15 phút bằng cách tự động hóa việc thu thập bối cảnh mà các kỹ sư thường thực hiện thủ công. Hệ thống thu thập dữ liệu từ nhật ký, tài nguyên AWS và mã, cho phép tổng đài viên suy luận về dữ liệu đó và cung cấp bản tóm tắt có cấu trúc cho Slack. Nhóm đã xây dựng phiên bản đầu tiên trên Amazon Bedrock Flows và Cơ sở kiến ​​thức Amazon Bedrock. Khi các cuộc điều tra ngày càng mở rộng, nhóm đã chuyển sang một đại lý duy nhất trên Amazon Bedrock AgentCore Runtime, với AgentCore Gateway cung cấp quyền truy cập vào các nguồn dữ liệu của nó. Nếu nhóm của bạn dành phần lớn thời gian ứng phó sự cố để thu thập bối cảnh thay vì khắc phục sự cố thì mẫu này sẽ áp dụng trực tiếp. Để bắt đầu, hãy khám phá Cơ sở kiến ​​thức về Amazon Bedrock AgentCore và Amazon Bedrock. Để được hướng dẫn thực hành hoặc thảo luận về trường hợp sử dụng của bạn với chuyên gia AWS, hãy truy cập trang bắt đầu Amazon Bedrock hoặc liên hệ với AWS. Chúng tôi muốn biết cách bạn tiếp cận việc phân loại sự cố. Chia sẻ kinh nghiệm của bạn trong các ý kiến.

Về các tác giả