Текстовый курс по DevOps
Зачем нужна обратная связь для безопасного развёртывания в рабочих средах?
На конкурентном рынке трудно быстро обслуживать клиентов и постоянно удовлетворять их запросы, если разработка, обеспечение качества и эксплуатация работают раздельно. Хотя большинство разработчиков жалуются на бюрократию, даже получив возможность работать со специалистами по качеству и эксплуатации в одной команде, они по-прежнему боятся самостоятельно развёртывать код в рабочей среде без надзора. Рассмотрим методы и меры, которые делают развёртывания безопаснее.
Как обеспечить непрерывный поток работы в DevOps
Самые успешные DevOps-организации поддерживают непрерывный поток работы, часто развёртывая небольшие пакеты изменений в рабочих системах. Так каждый участник команды может оценить и понять изменения и при необходимости их исправить.
Одного автоматизированного конвейера недостаточно. Встройте в него телеметрию эксплуатации, чтобы быстро узнавать о результатах изменений в рабочих и предрабочих средах. В организации также должно сложиться общее понимание того, что каждый участник команды DevOps отвечает за исправность и бесперебойную работу всего потока создания ценности и конвейера развёртывания.
Используйте телеметрию для более безопасного развёртывания
Изменение и развёртывание можно считать завершёнными только после того, как вы убедились, что они выполняют задачу, для которой были задуманы и реализованы. После развёртывания внимательно следите за метриками изменённых модулей, новыми метриками, если они есть, и показателями других компонентов, которые могут быть затронуты.
Даже если вы запускаете автоматизированные тесты в предрабочих средах и отслеживаете тестируемую систему с помощью телеметрии, в рабочих системах всё равно будут возникать проблемы. Предотвратить их все нельзя, но можно хорошо подготовиться к их устранению. Если изменение нарушает работу конвейера, привлеките нужных профильных специалистов, чтобы устранить проблему и восстановить работу. Вот три распространённых способа устранения проблем:
- Отключить функцию Это самый простой способ устранить проблему, не требующий срочного развёртывания кода. Отключите функцию переключателем. Вам не придётся в спешке исправлять ошибочные части развёрнутого решения. Команда DevOps сможет точно определить первопричину и улучшить свои методы, чтобы снизить вероятность повторения проблемы.
- Внести исправление без отката Разверните новый код, который исправляет проблему. В традиционных ИТ-организациях такой подход к сбоям в рабочей среде опасен. В DevOps он может быть эффективным и безопасным, если налажены автоматизированное тестирование и развёртывание и есть полная телеметрия рабочих систем.
- Откатить изменение Удалите ошибочный код, и проблема, скорее всего, исчезнет.
Дайте разработчикам обратную связь из реальной эксплуатации
По очереди поручайте участникам команды DevOps обязанности специалистов эксплуатации, в том числе реагирование на инциденты. Так каждый участник потока поймёт задачи и трудности коллег на последующих этапах. Привлекайте разработчиков, тестировщиков, архитекторов, проектировщиков, менеджеров и директоров к внеплановым дежурствам, чтобы и им звонили об инцидентах в 3 часа ночи. Тогда каждый увидит последствия решений, которые принимает в повседневной работе.
Такая ротация помогает специалистам эксплуатации не чувствовать себя изолированными. Все участники команды DevOps помогают находить равновесие между устранением инцидентов, сокращением технического долга и разработкой новых функций. Когда архитекторов и разработчиков будят в 3 часа ночи, инциденты устраняются быстрее, чем когда-либо.
Когда разработчики наблюдают, как клиенты пользуются их ПО, они часто сразу понимают, что стоит улучшить. То же происходит, когда архитекторы, проектировщики, разработчики и тестировщики наблюдают за последующими этапами разработки. Понимая влияние своей работы на коллег, они видят, как повысить её качество и скорректировать результаты, чтобы помочь следующим участникам работать лучше. Все члены команды DevOps начинают учитывать нефункциональные требования эксплуатации в своей повседневной работе и бэклогах. Для этого нужна быстрая и непрерывная обратная связь внутри организации DevOps.
Поручите разработчикам эксплуатацию собственной системы
Передать командам разработки опыт, полученный в реальных рабочих системах, очень трудно. Поэтому некоторые ведущие организации DevOps, в том числе Google, поручают разработчикам эксплуатацию ПО во время и после первоначального запуска продукта. Пока продуктом управляют разработчики, инженеры эксплуатации консультируют их. Когда продукт показывает достаточную стабильность примерно 6 месяцев, его передают команде эксплуатации. Перед передачей проверяют прошлые и текущие дефекты, охват телеметрией, инциденты вне рабочего времени, слабую связанность архитектуры и безопасность изменений и развёртываний.
Если после передачи команде эксплуатации обнаружатся серьёзные проблемы проектирования или кода, продукт можно вернуть разработчикам. Они будут отвечать за его стабилизацию, а инженеры эксплуатации — консультировать их.
ВЫВОДЫ
В этой главе мы рассмотрели способы обеспечить бесперебойную и более безопасную работу конвейеров развёртывания в вашей организации DevOps.
Эти методы показывают, как разработчики и инженеры эксплуатации в командах DevOps могут сотрудничать и уважать работу друг друга.
