Tiến bước nhanh hơn nhờ phân phối liên tục

Hơn 10 năm trước, chúng tôi thực hiện một dự án tại Amazon để tìm hiểu các nhóm của mình nhanh chóng biến ý tưởng thành hệ thống sản xuất chất lượng cao như thế nào. Từ đó, chúng tôi đã đo lường thông lượng phần mềm để có thể cải thiện tốc độ thực hiện. Chúng tôi nhận thấy rằng phải mất trung bình 16 ngày từ giai đoạn kiểm nhập (check-in) mã đến giai đoạn sản xuất. Tại Amazon, các nhóm bắt đầu từ một ý tưởng, rồi thường viết mã trong một ngày rưỡi để biến ý tưởng thành hiện thực. Chúng tôi dành ra chưa đến 1 tiếng để xây dựng và triển khai mã mới. Trong thời gian còn lại (gần 14 ngày), chúng tôi đợi các thành viên trong nhóm tạo bản dựng, triển khai và chạy kiểm thử. Vào cuối dự án, chúng tôi đề xuất tự động hóa các quy trình hậu kiểm nhập để cải thiện tốc độ thực hiện. Mục đích là loại bỏ sự trì hoãn mà vẫn giữ vững hay thậm chí là cải thiện chất lượng.

Trọng tâm của đề xuất này là một chương trình cải tiến liên tục nhằm tăng tốc độ thực hiện. Quyết định cải thiện tốc độ thực hiện của chúng tôi dựa trên nguyên tắc lãnh đạo: Luôn giữ vững các tiêu chuẩn cao nhất. Nguyên tắc này tập trung vào việc không ngừng đặt ra các tiêu chuẩn cao, liên tục nâng cao tiêu chuẩn cũng như cung cấp các sản phẩm, dịch vụ và quy trình có chất lượng cao. Nguyên tắc lãnh đạo của chúng tôi mô tả cách Amazon tiến hành kinh doanh, cách dẫn dắt của đội ngũ lãnh đạo và cách chúng tôi luôn đặt khách hàng ở vị trí trung tâm khi ra quyết định.

Amazon đã xây dựng các công cụ phát triển phần mềm để giúp các kỹ sư phần mềm của mình làm việc hiệu quả hơn. Chúng tôi đã tạo ra hệ thống xây dựng tập trung và được lưu trữ của riêng mình là Brazil, chuyên thực hiện một chuỗi các lệnh trên máy chủ nhằm tạo ra artifact có thể triển khai. Tại thời điểm đó, Brazil không lắng nghe các thay đổi về mã nguồn. Phải có người khởi tạo bản dựng. Chúng tôi cũng có hệ thống triển khai riêng là Apollo. Hệ thống này yêu cầu phải tải lên một artifact bản dựng trong quá trình bắt đầu triển khai. Sự quan tâm đến hoạt động phân phối liên tục trong toàn ngành đã thôi thúc chúng tôi xây dựng hệ thống của riêng mình là Pipelines, nhằm tự động hóa quá trình phân phối phần mềm giữa Brazil và Apollo.

Các quy trình phát hành của chúng tôi, bao gồm cả pipeline và hệ thống triển khai, phải được thiết kế để xác định các khiếm khuyết đó càng nhanh càng tốt và ngăn chúng ảnh hưởng đến khách hàng. Chúng tôi cần đảm bảo rằng các quy trình phát hành được đặt cấu hình chính xác và artifact bản dựng hoạt động đúng như dự kiến.

Chuẩn bị triển khai: Hình thức cơ bản nhất của kiểm thử triển khai sẽ đảm bảo rằng artifact mới triển khai có thể bắt đầu và phản hồi với công việc. Trong quy trình hậu triển khai, chúng tôi chạy các kiểm tra nhanh nhằm đảm bảo artifact mới triển khai đã bắt đầu và đáp ứng lưu lượng truy cập. Ví dụ: chúng tôi sử dụng cơ chế hook sự kiện vòng đời trong tệp AWS CodeDeploy AppSpec để lệnh cho các tập lệnh đơn giản dừng lại, bắt đầu và xác thực quy trình triển khai. Chúng tôi cũng kiểm tra xem mình có đủ dung lượng để đáp ứng lưu lượng truy cập của khách hàng không. Chúng tôi đã xây dựng các kỹ thuật như máy chủ lưu trữ có tình trạng tốt tối thiểu trong CodeDeploy để chắc chắn rằng mình luôn có đủ dung lượng để phục vụ khách hàng. Cuối cùng, nếu cơ chế triển khai có thể phát hiện sự cố, nó sẽ rút lại thay đổi để giảm thiểu thời gian mà khách hàng nhận thấy khiếm khuyết.

Kiểm thử trước sản xuất: Một trong những cách làm tốt nhất của Amazon là tự động hóa đơn vị, tích hợp và kiểm thử trước sản xuất, rồi thêm các kiểm thử này vào pipeline. Chúng tôi quán triệt việc thực hiện kiểm thử tải và bảo mật, và thường ưu tiên thêm bước kiểm thử vào pipeline của mình. Khi nhắc đến kiểm thử đơn vị, chúng tôi muốn nói đến tất cả bước kiểm thử có thể thực hiện trên máy xây dựng, bao gồm kiểm tra kiểu, phạm vi sử dụng mã, độ phức tạp của mã, v.v. Chúng tôi nghĩ về kiểm thử tích hợp như một quy trình bao gồm toàn bộ bước kiểm thử ngoài hộp, chẳng hạn như đưa sự cố vào, kiểm thử trình duyệt tự động, v.v. Có nhiều bài viết hay về kiểm thử đơn vị và tích hợp, vì vậy tôi sẽ không đi vào chi tiết ở đây.

Kiểm thử đơn vị và tích hợp nhằm xác minh rằng artifact bản dựng hoạt động đúng chức năng. Càng tiến hành xác minh nhiều thì chúng tôi càng giảm được rủi ro khiếm khuyết xuất hiện với khách hàng. Để rút ngắn thời gian đưa sản phẩm đến tay khách hàng, chúng tôi cố gắng phát hiện khiếm khuyết càng sớm trong quy trình phát hành càng tốt. Nhìn chung, điều này có nghĩa là nếu bước kiểm thử có quy mô nhỏ và diễn ra nhanh hơn, ta sẽ sớm nhận được phản hồi về bất kỳ sự cố nào khi có thay đổi.

Tại Amazon, chúng tôi cũng sử dụng một kỹ thuật có tên kiểm thử tiền sản xuất. Môi trường tiền sản xuất là bước kiểm thử cuối cùng trước khi chúng tôi triển khai thay đổi trong giai đoạn sản xuất. Kiểm thử môi trường tiền sản xuất sử dụng cấu hình sản xuất của hệ thống để hoạt động đúng như một hệ thống sản xuất. Cách này mang lại hai lợi ích. Thứ nhất, môi trường tiền sản xuất sẽ kiểm thử cấu hình sản xuất để đảm bảo rằng dịch vụ có thể kết nối chính xác với tất cả tài nguyên sản xuất, bao gồm cả nơi lưu trữ dữ liệu sản xuất. Thứ hai, nó đảm bảo rằng hệ thống tương tác đúng cách với các API của dịch vụ sản xuất mà hệ thống dựa vào. Môi trường tiền sản xuất chỉ được nhóm sở hữu dịch vụ đó sử dụng, đồng thời không bao giờ nhận được lưu lượng truy cập của khách hàng. Việc chạy kiểm thử tiền sản xuất sẽ giúp chúng tôi bảo đảm rằng mã và cấu hình đó sẽ hoạt động trong giai đoạn sản xuất.

Xác minh trong giai đoạn sản xuất: Khi phát hành mã cho khách hàng, chúng tôi không thực hiện tất cả cùng lúc. Bởi như vậy sẽ gây ra tác động lớn rằng khiếm khuyết sẽ xuất hiện với tất cả khách hàng. Thay vào đó, chúng tôi triển khai vào các cụm - một phiên bản dịch vụ hoàn toàn độc lập. Khi triển khai thay đổi cho nhóm khách hàng đầu tiên trong cụm đầu tiên, chúng tôi cực kỳ thận trọng. Chúng tôi sẽ chỉ cho một số khách hàng nhìn thấy thay đổi mới, rồi thu thập phản hồi xem mã mới có hoạt động không. Chúng tôi theo dõi số lượng lỗi mà dịch vụ tạo ra sau khi triển khai thử nghiệm. Nếu tỷ lệ lỗi tăng lên, chúng tôi sẽ tự động rút lại thay đổi. Ví dụ: chúng tôi có thể đợi để đạt được 3.000 điểm dữ liệu tích cực mà không có điểm dữ liệu tiêu cực nào trước khi tiếp tục triển khai.

Sự cố có thể xảy ra nếu kiểm thử tự động thiếu một trường hợp sử dụng. Chúng tôi cố gắng nắm được tất cả các lỗi bằng kiểm thử có cấu trúc và có thể lặp lại, bằng cả hình thức tự động lẫn thủ công. Tuy nhiên, ngay cả khi chúng tôi cố hết sức thì khiếm khuyết vẫn có thể xuất hiện. Để kiểm tra các kiểm thử của mình, chúng tôi đưa thay đổi mới vào sản xuất trong một khoảng thời gian nhất định để xem người không phải thành viên nhóm có nhận thấy sự cố nào không. Chúng tôi đã dành rất nhiều thời gian tranh luận xem có nên chỉ áp dụng thay đổi trong giai đoạn sản xuất hay không, cũng như nên chờ bao lâu sau khi triển khai thử nghiệm để áp dụng cho phần còn lại của nhóm triển khai. Rất nhiều nhóm đã quyết định đợi một khoảng thời gian nhất định ngoài việc thu thập điểm dữ liệu tích cực rồi mới tiến hành quy trình triển khai. Khoảng thời gian mà pipeline đợi phụ thuộc phần lớn vào nhóm. Có nhóm đợi hàng giờ, có nhóm chỉ đợi vài phút. Tác động càng cao và thời gian khắc phục sự cố càng dài thì quy trình phát hành càng chậm.

Sau khi đã chắc chắn ở cụm đầu tiên, chúng tôi sẽ đưa thay đổi mã mới đến với nhiều khách hàng hơn nữa cho đến khi phát hành hoàn toàn. Cũng như với quá trình triển khai thay đổi mã, chúng tôi đợi để có được sự chắc chắn trong quá trình triển khai cho cụm mới đầu tiên, rồi mới chuyển đến cụm tiếp theo. Khi chắc chắn hơn về artifact bản dựng, chúng tôi giảm thời gian dành cho việc xác minh thay đổi mã. Việc này dẫn đến một quy luật mà chúng tôi muốn nhận được từ khách hàng trong giai đoạn kiểm nhập đến giai đoạn sản xuất đầu tiên càng sớm càng tốt. Tuy nhiên, sau khi chuyển sang giai đoạn sản xuất, chúng tôi dần phát hành mã mới cho khách hàng, nỗ lực tăng cường độ chắc chắn khi dần đẩy nhanh tốc độ của các lần triển khai còn lại.

Để đảm bảo hệ thống sản xuất liên tục đáp ứng yêu cầu của khách hàng, chúng tôi tạo ra lưu lượng truy cập tổng hợp trên các hệ thống của mình. Do muốn có phản hồi nhanh nếu các dịch vụ của mình không hoạt động chính xác, chúng tôi chạy kiểm thử tổng hợp ít nhất mỗi phút một lần. Chúng tôi thiết kế kiểm thử tổng hợp để đảm bảo rằng các quy trình đang chạy đều ở tình trạng tốt, cũng như tất cả yếu tố phụ thuộc đều được kiểm thử, trong đó thường bao gồm kiểm thử tất cả API hướng công khai.

Kiểm soát thời điểm phát hành phần mềm: Để kiểm soát vấn đề an toàn trong các lần phát hành phần mềm, chúng tôi xây dựng các cơ chế cho phép kiểm soát tốc độ thực hiện thay đổi trong pipeline. Chúng tôi sử dụng số liệu, khoảng thời gian và kiểm tra an toàn để kiểm soát thời điểm phát hành phần mềm.

Pipeline có thể được cấu hình để ngăn triển khai khi hệ thống kích hoạt cảnh báo dựa trên thay đổi về số liệu. Chúng tôi sử dụng các số liệu một cách rộng rãi và có cảnh báo về tình trạng hệ thống, tình trạng các cụm, Vùng sẵn sàng và Khu vực, cũng như hầu hết mọi yếu tố khác. Chúng tôi cấu hình pipeline để dừng quá trình triển khai mã khi một số liệu quan trọng kích hoạt cảnh báo. Tuy nhiên, đôi khi một nhóm cần triển khai bản sửa lỗi thì mới khắc phục được cảnh báo của hệ thống. Trong tình huống này, chúng tôi để các nhóm kiểm soát cảnh báo nhằm ngăn thay đổi trong pipeline.

Pipeline của chúng tôi có thể chỉ định khoảng thời gian được phép tiến hành thay đổi trong pipeline. Các nhóm có thể tự chọn khoảng thời gian để hạn chế thời điểm áp dụng thay đổi cho khách hàng. Các nhóm AWS ưu tiên phát hành phần mềm khi có nhiều người có thể phản hồi nhanh chóng và giảm thiểu sự cố do việc triển khai gây ra. Để biến điều này thành hiện thực, các nhóm thường phải đặt khoảng thời gian sao cho chỉ tiến hành triển khai trong giờ làm việc. Các nhóm khác tại Amazon muốn phát hành phầm mềm khi lưu lượng truy cập của khách hàng ở mức thấp. Có thể kiểm soát các khoảng thời gian này nếu cần.

Chúng tôi cũng có thể dừng pipeline dựa trên nội dung của artifact bản dựng. Ví dụ: chúng tôi có thể chặn artifact bản dựng có chứa một gói lỗi đã xác định hoặc một tham chiếu Git cụ thể. Chúng tôi đã sử dụng tính năng này khi phát hiện ra rằng thay đổi về gói dữ liệu có chứa hồi quy hiệu suất. Nếu chỉ loại bỏ gói đó khỏi thư mục gói thì pipeline chứa gói bị lỗi từ trước vẫn sẽ triển khai thay đổi lỗi cho khách hàng.

Chúng tôi nhận thấy rằng các nhóm rất sẵn sàng tiếp nhận phương pháp tự động hóa. Chúng tôi đều háo hức xây dựng và phát hành tính năng cho khách hàng để nâng cao cuộc sống của họ, và quá trình phân phối liên tục góp phần duy trì điều đó. Chúng tôi từng chứng kiến tự động hóa đã giúp ích cho kỹ sư qua việc loại bỏ công việc gây chán nản, nhiều khả năng bị lỗi và tốn nhiều công sức. Chúng tôi đã chứng minh rằng phân phối liên tục có tác động tích cực đến chất lượng. Nhờ có tự động hóa, các nhóm có thể thường xuyên phát hành từng thay đổi để dễ dàng xác định các trường hợp hồi quy.

Khi các hệ thống còn mới, hầu hết mọi thành viên nhóm đều biết vùng bề mặt nào cần kiểm thử. Điều này giúp họ dễ dàng quản lý một số bước kiểm thử thủ công. Tuy nhiên, khi hệ thống trở nên phức tạp hơn và có thay đổi về thành viên nhóm, thì lợi ích của tự động hóa sẽ tăng lên. Chúng tôi thích tự động hóa hệ thống để có thể tập trung tăng thêm lợi ích cho khách hàng, thay vì quản lý thủ công quy trình đưa các thay đổi đó đến với khách hàng.

Suốt nhiều năm, Amazon đã liên tục chạy các chương trình cải tiến tập trung vào tốc độ phát hành phần mềm cho khách hàng và sự an toàn của các lần phát hành đó. Chúng tôi không bắt đầu với tất cả các bước kiểm tra rủi ro và kiểm thử mà tôi đã đề cập trong bài viết này. Theo thời gian, chúng tôi sẽ phát minh ra các cách để xác định và giảm thiểu rủi ro.

Các chương trình cải tiến liên tục đều do lãnh đạo doanh nghiệp tiến hành ở các cấp độ khác nhau của tổ chức. Điều này cho phép từng lãnh đạo doanh nghiệp điều chỉnh quy trình phát hành phần mềm của mình để khắc phục rủi ro và tác động đối với doanh nghiệp của mình. Một số chương trình cải tiến liên tục của chúng tôi còn được chạy trên các bộ phận lớn của Amazon, đồng thời cũng có trường hợp lãnh đạo của các tổ chức nhỏ hơn chạy chương trình của riêng họ. Chúng tôi biết rằng luôn có trường hợp ngoại lệ. Hệ thống của chúng tôi có cơ chế rút lui để không cản trở tiến độ của các nhóm cần rút lui tạm thời hoặc vĩnh viễn. Cuối cùng, các nhóm của chúng tôi sở hữu hành vi của phần mềm và chịu trách nhiệm đầu tư một cách phù hợp vào quy trình phát hành phần mềm.

Chúng tôi bắt đầu bằng cách đánh giá nơi xảy ra sự cố, khắc phục sự cố và thực hiện lại. Để duy trì công việc này, chúng tôi cần tăng dần tần suất và chúc mừng cải tiến theo thời gian. Khi Amazon bắt đầu sử dụng pipeline lần đầu tiên, nhiều nhóm không chắc phương thức triển khai liên tục sẽ có hiệu quả hay không. Để thôi thúc các nhóm bắt đầu, chúng tôi khuyến khích họ mã hóa quy trình phát hành hiện tại, các bước thủ công, v.v. trong pipeline. Đối với nhiều nhóm, pipeline của họ đóng vai trò một giao diện trực quan cho thấy quy trình phát hành, mà không tự động đưa các artifact bản dựng vào quy trình phát hành. Khi trở nên chắc chắn hơn, họ dần sử dụng tự động hóa ở các giai đoạn khác nhau của pipeline cho đến khi không cần kích hoạt thủ công bất kỳ bước nào trong pipeline nữa.

Tiến bước đến hôm nay. Hiện nay, các nhóm tại Amazon đều hướng đến tự động hóa hoàn toàn khi viết mã mới. Đối với chúng tôi, tự động hóa là cách duy nhất để công việc không ngừng phát triển bền vững.