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

Переместите большинство низкорисковых правок в категорию стандартных изменений

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

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

Даже если наши изменения классифицированы как стандартные, их все равно нужно фиксировать в соответствующих системах управления изменениями (например, Remedy или ServiceNow). В идеале развертывания будут проводиться автоматически, с помощью инструментов конвейера развертывания и управления конфигурациями (например, Puppet, Chef, Jenkins), а результаты тоже будут записываться автоматически. Благодаря этому все сотрудники компании будут иметь доступ к информации об изменениях.

Мы можем привязать эти записи к конкретным задачам в инструментах планирования работы (например, JIRA, Rally, LeanKit, ThoughtWorks Mingle), что позволит создать более широкий контекст изменений, к примеру соотнести их с дефектами компонентов функциональности, сбоями в эксплуатации или требованиями заказчиков. Этого можно легко добиться с помощью включения номеров тикетов из инструментов планирования в комментарии о регистрации кода в системе контроля версий[171]. Благодаря такому подходу мы сможем связать конкретное развертывание с изменениями в системе контроля версий, а они, в свою очередь, связаны с тикетами инструментов планирования.

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

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