Три пути DevOps

Мой перевод про три пути DevOps (с комментариями) из статьи 2012-года «Top 11 Things You Need to Know About DevOps» за авторством Gene Kim

Первый путь: системное мышление

Первый путь подчеркивает важность рассмотреть производительности всей системы в целом. Противоположность этому — оптимизация отдельных подразделений компании (разработка, тестирование, эксплуатация, поддержка и так далее) или работы отдельных людей (разработчик, системный администратор, аналитик, специалист по тестированию и т.д.)

Уделяется внимание всем потокам создания ценности бизнеса, опирающимся на IT. Другими словами, все начинается с момента формирования требований, проходит через разработку и передается в эксплуатацию, где клиенту и предоставляется новая ценность в виде сервиса.

Результаты применения «Первого пути» на практике:

  • Известные дефекты никогда не передаются на следующий этап работ
  • Не применяется локальная оптимизация, ведущая к глобальной деградации производительности системы
  • Постоянные поиски путей для ускорения потока
  • Постоянное стремление к глубокому пониманию системы (по Демингу)
От себя
Здесь суть именно в том, чтобы добиться глубокого понимания системы: откуда приходит работа, как быстро проходит по потоку, где задерживается и по каким причинам. Визуализация всей работы и этапов её выполнения — первый шаг к пониманию системы. Не должно быть скрытой работы, так как это может привести к неверным данным и, соответственно — неверным решениям по улучшению (непреднамеренная локальная оптимизация).
Постепенно накапливаются данные о том, что может заблокировать выполнение работы, откуда работа может прийти внезапно, при каких условиях условное развертывание на проде проходит за час, а при каких требует недель.
Нередко система нам сама показывает, какие из проблем, возникающих на более поздних этапах выполнения работы решаются за счет улучшения или изменения правил работы на предыдущих. То есть решить проблему затянутого регрессионного тестирования нередко можно улучшениями на более ранних (specification by example, system decomposition) или более поздних (low risk deployments, canary releases + immune system) этапах.

Второй путь: усиление обратной связи

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

Результаты применения «Второго пути» на практике:

  • Понимание и реакция на всех клиентов, как внутренних, так и внешних
  • Сокращение и усиление всех петель обратной связи
  • Появление знаний о системе там, где они требуются
От себя 
Здесь всё рассматривается с точки зрения именно петель обратной связи: если раньше существовал клиент, с которым у нас не было никаких коммуникаций, то теперь эта связь появляется и мы может адаптировать систему исходя из новой информации, получаемой от клиента; равно как и клиенту предоставляется информация в виде петли обратной связи и он может соответствующим образом менять свое поведение. Существующие петли сокращаются — мы начинаем получать информацию быстрее и в более качественном виде. Если петли обратной связи говорят о том, что где-то не хватает информации, чтобы работа выполнялась лучше — она там появляется (например — у разработчиков появляется описание инфраструктуры).

Третий путь: культура экспериментов и обучения

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

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

Результаты применения «Третьего пути» на практике:

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

Ссылка на оригинал:

Share

Leave a Reply