Прекратите терять скорость разработки из-за разрастания автоматизации. Выявляйте скрытые затраты, консолидируйте операционные модели и используйте «операции как код», пишет на портале The New Stack Джастин Робертс, ведущий консультант PagerDuty по решениям в области автоматизации.

Представьте себе, что где-то в организации есть задача Jenkins, к которой никто не хочет прикасаться. Эта задача критически важна и развертывается в продакшене каждый четверг. Она была написана три года назад кем-то, кто уже уволился, ссылается на переменные среды, которые могут существовать, а могут и не существовать, а единственная документация — это сообщение в Slack, которое гласит: «Просто запустите. Это работает».

Это разрастание автоматизации, и оно незаметно истощает скорость разработки в организации.

Скрытые затраты, которые никто не отслеживает

Если что-то не отражается в счете за инфраструктуру, то это когнитивная нагрузка, связанная с запоминанием того, какая автоматизация где находится. Тридцать минут, которые могут потребоваться, чтобы понять, почему одна и та же задача работает в Jenkins, но не работает в GitHub Actions. Незначительные различия между средами возникают из-за того, что два разных инструмента управляют пересекающимися ресурсами. Команды могут обнаружить, что старшие инженеры тратят 20% своего времени просто на поддержание автоматизации и работоспособности существующих конвейеров, вместо того чтобы создавать новые возможности.

Это не скорость. Это бег на месте.

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

Как на самом деле выглядит консолидация

Успешные усилия по консолидации имеют общие черты.

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

Они устанавливают шаблоны раньше платформ. Вопрос не в том, «Следует ли нам использовать инструмент X или инструмент Y?», а в том, «Какие три или четыре шаблона автоматизации нам действительно нужны, и как проще всего реализовать каждый из них?». Большинству организаций необходимы запланированные задания, рабочие процессы, запускаемые событиями, сценарии выполнения, инициируемые людьми, и конвейеры развертывания. Все остальное, вероятно, является частными случаями, существование которых должно быть оправдано.

Эти команды понимают, что миграция — это долгосрочная стратегия. Разрастание не произошло за одну ночь, и это не будет исправлено за одну ночь. Цель состоит в том, чтобы прекратить усугублять проблему, постепенно уменьшая существующий объем автоматизации.

Эволюция подхода «операции как код»

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

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

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

Практические шаги вперед

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

  • Проведите аудит, прежде чем действовать. Потратьте неделю на каталогизацию. Поговорите с руководителями команд, чтобы выяснить, что происходит, когда X ломается, какие скрипты они используют и что происходит, если человек, обычно запускающий скрипты, отсутствует. Найдите определения конвейеров в репозиториях с помощью grep. Команды могут обнаружить автоматизацию, о существовании которой они не знали, а также автоматизацию, которую никто больше не использует, но все боятся удалить.
  • Четко определите владельца. У каждого элемента автоматизации должен быть владелец, который знает, что он является владельцем, и который привязан к сервису, где это уместно. Количество «осиротевших» конвейеров в большинстве организаций говорит о том, что это не так очевидно, как кажется. Команды могут двигаться, но сервисы, как правило, нет.
  • Создайте систему принятия решений. Когда кому-то нужна новая автоматизация, где она должна находиться? Запишите критерии, например: «Если это CI/CD, используйте X. Если это запланированные операции, используйте Y. Если это реагирование на инциденты, используйте Z». Сделайте путь по умолчанию очевидным и рассмотрите возможность создания репозитория GitHub для хранения этих артефактов.
  • Измерьте затраты. Отслеживайте время, затраченное на поддержку существующей автоматизации, отдельно от времени, затраченного на разработку новых возможностей. Если на поддержку постоянно приходится более 30% работы, связанной с автоматизацией, у организации есть проблема консолидации.

Объединение

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

Конвейеры CI/CD должны находиться в системе CI/CD. Выделение инфраструктуры должно осуществляться с помощью Terraform, Pulumi или любого другого инструмента, который команда стандартизировала. Но средний уровень, который включает в себя запланированные задачи по техническому обслуживанию, процедуры реагирования на инциденты и разовую операционную работу, которая в настоящее время находится в 20 разных местах, — это то, где консолидация окупается быстрее всего.

Именно в этой области заняли свою нишу платформы автоматизации сценариев, такие как Rundeck. Речь идет не о замене существующих инструментов, а о предоставлении единой плоскости управления для операционной работы. Задачи координируются по всей инфраструктуре организации, а не дублируют ее. Контроль доступа позволяет командам делегировать выполнение без раздачи SSH-ключей. Журналы аудита обеспечивают соответствие требованиям, чего никогда не смогут сделать разрозненные скрипты.

В этой области работают и другие инструменты. Платформа автоматизации Ansible, различные операторы Kubernetes и даже хорошо структурированные GitHub Actions с правильным OpenID Connect (OIDC). Операционная автоматизация заслуживает такой же тщательности, как и код приложений, а это значит, что ее нужно консолидировать, чтобы команды могли ею управлять.

Неприятная правда

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

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

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