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

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

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

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

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

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

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

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

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

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

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

Встройте пожелания команд эксплуатации в процесс разработки

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

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

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

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

Используйте технологии, работающие на достижение целей компании

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

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

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

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

• замедляют или мешают рабочему процессу;

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

• являются причиной большого количества запросов на поддержку;

• плохо соответствуют целям в плане характеристик архитектуры (например, производительность, стабильность, безопасность, надежность, бесперебойность работы).