I
Мне кажется это какой-то этап просветления, когда совсем не злишься и не хочется ругаться, когда читаешь очередную беседу с участием Олега)
😂😂😂😂
Size: a a a
2020 July 03
AB
Мне кажется это какой-то этап просветления, когда совсем не злишься и не хочется ругаться, когда читаешь очередную беседу с участием Олега)
надо просто побольше его читать
DS
Какая разница какое облако и облако ли вообще? Речь же о том что бы за конфигурирование, запуск и эксплуатацию кода была ответственность на тех кто его написал.
Если облака не вариант и надо строить на своём железе будь то экономические или юридические причины, то логичное решение создать "платформу" и команду ответственную за эту платформу.
В конце концов в облачных провайдерах есть специалисты у которых ответственность за то что бы платформа, который вы пользуетесь, работала
Если облака не вариант и надо строить на своём железе будь то экономические или юридические причины, то логичное решение создать "платформу" и команду ответственную за эту платформу.
В конце концов в облачных провайдерах есть специалисты у которых ответственность за то что бы платформа, который вы пользуетесь, работала
Полностью согласен. Облака - это всего лишь делегация ответственности за исполнение кода вовне. В подавляющем большинстве случаев она совершенно оправдана, но не всегда.
Ответственность девопса заключается в том, чтобы донести фидбек от среды до программиста. Здесь как раз практика You build it You run it очень полезна: она сокращает этот фидбек.
Если говорить более глубоко о принципе You build it You run it - он заканчивается ровно после run. После этого начинается длинный цикл эксплуатации. Который может длиться годами. Дольше, чем любой из авторов кода будет работать в компании. Кто-то должен отвечать за работу уже написанного кода в проде после того, как разраб выкатил артефакт, артефакт прошёл все тесты и был успешно задеплоен. Это команда эксплуатации. И (тадам) оказывается, что команда эксплуатации должна иметь полномочия, которые существенно превосходят полномочия разработчиков. По сути, разработчики должны подчиняться команде эксплуатации, просто потому что у команды эксплуатации связь с продом будет куда дольше и куда глубже. Соответственно - она гораздо ближе к клиентам, чем команда разработчиков. И на них больше ответственности.
Ответственность девопса заключается в том, чтобы донести фидбек от среды до программиста. Здесь как раз практика You build it You run it очень полезна: она сокращает этот фидбек.
Если говорить более глубоко о принципе You build it You run it - он заканчивается ровно после run. После этого начинается длинный цикл эксплуатации. Который может длиться годами. Дольше, чем любой из авторов кода будет работать в компании. Кто-то должен отвечать за работу уже написанного кода в проде после того, как разраб выкатил артефакт, артефакт прошёл все тесты и был успешно задеплоен. Это команда эксплуатации. И (тадам) оказывается, что команда эксплуатации должна иметь полномочия, которые существенно превосходят полномочия разработчиков. По сути, разработчики должны подчиняться команде эксплуатации, просто потому что у команды эксплуатации связь с продом будет куда дольше и куда глубже. Соответственно - она гораздо ближе к клиентам, чем команда разработчиков. И на них больше ответственности.
DB
надо просто побольше его читать
Какие побочки?
A
Мне кажется это какой-то этап просветления, когда совсем не злишься и не хочется ругаться, когда читаешь очередную беседу с участием Олега)
"В мире существуют два мнения: моё и неправильное".
😂
😂
A
Ничто не ново в этом мире
AB
Какие побочки?
в общем-то к любому жужжанию, если не дислоцироваться, рано или поздно привыкаешь и перестаёшь воспринимать, как жужжание, стараясь выделять нотки здравомыслия, которых немало пусть даже и весьма категоричных
DS
Если все разработчики продукта входят в команду эксплуатации, то это просто замечательно. В этом случае обратная связь для всех разрабов будет минимальной. Но это можно сделать только когда вопросы эксплуатации решены полностью. Когда, условно, ни один из клиентских запросов в техподдержку не доходит до разрабов, а решается максимум на третьей линии.
O
Если все разработчики продукта входят в команду эксплуатации, то это просто замечательно. В этом случае обратная связь для всех разрабов будет минимальной. Но это можно сделать только когда вопросы эксплуатации решены полностью. Когда, условно, ни один из клиентских запросов в техподдержку не доходит до разрабов, а решается максимум на третьей линии.
То есть никогда?
O
В концепции DevOps есть несколько важных особенностей, которые почему-то редко озвучиваются:
1. Нужны разработчики с сильно более широким спектром знаний, чем просто "код писать" (дороже, сложнее в поиске и вот это все)
2. Разработчики заканчиваются, то есть по мере того, как они пишут все больше и больше продуктов, у них все меньше времени чтобы их писать.
3. Ад как сложно разделить ответственность. Самая "на бумаге" рабочая схема - SRE а-ля Гугл. Но тут проблема с SRE, потому что их мало, они охренеть какие дорогие и внутри их выростить крайне сложно.
1. Нужны разработчики с сильно более широким спектром знаний, чем просто "код писать" (дороже, сложнее в поиске и вот это все)
2. Разработчики заканчиваются, то есть по мере того, как они пишут все больше и больше продуктов, у них все меньше времени чтобы их писать.
3. Ад как сложно разделить ответственность. Самая "на бумаге" рабочая схема - SRE а-ля Гугл. Но тут проблема с SRE, потому что их мало, они охренеть какие дорогие и внутри их выростить крайне сложно.
DS
То есть никогда?
Ну не. Когда для всех недоделанных фич и для обхода всех багов будут хотя бы написаны скрипты, которые саппорт третьей линии может сам запускать. Этого будет достаточно.
Но вообще, я вот вижу какой-то очень жёсткий конфликт между командой эксплуатации и командой разработки, который пока не могу решить:
В интересах разработчиков запилить как можно больше фич, чтобы переключиться уже на другой проект. Или лучше сказать, что в интересах разработчиков - как можно быстрее выкатить продукт.
В интересах команды эксплуатации - чтобы новых фич было как можно меньше, потому что усложнение системы по умолчанию увеличивает вероятность поломки.
Но вообще, я вот вижу какой-то очень жёсткий конфликт между командой эксплуатации и командой разработки, который пока не могу решить:
В интересах разработчиков запилить как можно больше фич, чтобы переключиться уже на другой проект. Или лучше сказать, что в интересах разработчиков - как можно быстрее выкатить продукт.
В интересах команды эксплуатации - чтобы новых фич было как можно меньше, потому что усложнение системы по умолчанию увеличивает вероятность поломки.
O
Я свои наблюдения озвучиваю, за 12 лет в эксплуатации в разных конторах от мелких до Яндекса и транснациональных корпов, и везде одни и те же проблемы по сути.
O
Ну не. Когда для всех недоделанных фич и для обхода всех багов будут хотя бы написаны скрипты, которые саппорт третьей линии может сам запускать. Этого будет достаточно.
Но вообще, я вот вижу какой-то очень жёсткий конфликт между командой эксплуатации и командой разработки, который пока не могу решить:
В интересах разработчиков запилить как можно больше фич, чтобы переключиться уже на другой проект. Или лучше сказать, что в интересах разработчиков - как можно быстрее выкатить продукт.
В интересах команды эксплуатации - чтобы новых фич было как можно меньше, потому что усложнение системы по умолчанию увеличивает вероятность поломки.
Но вообще, я вот вижу какой-то очень жёсткий конфликт между командой эксплуатации и командой разработки, который пока не могу решить:
В интересах разработчиков запилить как можно больше фич, чтобы переключиться уже на другой проект. Или лучше сказать, что в интересах разработчиков - как можно быстрее выкатить продукт.
В интересах команды эксплуатации - чтобы новых фич было как можно меньше, потому что усложнение системы по умолчанию увеличивает вероятность поломки.
тут стоит заменить s/в интересах разработчиков/в интересах бизнеса/g
DS
Ну не. Когда для всех недоделанных фич и для обхода всех багов будут хотя бы написаны скрипты, которые саппорт третьей линии может сам запускать. Этого будет достаточно.
Но вообще, я вот вижу какой-то очень жёсткий конфликт между командой эксплуатации и командой разработки, который пока не могу решить:
В интересах разработчиков запилить как можно больше фич, чтобы переключиться уже на другой проект. Или лучше сказать, что в интересах разработчиков - как можно быстрее выкатить продукт.
В интересах команды эксплуатации - чтобы новых фич было как можно меньше, потому что усложнение системы по умолчанию увеличивает вероятность поломки.
Но вообще, я вот вижу какой-то очень жёсткий конфликт между командой эксплуатации и командой разработки, который пока не могу решить:
В интересах разработчиков запилить как можно больше фич, чтобы переключиться уже на другой проект. Или лучше сказать, что в интересах разработчиков - как можно быстрее выкатить продукт.
В интересах команды эксплуатации - чтобы новых фич было как можно меньше, потому что усложнение системы по умолчанию увеличивает вероятность поломки.
Поэтому я вот не уверен, что если команда эксплуатации и разработки, в конце-концов, сольются в экстазе, то это приведёт к ускорению доставки фич.
O
Нет линейной зависимости между количеством фич (и их деплоем) и количеством сбоев, если мы говорим о современном CD. Средние показатели стабильности почти не меняются при частых деплоях, если некоторые из них сбоят.
DS
Хм, да, тут вы правы, понял.
O
Разломать все до критического состояния можно и деплоя раз в месяц 10 фич единовременно (причем с большим шансом), чем довозя 100, но по маленьку каждый день.
DS
В принципе, да. Тогда получается, что когда команда эксплуатации наладит CI/CD до приличной степени, то она смело может переключаться на фичи.
O
Я все это озвучиваю скорее к тому, что девопс это хорошо, но от эксплуатации по сути избавиться нельзя, иначе девелоперы разбегутся. Потому что те, кто умеет и в то, и в то на достаточном уровне попросят х3 к зарплате.
O
В принципе, да. Тогда получается, что когда команда эксплуатации наладит CI/CD до приличной степени, то она смело может переключаться на фичи.
По сути да. Тут организация процесса сильно важнее количественных метрик. Некоторые риски можно снять дополнительно через вендоров (облака не от хорошей жизни возникли то, на самом деле).