Хаос-инжинирнг (chaos engineering) — относительно новая дисциплина в цифровой сфере, в рамках которой инженеры проводят эксперименты, призванные смягчить последствия сбоев в системах. CTO сервисной компании Infostretch Маниш Мистри рассказывает на портале InformationWeek о его достоинствах и приводит рекомендации, как правильно к нему приступить.
Хаос-инжиниринг широко применяется в промышленности и производстве, но цифровой инжиниринг — это относительно новая дисциплина. С помощью этой техники проводятся эксперименты с ПО, которое находится в производственной среде, чтобы определить потенциальные проблемы в его работе, а также удостовериться в общей готовности системы противостоять турбулентности. Несмотря на то, что в последние годы принципы хаос-инжиниринга набирают популярность, некоторые клиенты и инженеры (по понятным причинам) опасаются иметь с ним дело, ошибочно считая, что хаос-инжиниринг — это намеренная поломка системы.
Кроме того, клиентов может отпугивать сама терминология: к примеру, «радиус взрыва», «случайное прекращение действия» или упоминание в названиях программ Facebook терминов «хаос» или «штормы». К слову, Facebook регулярно проверяет устойчивость своей инфраструктуры к работе в экстремальных условиях. Программа, известная как Storm Project, имитирует массовые отказы центров обработки данных. Однако большинство инженеров, которые потратили значительное количество времени на решение проблем, которые не удалось обнаружить на ранних стадиях цифрового жизненного цикла, ценят подход «Shift Left», тестирование с последующим устранением ошибок.
Считается, что чем раньше организация обнаружит проблемы в ПО, тем самым она повысит его качество и впоследствии программисты столкнутся с меньшим количеством непредвиденных ошибок. Это распространенное заблуждение. С появлением более сложного ПО, Интернета вещей, облаков, распределенных систем и микросервисов к качеству и устойчивости требуется новый подход, что позволило бы учитывать множество пермутаций и взаимозависимостей между всеми составными частями. Ответом на эти изменения может стать хаос-инжиниринг.
Традиционное тестирование ПО подтверждает, что код выполняет то, что от него требуется (оно продолжает оставаться важной частью цифрового инжиниринга). Между тем, хаос-инжиниринг — это способ проверки, который позволяет убедиться в том, что предсказуемо ведет себя не только код, но и вся система в целом. Другими словами, код в нем — лишь одна из составляющих. Чтобы эффективно протестировать систему, ее необходимо проверить в режиме реальной коммерческой эксплуатации. Это связано с тем, что определенную роль в работе системы играют многие другие факторы, такие как состояние, входные данные и поведение внешних систем.
Растущая сложность систем вдохнула жизнь в идею «темного долга», под которым подразумеваются непредвиденные аномалии — они возникают в сложных системах из-за непредсказуемого поведения и взаимодействия различных частей программного и аппаратного обеспечения. Этот термин заимствован из понятий «технический долг» (из ИТ-сферы) и «темная материя» (из сферы космоса), чтобы указать на неизбежные, невидимые осложнения, которые вторгаются в работу сложных систем. Их обнаружение — это именно то, что пытается обнаружить хаос-инжиниринг. Управление турбулентностью ПО в производственной среде должно стать важной частью планирования и затрагивать каждый эксперимент. Ниже приводится несколько советов, которые помогут обрести устойчивость всей системе.
Без сюрпризов
Лучший подход — это поговорить с коллегами, объяснить свои планы и ничего не делать, если вы подозреваете, что его не удастся реализовать. (В таком случае исправьте слабые места). Хаос-инжиниринг не может заменить планирование и шаблоны устойчивости. Организации, приступающие к его внедрению, должны тщательно продумать доказательные гипотезы с учетом того, как ограничить радиус взрыва. Тщательно спланированная реальность хаос-инжиниринга сильно отличается от того, как ее однажды описал Вернер Фогель из Amazon: «Взломайте все, чтобы увидеть, как реагируют ваши системы».
Небольшой эксперимент — это чудесно
Начните с малого и ограничьте радиус взрыва для своего эксперимента. Это подразумевает учет времени проведения, количества департаментов и объема ресурсов, которые он затронет. Речь идет не о намеренном перерезании кабеля или случайном отключении машины, чтобы посмотреть, что произойдет. Цель — доказать гипотезу. Получить представление о том, как реагирует система, всегда можно даже тогда, когда отказоустойчивость находится в пределах допустимого.
Окружающая среда имеет значение
Если проведение экспериментов в производственной среде кажется шагом в пропасть, ничего страшного. Первые шаги организации в области хаос-инжиниринга в условиях рабочей среды могут быть слишком рискованными. В этом случае они должны начинаться в другой среде, но максимально приближенной к производственной. Однако в этом случае нужно понимать, что полученные результаты не будут достаточно реалистичными, чтобы понять, как поведет себя рабочая система в случае отказа.
Не останавливайтесь
ПО и системы постоянно совершенствуются, поэтому эксперименты с хаос-инжинирингом должны отражать это. Предполагать, что если месяц назад система определенным образом отреагировала на тест с внесением неисправности (fault injection test, FIT) и таким же образом она будет реагировать сегодня, будет ошибкой. Многие из этих экспериментов можно автоматизировать, что позволяет инженерам сосредоточиться на увеличении объема, интенсивности и разнообразии тестов.
