Một cái nhìn tổng quan đơn giản về sự kiện AWS lần này từ góc độ của một SRE trong AIGC Startup, hy vọng có thể giúp ích cho mọi người. Kể từ khi bắt đầu làm việc, tôi đã nhận thấy rằng cụm chính của chúng tôi nằm ở USE1, vì vậy tôi đã bắt đầu chuẩn bị một số thứ. Những việc chính tôi đã làm là: 1. Sao lưu nhiều địa điểm cho một số cơ sở dữ liệu cốt lõi của chúng tôi, tạo thành sao lưu tại USE1, Tokyo và SG. Như vậy, trong trường hợp cực đoan, chúng tôi có thể mất một phần dữ liệu nhưng vẫn đảm bảo dịch vụ tiếp tục hoạt động. 2. Chuyển đổi cụm thử nghiệm SG của chúng tôi từ K3S tự xây dựng trên EC2 thành một cụm AWS EKS tiêu chuẩn. Điều này cho phép chúng tôi nhanh chóng khởi động một cụm trong thời điểm thảm họa, tái sử dụng các thành phần đã có của AWS. Giảm thiểu chi phí thay đổi manifest. 3. Đơn giản hóa một SOP, bao gồm thông báo cho người dùng, chuyển đổi DNS, đóng phiên bản, v.v. Quay lại hôm nay, khoảng 10 phút sau khi sự cố AWS xảy ra, tôi phát hiện có một Pod mới trong container của chúng tôi không thể thiết lập. Sau khi xác nhận với hỗ trợ AWS rằng đây là vấn đề của USE1, tôi nhận ra rằng sự kiện ECR chắc chắn liên quan đến các sự kiện khác, vì vậy tôi đã quyết định xử lý theo kế hoạch sự kiện cấp Tier1 mà tôi đã lập (đối với SRE, những việc như thế này có thể sai nhưng không thể bỏ lỡ). T+0 phút, tôi đã phát hành thông báo cho toàn bộ nhân viên, bắt đầu vào chế độ khẩn cấp. Tôi đã thiết lập một cuộc họp công khai cho tất cả mọi người. Tất cả nhân viên có thể tham gia bất cứ lúc nào. T+2 phút, tôi xác nhận sự kiện như tôi đã dự đoán, đang dần mở rộng, tôi đã phát đi hai chỉ thị: 1. Cấm mọi mã được hợp nhất/gửi (chủ yếu để tránh việc tạo tài nguyên mới dẫn đến Pod quay vòng và ảnh hưởng đến lưu lượng), 2. Yêu cầu các đồng nghiệp vận hành chuẩn bị thông báo. T+3 phút, tôi bắt đầu theo SOP, tiến hành khôi phục cơ sở dữ liệu tại khu vực SG và tạo các phụ thuộc như OpenSearch/Redis. T+5 phút, chúng tôi bắt đầu xác nhận các vấn đề cụ thể của các phụ thuộc lên/xuống, xác nhận một dịch vụ cốt lõi mới ra mắt bị ảnh hưởng. T+10 phút, chúng tôi phát hành thông báo ngừng dịch vụ và thông báo về các dịch vụ bị ảnh hưởng khác. T+10 phút, tôi đã nhờ hai đồng nghiệp khác hỗ trợ thiết lập ECR mới và dọn dẹp tài nguyên hiện có trong môi trường thử nghiệm, đồng thời thông báo cho CTO rằng trong trường hợp cực đoan, chúng tôi có thể phải đưa ra quyết định về việc bảo toàn trải nghiệm và mất dữ liệu. T+15 phút, chúng tôi cuối cùng xác nhận rằng các tài nguyên đã tạo và hướng lưu lượng vào sẽ không bị ảnh hưởng quá lớn. Kế hoạch chuyển đổi bị hoãn lại, nhưng chúng tôi tiếp tục chuẩn bị các tài nguyên liên quan. T+30 phút, cơ sở dữ liệu đầu tiên của chúng tôi đã được khôi phục hoàn tất. T+40 phút, cơ sở dữ liệu thứ hai của chúng tôi đã được khôi phục hoàn tất. T+1h, tất cả hạ tầng cốt lõi liên quan của chúng tôi, RDS/ES/Redis đều đã sẵn sàng và được thiết lập các tùy chọn tối ưu như chính và phụ. Đồng thời, chúng tôi cũng bắt đầu khởi động các dịch vụ mới trên cụm mới. May mắn thay, cuối cùng sự cố AWS không ảnh hưởng đến tất cả các dịch vụ của chúng tôi. Chúng tôi không phải đối mặt với công việc sửa chữa dữ liệu phức tạp sau khi chuyển đổi lưu lượng. Khoảng T+2h đến T+3h sau, tôi chính thức thông báo cho toàn bộ nhân viên rằng tình trạng khẩn cấp đã được dỡ bỏ. Để đảm bảo an toàn, tối nay vẫn sẽ đóng phiên bản tính năng. Nhìn lại toàn bộ sự cố, tôi còn có thể làm nhiều hơn nữa: 1. Công khai SOP về các trường hợp cực đoan mà tôi đã chuẩn bị trước đó cho tất cả nhân viên. Điều này đảm bảo rằng ngay cả khi tôi không có mặt, vẫn có người có thể thay thế tôi. 2. Chúng tôi có thể thực hiện một số buổi diễn tập trước. 3. Các chỉ thị có thể được đưa ra quyết đoán hơn. Gần như vậy, một chút chia sẻ, hy vọng có thể giúp ích cho mọi người.