Хаос-инжиниринг или революция в создании устойчивых систем
Примечание:
Материал будет полезен любому инженеру работающему со сложными вычислительными системами. Формирует системное мышление и развивает правильный подход к созданию и сопровождению комплексных систем.
Небольшое знакомство с дисциплиной перед тем как поведаю кейс в котором описанные ниже подходы помогли решить проблему.
Итак…
Хаос-инжиниринг - проведение организованных экспериментов с целью выявления системных недостатков.
Определение авторов этого нового направления Кейси Розенталя и Норы Джонсон.
Основные принципы хаос-инжиниринга:
- Начните с определения “устойчивого состояния” как некоторого измеримого результата системы, указывающего на нормальное поведение;
- Выдвиньте гипотезу, что это устойчивое состояние сохранится как для контрольной группы, так и для экспериментальной;
- Введите переменные факторы, которые отражают реальные события, такие как сбой серверов, сбой жестких дисков, разрыв сетевых подключений и т.п.;
- Попытайтесь опровергнуть гипотезу, находя разницу в установившемся состоянии между контрольной группой и экспериментальной.
Я бы назвал хаос-инжиниринг эдакой теорией надежности, которую мы так или иначе изучали, но эта новая дисциплина, развиваемая представителями топовых зарубежных компаний таких как Google, Netflix, AWS, Microsoft, Visa, Facebook и др. это адаптация всех накопленных инженерных знаний к современным информационным системам.
Наверняка вы слышали такое понятие как тестирование? А чем тестирование отличается от экспериментов? Многие скажут, что это все термины, описывающие одно и тоже. Но нет, между ними колоссальная разница. Я расскажу в чем она заключается, а потом приведу пример из жизни где это понимание решило проблему.
Самое главное отличие в том, что тестирование не создает новых знаний об исследуемой(эксплуатируемой) системе. Тестирование предполагает, чтобы инженер, пишущий тест, заранее знал конкретные свойства системы, которые тот ищет. Ограничение тестирования в том, что сложные(комплексные) системы не прозрачны для такого типа анализа. Люди по своей природе не могут соединить в своей голове все потенциальные побочные эффекты от всех возможных взаимодействий частей в сложной системе. Тесты выдвигают утверждение, основанное на существующих знаниях, затем запуск теста сводит утверждение к истинному или ложному значению.
Эксперименты, напротив, создают новые знания о системе. Эксперименты предлагают гипотезу и до тех пор пока пока она не опровергнута, доверия к этой гипотезе возрастает. Если гипотеза будет опровергнута, то мы получим новое знание. Главная задача экспериментов укрепить наше доверие к системе, либо получить новые знания о неочевидных свойствах своей системы.
Итак, разобравшись немного в том где пролегает водораздел между этими понятиями расскажу как это может выглядеть на практике.
Реальный случай:
Мы стояли на пороге внесения изменений в сетевую связность и порядок разрешения сетевых имен ресурсов для большого количества VPN пользователей (клиентов). Это были тысячи пользователей и сотни компаний. Все необходимые настройки были выполнены с нашей стороны, были проведены тесты. Тесты предусматривали применение новых политик к выделенной группе VPN пользователей о которых у нас была вся информация. Этими пользователями были мы сами) Все необходимые тесты прошли успешно. У нас на руках были рекомендации для VPN пользователей относительно тех параметров и свойств которые влияли на работоспособность клиентского ПО после внесения изменений. Эти рекомендации формировались нашим опытом, известными свойствами используемого ПО, знаниями применяемых протоколов. И каково было наше удивление, когда появилось понимание, что у 2 из 10 пользователей после выполнения всех рекомендаций клиентское ПО не работоспособно. Раз за разом на клиентской стороне проводились тесты. Серверное ПО утверждало, что политика применена к клиенту, но по тестам было видно, что клиент работает по старому и как результат отсутствие доступа к важным сервисам. Поток недовольных нарастал, телефоны обрывались, эмоции накалялись.
Отступление:
В такие моменты важно не скатиться в эмоции и скандалы. В чатах начинается поиск виноватых, предложения все срочно откатить, рождаются неэффективные предложения ведущие еще к большим проблемам и неразберихе. В такие моменты руководители среднего звена раскрываются. Одни разводят панику и кидают в чат инженеров скрины писем разгневанных пользователей подогревая и без того напряженную ситуацию, другие же формируют стену между пользователями и инженерам, чтобы последние могли без эмоций искать выход из ситуации. Это эффективно и это логично. Не зря когда ищут менеджера одним из критериев является стрессоустойчивость. Я заметил следующее: если менеджер, управляющий инженерами сам был инженером, то он понимает как себя вести эффективно в подобной ситуации, тому же кто не был сам инженером эту мудрость сходу не понять.
Мораль:
- Не обижайтесь на начальника, который как-будто устранился - скорее всего он просто старается не мешать своими бесполезными в момент истины вопросами. Скорее всего это признак опыта и осознанности;
- Если ваш или смежный руководитель разводит панику и поступает не мудро не спешите его прилюдно ругать. Скорее всего он не опытен, постарайтесь в мягкой форме коллективно донести свой дискомфорт. Если вопрос действительно был в отсутствии опыта, то в будущем скорее всего будет полегче. Ну а если вопрос не в опыте, а в стиле, то у меня для вас плохие новости :)
Что же было дальше?
А дальше было понимание, что пора самим или руками вендора копнуть поглубже - поэкспериментировать.
Тесты помогли большинству, но не всем - пришло время выдвигать гипотезы и проверять их через эксперименты.
Когда мы экспериментируем с штатно работающей системой и хотим проверить надежность, то мы строим гипотезу вида:
В ситуации ________ клиенты все еще остаются довольны;
Для экспериментов в попытках устранить проблему гипотеза выглядит так:
Если сделать ________, то проблема будет разрешена.
Составляется список того, что можно сделать. Этот список должен быть как-то связан с теми участками (модулями), которые подвергались изменениям. В нашем случае это была политика туннелирования и разрешения имен по новому. Политика, при наличии туннеля распространялась удаленно, при отсутствии канала могла досылаться файлом и вручную инсталлироваться. Т.е. изменения касались той части ПО которая принимает и применяет политику. Напомню, что дослав политику удаленно у 2 из 10 не заработало. Список при вдумчивом анализе должен включать в себя попытку ручной установки политики.
И это действительно помогло. Это был не тест, а эксперимент. И мы получили новое знание - если на проблемном хосте в ручную установить политику, то все заработает. На этом можно было бы и остановиться, но мы узнали как устранить проблему, но не получили ответ на вопрос почему так случилось. В одной и той же организации, на одной и той же инфраструктуре были как те у кого все сразу заработало так и те у кого начались проблемы. Если не разобраться в корне проблемы, то мы могли бы получить аналогичную проблему в следующий раз - логично же) Было логично, что есть какая-то аномалия, сложно воспроизводимая и неуловимая. В таких случаях требуется терпение и очень помогают журналы логов и всевозможные трассировки, дампы трафика. После непродолжительных наблюдений и анализа была зафиксирована странная ситуация. В журналах пакетов то и дело у одного номера клиента то и дело менялся реальный IP адрес хоста, виртуальный при этом оставался одним и тем же. При чем это происходило плюс-минус в одно и тоже время. IP у хоста меняется каждую секунду? Странная ситуация! Опять пришло время выдвигать гипотезы. На самом деле тут приходит одна и наиболее вероятная версия. Политика предусматривает идентификацию клиента по виртуальному IP. Было почти очевидно, что недобросовестные администраторы либо по незнанию, либо по лени инициализировали одной политикой разные хосты в своей инфраструктуре. Вот теперь было понятно как лечить проблему, почему так случилось, а ответом на гневное письмо пользователя могло стать уведомление об ответственности его Генерального директора об неправомерном использовании одной лицензии на нескольких единицах техники, а также о компрометации ключевой информации.
Выводы:
- Тесты и эксперименты - не одно и тоже. Там где не помогают тесты, начинайте строить гипотезы и проверяйте их через эксперименты;
- Найдя как лечить (в случае траблшутинге) или что приводит систему в нештатное состояние при проверках на надежность продолжайте пока не найдете корневую причину. Знание причин помогут не только временно, что-то вылечить или понимать где слабое место, но и не допустить возникновения в будущем аналогичной проблемы или устранить слабое место;
- Стремитесь попадать в подчинение к тем кто был в вашей “шкуре”. А если сложилось так, что не вы выбираете, то не спешите конфликтовать, постарайтесь найти компромисс. Если компромисс не достигается и вам уже край, то ищите новое место и читайте первое предложение этого пункта.)
Если интересна тематика хаос-инжиниринга ставьте лайки буду делиться этой темой.
Всем успехов, устойчивой инфраструктуры и мудрых руководителей!
