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

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

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

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

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

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

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

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

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

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

[173]

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

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

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