NộI Dung
- Chuẩn bị cho sự thất bại
- Các bước tiếp theo
- Không lỗi, không căng thẳng - Hướng dẫn từng bước của bạn để tạo ra phần mềm thay đổi cuộc sống mà không phá hủy cuộc sống của bạn
- Học hỏi và cải thiện thông qua các cuộc tập trận
Nguồn: áp lựcUA / iStockphoto
Lấy đi:
Các hệ thống hiện đại phải có khả năng xử lý sự hỗn loạn để tránh thời gian chết. Đó là lý do tại sao nó quan trọng hơn bao giờ hết để kiểm tra kỹ lưỡng các hệ thống và đảm bảo khả năng phục hồi của chúng.
Bất chấp những nỗ lực lớn nhất của chúng tôi để tránh chúng, các sự cố CNTT là một phần không thể tránh khỏi của công việc - và cố gắng đi trước thời gian ngừng hoạt động của doanh nghiệp chỉ trở nên khó khăn hơn. Các hệ thống ngày nay được kết hợp chặt chẽ và ngày càng phức tạp, và với nhiều bộ phận chuyển động hơn sẽ có nhiều cơ hội hơn cho những điều sai lầm.
Đây là một lý do tại sao ngày càng nhiều tổ chức chuyển sang microservice để tăng tính khả dụng của dịch vụ và khả năng phục hồi tốt hơn cho thất bại. Nhưng trong khi đây là những tiền đề tuyệt vời để phá vỡ các ứng dụng nguyên khối, chúng cũng có thể tiềm ẩn nguy cơ thất bại - trừ khi được thiết kế rõ ràng với khả năng phục hồi trong tâm trí.
Chuẩn bị cho sự thất bại
Do tính chất hỗn loạn vốn có của các hệ thống phân tán, các dịch vụ nên được phát triển không chỉ để lường trước sự thất bại, mà còn tự động phục hồi trong trường hợp thất bại. Điều này có nghĩa là xúi giục thất bại một cách thường xuyên để đảm bảo hệ thống của bạn có thể xử lý sự hỗn loạn mà không làm gián đoạn dịch vụ cho khách hàng cuối. Và để đạt được điều này, bạn cần có khả năng mô phỏng lưu lượng truy cập giống như sản xuất trong môi trường thử nghiệm.
Tất nhiên, đó là một ý tưởng tốt để kiểm tra khả năng phục hồi trước khi những thay đổi được đưa vào sản xuất. Nếu bạn không làm điều này, bạn đã có thể xác minh rằng các dịch vụ của bạn có thể hỗ trợ cả tải trung bình và cao điểm. Trên thực tế, đặt cược an toàn nhất là đảm bảo sản phẩm của bạn có thể xử lý gấp đôi số tiền cao nhất mà không phải tăng quy mô.
Khi nói đến kiểm tra khả năng phục hồi, các công cụ phù hợp không nên quá quan tâm đến cách xử lý các yêu cầu, chỉ là cuối cùng chúng có tác động chính xác. Hãy nhớ rằng trong một số điều kiện nhất định, dịch vụ đầu vào có thể không gửi yêu cầu cho phần còn lại của hệ thống nhưng không báo cáo lỗi. Các vấn đề rủi ro Don Don bay theo radar giám sát bằng cách đảm bảo rằng việc xác thực đầu cuối trên thực tế đang xảy ra. (Để biết thêm, hãy xem Thất bại về Công nghệ: Chúng ta có thể sống với họ không?)
Các bước tiếp theo
Sau khi hiểu cách các dịch vụ hoạt động dưới tải, đã đến lúc bắt đầu giới thiệu các sự kiện thất bại. Như với tất cả các thử nghiệm phần mềm, tốt nhất là có các công cụ tự động cho phép bạn tái tạo dễ dàng và nhanh chóng các kịch bản, để bạn có thể điều phối các sự kiện phức tạp ảnh hưởng đến các công nghệ cơ sở hạ tầng khác nhau. Và ngoài khả năng xác minh các sửa lỗi và thay đổi đối với các dịch vụ, điều này cho phép bạn chạy các tình huống lỗi ngẫu nhiên trong bất kỳ môi trường nào và theo lịch trình.
Các sự kiện thất bại có ý nghĩa phụ thuộc phần lớn vào cách bố trí các dịch vụ của bạn và bạn có thể hình thành chúng bằng cách đặt câu hỏi cụ thể có liên quan đến bạn. Ví dụ, tác động đối với những người sử dụng giao diện người dùng khi cơ sở dữ liệu không thể truy cập được trong một khoảng thời gian nhất định là gì? Những người dùng vẫn có thể điều hướng giao diện người dùng web? Họ vẫn có thể đưa ra các bản cập nhật cho thông tin của mình và những cập nhật đó có được xử lý chính xác khi cơ sở dữ liệu có thể truy cập lại được không?
Nếu bạn chạy nhiều dịch vụ siêu nhỏ, bạn có thể hỏi liệu sẽ có sự cố ngừng hoạt động toàn cầu nếu có bất kỳ dịch vụ riêng lẻ nào gặp sự cố. Hoặc nếu bạn có một cơ chế xếp hàng để đệm giao tiếp giữa các dịch vụ, điều gì xảy ra khi dịch vụ tiêu dùng (hoặc dịch vụ) ngừng hoạt động? Người dùng vẫn có thể làm việc với ứng dụng của bạn chứ? Và với một tải trung bình, bạn có bao lâu trước khi hàng đợi tràn ra và bạn bắt đầu mất s?
Không lỗi, không căng thẳng - Hướng dẫn từng bước của bạn để tạo ra phần mềm thay đổi cuộc sống mà không phá hủy cuộc sống của bạn
Bạn không thể cải thiện kỹ năng lập trình của mình khi không ai quan tâm đến chất lượng phần mềm.
Khi bạn đã xác định một vài câu hỏi chính về cơ sở hạ tầng của mình, bạn có thể bắt đầu liệt kê các cách khác nhau để mô phỏng những thất bại đó. Nó có thể là đủ để dừng một dịch vụ cụ thể hoặc một máy chủ cơ sở dữ liệu. Bạn có thể muốn chặn luồng chính của dịch vụ để mô phỏng khóa chết, trong khi container của nó vẫn phản hồi và chạy. Bạn có thể quyết định giới thiệu các quy tắc trong mạng của mình để chặn lưu lượng giữa các dịch vụ cụ thể. Trên môi trường Linux, bạn có thể sử dụng các công cụ như ‘tc, để mô phỏng các tình huống mạng như độ trễ cao, bị rớt, bị hỏng hoặc bị trùng lặp. (Điều quan trọng là có liên quan đến người dùng trong thử nghiệm. Đọc thêm trong 4 lý do tại sao người dùng cuối cần tham gia thử nghiệm trước UAT.)
Học hỏi và cải thiện thông qua các cuộc tập trận
Một trong những khía cạnh có giá trị nhất của việc tạo ra các kịch bản thất bại là chúng có thể phơi bày tất cả các cách tiềm năng mà hệ thống có thể thất bại, từ đó khắc đường dẫn đến logic tự phục hồi. Nhóm của bạn sẽ thực hiện các bước để khôi phục dịch vụ theo cách thủ công - nhân tiện, rất tốt, để xác nhận rằng họ có thể thực hiện việc này trong SLA. Tự động hóa quá trình phục hồi này có thể được thực hiện, nhưng trong thời gian đó, bạn có thể yên tâm khi biết nhóm của mình đã thực hiện quy trình đưa dịch vụ trở lại đúng hướng. Bằng cách tạo các kịch bản thất bại ngẫu nhiên và thường xuyên và không tiết lộ chi tiết đầy đủ về hoạt động, bạn cũng có thể bao gồm khám phá và chẩn đoán cho máy khoan - rốt cuộc, đây là một phần quan trọng của SLA.
Về cốt lõi, kỹ thuật hỗn loạn lấy sự phức tạp của hệ thống như một sự cho trước, kiểm tra nó bằng cách mô phỏng các điều kiện mới và lập dị, và quan sát cách hệ thống phản ứng. Đây là nhóm kỹ thuật dữ liệu cần thiết kế lại và cấu hình lại hệ thống để đạt được khả năng phục hồi cao hơn. Có rất nhiều cơ hội để học những điều mới và hữu ích. Chẳng hạn, bạn có thể tìm thấy các trường hợp trong đó các dịch vụ không được cập nhật khi các dịch vụ hạ nguồn đã thay đổi hoặc các khu vực thiếu giám sát hoàn toàn. Không có nhiều cách thú vị để làm cho sản phẩm của bạn trở nên linh hoạt và mạnh mẽ hơn!