Tự động hóa q trình triển khai an tồn, khơng cần thao tác thủ cơng Clare Liguori Tự động hóa q trình triển khai an tồn, khơng cần thao tác thủ cơng Bản quyền © 2020 Amazon Web Services, Inc và/hoặc đơn vị liên kết Amazon Web Services, Inc Bảo lưu quyền Tự động hóa q trình triển khai an tồn, khơng cần thao tác thủ cơng Khi tham gia vấn xin việc Amazon, hỏi người vấn rằng: “Bạn triển khai vào môi trường sản xuất lần?” Tại thời điểm đó, tơi phát triển sản phẩm triển khai phát hành hai lần năm Tuy nhiên, cần phát hành sửa lỗi nhỏ phát hành lớn Đối với sửa lỗi phát hành, tơi dành nhiều thời gian để triển khai sửa lỗi cách cẩn thận Sau đó, tơi liên tục kiểm tra kỹ nhật ký số để xem liệu tơi có làm hỏng thứ sau triển khai khơng có cần triển khai lại khơng Tơi biết Amazon thực hành phương pháp triển khai liên tục Vì vậy, tham gia vấn, tơi muốn biết lượng thời gian phải dành cho việc quản lý theo dõi trình triển khai với vai trò nhà phát triển Amazon Người vấn cho biết thay đổi tự động triển khai vào môi trường sản xuất nhiều lần ngày thông qua quy trình triển khai liên tục Khi tơi hỏi lượng thời gian ngày mà họ dành để giám sát kỹ q trình triển khai theo dõi nhật ký số tác động làm, họ cho biết thường khơng thời gian cho việc Vì quy trình giúp nhóm họ thực cơng việc này, nên hầu hết q trình triển khai khơng cần tích cực theo dõi Điều khiến ngạc nhiên Sau gia nhập Amazon, hào hứng tìm xác cách hoạt động q trình triển khai tự động “khơng cần thao tác thủ cơng” Cách q trình triển khai liên tục tiết kiệm thời gian cho nhà phát triển Kể từ đó, tơi thấy tận mắt cách Amazon thiết lập quy trình triển khai liên tục để giúp chúng tơi triển khai nhanh chóng an tồn Tơi đánh giá cao cách phương pháp an tồn triển khai liên tục giúp giảm thời gian làm việc cho nhà phát triển trình triển khai Khi tơi đẩy mã sản xuất vào nhánh kho lưu trữ mã nguồn dịch vụ, thường chuyển sang nhiệm vụ để quy trình lo phần cịn lại Trong đó, quy trình nhóm tơi tiếp quản nhiệm vụ triển khai thay đổi vào mơi trường sản xuất Quy trình tự động hóa hồn tồn việc phát hành thay đổi mã vào dịch vụ sản xuất Điều nghĩa lần cuối mà nhà phát triển khác phải động đến xem xét phần mã mã hợp vào khu lưu trữ mã nguồn Nhóm tơi thiết lập quy trình với bước tự động giúp triển khai thay đổi vào môi trường sản xuất cách an tồn để chúng tơi khơng phải theo dõi trình triển khai Quy trình chạy thay đổi thông qua kiểm thử kiểm tra an toàn triển khai Các bước tự động ngăn không cho sai sót ảnh hưởng đến khách hàng đến mơi trường sản xuất hạn chế tác động sai sót đến khách hàng sai sót xuất mơi trường sản xuất Là nhà phát triển, tơi tin tưởng quy trình giúp tơi triển khai thay đổi vào mơi trường sản xuất cách thận trọng an toàn Nhờ vậy, tơi khơng cần phải tích cực theo dõi q trình triển khai Hành trình đến phân phối liên tục Khi Amazon chưa bắt đầu thực hành phương pháp phân phối liên tục, nhà phát triển phải nhiều thời gian cho việc quản lý q trình triển khai mã họ vào mơi trường sản xuất Chúng áp dụng phương pháp phân phối liên tục tồn cơng ty cách tự động hóa tiêu chuẩn hóa cách chúng tơi triển khai phần mềm giảm thời gian triển khai thay đổi vào môi trường sản xuất Các cải thiện quy trình phát hành chúng tơi tăng dần theo thời gian Tự động hóa q trình triển khai an tồn, khơng cần thao tác thủ công Chúng phát rủi ro triển khai tìm cách giảm thiểu rủi ro thơng qua phương pháp tự động hóa an tồn quy trình Chúng tơi tiếp tục thực lại quy trình phát hành cách phát rủi ro cách để cải thiện độ an tồn q trình triển khai Để tìm hiểu thêm hành trình chúng tơi đến với trình phân phối liên tục cách tiếp tục cải thiện, xem viết Phát triển nhanh nhờ phân phối liên tục Builders’ Library Bốn giai đoạn quy trình Trong viết này, chúng tơi trình bày bước mà thay đổi mã trải qua quy trình Amazon trình triển khai vào mơi trường sản xuất Quy trình phân phối liên tục điển hình có giai đoạn nguồn, dựng, kiểm thử sản xuất Chúng tơi giải thích kỹ thơng tin chi tiết hoạt động diễn giai đoạn quy trình dịch vụ AWS điển hình Chúng tơi cung cấp cho bạn ví dụ cách nhóm dịch vụ AWS thiết lập quy trình họ Nguồn dựng Sơ đồ cung cấp cho bạn tổng quan bước nguồn dựng mà bạn thấy quy trình điển hình nhóm dịch vụ AWS Tự động hóa q trình triển khai an tồn, khơng cần thao tác thủ cơng Nguồn quy trình Các quy trình Amazon tự động xác thực triển khai an toàn loại thay đổi nguồn vào môi trường sản xuất, không thay đổi mã ứng dụng Các quy trình xác thực triển khai thay đổi nguồn tài sản tĩnh trang web, công cụ, kiểm thử, sở hạ tầng, cấu hình hệ điều hành (OS) ứng dụng Tất thay đổi kiểm soát kho lưu trữ mã nguồn riêng lẻ Các phần phụ thuộc mã nguồn, thư viện, ngôn ngữ lập trình tham số, ID AMI, tự động nâng cấp lên phiên nhất tuần lần Các nguồn triển khai quy trình riêng lẻ chế an toàn (như quay lui tự động) mà chúng tơi dùng để triển khai mã ứng dụng Ví dụ: giá trị cấu hình cho dịch vụ thay đổi vào thời gian chạy (như việc tăng giới hạn tốc độ API cờ tính năng) tự động triển khai quy trình cấu hình dành riêng Các thay đổi nguồn tự động quay lui thay đổi gây cố mơi trường sản xuất cho dịch vụ (như lỗi phân tích cú pháp tệp cấu hình) Vi dịch vụ điển hình có quy trình mã ứng dụng, quy trình sở hạ tầng, quy trình vá lỗi hệ điều hành, quy trình cờ tính năng/cấu hình quy trình cơng cụ tốn tử Việc có nhiều quy trình cho vi dịch vụ giúp chúng tơi triển khai thay đổi vào môi trường sản xuất nhanh Các thay đổi mã ứng dụng (làm hỏng kiểm thử tích hợp chặn quy trình ứng dụng) khơng ảnh hưởng đến quy trình khác Ví dụ: thay đổi không chặn thay đổi mã cở hạ tầng đến môi trường sản xuất quy trình sở hạ tầng Tất quy trình cho vi dịch vụ thường trông giống Ví dụ: quy trình cờ tính quy trình mã ứng dụng dùng công nghệ triển khai an tồn mức tác động thay đổi cấu hình cờ tính khơng thích hợp đến mơi trường sản xuất giống với thay đổi mã ứng dụng khơng thích hợp Tự động hóa q trình triển khai an tồn, khơng cần thao tác thủ cơng Xem xét mã Tất thay đổi đến môi trường sản xuất bắt đầu với bước xem xét mã phải thành viên nhóm phê duyệt trước hợp vào nhánh dịng (phiên “chính” chúng tôi) Việc tự động bắt đầu quy trình Quy trình thực thi yêu cầu tất lệnh xác nhận nhánh dịng phải mã thành viên nhóm dịch vụ xem xét phê duyệt cho quy trình Quy trình chặn không cho cam kết chưa xem xét triển khai Nhờ quy trình hồn tồn tự động, xem xét mã bước xem xét phê duyệt thủ công cuối mà kỹ sư thực thay đổi mã trước thay đổi triển khai vào mơi trường sản xuất Vì vậy, bước quan trọng Người xem xét mã đánh giá độ xác mã đánh giá xem thay đổi triển khai vào mơi trường sản xuất cách an tồn khơng Họ đánh giá xem mã có kiểm thử đủ (kiểm thử đơn vị, kiểm thử tích hợp kiểm thử canary) khơng, có cung cấp công cụ đầy đủ cho giám sát triển khai quay lui an tồn hay khơng Một số nhóm sử dụng danh sách kiểm tra tùy chỉnh giống danh sách mẫu bên Danh sách tự động thêm vào hoạt động xem xét mã nhóm để kiểm tra rõ ràng xem có mối lo ngại an tồn triển khai hay khơng Ví dụ danh sách kiểm tra cho xem xét mẫu ## Testing [ ] Did you write new unit tests for this change? [ ] Did you write new integration tests for this change? Include the test commands you ran locally to test this change: ``` mvn test && mvn verify ``` ## Monitoring [ ] Will this change be covered by our existing monitoring? (no new canaries/metrics/dashboards/alarms are required) [ ] Will this change have no (or positive) effect on resources and/or limits? (including CPU, memory, AWS resources, calls to other services) [ ] Can this change be deployed to Prod without triggering any alarms? ## Rollout [ ] Can this change be merged immediately into the pipeline upon approval? [ ] Are all dependent changes already deployed to Prod? [ ] Can this change be rolled back without any issues after deployment to Prod? Tự động hóa q trình triển khai an tồn, khơng cần thao tác thủ công Dựng kiểm thử đơn vị Trong bước dựng, mã dịch kiểm thử đơn vị Các công cụ dựng logic dựng khác tùy theo ngơn ngữ chí tùy theo nhóm Ví dụ: nhóm chọn khung kiểm thử đơn vị, linter công cụ phân tích tĩnh thích hợp cho họ Ngồi ra, nhóm chọn cấu hình cơng cụ đó, phạm vi mã tối thiểu chấp nhận khung kiểm thử đơn vị họ Các công cụ loại kiểm thử chạy khác tùy theo loại mã quy trình triển khai Ví dụ: kiểm thử đơn vị dùng cho mã ứng dụng linter dùng cho mẫu sở hạ tầng dạng mã Tất dựng chạy mà không cần truy cập mạng để tách biệt dựng thúc đẩy khả tái sản xuất dựng Thông thường, kiểm thử đơn vị mô (bắt chước) tất lệnh gọi API chúng phần phụ thuộc, dịch vụ AWS khác Hoạt động tương tác với phần phụ thuộc (không mô “trực tiếp”) kiểm thử sau quy trình kiểm thử tích hợp So với kiểm thử tích hợp, kiểm thử đơn vị với phần phụ thuộc mơ thực trường hợp cá biệt lỗi không mong muốn trả từ lệnh gọi API đảm bảo việc xử lý hợp lý lỗi mã Khi dựng hồn tất, mã dịch đóng gói ký Kiểm thử triển khai môi trường tiền sản xuất Trước triển khai vào môi trường sản xuất, quy trình triển khai xác thực thay đổi nhiều mơi trường tiền sản xuất, ví dụ alpha, beta gamma Alpha beta xác thực mã hoạt động mong đợi cách chạy kiểm thử API chức kiểm thử tích hợp tồn diện Gamma xác thực mã hoạt động triển khai an tồn vào mơi trường sản xuất Gamma giống với mơi trường sản xuất có thể, bao gồm cấu hình triển khai, hoạt động giám sát cảnh báo, kiểm thử canary liên tục dạng môi trường sản xuất Gamma triển khai nhiều Khu vực AWS để phát tác động tiềm ẩn khác biệt khu vực Tự động hóa q trình triển khai an tồn, khơng cần thao tác thủ cơng Kiểm thử tích hợp Kiểm thử tích hợp giúp chúng tơi tự động sử dụng dịch vụ tương tự khách hàng sử dụng Đây bước quy trình Các kiểm thử thực đầu cuối toàn diện cách gọi API thực chạy sở hạ tầng thực giai đoạn tiền sản xuất tất tình sử dụng thực tế khách hàng Mục đích kiểm thử tích hợp phát hành vi khơng mong đợi khơng xác dịch vụ trước triển khai vào môi trường sản xuất Trong kiểm thử đơn vị chạy dựa vào phần phụ thuộc mơ phỏng, kiểm thử tích hợp chạy dựa vào hệ thống tiền sản xuất gọi phần phụ thuộc thực, xác thực giả định mơ cách phần phụ thuộc hoạt động Kiểm thử tích hợp xác thực hành vi API riêng lẻ đầu vào khác Ngoài ra, kiểm thử tích hợp xác thực quy trình công việc đầy đủ kết hợp nhiều API tạo tài nguyên mới, mô tả tài nguyên tài nguyên sẵn sàng, sau sử dụng tài nguyên Kiểm thử tích hợp chạy trường hợp kiểm thử tích cực tiêu cực, cung cấp đầu vào không hợp lệ cho API kiểm tra để đảm bảo lỗi “đầu vào không hợp lệ” trả dự kiến Một số quy trình chạy kiểm thử fuzz để tạo nhiều đầu vào API dùng xác thực API khơng gây lỗi nội dịch vụ Một số quy trình chạy kiểm thử tải ngắn giai đoạn tiền sản xuất để đảm bảo thay đổi không gây độ trễ hồi quy thông lượng cấp tải thực Khả tương thích ngược kiểm thử hộp Trước triển khai vào môi trường sản xuất, cần đảm bảo mã tương thích ngược triển khai an toàn với mã Ví dụ: chúng tơi cần phát xem mã có viết liệu định dạng mà mã khơng thể phân tích cú pháp hay khơng Giai đoạn hộp gamma triển khai mã vào đơn vị triển khai nhỏ nhất, chẳng hạn vào máy ảo đơn lẻ hay chứa đơn lẻ, vào số yêu cầu gọi hàm AWS Lambda Quá trình triển khai hộp để phần cịn lại mơi trường gamma triển khai mã khoảng thời gian, 30 phút Lưu lượng không cần phải dẫn riêng đến hộp Lưu lượng thêm vào cân tải thăm dò hàng đợi phần cịn lại mơi trường gamma Ví dụ: mơi trường gamma gồm 10 chứa sau cân tải, hộp nhận 10% lưu lượng gamma kiểm thử canary liên tục tạo Triển khai hộp giám sát tỷ lệ thành công kiểm thử canary số dịch vụ để phát tác động từ việc triển khai từ việc có nhóm “hỗn hợp” triển khai song song Sơ đồ cho biết trạng thái môi trường gamma sau mã triển khai vào giai đoạn hộp, chưa triển khai vào phần cịn lại nhóm gamma: Tự động hóa q trình triển khai an tồn, khơng cần thao tác thủ công Chúng cần đảm bảo mã tương thích ngược với phần phụ thuộc Ví dụ: thay đổi cần thực vi dịch vụ theo trình tự cụ thể Vi dịch vụ môi trường tiền sản xuất thường gọi điểm cuối sản xuất dịch vụ nhóm khác sở hữu, Amazon Simple Storage Service (S3) Amazon DynamoDB Tuy nhiên, vi dịch vụ gọi điểm cuối tiền sản xuất vi dịch vụ khác nhóm dịch vụ giai đoạn Ví dụ: vi dịch vụ A nhóm gamma gọi vi dịch vụ B nhóm gamma, gọi điểm cuối sản xuất cho Amazon S3 Một số quy trình chạy lại kiểm thử tích hợp giai đoạn tương thích ngược riêng biệt mà gọi zeta Đây môi trường riêng biệt mà vi dịch vụ gọi điểm cuối sản xuất, kiểm thử thay đổi triển khai vào mơi trường sản xuất tương thích với mã triển khai môi trường sản xuất nhiều vi dịch vụ Ví dụ: vi dịch vụ A zeta gọi điểm cuối sản xuất vi dịch vụ B điểm cuối sản xuất cho Amazon S3 Để biết thông tin mô tả chiến lược dùng để viết triển khai thay đổi tương thích ngược, xem viết Đảm bảo an toàn quay lui trình triển khai Builders’ Library Triển khai sản xuất Mục tiêu hàng đầu triển khai sản xuất AWS ngăn tác động tiêu cực nhiều Khu vực thời gian nhiều Vùng sẵn sàng Khu vực Việc giới hạn phạm vi triển khai riêng lẻ hạn chế tác động tiềm ẩn đến khách hàng việc triển khai sản xuất không thành công ngăn chặn tác động đến nhiều Vùng sẵn sàng nhiều Khu vực Để giới hạn phạm vi triển khai tự động, chia giai đoạn sản xuất quy trình thành nhiều giai đoạn nhiều lượt triển khai đến Khu vực riêng lẻ Các nhóm chia q trình triển khai khu vực thành quy trình triển khai có phạm vi nhỏ cách triển khai đến Vùng sẵn sàng riêng lẻ đến phân mảnh (gọi ô) nội riêng lẻ dịch vụ quy trình họ Việc nhằm hạn chế thêm phạm vi tác động tiềm ẩn triển khai sản xuất khơng thành cơng Tự động hóa q trình triển khai an tồn, khơng cần thao tác thủ cơng Triển khai xen kẽ Mỗi nhóm cần cân độ an toàn lượt triển khai phạm vi nhỏ tốc độ mà chúng tơi phân phối thay đổi cho khách hàng tất Khu vực Việc triển khai thay đổi 24 Khu vực 76 Vùng sẵn sàng thơng qua quy trình giúp hạn chế tối thiểu việc gây ảnh hưởng rộng, vài tuần quy trình phân phối thay đổi cho tất khách hàng Chúng nhận thấy việc nhóm lượt triển khai thành “đợt” với quy mơ tăng dần, quy trình sản xuất mẫu trước đây, giúp đạt cân tốc độ rủi ro triển khai Mỗi giai đoạn đợt quy trình bố trí lượt triển khai cho nhóm Khu vực, với thay đổi xúc tiến từ đợt sang đợt khác Các thay đổi vào giai đoạn sản xuất quy trình lúc Sau nhóm thay đổi xúc tiến từ bước đến bước đợt 1, nhóm thay đổi từ gamma xúc tiến vào bước đợt Vì vậy, chúng tơi khơng kết thúc với gói lớn chứa thay đổi đợi triển khai vào môi trường sản xuất đợt quy trình tạo dựng độ tin cậy thay đổi: Đợt triển khai đến Khu vực có số yêu cầu thấp để hạn chế tác động tiềm ẩn triển khai sản xuất thay đổi Đợt triển khai đến Vùng sẵn sàng (hoặc ô) lần Khu vực để triển khai thay đổi Khu vực cách thận trọng Sau đó, đợt thứ triển khai đến Vùng sẵn sàng (hoặc ô) lần Khu vực có số lượng yêu cầu cao, nơi mà nhiều khả khách hàng thực tất đường dẫn mã nơi nhận xác thực thích hợp thay đổi Sau tin tưởng độ an toàn thay đổi từ lượt triển khai đợt quy trình ban đầu, chúng tơi triển khai song song ngày nhiều Khu vực đợt Ví dụ: quy trình sản xuất mẫu trước triển khai đến Khu vực đợt 3, sau đến tối đa 12 Khu vực đợt Khu vực lại đợt Lựa chọn số lượng xác Khu vực đợt số đợt này, số lượng đợt quy trình nhóm dịch vụ phụ thuộc vào phạm vi mẫu sử dụng dịch vụ riêng lẻ Các đợt sau quy trình giúp chúng tơi đạt mục tiêu ngăn chặn tác động tiêu cực đến nhiều Vùng sẵn sàng Khu vực Khi đợt triển khai song song đến nhiều Khu vực, đợt tuân theo hành vi triển khai thận trọng Khu vực dùng Tự động hóa q trình triển khai an tồn, không cần thao tác thủ công đợt ban đầu Từng bước đợt triển khai đến Vùng sẵn sàng ô đơn lẻ từ Khu vực đợt Triển khai luân phiên hộp Triển khai đến đợt sản xuất bắt đầu giai đoạn hộp Như giai đoạn hộp gamma, giai đoạn hộp sản xuất triển khai mã đến hộp (máy ảo đơn lẻ, chứa đơn lẻ số yêu cầu gọi hàm Lambda) Khu vực Vùng sẵn sàng đợt Triển khai hộp sản xuất giảm tối thiểu tác động tiềm ẩn thay đổi đợt cách hạn chế từ đầu yêu cầu mã đợt phân phối Thông thường, hộp phân phối tối đa 10% tổng yêu cầu cho Khu vực Vùng sẵn sàng Nếu thay đổi gây tác động tiêu cực hộp, quy trình tự động quay lui thay đổi không xúc tiến thay đổi đến giai đoạn sản xuất lại Sau giai đoạn hộp, hầu hết nhóm dùng triển khai luân phiên để triển khai đến nhóm sản xuất đợt Triển khai ln phiên đảm bảo dịch vụ có đủ cơng suất để phân phối tải sản xuất suốt trình triển khai Triển khai ln phiên kiểm sốt tốc độ mà mã đưa vào dịch vụ (đó thời điểm bắt đầu phân phối lưu lượng sản xuất) để hạn chế tác động thay đổi Trong lượt triển khai luân phiên thông thường đến Khu vực, tối đa 33% hộp dịch vụ Khu vực (bộ chứa, yêu cầu gọi Lambda phần mềm chạy máy ảo) thay mã Trong trình triển khai, đầu tiên, hệ thống triển khai chọn lô ban đầu gồm tối đa 33% hộp để thay mã Trong trình thay thế, tối thiểu 66% tổng dung lượng tình trạng tốt phân phối yêu cầu Tất dịch vụ điều chỉnh quy mô để tránh Vùng sẵn sàng Khu vực Nhờ vậy, biết dịch vụ phân phối tải sản xuất với cơng suất Sau hệ thống triển khai xác định hộp lô hộp ban đầu vượt qua bước kiểm tra tình trạng, hộp từ nhóm cịn lại thay mã mới, v.v Trong đó, chúng tơi trì tối thiểu 66% công suất để phân phối yêu cầu lúc Để hạn chế thêm tác động thay đổi, số quy trình nhóm triển khai 5% số hộp chúng lần Tuy nhiên, sau quy trình tiến hành quay lui nhanh Tại đây, hệ thống thay 33% số hộp lần mã trước để đẩy nhanh tốc độ quay lui Sơ đồ sau cho biết tình trạng mơi trường sản xuất trình triển khai luân phiên Mã triển khai đến giai đoạn hộp đến lơ nhóm sản xuất Lơ lại bị loại bỏ khỏi cân tải bị ngừng hoạt động để thay Tự động hóa q trình triển khai an tồn, khơng cần thao tác thủ công Giám sát số quay lui tự động Triển khai tự động quy trình thường khơng có nhà phát triển tích cực theo dõi lượt triển khai vào môi trường sản xuất, kiểm tra số quay lui thủ công họ nhận thấy cố Những lượt triển khai hoàn toàn không cần thao tác thủ công Hệ thống triển khai tích cực giám sát cảnh báo để xác định xem có cần tự động quay lui lượt triển khai hay khơng Q trình quay lui chuyển mơi trường hình ảnh chứa, gói triển khai hàm AWS Lambda gói triển khai nội triển khai trước Các gói triển khai nội chúng tơi giống với hình ảnh chứa gói khơng thay đổi dùng giá trị tổng kiểm để xác minh tính tồn vẹn Mỗi vi dịch vụ Khu vực thường có cảnh báo mức độ nghiêm trọng cao Cảnh báo kích hoạt ngưỡng cho số tác động đến khách hàng dịch vụ (như tỷ lệ lỗi độ trễ cao) số tình trạng hệ thống (như mức sử dụng CPU) minh họa ví dụ sau Cảnh báo mức độ nghiêm trọng cao dùng để thông báo cho kỹ sư trực tự động quay lui dịch vụ trình triển khai Thơng thường, kỹ sư trực thơng báo bắt đầu can thiệp, q trình quay lui diễn Ví dụ cảnh báo vi dịch vụ mức nghiêm trọng cao ALARM("FrontEndApiService_High_Fault_Rate") OR ALARM("FrontEndApiService_High_P50_Latency") OR ALARM("FrontEndApiService_High_P90_Latency") OR ALARM("FrontEndApiService_High_P99_Latency") OR ALARM("FrontEndApiService_High_Cpu_Usage") OR ALARM("FrontEndApiService_High_Memory_Usage") OR ALARM("FrontEndApiService_High_Disk_Usage") OR ALARM("FrontEndApiService_High_Errors_In_Logs") OR ALARM("FrontEndApiService_High_Failing_Health_Checks") Các thay đổi q trình triển khai tạo có tác động đến vi dịch vụ ngược tuyến xuôi tuyến Vì vậy, hệ thống triển khai cần giám sát cảnh báo mức độ nghiêm trọng cao vi dịch vụ 10 Tự động hóa q trình triển khai an tồn, khơng cần thao tác thủ cơng trình triển khai, đồng thời giám sát cảnh báo mức độ nghiêm trọng cao vi dịch vụ khác nhóm để xác định thời điểm cần quay lui Các thay đổi triển khai ảnh hưởng đến số kiểm thử canary liên tục Vì vậy, hệ thống triển khai cần giám sát thêm kiểm thử canary không thành công Để tự động quay lui dựa tất vùng tác động tiềm ẩn này, nhóm cần tạo cảnh báo kết hợp có mức độ nghiêm trọng cao cho hệ thống triển khai để giám sát Cảnh báo kết hợp có mức độ nghiêm trọng cao hợp trạng thái tất cảnh báo riêng lẻ có mức độ nghiêm trọng cao liên quan đến vi dịch vụ nhóm, trạng thái cảnh báo canary thành trạng thái kết hợp đơn lẻ, mẫu Nếu cảnh báo mức độ nghiêm trọng cao cho vi dịch vụ nhóm chuyển sang trạng thái cảnh báo, tất lượt triển khai diễn nhóm tất vi dịch vụ nhóm Khu vực tự động quay lui Ví dụ cảnh báo quay lui kết hợp mức độ nghiêm trọng cao ALARM("FrontEndApiService_High_Severity") OR ALARM("BackendApiService_High_Severity") OR ALARM("BackendWorkflows_High_Severity") OR ALARM("Canaries_High_Severity") Giai đoạn hộp phân phối tỷ lệ nhỏ tổng số lưu lượng Vì vậy, cố việc triển khai hộp gây khơng kích hoạt cảnh báo quay lui mức độ nghiêm trọng cao dịch vụ Để phát quay lui thay đổi gây cố giai đoạn hộp trước chúng đến giai đoạn sản xuất cịn lại, ngồi ra, giai đoạn hộp cịn quay lui dựa số gắn với hộp Ví dụ: thay đổi quay lui dựa tỷ lệ lỗi yêu cầu hộp cung cấp riêng, điều tạo nên tỷ lệ nhỏ tổng số yêu cầu Ví dụ cảnh báo quay lui hộp ALARM("High_Severity_Aggregate_Rollback_Alarm") OR ALARM("FrontEndApiService_OneBox_High_Fault_Rate") OR ALARM("FrontEndApiService_OneBox_High_P50_Latency") OR ALARM("FrontEndApiService_OneBox_High_P90_Latency") OR ALARM("FrontEndApiService_OneBox_High_P99_Latency") OR ALARM("FrontEndApiService_OneBox_High_Cpu_Usage") OR ALARM("FrontEndApiService_OneBox_High_Memory_Usage") OR ALARM("FrontEndApiService_OneBox_High_Disk_Usage") OR ALARM("FrontEndApiService_OneBox_High_Errors_In_Logs") OR ALARM("FrontEndApiService_OneBox_Failing_Health_Checks") Bên cạnh việc quay lui dựa cảnh báo nhóm dịch vụ xác định, hệ thống triển khai chúng tơi xác định tự động quay lui dựa vấn đề bất thường số thông thường khung dịch vụ web nội tạo Hầu hết vi dịch vụ tạo số số lượng yêu cầu, độ trễ yêu cầu số lượng lỗi định dạng tiêu chuẩn Bằng cách sử dụng số tiêu chuẩn này, hệ thống triển khai quay lui tự động có vấn đề bất thường số 11 Tự động hóa q trình triển khai an tồn, khơng cần thao tác thủ cơng q trình triển khai Ví dụ việc số lượng yêu cầu đột ngột giảm xuống độ trễ hay số lượng lỗi cao nhiều so với bình thường Thời gian xử lý Đơi khi, chúng tơi khó nhận thấy tác động tiêu cực trình triển khai gây Tác động diễn chậm Điều nghĩa tác động khơng xuất trình triển khai, đặc biệt dịch vụ trình tải chậm vào thời điểm Việc xúc tiến thay đổi đến giai đoạn quy trình sau triển khai xong dẫn đến tác động nhiều Khu vực tác động xuất Khu vực Trước xúc tiến thay đổi đến giai đoạn sản xuất tiếp theo, giai đoạn sản xuất quy trình có thời gian xử lý (bake time) Đó khoảng thời gian quy trình tiếp tục giám sát cảnh báo kết hợp mức độ nghiêm trọng cao nhóm tác động diễn chậm sau triển khai xong trước chuyển đến giai đoạn Để tính lượng thời gian xử lý việc triển khai, cần cân rủi ro việc gây tác động rộng xúc tiến thay đổi đến nhiều Khu vực nhanh so với tốc độ mà chúng tơi phân phối thay đổi cho tất khách hàng Chúng nhận thấy cách hiệu để cân rủi ro dành nhiều thời gian xử lý cho đợt quy trình, đồng thời tạo dựng độ tin cậy an toàn thay đổi, sau rút ngắn thời gian xử lý cho đợt sau Mục tiêu giảm tối thiểu rủi ro tác động ảnh hưởng đến nhiều Khu vực Vì hầu hết lượt triển khai khơng thành viên nhóm tích cực theo dõi, nên thời gian xử lý mặc định quy trình điển hình bảo toàn triển khai thay đổi đến tất Khu vực vòng khoảng ngày làm việc Các dịch vụ lớn đặc biệt quan trọng có nhiều thời gian xử lý bảo toàn nhiều thời gian cho quy trình chúng triển khai tổng thể thay đổi Quy trình điển hình chờ tối thiểu sau giai đoạn hộp, tối thiểu 12 sau đợt khu vực tối thiểu đến sau đợt khu vực lại, với thời gian xử lý bổ sung cho Khu vực, Vùng sẵn sàng ô riêng lẻ đợt Thời gian xử lý bao gồm yêu cầu đợi số lượng điểm liệu cụ thể số nhóm (ví dụ: “đợi tối thiểu 100 u cầu để Tạo API”) để đảm bảo đủ yêu cầu xuất nhằm đảm bảo mã thực đầy đủ Trong toàn thời gian xử lý, triển khai tự động quay lui cảnh báo kết hợp mức độ nghiêm trọng cao nhóm chuyển sang trạng thái cảnh báo Mặc dù xảy ra, số trường hợp, thay đổi khẩn cấp (như sửa lỗi bảo mật việc giảm thiểu cho kiện quy mơ lớn ảnh hưởng đến tính sẵn có dịch vụ) cần phân phối đến khách hàng nhanh thời gian mà quy trình thường để xử lý thay đổi triển khai Trong trường hợp này, chúng tơi giảm thời gian xử lý quy trình để thúc đẩy việc triển khai, cần xem xét kỹ lưỡng thay đổi để thực việc Đối với trường hợp này, chúng tơi cần Kỹ sư tổ chức phải xem xét kỹ lưỡng Nhóm phải xem xét thay đổi mã, mức cấp thiết rủi ro tác động nhờ nhà phát triển giàu kinh nghiệm chuyên gia lĩnh vực an toàn vận hành Thay đổi trải qua bước quy trình bình thường, xúc tiến đến giai đoạn nhanh Chúng quản lý rủi ro triển khai nhanh 12 Tự động hóa q trình triển khai an tồn, khơng cần thao tác thủ cơng cách hạn chế thay đổi di chuyển quy trình thời gian phép thay đổi mã nhỏ cần thiết để xử lý cố cách tích cực theo dõi triển khai Trình chặn cửa sổ thời gian cảnh báo Quy trình ngăn triển khai tự động vào môi trường sản xuất có rủi ro cao gây tác động tiêu cực Quy trình sử dụng “trình chặn” giúp đánh giá rủi ro triển khai Ví dụ: tự động triển khai thay đổi vào môi trường sản xuất số diễn mơi trường khiến tác động xấu kéo dài Trước bắt đầu triển khai vào giai đoạn sản xuất nào, quy trình kiểm tra cảnh báo kết hợp mức độ nghiêm trọng cao nhóm để xác định xem có cố diễn không Nếu cảnh báo trạng thái cảnh báo, quy trình ngăn khơng cho thay đổi chuyển đến bước Quy trình kiểm tra cảnh báo toàn tổ chức, cảnh báo kiện quy mơ lớn cho biết liệu có tác động rộng hệ thống nhóm khác khơng ngăn việc bắt đầu triển khai bổ sung vào tác động tổng thể Nhà phát triển ghi đè trình chặn triển khai thay đổi cần triển khai đến giai đoạn sản xuất để khôi phục từ cố mức độ nghiêm trọng cao Quy trình định cấu hình với cửa sổ thời gian xác định triển khai phép bắt đầu Khi định cấu hình cửa sổ thời gian, cần cân nguyên nhân rủi ro triển khai Mặt khác, khoảng thời gian nhỏ gây thay đổi gây tình trạng chồng chất quy trình khoảng thời gian kết thúc, tăng khả thay đổi số triển khai có tác động khoảng thời gian bắt đầu Mặt khác, khoảng thời gian lớn vượt làm việc thông thường tăng rủi ro kéo dài tác động triển khai không thành công Trong thời gian làm việc, nhiều thời gian để thông báo cho kỹ sư trực ngày, kỹ sư trực thành viên nhóm khác làm việc Trong làm việc thông thường, nhóm can thiệp nhanh sau triển khai không thành công trường hợp cần thực bước khôi phục thủ công Hầu hết triển khai khơng thành viên nhóm tích cực theo dõi, vậy, chúng tơi tối đa hóa thời gian triển khai nhằm giảm tối thiểu thời gian cần thiết để thông báo cho kỹ sư trực, trường hợp cần thực thao tác thủ công việc khôi phục sau quay lui tự động Kỹ sư trực thường nhiều thời gian để can thiệp vào ban đêm, vào ngày nghỉ cuối tuần, thời gian bị loại trừ khỏi cửa sổ thời gian Tùy thuộc vào mẫu sử dụng dịch vụ, số cố không xuất vài sau triển khai Vì vậy, nhiều nhóm loại trừ triển khai vào thứ chiều muộn khỏi cửa sổ thời gian để giảm rủi ro cần thông báo cho kỹ sư trực vào ban đêm cuối tuần sau triển khai Chúng nhận thấy cửa sổ thời gian cho phép khôi phục nhanh cần có thao tác thủ cơng, đảm bảo giảm can thiệp kỹ sư trực ngồi làm việc thơng thường, đồng thời đảm bảo số thay đổi nhỏ gộp với cửa sổ thời gian đóng 13 Tự động hóa trình triển khai an tồn, khơng cần thao tác thủ cơng Quy trình dạng mã Nhóm dịch vụ AWS điển hình sở hữu nhiều quy trình để triển khai nhiều vi dịch vụ loại nguồn (mã ứng dụng, mã sở hạ tầng, vá hệ điều hành, v.v.) nhóm Mỗi quy trình có nhiều giai đoạn triển khai cho số lượng Khu vực Vùng sẵn sàng ngày tăng Điều dẫn đến nhiều cấu hình cho nhóm để quản lý hệ thống quy trình, hệ thống triển khai hệ thống cảnh báo nhiều nỗ lực để cập nhật phương pháp tốt với Khu vực Vùng sẵn sàng Trong vài năm qua, tiếp nhận việc thực “quy trình dạng mã” cách định cấu hình quy trình an tồn cập nhật dễ dàng qn cách tạo mơ hình cấu hình mã Các quy trình nội dạng công cụ mã đẩy từ danh sách tập trung gồm Khu vực Vùng sẵn sàng để dễ dàng thêm Khu vực Vùng sẵn sàng vào quy trình thơng qua AWS Cơng cụ cho phép nhóm tạo mơ hình quy trình phương pháp kế thừa, xác định cấu hình thơng thường quy trình nhóm lớp mẹ (như Khu vực đợt thời gian xử lý cần thiết cho đợt) xác định tất cấu hình quy trình vi dịch vụ dạng lớp kế thừa tất cấu hình thơng thường Kết luận Tại Amazon, tạo dựng phương pháp triển khai tự động theo thời gian dựa yếu tố giúp chúng tơi cân an tồn triển khai với tốc độ triển khai Đồng thời, muốn giảm tối thiểu lượng thời gian mà nhà phát triển cần theo dõi trình triển khai Việc tạo dựng an toàn triển khai tự động quy trình phát hành cách sử dụng quay lui tự động, triển khai sản xuất xen kẽ kiểm thử tiền sản xuất rộng rãi cho phép giảm tối thiểu tác động tiềm ẩn đến môi trường sản xuất việc triển khai gây Điều nghĩa nhà phát triển khơng cần phải tích cực theo dõi q trình triển khai vào mơi trường sản xuất Nhờ quy trình hồn tồn tự động, nhà phát triển sử dụng xem xét mã để kiểm tra mã họ xác nhận thay đổi sẵn sàng triển khai vào môi trường sản xuất Sau thay đổi hợp vào khu lưu trữ mã nguồn, nhà phát triển chuyển sang nhiệm vụ để quy trình lo phần cịn lại Sau đó, quy trình triển khai thay đổi họ vào mơi trường sản xuất cách an tồn thận trọng Quy trình tự động phụ trách việc triển khai liên tục vào môi trường sản xuất nhiều lần ngày, đồng thời cân độ an toàn tốc độ Việc tạo mơ hình phương pháp phân phối liên tục mã giúp việc triển khai trở nên dễ dàng hết Các nhóm dịch vụ AWS thiết lập quy trình để triển khai thay đổi mã họ theo cách tự động an toàn 14