Почему DevOps-отдел - это пустая трата сил и времени? / Алексей Шарапов (ЦРПТ)
HTML-код
- Опубликовано: 25 авг 2024
- Приглашаем на DevOpsConf 2024, которая пройдет 4 и 5 марта 2024 в Москве. Программа, подробности и билеты по ссылке: devopsconf.io/...
---------
DevOpsConf 2021
Профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации
31 мая 2021 и 1 июня 2021 Москва, Radisson Slavyanskaya
Тезисы и презентация:
devopsconf.io/...
Если:
- у вас в компании есть DevOps-отдел;
- вы задумываетесь о том, чтобы объединить всех девопсов в один отдел;
- кто-то в компании раскатал кластер кубера, и теперь мы их зовем DevOps-отдел;
то у меня для вас плохие новости...
--------
Нашли ошибку в видео? Пишите нам на support@ontico.ru
![Tee Grizzley - Detroit (Feat. 42 Dugg) [Official Video]](http://i.ytimg.com/vi/aeKfTtt0x14/mqdefault.jpg)
У меня абсолютно противоположный с Алексеем опыт. Разработчики НИКОГДА не хотят погружаться в DevOps практики, если это им явно не помогает в разработке. Они никогда не разбираются в тонкостях инструментов поддержки pipeline'а, проверки образов/библиотек на безопасность, проверки кода, автотестирования, настройки мониторинга, связями между этими инструментами. Если даже они этим займутся, у них будет всего лишь локальный специфический опыт работы со своим стеком.
Как правило никто не обучает DevOps практикам разработчиков. Это сделать нецентрализованно - практически невозможно. Т.е. в вашей организации должны быть соответствующие курсы, с обязательным тестированием разработчиков. Иначе получится следующая картина: есть один-два разраба, которые могут уметь даже пайплайн написать и задеплоиться в облако, и есть куча других разработчиков, которые этого не знают и, возможно, даже не хотят знать ("это не моя работа, я программист"). В итоге на проектах у вас будет твориться полный хаос в плане пайплайнов: каждый проект будет абсолютно уникальным с точки зрения деплоя.
Как разраб в прошлом, я прекрасно понимаю что нахрен программисту не сдалось изучать особенности деплоя в облака, Kubernetes/Openshift, Helm, Gitlab CI, Jenkins и прочее и прочее. Я хочу программировать, разрабатывать программы, архитектуру, ковыряться в оптимизации проекта и всё такое. Мне нравится программировать на Java/Kotlin/чем-то ещё, а изучать DSL инструмента для деплоя - занятие скучное, а главное - нецелевое. У меня в Jira куча разработческих задач, которые с меня спрашивают, а вы мне предлагаете заниматься совершенно неприятными для меня вещами, которые ещё и отбирают большое количество времени. Если процент DevOps задач превысит некоторый приемлемый порог, я просто соберу манатки и свалю в другую организацию. Потому что Java-программисты ценятся, а "так себе программисты, но с опытом DevOps практик" - нет.
Выделение отдельных DevOps инженеров в каждую команду разработки - тоже плохое решение. Во-первых таких нужно минимум два, потому что люди уходят в отпуск, болеют и т.д, и нельзя останавливать конвеер из-за этого. Двое - уже слишком дорого. Отсюда следует вполне логичный вывод: нужно создать отдельную команду девопсов, которые будут ходить по проектам и делать девопс задачи в их рамках. Таким образом и вопрос из зала снимается - про то что "иногда нам девопс нужен 10% времени, а иногда - 300% времени". Пока его нет на вашем проекте - он есть на другом, но когда нужно - прибежит на ваш. Причём время между проектами можно будет распределить между девопсами, потому что у вас есть отдел, в котором несколько девопсов и вы управляете тем какими задачами они занимаются. А ещё люди, работающие в одном отделе, гораздо чаще и больше делятся друг с другом информацией, чем те кто работает в разных отделах на разных проектах. Очень скоро у вас получится унификация девопс практик и - тадам! - "мультикаталка".
В мультикаталке есть свои недостатки. Здесь важно чтобы люди, работающие над мультикаталкой, продолжали работать на проектах обычными девопсами. Таким образом они не будут отрываться от реальности и становиться закрытой в себе "командой платформы", имеющей мало общего с проблемами конкретных проектов.
От души
Манал я это ковыряние в AWS, Gitlab CI и Jira, чтоб хоть что-то приемлемое вышло для автоматизации деплоя, работы с ветками и доставку в Slack информации о состоянии
Это реально ад для разработчика.
Люто плюсую. Я конечно не против разобраться как что работает, может где-то что-то подкрутить, но не на постоянку и уж точно не полный пайплайн на своей спине держать. При этом когда такое говоришь - все сразу думают что ты ленивое нечто, который не хочет учить ничего нового, не понимая что мне как разрабу и так есть что новое поучить.
При этом никто не заставить никогда серьезно заниматься разработкой девопса/тестировщика/дизайнера/бизнес аналитика/т.д., т.к. всем понятно, что это не их задача. Но почему-то разработчик должен быть готов "прикрыть" недоработки любого на одной из этих позиций...
Отличный стендап на тему мультикаталки ) Посмеялся от души.
мультикаталка сделал мой день
Конечно. Все можно. Можно и без DevOps. Только никакой вменяемый проф.разраб в такую фирму/команду не пойдет,потому что прекрасно знает как выглядят рабочие будни в таком билде.
ух ты... квадратное колесо ?)
Водяной доклад и возможно додумки докладчика. Странно что он не показал код мультикаталки, что в нем было не так и привел бы в пример код кастомного пайплайна, который решил бы проблему. Пример про чарт и хелсчеки для мобилки это кринж, потому что фикситься параметрами в values для конкретного микросервиса.
Я бы еще проникся и поверил, если бы речь шла о быстро растушем стартапе, но чел сразу сказал что это гос/окологос сегмент, то есть банки, телеком и рос-компании. Удачи там с time to market с дрочем артефактов, документации, ПСИ, ЗНИ, ЗНО, ЗНУ. В такие компании банально новую технологию занести сложно, уж что говорить про внедрение, отсюда 90% микросервисов могут иметь один и тот же докерфаил, хелмчарт, а так же CI/CD.
Короче, по возможности, больше ресурсов и индивидаульного подхода -- всё будет ок. :)
основано на реальных событиях
Абсалютна сагласен с аватаром, все кампании абсалютна нечиго не знают и нипанимают, дывопсав напамойку XD