Khả năng phục hồi của đám mây ở quy mô lớn: Khuôn khổ cho sự tăng trưởng bền bỉ

88% người mua đám mây đã triển khai môi trường đám mây lai (IDC), điều đó có nghĩa là kỷ nguyên di chuyển đang kết thúc và kỷ nguyên hoạt động đã đến. Hầu hết các nhóm đều coi khả năng phục hồi là điều họ đạt được trong ngày go-live, sau đó kế thừa vĩnh viễn. Giả định đó không thành công ngay khi môi trường của bạn tăng gấp đôi độ phức tạp và lỗi xếp tầng xảy ra sau đó sẽ làm lộ ra mọi khoảng trống chưa được xác thực cùng một lúc. Bài viết này cung cấp khuôn khổ dành cho người thực hành để liên tục xây dựng, thử nghiệm và vận hành khả năng phục hồi của đám mây trên các môi trường kết hợp và nhiều đám mây, với các mẫu cụ thể dành cho SRE và các nhóm cơ sở hạ tầng cần câu trả lời chứ không phải trừu tượng.

Khả năng phục hồi của đám mây trên quy mô lớn là khả năng có thể đo lường được của môi trường kết hợp hoặc nhiều đám mây trong việc khắc phục lỗi, khôi phục trong các mục tiêu RTO/RPO đã xác định và duy trì khả năng đó khi khối lượng công việc và độ phức tạp của cơ sở hạ tầng tăng lên. Điều này quan trọng vì khả năng phục hồi theo thời gian thiết kế và khả năng phục hồi trong thời gian chạy không giống nhau và khoảng cách giữa chúng là nguyên nhân dẫn đến hầu hết các sự cố ngừng sản xuất.

Khả năng phục hồi của đám mây trên quy mô lớn có nghĩa là cơ sở hạ tầng của bạn có thể phục hồi theo dự đoán, với tính năng khôi phục tự động ở bất cứ nơi nào thích hợp, cho dù bạn đang chạy 10 dịch vụ hay hàng nghìn dịch vụ. Xác thực khả năng đó liên tục, nếu không nó sẽ âm thầm suy giảm khi môi trường của bạn phát triển.

• Xem lại phạm vi bảo hiểm DR trước khi mở rộng khối lượng công việc của bạn; ánh xạ các dịch vụ sản xuất tới các đường dẫn chuyển đổi dự phòng đã được xác thực, các mục tiêu RTO/RPO và xóa quyền sở hữu khôi phục trước khi tăng quy mô.
• Phân chia khối lượng công việc theo miền lỗi để giảm bán kính vụ nổ; thiết kế xung quanh các khu vực, khu vực, khu vực phụ thuộc và các dịch vụ quan trọng trong kinh doanh để các lỗi cục bộ ít có khả năng xảy ra hơn.
• Ưu tiên tự động hóa cho các hành động phục hồi tần suất cao; bắt đầu với các phản hồi sự cố mà nhóm của bạn thực hiện thường xuyên nhất để giảm độ trễ thủ công và cải thiện MTTR so với các mục tiêu SLO.
• Sử dụng thử nghiệm liên tục để ngăn chặn sự trôi dạt khả năng phục hồi; chạy thử nghiệm DR tự động cho khối lượng công việc quan trọng và lên lịch thử nghiệm hỗn loạn dựa trên mức độ quan trọng của dịch vụ, lưu lượng truy cập và rủi ro bán kính vụ nổ.
• Tăng cường quản trị trước khi mở rộng quy mô ra đa vùng; đánh giá mức độ trưởng thành của SRE, DR, khả năng quan sát, tự động hóa và quản trị đám mây nội bộ trước khi thêm mức độ phức tạp trong hoạt động.

Di cư là một dự án. Khả năng phục hồi là một thực hành. Các lộ trình tài trợ cho bên này và cấp vốn cho bên kia luôn tạo ra kết quả giống nhau: môi trường đám mây được thiết kế để tải Ngày 1 chứ không phải tải Ngày 300.

Theo IDC, việc chuyển sang đám mây lai có nghĩa là thách thức hiện tại không còn chỉ là đưa khối lượng công việc lên đám mây nữa. Nó đang duy trì một môi trường nhiều đám mây rộng lớn và đáng tin cậy khi nó phát triển. Các nhóm bỏ qua quá trình trưởng thành về mặt vận hành có cấu trúc sẽ phát hiện ra chi phí của việc trang bị thêm các hợp chất phục hồi hàng tuần.

Hai vấn đề về cấu trúc đẩy nhanh mô hình thất bại này. Khoảng cách về nhân tài và mô hình vận hành vẫn là một hạn chế khi môi trường hiện đại hóa; Theo Kyndryl, các nhà lãnh đạo doanh nghiệp cho rằng quản lý nhân tài và tích hợp công nghệ mới vào cơ sở hạ tầng hiện có là những lĩnh vực chính mà họ cần trợ giúp. Việc khôi phục sau thảm họa trở nên khó khăn hơn khi các mục tiêu khôi phục, kiến ​​trúc, bản sao, sai lệch cấu hình và tự động hóa không được thiết kế cùng nhau ngay từ đầu.

Nợ phục hồi không phải là lý thuyết. Mỗi đường dẫn chuyển đổi dự phòng không được xác thực là một trách nhiệm đang chờ sự cố sản xuất xảy ra. Các nhóm coi khả năng phục hồi là kết quả di chuyển có thể thực hiện được, thay vì kỷ luật vận hành, sẽ trả trách nhiệm đó cùng với lãi suất.

Khả năng phục hồi của cơ sở hạ tầng đám mây có thể mở rộng dựa trên ba lớp phụ thuộc lẫn nhau: kiến ​​trúc, tự động hóa và thử nghiệm liên tục. Loại bỏ bất kỳ một lớp nào và hai lớp còn lại sẽ trở thành rạp hát.

Kiến trúc: thiết kế để thất bại, không chống lại nó

Quyết định thiết kế đầu tiên là cách ly bán kính vụ nổ. Phân đoạn khối lượng công việc theo miền lỗi để một lần ngừng hoạt động của một vùng khả dụng, một nhóm bảo mật bị định cấu hình sai hoặc một sự kiện hàng xóm ồn ào không thể xảy ra trên toàn bộ khu vực của bạn. Đối với những khối lượng công việc ảnh hưởng đến doanh thu quan trọng nhất, kiến ​​trúc tích cực-hoạt động đa vùng có thể phù hợp; đối với nhiều người khác, các kiểu chủ động/thụ động, đèn hoa tiêu hoặc chế độ chờ ấm có thể đáp ứng các mục tiêu RTO/RPO với chi phí và độ phức tạp thấp hơn.

Sự dư thừa ở lớp mạng, bao gồm các đường dẫn đầu ra dự phòng, cân bằng tải giữa các khu vực và chuyển đổi dự phòng DNS nhận biết địa lý, giúp giảm các điểm lỗi đơn lẻ trước khi chúng gây ra sự cố.

Tự động hóa: biến việc khôi phục thành một sự kiện không thể xảy ra

Việc khôi phục thủ công khiến các mục tiêu RTO nhất quán khó đạt được hơn. Các hành động khôi phục yêu cầu kỹ sư đọc sổ quản lý và thực thi lệnh theo cách thủ công có thể làm tăng thêm độ trễ và tính biến đổi cho dòng thời gian sự cố. Tự động hóa thông qua các công cụ Cơ sở hạ tầng dưới dạng Mã như Terraform và Ansible, kết hợp với quy trình tự phục hồi, có thể giảm thời gian khôi phục và khiến các bước khôi phục có thể lặp lại nhiều hơn.

Quy trình triển khai dựa trên GitOps thực thi tính nhất quán của cấu hình trên các môi trường. Điều này giúp loại bỏ hiện tượng lệch cấu hình âm thầm làm suy giảm khả năng phục hồi giữa các bản phát hành. Chính sách chuyển đổi dự phòng tự động được kích hoạt bởi ngưỡng kiểm tra tình trạng có thể giảm đáng kể thời gian phục hồi so với can thiệp thủ công.

Kiểm tra liên tục: đo lường những gì bạn tuyên bố có

Kiến trúc và tự động hóa chỉ chứng minh được giá trị của chúng trong điều kiện thử nghiệm. Nhịp độ kỹ thuật hỗn loạn có cấu trúc, bắt đầu trong môi trường tương đương với sản xuất và mở rộng cẩn thận sang sản xuất khi thích hợp, giúp chuyển đổi khả năng phục hồi giả định thành khả năng phục hồi đo lường được. Bảng thông tin SLO hiển thị tỷ lệ chi tiêu ngân sách do lỗi giúp cảnh báo sớm cho các nhóm SRE trước khi tình trạng xuống cấp chậm dẫn đến ngừng hoạt động.

Kiểm tra DR liên tục không phải là một bài tập tuân thủ. Chính vòng phản hồi giúp giữ cho kiến ​​trúc khả năng phục hồi của bạn luôn trung thực khi môi trường phát triển.

Nhiều đội vẫn tổ chức các cuộc diễn tập DR không thường xuyên, thường là hàng năm hoặc chỉ để tuân thủ. Các cuộc diễn tập không thường xuyên thường để lại những khoảng trống phục hồi chưa được phát hiện cho đến lần thử nghiệm tiếp theo hoặc sự cố sản xuất. Các nhóm chạy thử nghiệm DR tự động hàng tháng phát hiện lỗi lệch cấu hình, thông tin xác thực hết hạn và liên kết sao chép bị hỏng trước khi chúng xuất hiện trong báo cáo sự cố sản xuất.

Cơ chế rất đơn giản. Xác định ma trận kiểm tra DR ánh xạ từng khối lượng công việc quan trọng tới các mục tiêu RTO/RPO của nó. Tự động hóa trình tự chuyển đổi dự phòng bằng các công cụ tự động hóa runbook. Thiết bị thử nghiệm với các tác nhân có thể quan sát để đo thời gian phục hồi thực tế so với mục tiêu. Ghi lại đồng bằng. Khắc phục. Lặp lại.

Các cuộc diễn tập DR thường xuyên giúp các nhóm xác định tình trạng sai lệch cấu hình, thông tin xác thực đã hết hạn, sự cố sao chép và lỗ hổng trong sổ chạy trước khi chúng ảnh hưởng đến hoạt động sản xuất. Mỗi chu kỳ thử nghiệm sẽ thu hẹp khoảng cách giữa RTO được thiết kế và RTO thực tế.

Kỹ thuật tiêm lỗi và hỗn loạn

Kỹ thuật hỗn loạn, cố tình đưa các lỗi được kiểm soát vào các môi trường tương đương với sản xuất và các hệ thống sản xuất được lựa chọn cẩn thận, sẽ đẩy nhanh vòng phản hồi phục hồi. Mục đích không phải là gây ra sự gián đoạn. Mục tiêu là tìm ra những điểm dừng trước khi khách hàng của bạn làm.

Một chương trình hỗn loạn có cấu trúc tốt tuân theo bốn bước:

1. Thiết lập đường cơ sở ở trạng thái ổn định bằng cách sử dụng số liệu SLO của bạn.

2. Đưa vào một lỗi cụ thể: phân vùng mạng, trục xuất nhóm, lỗi nút cơ sở dữ liệu hoặc suy thoái vùng đám mây.

3. Đo độ lệch so với trạng thái ổn định.

4. Khắc phục lỗ hổng và kiểm tra lại để xác nhận việc khắc phục.

Các công cụ như LitmusChaos cho môi trường Kubernetes và Trình mô phỏng tiêm lỗi AWS cung cấp bán kính nổ được kiểm soát cần thiết để chạy các thử nghiệm này một cách an toàn trong sản xuất.

Bảng sau đây trình bày mô hình minh họa để so sánh các phương pháp thử nghiệm khả năng phục hồi phổ biến. Phạm vi cải thiện là ước tính định hướng, không phải điểm chuẩn được đảm bảo. Kết quả thực tế phụ thuộc vào kiến ​​trúc khối lượng công việc, mức độ hoàn thiện tự động hóa, phạm vi bao phủ DR, chất lượng quan sát, lịch sử sự cố và mô hình vận hành của nhóm.

CloudOps được quản lý và các hoạt động do SRE dẫn dắt chuyển đổi khả năng phục hồi từ một tập hợp các quyết định kiến trúc thành một hệ thống vận hành có thể lặp lại. Đây là nơi khả năng phục hồi sau di chuyển của đám mây được duy trì: không chỉ trong các tài liệu thiết kế mà còn trong hoạt động thực tiễn hàng ngày của nhóm vận hành môi trường.

Mô hình SRE giới thiệu ba nguyên tắc hoạt động giúp khả năng phục hồi tự duy trì.

Quản lý ngân sách lỗi cung cấp cho các nhóm một cách định lượng để cân bằng rủi ro về độ tin cậy với tốc độ phân phối. Khi lượng lỗi ở mức ổn định, các nhóm có thể tiếp tục cung cấp tính năng trong khi giám sát rủi ro về độ tin cậy. Khi ngân sách tiêu tốn quá nhanh, các nhóm nên ưu tiên công việc đảm bảo độ tin cậy cho đến khi rủi ro quay trở lại ngưỡng đã thỏa thuận. Điều này tạo ra một cơ chế dựa trên dữ liệu để cân bằng tốc độ phân phối với sự ổn định trong vận hành.

Giảm bớt công việc vất vả sẽ loại bỏ công việc thủ công lặp đi lặp lại khỏi vòng lặp vận hành. Các hành động khôi phục thủ công, phản hồi cảnh báo được kích hoạt bằng tay và triển khai nhấp qua tạo ra công việc vất vả thường phát triển theo quy mô cơ sở hạ tầng. Công việc tự động hóa giúp năng lực của SRE tập trung vào việc cải thiện khả năng phục hồi chứ không phải vào việc chữa cháy khi có sự cố.

Việc học sau sự cố sẽ khép lại vòng lặp. Những quá trình hồi cứu không đáng trách tạo ra những thay đổi về kiến ​​trúc hoặc tự động hóa cụ thể là cơ chế mà mỗi sự cố giúp hệ thống trở nên linh hoạt hơn trước.

Khám phá các dịch vụ đổi mới dữ liệu và AI của Uptech để tăng tốc khả năng quan sát và tự động hóa làm nền tảng cho mô hình SRE này.

Bốn mô hình thất bại xuất hiện lặp đi lặp lại trong các môi trường mở rộng quy mô mà không có cơ chế quản lý khả năng phục hồi có cấu trúc.

Sự tích lũy nợ về khả năng phục hồi xảy ra khi các nhóm thêm dịch vụ mà không mở rộng ma trận phạm vi DR của họ. Kiểm tra sau di chuyển thường phát hiện khối lượng công việc sản xuất không có đường dẫn chuyển đổi dự phòng được xác thực. Bản sửa lỗi là kiểm tra khối lượng công việc hàng quý nhằm khởi chạy dịch vụ mới khi đăng ký DR.

Khoảng trống về khả năng quan sát xuất hiện khi số liệu tồn tại nhưng không được kết nối với các cảnh báo có thể thực hiện được. Các nhóm SRE phát hiện ra sự xuống cấp từ báo cáo của khách hàng thay vì bảng thông tin. Chỉ riêng thiết bị đo đạc là không đủ; định tuyến cảnh báo phải được gắn với sổ sách cụ thể.

Sự không phù hợp về nhân sự ở quy mô là một hạn chế về mặt cơ cấu, không phải là tình trạng thiếu hụt tạm thời. Khoảng cách về nhân lực và độ phức tạp của quá trình tích hợp có thể làm chậm quá trình ứng phó sự cố khi môi trường kết hợp và nhiều đám mây phát triển, đặc biệt khi các nhóm dựa vào nhân sự phản ứng thay vì tự động hóa, sổ sách và sự trưởng thành của mô hình vận hành. Sách hướng dẫn được ghi lại và tự động hóa giúp giảm ngưỡng kiến ​​thức chuyên môn cho các hành động phản hồi đầu tiên là biện pháp giảm nhẹ.

Lỗi kiến trúc DR thường phát sinh khi sao lưu, sao chép, định tuyến, khôi phục phụ thuộc và tự động hóa runbook được bật sau khi kiến trúc dịch vụ đã được đưa vào sản xuất. Hậu quả là các chuỗi phục hồi dễ vỡ sẽ thất bại trong điều kiện sự cố thực tế. DR phải được thiết kế trong kiến ​​trúc dịch vụ ngay từ đầu.

Đối với lớp tài chính bổ sung cho khả năng phục hồi của cơ sở hạ tầng, hãy đọc hướng dẫn của chúng tôi về quản lý chi phí đám mây khi khối lượng công việc AI mở rộng.

Uptech, một công ty công nghệ phần mềm B2B, AI, đám mây và dịch vụ DevOps, hỗ trợ khả năng phục hồi của đám mây thông qua CloudOps được quản lý, tự động hóa DevOps, khả năng quan sát, ứng phó sự cố và các biện pháp vận hành do SRE dẫn đầu. Cam kết về khả năng phục hồi có thể bắt đầu bằng đường cơ sở trưởng thành: đánh giá có cấu trúc về mức độ bao phủ DR, thiết bị đo có khả năng quan sát, độ sâu tự động hóa, công việc vận hành vất vả và mức độ sẵn sàng ứng phó sự cố. Từ cơ sở đó, nhóm xây dựng một lộ trình ưu tiên nhằm giải quyết các lỗ hổng kiến ​​trúc trước tiên, sau đó là các lớp trong nhịp độ tự động hóa và thử nghiệm liên tục. Phương pháp này có thể được áp dụng trên các môi trường AWS, Azure, GCP và Kubernetes, sử dụng Cơ sở hạ tầng làm Mã, tự động hóa, khả năng quan sát và thực tiễn vận hành DevOps.

Uptech đã công bố các kết quả trên đám mây bao gồm chu kỳ triển khai nhanh hơn 63% sau khi chuyển khối lượng công việc cũ sang mô hình phân phối CI/CD gốc trên nền tảng đám mây và giảm 40% chi tiêu trên đám mây trong vòng ba tháng thông qua việc cấp quyền cho khối lượng công việc và quản trị FinOps. Khả năng vận hành và đám mây được quản lý của Uptech bao gồm quản lý, giám sát và quan sát cơ sở hạ tầng đám mây, sao lưu và khắc phục thảm họa, quản lý sự cố, tự động hóa sổ chạy và hỗ trợ khả năng phục hồi đa khu vực. Những kết quả này phản ánh giá trị của việc coi khả năng phục hồi như một phương pháp hoạt động liên tục chứ không phải là điểm kiểm tra di chuyển một lần.

Khả năng phục hồi của đám mây ở quy mô lớn không phải là trạng thái bạn đạt được. Đó là một thực hành bạn duy trì. Các nhóm duy trì nó coi khả năng phục hồi như một kỷ luật vận hành chứ không phải là một dự án có thể thực hiện được. Họ kiểm tra liên tục, tự động phục hồi, giảm bớt công sức và thu hẹp khoảng cách một cách có hệ thống sau mỗi lần hồi cứu sự cố.

Nếu môi trường của bạn đã vượt quá kiến trúc di chuyển ban đầu và phạm vi bao phủ DR không theo kịp, khoảng cách rủi ro có thể đã tăng lên. Bắt đầu với việc kiểm tra phạm vi bảo hiểm DR trong quý này. Ánh xạ mọi khối lượng công việc sản xuất theo mục tiêu RTO/RPO của nó, xác định khối lượng công việc không có đường dẫn chuyển đổi dự phòng được xác thực và tự động hóa năm hành động khôi phục đầu tiên mà nhóm của bạn hiện đang thực hiện theo cách thủ công. Đó là điểm khởi đầu có thể đo lường được và có thể đạt được.