Так была реальная конкуренция, и годами рутуб во многом благодаря такой реальной конкуренции никому был не нужен. Хотя казалось бы можно было что-то придумать. Не блокировать, а сделать так, чтобы реклама и монетизация на ютуб была невозможной по закону. Хотя думаю даже такие травоядные меры далеко бы не все поддержали, потому что реально что-то свое у нас не умеют, не могут и не хотят развивать да и пользоваться своим многие как-то не спешат, что конечно грустно.
В общем тут даже по архитектуре сети видно, что проектом реально начали заниматься фактически последние пять лет, а до этого он жил по принципу пусть живёт работает, много денег у Газпрома не требует, вестимо.
Ну в общем по факту толку мало, все равно подозреваю, что большая часть траффика мимо них ходит, увы. Хотя тема конечно несколько холиварная, как правильно фаерволить траффик, похоже нгфв ответом на это точно не является.
Статья нравится. А ngfw норм нагрузку держат? Это что-то у вас на богатом всякие palo alto шкафы, или получилось траффик пропускать через какие-нибудь ngfw построенные на базе dpdk?
На каком-то очередном абзаце, читая множество разных заумных слов выставленных к месту и не к месту, бесконечных ссылок на "авторитетные" опросы ознакомиться с которыми впрочем невозможно, я наконец понял, что читаю какую-то чатгпт-сгенерированную статью.
Конечно, тема несомненно интересная, но попробуйте все же хотя бы написать её самостоятельно.
Никаких технических подробностей, а хотелось бы узнать как это делается во "взрослом" проекте. Я-то свой простенький сервер поднимал, и ничего интересного, увы, из статьи не вынес.
Вот в качестве упражнения на досуге, ответьте, что вы думаете по поводу шардированного майна по типу проекта https://github.com/MultiPaper/MultiPaper? А как насчёт того, чтобы майн запихнуть в кубер? Почему да и почему нет? И как бы решали подобную задачу? Какие есть особенности тюнинга майна (всеми любимая жава с тысячами разных параметров и разными гс), что в первую очередь требуется потрогать, чтобы из-за взрыва сотен тнт сервер не падал? Какие стандартные настройки вы бы включили на сервере/установили нужные плагины, чтобы его не сломали за один вечер парочка скучающих школьников? Резервирование и восстановление мира (эксплоиты для серверов майна не такая и редкость, и лучше иметь бэкап на готове), как лучше это сделать? А как правильно мониторить работу сервера и на что смотреть?
Вот ответы хотя бы на эти вопросы дали бы огромную пищу для размышлений и позволили бы действительно запустить сервер в майнкрафте :)
>Человек в свои 18 сделал то, что вы в свои 35 хрен сделали, а вы завидуете и пишете всякую чушь
Тут завидовать нечему. Можно лишь умиляться.
Мне бы его 2 RPS честное слово. Жизнь была бы просто шикарной. А нет, хотел себе хайлоад, теперь вот вместо статей на хабре занимаюсь хайлоадом по полной программе.
>Devops-инжинер - звучит гордо. Только не надо заблуждаться. Чтобы насадить культуру ДевОпс инженером должен быть психолог, т.к. речь про поведение людей и групп
Это вообще так не работает. Культуру невозможно насадить, её можно только вырастить внутри. Честно говоря реальный девопс я мало где видел, не в части наличия каких-то автоматизаций, а именно как культуру разработки и не представляю даже близко, как это делается.
Я сам участвовал в проекте, где девопс действительно насадили причём в формате безальтернативно взяли и забрали доступ от продакшена (таковы были требования ИБ). К сожалению, но по итогу понимания что это и зачем даже спустя несколько лет пришло далеко не всем. Осталось не мало людей для которых не иронично "гит не инструмент разработчика" и вообще верните нам лучше доступ к нашим базам в продакшене (речь про DWH-аналитиков, если что).
Думаю, что подобное разделение чистая условность. Или если хотите маркетинговый ход. Платят больше денег за то, чтобы меня называли DevOps или SRE - и ладно.
Вот я был системным администратором все последние десять лет. Я занимался плюс-минус похожими вещами в разных направлениях и в разных компаниях. Если объяснить бизнесу что на самом деле админ и 10 лет назад умел поддерживать инфру, писал какую-то автоматизацию, занимался мониторингом, то их думаю данная мысль сведёт с ума.
Речь о том, что в целом частые релизы ником образом не снижают риски и не свидетельствуют об наличии автоматизированного тестирования. Сто быстрых выкаток могут быть не менее опасными, чем одна выкатка в месяц.
>Странный у вас "очень крупный финтех", если никакого тестирования перед продом не происходит, ни с вашей стороны ни с стороны заказчика (если он есть)
Там было некоторое приёмочное тестирование для отдельных принятых на сопровождение сервисов, но в чем оно заключалось сказать сложно. Я в целом не очень уверен, что оно велось в достаточной степени, скорее типичные банковские потемкинские деревни.
>Я тоже из этой области, и вот когда мы делали для банка приложение, которое просто по сути делала отчёты анализируя их проводки, они перед продом это всё месяц гоняли на тестовой базе
Ну банк это история смешная. Где-то у вас будет чуть ли не доскональное тестирование, а где-то оно будет отсутствовать в принципе, тк разработчики и заказчики так привыкли, им обязательно надо как можно более быстро выводить изменения. Вообще всегда когда раздаётся странный возглас надо быстрее всегда следует задать вопрос - зачем, какую проблему решаем, нет ли здесь проблемы с тем, что у людей чисто организационные проблемы, что у них плохо в целом с планированием, и они пытаются решить не ту проблему?
>Возможность релизить часто означает, что у вас маленькие, изолированные изменения, хороший уровень автоматизации и тестирования, это снижает риски
На практике, к сожалению, но частота релизов может быть индикатором как раз наоборот особенно дерьмовых процессов, когда менеджменту всегда надо ещё вчера, а как оно там у айти работает их совершенно не касается, и тогда ваш быстрый девопс ничем не лучше становится прямого доступа к продакшену разработчикам.
На моем проекте (очень крупный финтех) мы добились впечатляющей автоматизации, когда в целом изменение пусть и в качестве хотфикса можно было вывести за один час. А всего у нас в день через нашу автоматизацию успешно ставилось на продакшен несколько десятков релизов и ещё несколько сотен параллельно ставились на разные другие среды. Вы думаете у нас было тестирование? Или возможность быстро выводить снизило какие-то в сущности риски благодаря инкрементным изменениям? К сожалению, но это даже близко было не так. По факту мы просто дали разработчикам вместо прямого доступа к проду ровно такой же аналогичный прямой доступ к проду, но только через нашу трубу, и в головах собственно это и осталось, что это просто палка-копалка для доступа к проду.
В общем как и всегда проблема вовсе не в клозетах.
Ну в целом кто пользуется neovim действительно вряд ли нуждается в каких-то IDE, но тут уж вопрос вкусов, что считать нормальной IDE. Боюсь, что не все согласятся с вами. Даже в контексте VS Code.
>Продолжает кодить и переусложнять. Ещё, зараза такая, обязательно постарается впихнуть то, чему в инфре не место, типа раста или котлина, которые кроме него никто в команде не знает. На вопрос, мол, а что не питон-то, начинает тираду про то что питон говно и вообще. На то что никто не будет после его ухода это поддерживать фыркает и говорит что ничего, перепишите. Ну не чудак ли?
А парень ироничный попался. Обычно ведь как бывает. Разработчик говорит, что надо делать так и так, и будет нам всем счастье, а разработчику на это отвечают "Вася, все горит, давай в прод, потом если что проект перепишем". По итогу конечно никто никому рефакторинг проводить не дает, и все костыли живут до скончания времен, пока наконец сервис не складывается окончательно. А тут вам разработчик заявляет, что сделал все как надо, потом хотите переписывайте сами без меня. Умный, видно уже попадался на такие приколы, по ночам работать не хочет.
>Типичная позиция вчерашнего сисадмина: как задачу поставили, так и сделал. Но уточнять такие детали — это зона ответственности девопса, это он должен быть инициатором коммуникации
Не должен. Вы как инициатор задачи заинтересованы, чтобы она была сделана так, как вам это необходимо в рамках тех заложенных сроков, что у вас есть. Тут соре работает правило shit in -> shit out. Или разработчикам вы также ТЗ ставите, а выяснять что хотел заказчик должен сам разработчик? Если так, то у вас неправильно выстроены процессы разработки.
>Разработчики привыкли к детерминированности их вселенной: есть ТЗ — работаем по ТЗ. У DevOps зачастую задача поставлена высокоуровнево, а вот на какие грабли придется наступить в процессе — будет ясно только по факту.
Я оказался выше прав. Вы знаете, но в былые времена я слышал такую замечательную присказку, о которой также поделюсь с вами "без тз - результат хз". Она справедлива и в случае тех кто занимается эксплуатацией, и тех кто занимается разработкой. Это в общем-то как менеджера ваша задача, вы ее пытаетесь свалить на каких-то других людей и удивляетесь, что такой подход не работает.
>Если задача сформулирована «поднять сервис», он должен найти или запросить архитектурную схему проекта, выяснить, как и с чем будет взаимодействовать этот сервис, понять, какая нужна доступность (SLA) и т. п. От всех этих деталей зависит архитектура, и увы, никто не принесет их ему на блюдечке. Информацию придется добывать самостоятельно, поскольку это требования бизнеса к нему, как DevOps‑инженеру. По сути он сам должен быть немного архитектором, который может спроектировать отказоустойчивый сервис, а потом еще и помочь разработке сделать его действительно таковым. Ведь разработчики иногда совершают типичные ошибки, отражающиеся на отказоустойчивости, так что DevOps выступает еще и своего роля инструментом контроля качества.
Ну опять же у вас явно нет отдельно человека, который был бы занят архитектурой, нет аналитиков, которые бы уточняли требования, вы все спихиваете на какого-то мифического девопса, который все должен сделать и даже немного больше. Но так в жизни не работает, либо работает, но тогда такому специалисту вы вынуждены платить прямо-таки конский ценник (обычно речь про какого-то консультанта, которого вы приглашаете на проект, и он вам все такое делает под ключ), поскольку чисто из моего опыта есть полно мест, где таких требований не предъявляются, где роли распределены, а зоны отвественности устаканены, а сам процесс разработки и вывода в эксплуатацию согласован со всеми заинтересованными сторонами. Вообще это решается по-другому. Есть четкий чеклист "принятия сервиса в эксплуатацию", там обычно расписано что требуется, чтобы сервис можно было использовать в продакшене, а девопс в случае проблем смог бы подключиться и их решить, там как раз все эти моменты с SLA, отказоустойчивостью, деталей реализации архитектуры, а также многие другие важные вещи описаны, и заранее все стороны знают, что от них требуется. Вас могут за ручку провести в продакшен, но, например, ручки с метриками и правильный формат логов хоть убейте придется делать не девопсам, а разработчикам. В общем и целом, если работа построена правильно, если есть процесс, есть заявки с четким ТЗ, есть необходимые чеклисты, то никаких проблем не возникнет, в случае отсутствия всего вышегоперечисленного и формата работы "зачастую задача поставлена высокоуровнево, а вот на какие грабли придется наступить в процессе — будет ясно только по факту" будет масса сплошных неожиданностей, возникающих вследствие непонимания SDLC некоторыми менедежрами.
>Есть еще один путь — представитель техподдержки, который развился в DevOps. Причем, речь идет о классической техподдержке, например, оператора связи — т. е. о людях, помогающих решить вопросы по телефону, занимаются настройкой сетей и т. п., которым приходится много траблшутить и коммуницировать. Это может быть третья линия какого‑нибудь хостинга — ребята, которые каждый день решают бесконечную реку проблем. Но не просто решают, а потом еще и объясняют клиенту, что именно они сделали. С моей точки зрения статистически на этом пути чаще рождаются хорошие девопсы.
Ну и как вишенка на торте - вы видите в роли девопса человека уровня принеси-подай-иди-нафиг-не-мешай. Напоминаю, что этим специалистам вы платите огромные деньги за умение решать очень сложные вещи в очень сжатые сроки, у многих из этих специалистов реальное высшее образование, подкрепленное годами реальной практики, а иногда весь ваш бизнес буквально может от такого человека зависеть. Возможно, вам стоит подумать, что все-таки, если девопсы\разработчики так работают, то этому есть объяснение помимо того, что они все чудаки, и все делают неправильно, а вы сейчас их научите как верно им работать. Возможно, это вы все делаете неправильно. Почитайте, например, мифический человеко-месяц, там вообще говоря хорошо объяснены все трудности, которые возинкают в ходе разработки любого продукта. Хоть книжке уже несколько десятков лет, а очень свежо читается особенно в контексте вашего понимания, как должна быть устроена разработка и эксплуатация.
>а не дай бог снимут животворящие и беззубые санкции
Скромно напоминаю, что на несчастную поправку Джексона-Вэника принятую в 1974 наложили мораторий только в 1989 году, а окончательно отменили только в 2012 (и то потому что приняли акт Магнитского). Конечно, аналогия не доказательство, но не думаю, что в этот раз произойдёт как-то иначе. Это, увы, надолго. Скорее всего на следующие лет двадцать.
Не очень если честно понятно зачем продолжать рекламировать на хабре человека, который продает людям воздух. Его уже здесь отправили в рид-онли на хабре, хочется спросить @moderator не пора ли начать блокировать и его виртуалов? Развивайте, пожалуйста, свои "личные бренды" в другом месте.
Рубрика: каждые пять лет в сбере обязательно кто-то приходит, и требует срочно переделать все. Зачем, почему, какие у этого будут трудозатраты - не важно. Просто надо.
Казалось бы сами пишите: "В проекте, который изначально запускали на вполне нормальном техстеке — Scala, Akka, Akka HTTP". А в чем проблема заняться рефакторингом? Стек нормальный. а основная боль судя по всему в том, что "через четыре года разработки периодически меняющейся командой подрядчиков появился зоопарк из Akka, Akka HTTP, Akka Streams, Cats, Zio, Monix, Scalike jDBC, Quill, Monocle, Tapir, Play, Circe и ещ` десятка малоизученных эзотерических библиотек суммарно с сотней звёзд на Github".
Ради этого надо было все тащить в кубер, переделывать монолит на микросервисы, полностью менять техстек?
Итог неутешительный: "Почти полностью сменился состав команды backend-разработки". И все ради того, чтобы в среднем увеличилось производительность REST в 1,5—2 раза, чего бы вы добились с куда меньшими трудозатрами, просто по-нормальному текущий проект переписав.
К тому, что было высказано до меня, я бы хотел вот что ещё добавить от себя лично.
Большая проблема, что если с горем пополам чем занимаются программисты понятно, то объяснить чем занимаются люди ответственные за эксплуатацию для менеджмента сложнее. Вы не понимаете проблем и задач эксплуатации, поэтому вам и кажется, что они что-то делают неправильно, но в общем все ровным счётом наоборот.
В свое время я начинал один свой проект с того, что не было ни тикетов, ни малейшей бюрократии, по итогу триста человек начали звонить, писать, а то и ходить ногами. И при этом остальная работа никуда не исчезла. Это безусловно было очень удобно для моих коллег, правда вся моя работа фактически вставала, это вело к огромным переработкам, к необходимости бежать в два раза быстрее, чтобы двигаться вперёд, чтобы успеть все, при этом документально куда тратится моё рабочее время я ничем не мог подтвердить.
На хабре есть полно статей, где люди также пришли к тикетам, чтобы хотя бы как-то было возможно планировать работу, фиксировать задачи и отчитываться о результатах своей детальности. Это делается не из-за большой прихоти, не для желания отгородиться, а потому что жизнь заставила.
Так была реальная конкуренция, и годами рутуб во многом благодаря такой реальной конкуренции никому был не нужен. Хотя казалось бы можно было что-то придумать. Не блокировать, а сделать так, чтобы реклама и монетизация на ютуб была невозможной по закону. Хотя думаю даже такие травоядные меры далеко бы не все поддержали, потому что реально что-то свое у нас не умеют, не могут и не хотят развивать да и пользоваться своим многие как-то не спешат, что конечно грустно.
В общем тут даже по архитектуре сети видно, что проектом реально начали заниматься фактически последние пять лет, а до этого он жил по принципу пусть живёт работает, много денег у Газпрома не требует, вестимо.
Ну в общем по факту толку мало, все равно подозреваю, что большая часть траффика мимо них ходит, увы. Хотя тема конечно несколько холиварная, как правильно фаерволить траффик, похоже нгфв ответом на это точно не является.
Благодарю за такой развёрнутый ответ и ссылку на другую вашу статью, было очень познавательно :)
Статья нравится. А ngfw норм нагрузку держат? Это что-то у вас на богатом всякие palo alto шкафы, или получилось траффик пропускать через какие-нибудь ngfw построенные на базе dpdk?
На каком-то очередном абзаце, читая множество разных заумных слов выставленных к месту и не к месту, бесконечных ссылок на "авторитетные" опросы ознакомиться с которыми впрочем невозможно, я наконец понял, что читаю какую-то чатгпт-сгенерированную статью.
Конечно, тема несомненно интересная, но попробуйте все же хотя бы написать её самостоятельно.
Честно сказать статья откровенно проходная :)
Никаких технических подробностей, а хотелось бы узнать как это делается во "взрослом" проекте. Я-то свой простенький сервер поднимал, и ничего интересного, увы, из статьи не вынес.
Вот в качестве упражнения на досуге, ответьте, что вы думаете по поводу шардированного майна по типу проекта https://github.com/MultiPaper/MultiPaper? А как насчёт того, чтобы майн запихнуть в кубер? Почему да и почему нет? И как бы решали подобную задачу? Какие есть особенности тюнинга майна (всеми любимая жава с тысячами разных параметров и разными гс), что в первую очередь требуется потрогать, чтобы из-за взрыва сотен тнт сервер не падал? Какие стандартные настройки вы бы включили на сервере/установили нужные плагины, чтобы его не сломали за один вечер парочка скучающих школьников? Резервирование и восстановление мира (эксплоиты для серверов майна не такая и редкость, и лучше иметь бэкап на готове), как лучше это сделать? А как правильно мониторить работу сервера и на что смотреть?
Вот ответы хотя бы на эти вопросы дали бы огромную пищу для размышлений и позволили бы действительно запустить сервер в майнкрафте :)
>Человек в свои 18 сделал то, что вы в свои 35 хрен сделали, а вы завидуете и пишете всякую чушь
Тут завидовать нечему. Можно лишь умиляться.
Мне бы его 2 RPS честное слово. Жизнь была бы просто шикарной. А нет, хотел себе хайлоад, теперь вот вместо статей на хабре занимаюсь хайлоадом по полной программе.
>Devops-инжинер - звучит гордо. Только не надо заблуждаться. Чтобы насадить культуру ДевОпс инженером должен быть психолог, т.к. речь про поведение людей и групп
Это вообще так не работает. Культуру невозможно насадить, её можно только вырастить внутри. Честно говоря реальный девопс я мало где видел, не в части наличия каких-то автоматизаций, а именно как культуру разработки и не представляю даже близко, как это делается.
Я сам участвовал в проекте, где девопс действительно насадили причём в формате безальтернативно взяли и забрали доступ от продакшена (таковы были требования ИБ). К сожалению, но по итогу понимания что это и зачем даже спустя несколько лет пришло далеко не всем. Осталось не мало людей для которых не иронично "гит не инструмент разработчика" и вообще верните нам лучше доступ к нашим базам в продакшене (речь про DWH-аналитиков, если что).
Думаю, что подобное разделение чистая условность. Или если хотите маркетинговый ход. Платят больше денег за то, чтобы меня называли DevOps или SRE - и ладно.
Вот я был системным администратором все последние десять лет. Я занимался плюс-минус похожими вещами в разных направлениях и в разных компаниях. Если объяснить бизнесу что на самом деле админ и 10 лет назад умел поддерживать инфру, писал какую-то автоматизацию, занимался мониторингом, то их думаю данная мысль сведёт с ума.
Никакого вопроса доверия не стоит в принципе.
Речь о том, что в целом частые релизы ником образом не снижают риски и не свидетельствуют об наличии автоматизированного тестирования. Сто быстрых выкаток могут быть не менее опасными, чем одна выкатка в месяц.
>Странный у вас "очень крупный финтех", если никакого тестирования перед продом не происходит, ни с вашей стороны ни с стороны заказчика (если он есть)
Там было некоторое приёмочное тестирование для отдельных принятых на сопровождение сервисов, но в чем оно заключалось сказать сложно. Я в целом не очень уверен, что оно велось в достаточной степени, скорее типичные банковские потемкинские деревни.
>Я тоже из этой области, и вот когда мы делали для банка приложение, которое просто по сути делала отчёты анализируя их проводки, они перед продом это всё месяц гоняли на тестовой базе
Ну банк это история смешная. Где-то у вас будет чуть ли не доскональное тестирование, а где-то оно будет отсутствовать в принципе, тк разработчики и заказчики так привыкли, им обязательно надо как можно более быстро выводить изменения. Вообще всегда когда раздаётся странный возглас надо быстрее всегда следует задать вопрос - зачем, какую проблему решаем, нет ли здесь проблемы с тем, что у людей чисто организационные проблемы, что у них плохо в целом с планированием, и они пытаются решить не ту проблему?
>Возможность релизить часто означает, что у вас маленькие, изолированные изменения, хороший уровень автоматизации и тестирования, это снижает риски
На практике, к сожалению, но частота релизов может быть индикатором как раз наоборот особенно дерьмовых процессов, когда менеджменту всегда надо ещё вчера, а как оно там у айти работает их совершенно не касается, и тогда ваш быстрый девопс ничем не лучше становится прямого доступа к продакшену разработчикам.
На моем проекте (очень крупный финтех) мы добились впечатляющей автоматизации, когда в целом изменение пусть и в качестве хотфикса можно было вывести за один час. А всего у нас в день через нашу автоматизацию успешно ставилось на продакшен несколько десятков релизов и ещё несколько сотен параллельно ставились на разные другие среды. Вы думаете у нас было тестирование? Или возможность быстро выводить снизило какие-то в сущности риски благодаря инкрементным изменениям? К сожалению, но это даже близко было не так. По факту мы просто дали разработчикам вместо прямого доступа к проду ровно такой же аналогичный прямой доступ к проду, но только через нашу трубу, и в головах собственно это и осталось, что это просто палка-копалка для доступа к проду.
В общем как и всегда проблема вовсе не в клозетах.
Ну в целом кто пользуется neovim действительно вряд ли нуждается в каких-то IDE, но тут уж вопрос вкусов, что считать нормальной IDE. Боюсь, что не все согласятся с вами. Даже в контексте VS Code.
>Продолжает кодить и переусложнять. Ещё, зараза такая, обязательно постарается впихнуть то, чему в инфре не место, типа раста или котлина, которые кроме него никто в команде не знает. На вопрос, мол, а что не питон-то, начинает тираду про то что питон говно и вообще. На то что никто не будет после его ухода это поддерживать фыркает и говорит что ничего, перепишите. Ну не чудак ли?
А парень ироничный попался. Обычно ведь как бывает. Разработчик говорит, что надо делать так и так, и будет нам всем счастье, а разработчику на это отвечают "Вася, все горит, давай в прод, потом если что проект перепишем". По итогу конечно никто никому рефакторинг проводить не дает, и все костыли живут до скончания времен, пока наконец сервис не складывается окончательно. А тут вам разработчик заявляет, что сделал все как надо, потом хотите переписывайте сами без меня. Умный, видно уже попадался на такие приколы, по ночам работать не хочет.
>Типичная позиция вчерашнего сисадмина: как задачу поставили, так и сделал. Но уточнять такие детали — это зона ответственности девопса, это он должен быть инициатором коммуникации
Не должен. Вы как инициатор задачи заинтересованы, чтобы она была сделана так, как вам это необходимо в рамках тех заложенных сроков, что у вас есть. Тут соре работает правило shit in -> shit out. Или разработчикам вы также ТЗ ставите, а выяснять что хотел заказчик должен сам разработчик? Если так, то у вас неправильно выстроены процессы разработки.
>Разработчики привыкли к детерминированности их вселенной: есть ТЗ — работаем по ТЗ. У DevOps зачастую задача поставлена высокоуровнево, а вот на какие грабли придется наступить в процессе — будет ясно только по факту.
Я оказался выше прав. Вы знаете, но в былые времена я слышал такую замечательную присказку, о которой также поделюсь с вами "без тз - результат хз". Она справедлива и в случае тех кто занимается эксплуатацией, и тех кто занимается разработкой. Это в общем-то как менеджера ваша задача, вы ее пытаетесь свалить на каких-то других людей и удивляетесь, что такой подход не работает.
>Если задача сформулирована «поднять сервис», он должен найти или запросить архитектурную схему проекта, выяснить, как и с чем будет взаимодействовать этот сервис, понять, какая нужна доступность (SLA) и т. п. От всех этих деталей зависит архитектура, и увы, никто не принесет их ему на блюдечке. Информацию придется добывать самостоятельно, поскольку это требования бизнеса к нему, как DevOps‑инженеру. По сути он сам должен быть немного архитектором, который может спроектировать отказоустойчивый сервис, а потом еще и помочь разработке сделать его действительно таковым. Ведь разработчики иногда совершают типичные ошибки, отражающиеся на отказоустойчивости, так что DevOps выступает еще и своего роля инструментом контроля качества.
Ну опять же у вас явно нет отдельно человека, который был бы занят архитектурой, нет аналитиков, которые бы уточняли требования, вы все спихиваете на какого-то мифического девопса, который все должен сделать и даже немного больше. Но так в жизни не работает, либо работает, но тогда такому специалисту вы вынуждены платить прямо-таки конский ценник (обычно речь про какого-то консультанта, которого вы приглашаете на проект, и он вам все такое делает под ключ), поскольку чисто из моего опыта есть полно мест, где таких требований не предъявляются, где роли распределены, а зоны отвественности устаканены, а сам процесс разработки и вывода в эксплуатацию согласован со всеми заинтересованными сторонами. Вообще это решается по-другому. Есть четкий чеклист "принятия сервиса в эксплуатацию", там обычно расписано что требуется, чтобы сервис можно было использовать в продакшене, а девопс в случае проблем смог бы подключиться и их решить, там как раз все эти моменты с SLA, отказоустойчивостью, деталей реализации архитектуры, а также многие другие важные вещи описаны, и заранее все стороны знают, что от них требуется. Вас могут за ручку провести в продакшен, но, например, ручки с метриками и правильный формат логов хоть убейте придется делать не девопсам, а разработчикам. В общем и целом, если работа построена правильно, если есть процесс, есть заявки с четким ТЗ, есть необходимые чеклисты, то никаких проблем не возникнет, в случае отсутствия всего вышегоперечисленного и формата работы "зачастую задача поставлена высокоуровнево, а вот на какие грабли придется наступить в процессе — будет ясно только по факту" будет масса сплошных неожиданностей, возникающих вследствие непонимания SDLC некоторыми менедежрами.
>Есть еще один путь — представитель техподдержки, который развился в DevOps. Причем, речь идет о классической техподдержке, например, оператора связи — т. е. о людях, помогающих решить вопросы по телефону, занимаются настройкой сетей и т. п., которым приходится много траблшутить и коммуницировать. Это может быть третья линия какого‑нибудь хостинга — ребята, которые каждый день решают бесконечную реку проблем. Но не просто решают, а потом еще и объясняют клиенту, что именно они сделали. С моей точки зрения статистически на этом пути чаще рождаются хорошие девопсы.
Ну и как вишенка на торте - вы видите в роли девопса человека уровня принеси-подай-иди-нафиг-не-мешай. Напоминаю, что этим специалистам вы платите огромные деньги за умение решать очень сложные вещи в очень сжатые сроки, у многих из этих специалистов реальное высшее образование, подкрепленное годами реальной практики, а иногда весь ваш бизнес буквально может от такого человека зависеть. Возможно, вам стоит подумать, что все-таки, если девопсы\разработчики так работают, то этому есть объяснение помимо того, что они все чудаки, и все делают неправильно, а вы сейчас их научите как верно им работать. Возможно, это вы все делаете неправильно. Почитайте, например, мифический человеко-месяц, там вообще говоря хорошо объяснены все трудности, которые возинкают в ходе разработки любого продукта. Хоть книжке уже несколько десятков лет, а очень свежо читается особенно в контексте вашего понимания, как должна быть устроена разработка и эксплуатация.
Это другое!
>а не дай бог снимут животворящие и беззубые санкции
Скромно напоминаю, что на несчастную поправку Джексона-Вэника принятую в 1974 наложили мораторий только в 1989 году, а окончательно отменили только в 2012 (и то потому что приняли акт Магнитского). Конечно, аналогия не доказательство, но не думаю, что в этот раз произойдёт как-то иначе. Это, увы, надолго. Скорее всего на следующие лет двадцать.
Не очень если честно понятно зачем продолжать рекламировать на хабре человека, который продает людям воздух. Его уже здесь отправили в рид-онли на хабре, хочется спросить @moderator не пора ли начать блокировать и его виртуалов? Развивайте, пожалуйста, свои "личные бренды" в другом месте.
Рубрика: каждые пять лет в сбере обязательно кто-то приходит, и требует срочно переделать все. Зачем, почему, какие у этого будут трудозатраты - не важно. Просто надо.
Казалось бы сами пишите: "В проекте, который изначально запускали на вполне нормальном техстеке — Scala, Akka, Akka HTTP". А в чем проблема заняться рефакторингом? Стек нормальный. а основная боль судя по всему в том, что "через четыре года разработки периодически меняющейся командой подрядчиков появился зоопарк из Akka, Akka HTTP, Akka Streams, Cats, Zio, Monix, Scalike jDBC, Quill, Monocle, Tapir, Play, Circe и ещ` десятка малоизученных эзотерических библиотек суммарно с сотней звёзд на Github".
Ради этого надо было все тащить в кубер, переделывать монолит на микросервисы, полностью менять техстек?
Итог неутешительный: "Почти полностью сменился состав команды backend-разработки". И все ради того, чтобы в среднем увеличилось производительность REST в 1,5—2 раза, чего бы вы добились с куда меньшими трудозатрами, просто по-нормальному текущий проект переписав.
К тому, что было высказано до меня, я бы хотел вот что ещё добавить от себя лично.
Большая проблема, что если с горем пополам чем занимаются программисты понятно, то объяснить чем занимаются люди ответственные за эксплуатацию для менеджмента сложнее. Вы не понимаете проблем и задач эксплуатации, поэтому вам и кажется, что они что-то делают неправильно, но в общем все ровным счётом наоборот.
В свое время я начинал один свой проект с того, что не было ни тикетов, ни малейшей бюрократии, по итогу триста человек начали звонить, писать, а то и ходить ногами. И при этом остальная работа никуда не исчезла. Это безусловно было очень удобно для моих коллег, правда вся моя работа фактически вставала, это вело к огромным переработкам, к необходимости бежать в два раза быстрее, чтобы двигаться вперёд, чтобы успеть все, при этом документально куда тратится моё рабочее время я ничем не мог подтвердить.
На хабре есть полно статей, где люди также пришли к тикетам, чтобы хотя бы как-то было возможно планировать работу, фиксировать задачи и отчитываться о результатах своей детальности. Это делается не из-за большой прихоти, не для желания отгородиться, а потому что жизнь заставила.