>Возможность релизить часто означает, что у вас маленькие, изолированные изменения, хороший уровень автоматизации и тестирования, это снижает риски
На практике, к сожалению, но частота релизов может быть индикатором как раз наоборот особенно дерьмовых процессов, когда менеджменту всегда надо ещё вчера, а как оно там у айти работает их совершенно не касается, и тогда ваш быстрый девопс ничем не лучше становится прямого доступа к продакшену разработчикам.
На моем проекте (очень крупный финтех) мы добились впечатляющей автоматизации, когда в целом изменение пусть и в качестве хотфикса можно было вывести за один час. А всего у нас в день через нашу автоматизацию успешно ставилось на продакшен несколько десятков релизов и ещё несколько сотен параллельно ставились на разные другие среды. Вы думаете у нас было тестирование? Или возможность быстро выводить снизило какие-то в сущности риски благодаря инкрементным изменениям? К сожалению, но это даже близко было не так. По факту мы просто дали разработчикам вместо прямого доступа к проду ровно такой же аналогичный прямой доступ к проду, но только через нашу трубу, и в головах собственно это и осталось, что это просто палка-копалка для доступа к проду.
В общем как и всегда проблема вовсе не в клозетах.
Ну в целом кто пользуется 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 раза, чего бы вы добились с куда меньшими трудозатрами, просто по-нормальному текущий проект переписав.
К тому, что было высказано до меня, я бы хотел вот что ещё добавить от себя лично.
Большая проблема, что если с горем пополам чем занимаются программисты понятно, то объяснить чем занимаются люди ответственные за эксплуатацию для менеджмента сложнее. Вы не понимаете проблем и задач эксплуатации, поэтому вам и кажется, что они что-то делают неправильно, но в общем все ровным счётом наоборот.
В свое время я начинал один свой проект с того, что не было ни тикетов, ни малейшей бюрократии, по итогу триста человек начали звонить, писать, а то и ходить ногами. И при этом остальная работа никуда не исчезла. Это безусловно было очень удобно для моих коллег, правда вся моя работа фактически вставала, это вело к огромным переработкам, к необходимости бежать в два раза быстрее, чтобы двигаться вперёд, чтобы успеть все, при этом документально куда тратится моё рабочее время я ничем не мог подтвердить.
На хабре есть полно статей, где люди также пришли к тикетам, чтобы хотя бы как-то было возможно планировать работу, фиксировать задачи и отчитываться о результатах своей детальности. Это делается не из-за большой прихоти, не для желания отгородиться, а потому что жизнь заставила.
>Возможность релизить часто означает, что у вас маленькие, изолированные изменения, хороший уровень автоматизации и тестирования, это снижает риски
На практике, к сожалению, но частота релизов может быть индикатором как раз наоборот особенно дерьмовых процессов, когда менеджменту всегда надо ещё вчера, а как оно там у айти работает их совершенно не касается, и тогда ваш быстрый девопс ничем не лучше становится прямого доступа к продакшену разработчикам.
На моем проекте (очень крупный финтех) мы добились впечатляющей автоматизации, когда в целом изменение пусть и в качестве хотфикса можно было вывести за один час. А всего у нас в день через нашу автоматизацию успешно ставилось на продакшен несколько десятков релизов и ещё несколько сотен параллельно ставились на разные другие среды. Вы думаете у нас было тестирование? Или возможность быстро выводить снизило какие-то в сущности риски благодаря инкрементным изменениям? К сожалению, но это даже близко было не так. По факту мы просто дали разработчикам вместо прямого доступа к проду ровно такой же аналогичный прямой доступ к проду, но только через нашу трубу, и в головах собственно это и осталось, что это просто палка-копалка для доступа к проду.
В общем как и всегда проблема вовсе не в клозетах.
Ну в целом кто пользуется 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 раза, чего бы вы добились с куда меньшими трудозатрами, просто по-нормальному текущий проект переписав.
К тому, что было высказано до меня, я бы хотел вот что ещё добавить от себя лично.
Большая проблема, что если с горем пополам чем занимаются программисты понятно, то объяснить чем занимаются люди ответственные за эксплуатацию для менеджмента сложнее. Вы не понимаете проблем и задач эксплуатации, поэтому вам и кажется, что они что-то делают неправильно, но в общем все ровным счётом наоборот.
В свое время я начинал один свой проект с того, что не было ни тикетов, ни малейшей бюрократии, по итогу триста человек начали звонить, писать, а то и ходить ногами. И при этом остальная работа никуда не исчезла. Это безусловно было очень удобно для моих коллег, правда вся моя работа фактически вставала, это вело к огромным переработкам, к необходимости бежать в два раза быстрее, чтобы двигаться вперёд, чтобы успеть все, при этом документально куда тратится моё рабочее время я ничем не мог подтвердить.
На хабре есть полно статей, где люди также пришли к тикетам, чтобы хотя бы как-то было возможно планировать работу, фиксировать задачи и отчитываться о результатах своей детальности. Это делается не из-за большой прихоти, не для желания отгородиться, а потому что жизнь заставила.