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