Комментарии 24
молодые разработчики не пытаясь вникнуть в свой код сразу заявляют девопсу что его пайпы не работают
За такое отношение к работе (и своему коду) можно и вылететь. Я формально сениор/архитект, но иногда и в девопс лезу, потому что а) надо и б) интересно же!
Отлично, все проблемы не чьи-то конкретные, а общие. Никто четко не отвечает за какую-то часть работы. Удобно, и зп больше чем у одмина, и ответственности меньше. Надо переписать резюме на девопса :)
Можно по разному. Можно как вы сказали "у задачи должен быть тот, кто за неё отвечает". А бывает и иначе: "парни, у нас тут вот это сломалось, давайте чинить ".
Когда задача большая, то одному человеку сложно быть ответственным за нее всю. В результате получается или "к пуговицам претензии есть?", или ответственным назначается кто-то. По моему опыту, когда ответственность возлагают, то ничего хорошего из этого не получается.
Потому идея довольно простая — давайте ответственной будет вся команда, от джуна до лида, и от дева до прода.
Синтаксически корректно разговаривать на русском языке тоже сложно, так что теперь, синтаксис отменить?
ответственной будет вся команда
Sounds good, doesn’t work. Наблюдал бумажного тимлида, который прямо декларировал «у нас каждый человек может заниматься каждым сервисом, сервисами владеет команда». Как только начинались конкретные вопросы, сразу в ответ «я, конечно, могу посмотреть, но это тебе лучше Феоктиста спросить». А потом Феоктист ушёл в отпуск на две недели, и все серьёзные работы по некоторым сервисам были остановлены, пока он не вернулся.
В группе из более чем одного человека неминуемо возникнет специализация, поэтому о групповой ответственности можно только мечтать. Групповая ответственность удобна только при роутинге внешних задач, чтобы не к конкретным людям бегали ногами, а в таск-трекер, например.
Это проблема реализации DevOps-методологии, одна из основных. Вторая крайность звучит как «я программист, я фичи пишу, а для деплоя у нас девопсы есть». DevOps идейно простой, типа Agile, но когда люди начинают делать буквально то, что в статьях написано, весь этот горький катаклизм и получается.
Идея всей этой движухи не в том, чтобы пайпы делать или k8s ставить и настраивать бесконечно, и уж точно не в том, чтобы нанимать специальных людей для этого, а чтобы двух людей с узкой специализацией подружить и донести до них обоих простую мысль: фича, не работающая на проде, не приносит ни денег, ни радости. Поэтому заявления «я написал фичу, дальше как хотите» и «я настроил пайпы, дальше как хотите» не работают, надо как-то друг с другом договариваться. Как только эту мысль становится возможным донести до некоего критического подмножествам людей — внезапно они сами и приложение инструментируют, и деплой делают по кнопке, и в on-call стоят все по очереди. До этого — декларации, обещания полетов к звёздам и карго-культ, всё как мы любим.
4 программера и я одмин
вот всеобщими усилиями ваяли продакшн, соединяли знания одмина со знаниями программеров и никакие девопсы не нужны были
на мой взгляд самая эффективная модель
а требовать от админа ковырять код и указывать на ошибки программерам — это какой-то особенный мазохизм.
Тоже работал одменом. Чтобы доказать что у нас все в порядке, надо было разобраться что именно сломалось. Это могут сделать как админы, так и разрабы. В особо тяжёлых случаях сесть рядом и разобраться совместно. Проблем с перетягиванием каната не было, виноватых обычно искали после исправления проблемы.
В другой компании напротив были две группы: одна помогала разработчикам настраивать инфраструктуру для разработки, вторая постоянно латала падающие пайплайны. Обе назывались девопс, хотя очевидно это не стык дев и опс, а просто поддержка определённых сервисов.
Сисадмин (ops): у нас этот код не работает! Мы тоже постарались!
DevOps: этот код работает только на такой платформе, а вот чтоб запихнуть в прод, надо сделать тулчейн для сборки образа.
Git и GitHub — системы управления исходным кодом
git это система контроля версий, а github это сервис, реализующий публичные и приватные git репозитории.
Docker — ПО для автоматизации деплоя и управления приложениями в средах с поддержкой контейнеризации;
тоже нет, это инструмент управления контейнерами. Сборкой и запуском контейнеров, если быть точным. В википедии, откуда вы скопипастили это, не совсем точно написано.
Chef, Puppet и Ansible — средства для автоматического конфигурирования и развертывания
Паппет лишний, его крайне неудобно использовать для развертки, для этого у них есть bolt, практически — аналог ансибла. Впрочем, все три системы были изначально для централизованного управления конфигурациями, а не развертывания.
На мой вкус, автор на самом деле не был настоящим сисадмином. Еще до того, как к нам приплыло слово devops (лет 10 назад точно), я работал в компаниях, где мы так же, как пишет автор, деплоили автоматически (надеюсь что в статье не имеется ввиду все же система сборки-деплоя, а не пачка башскриптов), имелись автотесты с пайплайнами. Не было никакого «Тот идет на сервер, устанавливает и настраивает все руками.»
Со сбором метрик и оптимизацией производительности тоже никаких проблем никогда не было. Кстати говоря, с приходом докера и кубернетис, этот вопрос стал в десятки раз сложнее. Просто не все знали какие метрики снимать. Судя по собеседованиям, многие даже не знают что такое LA, что уж тут говорить о том, сколько метрик отдает jvm или хотя бы мониторинге времени ответа по типам запросов
Профессия DevOps-инженера: взгляд сисадмина