Приближается Хэллоуин. Конечно, главное понятие сегодня – это страх. А у меня, как у программиста, есть пара страшных фраз. Дедлайны, баги, сбои производительности, утечки памяти, проблемы с сетью, проблемы с DNS, боже мой, проблемы с DNS, ошибки «да, мы не можем откатиться, потому что БД уже манипулируют», «О, черт, я был на производстве?!» ошибки… И так далее. Легко напугать разработчиков программного обеспечения, если вы немного знаете предметную область и их проблемы. Когда я описываю такой сценарий, как дежурство и работа с последовательными вызовами в очень сложной системе, в одиночестве я вижу тот же страх на лицах разработчиков.

Но когда я сокращаю свои предложения и описываю их как «Сбой производства», я все еще вижу страшные лица, но теперь каждое лицо рассказывает другую историю. Каждый инженер-программист помнит день (дни), когда они все испортили. Лучшие инженеры, которых я встречал, самые умные, самые трудолюбивые ребята рассказывали мне о худшем бреде, который я когда-либо слышал.

Так что провал на производстве неизбежен. Если бы Марк Аврелий был разработчиком программного обеспечения, он бы сказал: «Сбои в производстве неизбежны», а не Memento Mori. Сбои в производственной среде болезненны как для компании, сотрудников компаний, так и для их клиентов. Так что же мы делаем, чтобы предотвратить их? У нас есть процессы проверки кода, модульные тесты, интеграционные тесты, сценарии сквозного тестирования, отдельные группы контроля качества, нагрузочные тесты, промежуточные среды, альфа- и бета-тесты, расширенные стратегии развертывания,…

Достаточно ли отлавливать ошибки до того, как они произойдут в продакшене? Очевидно нет. Это действительно мощные техники, и каждая из них охватывает разные области отказа, но этого все же недостаточно. Итак, у нас появился новый термин, Chaos Engineering! Chaos Monkey был выпущен в 2012 году, поэтому он не настолько нов, но я почти уверен, что большинство компаний до сих пор не используют этот термин в своих SDLC. Моя цель в этом сообщении в блоге — упомянуть методы и инструменты, которые могут быть полезны для Chaos Engineering.

Основная идея этой истории заключается в том, чтобы быть готовым к производственным неудачам. В дисциплине Chaos Engineering инженер хаоса предполагает, что будет недостаточная устойчивость. И системы должны быть готовы к этому постоянно. Для достижения этой цели мы используем научный подход к проблемам.

И, пожалуйста, посмотрите также Принципы Хаос-инженерии.

Методы

  • Отключение узлов, отключение серверов/сервисов
  • Задержка инъекции
  • Сбои ЦП
  • Полная память / диск
  • Сбои сети/DNS

Инструменты

  • Chaos Monkey до сих пор первое, что приходит на ум, когда люди слышат термин Chaos Engineering. Это помогает произвольно завершать экземпляры, чтобы убедиться в отказоустойчивости.
  • Гремлин — это комплексный инструмент, который предоставляет простой пользовательский интерфейс и обширную базу данных атак для нескольких технологий…
  • Литмус также является комплексным инструментом на базе облака. Поставляется с графическим интерфейсом, рабочим процессом, планированием, функциями командной работы…
  • AWS FIS, также известная как Fault Injection System, помогает внедрять сбои в сервисы, такие как высокое потребление памяти, использование всего места на диске и т. д.
  • Istio Chaos Testing встроен в Istio. Может использоваться для прекращения работы сервисов, введения задержки или имитации ошибок HTTP…
  • Существует также множество инструментов, таких как промежуточное программное обеспечение для сценариев внедрения ошибок на различных языках программирования. Пожалуйста, ознакомьтесь с репозиторием Github Awesome Chaos Engineering, чтобы узнать больше.

Спасибо за чтение до сих пор.

Присоединяйтесь к FAUN: Сайт💻|Подкаст🎙️|Twitter🐦|Facebook👥 |Instagram📷|Группа Facebook🗣️|Группа Linkedin💬| Slack 📱|Cloud Native Новости📰|Дополнительно.

Если этот пост был полезен, пожалуйста, несколько раз нажмите кнопку аплодисментов 👏 ниже, чтобы выразить свою поддержку автору 👇