Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

Включайте проверку нефункциональных требований в программу тестирования

В дополнение к тестированию того, что код работает, как запланировано, и выдерживает нагрузку, близкую к производственной, мы также хотели бы проверить все другие атрибуты системы, о которых считаем нужным позаботиться. Это так называемые нефункциональные требования: доступность, масштабируемость, производительность, безопасность и так далее.

Многие из этих требований оказываются выполненными при правильной конфигурации наших сред, поэтому мы должны также создавать автоматические проверки, чтобы убедиться, что наши среды были созданы и настроены правильно. Например, мы хотим обеспечить согласованность и правильность следующих характеристик (на их основе выполняются и многие нефункциональные требования, в частности безопасности, производительности и доступности):

• поддержка приложений и баз данных, библиотек и так далее;

• интерпретаторы языков программирования, компиляторы и так далее;

• операционные системы (например, включение ведения журналов аудита и так далее);

• все зависимости.

Используя инструменты автоматизированного управления конфигурацией «infrastructure as a code» (например, Puppet, Chef, Ansible, Salt, Bosh), мы можем задействовать те же инструменты тестирования, что и для проверки кода, чтобы также выяснить, что наши среды настроены и работают правильно (например, используя проверки конфигурации сред в тестах Cucumber или Gherkin).

Кроме того, подобно тому как мы используем средства анализа приложений в конвейере развертывания (например, статический анализ кода, анализ тестового покрытия), мы должны запускать инструменты, анализирующие код автоматизированной конфигурации (например, Foodcritic for Chef, Puppet-lint for Puppet). Мы должны также выполнить проверки усиления безопасности как часть наших автоматических тестов, чтобы убедиться, что все настроено надежно и правильно (например, конфигурации серверов).

В любой момент времени наши автоматизированные тесты могут подтвердить, что у нас есть «зеленая» сборка и она находится в готовности к развертыванию. Теперь мы должны создать шнур-андон, чтобы, когда кто-либо нарушил работу конвейера развертывания, мы смогли предпринять все необходимые шаги для возвращения обратно в «зеленое» состояние сборки.

Дергайте за шнур-андон, если конвейер развертывания поврежден

Когда в конвейере развертывания «зеленая» сборка, мы обретаем высокую степень уверенности, что наши код и окружение при развертывании изменений в производственной среде будут работать именно так, как задумывалось.

Чтобы поддерживать конвейер развертывания в «зеленом» состоянии, создадим виртуальный шнур-андон, аналогичный физическому шнуру в системе производства Toyota. Когда кто-либо вносит изменение, нарушающее сборку или прохождение автоматизированных тестов, любая новая работа не подпускается в систему, пока проблема не устранена. И если кто-то нуждается в помощи для устранения этой проблемы, он может получить ее от всех членов команды, как и в примере с компанией Google, приведенном в начале главы.

Когда работа конвейера развертывания нарушена, мы по крайней мере должны уведомить о сбое всю команду, чтобы тот, из-за кого проблема возникла, мог ее исправить или откатить внесенные изменения. Мы даже можем настроить систему контроля версий для предотвращения дальнейшей записи изменений кода, пока первая стадия (то есть сборка и модульное тестирование) конвейера развертывания не перейдет обратно в «зеленое» состояние. Если эта проблема вызвана тем, что автоматизированная проверка выдала ложноположительную оценку, неправильная проверка должна быть переписана или удалена[84]. Каждый член команды должен быть наделен полномочиями для совершения отката, чтобы вернуть сборку обратно в «зеленое» состояние.

Рэнди Шуп, бывший технический директор Google App Engine, писал о важности возвращения процесса развертывания обратно в «зеленое» состояние: «Мы ставим командные цели выше индивидуальных, когда мы можем помочь кому-нибудь из членов команды продвинуть его работу вперед, мы делаем это всей командой. Это правило применимо ко всем случаям, независимо от того, помогаем ли мы кому-то исправить сборку, автоматизированный тест или даже делаем для него обзор кода. И конечно же, мы уверены, что все будут делать то же самое для нас, если нам понадобится помощь. Эта система работала без особых формальностей или правил — все знали, что нашей задачей было не просто “написать код”, но “запустить сервис”. Вот почему мы сделали приоритетными все вопросы качества, особенно связанные с надежностью и масштабированием, и рассматривали их как наиболее приоритетные задачи, а их невыполнение — как ошибку, приводящую к неработоспособности системы. С точки зрения системы эти методы удерживали нас от соскальзывания назад».