9.6 Kỹ thuật hỗn loạn và kiểm thử khả năng phục hồi

Tổng quan và động lực

Kỹ thuật hỗn loạn là thực hành có kỷ luật chạy các thí nghiệm trên một hệ thống để xây dựng sự tự tin vào khả năng chịu được điều kiện hỗn loạn trong môi trường sản xuất của nó. Cái tên nghe liều lĩnh, và đó là điều đầu tiên cần gỡ bỏ. Kỹ thuật hỗn loạn không phải là làm hỏng mọi thứ ngẫu nhiên và hy vọng học được gì đó. Nó ngược lại: một phương pháp có kiểm soát, dựa trên giả thuyết để tiêm các thất bại thực tế nhằm bạn phát hiện điểm yếu trước khi người dùng của bạn phát hiện. Bạn đã biết hệ thống của mình sẽ đối mặt thất bại, vì mọi hệ thống thật đều vậy. Câu hỏi duy nhất là bạn gặp những thất bại đó vào một chiều thứ Ba với bản hoàn tác sẵn sàng, hay lúc 3 giờ sáng vào giờ bận nhất mà không biết chuyện gì đang xảy ra.

Với các đội lớn, điều này quan trọng vì độ phức tạp đã vượt quá khả năng suy luận của bất kỳ ai bằng cách kiểm tra. Một dịch vụ hiện đại là mạng lưới hàng chục hay hàng trăm thành phần, mỗi cái có thời gian chờ, lần thử lại, bộ nhớ đệm và kiểu thất bại riêng, và các tương tác giữa chúng tạo ra hành vi nổi lên mà không sơ đồ kiến trúc nào dự đoán. Bạn có thể rà soát mã, vẽ các hộp, và vẫn bị bất ngờ khi một phụ thuộc chậm kích hoạt cơn bão thử lại làm sập một dịch vụ cách ba bước. Kỹ thuật hỗn loạn là cách bạn thăm dò những tương tác đó bằng thực nghiệm, để khả năng phục hồi của bạn là thứ bạn đã xác minh thay vì thứ bạn giả định.

Bối cảnh doanh nghiệp và chính phủ nâng rủi ro và, ngày càng, cả nhiệm vụ. Cơ quan quản lý tài chính nay kỳ vọng các công ty kiểm thử khả năng phục hồi vận hành theo các kịch bản nghiêm trọng-nhưng-có-thể-xảy-ra và chứng minh họ giữ được dịch vụ trọng yếu chạy qua gián đoạn. Các cơ quan chính phủ chạy bài tập liên tục hoạt động để dịch vụ công thiết yếu sống sót qua ngừng hoạt động, thiên tai và tấn công mạng. Trong cả hai thế giới, “chúng tôi nghĩ nó sẽ chịu được” không phải câu trả lời chấp nhận được cho kiểm toán viên hay công dân. Kỹ thuật hỗn loạn cho bạn bằng chứng. Chương này xây trên kỹ thuật độ tin cậy hệ thống (chương 9.1) và các mẫu khả năng phục hồi trong chương 3.5, và nó nối chặt với quản lý sự cố (chương 9.3) và khôi phục thảm họa (chương 9.5).

Các nguyên tắc chính

Xây sự tự tin, đừng tạo hỗn loạn. Mục tiêu là khả năng phục hồi được xác minh, không phải cảnh tượng. Mỗi thí nghiệm trả lời một câu hỏi cụ thể về hệ thống hành xử thế nào dưới áp lực.
Xác định trạng thái ổn định trước. Bạn không phát hiện được vấn đề nếu thiếu định nghĩa rõ ràng, đo được về “khỏe mạnh” trông thế nào.
Hình thành giả thuyết. Nêu điều bạn kỳ vọng xảy ra trước khi tiêm một lỗi. Một bất ngờ là phát hiện; sự vắng mặt của nó cũng là phát hiện.
Tối thiểu hóa và chứa bán kính ảnh hưởng. Bắt đầu nhỏ, bảo vệ người dùng thật, và chỉ mở rộng phạm vi khi sự tự tin lớn lên.
Ưu tiên môi trường sản xuất, cẩn thận. Thất bại hành xử khác dưới lưu lượng thật, dữ liệu thật và quy mô thật. Hãy giành quyền kiểm thử ở đó.
Tự động hóa hướng tới xác minh liên tục. Một điểm yếu bạn sửa một lần có thể hồi quy. Khả năng phục hồi được kiểm thử liên tục giữ đúng.
Thất bại là người thầy, không phải phán quyết. Phát hiện cải thiện hệ thống; chúng không bao giờ là lý do đổ lỗi cho người chạy thí nghiệm.

Khuyến nghị

Thiết lập điều kiện tiên quyết trước khi tiêm một lỗi nào

Kỹ thuật hỗn loạn là bội số lực cho một hệ thống trưởng thành và là gánh nặng cho một hệ thống chưa trưởng thành. Trước khi bắt đầu, bạn cần ba thứ tại chỗ. Thứ nhất, khả năng quan sát, nghĩa là chỉ số, nhật ký và vết cho phép bạn thấy hệ thống đang làm gì từ bên ngoài, vì một thí nghiệm bạn không quan sát được không dạy bạn gì. Thứ hai, mục tiêu mức dịch vụ hoặc định nghĩa tương đương về sức khỏe trạng thái ổn định (chương 9.1), để bạn phân biệt thí nghiệm thành công với có hại trong thời gian thực. Thứ ba, một đường hoàn tác hoặc hủy nhanh, đáng tin, để ngay khi một thí nghiệm đe dọa người dùng thật bạn có thể dừng nó và khôi phục dịch vụ bình thường trong vài giây. Nếu bạn không đo được hệ thống, xác định trạng thái khỏe của nó, và kéo nó trở lại từ bờ vực, đừng chạy thí nghiệm hỗn loạn vội. Hãy xây những năng lực đó trước. Chúng tự trả giá bất kể.

Xác định trạng thái ổn định và hình thành giả thuyết thật

Mọi thí nghiệm bắt đầu bằng việc viết ra “bình thường” trông thế nào theo thuật ngữ đo được: tỷ lệ yêu cầu thành công trên 99,9 phần trăm, độ trễ thanh toán dưới 400 mili giây ở phân vị 95, độ sâu hàng đợi dưới một ngưỡng. Đây là định nghĩa trạng thái ổn định của bạn, và nó nên phản ánh sức khỏe người dùng nhìn thấy, không phải hệ thống ống dẫn nội bộ. Rồi nêu một giả thuyết bằng ngôn ngữ đơn giản: “Nếu chúng ta thêm 300 mili giây độ trễ vào dịch vụ đề xuất, trang sản phẩm vẫn hiển thị trong ngân sách độ trễ vì trang coi đề xuất là tùy chọn và hết thời gian chờ sau 200 mili giây.” Giờ bạn có một tuyên bố bác bỏ được. Khi chạy thí nghiệm, một trong hai điều tốt xảy ra. Hoặc hệ thống hành xử như dự đoán và sự tự tin của bạn được giành, hoặc không và bạn đã tìm thấy một điểm yếu thật rẻ, theo điều kiện của bạn, với kỹ sư quan sát.

Tiêm lỗi thực tế, không tùy ý

Các lỗi bạn đưa vào nên phản chiếu các thất bại hệ thống của bạn thực sự trải qua. Tiêm lỗi, việc cố ý đưa lỗi vào để kiểm thử hệ thống phản ứng thế nào, cho bạn một thực đơn rút từ sự cố sản xuất thật. Tiêm độ trễ để mô phỏng phụ thuộc chậm hay đường mạng bão hòa. Tiêm lỗi, trả HTTP 500 hay từ chối kết nối, để mô phỏng dịch vụ hạ nguồn đang hỏng. Tiêm cạn kiệt tài nguyên bằng cách tiêu CPU, bộ nhớ, đĩa hay bộ mô tả tệp, để xem hệ thống suy giảm dưới áp lực thế nào. Tiêm thất bại phụ thuộc bằng cách làm cả cơ sở dữ liệu, bộ nhớ đệm, hàng đợi hay API bên thứ ba không với tới được. Trong một hệ phân tán, nơi các thành phần chạy trên máy riêng và giao tiếp qua mạng không đáng tin, đây là những thất bại chi phối các lần ngừng hoạt động thật. Độ trễ và thất bại một phần, không phải sập sạch, là thứ làm hỏng mọi thứ trong thực tế, nên hãy thiên các thí nghiệm của bạn về vùng giữa lộn xộn.

Xác minh các cơ chế phục hồi của bạn thực sự hoạt động

Đây là nơi kỹ thuật hỗn loạn xứng đáng chỗ đứng. Hệ thống của bạn đầy những cơ chế được cho là bảo vệ bạn: thời gian chờ ngăn bên gọi chờ vô tận, lần thử lại che những trục trặc tạm thời, bộ ngắt mạch ngừng đập vào phụ thuộc đang hỏng, và chuyển dự phòng chuyển sang dự phòng khi bản chính chết. Các mẫu này, bao quát trong chương 3.5, là sự khác biệt giữa vấn đề được chứa và ngừng hoạt động dây chuyền. Rắc rối là chúng hiếm khi được kiểm thử dưới những điều kiện chúng tồn tại để đối phó. Một thời gian chờ đặt 30 giây khi hạn của bên gọi là 2 giây không làm gì. Một lần thử lại không lùi biến một dịch vụ đang vật lộn thành bầy đàn xô đẩy. Một bộ ngắt mạch chưa bao giờ được thực hành có thể bị cấu hình sai và không bao giờ kích hoạt, hoặc kích hoạt liên tục. Thí nghiệm hỗn loạn là cách bạn xác nhận mỗi cái hành xử như thiết kế khi lỗi nó canh giữ thực sự đến. Hãy giả định mọi cơ chế an toàn chưa kiểm thử là hỏng cho đến khi một thí nghiệm chứng minh ngược lại.

Bắt đầu với ngày diễn tập trước khi tự động hóa

Đừng bắt đầu bằng nền tảng tự động tiêm lỗi liên tục. Hãy bắt đầu bằng một ngày diễn tập: một bài tập thực hành, lên lịch nơi một đội tụ họp, chọn kịch bản, tiêm một lỗi trong môi trường có kiểm soát, và cùng quan sát. Trước cả điều đó, một bài tập bàn giấy, nơi bạn nói qua một kịch bản trên bảng trắng mà không chạm vào hệ thống, làm lộ khoảng trống trong sổ tay vận hành, cảnh báo và quyền sở hữu với rủi ro gần bằng không. Ngày diễn tập là đường lên của bạn. Chúng xây cơ bắp hình thành giả thuyết, chứa bán kính ảnh hưởng và đọc hệ thống dưới áp lực, và chúng xây lòng tin với lãnh đạo và các đội lân cận mà bạn sẽ cần trước khi ai cho bạn chạy thí nghiệm trong môi trường sản xuất. Chúng cũng củng cố trực tiếp ứng phó sự cố, vì kỹ năng là những kỹ năng kỹ sư trực của bạn dùng trong sự cố thật (chương 9.3). Hãy chạy các ngày diễn tập đầu tiên trong staging, rồi trong môi trường sản xuất vào giờ vắng với bán kính ảnh hưởng nhỏ, rồi mở rộng.

Chứa bán kính ảnh hưởng có chủ đích

Thực hành an toàn quan trọng nhất đơn lẻ là giới hạn tác hại tiềm tàng của mọi thí nghiệm. Bắt đầu với phạm vi nhỏ nhất có thể dạy bạn điều gì đó: một thể hiện, một phần trăm lưu lượng, một phụ thuộc không trọng yếu, một vùng sẵn sàng. Xác định điều kiện hủy trước khi bắt đầu, nối chúng với chỉ số trạng thái ổn định, và làm việc dừng thí nghiệm thành một hành động duy nhất mà bất kỳ ai quan sát cũng kích hoạt được. Ưu tiên chạy trong giờ làm việc khi đội tỉnh táo và có nhân sự, không phải qua đêm khi một bất ngờ thành sự cố không ai theo dõi. Chỉ mở rộng bán kính ảnh hưởng khi các thí nghiệm nhỏ hơn đã chạy sạch và sự tự tin của bạn thực sự cao hơn. Kỷ luật chứa là thứ phân biệt kỹ thuật hỗn loạn với một lần ngừng hoạt động bạn tự gây ra.

Phát triển hướng tới xác minh khả năng phục hồi liên tục, tự động

Ngày diễn tập thỉnh thoảng tìm điểm yếu, nhưng hệ thống thay đổi mỗi ngày, và một bản sửa từ quý trước có thể lặng lẽ hồi quy. Trạng thái cuối trưởng thành là xác minh liên tục: một tập thí nghiệm khả năng phục hồi được chọn lọc chạy tự động, trong một đường ống hoặc theo lịch, để hồi quy trong thời gian chờ, chính sách thử lại hay đường chuyển dự phòng bị bắt trong vài ngày thay vì trong lần ngừng hoạt động thật kế tiếp. Đây là nơi các công cụ như Chaos Monkey của Netflix, ngẫu nhiên chấm dứt các thể hiện trong môi trường sản xuất để buộc kỹ sư xây dịch vụ chịu được mất thể hiện, giành được tiếng tăm. Chỉ tự động hóa các thí nghiệm bạn đã hiểu và tin từ các lần chạy thủ công. Hỗn loạn liên tục trên hệ thống chưa trưởng thành là cách tạo sự cố, không phải sự tự tin.

Nối thí nghiệm với khôi phục thảm họa và học từ sự cố

Kỹ thuật hỗn loạn không sống một mình. Các kịch bản lớn hơn, hiếm hơn, mất cả một khu vực, chuyển dự phòng cơ sở dữ liệu, khôi phục từ bản sao lưu, thuộc về kiểm thử khôi phục thảm họa (chương 9.5), và một ngày diễn tập thường là phương tiện tốt nhất để thực hành các kế hoạch đó thay vì để chúng mục rữa như tài liệu chưa kiểm thử. Mặt khác, mọi thí nghiệm làm lộ điểm yếu nên nuôi cùng vòng học như một sự cố thật (chương 9.3): một bản ghi không đổ lỗi, một bản sửa được theo dõi, và một thí nghiệm theo dõi để xác nhận bản sửa vẫn giữ. Khi phát hiện hỗn loạn, buổi diễn tập khôi phục thảm họa và rút kinh nghiệm sự cố đều chảy vào một tồn đọng công việc khả năng phục hồi, bạn nhận lợi tức cộng dồn thay vì các bài tập rời rạc một lần.

Đánh đổi: ưu và nhược điểm

Quyết định	Ưu điểm	Nhược điểm
Kiểm thử trong môi trường sản xuất	Lưu lượng, dữ liệu và quy mô thật; phát hiện đúng	Rủi ro cho người dùng nếu chứa thất bại; cần độ trưởng thành
Chỉ kiểm thử trong staging	An toàn, rủi ro thấp, dễ bắt đầu	Bỏ sót hành vi thế giới thực; tự tin giả
Ngày diễn tập thủ công	Xây kỹ năng và lòng tin; chi phí công cụ thấp	Không thường xuyên; phát hiện có thể hồi quy không bị chú ý
Hỗn loạn tự động liên tục	Bắt hồi quy nhanh; mở rộng được	Cần công cụ và khả năng quan sát trưởng thành trước
Bán kính ảnh hưởng rộng	Làm lộ điểm yếu hệ thống lớn	Rủi ro cao; một sai lầm thành sự cố
Bán kính ảnh hưởng hẹp	An toàn và kiểm soát được	Có thể bỏ sót thất bại xuyên dịch vụ nổi lên

Căng thẳng trung tâm là giữa tính thực tế và an toàn. Những phát hiện bạn muốn nhất đến từ môi trường sản xuất, vì đó là nơi duy nhất hệ thống của bạn đối mặt lưu lượng thật, dữ liệu thật và quy mô thật, vậy mà môi trường sản xuất chính là nơi một thí nghiệm hỏng gây hại cho người dùng. Cách giải quyết không phải chọn một phía. Mà là giành đường tiến về môi trường sản xuất dần dần: chứng minh điều kiện tiên quyết, diễn tập trong staging, rồi chạy thí nghiệm nhỏ, được chứa tốt trong môi trường sản xuất với điều kiện hủy nối với chỉ số trực tiếp, và mở rộng phạm vi chỉ khi bằng chứng tích lũy. Căng thẳng lặp lại khác, thủ công so với tự động, giải quyết theo cùng cách qua thời gian. Bắt đầu thủ công để xây hiểu biết và lòng tin, rồi tự động hóa các thí nghiệm bạn đã dựa vào, để khả năng phục hồi bạn đã xác minh một lần vẫn được xác minh.

Câu hỏi để thảo luận với đội của bạn

Chúng ta thực sự sẵn sàng chạy thí nghiệm hỗn loạn chưa, và làm sao chúng ta biết? Bắt đầu tiêm lỗi vì nghe tinh vi thì hấp dẫn, nhưng kỹ thuật hỗn loạn trên hệ thống không quan sát được, không có định nghĩa sức khỏe rõ ràng và không có hoàn tác nhanh chỉ là ngừng hoạt động tự gây ra. Hãy mang bằng chứng trung thực đến cuộc thảo luận này: bạn có thấy tỷ lệ yêu cầu thành công và độ trễ theo thời gian thực không, bạn có định nghĩa trạng thái ổn định đã thống nhất không, và bạn có hủy được một thí nghiệm và phục hồi trong vài giây không? Với một đội lớn, câu trả lời thường khác nhau theo dịch vụ, nên đầu ra hữu ích là một thanh sẵn sàng mà một dịch vụ phải vượt trước khi đủ điều kiện cho thí nghiệm. Trong bối cảnh chịu quy định thanh sẵn sàng đó đồng thời là kiểm soát bạn trình cho kiểm toán viên. Nếu câu trả lời trung thực là bạn chưa sẵn sàng, công việc hỗn loạn có giá trị nhất bạn làm quý này là xây năng lực quan sát và hoàn tác làm bạn sẵn sàng.
Chính sách bán kính ảnh hưởng của chúng ta là gì, và ai có thẩm quyền dừng một thí nghiệm? Mọi thí nghiệm hỗn loạn mang một ít rủi ro cho người dùng thật, và sự khác biệt giữa phát hiện có giá trị và sự cố bạn tự gây ra là bạn chứa nó chặt đến đâu. Hãy nói qua các giới hạn cụ thể: bao nhiêu phần lưu lượng, bao nhiêu thể hiện, môi trường nào, giờ nào trong ngày, và ngưỡng chỉ số nào tự động hủy lần chạy. Quyết định trước ai theo dõi mỗi thí nghiệm và ai giữ công tắc ngắt một hành động, vì một thí nghiệm không ai dừng nhanh được thì không được chứa. Với một tổ chức lớn chính sách này là thứ cho phép nhiều đội thí nghiệm mà không đội nào vô tình làm sập một phụ thuộc dùng chung. Câu trả lời nên được viết ra, thống nhất với các đội có dịch vụ bạn có thể ảnh hưởng, và coi là điều kiện tiên quyết để chạy bất cứ thứ gì trong môi trường sản xuất.
Cơ chế phục hồi nào chúng ta tin bảo vệ chúng ta, và chúng ta đã bao giờ thực sự kiểm thử chúng chưa? Hầu hết hệ thống đầy thời gian chờ, lần thử lại, bộ ngắt mạch, bộ nhớ đệm và đường chuyển dự phòng được cấu hình một lần và không bao giờ được thực hành dưới thất bại chúng tồn tại để đối phó. Hãy lập danh sách các cơ chế bạn đang dựa vào, rồi hỏi, với mỗi cái, lần cuối nó được xác minh hoạt động dưới lỗi tiêm thật là khi nào. Cân nhắc đối lập là thời gian: xác minh từng cơ chế tốn công sức kỹ thuật, và luôn có hạn chót tính năng. Hãy mang bằng chứng ngược lại với phản đối đó, cụ thể là chi phí của một lần ngừng hoạt động quá khứ mà một bộ ngắt mạch hoạt động hay thời gian chờ đúng đã chứa được. Câu trả lời nên biến một danh sách bảo vệ giả định an ủi thành tồn đọng thí nghiệm được ưu tiên, bắt đầu với những cơ chế mà thất bại sẽ đau nhất.
Điều gì phải đúng trước khi chúng ta chạy thí nghiệm trong môi trường sản xuất thay vì staging, và dịch vụ nào đã giành được quyền đó hôm nay? Những phát hiện bạn muốn nhất đến từ môi trường sản xuất, vì đó là nơi duy nhất hệ thống gặp lưu lượng thật, dữ liệu thật và quy mô thật, vậy mà nó cũng là nơi duy nhất một thí nghiệm hỏng gây hại cho người dùng thực. Với một đội lớn thực tế trung thực là các dịch vụ ở các mức sẵn sàng khác nhau, nên quy tắc đại trà “không hỗn loạn trong sản xuất” lãng phí việc học tốt nhất của bạn trong khi quy tắc đại trà “có” mời gọi ngừng hoạt động tự gây ra. Hãy mang bằng chứng theo dịch vụ: chất lượng khả năng quan sát của nó, liệu trạng thái ổn định có được xác định và cảnh báo được, hoàn tác nhanh đến đâu, và thành tích các thí nghiệm staging sạch biện minh cho việc thăng cấp nó. Trong bối cảnh doanh nghiệp và chính phủ, hãy gắn cổng sản xuất với một kiểm soát có tài liệu nêu ai phê duyệt thăng cấp và điều kiện hủy nào nối với chỉ số trực tiếp, để kiểm toán viên thấy một quyết định có chủ đích, có bằng chứng thay vì một đội ứng biến với người dùng thật.
Khi một thí nghiệm hỗn loạn làm lộ điểm yếu, phát hiện đó đi đâu, và làm sao chúng ta ngăn nó mục rữa không ai chạm? Một chương trình khám phá điểm yếu mà không bao giờ sửa còn tệ hơn không có, vì nó đốt công sức, xói mòn lòng tin, và dạy mọi người rằng thí nghiệm là sân khấu. Áp lực đối lập luôn là lộ trình tính năng: một bản sửa khả năng phục hồi hiếm khi cảm thấy khẩn cấp như bản phát hành kế tiếp cho đến khi lần ngừng hoạt động nó đã ngăn thực sự đến. Hãy mang trạng thái hiện tại của tồn đọng khả năng phục hồi vào cuộc thảo luận: bao nhiêu phát hiện hỗn loạn đang mở, cái cũ nhất bao nhiêu tuổi, và liệu phát hiện từ thí nghiệm, buổi diễn tập khôi phục thảm họa và rút kinh nghiệm sự cố có chảy vào một hàng đợi chung hay rải qua các đội. Thống nhất ai sở hữu mỗi bản sửa và ai chạy thí nghiệm theo dõi xác nhận nó giữ. Với một tổ chức lớn hay chịu quy định, hãy nêu diễn đàn rà soát tồn đọng theo nhịp cố định và nắm thẩm quyền ưu tiên một bản sửa khả năng phục hồi hơn một tính năng, vì một phát hiện không ai chịu trách nhiệm đóng là rủi ro bạn chỉ mới ghi lại chứ chưa loại bỏ.
Chúng ta đã sẵn sàng tự động hóa bất kỳ thí nghiệm nào thành xác minh liên tục chưa, và cụ thể là những cái nào? Ngày diễn tập thỉnh thoảng tìm điểm yếu, nhưng hệ thống thay đổi hằng ngày và một bản sửa từ quý trước có thể lặng lẽ hồi quy, nên trạng thái cuối trưởng thành là một tập thí nghiệm được chọn lọc chạy tự động và bắt hồi quy trong vài ngày. Mối nguy là tự động hóa quá sớm: hỗn loạn liên tục chồng lên hệ thống chưa trưởng thành với khả năng quan sát yếu tạo sự cố nhanh hơn hiểu biết. Hãy mang danh sách các thí nghiệm bạn đã chạy thủ công đủ nhiều lần để tin hoàn toàn, các kiểm soát bán kính ảnh hưởng và điều kiện hủy sẽ chi phối chúng khi không giám sát, và giám sát sẽ bắt một lần chạy tự động đi sai lúc 3 giờ sáng khi không ai theo dõi. Với một doanh nghiệp lớn hay cơ quan công, hãy cân nhắc sự soi xét thêm mà tiêm lỗi không giám sát mời gọi: phê duyệt quản lý thay đổi, dấu vết kiểm toán mỗi lần chạy tự động phải để lại, và trách nhiệm rõ ràng cho một thí nghiệm lên lịch trùng với sự cố thật. Chỉ tự động hóa các thí nghiệm bạn đã hiểu, và giữ phần còn lại thủ công cho đến khi chúng giành được cùng lòng tin.

Góc nhìn theo lĩnh vực

Công ty khởi nghiệp. Tốc độ và sự sống còn chi phối, vì vậy đừng chi gì cho nền tảng hỗn loạn. Hãy chạy một ngày diễn tập chín mươi phút trong staging nhắm vào phụ thuộc duy nhất mà thất bại sẽ thực sự giết bạn, thường là thanh toán, xác thực, hay kho dữ liệu chính. Tiêm thất bại bằng một proxy thô hay một tiến trình bị giết, xem cái gì hỏng, sửa thời gian chờ hay phương án dự phòng bị thiếu, và đi tiếp. Toàn bộ ý nghĩa là bắt lần ngừng hoạt động tự gây ra hiển nhiên một cách rẻ trước khi khách hàng làm vậy, không phải xây một kỷ luật bạn không bố trí nhân sự nổi.

Doanh nghiệp nhỏ. Không có chuyên gia độ tin cậy và ngân sách eo hẹp, hãy coi kiểm thử khả năng phục hồi là bài tập định kỳ, có chủ đích hơn là chương trình bạn bố trí nhân sự. Dựa vào tính năng tiêm lỗi mà nhà cung cấp đám mây hay công cụ được quản lý của bạn đã có thay vì mua nền tảng chuyên dụng, và tập trung thí nghiệm vào nhúm phụ thuộc mà khách hàng sẽ nhận ra. Đóng khung nó như bảo hiểm: một buổi chiều xác nhận bản sao lưu khôi phục và thanh toán suy giảm êm rẻ hơn nhiều so với lần ngừng hoạt động chứng minh chúng không.

Doanh nghiệp lớn. Vấn đề là phối hợp nhiều đội trên các phụ thuộc dùng chung ở quy mô, vì vậy hãy chuẩn hóa thanh sẵn sàng, chính sách bán kính ảnh hưởng, và việc nối điều kiện hủy mà mọi đội phải vượt trước khi chạy trong môi trường sản xuất. Chuyển phát hiện hỗn loạn, buổi diễn tập khôi phục thảm họa và rút kinh nghiệm sự cố vào một tồn đọng khả năng phục hồi với quyền sở hữu rõ ràng, và dùng ngày diễn tập hằng quý cộng một tập thí nghiệm tự động được chọn lọc để thỏa mãn kỳ vọng khả năng phục hồi vận hành bằng bằng chứng. Quản trị ai được ảnh hưởng một dịch vụ dùng chung để thí nghiệm của một đội không làm sập hạ tầng người khác phụ thuộc.

Chính phủ. Quy tắc mua sắm, minh bạch và trách nhiệm giải trình công định hình công việc. Yêu cầu liên tục hoạt động thường đòi bài tập thường xuyên dù sao, nên hãy chạy chúng như ngày diễn tập trực tiếp tạo phát hiện thật thay vì tập hồ sơ không ai mở, và giữ dấu vết kiểm toán về mỗi thí nghiệm, bán kính ảnh hưởng và kết quả. Nơi công cụ tiêm lỗi được mua sắm, hãy đòi nó vừa trong quy tắc bảo mật và xử lý dữ liệu, và dành thí nghiệm sản xuất trên dịch vụ hướng công dân cho các cửa sổ được chứa chặt, được phê duyệt. Bằng chứng một chương trình hỗn loạn tạo ra chính xác là điều kiểm toán viên hay cơ quan giám sát kỳ vọng thấy.

Ví dụ

Công ty khởi nghiệp. Một công ty khởi nghiệp mười lăm người chạy ứng dụng web trên một nhúm dịch vụ và phụ thuộc vào API thanh toán bên thứ ba. Không ai có thời gian cho nền tảng hỗn loạn, nên đội chạy một ngày diễn tập chín mươi phút trong staging. Họ hình thành một giả thuyết: nếu API thanh toán bắt đầu trả lỗi, thanh toán nên hiện thông báo thử lại rõ ràng và xếp hàng đơn hàng thay vì sập. Họ tiêm phản hồi 500 bằng một proxy đơn giản, và phát hiện giao diện treo vô tận vì lệnh gọi máy khách không có thời gian chờ. Họ thêm thời gian chờ và phương án dự phòng thân thiện, chạy lại thí nghiệm để xác nhận bản sửa, và viết một ghi chú hai đoạn trong tài liệu chung. Tổng chi phí: một buổi chiều và một lỗi rất thật bị bắt trước khi khách hàng gặp.

Doanh nghiệp lớn. Một ngân hàng toàn cầu phải chứng minh khả năng phục hồi vận hành với cơ quan quản lý theo các kịch bản nghiêm trọng-nhưng-có-thể-xảy-ra. Đội độ tin cậy của nó chạy chương trình ngày diễn tập hằng quý cộng một tập thí nghiệm tự động trong môi trường sản xuất. Một kịch bản chuyển dự phòng cơ sở dữ liệu giao dịch chính sang dự phòng của nó trong cửa sổ lưu lượng thấp, với bán kính ảnh hưởng được chứa chặt và điều kiện hủy gắn với tỷ lệ giao dịch thành công. Lần chạy đầu tiên hé lộ rằng một dịch vụ đối chiếu hạ nguồn có chính sách thử lại không lùi, tạo đỉnh tải làm trễ phục hồi vượt xa mục tiêu thời gian phục hồi trong kế hoạch khôi phục thảm họa (chương 9.5). Phát hiện đi vào cùng tồn đọng như rút kinh nghiệm sự cố, chính sách thử lại được sửa với lùi lũy thừa, và một thí nghiệm theo dõi xác nhận chuyển dự phòng nay hoàn tất trong mục tiêu. Toàn bộ bài tập trở thành bằng chứng cho cơ quan quản lý.

Chính phủ. Một cơ quan quốc gia vận hành cổng trợ cấp hướng công dân được yêu cầu duy trì liên tục hoạt động qua gián đoạn. Thay vì coi kế hoạch liên tục là tập hồ sơ không ai mở, cơ quan chạy bài tập liên tục hằng năm như một ngày diễn tập trực tiếp. Đội mô phỏng mất trung tâm dữ liệu chính và đi qua việc chuyển dự phòng sang địa điểm phụ, đồng thời riêng biệt tiêm độ trễ vào một phụ thuộc xác minh danh tính để xem cổng có suy giảm êm không. Họ biết rằng một khoảng trống giám sát chưa kiểm thử khiến đội trực mù trước việc dịch vụ danh tính chậm lại, nên cảnh báo kích hoạt muộn. Cơ quan đóng khoảng trống quan sát, cập nhật sổ tay vận hành, và lên lịch cùng bài tập cho năm sau, biến yêu cầu tuân thủ thành khả năng phục hồi thật, đã kiểm thử cho một dịch vụ công trọng yếu.

Luận chứng kinh doanh: động lực, ROI và TCO

Lợi tức của kỹ thuật hỗn loạn đến từ những lần ngừng hoạt động không bao giờ xảy ra. Một lần ngừng hoạt động lớn duy nhất của một dịch vụ lớn có thể tốn từ hàng chục nghìn đến hàng triệu về doanh thu mất, tiền phạt quy định, lao động khắc phục và thiệt hại danh tiếng kéo dài lâu sau khi dịch vụ được khôi phục. Thí nghiệm hỗn loạn chuyển những bất ngờ không khả đoán, đắt đỏ đó thành phát hiện rẻ, lên lịch mà bạn sửa theo thời gian của mình với kỹ sư quan sát và hoàn tác sẵn sàng. Tìm một thời gian chờ hỏng trong ngày diễn tập có kiểm soát tốn một buổi chiều. Tìm nó trong sự cố thật tốn một lần ngừng hoạt động, một cuộc chạy vạy toàn đội, và lòng tin của người dùng. Số học nghiêng về ngày diễn tập với biên độ lớn.

Tổng chi phí sở hữu khiêm tốn một khi điều kiện tiên quyết tồn tại, vì kỹ thuật hỗn loạn tái sử dụng khoản đầu tư vào khả năng quan sát, cảnh báo và hoàn tác mà bạn cần dù sao. Chi phí trung thực là thời gian kỹ thuật để chạy thí nghiệm, một ít công cụ để tiêm lỗi và chứa bán kính ảnh hưởng, và công việc văn hóa làm lãnh đạo thoải mái với việc cố ý đưa thất bại vào. Điều cuối là rào cản thật, và cách đi qua nó là bắt đầu trong staging, cho thấy phát hiện ánh xạ đến tiền hay rủi ro, và để vài thí nghiệm sản xuất được chứa xây lòng tin. Để lập luận với ban lãnh đạo, hãy đóng khung kỹ thuật hỗn loạn là bảo hiểm bạn đo được: trình bày chi phí các sự cố gần đây, cho thấy cái nào thí nghiệm khả năng phục hồi sẽ bắt được, và đề xuất một chương trình bắt đầu nhỏ và mở rộng chỉ khi nó tự chứng minh. Trong bối cảnh chịu quy định và khu vực công, hãy thêm góc tuân thủ, vì kiểm thử khả năng phục hồi vận hành và bài tập liên tục ngày càng được kỳ vọng, và một chương trình hỗn loạn là cách bạn thỏa mãn kỳ vọng đó bằng bằng chứng thay vì giấy tờ.

Phản mẫu và cạm bẫy

Hỗn loạn không có khả năng quan sát. Tiêm lỗi vào hệ thống bạn không thấy là đoán mò thêm bước; bạn sẽ gây hại và không học gì.
Không có định nghĩa trạng thái ổn định. Không có thước đo sức khỏe thống nhất, bạn không phân biệt được thí nghiệm làm lộ vấn đề hay gây ra nó.
Không có giả thuyết. Ngẫu nhiên làm hỏng đồ không phải kỹ thuật hỗn loạn; đó là phá hoại với cái tên mỹ miều và không có phát hiện.
Bán kính ảnh hưởng không được chứa. Bỏ qua thí nghiệm nhỏ, an toàn và đi thẳng đến thất bại toàn môi trường sản xuất biến bài kiểm tra thành ngừng hoạt động tự gây ra.
Không có đường hủy. Một thí nghiệm bạn không dừng tức thì được không phải thí nghiệm; đó là sự cố đang chờ kích hoạt.
Tự động hóa quá sớm. Hỗn loạn liên tục trên hệ thống chưa trưởng thành tạo sự cố nhanh hơn hiểu biết.
Phát hiện không đi đến đâu. Khám phá điểm yếu và không bao giờ sửa lãng phí bài tập và xói mòn lòng tin vào cả chương trình.
Đổ lỗi sau thí nghiệm hỏng. Trừng phạt kỹ sư chạy thí nghiệm làm lộ khiếm khuyết thật bảo đảm không ai chạy cái kế tiếp.

Mô hình trưởng thành

Mức 1, Khởi đầu: Khả năng phục hồi được giả định, không được kiểm thử. Thất bại được khám phá trong môi trường sản xuất trong sự cố thật. Không có ngày diễn tập, không tiêm lỗi, và thường không có định nghĩa rõ ràng về khỏe mạnh trông thế nào. Đội biết về điểm yếu của mình bằng con đường khó, từng lần ngừng hoạt động một.
Mức 2, Phát triển: Đội chạy ngày diễn tập thỉnh thoảng, thường trong staging, với kịch bản xác định và một giả thuyết. Trạng thái ổn định được xác định cho vài dịch vụ then chốt và khả năng quan sát cơ bản tồn tại. Phát hiện được nắm bắt và một số được sửa, nhưng thực hành không nhất quán qua các đội và phụ thuộc vào những người ủng hộ cá nhân thay vì phương pháp đã thiết lập.
Mức 3, Chuẩn hóa: Thí nghiệm hỗn loạn là thực hành có tài liệu, toàn tổ chức với chính sách bán kính ảnh hưởng được thực thi, điều kiện hủy, và tiêu chí sẵn sàng mà một dịch vụ phải vượt trước khi thí nghiệm trong môi trường sản xuất. Thí nghiệm chạy trong môi trường sản xuất dưới điều kiện có kiểm soát, phát hiện chảy vào tồn đọng khả năng phục hồi chung cùng rút kinh nghiệm sự cố và buổi diễn tập khôi phục thảm họa, và cơ chế phục hồi được xác minh thay vì giả định. Mọi đội theo cùng một sổ tay.
Mức 4, Quản lý: Chương trình được đo và kiểm soát bằng dữ liệu theo đường cơ sở. Bạn theo dõi độ phủ khả năng phục hồi (dịch vụ trọng yếu nào và cơ chế nào, như thời gian chờ, thử lại, bộ ngắt mạch và chuyển dự phòng, đã được xác minh dưới lỗi tiêm thật và gần đây thế nào), tỷ lệ thí nghiệm làm lộ phát hiện, thời gian trung bình để đóng một phát hiện khả năng phục hồi, và một cơ chế đã xác minh hồi quy bao lâu một lần. Các chỉ số này được rà soát theo nhịp cố định, thăng cấp lên sản xuất được chặn cổng bằng bằng chứng thay vì ý kiến, và thí nghiệm được ưu tiên theo rủi ro đo được của các cơ chế còn chưa xác minh.
Mức 5, Điều phối: Một tập thí nghiệm được chọn lọc chạy liên tục và tự động, bắt hồi quy trong vài ngày, và chương trình thích ứng khi hệ thống và bức tranh rủi ro đổi. Kỹ thuật hỗn loạn được tích hợp trong toàn tổ chức với đường ống phân phối, học từ sự cố và kiểm thử khôi phục thảm họa, nên dịch vụ mới thừa hưởng xác minh khả năng phục hồi theo mặc định. Khả năng phục hồi là thuộc tính được xác minh liên tục của hệ thống, và lãnh đạo coi chương trình là quản lý rủi ro tiêu chuẩn được tinh chỉnh dựa trên bằng chứng thay vì một sáng kiến đặc biệt.

Ý tưởng để thảo luận

Làm sao bạn quyết định dịch vụ nào trong tổ chức của bạn giành được quyền chạy thí nghiệm hỗn loạn trong môi trường sản xuất trước, và điều gì phải đúng trước khi nó làm vậy?
Khi một thí nghiệm hỗn loạn làm lộ điểm yếu nghiêm trọng, ai sở hữu bản sửa, và làm sao bạn giữ phát hiện đó khỏi nằm không ai chạm trong tồn đọng?
Lằn ranh giữa thí nghiệm hỗn loạn, buổi diễn tập khôi phục thảm họa và ngày diễn tập nằm ở đâu trong bối cảnh của bạn, và sự phân biệt có quan trọng cho cách bạn lên kế hoạch không?
Làm sao bạn thuyết phục một giám đốc hoài nghi rằng cố ý tiêm thất bại vào môi trường sản xuất an toàn hơn hiện trạng chờ ngừng hoạt động thật?
Thí nghiệm đầu tiên nhỏ nhất, có giá trị nhất mà đội của bạn có thể chạy tháng tới là gì, và cái gì sẽ ngăn bạn chạy nó?
Kiểm thử khả năng phục hồi nên khác nhau thế nào giữa dịch vụ công hướng công dân có nhiệm vụ liên tục và công cụ doanh nghiệp nội bộ có ít người dùng?

Những điểm cần ghi nhớ

Kỹ thuật hỗn loạn là thử nghiệm có kỷ luật, dựa trên giả thuyết để xây sự tự tin vào khả năng phục hồi, không phải phá hỏng ngẫu nhiên.
Thiết lập khả năng quan sát, định nghĩa trạng thái ổn định và hoàn tác nhanh trước khi tiêm một lỗi.
Tiêm lỗi thực tế (độ trễ, lỗi, cạn kiệt tài nguyên, thất bại phụ thuộc) và dùng chúng để xác minh thời gian chờ, thử lại, bộ ngắt mạch và chuyển dự phòng thực sự hoạt động.
Bắt đầu với bài tập bàn giấy và ngày diễn tập, chứa bán kính ảnh hưởng có chủ đích, và giành đường tiến tới môi trường sản xuất và tự động hóa.
Nối thí nghiệm với kiểm thử khôi phục thảm họa (chương 9.5) và học từ sự cố (chương 9.3) để phát hiện cộng dồn vào một tồn đọng khả năng phục hồi duy nhất.
Xử lý phát hiện không đổ lỗi và sửa chúng; một thí nghiệm có bài học không được giải quyết còn tệ hơn không có thí nghiệm.

Tài liệu tham khảo và đọc thêm

Casey Rosenthal, Nora Jones, Chaos Engineering: System Resiliency in Practice
Russ Miles, Learning Chaos Engineering: Discovering and Overcoming System Weaknesses Through Experimentation
Mikolaj Pawlikowski, Chaos Engineering: Crash Test Your Applications
Ali Basiri et al., Chaos Engineering (IEEE Software, 2016)
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, Site Reliability Engineering: How Google Runs Production Systems
Michael T. Nygard, Release It! Design and Deploy Production-Ready Software
Principles of Chaos Engineering, principlesofchaos.org