Индикаторы и метрики Devops | OTUS

Индикаторы и метрики Devops

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

EwlRV1NXEAECicd_1-20219-df13dc.jpg

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

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

dndyk2au0aai2yz_1-20219-b41126.jpg

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

Больше полезных материалов читайте в моем блоге https://timurb.ru/.

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться