Comments 6
Классная градация ;) религиозные фанатики — особенно точное сравнение!
А как вы считаете, какие индикаторы DevOps будут показательны?На мой взгляд, ключевой индикатор — это когда внедрение новых фич вообще никак не сказывается на стабильности продукта. Но это недостижимый идеал ИМО. Ну и не менее значимые это: скорость внедрения новых фич, качество кода (как инфраструктурного, так и продукта), покрытие тестами и минимизация bottle-necks.
Метки:
У Devops есть один необходимый показатель: time-to-market. Сколько прошло времени от идеи до продукта. Если это часы-дни, то девопс есть. Если это недели-месяц, то девопс может и есть, но не работает эффективно. Если это месяцы-год, то никакого девопса нет. Это не «достаточное» условие, но «необходимое». Если вы, предположим, вложили в девопс миллион и time-to-market улучшился с года до 11 месяцев, то вы выкинули миллион.
Остальные показатели и метрики интересны только в контексте «где болит» и «как исправить», причем, если «болит» не на критическом пути, то и приоритет исправления не высокий.
Остальные показатели и метрики интересны только в контексте «где болит» и «как исправить», причем, если «болит» не на критическом пути, то и приоритет исправления не высокий.
Я стесняюсь спросить но каким боком тут девопс? Если те самые идеи в головах бизнеса формулируются и превращаются в что то имеющее хотя бы форму юзер стори с непротиворечивыми акцептанс критериями иногда годами. Инженеры в своём большинстве понятия не имеют как это присходит и меряют тайм ту маркет от момента когда они видят юзер стори с макетами, а это процентов 10% от общего времени. И ускорение на жалкие проценты за счёт автоматизации развёртывания с точки зрения всего бизнеса являются исчезающие малыми. И никак не являются ключом к успеху компании.
Ну так девопс это не только, и не столько автоматизация сборки и развертывания. (Чтобы не было двоякого толкования: я под Devops понимаю примерно то, что изложено в «The DevOps Handbook» от Gene Kim. В этих терминах даже чисто технически автоматизация сборки и развертывания это меньше половины автоматизации)
На самом деле проблема долгого вызревания историй, она напрямую связана с большими итерациями и долгим циклом разработки, «мы долго придумываем и согласуем фичи, потому что их реализация займет год». Это такая взаимная индульгенция. За этими большими фичами теряются тонны тех мелочей, которые на самом деле и есть свидетельство качества. Дурацкое значение по умолчанию, странное поведение радиобаттонов, непоследовательные поля, необходимость три раза вводить одно и то же (вот, кстати, помню у покойного Трансаэро, кажется, всё вышеперечисленное на сайте было). Вроде и не критично, но ведь поправить каждое — реально час работы программиста. Но это не ставится в план, потому что «реализация займет год». А если процесс разработки, развертывания и эксплуатации быстрый и автоматизированный, то такие штуки могут исправляться быстро. Тогда начинается обратный процесс: «что там месяц думать, когда за это время мы три раза другое решение сможем реализвать», ну или не начинается, если проблема не в разработке в принципе. Но тогда и любые затраты на devops будут ненужными.
На самом деле проблема долгого вызревания историй, она напрямую связана с большими итерациями и долгим циклом разработки, «мы долго придумываем и согласуем фичи, потому что их реализация займет год». Это такая взаимная индульгенция. За этими большими фичами теряются тонны тех мелочей, которые на самом деле и есть свидетельство качества. Дурацкое значение по умолчанию, странное поведение радиобаттонов, непоследовательные поля, необходимость три раза вводить одно и то же (вот, кстати, помню у покойного Трансаэро, кажется, всё вышеперечисленное на сайте было). Вроде и не критично, но ведь поправить каждое — реально час работы программиста. Но это не ставится в план, потому что «реализация займет год». А если процесс разработки, развертывания и эксплуатации быстрый и автоматизированный, то такие штуки могут исправляться быстро. Тогда начинается обратный процесс: «что там месяц думать, когда за это время мы три раза другое решение сможем реализвать», ну или не начинается, если проблема не в разработке в принципе. Но тогда и любые затраты на devops будут ненужными.
Особенно улыбнул пассаж про пассионарность, Гумилева и суперэтнос…
Sign up to leave a comment.
Долгая дорога в дюнах, или как изменялась инженерная субкультура ЕФС