0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Большая ошибка многих рассуждающих в контексте DevOps о “снижении TTM” и необходимости “релизиться чаще” состоит в том, что они рассматривают частоту релизов и время “от коммита до продакшна” как технический показатель. В лучшем случае рассматривают с учетом простоев в цепочке поставке. Они считают, что если автоматизировать все, они смогут релизиться 100 раз в день и догонят и перегонят Google (конечно, для этого автоматизировать нужно “не просто так”, а “по-умному”).</p>
1
<p>Большая ошибка многих рассуждающих в контексте DevOps о “снижении TTM” и необходимости “релизиться чаще” состоит в том, что они рассматривают частоту релизов и время “от коммита до продакшна” как технический показатель. В лучшем случае рассматривают с учетом простоев в цепочке поставке. Они считают, что если автоматизировать все, они смогут релизиться 100 раз в день и догонят и перегонят Google (конечно, для этого автоматизировать нужно “не просто так”, а “по-умному”).</p>
2
<p>На деле же автоматизация на этот показатель влияет достаточно мало (больше влияет отсутствие автоматизации) и в современном мире эти показатели в гораздо большей степени определяют другие сущности в организации - социотехническая архитектура приложения (зависимости между командами разработки и их автономность) и планирование продуктового инкремента. Возможно еще что-то, что я плохо вижу прямо сейчас.</p>
2
<p>На деле же автоматизация на этот показатель влияет достаточно мало (больше влияет отсутствие автоматизации) и в современном мире эти показатели в гораздо большей степени определяют другие сущности в организации - социотехническая архитектура приложения (зависимости между командами разработки и их автономность) и планирование продуктового инкремента. Возможно еще что-то, что я плохо вижу прямо сейчас.</p>
3
<p>Все прямо по канонам Lean - после того, как мы устранили узкое место в инфраструктуре тут же обнаружились узкие места в других частях организации как системы. И для отслеживания поиска и устранения этих узких мест и применимы эти показатели “частота деплоя” и “время от коммита до продакшна” - на них влияет устройство всей организации целиком, а конвеер CI/CD оказался просто удобным инструментов для измерения этих параметров (и в меньшей степени влияния на них).</p>
3
<p>Все прямо по канонам Lean - после того, как мы устранили узкое место в инфраструктуре тут же обнаружились узкие места в других частях организации как системы. И для отслеживания поиска и устранения этих узких мест и применимы эти показатели “частота деплоя” и “время от коммита до продакшна” - на них влияет устройство всей организации целиком, а конвеер CI/CD оказался просто удобным инструментов для измерения этих параметров (и в меньшей степени влияния на них).</p>
4
<p>Кажется, у всей истории с DevOps все еще просто ужасное позиционирование в пространстве концепций несмотря на все усилия DORA и отцов-основателей.</p>
4
<p>Кажется, у всей истории с DevOps все еще просто ужасное позиционирование в пространстве концепций несмотря на все усилия DORA и отцов-основателей.</p>
5
<p><em>Больше полезных материалов читайте в моем блоге https://timurb.ru/.</em></p>
5
<p><em>Больше полезных материалов читайте в моем блоге https://timurb.ru/.</em></p>
6
6