Прим. перев.: Цей матеріал продовжує чудовий цикл статей від технологічного євангеліста з AWS - Adrian Hornsby, - який задався метою просто і зрозуміло пояснити важливість експериментів, покликаних пом'якшити наслідки збоїв в ІТ-системах.
"Якщо провалив підготовку плану, то плануєш провал". - Бенджамін Франклін
В даної серії статей я представив концепцію chaos engineering'а і пояснив, як він допомагає знаходити та виправляти вади в системі до того, як вони призведуть до збоїв production. Також було розказано про те, як хаос-інжиніринг сприяє позитивним культурним змінам усередині організацій.
Наприкінці першої частини я пообіцяв розповісти про «інструменти та способи впровадження збоїв у системи». На жаль, у моєї голови щодо цього були власні плани, і в цій статті я спробую відповісти на найпопулярніше питання, що виникає і людей, які бажають зайнятися хаос-інжинірингом: Що ламати насамперед?
Чудове питання! Втім, цю панду він, схоже, не турбує.
Не зв'язуйтесь із хаос-пандою!
Коротка відповідь: Цільтесь у критичні сервіси на шляху запиту
Довга, але більш зрозуміла відповідь: Щоб зрозуміти, з чого слід починати експерименти з хаосом, зверніть увагу на три області:
- Подивіться на історію збоїв та виявите закономірності;
- Визначтеся критичними залежностями;
- Скористайтеся т.з. ефектом надвпевненості.
Смішно, але цю частину з тим самим успіхом можна було назвати «Подорож до самопізнання та освіти». У ній ми почнемо «грати» з деякими прикольними інструментами.
1. Відповідь лежить у минулому
Якщо пам'ятаєте, у першій частині я ввів поняття Correction-of-Errors (COE) — методу, за допомогою якого ми аналізуємо наші промахи: промахи в технології, процесі чи організації — щоб зрозуміти їхню причину(и) і запобігти повторенню в майбутньому . Загалом, з цього слід починати.
«Щоб зрозуміти сьогодення, треба знати минуле». - Карл Саган
Подивіться на історію збоїв, проставте теги в ШОЄ або postmortem'ах і класифікуйте їх. Виявіть загальні закономірності, які часто призводять до проблем, і для кожного ЗОЄ поставте собі таке запитання:
«Чи можна було передбачити, а отже, запобігти за допомогою впровадження несправності?»
Я згадую один збій на самому початку моєї кар'єри. Його можна було б легко запобігти, якби ми провели пару найпростіших хаос-експериментів:
У нормальних умовах екземпляри backend'а відповідають на health check'і від ). ELB використовує ці перевірки для перенаправлення запитів на здорові екземпляри. Коли виявляється, що якийсь екземпляр «нездоровий», ELB перестає надсилати на нього запити. Одного разу, після успішної маркетингової кампанії, обсяг трафіку виріс, і backend'и почали відповідати на health check'і повільніше, ніж зазвичай. Слід сказати, що ці health check'і були , тобто проводилася перевірка стану залежностей.
Тим не менш, деякий час все було гаразд.
Потім, вже перебуваючи в досить напружених умовах, один із екземплярів приступив до виконання некритичної, регулярної cron-завдання з розряду ETL. Комбінація високого трафіку і cronjob'а спонукала завантаження ЦПУ майже на 100%. Перевантаження процесора ще сильніше уповільнило відповіді на health check'і — настільки, що ELB вирішив, що екземпляр має проблеми в роботі. Як і очікувалося, балансувальник перестав розподіляти трафік на нього, що, своєю чергою, призвело до зростання навантаження на інші екземпляри у групі.
Несподівано всі інші екземпляри також почали провалювати health check.
Запуск нового екземпляра вимагав завантаження та встановлення пакетів і займав набагато більше часу, ніж вимагалося ELB на їхнє відключення — одного за іншим — у групі автомасштабування. Зрозуміло, що незабаром весь процес досяг критичної позначки і програма впала.
Тоді ми назавжди усвідомили такі моменти:
- Встановлювати ПЗ при створенні нового екземпляра довго, краще віддати перевагу незмінному (immutable) підходу та .
- У складних ситуаціях відповіді на health-check'і ELB повинні мати пріоритет — найменше ви хочете ускладнити життя екземплярам, що залишилися.
- Добре допомагає локальне кешування health-check'ів (навіть кілька секунд).
- У складній ситуації не запускайте cron-завдання та інші некритичні процеси – бережіть ресурси для найважливіших завдань.
- Під час автомасштабування використовуйте менші за розміром екземпляри. Група з 10 малих екземплярів краще, ніж із 4 великих; якщо один екземпляр впаде, у першому випадку 10% трафіку розподіляться по 9 точках, у другому - 25% трафіку за трьома точками.
Отже, чи можна це було передбачити, а отже — запобігти за допомогою впровадження проблеми?
Так, та кількома способами.
По-перше, імітацією високого завантаження CPU за допомогою таких інструментів, як або :
❯ stress-ng --matrix 1 -t 60s
стрес
По-друге, перевантаженням екземпляра за допомогою та інших схожих утиліт:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Експерименти порівняно прості, але можуть дати непогану їжу для роздумів без потреби переживати стрес реального збою.
Однак не зупиняйтесь на досягнутому. Спробуйте відтворити збій у тестовому середовищі та перевірити свою відповідь на запитання «Чи це можна було передбачити, а отже — запобігти за допомогою впровадження несправності?». Це міні-хаос-експеримент всередині хаос-експерименту для перевірки припущень, але починаючи зі збою.
То був сон, чи все трапилося насправді?
Тож вивчайте історію збоїв, аналізуйте Коефіцит, тегуйте та класифікуйте їх за «радіусом поразки» — або, точніше, за кількістю порушених клієнтів, — а потім шукайте закономірності. Запитуйте себе, чи це можна було передбачити і запобігти шляхом впровадження проблеми. Перевіряйте свою відповідь.
Потім перемикайтеся на найпоширеніші патерни з найбільшим радіусом ураження.
2. Побудуйте карту залежностей
Виберіть хвилинку, щоб подумати про свою програму. Чи є чітка карта його залежностей? Чи знаєте ви, який вплив вони вплинуть у разі збою?
Якщо ви не дуже добре знайомі з кодом свого додатка або він став занадто великим, може бути важко зрозуміти, що робить код і які його залежності. Розуміння цих залежностей та їх можливого впливу на додаток та користувачів є критично важливим для уявлення про те, з чого почати хаос-інжиніринг: відправною точкою буде виступати компонент з найбільшим радіусом ураження.
Виявлення та документування залежностей називають «побудовою карти залежностей» (dependency mapping). Зазвичай воно проводиться для програм з великою базою коду з використанням інструментів для профілювання коду (code profiling) та інструментування (instrumentation). Також можна проводити побудову карти, відстежуючи мережевий трафік.
При цьому не всі залежності однакові (що ще більше ускладнює процес). Деякі критично важливі, інші - другорядні (принаймні теоретично, оскільки збої часто виникають через проблеми із залежностями, які вважалися некритичними).
Без критичної залежності сервіс не може працювати. Некритичні залежності «не повинні» Надавати впливу на сервіс у разі свого падіння. Щоб розібратися із залежностями, необхідно мати чітке уявлення про API, що використовуються програмою. Це може бути набагато складніше, ніж здається, принаймні для великих додатків.
Почніть із перебору всіх API. Виділіть самі значущі та критичні. Візьміть залежно з репозиторію коду, вивчіть логи підключеньпотім перегляньте документацію (Звичайно, якщо вона існує - інакше у вас ще больші проблеми). Задіяти інструменти для профілювання та трасування, відфільтруйте зовнішні дзвінки.
Можна скористатися програмами на зразок netstat - Утиліта командного рядка, яка виводить список всіх мережевих підключень (активних сокетів) в системі. Наприклад, щоб вивести всі поточні з'єднання, наберіть:
❯ netstat -a | more
В AWS можна використовувати (flow logs) VPC - метод, що дозволяє зібрати інформацію про IP-трафік, що йде до мережевих інтерфейсів у VPC або від них. Такі логи здатні допомогти і з іншими завданнями, наприклад, з пошуком відповіді на питання, чому певний трафік не досягає екземпляра.
Також можна використовувати . X-Ray дозволяє отримати докладний, кінцевий (кінець в кінець) огляд запитів у міру їх просування за програмою, а також будує карту базових компонентів програми. Дуже зручно, якщо потрібно виявити залежність.
Консоль AWS X-Ray
Карта мережевих залежностей – лише часткове рішення. Так, вона показує, який додаток з яким зв'язується, але є й інші залежності.
Багато програм використовують DNS для підключення до залежностей, у той час як інші можуть використовувати механізм виявлення сервісів або навіть жорстко прописані IP-адреси в конфігураційних файлах (наприклад, в /etc/hosts).
Наприклад, можна створити за допомогою iptables і подивитися, що зламається. Для цього введіть наступну команду:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
"Чорна діра" DNS
Якщо в /etc/hosts або інших конфігураційних файлах ви виявите IP-адреси, про які нічого не знаєте (так, на жаль, і таке буває), на виручку знову може прийти iptables. Скажімо, ви виявили 8.8.8.8 і не знаєте, що це адреса загальнодоступного сервера DNS Google. За допомогою iptables можна закрити вхідний та вихідний трафік до цієї адреси за допомогою наступних команд:
❯ 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"
Закриття доступу
Перше правило відкидає всі пакети з публічного DNS Google: ping працює, але пакети не повертаються. Друге правило відкидає всі пакети, що виходять з вашої системи у напрямку публічного DNS Google — у відповідь ping отримуємо Операція не допускається.
Примітка: у цьому випадку було б краще використовувати whois 8.8.8.8, але це лише приклад.
Можна забратися ще глибше в кролячу нору, оскільки все, що використовує TCP та UDP, насправді залежить і від IP. Найчастіше IP зав'язаний на ARP. Не варто забувати і про firewall'ах.
Вибереш червону пігулку — залишишся в Країні Чудес, і я покажу, наскільки глибоко йде кроляча нора»
Більш радикальний підхід у тому, щоб відключати машини одну за одною і дивитися, що зламалося… станьте «мавпою хаосу». Звичайно, багато production-систем не розраховані на подібну грубу атаку, але принаймні її можна спробувати в тестовому середовищі.
Побудова карти залежностей часто дуже довгий захід. Нещодавно я розмовляв із клієнтом, що витратив майже 2 роки на розробку інструменту, який у напівавтоматичному режимі генерує карти залежностей для сотень мікросервісів та команд.
Результат, однак, надзвичайно цікавий та корисний. Ви дізнаєтеся багато нового про свою систему, її залежності і операції. Знову ж таки, будьте терплячі: найбільше значення має сама подорож.
3. Остерігайтесь самовпевненості
«Хто про що мріє, той у те й вірить». - Демосфен
Ви коли-небудь чули про ефект надвпевненості?
Згідно з Вікіпедією, ефект надвпевненості — це «когнітивне спотворення, при якому впевненість людини у своїх діях і рішеннях значно вища, ніж об'єктивна точність цих суджень, особливо коли рівень впевненості відносно високий».
Грунтуючись на чуття та досвіді…
З власного досвіду можу сказати, що це спотворення — чудовий натяк на те, з чого слід починати хаос-інжиніринг.
Остерігайтесь самовпевненого оператора:
Чарлі: "Ця штука не падала років п'ять, все в нормі!"
Збій: «Чекайте… скоро буду!»
Упередженість як наслідок самовпевненості — річ підступна і навіть небезпечна через різні фактори, що впливають на неї. Це особливо справедливо, коли члени команди вклали душу в якусь технологію або витратили багато часу на «виправлення».
Підводжу підсумки
Пошуки відправної точки для хаос-інжинірингу завжди приносять більше результатів, ніж очікувалося, і команди, які починають надто швидко ламати все навколо, упускають з уваги більш глобальну та цікаву суть (хаос-)інжинірингу - Творче застосування наукових методів и емпіричних доказів для проектування, розробки, експлуатації, обслуговування та вдосконалення (програмних) систем.
На цьому друга частина добігає кінця. Будь ласка, пишіть відгуки, ділитесь думками або просто плескайте в долоні на . У наступній частині я дійсно розгляну інструменти та методи щодо впровадження збоїв у системи. Доти поки!
PS від перекладача
Читайте також у нашому блозі:
- «»;
- «»;
- «»;
- «».
Джерело: habr.com