Книга: Руководство по DevOps

Разрываем нисходящую спираль, используя DevOps

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

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

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

Всеобъемлющий сбор телеметрии о коде и программной среде обеспечивает своевременное обнаружение проблем и их быстрое исправление. Он подтверждает: все на месте, как предусмотрено, и клиенты получают продукт благодаря предоставленному нами ПО.

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

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

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

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

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

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

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

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

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

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

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

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

Оглавление книги