Comments 6
Олегу, респектище! Из то, что сделал, и за то, что делишься тем, что сделал!!! Очень вдохновляет!!
Немного пропустил: "А куда девались DBA?", если остались только Платформа (бывший TECH) и Продукт (бывший SERVICE)? Стали Гильдией в Платформе?
И ещё: а не проще ли было бы решить проблему просто добавив людей в TECH изначально, без Spotify (а для этого что бы руководители идентифицировали недостающие компетенции)? Судя по "бывает, что у команды Platform что-то горит, есть другие дела и они долго согласовывают всё это", ограничение вашей системы как было на стороне бывшего TECH, так и осталось там же (возможно, лишь уменьшилось).
Привет. Это мой доклад с DevOps Conf, отвечу с личного аккаунта)
DBA по факту остались отдельной командой, которая существует рядом с platform devops. У них свой лид, свои правила работы с разработкой. Синхронизация идет на уровне архитекторов, а так же на уровне стратегии при работе со мной (рук направления)
Добавлению людей в TECH изначально, на наш взгляд, не дало бы повышения контекста с точки зрения продуктовой разработки. Да, мы бы быстрее закрывали задачи, но поддержка разработки была бы слабой.
По поводу узкого звена в platform team, к сожалению такие темы есть. Те же самые RFC бывает часто заваливаем по срокам, думаем что с этим делать.
Там походу у многих компаний эти истории постепенно должны вызревать, т.к девопс-платформ-итд движ у крупных игроков РФ будто бы в одну пятилетку начался. Кто посмелее - будут плавно делиться опытом. А так - все слона с разных концов есть пытаются, но в целом переменные будто бы одни и те же, поэтому всей индустрией куда-то движемся.
Как по мне, деятельность которая выделялась в DevOps - это некая специфичная ветвь программирования. Оно вдруг стало нужно-важно-и-вообще-возможно, теперь нам с этим жить, и пататься не скатываться в корпоративный ад. Для чего надо как-то удачно заложить в рабочие процессы не просто аджайл, а ещё и среду для оттачивания гипотез поверх которой будет нарастать культура безопасных изменений.
А так, по сбоям и инцидентам куда больше б хотелось увидеть были ли сдвиги во времени восстановления, реакции и перевода проблемы в незаметную для пользователей. Само по себе снижение сбоев ещё не гарантирует хорошей жизни. Может наоборот копится застой и стагнация, и в нехороший день X окажется что все уже и подзабыли как действовать.
Привет. Это мой доклад с DevOps Conf, отвечу с личного аккаунта)
По инцидентам. Сейчас к сожалению метрик на руках нет, но как я знаю, там все болтается в средних 1-2 часа для крупных сбоев и 10-30 минут для мелких. Я сейчас больше подключаюсь к работе с инцидентами, так что метрики будем собирать более внимательно. Стагнации точно нет.
DevOps-трансформация: как раздать инженеров по командам и не погибнуть