Защита бизнеса с помощью хаотического тестирования
Вы переносите свою базу данных. На этот процесс ушли месяцы, сотни часов ушли на создание конвейера совместимости, десятки разработчиков вручную проверяли данные, собирались по выходным, чтобы успеть к сроку. И вот во время миграции скачок напряжения выводит систему из строя...
Никто не мог этого предвидеть, но такая незначительная оплошность может сорвать весь проект или, что еще хуже, нанести непоправимый ущерб базе данных.
Человек создан для того, чтобы с опаской относиться к будущему, это биологический инструмент, призванный сохранить нам жизнь перед лицом нового опыта. Но даже в этом случае мы редко, если вообще когда-либо, склонны думать о худшем сценарии.
Маловероятное не является невозможным
Один мой друг в шутку говорит: "Когда ты выходишь в прямой эфир, вопрос не в том, взорвется ли он? Скорее, какого цвета будет взрыв?". Шутки шутками, но в его словах есть доля правды.
Среды разработки часто пытаются воссоздать производственные среды как можно ближе к реальности или наоборот. К сожалению, компьютерные системы крайне неустойчивы, поэтому даже самое незначительное расхождение может иметь далеко идущие последствия, и это только вершина айсберга.
Системы выходят из строя, интернет-соединения работают с задержками, серверы падают, жесткие диски выходят из строя, данные повреждаются. Все это случается, и иногда мы практически не можем контролировать, когда и как это происходит. Помните, как в 2011 году сотни пользователей потеряли свои данные из-за сбоя AWS?
Может ли такое повториться? Нет, но возможно ли это? Да, и именно по этой причине инженеры всегда занимаются разработкой отказоустойчивых систем. Если бы NASA не разработало отказоустойчивую систему, Apollo 11 потерпел бы крушение на Луне из-за компьютерной ошибки.
Код ошибки "Аполлона" 1202 означал, что бортовой компьютер был перегружен задачами. К счастью, программисты NASA предвидели такую возможность и создали резервную систему, которая быстро перезагружала компьютер и освобождала память для новых вычислений.
Минимизация времени восстановления
История высадки на Луну является ярким примером того, что современные инженеры называют MTTR - минимизация времени восстановления после сбоя. Если катастрофы не избежать, то наше решение - минимизировать время, необходимое для восстановления работоспособности систем.
Представим себе, что у вас есть два конкурирующих предприятия, корпорация А испытывает несколько сбоев в работе систем в течение дня, а корпорация Б - один единственный сбой. Без всякой дополнительной информации каждый хотел бы быть корпорацией B.
Но, допустим, MTTR (среднее время восстановления) корпорации A составляет около 20 секунд, а корпорации B - от 4 до 6 часов. Если бы у корпорации А было 20 сбоев в течение дня, то общее время простоя составило бы от 6 до 10 минут. Неожиданно частота перебоев в работе системы кажется гораздо менее важной.
Как же минимизировать время восстановления? Прежде всего, нужно целенаправленно вывести систему из строя. Это называется контролируемым отказом. Хотя это может показаться нелогичным, если задуматься, то в этом появляется большой смысл.
При контролируемом сбое объявляется дата и время, когда система выйдет из строя, сам сбой не раскрывается, поэтому команде необходимо как можно быстрее диагностировать проблему и восстановить работоспособность системы.
В это время мы проводим мониторинг системных данных до, во время и после сбоя. Это делается не только для того, чтобы помочь в восстановлении системы, но и для того, чтобы получить данные для последующего анализа и совершенствования.
Подобные упражнения открывают путь к новым знаниям, поскольку команда обнаруживает влияние неожиданных недостатков в системе. Это смена точки зрения через шоковую терапию, когда внезапно отказоустойчивая система показывает, насколько она хрупка.
Благодаря полученным в ходе таких упражнений знаниям можно разрабатывать новые процедуры с более четким пониманием их недостатков. Несмотря на то, что упражнение может быть стрессовым, результат его более чем достоин. И, честно говоря, это может быть одним из самых интеллектуально сложных упражнений для команды разработчиков.
Введение в хаотическое тестирование
Упражнения с контролируемыми отказами - это лишь вершина айсберга и базовое введение в жизненный цикл тестирования/хаотическую инженерию. По своей сути хаотическое тестирование - это просто создание возможности постоянно, но случайным образом вызывать сбои в производственной системе.
Хаотическая инженерия была основной стратегией гиганта потокового вещания Netflix. Команда инженеров располагала широким набором "хаотических обезьян" или потенциальных сбоев, которые могли возникнуть в любую минуту, начиная от задержки и заканчивая всемирным отключением Amazon Web Services.
Эти хаотические сбои, в свою очередь, заставляют вашу команду перейти от оборонительной разработки к более агрессивному подходу. Точнее говоря, это метод развития отказоустойчивости системы и самой команды.
Устойчивая система обладает гибкостью, позволяющей адаптироваться к катастрофическим обстоятельствам, например, потоковая платформа, которая перенаправляет свой трафик при внезапном изменении задержки передачи данных.
Устойчивая команда отличается гибкостью и открытостью, способна быстро адаптироваться и разрабатывать новые стратегии при возникновении непредвиденных проблем. Устойчивые команды склонны рассматривать чрезвычайные ситуации как возможность для развития и адаптации, а не бояться их или испытывать стресс.
Устойчивость - это то, что можно создать, как с точки зрения динамики системы, так и с точки зрения динамики команды, и хаотическое тестирование способствует формированию такого мышления. Это похоже на те пожарные учения, которые мы проходили в детстве. Имитируя кризис, мы привыкаем к нему и учимся сохранять спокойствие, когда ситуация выходит из-под контроля.
Следует помнить, что этот метод очень требователен к разработчикам, и его не рекомендуется использовать в недавно сформированных командах или в небольших проектах. Он подходит для проектов с большим количеством подвижных частей, в которых одна ошибка может иметь масштабные последствия.
Хаотическое тестирование активно рекомендуется как один из лучших методов повышения отказоустойчивости и MTTR и используется такими гигантами в области программного обеспечения и инжиниринга, как IBM.
Провоцирование хаоса для защиты бизнеса
Создание хаоса может показаться оксюмороном, но нельзя отрицать доказательств. Netflix - одна из самых надежных систем на планете, что свидетельствует о том, насколько эффективным может быть хаотическое тестирование при правильном подходе.