Большая ошибка многих рассуждающих в контексте DevOps о “снижении TTM” и необходимости “релизиться чаще” состоит в том, что они рассматривают частоту релизов и время “от коммита до продакшна” как технический показатель. В лучшем случае рассматривают с учетом простоев в цепочке поставке. Они считают, что если автоматизировать все, они смогут релизиться 100 раз в день и догонят и перегонят Google (конечно, для этого автоматизировать нужно “не просто так”, а “по-умному”).

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

Все прямо по канонам Lean — после того, как мы устранили узкое место в инфраструктуре тут же обнаружились узкие места в других частях организации как системы. И для отслеживания поиска и устранения этих узких мест и применимы эти показатели “частота деплоя” и “время от коммита до продакшна” – на них влияет устройство всей организации целиком, а конвеер CI/CD оказался просто удобным инструментов для измерения этих параметров (и в меньшей степени влияния на них).

Кажется у всей истории с DevOps все еще просто ужасное позиционирование в пространстве концепций несмотря на все усилия DORA и отцов основателей.

Обсуждение на Facebook