Руководство по DevOps - [137]

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

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

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

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

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

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

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

Практический пример

Стандарты безопасности PCI и поучительная история о разделении обязанностей в компании Etsy (2014 г.)

[173]

Билл Мэсси работает руководителем разработки в компании Etsy и отвечает за приложение оплаты под названием ICHT (аббревиатура от I Can Haz Tokens[174]). ICHT проводит заказы клиентов через набор внутренних приложений обработки платежей: они принимают онлайн-заказ, выделяют информацию о платежной карте клиента, маркируют ее, отсылают платежной системе и завершают транзакцию[175].

Поскольку в предметную область среды CDE[176] входят «люди, процессы и технологии, хранящие, обрабатывающие и передающие данные владельцев платежных карт или конфиденциальную аутентификационную информацию», в том числе любые связанные с ними системные компоненты, приложение ICHT также попадает в область регулирования PCI DSS.

Чтобы поддерживать стандарты PCI DSS, приложение ICHT физически и логически отделено от остальных сервисов Etsy и управляется отдельной командой разработчиков, инженеров баз данных, специалистов по сетям и инженеров эксплуатации. У каждого члена команды есть два ноутбука: один для ICHT (который настроен по-особому, чтобы соответствовать требованиям DSS; в нерабочее время он хранится в сейфе) и один для прочей работы.

Благодаря такому подходу мы смогли отделить среду CDE от остальной части Etsy, тем самым сильно ограничив ту область, где должны соблюдаться стандарты PCI DSS. Системы, составляющие CDE, отделены (и управляются) от других сред компании на физическом, сетевом, логическом уровнях и на уровне исходного кода. Кроме того, среда CDE управляется и сопровождается многофункциональной командой, отвечающей только за нее.

Чтобы соблюсти требования по соответствию кода, группе ICHT пришлось поменять свои методики непрерывной поставки. Согласно разделу 6.3.2 PCI DSS v3.1, команды должны анализировать весь специально разработанный код до передачи в эксплуатацию или пользование, чтобы идентифицировать следующие потенциальные уязвимые места (с помощью процессов, проводимых вручную или автоматизированных).

• Анализируются ли изменения кода кем-то другим, помимо самого автора кода, и владеет ли эксперт методиками анализа кода и его написания?

• Проверяется ли код на соответствие требованиям написания безопасного кода?

• Исправляются ли проблемные места кода до релиза?

• Проверяются и одобряются ли результаты анализа кода соответствующими специалистами до релиза?

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

Это позволило Etsy выполнить требования PCI DSS и получить от оценщиков подписанный Отчет о соответствии требованиям. Однако в команде возникли серьезные проблемы.

Мэсси отмечает один проблематичный побочный эффект — это «уровень “изоляции” в команде ICHT. Такого нет ни в одной другой команде Etsy. С тех пор как мы ввели разделение обязанностей и другие средства контроля в соответствии с PCI DSS, в этой среде больше никто не мог быть инженером широкого профиля».