Джин Ким - Руководство по DevOps

Узконаправленные блиц-обучения «исправь это», по словам Бланда, должны проводиться в самые важные моменты, чтобы воодушевлять и давать энергию людям на решение важных проблем. С каждым значительным вложением сил масштабная цель изменить культуру компании становится все ближе и ближе.

Польза культуры тестирования очевидна: достаточно посмотреть на потрясающие результаты компании Google, многократно описанные в этой книге.

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

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

На протяжении части V мы изучили методики для создания в компании культуры обучения и экспериментирования. Обучение на ошибках, создание единых баз знаний и обмен опытом крайне важны, когда мы работаем в сложных системах; это делает нашу культуру более беспристрастной, а наши системы — более безопасными и устойчивыми.

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

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

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

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

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

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

• сделаем безопасность частью повседневной работы всех сотрудников;

• встроим профилактические меры безопасности в единый репозиторий исходного кода;

• преобразуем конвейер развертывания в соответствии с принципами безопасности;

• преобразуем телеметрию с учетом принципов безопасности, чтобы улучшить возможности обнаружения сбоев и восстановления после ошибок;

• обеспечим защиту конвейера развертывания;

• совместим процедуры развертывания и процессы согласования изменений;

• уменьшим зависимость от разделения обязанностей.

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

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

Когда за информационную безопасность отвечает отдельное подразделение, возникает много проблем. Джеймс Уикетт, один из создателей средства защиты GauntIt и организатор конференции DevOpsDays в Остине и конференции Lonestar Application Security, отмечает:

«Одной из причин появления DevOps называют необходимость повысить производительность разработчиков, потому что с ростом числа разработчиков инженеры эксплуатации перестают справляться с развертываниями. Это ограничение еще сильнее бросается в глаза в информационной безопасности: отношение инженеров разработки, эксплуатации и информационной безопасности в типичной организации — обычно 100:10:1. Когда работников информационной безопасности так мало, без автоматизации и интегрирования защиты информации в повседневную деятельность отделов разработки и эксплуатации их времени будет хватать только на проверку, соответствует ли продукт нормативам и требованиям, что прямо противоположно принципам защиты данных. И, кроме того, из-за этого все нас ненавидят».

Джеймс Уикетт и Джош Кормен, бывший технический директор компании Sonatype и известный исследователь информационной безопасности, писали о встраивании целей защиты информации в DevOps, о наборе методик и принципов под названием прочный DevOps (Rugged DevOps). Похожие идеи, где защита информации встроена во все стадии цикла создания ПО, были разработаны Тапабратой Палом, директором и инженером по разработке платформ банка Capital One, и командой Capital One. Они назвали придуманные ими процессы DevOpsSec. Один из источников идей DevOps — книга Visible Ops Security, ее авторы — Джин Ким, Пол Лав и Джордж Спаффорд.