Các phương pháp hay nhất để triển khai AWS DevOps Agent trong môi trường sản xuất

Tác giả: Greg Eppel
Ngày phát hành: 28 JAN 2026
Chuyên mục: Best Practices, DevOps, Management & Governance, Monitoring and observability

Phân tích nguyên nhân gốc rễ trong các sự cố là một trong những phần tốn thời gian và căng thẳng nhất khi vận hành các ứng dụng đám mây. Các kỹ sư phải nhanh chóng tương quan dữ liệu đo lường từ nhiều dịch vụ, xem xét lịch sử triển khai và hiểu các phụ thuộc ứng dụng phức tạp – tất cả trong khi chịu áp lực phải khôi phục dịch vụ. AWS DevOps Agent thay đổi mô hình này bằng cách mang lại khả năng điều tra tự động cho nhóm vận hành của bạn, giảm thời gian trung bình để khắc phục (MTTR) từ hàng giờ xuống còn vài phút.

Tuy nhiên, hiệu quả của AWS DevOps Agent phụ thuộc rất nhiều vào cách bạn cấu hình Agent Spaces, nơi kiểm soát ranh giới truy cập tài nguyên. Một Agent Space quá hẹp sẽ bỏ lỡ ngữ cảnh quan trọng trong quá trình điều tra. Một Agent Space quá rộng sẽ gây ra chi phí hiệu suất và sự phức tạp. Bài đăng này cung cấp các phương pháp hay nhất để thiết lập Agent Spaces nhằm cân bằng khả năng điều tra với hiệu quả vận hành, dựa trên kinh nghiệm của chúng tôi khi giới thiệu khách hàng ban đầu và sử dụng DevOps Agent trong các nhóm của chúng tôi.

Cuối bài đăng này, bạn sẽ hiểu cách cấu trúc Agent Spaces để có độ chính xác điều tra tối ưu, xác định phạm vi truy cập tài nguyên phù hợp và sử dụng Infrastructure as Code (IaC) để hợp lý hóa việc triển khai. Hãy bắt đầu bằng cách hiểu khái niệm nền tảng giúp tất cả những điều này trở nên khả thi: chính Agent Space.

Agent Space là gì và tại sao nó lại quan trọng?

Agent Space là một vùng chứa logic định nghĩa những gì AWS DevOps Agent có thể truy cập và điều tra. Hãy coi nó như ranh giới hoạt động của Agent – nó xác định tài khoản đám mây nào mà Agent có thể truy vấn, tích hợp bên thứ ba nào có sẵn và ai có thể tương tác với các cuộc điều tra.

Agent Spaces rất quan trọng vì AWS DevOps Agent cần đủ ngữ cảnh để thực hiện phân tích nguyên nhân gốc rễ chính xác.

Khi một sự cố xảy ra, Agent sẽ:

Tìm hiểu các tài nguyên của bạn và mối quan hệ của chúng trên các tài khoản
Tương quan dữ liệu đo lường từ nhật ký, số liệu và dấu vết
Xem xét các thay đổi gần đây bao gồm triển khai và cập nhật cấu hình
Tạo và kiểm tra các giả thuyết bằng cách truy vấn các nguồn dữ liệu bổ sung

Hình 1: Cấu trúc liên kết Agent Space

Nếu Agent Space không bao gồm quyền truy cập vào một tài khoản hoặc tích hợp quan trọng, Agent có thể bỏ lỡ hoàn toàn nguyên nhân gốc rễ. Ngược lại, một Agent Space quá rộng sẽ gây ra thách thức về hiệu suất khi Agent xem xét nhiều hoán vị tài nguyên hơn trong quá trình điều tra.

Hiểu rõ những đánh đổi giữa phạm vi và hiệu suất là điều cần thiết. Câu hỏi đặt ra là: làm thế nào để bạn xác định ranh giới phù hợp cho tổ chức và mô hình vận hành cụ thể của mình?

Phần 1: Thiết kế kiến trúc Agent Space của bạn

Chúng tôi khuyên bạn nên suy nghĩ về ranh giới Agent Space theo cách tương tự như cách bạn suy nghĩ về trách nhiệm trực: cấp quyền truy cập vào các tài khoản liên quan đến ứng dụng, nhưng tách biệt môi trường sản xuất khỏi môi trường phi sản xuất.

Cách tiếp cận này mang lại một số lợi ích:

Mô hình tư duy quen thuộc – Các nhóm vận hành đã hiểu rõ ranh giới trực
Phạm vi điều tra phù hợp – Phản ánh cách các kỹ sư con người sẽ điều tra các sự cố
Quyết định hai chiều – Bạn có thể mở rộng hoặc thu hẹp phạm vi Agent Space khi nhu cầu phát triển
Cân bằng hiệu suất – Cung cấp đủ ngữ cảnh mà không làm quá tải Agent

Xác định ranh giới Agent Space của bạn

Bắt đầu bằng cách ánh xạ kiến trúc ứng dụng của bạn tới ranh giới Agent Space và xem xét các câu hỏi sau:

Điều gì định nghĩa một ứng dụng logic?
- Nhóm của bạn có sở hữu nhiều ứng dụng độc lập không? Nếu vậy, hãy tạo các Agent Space riêng biệt. Tuy nhiên, nếu các ứng dụng được kết nối chặt chẽ (ví dụ: các microservice phụ thuộc lẫn nhau) và ánh xạ tới một nhóm giải quyết duy nhất, nhóm được chỉ định để trực, thì hãy xem xét một Agent Space duy nhất cho mỗi nhóm.
- Nó có phải là một monolith trải rộng trên nhiều tài khoản không? Khi đó, một Agent Space có quyền truy cập đa tài khoản là hợp lý.
Bạn tổ chức các ca trực như thế nào?
- Các nhóm riêng biệt cho môi trường sản xuất so với môi trường phi sản xuất gợi ý các Agent Space riêng biệt.
- Một nhóm xử lý tất cả các môi trường có thể hoạt động với một Agent Space cho mỗi ứng dụng.
Các mẫu điều tra của bạn là gì?
- Các sự cố sản xuất có yêu cầu truy vấn các dịch vụ phụ thuộc trong các tài khoản khác không? Bao gồm các tài khoản đó.
- Các môi trường có hoàn toàn bị cô lập không? Giữ các Agent Space riêng biệt.

Ví dụ cây quyết định:

Application: E-commerce Platform
 
├── Production environment
 
│ ├── Account 111111111111 (Frontend)
 
│ ├── Account 222222222222 (API Gateway + Lambda)
 
│ └── Account 333333333333 (RDS + DynamoDB)
 
├── Staging environment
 
│ └── Account 444444444444 (All resources)
 
└── Development environment
 
└── Account 555555555555 (All resources)

Recommended Agent Spaces:
 
→ "EcommerceProd" (accounts 111111111111, 222222222222, 333333333333)
 
→ "EcommerceNonProd" (accounts 444444444444, 555555555555)

Hình 2: Ranh giới Agent Space phản ánh trách nhiệm của nhóm trực

Các mẫu Agent Space phổ biến và điểm quyết định

Ngoài mẫu ứng dụng đơn cơ bản, các tổ chức gặp phải các kịch bản phức tạp hơn đòi hỏi sự cân nhắc kỹ lưỡng. Dưới đây là các mẫu quan trọng để giải quyết các kịch bản này mà chúng tôi đã thấy khách hàng áp dụng thành công:

Pattern 1: Investigations Spanning Multiple Teams. Các tổ chức lớn với nhiều nhóm (ví dụ: 3 nhóm quản lý hơn 100 tài khoản sản xuất) gặp phải các tình huống mà một vấn đề bắt nguồn từ cơ sở hạ tầng của Nhóm A nhưng nguyên nhân gốc rễ nằm ở các dịch vụ của Nhóm B. Câu hỏi đặt ra là: làm thế nào để bạn kích hoạt sự hợp tác giữa các Agent Space?

Cách tiếp cận được đề xuất: Tạo các Agent Space dành riêng cho ứng dụng bao gồm quyền truy cập chỉ đọc vào các tài khoản tài nguyên được chia sẻ (ví dụ: các phụ thuộc). Thiết lập các quy trình leo thang trực rõ ràng và thêm chúng làm runbooks khi các cuộc điều tra xác định nguyên nhân gốc rễ liên nhóm để giao tiếp hiệu quả (ví dụ: qua trò chuyện trong Slack). Cấu hình các tài nguyên của nhóm dịch vụ được chia sẻ với các thẻ nhận dạng ứng dụng nào sử dụng chúng (ví dụ: app-id: ecommerce-frontend). Tuân thủ chiến lược gắn thẻ nhất quán cung cấp ngữ cảnh điều tra cho các tài nguyên được chia sẻ trong khi vẫn duy trì quyền sở hữu tài nguyên rõ ràng.

Pattern 2: Shared Services and Network Operations Center (NOC) Teams. Một số tổ chức có các nhóm tập trung cung cấp và hỗ trợ các dịch vụ cơ sở hạ tầng được chia sẻ (cơ sở dữ liệu, mạng, giám sát, bảo mật) được sử dụng bởi nhiều ứng dụng trong toàn tổ chức. Các nhóm NOC hoặc nhóm vận hành trung tâm này cần khả năng hiển thị vào các dịch vụ của họ mà không yêu cầu quyền truy cập vào Agent Space của mọi ứng dụng.

Cách tiếp cận được đề xuất: Tạo một Agent Space chuyên dụng cho nhóm dịch vụ được chia sẻ và cấu hình một Agent Space có phạm vi cho cơ sở hạ tầng và trách nhiệm vận hành của nhóm dịch vụ được chia sẻ:

Bao gồm các tài khoản AWS chứa cơ sở dữ liệu được chia sẻ, cơ sở hạ tầng mạng, hệ thống ghi nhật ký và giám sát tập trung.
Cấu hình các vai trò IAM cung cấp quyền truy cập chỉ đọc vào các tài nguyên cụ thể mà nhóm hỗ trợ
Bao gồm các runbook và quy trình vận hành dành riêng cho các dịch vụ được chia sẻ

Điều này tuân theo cùng một nguyên tắc như các Agent Space dành riêng cho ứng dụng: một Agent Space cho mỗi nhóm trực, ngay cả khi phạm vi của Agent Space đó trải rộng trên nhiều ứng dụng.

Pattern 3: Central Operations Teams Managing Many Applications. Trong khi các nhóm dịch vụ được chia sẻ quản lý các miền cơ sở hạ tầng cụ thể, các nhóm SRE thường phải đối mặt với một thách thức lớn hơn: trách nhiệm vận hành cho hàng trăm hoặc hàng nghìn ứng dụng ở quy mô doanh nghiệp. Các nhóm vận hành trung tâm chịu trách nhiệm về công cụ vận hành trên hàng trăm hoặc hàng nghìn ứng dụng có thể quản lý hiệu quả Agent Spaces ở quy mô lớn bằng cách sử dụng Infrastructure as Code.

Cách tiếp cận được đề xuất: Sử dụng các mẫu CDK hoặc Terraform của AWS có sẵn làm điểm khởi đầu. Các mẫu này cho phép các nhóm:

Xác định một mẫu Agent Space được tiêu chuẩn hóa với các vai trò IAM, tích hợp và ranh giới tài nguyên bắt buộc của tổ chức bạn
Triển khai Agent Spaces theo chương trình như một phần của quy trình làm việc giới thiệu ứng dụng
Thực thi tuân thủ thông qua các quy tắc AWS Config hoặc chính sách kiểm soát dịch vụ
Theo dõi tất cả các Agent Space thông qua thanh toán và gắn thẻ hợp nhất (application-id, team, cost-center, environment)

Các nhóm vận hành trung tâm quản lý các mẫu và chính sách quản trị, trong khi các nhóm ứng dụng hoạt động trong các rào cản đó. Cách tiếp cận này mở rộng quy mô lên hàng nghìn ứng dụng với cấu hình nhất quán và triển khai tự động. AWS DevOps Agent cho phép hạn chế quyền truy cập của Agent trong một tài khoản AWS và kiểm soát quyền truy cập cho người dùng vào bảng điều khiển của nhà điều hành để các nhóm quản lý quyền truy cập Agent Space ở quy mô lớn.

Hình 3: Mẫu quy mô doanh nghiệp sử dụng Infrastructure as Code

Bây giờ bạn đã hiểu cách thiết kế ranh giới Agent Space phù hợp với cấu trúc nhóm và yêu cầu về quy mô của bạn, hãy cùng tìm hiểu các bước triển khai thực tế để biến các mẫu kiến trúc này thành hiện thực.

Phần 2: Triển khai kiến trúc Agent Space của bạn

Phần này hướng dẫn bạn các bước thực tế để tạo Agent Space đầu tiên của mình – từ việc xác minh các điều kiện tiên quyết và cấu hình các vai trò IAM trên các tài khoản đến tích hợp các công cụ quan sát, thiết lập kiểm soát truy cập và kiểm tra cấu hình của bạn để đảm bảo các cuộc điều tra có ngữ cảnh cần thiết.

Bước 1: Điều kiện tiên quyết của Agent Space

Trước khi thiết lập Agent Space đầu tiên của bạn, hãy đảm bảo bạn có:

Tài khoản AWS – Ít nhất một tài khoản AWS nơi các tài nguyên ứng dụng của bạn chạy
Quyền IAM – Đủ quyền truy cập để tạo các vai trò và chính sách IAM trên các tài khoản. AWS DevOps Agent yêu cầu hai bộ quyền IAM riêng biệt:
- Quyền vai trò Agent Space – Vai trò IAM mà AWS DevOps Agent đảm nhận để truy vấn các tài nguyên AWS của bạn, truy cập CloudWatch Logs và khám phá cấu trúc liên kết. Vai trò này yêu cầu chính sách được quản lý AIOpsAssistantPolicy cộng với các quyền bổ sung cho AWS Support và các khả năng mở rộng. Xem hướng dẫn giới thiệu CLI để biết cấu hình vai trò hoàn chỉnh.
- Quyền vai trò ứng dụng Operator – Vai trò IAM kiểm soát những gì các nhà điều hành con người có thể làm trong ứng dụng web AWS DevOps Agent, chẳng hạn như bắt đầu điều tra, xem kết quả và tạo các trường hợp AWS Support. Vai trò này tách biệt với các quyền điều tra của Agent.
Service Control Policies (SCPs) – Xác minh rằng SCP của tổ chức bạn cho phép các hành động API của AWS DevOps Agent. Vấn đề phổ biến: Các nhóm hoàn tất thiết lập Agent Space nhưng các cuộc điều tra thất bại vì SCP chặn các hành động aidevops:* hoặc các hành động bedrock:InvokeModel. Xem xét SCP của AWS Organization của bạn và thêm các ngoại lệ cho DevOps Agent nếu cần. Lưu ý rằng DevOps Agent và suy luận Amazon Bedrock không bị ảnh hưởng bởi các chính sách hạn chế nội dung khách hàng đối với các AWS Region cụ thể – Bedrock có thể sử dụng các Region của Hoa Kỳ khác ngoài US East (N. Virginia) cho suy luận không trạng thái.
Công cụ quan sát – Tối thiểu, Amazon CloudWatch (tự động có sẵn thông qua các vai trò IAM) và Amazon CloudTrail. Để điều tra toàn diện, hãy tích hợp các công cụ Giám sát hiệu suất ứng dụng như Datadog, Dynatrace, New Relic, Grafana hoặc Splunk. Xem Kết nối các nguồn đo lường để biết các tích hợp được hỗ trợ.
Hiểu cấu hình tích hợp bên thứ ba – Một số công cụ bên thứ ba yêu cầu quy trình cấu hình hai bước:
- Đăng ký cấp tài khoản – Các công cụ sử dụng OAuth (như GitHub, Dynatrace) trước tiên phải được đăng ký ở cấp tài khoản AWS thông qua bảng điều khiển DevOps Agent. Điều này thiết lập thông tin xác thực OAuth được chia sẻ trên tất cả các Agent Space trong tài khoản của bạn.
- Liên kết cấp Agent Space – Sau khi đăng ký, mỗi Agent Space riêng lẻ chỉ định tài nguyên nào từ công cụ đó sẽ sử dụng. Ví dụ, sau khi đăng ký GitHub một lần, Agent Space “EcommerceProd” chỉ có thể liên kết các kho lưu trữ sản xuất trong khi Agent Space “EcommerceNonProd” liên kết các kho lưu trữ phát triển. Các công cụ khác như Datadog, New Relic và Splunk có thể được liên kết trực tiếp với Agent Space bằng cách sử dụng khóa API hoặc mã thông báo mà không cần đăng ký cấp tài khoản riêng. CloudWatch không yêu cầu cấu hình bổ sung nào ngoài các vai trò IAM.
Kiểm soát nguồn – Quyền truy cập kho lưu trữ GitHub hoặc GitLab để có ngữ cảnh mã và tương quan triển khai (tùy chọn nhưng rất được khuyến nghị)
Công cụ IaC – AWS CDK (TypeScript/Python), Terraform, AWS CLI hoặc AWS Management Console để triển khai Agent Space

Với các điều kiện tiên quyết đã được xác minh, bạn đã sẵn sàng tạo Agent Space của mình và thiết lập các mối quan hệ tin cậy IAM cho phép điều tra.

Bước 2: Tạo Agent Space

AWS DevOps Agent yêu cầu các vai trò IAM trong mỗi tài khoản AWS trong ranh giới Agent Space. Agent đảm nhận các vai trò này để truy vấn CloudWatch Logs, mô tả tài nguyên và xây dựng cấu trúc liên kết ứng dụng.

AWS DevOps Agent được thiết kế để truy xuất dữ liệu vận hành từ nhiều AWS Region trên tất cả các tài khoản AWS mà bạn cấp quyền truy cập trong Agent Space đã cấu hình, cho phép khả năng hiển thị toàn diện vào cơ sở hạ tầng và ứng dụng phân tán bất kể triển khai địa lý của chúng, đồng thời hỗ trợ nhiều tài khoản thông qua quy trình cấu hình liên quan đến việc tạo các vai trò IAM với các chính sách tin cậy và quyền phù hợp trong các tài khoản phụ.

Option A: Sử dụng trình hướng dẫn AWS Console
Điều hướng đến bảng điều khiển AWS DevOps Agent và chọn Create Agent Space và làm theo hướng dẫn thiết lập để tạo các vai trò IAM trong mỗi tài khoản đích.

Hình 4: Tạo Agent Space trong Console

Trình hướng dẫn thiết lập giúp cấu hình các mối quan hệ tin cậy đa tài khoản.

Hình 5: Cấu hình nhiều tài khoản cho Agent Space của bạn

Option B: Sử dụng Infrastructure as Code (Được khuyến nghị)
Chúng tôi cung cấp các mẫu CDK và Terraform mẫu tự động hóa việc tạo Agent Space và triển khai vai trò IAM trên nhiều tài khoản.

Ví dụ AWS CDK (TypeScript):

			
//If you have many accounts, use a loop:
const accounts = [
  { id: '111111111111', name: 'Prod', role: prodRole, stage: 'prod' },
  { id: '222222222222', name: 'Dev', role: devRole, stage: 'dev' },
  { id: '333333333333', name: 'Test', role: testRole, stage: 'test' },
];
accounts.forEach(account => {
  const association = new devopsagent.CfnAssociation(this, `${account.name}Association`, {
    agentSpaceId: agentSpace.ref,
    serviceId: 'aws',
    configuration: {
      aws: {
        assumableRoleArn: account.role.roleArn,
        accountId: account.id,
        accountType: 'monitor'
      }
    }
  });
  association.addDependency(agentSpace);
  cdk.Tags.of(association).add('stage', account.stage);
});

		

Để biết hướng dẫn chi tiết về cách thiết lập các vai trò và quyền IAM trên các tài khoản, hãy xem Hướng dẫn giới thiệu CLI.

Khi Agent Space của bạn tồn tại và có quyền truy cập vào các tài khoản AWS, bước quan trọng tiếp theo là kết nối các công cụ quan sát và phát triển cung cấp ngữ cảnh điều tra ngoài các dịch vụ gốc của AWS.

Bước 3: Cấu hình tích hợp

AWS DevOps Agent điều tra các sự cố bằng cách tương quan dữ liệu từ nhiều nguồn. Càng có nhiều ngữ cảnh, phân tích nguyên nhân gốc rễ càng chính xác.

Các tích hợp được khuyến nghị theo thứ tự ưu tiên:

Amazon CloudWatch – Cung cấp nhật ký, số liệu và dấu vết từ các dịch vụ AWS. Agent tự động truy vấn CloudWatch Logs Insights trong quá trình điều tra. Không cần cấu hình bổ sung nếu các vai trò IAM được cấu hình đúng cách.
Công cụ quan sát – Datadog, Dynatrace, New Relic và Splunk cung cấp dấu vết phân tán, nhật ký, số liệu và ngữ cảnh cấp ứng dụng. Cấu hình thông qua tích hợp Agent Space trong AWS Console.
Kho lưu trữ mã – Tích hợp GitHub hoặc GitLab cho phép Agent xem xét các triển khai và thay đổi mã gần đây. Yêu cầu OAuth hoặc mã thông báo truy cập cá nhân.
Các pipeline CI/CD – GitHub Actions hoặc GitLab workflows giúp Agent tương quan các sự cố với thời gian triển khai. Được cấu hình cùng với tích hợp kho lưu trữ mã.
Kênh liên lạc – Tích hợp Slack và ServiceNow cho phép DevOps Agent đăng các cập nhật điều tra theo thời gian thực lên các kênh nhóm và tự động cập nhật các phiếu sự cố với các phát hiện, phân tích nguyên nhân gốc rễ và các bước giảm thiểu được đề xuất trong suốt vòng đời điều tra.

Advanced Integrations

Ngoài các tích hợp tích hợp sẵn, AWS DevOps Agent hỗ trợ điều tra được kích hoạt bằng webhook và các máy chủ MCP (Model Context Protocol) tùy chỉnh để bạn có thể mang theo các công cụ quan sát của riêng mình.

Cấu hình Webhook để kích hoạt điều tra
Webhooks cho phép các hệ thống bên ngoài (Grafana, Prometheus, PagerDuty, các công cụ giám sát tùy chỉnh) tự động kích hoạt các cuộc điều tra của DevOps Agent khi sự cố xảy ra. Mỗi Agent Space nhận được một URL webhook duy nhất chấp nhận các payload JSON mô tả sự cố.

Các lỗi cấu hình phổ biến:

Xác thực Webhook: Webhooks sử dụng chữ ký HMAC để bảo mật. Lưu trữ khóa bí mật webhook trong AWS Secrets Manager và xoay vòng nó theo chính sách bảo mật của bạn.
Định dạng Payload: Đảm bảo công cụ giám sát của bạn gửi ngữ cảnh sự cố bao gồm dấu thời gian, tài nguyên bị ảnh hưởng và mô tả triệu chứng. Ngữ cảnh phong phú hơn cho phép điều tra chính xác hơn.

Để biết thiết lập webhook chi tiết, hãy xem Kích hoạt DevOps Agent thông qua Webhook.

Mang theo máy chủ MCP của riêng bạn
Nếu bạn sử dụng các công cụ quan sát ngoài các tích hợp tích hợp sẵn (Grafana, Prometheus, hệ thống đo lường tùy chỉnh), bạn có thể kết nối chúng thông qua các máy chủ MCP. Các máy chủ MCP hiển thị dữ liệu của công cụ của bạn thông qua một giao thức tiêu chuẩn mà DevOps Agent truy vấn trong quá trình điều tra.

Các yêu cầu chính đối với máy chủ MCP:

Điểm cuối HTTPS có thể truy cập công khai: Các máy chủ MCP phải có thể truy cập được từ internet công cộng. Các máy chủ được lưu trữ trong VPC hiện không được hỗ trợ.
Chỉ các công cụ chỉ đọc: Để bảo mật, chỉ hiển thị các công cụ MCP thực hiện các hoạt động đọc. Các hoạt động ghi gây ra rủi ro chèn lời nhắc.
Danh sách cho phép công cụ: Đăng ký các máy chủ MCP ở cấp tài khoản, sau đó chọn lọc kích hoạt các công cụ cụ thể cho mỗi Agent Space. Không cấp quyền truy cập vào tất cả các công cụ – chỉ chọn những công cụ liên quan đến điều tra.

Các lỗi thiết lập MCP phổ biến:

Cấu hình xác thực sai: Các máy chủ MCP hỗ trợ xác thực OAuth 2.0 hoặc khóa API. Xác minh thông tin xác thực máy khách OAuth của bạn là chính xác và các URL trao đổi mã thông báo có thể truy cập được từ cơ sở hạ tầng AWS.
Độ dài tên công cụ: Tên công cụ MCP có độ dài tối đa 64 ký tự. Tên dài hơn sẽ không đăng ký được.
Định dạng URL điểm cuối: Sử dụng URL HTTPS đầy đủ bao gồm đường dẫn. Ví dụ: https://mcp.example.com/v1/mcp chứ không phải chỉ mcp.example.com.

Để biết thiết lập máy chủ MCP toàn diện bao gồm cấu hình xác thực, hãy xem Kết nối máy chủ MCP.

Kiểm tra các tích hợp của bạn
Sau khi cấu hình webhook hoặc máy chủ MCP, hãy kích hoạt một cuộc điều tra thử nghiệm để xác minh kết nối:

Đối với webhook: Gửi một payload thử nghiệm từ công cụ giám sát của bạn và xác minh cuộc điều tra bắt đầu trong ứng dụng web DevOps Agent
Đối với máy chủ MCP: Bắt đầu một cuộc điều tra thủ công và kiểm tra nhật ký Agent để xác nhận nó đã gọi thành công các công cụ MCP của bạn
Xem xét bất kỳ lỗi nào trong nhật ký AWS CloudTrail, nơi ghi lại tất cả các cuộc gọi API của DevOps Agent bao gồm các nỗ lực tích hợp

Với các nguồn dữ liệu của bạn đã được kết nối, bây giờ bạn cần đảm bảo đúng người có quyền truy cập phù hợp vào các cuộc điều tra trong khi vẫn duy trì ranh giới bảo mật.

Bước 4: Cấu hình kiểm soát truy cập

Agent Spaces hỗ trợ kiểm soát truy cập chi tiết để đảm bảo chỉ các thành viên nhóm được ủy quyền mới có thể tương tác với các cuộc điều tra.

Các cân nhắc về kiểm soát truy cập:

Ai nên xem các cuộc điều tra? Thông thường là các kỹ sư trực, SRE và kỹ sư DevOps. Cân nhắc bao gồm các nhóm bảo mật cho các sự cố liên quan đến bảo mật.
Ai nên tạo các trường hợp AWS Support? Thông thường là các trưởng nhóm trực và kỹ sư cấp cao. Hạn chế quyền này để ngăn chặn việc tạo trường hợp quá mức.
Ai nên sửa đổi cấu hình Agent Space? Thông thường là các nhóm vận hành trung tâm hoặc cơ sở hạ tầng. Tách biệt điều này khỏi quyền truy cập điều tra hàng ngày.

Kiểm soát truy cập dựa trên IAM:

AWS DevOps Agent sử dụng các chính sách IAM để kiểm soát quyền truy cập vào Agent Spaces. Đính kèm các chính sách vào người dùng, nhóm hoặc vai trò IAM:

			
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "devopsagent:GetAgentSpace",
        "devopsagent:StartInvestigation",
        "devopsagent:GetInvestigation",
        "devopsagent:ListInvestigations"
      ],
      "Resource": "arn:aws:devopsagent:us-east-1:123456789012:agentspace/EcommerceProd"
    }
  ]
}

		

AWS DevOps Agent hoạt động trong môi trường AWS của bạn với quyền truy cập đặc quyền vào dữ liệu vận hành trên nhiều tài khoản. Mặc dù các nền tảng bảo mật chung được áp dụng, cấu hình Agent Space đưa ra các cân nhắc cụ thể. Để biết hướng dẫn bảo mật toàn diện, hãy xem tài liệu Bảo mật AWS DevOps Agent.

Các kiểm soát truy cập đã được thiết lập – bây giờ là lúc để xác thực rằng cấu hình Agent Space của bạn cung cấp phạm vi điều tra mà bạn cần.

Bước 5: Kiểm tra và lặp lại

Cấu hình Agent Space là một quyết định hai chiều. Bắt đầu với một phạm vi tập trung và mở rộng dựa trên kết quả điều tra.

Kiểm tra Agent Space của bạn:

Kích hoạt một cuộc điều tra thử nghiệm bằng cách sử dụng ứng dụng web AWS DevOps Agent.

Bắt đầu một cuộc điều tra và cung cấp các triệu chứng như “Độ trễ cao trên điểm cuối /api/checkout”.
Quan sát các tài nguyên mà Agent truy vấn.
Xem xét tính đầy đủ của cuộc điều tra. Agent có xác định được nguyên nhân gốc rễ không?
Có tài khoản hoặc dịch vụ nào bị thiếu trong cuộc điều tra không?
Agent có đủ dữ liệu đo lường không?

Điều chỉnh ranh giới Agent Space dựa trên kết quả.

Thêm tài khoản nếu các cuộc điều tra thiếu ngữ cảnh.
Thêm tích hợp nếu tồn tại khoảng trống đo lường.
Thu hẹp phạm vi nếu hiệu suất giảm.

Kết luận

AWS DevOps Agent biến phản ứng sự cố từ một quy trình thủ công, tốn thời gian thành một cuộc điều tra tự động, dựa trên dữ liệu. Tuy nhiên, hiệu quả của Agent phụ thuộc vào cấu hình Agent Space phù hợp. Bằng cách tuân theo cách tiếp cận dựa trên trực – cấp quyền truy cập vào các tài khoản liên quan đến ứng dụng của bạn trong khi tách biệt môi trường sản xuất khỏi môi trường phi sản xuất – bạn cung cấp đủ ngữ cảnh để phân tích nguyên nhân gốc rễ chính xác mà không gây ra sự phức tạp không cần thiết.

Những điểm chính:

Suy nghĩ về ranh giới trực – Phạm vi Agent Space phải phản ánh cách nhóm của bạn điều tra các sự cố
Sử dụng Infrastructure as Code – Các mẫu CDK và Terraform đảm bảo triển khai nhất quán, có thể lặp lại
Tích hợp các công cụ quan sát – Càng nhiều nguồn dữ liệu thì các cuộc điều tra càng chính xác
Lặp lại dựa trên kết quả – Mở rộng hoặc thu hẹp phạm vi Agent Space khi các mẫu điều tra xuất hiện

Các bước tiếp theo:

Tạo Agent Space đầu tiên của bạn

Chúng tôi cam kết làm cho AWS DevOps Agent dễ áp dụng hơn và chính xác hơn trong việc giải quyết các vấn đề của khách hàng. Thiết lập Agent Space của bạn là nền tảng để đạt được giải quyết sự cố nhanh chóng, đáng tin cậy. Có câu hỏi hoặc phản hồi? Hãy để lại bình luận bên dưới.

Về tác giả

Tipu Qureshi
Tipu Qureshi là Kỹ sư Công nghệ Chính cấp cao trong AWS Agentic AI, tập trung vào sự xuất sắc trong vận hành và tự động hóa phản ứng sự cố. Anh ấy làm việc với khách hàng AWS để thiết kế các ứng dụng đám mây linh hoạt, có thể quan sát được và các hệ thống vận hành tự động.

Bill Fine
Bill Fine là Trưởng nhóm Quản lý Sản phẩm cho Agentic AI tại AWS, nơi anh ấy dẫn dắt chiến lược sản phẩm và tương tác với khách hàng cho AWS DevOps Agent.

Greg Eppel
Greg Eppel là Chuyên gia chính về DevOps Agent và đã dành vài năm qua để tập trung vào Cloud Operations và giúp khách hàng AWS trong hành trình đám mây của họ.

AWS Study Group

Các phương pháp hay nhất để triển khai AWS DevOps Agent trong môi trường sản xuất

Agent Space là gì và tại sao nó lại quan trọng?