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

Бесстрашно избавляйтесь от бюрократических процессов

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

Как отмечает Адриан Коккрофт, «вывешивать на широкое обозрение стоит отличный показатель — сколько встреч и тикетов нужно, чтобы сделать один релиз. Цель — неуклонно сокращать усилия инженеров на создание продукта и поставку его заказчикам».

Точно так же Тапабрата Пал, сотрудник компании Capital One, описал одну программу под названием Got Goo?[141]. Специальная команда устраняет всевозможные препятствия, включая инструменты, процессы и одобрение, мешающие завершению процесса. Джейсон Кокс, старший директор по проектированию систем компании Disney, в презентации на конференции DevOps Enterprise Summit 2015 г. описал программу Join the Rebellion[142]. Ее цель — избавить от тяжелого труда и всевозможных препятствий.

В 2012 г. в компании Target комбинация процесса принятия новых технологий (TEAP) и ведущей комиссии контроля по архитектуре (LARB) привела к тому, что на одобрение использования новой технологии требовалось очень много времени. Чтобы предложить новую технологию, например иную базу данных или систему мониторинга, нужно было заполнить форму TEAP. Эти предложения затем оценивались, и стоящие заносились в список вопросов ежемесячных встреч LARB.

Хизер Микман и Росс Клэнтон, директор по разработке и директор по эксплуатации в Target, Inc. соответственно, помогали внедрять методы DevOps в своей компании. Микман нашла необходимую для одного проекта технологию (в данном случае Tomcat и Cassandra). Решение LARB гласило, что в данный момент команда эксплуатации не может ее поддерживать. Однако Микман была настолько убеждена в необходимости этих систем, что она предложила, чтобы за поддержку, интеграцию, доступность и безопасность этой технологии отвечала ее команда разработчиков, а не команда эксплуатации.

«Пока это предложение рассматривалось, я хотела понять, почему процесс TEAP-LARB занимает столько времени, и я использовала методику “пяти почему”… Она в конце концов привела меня к вопросу, зачем вообще нужен TEAP-LARB. Удивительно, но никто не мог на него ответить, кроме разве что расплывчатых соображений о том, что нам нужен какой-то контроль. Многие знали, что несколько лет назад произошла какая-то катастрофа и она ни за что не должна повториться снова. Но никто не мог точно вспомнить, что же это была за катастрофа».

Микман отмечает, что проходить через этот процесс ее группе было необязательно, если они соглашались быть ответственными за поддержание новой технологии. Она также добавляет: «Я дала всем знать, что все новые технологии, поддержанные моей командой, согласовывать с TEAP-LARB не нужно».

В результате систему управления базами данных Cassandra в Target успешно внедрили. Более того, процесс TEAP-LARB впоследствии был отменен. В благодарность за устранение барьеров для введения новых технологий команда Хизер Микман вручила ей награду за профессиональные достижения.

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