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

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

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

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

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

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

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

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

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