Làm thế nào để ứng dụng Chaos Engineering vào hoạt động công nghệ thông tin?

Chaos Engineering (CE) là bộ môn thử nghiệm trên một hệ thống nhằm xây dựng niềm tin vào khả năng của hệ thống để chịu được các điều kiện hỗn loạn trong sản xuất . Cách tiếp cận này đang trở nên phổ biến trong thực tiễn DevOps; nhưng làm thế nào để ứng dụng của nó mở rộng cho các hoạt động CNTT?

Trong thực tế, CE cho các hoạt động CNTT cung cấp một khuôn khổ tương tự để kiểm tra căng thẳng một nền tảng công nghệ để hiểu các điểm yếu và cạm bẫy hiệu suất của nó dưới áp lực nặng nề.

CE có xu hướng được sử dụng chủ yếu trong DevOps trong quá trình kiểm tra lỗi: thiết lập các thử nghiệm để chạy phần mềm trong các điều kiện khác nhau, chẳng hạn như lưu lượng cao điểm và giám sát cách thức hoạt động và hoạt động của nó. Điều này ngày càng trở nên cần thiết trong các hệ thống dựa trên đám mây, nơi việc không hiểu được các phản ứng tải cực đoan có thể dẫn đến các thất bại trong dòng chảy hoặc tệ hơn nữa là làm quay hàng ngàn nút bổ sung xử lý các điều kiện lỗi trong khi không thực hiện bất kỳ công việc thực tế nào.

Những nguyên tắc tương tự này, được áp dụng cho quản lý hoạt động CNTT (ITOM), giúp xác định đường cơ sở chức năng và dung sai cho cơ sở hạ tầng, chính sách và quy trình bằng cách làm rõ cả đầu ra trạng thái ổn định và hỗn loạn khi đạt đến cực trị.

Ứng dụng trong CNTT

Lý thuyết về CE trong DevOps đã đạt được lực kéo sớm tại Netflix khi họ chuyển từ cơ sở hạ tầng vật lý sang ảo, với nhóm thực hiện nó trên AWS đã tách ra để tạo thành Gremlin . Tuy nhiên, kỹ thuật hỗn loạn thường không được sử dụng trong các hoạt động CNTT, vì ITOM trước đây đã bị tách khỏi sự phát triển (nói chung, CNTT giám sát động lực hệ thống và khi xảy ra sự cố, quản lý thay đổi kỹ thuật hoặc ITSM được đưa vào để khắc phục sự cố).

Với sự phát triển của container hóa trong các ứng dụng đám mây ngày nay, cơ sở hạ tầng CNTT trông giống môi trường phát triển hơn là kiến ​​trúc đa tầng cổ điển. Nhưng quy mô không giới hạn của đám mây có nghĩa là sự thất bại cũng có thể là vô hạn: microservice được phục vụ tốt bằng cách kiểm tra độ đàn hồi và khả năng mở rộng, luồng dữ liệu và khả năng phục hồi thông qua việc nhấn mạnh hệ thống vào khả năng chịu đựng của nó và khắc phục những thiếu sót của chúng trước khi xảy ra sự cố.

1, 2, 3 … hỗn loạn

Việc triển khai kỹ thuật hỗn loạn cho quản lý hoạt động CNTT cung cấp một cách tiếp cận có hệ thống để xác định các điểm yếu trong thế giới microservice. Trong một môi trường nguyên khối, bạn có thể thấy được các số liệu về hiệu suất và sự kiện có thể bị mất với các thiết kế microservice. Do đó, nhu cầu hiểu biết sâu sắc về hoạt động càng trở nên quan trọng hơn khi nhân rộng ra khối lượng công việc không xác định.

Khỉ con của Netflix đã phát triển từ các nguyên tắc CE từ cộng đồng bản địa trên nền tảng đám mây của họ, nhằm giải quyết các lỗ hổng trong khả năng của các công cụ phát triển chung để quản lý sự phức tạp cực độ. Phương pháp này có thể mở rộng cho cơ sở hạ tầng và giúp thiết lập các rào cản đối với toàn bộ hoạt động của nền tảng. Vậy làm thế nào một nhóm nên mang suy nghĩ này vào quản lý hoạt động CNTT của họ? Thực hiện theo năm bước cơ bản sau:

  • Xác định trạng thái ổn định hiện tại:  Thực hiện phân tích cơ sở là một khái niệm tiêu chuẩn trong hoạch định năng lực, chiến lược nâng cấp và các chức năng có tác động cao khác. Bắt đầu với một cái gì đó tương đối đơn giản (và nhỏ) để bạn không bị choáng ngợp bởi dữ liệu hoặc có nguy cơ can thiệp vào doanh nghiệp nếu có sự cố xảy ra (chẳng hạn như Bảo mật nhóm đỏ ). Ví dụ: giám sát việc sử dụng CPU và mạng, đó là những tắc nghẽn phổ biến trong bất kỳ cửa hàng CNTT nào
  • Xác định điều kiện tối ưu. Có cách hệ thống của bạn thường hoạt động, và sau đó là cách nó hoạt động; Chúng thường không giống nhau. Việc sử dụng CPU và độ trễ mạng luôn bị ảnh hưởng bởi hiệu quả ứng dụng, điều kiện phần cứng và một loạt các yếu tố khác. Tạo một tiêu chuẩn phác thảo những gì các kỹ sư nên mong đợi vào một ngày bình thường, vào một ngày dễ dàng và vào một ngày rất khó khăn. Đây là các nhóm kiểm soát và ngày cực đoan sẽ là bài kiểm tra căng thẳng
  • Hình thành một giả thuyết. Hệ thống sẽ phá vỡ ở đâu? Nếu bạn đang chạy một kịch bản ứng dụng như tăng gấp đôi lưu lượng cao nhất mà ngay cả ngày tồi tệ nhất của bạn cho đến nay, CPU của bạn sẽ duy trì việc sử dụng tối ưu (hoặc công cụ cung cấp container sẽ triển khai trơn tru các nút bổ sung) như trong các nhóm điều khiển biến, hoặc nó sẽ tăng đột biến đến mức các quá trình bị đình trệ vì không còn đủ bộ nhớ hoặc băng thông mạng để quản lý tải?
  • Thực hiện một sự kiện trong thế giới thực (nhưng chứa bán kính vụ nổ). Làm một cái gì đó cực đoan, như gỡ bỏ một tường lửa cắt đứt kết nối với một nhà cung cấp dịch vụ internet. Điều này sẽ gây nhầm lẫn cho ứng dụng khi nó cố gắng đáp ứng các yêu cầu với các lỗi lặp đi lặp lại, làm tăng quá trình CPU khi lỗi trở về từ điểm cuối mạng chết. Các sự kiện đăng nhập sẽ gắn kết, điền vào cơ sở dữ liệu và bão hòa xương sống
  • Xác thực giả thuyết. Chuyện gì đã xảy ra? Giám sát việc sử dụng và thông lượng mạng trong quá trình kiểm tra và xem hệ thống bị đổ ở đâu. Đó có phải là những gì bạn mong đợi, hoặc đã làm một cái gì đó chưa bao giờ được coi là diễn ra trước đây? Có phải sự hỗn loạn mới nổ ra từ các khe nứt trong cơ sở hạ tầng của bạn? Ổn định, tài liệu và khắc phục

Không bao giờ ngừng không sợ hãi

Nhấn mạnh một hệ thống đến mức tối đa tuyệt đối của nó và thêm một chút nữa để xem mọi thứ xảy ra sai sót cho phép bạn hiểu hành vi trạng thái ổn định và xử lý lỗi, do đó bạn có thể khắc phục nó trước khi xảy ra sự cố theo cách mới và bất ngờ. Làm đột biến giao thông trông như thế nào? Các sự kiện trong thế giới thực và tác động của chúng đối với tổ chức của bạn là gì?

Kỹ thuật hỗn loạn không chỉ dành cho DevOps. Nó nên là một thực hành có hệ thống để kiểm tra tải (ra khỏi vùng thoải mái của bạn) đến mức thất bại. Đó là trách nhiệm đối với nhiều hơn các triển khai microservice và áp dụng cho tất cả các loại kỷ luật trong tổ chức CNTT.

Trả lời

Thư điện tử của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *