Ghi chú. bản dịch.: Bài viết này tiếp nối một loạt bài viết tuyệt vời của nhà truyền giáo công nghệ AWS, Adrian Hornsby, người đã giải thích một cách đơn giản và rõ ràng về tầm quan trọng của thử nghiệm nhằm giảm thiểu hậu quả của lỗi trong hệ thống CNTT.
“Nếu bạn không chuẩn bị một kế hoạch, nghĩa là bạn có kế hoạch thất bại.” - Benjamin Franklin
В Trong loạt bài viết này, tôi đã giới thiệu khái niệm về kỹ thuật hỗn loạn và giải thích cách nó giúp tìm ra và sửa chữa các sai sót trong hệ thống trước khi chúng dẫn đến lỗi sản xuất. Nó cũng thảo luận về cách kỹ thuật hỗn loạn thúc đẩy sự thay đổi văn hóa tích cực trong các tổ chức.
Ở cuối phần đầu tiên, tôi hứa sẽ nói về “các công cụ và phương pháp đưa lỗi vào hệ thống”. Than ôi, đầu tôi đã có kế hoạch riêng về vấn đề này và trong bài viết này, tôi sẽ cố gắng trả lời câu hỏi phổ biến nhất nảy sinh ở những người muốn tham gia vào lĩnh vực kỹ thuật hỗn loạn: Nên phá cái gì trước?
Câu hỏi tuyệt vời! Tuy nhiên, anh ấy dường như không đặc biệt bận tâm đến chú gấu trúc này...
Đừng gây rối với gấu trúc hỗn loạn!
Câu trả lời ngắn: Nhắm mục tiêu các dịch vụ quan trọng dọc theo đường dẫn yêu cầu.
Câu trả lời dài hơn nhưng rõ ràng hơn: Để hiểu nơi bắt đầu thử nghiệm sự hỗn loạn, hãy chú ý đến ba lĩnh vực:
- Nhìn vào lịch sử sự cố và xác định các mẫu;
- Quyết định về sự phụ thuộc quan trọng;
- Sử dụng cái gọi là hiệu ứng quá tự tin.
Thật buồn cười, nhưng phần này có thể dễ dàng được gọi là "Hành trình khám phá bản thân và giác ngộ". Trong đó chúng ta sẽ bắt đầu “chơi” với một số nhạc cụ hay.
1. Câu trả lời nằm ở quá khứ
Nếu bạn còn nhớ, ở phần đầu tiên tôi đã giới thiệu khái niệm Sửa lỗi (COE) - một phương pháp giúp chúng ta phân tích những sai sót của mình - những sai sót trong công nghệ, quy trình hoặc tổ chức - để hiểu (các) nguyên nhân của chúng và ngăn chặn chúng. tái phát trong tương lai. Nói chung, đây là nơi bạn nên bắt đầu.
“Muốn hiểu hiện tại thì phải biết quá khứ.” - Carl Sagan
Xem lịch sử các lỗi, gắn thẻ chúng trong COE hoặc các bản khám nghiệm tử thi và phân loại chúng. Xác định các mô hình phổ biến thường dẫn đến vấn đề và đối với mỗi COE, hãy tự hỏi mình câu hỏi sau:
“Điều này có thể được dự đoán trước và do đó được ngăn chặn bằng cách tiêm lỗi?”
Tôi nhớ một thất bại đầu tiên trong sự nghiệp của tôi. Nó có thể dễ dàng được ngăn chặn nếu chúng ta thực hiện một vài thí nghiệm hỗn loạn đơn giản:
Trong điều kiện bình thường, các phiên bản phụ trợ phản hồi việc kiểm tra tình trạng từ ). ELB sử dụng các bước kiểm tra này để chuyển hướng yêu cầu đến các phiên bản hoạt động tốt. Khi phát hiện một phiên bản “không tốt”, ELB sẽ ngừng gửi yêu cầu đến phiên bản đó. Một ngày nọ, sau một chiến dịch tiếp thị thành công, lưu lượng truy cập tăng lên và phần phụ trợ bắt đầu phản hồi việc kiểm tra tình trạng chậm hơn bình thường. Có thể nói, những cuộc kiểm tra sức khỏe này là , nghĩa là trạng thái của các phần phụ thuộc đã được kiểm tra.
Tuy nhiên, mọi thứ đều ổn trong một thời gian.
Sau đó, trong điều kiện khá căng thẳng, một trong các trường hợp bắt đầu thực thi một tác vụ cron ETL thông thường, không quan trọng. Sự kết hợp giữa lưu lượng truy cập cao và cronjob đã đẩy mức sử dụng CPU lên gần 100%. Quá tải CPU còn làm chậm phản hồi đối với các cuộc kiểm tra tình trạng, đến mức ELB quyết định rằng phiên bản đang gặp vấn đề về hiệu năng. Đúng như dự đoán, bộ cân bằng đã ngừng phân phối lưu lượng truy cập đến nó, điều này dẫn đến việc tăng tải cho các phiên bản còn lại trong nhóm.
Đột nhiên, tất cả các trường hợp khác cũng bắt đầu thất bại trong việc kiểm tra sức khỏe.
Việc bắt đầu một phiên bản mới yêu cầu phải tải xuống và cài đặt các gói, đồng thời mất nhiều thời gian hơn ELB để vô hiệu hóa chúng - từng gói một - trong nhóm tự động điều chỉnh quy mô. Rõ ràng là ngay sau đó toàn bộ quá trình đã đạt đến điểm tới hạn và ứng dụng bị lỗi.
Sau đó, chúng tôi mãi mãi hiểu những điểm sau:
- Việc cài đặt phần mềm khi tạo một phiên bản mới mất nhiều thời gian, tốt hơn là nên ưu tiên phương pháp bất biến và .
- Trong những tình huống khó khăn, nên ưu tiên các phản hồi về kiểm tra sức khỏe và ELB - điều cuối cùng bạn muốn là làm phức tạp cuộc sống cho những trường hợp còn lại.
- Bộ nhớ đệm cục bộ của kiểm tra tình trạng giúp ích rất nhiều (thậm chí trong vài giây).
- Trong tình huống khó khăn, không chạy các tác vụ cron và các quy trình không quan trọng khác - hãy tiết kiệm tài nguyên cho các tác vụ quan trọng nhất.
- Khi tự động điều chỉnh tỷ lệ, hãy sử dụng các phiên bản nhỏ hơn. Một nhóm 10 mẫu nhỏ tốt hơn một nhóm 4 mẫu lớn; nếu một trường hợp không thành công, trong trường hợp đầu tiên, 10% lưu lượng truy cập sẽ được phân bổ trên 9 điểm, trong trường hợp thứ hai - 25% lưu lượng truy cập trên ba điểm.
Vì vậy, liệu điều này có thể đoán trước được và do đó được ngăn chặn bằng cách đưa ra vấn đề không?
vâng, và theo nhiều cách.
Đầu tiên, bằng cách mô phỏng mức sử dụng CPU cao bằng các công cụ như hoặc :
❯ stress-ng --matrix 1 -t 60s
căng thẳng-ng
Thứ hai, bằng cách nạp chồng thể hiện với và các tiện ích tương tự khác:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Các thí nghiệm tương đối đơn giản nhưng có thể cung cấp một số kiến thức bổ ích để suy nghĩ mà không cần phải trải qua căng thẳng vì thất bại thực sự.
Nhưng đừng dừng lại ở đó. Hãy thử tái tạo sự cố trong môi trường thử nghiệm và kiểm tra câu trả lời của bạn cho câu hỏi "Liệu điều này có thể được thấy trước và do đó được ngăn chặn bằng cách đưa ra một lỗi không?" Đây là một thử nghiệm hỗn loạn nhỏ trong một thử nghiệm hỗn loạn để kiểm tra các giả định nhưng bắt đầu bằng một thất bại.
Đó là một giấc mơ, hay nó thực sự đã xảy ra?
Vì vậy hãy nghiên cứu lịch sử thất bại, phân tích EOC, gắn thẻ và phân loại chúng theo “bán kính tiếp cận”—hay chính xác hơn là số lượng khách hàng bị ảnh hưởng—rồi tìm kiếm các mẫu. Hãy tự hỏi liệu điều này có thể được dự đoán và ngăn chặn bằng cách đưa ra vấn đề hay không. Kiểm tra câu trả lời của bạn.
Sau đó chuyển sang các mẫu phổ biến nhất với phạm vi lớn nhất.
2. Xây dựng bản đồ phụ thuộc
Hãy dành một chút thời gian để suy nghĩ về ứng dụng của bạn. Có bản đồ rõ ràng về sự phụ thuộc của nó không? Bạn có biết họ sẽ có tác động gì nếu thất bại không?
Nếu bạn không quen với mã ứng dụng của mình hoặc mã quá lớn, bạn có thể khó hiểu mã đó làm gì và các phần phụ thuộc của nó là gì. Việc hiểu những phần phụ thuộc này và tác động có thể có của chúng đối với ứng dụng và người dùng là rất quan trọng để biết bắt đầu từ đâu với kỹ thuật hỗn loạn: điểm bắt đầu là thành phần có bán kính tác động lớn nhất.
Việc xác định và ghi lại các phụ thuộc được gọi là "xây dựng bản đồ phụ thuộc» (ánh xạ phụ thuộc). Điều này thường được thực hiện cho các ứng dụng có cơ sở mã lớn bằng cách sử dụng các công cụ định hình mã. (hồ sơ mã) và thiết bị đo đạc (thiết bị đo đạc). Bạn cũng có thể xây dựng bản đồ bằng cách giám sát lưu lượng mạng.
Tuy nhiên, không phải tất cả các phần phụ thuộc đều giống nhau (điều này càng làm phức tạp thêm quy trình). Một số phê bình, khác - sơ trung (ít nhất là về mặt lý thuyết, vì sự cố thường xảy ra do các vấn đề với phần phụ thuộc được coi là không nghiêm trọng).
Nếu không có sự phụ thuộc quan trọng, dịch vụ sẽ không thể hoạt động. Sự phụ thuộc không quan trọng "không nên» ảnh hưởng đến dịch vụ trong trường hợp bị ngã. Để hiểu các phần phụ thuộc, bạn cần hiểu rõ về các API được ứng dụng của bạn sử dụng. Điều này có thể khó khăn hơn nhiều so với vẻ ngoài của nó - ít nhất là đối với các ứng dụng lớn.
Bắt đầu bằng cách xem qua tất cả các API. Làm nổi bật nhất quan trọng và quan trọng... Lấy phụ thuộc từ kho lưu trữ mã, hãy kiểm tra nó nhật ký kết nối, sau đó xem tài liệu (tất nhiên, nếu nó tồn tại - nếu không bạn vẫn cóоvấn đề lớn hơn). Sử dụng các công cụ để hồ sơ và truy tìm, lọc các cuộc gọi bên ngoài.
Bạn có thể sử dụng các chương trình như netstat - tiện ích dòng lệnh hiển thị danh sách tất cả các kết nối mạng (ổ cắm hoạt động) trong hệ thống. Ví dụ: để liệt kê tất cả các kết nối hiện tại, hãy nhập:
❯ netstat -a | more
Trong AWS bạn có thể sử dụng (nhật ký luồng) VPC là phương pháp cho phép bạn thu thập thông tin về lưu lượng IP đến hoặc đi từ các giao diện mạng trong VPC. Những nhật ký như vậy cũng có thể trợ giúp thực hiện các tác vụ khác - ví dụ: tìm câu trả lời cho câu hỏi tại sao lưu lượng truy cập nhất định không đến được phiên bản.
Bạn cũng có thể dùng . X-Ray cho phép bạn có được hình ảnh chi tiết, "tối thượng" (từ đầu đến cuối) tổng quan về các yêu cầu khi chúng di chuyển qua ứng dụng, đồng thời xây dựng bản đồ các thành phần cơ bản của ứng dụng. Rất thuận tiện nếu bạn cần xác định các phụ thuộc.
Bảng điều khiển X-Ray của AWS
Bản đồ phụ thuộc mạng chỉ là giải pháp một phần. Có, nó hiển thị ứng dụng nào giao tiếp với ứng dụng nào, nhưng có những phần phụ thuộc khác.
Nhiều ứng dụng sử dụng DNS để kết nối với các phần phụ thuộc, trong khi những ứng dụng khác có thể sử dụng khám phá dịch vụ hoặc thậm chí địa chỉ IP được mã hóa cứng trong tệp cấu hình (ví dụ: /etc/hosts).
Ví dụ: bạn có thể tạo thông qua iptables và xem những gì bị hỏng. Để thực hiện việc này, hãy nhập lệnh sau:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
lỗ đen DNS
Nếu /etc/hosts hoặc các tệp cấu hình khác, bạn sẽ tìm thấy các địa chỉ IP mà bạn không biết gì về (vâng, thật không may, điều này cũng xảy ra), bạn có thể đến giải cứu lần nữa iptables. Giả sử bạn đã phát hiện ra 8.8.8.8 và không biết rằng đây là địa chỉ máy chủ DNS công cộng của Google. Bằng cách sử dụng iptables Bạn có thể chặn lưu lượng truy cập đến và đi đến địa chỉ này bằng các lệnh sau:
❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
Đóng quyền truy cập
Quy tắc đầu tiên loại bỏ tất cả các gói khỏi DNS công cộng của Google: ping hoạt động, nhưng các gói không được trả lại. Quy tắc thứ hai loại bỏ tất cả các gói có nguồn gốc từ hệ thống của bạn tới DNS công cộng của Google - để đáp lại ping chúng tôi nhận được Hoạt động không phép.
Lưu ý: trong trường hợp cụ thể này sẽ tốt hơn nếu sử dụng whois 8.8.8.8, nhưng đây chỉ là một ví dụ.
Chúng ta thậm chí có thể đi sâu hơn vào hố thỏ, bởi vì mọi thứ sử dụng TCP và UDP thực sự cũng phụ thuộc vào IP. Trong hầu hết các trường hợp, IP được gắn với ARP. Đừng quên tường lửa...
Nếu bạn uống viên thuốc màu đỏ, bạn sẽ ở lại Xứ sở thần tiên và tôi sẽ cho bạn biết hang thỏ sâu đến mức nào."
Một cách tiếp cận triệt để hơn là tắt từng chiếc ô tô và xem cái gì bị hỏng... trở thành một "con khỉ hỗn loạn". Tất nhiên, nhiều hệ thống sản xuất không được thiết kế cho một cuộc tấn công bạo lực như vậy, nhưng ít nhất nó có thể được thử trong môi trường thử nghiệm.
Xây dựng bản đồ phụ thuộc thường là một công việc rất dài. Gần đây tôi đã nói chuyện với một khách hàng đã dành gần 2 năm để phát triển một công cụ tạo bản đồ phụ thuộc bán tự động cho hàng trăm vi dịch vụ và lệnh.
Tuy nhiên, kết quả lại cực kỳ thú vị và hữu ích. Bạn sẽ học được nhiều điều về hệ thống của mình, các phụ thuộc và hoạt động của nó. Một lần nữa, hãy kiên nhẫn: chính cuộc hành trình mới là điều quan trọng nhất.
3. Cẩn thận với sự tự tin thái quá
“Ai mơ ước điều gì thì hãy tin vào điều đó.” — Demosthenes
Bạn đã bao giờ nghe nói về hiệu ứng quá tự tin?
Theo Wikipedia, hiệu ứng tự tin thái quá là “thành kiến nhận thức trong đó sự tự tin của một người vào hành động và quyết định của họ lớn hơn đáng kể so với độ chính xác khách quan của những phán đoán đó, đặc biệt là khi mức độ tự tin tương đối cao”.
Dựa vào bản năng và kinh nghiệm...
Theo kinh nghiệm của tôi, sự biến dạng này là một gợi ý tuyệt vời về nơi bắt đầu với kỹ thuật hỗn loạn.
Hãy cẩn thận với người điều hành quá tự tin:
Charlie: "Thứ này đã không rơi trong 5 năm rồi, mọi thứ vẫn ổn!"
Crash: “Đợi đã… Tôi sẽ đến đó sớm thôi!”
Thành kiến do sự tự tin thái quá là một điều ngấm ngầm và thậm chí nguy hiểm do có nhiều yếu tố khác nhau ảnh hưởng đến nó. Điều này đặc biệt đúng khi các thành viên trong nhóm đã dồn tâm huyết vào một công nghệ hoặc dành nhiều thời gian để “sửa chữa” nó.
Tổng hợp
Việc tìm kiếm điểm khởi đầu cho kỹ thuật hỗn loạn luôn mang lại nhiều kết quả hơn mong đợi và các nhóm bắt đầu phá vỡ mọi thứ quá nhanh sẽ đánh mất bản chất toàn cầu và thú vị hơn của (hỗn loạn-)kỹ thuật - sử dụng sáng tạo Phương pháp khoa học и bằng chứng thực nghiệm để thiết kế, phát triển, vận hành, bảo trì và cải tiến hệ thống (phần mềm).
Điều này kết thúc phần thứ hai. Hãy viết đánh giá, chia sẻ ý kiến hoặc chỉ cần vỗ tay . Ở phần tiếp theo tôi thực sự Tôi sẽ xem xét các công cụ và phương pháp đưa lỗi vào hệ thống. Cho đến khi!
Tái bút từ người dịch
Đọc thêm trên blog của chúng tôi:
- «»;
- «»;
- «»;
- «'.
Nguồn: www.habr.com