Всем привет! Это моя первая статья в пространстве хабра, и на написание данной статьи меня сподвигли недавние проблемы в гигантах it индустрии. Пересказывать произошедшее я не буду, но вот кое-какие выводы из это сделать можно.
Как показала практика от сбоев в IT системах никто не застрахован, даже у мамонтов индустрии. А убытки от простоев, после таких событий, достигают заоблачных цифр. К примеру, простои от последних событий для Facebook обошлись в миллиарды долларов.
Сбои неизбежны – это факт, но когда – это вопрос. Компаниям нужны решения здесь и сейчас, и эти решения предлагает молодое направление в IT – Chaos Enginering. Материала на данную тематику уже написано не мало, но очень мало в русскоязычных сообществах, их можно по пальцам перечитать. В рамках данной статьи я хочу поделиться своим опытом Chaos Enginering, так сказать простыми русскими словами.
Так случилось, что я попал в число первопроходцев по Chaos Enginering в России, и поверти на слово - «не так страшен черт, как его малюют», но всё же есть подводные камни.
Кому интересна история зарождения Chaos, на habr есть отличная статья-перевод, первая часть здесь. А я в свою очередь не буду ходить вокруг да около и начну прямо с примеров.
Основа направления Chaos Enginering - что-то специально сломать, имитируя события из реальной жизни, чтоб посмотреть, что произойдёт и как ваши системы с этим справятся.
Представите обычный интернет-магазин на микро-сервисах. Микро-сервис Б возвращает какое-либо свойство по товару. Микро-сервис А взаимодействует с микро-сервисом Б, и обрабатывает получаемые значения. Микро-сервисы находятся на разных серверах/облаках. Так вот сеть в этом всём организме является оптимальным звеном для наших экспериментов с хаосом.
Chaos Engineering делится на простые этапы:
Теперь давайте пройдемся по этим этапам на примере нашего магазина
1) Так как это магазин, то стабильная метрика кол-во продаж на единицу времени, вроде логично. Замеряем и получаем 10 продаж в минуту, это стабильное состоянии. (гипотетическая закадровая нагрузка где-то там присудствует)
2) Придумываем гипотезу. Наши микросерсвисы находятся в разных местах, и общаются через сеть, то логично отключить сеть между микросервисами или отключить один из микросервисов и посмотреть, что будет с нашим магазином. Я понимаю, что сейчас это звучит глупо, и если вы с этой идей пойдете к своим руководителям или клиентам, вас поднимут на смех, со словами, у нас есть реплики, балансеры и так далее. Но в этом и один из смыслов chaos engineering, проверить, так ли хороши системы HA на практике.
3) Так как мы не можем отключить сеть или как-то повлиять на неё (можем, но речь сейчас не об этом), мы просто запланировали отключение сервера/облака.
4) Замеряем кол-во продаж и что мы видим, а видим мы 0 (нуль). Магазин не работает.
5) Разбираемся почему это случилось и как исправить.
В ходе разбирательства оказалось, что java http клиент в миросервисе А не обрабатывал исключения таймаута и/или connection reset, обработка строилась только на http кодах 200-500. Исправили, починили, запустили сервисы и повторно провели эксперимент. Ура! Всё прошло удачно. Данный эксперимент можно поставить на поток в пострелизное время.
Да, пример весьма глупый, но он раскрывает суть Chaos Engineering. Любая и даже самая глупая гипотеза моделирования «реальных сбоев» должна быть поэкспериментировала в рамках вашей системы IT, особенно это касается сетей.
Теперь давайте подумаем, как вам строить системы хаоса в ваших компания, и что может пригодиться в этом не легком поприще.
Запомните одно из правил - Нельзя просто открыть поисковик, напечатать «хаос инженеринг, скачать без смс и регистрации» и запускать на ваших ресурсах всё что вы найдете. Оно так не работает и работает вообще не так.
В первую очередь, хаос должен быть целенаправленный и спланированный. Вы должны понимать, что вы собираетесь ломать, когда вы собираетесь ломать, как вы это будете ломать, и самое главное, как наблюдать, что происходит с вашей системой, когда вы её ломаете. Разрушения без замеров – не даст вам понимания, что произошло, соответственно вы не поймете как исправить.
В пространстве интернета, по поиску Chaos Enginering вы наверняка найдете ссылки содержащие слова: Chaos monkey, gremlin, chaos mesh, litmus, pumba, chaos toolkit и многие другие. Некоторые из них вы не сможете даже реализовать под свои нужны, но большую часть, я вам не советую даже запускать. В лучшем случае вы не получите результатов, в худшем вы обрушите ваши сервера, после чего разочаруетесь в данном направлении и прибегните к старому дедовскому НТ.
Chaos Enginering должен строится под конкретную компанию, под конкретное направление в компании или под отдельно взятый проект. Выстраивать его надо обдуманно, начиная с локальных разрушений.
Начните с самого простого. Допустим, используйте утилиту stress-ng. Нагрузите процессор на сервере приложений до 100% и проверяйте как это отобразится на работе основного приложения и какие тайминги будут доступны, время запросов и ответов
Пример команды для 4 ядер: stress-ng --cpu 4 -v --timeout 30s
Удачные эксперименты будут внушать доверие, и с подвигать вас на более сложные решения, в итоге проводя эксперименты в production среде, ведь конечная цель Chaos Enginering – это production системы.
Инструментов для хаоса много, некоторые из них я уже перечислил выше, но все они делятся на 4 основные группы сбоев приложения: вычислительные ресурсы, сеть, хранилище, инфраструктура.
Вернёмся к нашему интернет магазину, чтоб провести эксперимент по отключению сервера (группа сбоев инфраструктура), не обязательно скачивать что-то необычное, наверняка у вас есть ansible. С помощью не сложных усилий можно организовать отключение случайного сервера:
- name: "Вычисляем жертву"
host: localhost
tasks:
- set_fact:
random_server: "{{ server_list | random | json_query('name') }}"
- name: "Отключаем жертву :)"
host: {{ random_server }}
tasks:
- shell: poweroff
when: random_server is defineСобственно, правильно дописав этот playbook под ваши нужны, это уже будет второй эксперимент в вашей библиотеке хаоса, который вы можете использовать.
На текущий момент я разрабатываю свои архитектуры Chaos Enginering способные работать с платформами k8s, openshift, docker, и с классическими bare-metal. Добавлены возможности в автоматическом режиме собирать метрики с систем мониторинга (Zabbix, Prometheus), запускать и останавливать инструменты «разрушения», формировать отчеты проведённого эксперимента.
Если тематика интересна, то в следующих статьях я постараюсь подробно рассматриваться, тестировать и описывать различные инструменты хаоса, предоставленных на рынке.
Спасибо за внимание.
