Джин Ким - Руководство по DevOps

Представьте реальную организацию, пользующуюся 81 версией библиотеки Java Struts. Всех версии, кроме одной, серьезно уязвимы. Поддержка всех этих вариантов — у каждого свои особенности — создает огромную операционную нагрузку. Кроме того, такое большое количество делает обновление версий рискованным и опасным, из-за чего разработчики не горят желанием эти обновления проводить. Порочный круг.

Единое хранилище исходного кода решает большинство этих проблем, и к тому же можно создать автоматизированные тесты, позволяющие командам переходить на новые версии уверенно и безопасно.

Если мы не можем собирать все приложения с единого дерева исходного кода, нужно найти другой способ поддержки хороших версий библиотек и их зависимостей. Например, можно завести единое хранилище, такое как Nexus, Artifactory или репозиторий Debian или RPM. Это хранилище затем необходимо регулярно обновлять, если в репозиториях или в производственных системах будут выявлены уязвимые места.

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

Если мы внедрили методологию разработки через тестирование (TDD), где тесты пишутся до кода, то такое преимущество мы получим практически без лишних действий. Такой подход превращает наши наборы тестов в актуальную спецификацию системы. Любой сотрудник, желающий понять, как работать с какой-либо системой, может просто взглянуть на набор тестов и увидеть работающие примеры того, как пользоваться API-системой.

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

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

Чтобы быстрее распространять знания, можно также создать группы обсуждений или чаты для каждой библиотеки и сервиса. Благодаря этому любой сотрудник, имеющий вопросы, может получить ответ от других пользователей, часто отвечающих быстрее, чем разработчики.

С помощью такого инструмента коммуникации мы облегчаем обмен знаниями и опытом, а сотрудники получают возможность помогать друг другу с проблемами и новыми подходами к разработке.

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

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

• достаточный объем производственной телеметрии в приложениях и средах;

• способность четко отслеживать зависимости;

• адаптивные сервисы, способные поддерживать минимум функциональности даже при масштабных сбоях;

• прямая и обратная совместимость между версиями;

• способность архивировать данные для управления размером набора данных в эксплуатации;

• легкий поиск и интерпретация логов всех сервисов;

• способность отслеживать запросы пользователей через большое количество сервисов;

• простая централизованная конфигурация вычислительной среды с флажками элементов функциональности и так далее.

При определении таких типов нефункциональных требований использовать накопленный опыт компании в новых и уже существующих сервисах становится гораздо проще. Ответственность за это лежит на команде, разрабатывающей тот или иной сервис.

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

Вместо того чтобы собирать серверы вручную и только потом вводить их в производственную среду в соответствии с чек-листами, нужно автоматизировать эту работу, насколько возможно. Если некоторые действия все равно требуют вмешательства вручную (например, установка и подключение серверов, проводимые другой командой), то нужно четко определить момент перехода задачи к другой группе, чтобы сократить время простоя и уменьшить число ошибок. Все это также поможет планировать такие шаги в будущем. Например, для автоматизации и организации рабочего процесса можно использовать инструменты Rundeck или системы тикетов вроде JIRA или ServiceNow.

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

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