Triển khải lên prod sau mỗi thay đổi có thể đáng sợ, nhưng không triển khai trực tiếp lên prod còn đáng sợ hơn.
Đây là quy trình tôi đã áp dụng tại Amazon, khi dẫn dắt một đội ngũ phục vụ hàng trăm triệu khách hàng. Thông qua công việc tư vấn, tôi đã giúp các đội kỹ thuật chuyển từ triển khai theo lịch phát hành hai tuần một lần sang ship ngay sau mỗi lần merge.
Hãy bắt đầu với điều hiển nhiên:
Bạn sẽ gây ra sự cố. Không phải là nếu, mà là khi nào.
Dù có bao nhiêu unit test, integration test, dogfooding, end-to-end hay bất cứ thứ gì, hay hy sinh cho các vị thần deploy, cũng không thể bắt hết mọi bug.
Việc kiểm thử cho tính năng của bạn được thực hiện một tuần trước không hề được kiểm thử cùng với những thay đổi mới nhất của đồng đội.
Kiểm thử của bạn được chạy dựa trên phiên bản pre-prod của dịch vụ đồng đội, nhưng giờ phiên bản đó đã thay đổi và chứa một thay đổi không tương thích ngược.
Càng chờ lâu, càng nhiều thay đổi chất lên một bản release. Nếu cần rollback, bạn sẽ phải rollback hai tuần thay đổi thay vì chỉ 1-2 giờ.
Nếu chấp nhận tiền đề rằng sự cố là điều không thể tránh khỏi, thì việc dành nguồn lực lớn để QA một bản release trở nên kém hợp lý hơn nhiều. Thay vào đó, chúng ta nên tập trung nguồn lực vào giám sát và theo dõi bản release, cũng như sẵn sàng xử lý sự cố khi nó xảy ra.
Giờ, chúng ta xem làm thế nào để đạt được điều đó:
Điều kiện tiên quyết:
CI/CD
Kiểm thử quan trọng ít hơn bạn nghĩ rất nhiều. Kiểm thử không thể chứng minh thay đổi của bạn an toàn trong production. Không gì có thể làm được điều đó. Điều kiểm thử làm là khiến việc thất bại trở nên rẻ. Một bug bị phát hiện ở CI chỉ tốn vài phút. Một bug phát hiện ở production sẽ tốn cả buổi tối của bạn để rollback.
Vì vậy, hãy chạy toàn bộ test suite sau mỗi lần merge, hoặc ít nhất là trong pipeline: unit, integration, end-to-end. Bug di chuyển càng xa trong pipeline, chi phí xử lý càng cao.
Giám sát / Observability
Điều cốt lõi là có thể phát hiện regression càng sớm càng tốt. Để làm được điều đó, bạn cần có hệ thống giám sát tuyệt vời. Nó bao gồm:
- metrics: lỗi, độ trễ, tính khả dụng
- logs kèm correlation id
- alarm cho sev-3 và sev-2 (paging) gắn với hai loại trên
Việc tinh chỉnh ngưỡng alarm vừa là nghệ thuật vừa là khoa học. Đó là sự cân bằng giữa độ nhạy và tốc độ phản ứng của bạn khi có sự cố thật. Thời gian mục tiêu để có cảnh báo sev-2 nên là 5-10 phút.
Ban đầu, rất có thể bạn sẽ sai và quá nhạy cảm. Không may, điều này chủ yếu học được qua thử và sai, nên bạn có thể sẽ bị đánh thức lúc 2 giờ sáng vài lần.
Feature Flags
Với bất kỳ thay đổi nào có rủi ro, bạn nên ship nó phía sau một feature flag / remote config. Feature flag cho phép bạn rollback và tắt bất kỳ thay đổi nào trong vài phút, thay vì phải rollback toàn bộ deployment. Thêm vào đó, nếu dịch vụ feature flag của bạn cho phép (và nó nên cho phép), bạn có thể triển khai dần tính năng theo phần trăm hoặc theo nhóm, giảm thêm tác động của một thay đổi xấu.
Điều này cho phép chúng ta tách rời việc triển khai mã và kích hoạt mã. Nghe có vẻ nhỏ nhặt, nhưng lại là yếu tố thay đổi cuộc chơi trong việc giảm rủi ro.
Lưu ý: bạn sẽ cần một quy trình để dọn dẹp chúng. Lý tưởng nhất là tạo một ticket gỡ bỏ cho mỗi flag được tạo. Nếu không, khi dịch vụ feature flag của bạn sập (chắc chắn sẽ sập), bạn sẽ gặp một regression nghiêm trọng. Đừng hỏi vì sao tôi biết.
Tự động Rollback (Circuit breaker lúc deploy)
Circuit breaker lúc deploy là chức năng cho phép bạn rollback deployment nếu bạn thấy một số lượng hoặc tỷ lệ lỗi khi đang triển khai ra toàn bộ hệ thống. Hầu hết các nhà cung cấp cloud hiện nay đều có tính năng này chỉ với một checkbox.
Các thay đổi tương thích ngược
Bạn lẽ ra đã phải làm điều này, nhưng triển khai sau mỗi commit sẽ buộc bạn thực hiện. Trong một rolling deployment, phiên bản cũ và phiên bản mới sẽ chạy cùng lúc. Mọi thay đổi cần hoạt động tương thích với phiên bản trước. Mẹo deploy lúc nửa đêm để tránh điều này của bạn không còn tác dụng nữa.
Các chiến lược triển khai
Giờ, với những thứ đó đã sẵn sàng, chúng ta có thể điểm qua một vài chiến lược triển khai khác nhau giúp giảm rủi ro khi bạn triển khai thay đổi của mình.
One box (canary)
Triển khai one box sẽ đưa thay đổi của bạn lên một box trong toàn bộ fleet. Điều này giúp giới hạn tác động của mọi thay đổi xấu chỉ trong một host.
Bạn deploy và để nó chạy trong một khoảng thời gian, nhận một phần nhỏ trong tổng lưu lượng truy cập. Bạn cấu hình monitoring và alerting trên box này để cảnh báo nếu có bất cứ thứ gì hỏng.
Triển khai Rolling
Triển khai rolling cho phép bạn rollout theo phần trăm theo thời gian, để nếu có lỗi nghiêm trọng, bạn sẽ phát hiện trước khi nó ảnh hưởng đến tất cả máy và có thể bắt đầu rollback chúng.
Triển khai theo khu vực
Khi công ty phát triển, bạn sẽ có các deployment đa khu vực. Thay vì triển khai đồng thời lên tất cả các khu vực, bạn có thể deploy vào một khu vực cụ thể trước (thường là khu vực có lưu lượng thấp nhất).
Các trường hợp không áp dụng
App store
Phát hành ứng dụng di động không hoàn toàn phù hợp với hướng dẫn này. Hàng đợi duyệt của app store sẽ làm chậm nhịp triển khai và đòi hỏi một chiến lược khác.
Môi trường có chứng nhận
Thiết bị y tế, điện tử hàng không, điều khiển công nghiệp, v.v. Bạn không thể triển khai liên tục nếu cần cơ quan quản lý chứng nhận bản build.
On-prem / Tự lưu trữ
Bạn không kiểm soát được việc nâng cấp. Bạn vẫn có thể triển khai liên tục trên mọi thứ bạn vận hành, tuy nhiên bạn vẫn phải đánh phiên bản cho từng thay đổi và khách hàng của bạn quyết định khi nào nó được áp dụng.
Bắt đầu từ đâu
Đừng làm tất cả cùng một lúc. Thứ tự rất quan trọng:
- Làm cho CI xanh và nhanh. Lý tưởng là dưới 15 phút
- Thiết lập metrics và alarm cho tỷ lệ lỗi, độ trễ và tính khả dụng. Đây là phần quan trọng nhất của việc này
- Đặt mọi thay đổi rủi ro phía sau một flag
- Thêm one-box + rollback tự động
- Xóa lịch phát hành
- Tìm việc để làm với toàn bộ thời gian rảnh mới của bạn vì giờ bạn không còn phải lên lịch phát hành
Hầu hết các đội tôi từng làm việc cùng mất khoảng một quý để hoàn thành việc này. Phần công cụ (tooling) là dễ. Phần khó là quy trình tổ chức và phá vỡ ảo tưởng rằng việc lên lịch phát hành là an toàn.
Nếu đội của bạn đang dùng lịch phát hành và muốn thoát khỏi nó, đó chính là việc tôi làm. Nhắn tin riêng cho tôi (DM) nhé.
