Comments 18
Поделюсь опытом. Несколько лет руководил отделом и развивал девопс практики, в т.ч. иногда приходилось брать в команду совсем зелень. На мой взгляд у вчерашнего админа совсем другие проблемы:
Встречалось почти у всех: непонимание необходимости ведения документации; приходится прям с примерами пояснять, что будет с их фигнёй, которую они кинули а-ля я сделяль и радостно закрыли тикет.
Непомерная любовь к виртуалкам. Даже если чувак идеально проходит собес и всё знает про кубер, он вероятно в проде никогда им не пользовался. Или просто боится иметь с ним дело.
Непонимание как удобно людям и как сделать продукт, которым хочется пользоваться: баш портянки на 100500 строк, ключи ssh руками, вместо того чтоб прикрутить otp через vault, и другие моменты, банально вызванные отсуствием опыта.
Про то что он там не знает ansible или как гитом пользоваться, такие даже первичный скрининг у hr не проходят.
С вчерашними разработчиками, кстати, тоже есть списочек, к несчастью или к счастью такой у меня был только один:
Продолжает кодить и переусложнять. Ещё, зараза такая, обязательно постарается впихнуть то, чему в инфре не место, типа раста или котлина, которые кроме него никто в команде не знает. На вопрос, мол, а что не питон-то, начинает тираду про то что питон говно и вообще. На то что никто не будет после его ухода это поддерживать фыркает и говорит что ничего, перепишите. Ну не чудак ли?
Очень низкий технический уровень. Поправить ямлик он может, но если вдруг случится фигня с сетью или ещё какая засада, внезапно выясняется, что он не разбирается в этом. Можно повозражать, что это не работа девопса, но мы же знаем как у нас в большинстве компаний, так что спорить смысла особо не вижу.
Про хорошие практики тоже беда. Приходится пояснять и достаточно часто. Кажется, это беда всех зелёных
>Продолжает кодить и переусложнять. Ещё, зараза такая, обязательно постарается впихнуть то, чему в инфре не место, типа раста или котлина, которые кроме него никто в команде не знает. На вопрос, мол, а что не питон-то, начинает тираду про то что питон говно и вообще. На то что никто не будет после его ухода это поддерживать фыркает и говорит что ничего, перепишите. Ну не чудак ли?
А парень ироничный попался. Обычно ведь как бывает. Разработчик говорит, что надо делать так и так, и будет нам всем счастье, а разработчику на это отвечают "Вася, все горит, давай в прод, потом если что проект перепишем". По итогу конечно никто никому рефакторинг проводить не дает, и все костыли живут до скончания времен, пока наконец сервис не складывается окончательно. А тут вам разработчик заявляет, что сделал все как надо, потом хотите переписывайте сами без меня. Умный, видно уже попадался на такие приколы, по ночам работать не хочет.
Лучщий девопс - это тот, кто сразу учился га девопса. Не благодарите!
На самом деле все зависит от желания учиться и страдать. А страдать придется очень много: хоть из разраба приходи, хоть из админа.
Обычно приходят из админов: если человек понимает за Linux, может строчить большие скрипты это уже очень хорошая точка входа. А если под админом понимать эникей - то эникею лучше сначала в хорошего админа расти.
Когда начал читать статью, подобные которых валом, сразу задался вопросом кто же автор: админ или программист, но почитав понял, что максимальный уровень человека - это начальный уровень администрирования, проще говоря подай принеси, а разработчик из него такой же, как из промокашки скрипач, поэтому узнав азы программирования и языки - чувак мечтает стать гуру разработчиком, но на рынке такой не нужен недотепа, поэтому хоть и с уважением он говорит в статье - разработчик и более пренебрежительно - эникей, в итоге он сидел на мясной линии поддержки, ну и понятно с временем пытался жрать всю инфу нужную и нет, посему считает, что только так становятся девопсами, ведь в его понятии мира, админы - это те, кто зачем то постоянно чинят компы пользователям, а разрабы - только кодят, ведь чтобы создать устройство - читать схемы ненужно, надо только питон учить))))) короче очередной высер мамкиного спеца, что девопсы это отдельная каста… но в статье правда не описано чем же даже отличаются админы и программисты, потому как автор записал в минусы одни и те же навыки, которые есть только у мальчика из колцентра)))) ну действительно зачем админу компании продумывать инфраструктуру, разбираться в бизнес процессах и прочее - пришел к директору, стукнул кулаком и тебе тут же новенькие сервера и секретутку впридачу)))) а если что не заработало - та плевать на деньги компании))))) и программисту, ну нафиг знать что то о секьюрности - сделал пароль 123, а двухфакторку - пусть индус напишет)))) осциллограф? Паяльник? Это пусть инженера разбираются с девайсами каменного века, а у нас чат-gpt и код на коленках тяп ляп и в продакшен))))) а на самом деле девопс всегда был карманным админом отдела, например разрабов ну и чтобы админа не забибикивали своими проблемами - берут теперь не эникея, которых уже наверно даже нигде и нет, а спеца, которому ставишь задачу и пусть решает
Инженер - забытый навык предков.
>Типичная позиция вчерашнего сисадмина: как задачу поставили, так и сделал. Но уточнять такие детали — это зона ответственности девопса, это он должен быть инициатором коммуникации
Не должен. Вы как инициатор задачи заинтересованы, чтобы она была сделана так, как вам это необходимо в рамках тех заложенных сроков, что у вас есть. Тут соре работает правило shit in -> shit out. Или разработчикам вы также ТЗ ставите, а выяснять что хотел заказчик должен сам разработчик? Если так, то у вас неправильно выстроены процессы разработки.
>Разработчики привыкли к детерминированности их вселенной: есть ТЗ — работаем по ТЗ. У DevOps зачастую задача поставлена высокоуровнево, а вот на какие грабли придется наступить в процессе — будет ясно только по факту.
Я оказался выше прав. Вы знаете, но в былые времена я слышал такую замечательную присказку, о которой также поделюсь с вами "без тз - результат хз". Она справедлива и в случае тех кто занимается эксплуатацией, и тех кто занимается разработкой. Это в общем-то как менеджера ваша задача, вы ее пытаетесь свалить на каких-то других людей и удивляетесь, что такой подход не работает.
>Если задача сформулирована «поднять сервис», он должен найти или запросить архитектурную схему проекта, выяснить, как и с чем будет взаимодействовать этот сервис, понять, какая нужна доступность (SLA) и т. п. От всех этих деталей зависит архитектура, и увы, никто не принесет их ему на блюдечке. Информацию придется добывать самостоятельно, поскольку это требования бизнеса к нему, как DevOps‑инженеру. По сути он сам должен быть немного архитектором, который может спроектировать отказоустойчивый сервис, а потом еще и помочь разработке сделать его действительно таковым. Ведь разработчики иногда совершают типичные ошибки, отражающиеся на отказоустойчивости, так что DevOps выступает еще и своего роля инструментом контроля качества.
Ну опять же у вас явно нет отдельно человека, который был бы занят архитектурой, нет аналитиков, которые бы уточняли требования, вы все спихиваете на какого-то мифического девопса, который все должен сделать и даже немного больше. Но так в жизни не работает, либо работает, но тогда такому специалисту вы вынуждены платить прямо-таки конский ценник (обычно речь про какого-то консультанта, которого вы приглашаете на проект, и он вам все такое делает под ключ), поскольку чисто из моего опыта есть полно мест, где таких требований не предъявляются, где роли распределены, а зоны отвественности устаканены, а сам процесс разработки и вывода в эксплуатацию согласован со всеми заинтересованными сторонами. Вообще это решается по-другому. Есть четкий чеклист "принятия сервиса в эксплуатацию", там обычно расписано что требуется, чтобы сервис можно было использовать в продакшене, а девопс в случае проблем смог бы подключиться и их решить, там как раз все эти моменты с SLA, отказоустойчивостью, деталей реализации архитектуры, а также многие другие важные вещи описаны, и заранее все стороны знают, что от них требуется. Вас могут за ручку провести в продакшен, но, например, ручки с метриками и правильный формат логов хоть убейте придется делать не девопсам, а разработчикам. В общем и целом, если работа построена правильно, если есть процесс, есть заявки с четким ТЗ, есть необходимые чеклисты, то никаких проблем не возникнет, в случае отсутствия всего вышегоперечисленного и формата работы "зачастую задача поставлена высокоуровнево, а вот на какие грабли придется наступить в процессе — будет ясно только по факту" будет масса сплошных неожиданностей, возникающих вследствие непонимания SDLC некоторыми менедежрами.
>Есть еще один путь — представитель техподдержки, который развился в DevOps. Причем, речь идет о классической техподдержке, например, оператора связи — т. е. о людях, помогающих решить вопросы по телефону, занимаются настройкой сетей и т. п., которым приходится много траблшутить и коммуницировать. Это может быть третья линия какого‑нибудь хостинга — ребята, которые каждый день решают бесконечную реку проблем. Но не просто решают, а потом еще и объясняют клиенту, что именно они сделали. С моей точки зрения статистически на этом пути чаще рождаются хорошие девопсы.
Ну и как вишенка на торте - вы видите в роли девопса человека уровня принеси-подай-иди-нафиг-не-мешай. Напоминаю, что этим специалистам вы платите огромные деньги за умение решать очень сложные вещи в очень сжатые сроки, у многих из этих специалистов реальное высшее образование, подкрепленное годами реальной практики, а иногда весь ваш бизнес буквально может от такого человека зависеть. Возможно, вам стоит подумать, что все-таки, если девопсы\разработчики так работают, то этому есть объяснение помимо того, что они все чудаки, и все делают неправильно, а вы сейчас их научите как верно им работать. Возможно, это вы все делаете неправильно. Почитайте, например, мифический человеко-месяц, там вообще говоря хорошо объяснены все трудности, которые возинкают в ходе разработки любого продукта. Хоть книжке уже несколько десятков лет, а очень свежо читается особенно в контексте вашего понимания, как должна быть устроена разработка и эксплуатация.
Нельзя просто так взять и обозвать эникейщика админом. Это отдельная и довольно высококвалифицированная работа. Без шуток. Я вот лично ноутбуки и маковские моноблоки чинить не полезу, да и винду или макось чинить не стану. И с приколами всех принтеров разбираться не хочу. Но они при этом не админы и в гробу это всё видели.
Странное предположение, что девопсам кто то платит x2-3 от разработчиков. Или я ошибаюсь насчет максимальной зп девопса в Москве/России (сеньорам больше 400т.р. в России вряд ли кто то предложит). Уверен, программисты сеньоры получают столько же или больше.
И в реальной жизни у девопсов разумеется всегда есть руководитель и не один. Команда тоже обычно есть. Редко на собеседованиях приходилось слышать, что нужен девопс-спаситель одна штука. Я от такого сразу отказывался.
Без разницы, из админов или из разработчиков наш девопс.
Главное, что он понимает КАК автоматизировать рутину (CI, CD, ...), может сам это все РУКАМИ делать и имеет здравый смысл. Остальное получится :)
Пришел в депопсины из сп3)))
А в третью линию пришел с бэком админки виндовых серверов. Ну и кодил на 1с, но в резюме написал, что в этот период сидел на героине 😀
Большинство здесь справедливо, но что касается постановки задач девуопсу, у нас есть четкий регламент, и если что-то не описано, задача в работу не идёт. Возвращается на уточнение. Но валидация да, за нами.
Не знаю что там автор вообразил про админов и про разработчиков. Есть такое понятие как инженер, а чем он там занимается, внедряет системы, обслуживает или разрабатывает это уже детали. Для этого учили когда-то электротехнику, микропроцессоры, ОС, сети, ассемблер, c++ и c#/java. Может быть он не в теме последних новинок, но точно коллег смежников будет понимать.
В заголовке про админа, а в статье про эникейщика. Сисадмин и траблшутит, и на нескольких языках пишет. При этом в отличии от большинства прогеров прекрасно знает основы сети.
Да и вообще довольно много клише словно родом из начала 2000-х.
С тейка про то, что разработчик работает по тз похихикал) большинство задач ставится на уровне заголовка в жире, а там уже сам думай что имел ввиду автор тикета
Автор рассмотрел эникеев (ладно, натянем = между эникеев и СА), но не освещены вопросы: что, если знания в деве получает и применяет ведущий СА? Тимлид СА? Тут, сказать по правде, = трещит и не натягивается.
Я администрировал сервера и писал код. Писал инфраструктуру в бигтехе и создавал платформы для разработки. Видел много чужой инфры от разработчиков и сисадминов. Поэтому имею что сказать.
DevOps должен делать инженер, который умеет работать в команде. Если надо он разберется с администрированием. По необходимости напишет код. Но главное он решит проблему, а не будет кормить свое эго создавая никому не нужные вещи. И это будет жить после его ухода.
Например, в одной бигтех компании сократили админов и после них осталось огромное число решений одного человека. Оказалось, что есть более 10 способов прописать днс имя внутри, но часть сломано и не работает. Как сказал один из последних сисадминов - лучший админ знает максимальное число способов решения задачи, так как работает в компании давно и видел все.
Потом маятник качнулся в лругую сторону, и из разработчиков-алгоритмистов пытались сделать сисадминов. Тогда это еще не называли - имплементировать роль DevOps. Получилось также плохо, разработчики не хотели делать надежно и лепили тяп ляп. Помню как из-за смешных проблем разваливался прод. Например, ребята писали по одному байту на диск в цикле. Они сбрасывали состояние своего приложения, но не понимали ограничения железа (hdd).
Спас всех инженерный подход. Когда подошли к devops задачам как к продукту. И поставили инженеров писать решение. Все проблемы не решили, но работает. Палки и связующая субстанция помогли. Но когда было по другому?
Кто лучший DevOps: админ, который освоил разработку, или разработчик, который освоил инфраструктуры