, анализ рисков и альтернатив, а также план воплощения в жизнь
[170].
• Срочные изменения: высокорисковые изменения, их нужно провести как можно быстрее (например, выпуск важного патча безопасности, восстановление сервиса). Для этих изменений часто нужно одобрение высшего руководства, но всю документацию можно оформить постфактум. Ключевая цель методик DevOps — так улучшить обычный процесс внесения изменений, чтобы его можно было использовать и для срочных изменений.
Переместите большинство низкорисковых правок в категорию стандартных изменений
В идеальной ситуации, когда конвейер развертывания надежен, у нас уже есть большой опыт быстрых, надежных и спокойных развертываний. На этом этапе мы должны договориться с инженерами эксплуатации и теми, кто отвечает за одобрение изменений: все перемены до этого момента были достаточно безрисковыми, чтобы определить их в категорию стандартных изменений. Это позволит нам проводить развертывания без лишних процедур по согласованию, хотя все изменения по-прежнему будут надлежащим образом фиксироваться.
Один из способов аргументировать утверждение, что у наших правок низкий риск, — продемонстрировать историю изменений за продолжительный временной отрезок (месяцы или кварталы) и полный список всех проблем эксплуатации за этот же период. Если доля успешных изменений будет высокой, а индекс MTTR — низким, можно уверенно утверждать, что наши средства контроля эффективно предотвращают ошибки развертывания и что мы можем быстро обнаруживать и исправлять возникающие проблемы.
Даже если наши изменения классифицированы как стандартные, их все равно нужно фиксировать в соответствующих системах управления изменениями (например, Remedy или ServiceNow). В идеале развертывания будут проводиться автоматически, с помощью инструментов конвейера развертывания и управления конфигурациями (например, Puppet, Chef, Jenkins), а результаты тоже будут записываться автоматически. Благодаря этому все сотрудники компании будут иметь доступ к информации об изменениях.
Мы можем привязать эти записи к конкретным задачам в инструментах планирования работы (например, JIRA, Rally, LeanKit, ThoughtWorks Mingle), что позволит создать более широкий контекст изменений, к примеру соотнести их с дефектами компонентов функциональности, сбоями в эксплуатации или требованиями заказчиков. Этого можно легко добиться с помощью включения номеров тикетов из инструментов планирования в комментарии о регистрации кода в системе контроля версий[171]. Благодаря такому подходу мы сможем связать конкретное развертывание с изменениями в системе контроля версий, а они, в свою очередь, связаны с тикетами инструментов планирования.