притащили
чудесное (конечно, я же там участвовал)
хочу прокомментировать то, что увидел и что происходит в головах общества.
однако, сразу осекусь: я и с devops раньше борцунствовал, но если всем ок сисадминам платить большие зарплаты, не получая практик — то кто я такой, чтобы с этим бороться?
(я сыч, я всю спикерскую деятельность на это положил и буду продолжать)Кто отвечает за надёжность?тут я хочу ответить просто и коротко: YBIYRI. а в ответах даже нет "разработчик сервиса"))) это как?)
то что SRE это молодая роль — в первую очередь заслуга размытия понимания роли как таковой. devops и SRE это вообще синонимы. в проде что-то полетело — зовите опсов (а это кто? SRE или devops? а может вообще sysops?), а если у вас облачная инфраструктура и managed сервисы? кого звать?
и как следствие — компаниям нужен универсал, понимающий код и подтиряющий сопельки + тот, кто напишет пайп и закрутит все гайки безопасности. да, это SRE)
про вкатунов и "я за три года до сеньора" — не буду.
девятки после запятой и девятки до запятой — это задача не SRE, а CTO.
дальше в отчете идет статистика по количеству SRE на компанию. и тут я не могу не вспомнить вопрос с собеседований "сколько должно быть инженеров на разработчика?" или правильнее сказать "сколько разработчиков у одного инженера?".
мое правило: коэффициент 0,1 — 10% должен быть инженерный состав, всё что ниже — будет отзываться так или иначе. хотя, правильнее было бы построить кривую зависимости. ну и отдать должное разным организационным подходам и практикам. чем лучше — тем проще и спокойнее инженеру и коэффициент можно уменьшить)
самое забавное что я слышал про SRE — что это девопс с дежуркой) но дежурка есть у всех и отчет это подтверждает. помимо дежурки, конечно, есть и инцидент и проблем-менеджмент (о них мы еще точно поговорим и не раз). но в отчете мне бросилось в глаза что упор на автоматизацию рутины делают... сисдамины! да-да! тогда как платформенных инженеров заставляют участвовать в он-коллах) что происходит с рынком?
пункты про сложность отстаивания своего мнения я спишу на плохие процессы, которые не позволяют каждому открыто и прозрачно влиять на инженерные и архитектурные решения (опять же, процессная проблема)
разумеется, более половины (хаха, статистика, 51%) не разделяют SRE и devops. да и зачем? ведь это всё просто фильтр, на деле люди одинаковые и работают одинаково? о, нет) о, нет! это не так. и ведь дальше раскрывается почему:
- операционка
- разрыв контекста
- нет денег на разделение
догадаетесь, что тут будет ключом к успеху?
и что меня расстроило больше всего в этом отчете — так это то6 что лишь в 2,5% случаев за инциденты и дежурства по сервису отвечает сама разработка (первичное реагирование). и, как следствие — лишь у полвины описаны инструкции и ранбуки по инцидентам.
но ладно, радует что об этом говорят и смотрят на ситуацию с разных сторон.
что ж, добро пожаловать в эру, когда мы (я) будем рассказывать и про
CRE. пристегивайтесь, будет душно.
