Комментарии 9
Тяжело читать. Понял что нужно повертеть хаус.
А если серьёзно, то это обыкновенный OAT, плюс периодические "учения" на поверку DR/HA на уровне систем, сервисов, цод-ов. Вы здесь далеко не первопроходец.
Не совсем так. Традиционные тестирования закладываются с известными переменными, в то время как хаос призван выявлять непредвиденные ситуации.
Может не совсем удачный пример, но попробую привести пример с кнопкой. Для тестирование кнопки задают выходные значения - кнопка нажалась, кнопка не нажалась. Ок, кнопка нажимается. Деплоим в прод. В проде кнопка нажимается, и даже выдает нужный результат. Но разработчик разрабатывал кнопку с правилом, что сеть всегда 100% доступности с бесконечной скоростью. А что если вдруг результат от нажатия кнопки задерживается, запаздывает? Пользователь начинает паниковать, жмет кнопку ещё 100 000 раз, и вот у вас уже очередь копится запросов))) Дальше больше, и тут вы уже не уверены как будет вести себя ваша система. Это и пытается донести chaos engineering
Нельзя просто открыть поисковик, напечатать «хаус инженеринг, скачать без смс и регистрации» и запускать на ваших ресурсах всё что вы найдете. Оно так не работает и работает вообще не так.
Особенно с учётом того, что chaos записывается на русском как "хаос".
Уххх.
offtop
Chaos произносится скорее как кэйос, а не хаус.
Chaos monkey и т.п. инструменты это только вершина айсберга которую все видят. Под этой вершиной лежит толстый-толстый слой тестирования, в котором проверяется поведение при негативный событиях. Под тестированием - еще более толстый слой разработки, в котором и закладывается поведение. Еще ниже разработки - сбор требований, которые и определяют негативные события для которых должно быть определено поведение. События тоже не берутся от балды - есть такая штука как управление рисками. В рамках которого и производится оценка вероятности события и ущерб в результате наступления этого события. В результате весь этот банкет оплачивается из бюджета предотвращения финансовых потерь. Только когда все слои собираются вместе - появляется chaos engineering. И да, это все имеет смысл только для достаточно крупных компаний. Для мелкой компании многие риски просто слишком дорого предотвращать.
Так что chaos engineering начинается с управления рисками. Метрика берется не от балды, а от возможного ущерба. Гипотеза тоже не придумывается, а выбирается исходя из событий которые агрегируются метрикой и вероятности наступления события. Планируется не только как ломать, но и как регистрировать происходящее после поломки - какие скрипты и когда должны запуститься, кто, что и когда должен сделать по регламентам и инструкциям. Замерять нужно не саму метрику, а время восстановления после поломки. Мда. Единственное, к чему не могу придолбаться - это "Оценить результаты, сделать выводы".
Автору могу порекомендовать исследовать пучины Краваго Ынтерпрайза. Ну там где мелкие изменения в микроскопический проект вносят три дев-синьора с солидной зарплатой в течении месяца, а тестируют два месяца четыре кьюэй-синьора. Просто потому что каждый час простоя сервиса компания теряет $10+К и все эти синьоромесяцы стоят меньше полусуток оффлайна.
Вы совершенно правы, инструментарий это только вершина. Но именно оно, одно из самых больших заблуждений, с которыми сталкиваются начинающие. Они берут инструментарий, видят там "подготовленные" сценарии (для "чужих" систем) и запутавшись в организации процесса, отталкивают саму идею.
Но вот про управление рисками, тут я с вами к сожалению не соглашусь. CE в основном применим к распределенным системам, где последняя разрастается семимильными шагами, и оценивать риски, как и контролировать систему становится всё сложнее и сложнее.
В любом случае, на мой взгляд стоимость самого CE переоценена, она может стать на много дешевле, если изначально понять азы и подойти с нужного ракурса.
Чтобы начинающие не хватались за инструменты - нужно разрабатывать методологию оценки готовности предприятия к внедрению СЕ, а не изобретать еще один универсальный инструмент для сферического предприятия в вакууме. Если поковыряться в вопросе - внезапно выходит, что СЕ строится не на пустом месте, а на вполне таки солидном фундаменте ITSM, ITIL и связанных стандартов. И при наличии фундамента стоимость внедрения СЕ действительно не так уж и велика. А когда фундамента нет - компания получит гораздо больший эффект если займется основами. Тогда и управление рисками будет формализованно и инструменты регистрации событий будут существовать и регламенты с инструкциями будут прописаны к началу внедрения СЕ.
"хаус" - это дом. Вы, наверное, хотели использовать слово "хаос" или если вы фанат англицизмов, то "кеёс". Если вы англичанину скажете "хаус инжиниирин", то он подумает, что вы civil engineer и планируете заниматься стройкой дома.
Chaos engineering: Начало