Tác giả: Aamir Dar và Faisal Oria  

Ngày đăng: ngày 07 tháng 4 năm 2025 

Danh mục: Advanced (300), Amazon Q Developer, AWS Elastic Disaster Recovery (DRS), Learning Levels, Management Tools, Storage, Technical How-to

Khả năng giám sát và quản lý khối lượng công việc theo thời gian thực là yêu cầu nền tảng để đảm bảo bạn có thể đáp ứng các mục tiêu về khả năng phục hồi. Việc nắm bắt (visibility) được các hoạt động chính của người dùng và hiệu suất của các chức năng kinh doanh quan trọng cho phép bạn tự động hóa các phản ứng với những sự kiện có thể ảnh hưởng đến hoạt động kinh doanh. Giám sát hiệu quả không chỉ quan trọng để đạt được (achieving) tính toàn vẹn trong vận hành (operational integrity) mà còn giúp quản lý chi phí. Ví dụ, việc chạy các máy chủ không cần thiết hoặc khởi chạy các hệ thống tiêu tốn tài nguyên mà không được giám sát có thể làm tăng chi phí đáng kể. Để giảm thiểu những rủi ro này, cần triển khai một chiến lược giám sát toàn diện nhằm theo dõi việc sử dụng tài nguyên, giám sát các chỉ số hiệu suất chính và cung cấp thông báo thời gian thực để hỗ trợ việc ra quyết định kinh doanh có cơ sở.

Amazon Q Developer cho phép bạn giám sát và phản ứng với các sự kiện vận hành trong Amazon Web Services (AWS). Bạn có thể tích hợp Amazon Q Developer với các kênh Slack để nhận thông báo thời gian thực về các sự kiện, hành động diễn ra trong khối lượng công việc của bạn, cũng như các thay đổi trong hạ tầng. AWS Elastic Disaster Recovery giúp giảm thiểu thời gian ngừng hoạt động và mất dữ liệu bằng cách phục hồi nhanh chóng và đáng tin cậy các ứng dụng tại chỗ và trên đám mây, sử dụng bộ lưu trữ với chi phí hợp lý (affordable storage), tài nguyên tính toán tối thiểu (minimal compute) và khả năng khôi phục theo thời điểm (point-in-time recovery). Bằng cách sử dụng Amazon Q Developer để giám sát môi trường Elastic Disaster Recovery, bạn có thể giúp đội ngũ vận hành phản ứng nhanh với các sự cố tiềm ẩn trước khi chúng trở thành vấn đề nghiêm trọng.

Trong bài viết này, chúng tôi hướng dẫn bạn quy trình tích hợp Amazon Q Developer với Slack để nhận thông báo thời gian thực về các sự kiện quan trọng liên quan đến tài nguyên được bảo vệ bởi Elastic Disaster Recovery. Giải pháp này cho phép bạn chủ động giám sát môi trường khôi phục thảm họa, phát hiện sớm các vấn đề tiềm ẩn và phản ứng nhanh chóng với các sự kiện đó. Với khả năng giám sát thời gian thực, chúng ta có thể cải thiện trạng thái sẵn sàng (posture) về khả năng phục hồi (resilience) tổng thể và đảm bảo đáp ứng được các mục tiêu về tính liên tục của doanh nghiệp (business continuity).

Tổng quan giải pháp

Trong bài viết này, chúng ta sẽ bảo vệ một phiên bản Amazon Elastic Compute Cloud (Amazon EC2) đang chạy trong Region eu-west-1 bằng Elastic Disaster Recovery trong Region eu-west-2.

Đầu tiên, chúng ta sẽ tạo một topic (chủ đề) của Amazon Simple Notification Service (Amazon SNS) để giám sát môi trường Elastic Disaster Recovery. Sau đó, tạo một kênh Slack để nhận thông báo thời gian thực từ Amazon Q Developer.

Để tích hợp các kênh Slack với Amazon Q Developer, chúng ta cần cấu hình Slack để nhận thông báo từ AWS, sau đó cấu hình Amazon Q Developer để gửi tin nhắn đến Slack. Khi hoàn tất, chúng ta sẽ cấu hình các quy tắc Amazon CloudWatch để nhận thông báo thời gian thực về các hành động và sự kiện diễn ra trong khối lượng công việc.

Trong kịch bản này, chúng ta sẽ tạo quy tắc CloudWatch Events để theo dõi các API thay đổi trạng thái (mutating APIs) của Elastic Disaster Recovery, chẳng hạn như StartRecovery, và các CloudWatch Events như “DRS Source Server Data Replication Stalled Change.”

Giải pháp tổng thể được minh họa trong Hình 1 dưới đây.

Điều kiện tiên quyết

Các điều kiện sau là cần thiết để hoàn thành giải pháp này:

• Dịch vụ Elastic Disaster Recovery phải được khởi tạo trong Region mà bạn dự định thực hiện chuyển đổi dự phòng (failover) khi xảy ra sự cố có kế hoạch hoặc không có kế hoạch.
• Bạn có một source server (máy chủ nguồn) đang được bảo vệ bằng Elastic Disaster Recovery. Tham khảo bài blog này (this blog) để được hướng dẫn cụ thể về việc thiết lập Elastic Disaster Recovery cho trường hợp sử dụng liên Region (cross-region).
• Bạn có quyền truy cập vào Slack và quyền tạo kênh cũng như tích hợp nó với Amazon Q Developer.

Hướng dẫn chi tiết

Dưới đây là tóm tắt các bước chính cần thực hiện cho giải pháp này:

1. Tạo một Amazon SNS topic
2. Thiết lập kênh Slack riêng biệt
3. Tích hợp Slack với Amazon Q Developer
4. Cấu hình Amazon Q Developer với Slack
5. Tạo quy tắc Amazon CloudWatch
6. Kiểm tra thông báo

1. Tạo một Amazon SNS topic

Tạo một Amazon SNS topic trong Region nơi bạn muốn giám sát môi trường dịch vụ Elastic Disaster Recovery.
Trong ví dụ này, ta tạo một topic có tên “DRS” trong Region eu-west-1.

Các bước thực hiện:

1.1. Đăng nhập vào Amazon SNS console.
1.2. Trong navigation panel, chọn Topics.
1.3. Trên trang Topics, chọn Create topic.
1.4. Trên trang Create topic, trong phần Details, thực hiện:
 1.4.1. Tại Type, chọn Standard topic type.
 1.4.2. Nhập Name cho chủ đề.
 1.4.3. (Tùy chọn) Nhập Display name cho chủ đề.
1.5. Bỏ qua các tùy chọn khác và chọn Create topic.
Nếu cần, bạn có thể tùy chỉnh thêm chủ đề theo chính sách của tổ chức.
Tham khảo tài liệu chính thức của AWS để biết thêm chi tiết về việc tạo Amazon SNS topic.

Sau khi tạo xong, trang MyTopic sẽ được hiển thị.
Tại phần Details, bạn sẽ thấy các thông tin gồm Tên (Name), ARN, (tùy chọn) Display name, và AWS account ID của chủ sở hữu chủ đề, như minh họa trong Hình 2.

Hình 2: Trang chi tiết chủ đề SNS (SNS topic details page)

2. Tạo kênh Slack

2.1. Tạo một kênh Slack mới hoặc sử dụng kênh hiện có để nhận thông báo. Làm theo hướng dẫn này (this guide) để tạo kênh Slack.

Trong ví dụ này, ta tạo kênh drs-slack-notifications và đặt mức hiển thị (Visibility) là Private, như minh họa trong Hình 3 dưới đây.

Hình 3: Tạo kênh Slack (Creating Slack channel)

3. Tích hợp kênh Slack với Amazon Q Developer

Để cho phép Amazon Q Developer gửi thông báo, bạn cần cấu hình tích hợp giữa Amazon Q Developer và Slack.

3.1. Cấu hình kênh Slack để nhận thông báo từ Amazon Q Developer

3.1.1. Trong kênh Slack của bạn, nhập lệnh “/invite @Amazon Q”,  và nhấn Enter, như minh họa trong Hình 4 dưới đây.

Hình 4: Mời Amazon Q Developer vào kênh Slack (Invite Amazon Q Developer in Slack)

Sau khi hoàn tất, Amazon Q Developer sẽ tham gia vào kênh Slack thông qua lời mời, như minh họa trong Hình 5 dưới đây.

Hình 5: Amazon Q Developer đã được mời vào kênh Slack (Amazon Q Developer invited to Slack channel)

3.2. Cấu hình Amazon Q Developer để gửi thông báo đến kênh Slack

3.2.1. Mở Amazon Q Developer console và chọn Configure new client.
Trong phần Configure a chat client, chọn Slack, sau đó chọn Configure client, như minh họa trong Hình 6 dưới đây.

Hình 6: Chọn Slack làm ứng dụng trò chuyện (Choosing Slack as a chat client)

3.2.2. Ở bước này, bạn cần chọn Slack workspace (không gian làm việc) của mình. Chọn workspace và nhấn Allow để cho phép Amazon Q Developer truy cập vào workspace Slack AWS của bạn, như minh họa trong Hình 7 dưới đây.

Hình 7: Cho phép Amazon Q Developer truy cập vào không gian làm việc Slack

Nếu bạn chưa đăng nhập Slack trên trình duyệt, hãy đăng nhập trước và đảm bảo chọn đúng workspace từ menu thả xuống ở góc trên bên phải của trình duyệt.

Sau khi bạn ủy quyền cho Amazon Q Developer truy cập workspace Slack, một thanh màu xanh lá với thông báo “Slack successfully authorized Amazon Q Developer.” sẽ xuất hiện ở đầu bảng điều khiển AWS, như minh họa trong Hình 8.

Hình 8: Ủy quyền Amazon Q Developer truy cập workspace Slack

3.2.3. Trong trang Workspace details của bảng điều khiển Amazon Q Developer, chọn Configure new channel. Trong phần Configuration details, nhập tên cho cấu hình để dễ nhận biết trong bảng điều khiển AWS.
Ví dụ, tôi đặt tên là aws-drs-slack-notifications, như minh họa trong Hình 9.

Hình 9: Nhập tên cấu hình

3.2.4. Nếu bạn muốn bật tính năng ghi nhật ký (logging) cho cấu hình này, hãy chọn Publish logs to Amazon CloudWatch Logs. Bạn có thể chọn Error only hoặc All events tùy theo nhu cầu, như minh họa trong Hình 10.
CloudWatch Logs cho phép bạn xem tất cả sự kiện do Amazon Q Developer xử lý, cũng như chi tiết lỗi ngăn thông báo xuất hiện trong phòng trò chuyện (chat room) Slack của mình.

Lưu ý: CloudWatch Logs có chi phí bổ sung. Tham khảo chi tiết tại trang Amazon CloudWatch Pricing.

Hình 10: Xuất nhật ký (logs) lên CloudWatch Logs

3.2.5. Trong phần Slack channel, chọn kênh Slack đã tạo trước đó. Amazon Q Developer hỗ trợ cả kênh công khai và riêng tư.

Để tìm Slack Channel ID, nhấp chuột phải vào tên kênh trong thanh bên trái của Slack và chọn View channel details. ID của kênh sẽ hiển thị ở cuối cửa sổ, như minh họa trong Hình 11.

Hình 11: Xem Channel ID trong Slack

Sao chép Channel ID và dán vào ô Channel ID trong phần Slack channel của Amazon Q Developer, như minh họa trong Hình 12.

Hình 12: Nhập Slack Channel ID trong Amazon Q Developer

3.2.6. Các lệnh AWS Command Line Interface (AWS CLI) cũng có thể được thực thi trong kênh Slack, do đó bạn có thể chọn Channel role (nếu tất cả thành viên kênh cần cùng một nhóm quyền) hoặc chọn User-level roles (nếu các thành viên kênh cần các quyền khác nhau), như minh họa trong Hình 13.

3.2.6.1. Trong ví dụ này, tôi chọn Channel role và chọn Create an IAM role using a template trong danh sách thả xuống.

3.2.6.2. Trong ô Role name, nhập tên vai trò IAM — ví dụ: aws-drs-slack-role.

3.2.6.3. Đối với Policy templates, các mẫu Notification permissions và Resource Explorer Permissions được chọn theo mặc định. Bạn có thể chọn thêm các mẫu khác, chẳng hạn như Read-only command permissions templates. Việc chọn các mẫu chính sách (policy templates) này sẽ dẫn đến việc tạo ra quyền IAM (IAM permission) trong tài khoản của bạn. Các chính sách này được đính kèm (attached) vào vai trò kênh (channel role) đã chỉ định ở bước trước.

3.2.6.4. Trong phần Channel guardrail policies, bạn có thể chọn tối đa 5 chính sách để bảo vệ cấu hình kênh. Theo mặc định, chính sách guardrail ReadOnlyAccess được chọn. Chính sách này định nghĩa các quyền Get, List, và Describe trên toàn bộ dịch vụ AWS, cho phép Amazon Q Developer sử dụng vai trò này để truy cập bất kỳ dịch vụ nào trong số đó thay mặt bạn. Các guardrail policies này kiểm soát chi tiết quyền mà thành viên và Amazon Q Developer có thể thực hiện — và luôn có ưu tiên cao nhất. Ví dụ: nếu một người dùng có quyền quản trị, nhưng kênh được ràng buộc bởi guardrail hạn chế, thì người đó chỉ có quyền giới hạn.

Hình 13: Tạo Channel role và chọn quyền cho vai trò

3.2.7. Trong phần Notifications (optional), chọn SNS topic đã tạo ở đầu hướng dẫn và chọn AWS Region của bạn, như minh họa trong Hình 14.
Bạn có thể thêm nhiều vùng nếu đã tạo SNS topic ở từng vùng để giám sát nhiều khu vực AWS khác nhau.

Hình 14: Cấu hình SNS notifications cho Amazon Q Developer

3.2.8. Trong phần Tags, thêm thẻ tùy chỉnh cho Slack client. Ví dụ, tôi thêm hai thẻ như minh họa trong Hình 15.

Hình 15: Thêm thẻ (tags) cho kênh Slack

3.2.9. Cuối cùng, chọn Configure để hoàn tất cấu hình.
Sau khi hoàn tất, thông báo màu xanh lá “You successfully configured the Slack channel.” sẽ xuất hiện trong bảng điều khiển AWS, như minh họa trong Hình 16.

Hình 16: Cấu hình Slack client với Slack channel thành công

Các API sau đây được thực thi trong các Region tương ứng — có thể tham khảo để xử lý sự cố (xem Bảng 1):

Region	us-east-2	us-east-1	eu-west-1
APIs	CreateSlackChannelConfiguration, GetAccountPreferences	CreateRole, CreatePolicy, AttachRolePolicy	Subscribe

Bảng 1: Ánh xạ API theo Region (API to regions mapping)

API Subscribe hiển thị ở Region eu-west-1 vì tôi đã chọn Region này để nhận thông báo từ SNS topic.

4. Tạo quy tắc Amazon CloudWatch

Để nhận thông báo Slack về các hành động API thay đổi trạng thái (mutating API actions) của Elastic Disaster Recovery, ta cần tạo CloudWatch Rule trong AWS Region nơi dịch vụ này được cấu hình.

4.1. Cấu hình quy tắc CloudWatch

4.1.1. Mở Amazon EventBridge console, chọn Rules, sau đó chọn Create rule.
4.1.2. Nhập Name và (tùy chọn) Description cho quy tắc.
4.1.3. Trong Event bus, chọn default event bus.
4.1.4. Giữ nguyên tùy chọn Enable the rule on the selected event bus và chọn loại quy tắc (rule type) là Rule with an event pattern, sau đó nhấn Next, như minh họa trong Hình 17.

Hình 17: Định nghĩa chi tiết quy tắc CloudWatch (Defining CloudWatch rule details)

4.2. Xây dựng mẫu sự kiện (Event pattern)

4.2.1. Ở trang Build event pattern, chọn Other tại Event source. Bỏ qua phần Sample event – optional.
4.2.2. Trong phần Creation method, chọn tùy chọn Custom pattern (JSON editor) như trong Hình 18.

Hình 18: Chọn mẫu sự kiện CloudWatch và phương thức tạo (Choosing CloudWatch Event pattern and Creation method)

4.2.3. Thêm các API của Elastic Disaster Recovery muốn nhận thông báo, rồi chọn Next, như minh họa trong Hình 19.

Ví dụ mẫu JSON:

JSON

{

  "source": ["aws.drs"],

  "detail-type": ["AWS API Call via CloudTrail"],

  "detail": {

    "eventSource": ["drs.amazonaws.com"],

    "eventName": ["InitializeService", "CreateSourceServerForDrs", "DisconnectSourceServer", "StartRecovery", "StartReplication", "StopFailback", "DeleteSourceServer", "ReverseReplication", "StartFailbackLaunch", "DisconnectRecoveryInstance", "DeleteRecoveryInstance"]

  }
}

Hình 19: Thêm mẫu sự kiện CloudWatch (Adding CloudWatch Event pattern)

Để tìm hiểu thêm về tất cả các API của dịch vụ Elastic Disaster Recovery, hãy truy cập tài liệu Elastic Disaster Recovery này.

4.2.4. Trong Select target(s), chọn AWS service làm Target 1 → chọn SNS topic. Chọn topic đã tạo ở Bước 1, sau đó nhấn Next, như minh họa trong Hình 20.

Hình 20: Chọn SNS targets (Selecting SNS targets)

4.2.5. Thêm tags (tùy chọn) → Next.

4.2.6. Xem lại cấu hình và nhấn Create rule.

4.2.7. Thực hiện lại các bước này và tạo một CloudWatch rule (quy tắc CloudWatch) khác để nhận thông báo về các CloudWatch Events (Sự kiện CloudWatch) khác được Elastic Disaster Recovery hỗ trợ. Để biết thêm chi tiết về danh sách sự kiện được hỗ trợ, tham khảo tài liệu hướng dẫn người dùng Elastic Disaster Recovery.

Trong ví dụ này, ta chọn sự kiện CloudWatch liên quan đến việc sao chép dữ liệu (data replication) của source server (máy chủ nguồn) bị ngưng trệ (stalled) cùng với một số sự kiện khác.

Việc sao chép dữ liệu có thể bị ngưng trệ (stall) do nhiều yếu tố khác nhau, bao gồm:

• Các sự cố kết nối mạng (Network connectivity issues): Điều này có thể bao gồm việc cấu hình sai security groups, network ACLs, hoặc route tables, ngăn cản giao tiếp giữa source server và staging subnet.
• Các sự cố AWS Replication Agent: AWS Replication Agent cho Elastic Disaster Recovery có thể không chạy đúng cách trên source server do các sự cố trên chính source server đó.
• Các sự cố quyền IAM (IAM permission problems): Replication server (máy chủ sao chép) có thể thiếu các quyền IAM cần thiết, chẳng hạn như thiếu IAM role, các permission policies (chính sách quyền), hoặc trust relationship policy (chính sách quan hệ tin cậy).

Duy trì sao chép dữ liệu liên tục là yếu tố then chốt cho tính liên tục của doanh nghiệp (business continuity). Theo dõi các sự kiện CloudWatch về tình trạng sao chép bị ngưng trệ giúp bạn chủ động phát hiện và khắc phục vấn đề kịp thời, nhanh chóng khôi phục việc sao chép dữ liệu liên tục đến máy chủ của bạn.

Ví dụ, thêm mẫu JSON sau vào phần Event pattern để giám sát các sự kiện CloudWatch này:

{

  "source": ["aws.drs"],

  "detail-type": ["DRS Source Server Data Replication Stalled Change", "DRS Recovery Instance Failback State Change", "DRS Source Server Launch Result"]

}

5. Kiểm tra thông báo

Cài đặt AWS Replication Agent trên máy chủ nguồn để kiểm tra thông báo. Khi cài đặt AWS Replication Agent thành công, bạn sẽ nhận được thông báo trong kênh Slack cho API CreateSourceServerForDrs kèm theo các chi tiết bổ sung.

Hình 21: Thông báo Slack khi cài đặt thành công Elastic Disaster Recovery agent

Khi xảy ra tình trạng ngưng trệ sao chép dữ liệu (data replication stalls) trong Elastic Disaster Recovery, tính liên tục của doanh nghiệp (business continuity) có thể bị gián đoạn. Việc sao chép từ các source server (máy chủ nguồn) sang các replication server (máy chủ sao chép) bị ngừng lại, có nghĩa là dữ liệu mới nhất không được sao chép. Điều này được thể hiện bằng trạng thái Stalled trong cột Data Replication Status của Elastic Disaster Recovery console, đòi hỏi người dùng phải chú ý ngay lập tức, như trong Hình 22.

Hình 22: Elastic Disaster Recovery bị ngưng trệ sao chép (stalled replication)

Với tích hợp CloudWatch Event “DRS Source Server Data Replication Stalled Change”, Amazon Q Developer sẽ gửi thông báo vào Slack, như trong Hình 23.

6. Dọn dẹp (Cleaning up)

Để giảm thiểu chi phí AWS không cần thiết, hãy xóa tất cả các tài nguyên mà bạn đã tạo, bao gồm các Amazon EC2 instances, các source server của Elastic Disaster Recovery, các CloudWatch Event rules, Slack client trong Amazon Q Developer, và các SNS topics. Việc để các tài nguyên này hoạt động có thể dẫn đến các khoản phí không mong muốn trên hóa đơn AWS của bạn, ngay cả khi chúng không được sử dụng. Hãy đảm bảo xem xét tất cả các tài nguyên đã được cung cấp và chấm dứt bất kỳ tài nguyên nào không còn cần thiết.

7. Kết luận

Trong bài viết này, chúng tôi đã hướng dẫn bạn các bước để tích hợp Amazon Q Developer với Slack, cho phép nhận thông báo theo thời gian thực về các sự kiện quan trọng liên quan đến tài nguyên được bảo vệ bởi AWS Elastic Disaster Recovery. Elastic Disaster Recovery giúp các tổ chức duy trì tính liên tục trong hoạt động kinh doanh bằng cách nhanh chóng khôi phục ứng dụng và dữ liệu về trạng thái gần đây nhất của chúng. Các thông báo theo thời gian thực về hoạt động của khối lượng công việc quan trọng là yếu tố then chốt để đảm bảo rằng các ứng dụng có thể đáp ứng các Mục tiêu Điểm Khôi phục (RPO – Recovery Point Objectives) và Mục tiêu Thời gian Khôi phục (RTO – Recovery Time Objectives) theo yêu cầu. Trong các tình huống khôi phục sau thảm họa, từng giây đều quan trọng — khả năng phát hiện và phản ứng nhanh với sự gián đoạn (disruptions) có thể tạo nên sự khác biệt giữa việc đáp ứng (meeting) các mục tiêu này và việc gây thất vọng cho người dùng (disappointing users).

Việc tích hợp Amazon Q Developer với các quy tắc CloudWatch Events giúp nâng cao đáng kể khả năng giám sát của bạn đối với Elastic Disaster Recovery. Amazon Q Developer cho phép bạn nhận thông báo theo thời gian thực trực tiếp trong các kênh liên lạc ưa thích, chẳng hạn như Slack. Trong bài viết này, chúng tôi đã cấu hình các quy tắc CloudWatch Event để tự động theo dõi các hành động và sự kiện cụ thể của Elastic Disaster Recovery, chẳng hạn như thay đổi trong quá trình sao chép dữ liệu của các máy chủ nguồn.

Chúng tôi hy vọng rằng bài viết này hữu ích cho bạn và mong nhận được phản hồi từ bạn. Hãy truy cập trang Elastic Disaster Recovery để tìm hiểu thêm về dịch vụ này. Bạn cũng có thể khám phá (explore) các nghiên cứu tình huống (case studies) về những người dùng đang sử dụng Elastic Disaster Recovery để bảo vệ khối lượng công việc của họ trên AWS.

TAGS: AWS Cloud Storage, AWS Elastic Disaster Recovery, AWS Elastic Disaster Recovery (DRS)

Aamir Dar là Kỹ sư Hỗ trợ Đám mây (Cloud Support Engineer) tại AWS Premium Support, làm việc tại Dublin. Trong vai trò của mình, Aamir thích giúp khách hàng giải quyết các vấn đề phức tạp liên quan đến EC2, Application Migration Service và Elastic Disaster Recovery Service. Khi không làm việc, anh dành thời gian cho gia đình và đi dạo trên bãi biển.

Faisal Oria là Quản lý Tài khoản Kỹ thuật (Technical Account Manager) tại Amazon Web Services (AWS), nơi anh hợp tác với các khách hàng doanh nghiệp để thiết kế, triển khai và mở rộng các ứng dụng đám mây phù hợp với mục tiêu kinh doanh của họ. Anh cũng là chuyên gia (SME) về Migration and Disaster Recovery Services (Dịch vụ Di chuyển và Khôi phục Thảm họa), và đã tham gia nhiều dự án di chuyển hệ thống trong nhiều ngành công nghiệp khác nhau.