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

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

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

Компания CSG International — один из крупнейших операторов по печати счетов в США. Скотт Праф, главный архитектор и вице-президент отдела разработки ПО, в рамках усилий по повышению предсказуемости и надежности выпусков программного обеспечения удвоил частоту релизов с двух до четырех в год (уменьшив интервал между развертываниями вдвое, с 28 недель до 14).

Хотя команды разработчиков использовали непрерывную интеграцию для ежедневного развертывания их кода в средах тестирования, релизы в производственную среду выполнялись отделом эксплуатации. Праф отмечал: «Это как если бы у нас была “учебная команда”, ежедневно (или даже чаще) тренировавшаяся создавать низкорисковые тестовые среды, совершенствуя свои процессы и инструменты. Но производственная “играющая команда” упражнялась очень редко, всего два раза в год. Что еще хуже, она тренировалась в высокорисковой производственной среде, часто сильно отличавшейся от предпроизводственных сред, имевших различные ограничения — в средах разработки отсутствовали многие производственные ресурсы (средства обеспечения безопасности, брандмауэры, средства балансировки нагрузки и SAN)».

Чтобы решить эту проблему, была создана общая команда эксплуатации (Shared Operations Team, SOT), отвечавшая за управление всеми средами (разработки, тестирования, производственной), ежедневно выполнявшая развертывание в средах разработки и тестирования, а каждые четырнадцать недель — развертывание в производство. Поскольку SOT выполняла развертывание каждый день, любые проблемы, с которыми она сталкивалась и которые не были исправлены, на следующий день возникали снова. Это побудило к автоматизации трудоемких или чреватых ошибками операций, проведенных вручную, и устранению любых проблем, которые потенциально могли бы повториться. Поскольку развертывание выполнялось почти сто раз перед релизом, большинство проблем задолго до него были найдены и устранены.

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

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

Праф также отмечает:

«Мы столкнулись со многими случаями, когда изменялись схемы баз данных — либо 1) переданные в группу ДБА запросы в стиле “идите и разбирайтесь”, либо 2) автоматизированные тесты, работавшие с неоправданно малыми наборами данных (например, сотни мегабайт вместо сотен гигабайт), что вело к сбоям в производственном процессе. При прежнем способе работы это приводило к дискуссиям между командами до глубокой ночи в поисках козла отпущения и попытках размотать клубок проблем. Мы создали процесс разработки и развертывания, снявший необходимость передачи группе ДБА заданий на работу благодаря перекрестному обучению разработчиков, автоматизации изменения схемы и ежедневному выполнению этого процесса. Мы создали реалистичное тестирование нагрузки, не урезая данные заказчика, и в соответствии с идеальным решением выполняли миграцию каждый день. Благодаря этому мы сотни раз запускаем сервис с реалистичными сценариями еще до того, как он начнет обслуживать реальный производственный трафик» [91].