Comments 22
Поделюсь опытом. Несколько лет руководил отделом и развивал девопс практики, в т.ч. иногда приходилось брать в команду совсем зелень. На мой взгляд у вчерашнего админа совсем другие проблемы:
Встречалось почти у всех: непонимание необходимости ведения документации; приходится прям с примерами пояснять, что будет с их фигнёй, которую они кинули а-ля я сделяль и радостно закрыли тикет.
Непомерная любовь к виртуалкам. Даже если чувак идеально проходит собес и всё знает про кубер, он вероятно в проде никогда им не пользовался. Или просто боится иметь с ним дело.
Непонимание как удобно людям и как сделать продукт, которым хочется пользоваться: баш портянки на 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: админ, который освоил разработку, или разработчик, который освоил инфраструктуры