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

Один из худших моментов в моей профессиональной карьере произошел в 2006 г. Я целое утро наблюдал, как один из наших заказчиков работал с нашим продуктом. Он выполнял операцию, которую, как мы думали, клиенты будут выполнять еженедельно, и, к нашему ужасу, ему потребовалось 63 клика. Представитель заказчика все время извинялся: «Простите, наверняка есть способ сделать это лучше».

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

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

Пусть поначалу разработчики сами сопровождают свой продукт

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

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

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

Одна из возможных мер — сделать как Google: там все группы разработчиков сами поддерживают и управляют своими сервисами, пока они не перейдут к централизованной группе инженеров эксплуатации. Если разработчики сами будут отвечать за развертывание и сопровождение своего кода, переход к централизованной команде эксплуатации будет гораздо более гладким[129].

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

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

• Количество дефектов и их серьезность. Работает ли приложение так, как было запланировано?

• Тип и частота оповещений о проблемах. Не выдает ли приложение чрезмерное количество оповещений на стадии эксплуатации?

• Уровень мониторинга. Достаточен ли уровень мониторинга для восстановления работоспособности сервиса, если что-то идет не так?

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

• Процесс развертывания. Есть ли предсказуемый, четкий и достаточно автоматизированный процесс развертывания кода в эксплуатацию?