Текстовый курс по DevOps
Как защитить конвейер развёртывания DevOps?
Когда вы с командой DevOps создадите работающий конвейер непрерывной поставки по рассмотренным принципам, вы сможете развёртывать изменения в рабочей среде с низким риском и без внешних согласований. Большинству развёртываний больше не нужен отдельный процесс согласования. Вы опираетесь на продуманный процесс поставки ПО, автоматизированное тестирование и мониторинг и информативные оповещения от ваших сред, а не только на внешних согласующих. Безопасность и соблюдение требований остаются важной обязанностью команды DevOps. Это нужно и для выполнения закона, и для защиты интересов клиентов. Команда продолжает работать с профильными экспертами по безопасности и соблюдению требований, но проектирование безопасных систем, соответствующих применимому законодательству, становится повседневной задачей и привычкой.
Виды изменений в рабочих системах
- Стандартные изменения Это изменения с низким риском. Они не требуют согласований и развёртываются быстро, поскольку полностью автоматизированы и регистрируются в журналах. Примеры — обновление справочных таблиц базы данных, изменение контента и оформления, установка стандартных обновлений операционной системы, базы данных или других сторонних компонентов.
- Обычные изменения Это изменения с высоким риском. Они требуют одобрения консультативного комитета по изменениям (CAB), который оценивает их по форме запроса на изменение (RFC). Согласование занимает много времени, поскольку членам комитета часто не хватает знаний для оценки изменений. Они откладывают решение и в итоге опираются на опыт, интуицию и предвзятое отношение к тому, кто запросил изменение.
- Срочные изменения Это изменения с высоким риском, которые требуют одобрения высшего руководства. Примеры — исправление критических ошибок в рабочих системах, затрагивающих клиентов, устранение последствий неудачного развёртывания, установка исправлений безопасности и восстановление сервисов.
Независимо от вида изменений вы и команда DevOps должны документировать их в системах управления изменениями и планирования работ, таких как Remedy и Jira. Тогда работа будет видна всем участникам команды DevOps и коллегам за её пределами.
Используйте историю успешных автоматизированных развёртываний, чтобы перевести обычные изменения в стандартные
Увеличив долю стандартных изменений по сравнению с обычными, вы сможете обходиться без одобрения CAB, ускорять поток работы и повышать качество конвейера развёртывания.
Используйте историю успешных автоматизированных развёртываний, чтобы перевести как можно больше обычных изменений в стандартные. Покажите комитету историю развёртываний и список инцидентов. Подтвердите, что автоматизированные развёртывания не вызывают инцидентов или приводят лишь к незначительным сбоям в рабочих системах.
Ускорьте развёртывание обычных изменений
Для изменений, которые должны остаться обычными, автоматизируйте подготовку запроса на изменение (RFC). Приложите результаты автоматизированных и ручных тестов, сведения об устранённых и неустранённых инцидентах, записи мониторинга и журналы предрабочих систем. Упростите работу CAB и предоставьте нужную информацию уже в первой версии запроса, чтобы максимально ускорить согласование.
После одобрения обеспечьте развёртывание обычных изменений одним нажатием кнопки. Регулярно пересматривайте с CAB виды обычных изменений и выясняйте, какие условия позволят перевести их в стандартные. Так вы сможете автоматически развёртывать большинство изменений в своей организации DevOps.
Сократите бюрократию и зависимость от других подразделений
Чем крупнее организация, тем больше возможностей для бюрократии. Она незаметно растёт экспоненциально и может существовать бесконечно. Если вы зависите от руководства и механизмов контроля на уровень выше при одобрении своей работы, вы перестаёте чувствовать полномочия и ответственность за её результат. В итоге вышестоящие согласующие регулярно ошибаются.
Со временем и этим согласующим понадобятся вышестоящие органы, на которые они смогут опираться и которые будут их проверять. Эта цепочка будет расти до следующей реорганизации. После неё с вероятностью почти 100% нынешнюю проблему сменит та же цепочка в немного другой форме.
Помните: разделение обязанностей и зависимость от контроля за пределами команды замедляют поставку, ухудшают её качество и снижают безопасность организации. Крупная финансовая организация США пострадала от мошенничества с банкоматами из-за бэкдора, который разработчик внедрил в их ПО. Внешние аудиторы, специалисты по безопасности и соблюдению требований и члены CAB не смогли обнаружить вредоносный исходный код, развёрнутый в рабочих системах. Его можно было выявить внутри команды, где он был написан, применив базовые методы DevOps, такие как проверка коммитов и коллегиальная проверка кода.
Чтобы поставлять ПО быстро и безопасно, сократите зависимость от других подразделений и разделение обязанностей, если они мешают команде DevOps нести ответственность. Используйте другие механизмы контроля: проверку коммитов, парное программирование, коллегиальную проверку, автоматизированное тестирование и мониторинг. Если разделение обязанностей обязательно по закону, встроенные средства контроля команды всё равно помогут аудиторам и специалистам по соблюдению требований принимать более взвешенные и быстрые решения.
ВЫВОДЫ
DevOps меняет подход к соблюдению требований и информационной безопасности. Когда инфраструктура описана кодом, системы создаются и удаляются с его помощью, а код развёртывается автоматически, аудиторам трудно понять, что происходит. Это и новая задача, и возможность создавать и применять более простые и эффективные механизмы аудита и соблюдения требований и привлекать специалистов, которые умеют с ними работать.
В команде DevOps информационная безопасность, соблюдение требований и ускорение конвейера развёртывания — работа каждого. Одна из главных целей команды — дать специалистам по соблюдению требований самостоятельный доступ к информации, журналам, отчётам и метрикам, подтверждающим качество поставки. Это позволит упростить бюрократические процедуры согласования или даже отказаться от них.
