Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

Встройте цели защиты данных и выполнения требований в процесс одобрения изменений

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

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

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

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

• Нормальные изменения: риски этих перемен выше, им требуется рецензирование или одобрение от выбранных специалистов. Во многих организациях эта ответственность ошибочно возлагается на комитет по изменениям (change advisory board, CAB) или на комитет по срочным изменениям (emergency change advisory board, ECAB). Однако у них может не быть достаточной компетенции, чтобы понять все последствия предлагаемых перемен, что часто ведет к недопустимо долгим срокам. Эта проблема особенно важна для крупных развертываний кода, содержащих сотни тысяч (и даже миллионы) строк нового кода, написанных сотнями разработчиков на протяжении нескольких месяцев. Для одобрения нормальных изменений у комитета, как правило, есть форма запроса для внесения изменений (request for change, RFC), и в ней определяется информация, нужная для принятия или отклонения этого запроса. В форме RFC обычно описываются предполагаемые результаты для бизнеса, планируемые функциональность и гарантии

[169], анализ рисков и альтернатив, а также план воплощения в жизнь[170].

• Срочные изменения

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

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

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

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

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