Изначально DevOps — специалист на стыке двух миров: разработки (DEVelopment) и эксплуатации (OPerations). Его задача — развертывать приложения и обеспечивать их бесперебойную работу, что включает в себя также заботу об инфраструктуре.
Я наблюдаю за развитием DevOps уже 13 лет. IT активно растет, девопсов требуется все больше. Так что сюда потянулись коллеги из смежных областей. Но в чистом виде ни одна из других специальностей не содержит полный набор требуемых навыков.
Сегодня размышляю, что так и что не так с разработчиками и сисадминами, которые устремились в DevOps (ну помимо идеи, что каждый должен заниматься своим делом).
Дисклеймер:
Прежде чем критиковать, оговорюсь, что как в разработке, так и среди админов есть прекрасные ребята — талантища! А есть, наоборот: «Пуля с моей стороны вылетела — все работает, значит остальное — ваши проблемы». Каждый из этих подходов имеет право на существование и хорош в своем мире. Но в мире девопсов приживается только тот, кто обладает широкой зоной ответственности — готов смотреть на смежные задачи и помогать коллегам.
К сожалению, мне, как руководителю, с этим ничего не сделать, кроме как на этапе собеседования выяснять о человеке чуть больше, чем список предыдущих мест работы. Поэтому надеюсь, что мое мнение никого не обидит, но даст почву для размышлений о том, стоит ли пытаться пробовать свои силы в DevOps.
Чем плох админ на позиции DevOps
Начну с некоторого негатива — почему эникейщику нельзя просто подучить Linux и стать девопсом (чуть дальше пройдемся и по разработчикам).
Недостаток технических знаний
Рядовому админу как правило банально не хватает технических компетенций, особенно если спектр задач сводился к обслуживанию офиса организации вне ИТ. Обычный офисный эникей вряд ли сталкивался с инструментами автоматизации Ansible, Terraform, Docker, Kubernetes и т. п.
К счастью, как раз эта проблема встречается реже всего — у многих сисадминов прекрасные технические навыки. А если и есть в чем‑то недостаток, он легко нивелируется дополнительным обучением.
Непонимание мира разработки
Поскольку эникей не касается разработки, он не знает ее процессов: как работать с версиями, с какими сложностями приходится сталкиваться… не умеет работать с Git. Аналогичная история с языками программирования (а они нужны для скриптов): Python, Shell или PowerShell. И тут проблема более глобальная — админ как правило не понимает самих процессов разработки и эксплуатации ИТ‑решений.
Неумение траблшутить
Эникейщикам не приходится глубоко погружаться в суть проблемы, соответственно обычная их работа особо не развивает навык анализа и поиска источника проблемы на уровне инфраструктуры.
Пробел в коммуникациях
Самая главная проблема — от эникейщика никто не требует презентовать результаты своей работы. Как правило, он общается только с «глупыми пользователями», которые в принципе не понимают смысл его работы, а также со своим руководителем, выдающим задачи. С руководителем они взаимодействуют на одном техническом языке и хорошо понимают друг друга. Ему не надо доказывать, почему решить ту или иную задачу важно. Пользователю, кстати, тоже не надо — его можно поставить перед фактом (у него нет выбора). В итоге сисадмин может знать все, но совершенно не уметь рассказать об этом.
Сисадминов, которые приходят в DevOps из эникеев или интеграторов, приходится в прямом смысле «ломать» — учить общаться по‑другому, объяснять необходимость своих действий и выбранные пути решения проблем. Если не сломать, то это будет головная боль его руководителя уже в статусе девопса.
Приведу простой пример.
Допустим, новоиспеченный DevOps получает в Jira задачку: «развернуть новый сервис» (и в качестве дополнительной информации — только ссылка на репозиторий с кодом). Вчерашний сисадмин, возможно, сходит к проджекту и инженерам за дополнительными деталями, а потом отправится разбираться. Рано или поздно сервис запуститься и он придет показывать его разработчику (тому, кто ставил задачу). Где‑то на этом этапе выяснится, что надо было разворачивать не в Kubernetes, а вообще в другом контуре. И это начало конфликта.
Типичная позиция вчерашнего сисадмина: как задачу поставили, так и сделал. Но уточнять такие детали — это зона ответственности девопса, это он должен быть инициатором коммуникации.
Здесь можно было бы пенять на руководителя девопса. Но в реальной жизни, как правило, у DevOps нет руководителей. Они работают не в команде, а в одиночку, потому что это очень дорогие специалисты, которые стоят как х2, а иногда и х3 от разработки.
Такой «самостоятельный юнит» приходит в задачу и должен уже на этом этапе немного понимать в бизнес‑процессы. Если задача сформулирована «поднять сервис», он должен найти или запросить архитектурную схему проекта, выяснить, как и с чем будет взаимодействовать этот сервис, понять, какая нужна доступность (SLA) и т. п. От всех этих деталей зависит архитектура, и увы, никто не принесет их ему на блюдечке. Информацию придется добывать самостоятельно, поскольку это требования бизнеса к нему, как DevOps‑инженеру. По сути он сам должен быть немного архитектором, который может спроектировать отказоустойчивый сервис, а потом еще и помочь разработке сделать его действительно таковым. Ведь разработчики иногда совершают типичные ошибки, отражающиеся на отказоустойчивости, так что DevOps выступает еще и своего роля инструментом контроля качества.
Таких уникальных специалистов очень мало. Большая доля технарей зашорены — пока не начнут доверять своему коллеге, не смогут с ним нормально коммуницировать. К счастью у меня, как у руководителя, есть вариант настроить работу и с ними. Когда специалист на собеседовании попадается хороший и я вижу, что ему интересно это направления, собираю тандемы с ребятами, которые являются экстравертами и умеют коммуницировать, пусть даже и не обладают должными техническими навыками. У нас это хорошо работает (мы писали про тандемы).
Чем плох разработчик на позиции DevOps
Как и обещал – теперь проблемы со стороны вчерашнего разработчика.
Высокомерие
Разработчики варятся в «своей каше» и не особо смотрят на другие отделы, отправляя что‑то в прод. Планируя свои спринты, они не оглядываются на те изменения в инфраструктуре, которые потребуются для запуска. Полно примеров, когда не то, что при развитии своего решения, а даже при закупке чужого софта DevOps даже не спрашивают. Возможно, причина этого в ошибках менеджмента или в том, что когда‑то девопсы конкретной компании сильно обидели разработку, послав их подальше с «классными идеями». Но так или иначе, разработчики привыкают работать без оглядки на DevOps.
Но чтобы самому двигаться в сторону карьеры в DevOps, необходимо изменить подход — сначала думать о том, что потребуется развивать в инфраструктуре — не сломает ли это политики безопасности и т. п. Нужно понимать, кто может быть заинтересован в изменениях и согласовывать их с ними заранее.
Пробел в коммуникациях
Как и сисадмины, разработчики довольно замкнуты. Получил задачу в Jira — отчитался там же, мало с кем контактируешь при ее решении. Максимум с кем надо общаться — тестировщики и проджект, но ни одним, ни другим не надо презентовать результаты своей работы (а значит, верны все те же рассуждения, что и для эникейщиков). DevOps надо взаимодействовать не только внутри своей команды, но также с разработчиками, руководством и другими заинтересованными сторонами. Нельзя стать хорошим DevOps с плохими навыками коммуникации.
Неумение траблшутить
Разработчики привыкли к детерминированности их вселенной: есть ТЗ — работаем по ТЗ. У DevOps зачастую задача поставлена высокоуровнево, а вот на какие грабли придется наступить в процессе — будет ясно только по факту.
Умение жить только в одной парадигме
Разработчики привыкли концентрировать внимание только на одной системе. DevOps приходится «жить» одновременно в разных мирах и на разных их уровнях — помнить о жизненных циклах всех продуктов, о безопасности, о патчах, о взаимодействии протоколов, брандмауэров.
А еще разработчик обычно не думает в контексте денег. Запуск приложения всегда чего‑то стоит компании — будь то арендованная мощность или эксплуатация собственного не вечного железа. Это тоже о способе мышления — при переходе в DevOps необходимо принять эту концепцию.
Недостаток технических знаний
В отличие от админов, разработчики хуже понимают процессы управления инфраструктурой — на позиции разработчиков они не связывались с серверами, сетями, облаками и т. п. Они не знают многих базовых концепций — DNS, модели OSI и т. п. Да и в целом — можно 8–10 лет быть разработчиком под Linux, но понятия не иметь, как администрировать ОС этого семейства.
Яркий пример — когда адреса DNS хардкодят в приложение или кэшируют внутрь него, не предполагая, что что‑то может измениться (и тогда для продолжения работы потребуется перезапуститься или, что еще хуже, выпускать фикс). То же самое можно сказать про инструменты автоматизации — Ansible, Terraform, Docker, Kubernetes и прочие. В коде реализуются решения, которые не стыкуются с позицией DevOps, потому что людям банально не хватает базы.
А какой DevOps хорош?
Есть еще один путь — представитель техподдержки, который развился в DevOps. Причем, речь идет о классической техподдержке, например, оператора связи — т. е. о людях, помогающих решить вопросы по телефону, занимаются настройкой сетей и т. п., которым приходится много траблшутить и коммуницировать. Это может быть третья линия какого‑нибудь хостинга — ребята, которые каждый день решают бесконечную реку проблем. Но не просто решают, а потом еще и объясняют клиенту, что именно они сделали. С моей точки зрения статистически на этом пути чаще рождаются хорошие девопсы.
DevOps требует ряда личностных качеств:
умения анализировать и выявлять источник проблемы (траблшутить) в условиях, когда он не является разработчиком, т. е. не знает систему в деталях — он должен уметь быстро разбираться с «черным ящиком»;
готовности к коммуникациям;
желания пробовать разные решения и соглашаться на оптимальное (даже если это чужое решение);
способности жить в быстроменяющихся внешних условиях;
стремления учиться и развиваться.
У техподдержки эти качества изначально есть. А технические знания приложатся.
Зачастую задача DevOps еще и в том, чтобы объяснить разработчику, что его первоначальное мнение ошибочно. А для этого очень нужны навыки презентации, умение донести мысль и объяснить, почему так правильно. Нужно день ото дня общаться, объясняя, почему проблема в принципе должна решаться и как. На этом этапе технарям очень не хватает софтов, а именно это — определяющий фактор, кто в итоге станет хорошим DevOps. Так что разработчик, как и админ, вполне может вырасти в хорошего DevOps, но это не история про hard‑овые навыки. Харды нужны — 100%, но не являются основными.
Еще раз подчеркну, опыт в техподдержке — не является обязательной ступенью для DevOps. Важно большое количество «нарешенных» задач в персональной истории, причем из максимально возможного количества вариантов.
У нас в коллективе есть примеры, когда разработчики и админы приходили в DevOps. Но зачастую это история про огромный жизненный опыт. Например, у нас в компании есть архитектор, который чуть больше 10 лет был разработчиком, потом несколько лет расследовал инциденты, и только после этого ушел в DevOps, проработав там еще четыре года. Общий стаж — почти 20 лет (с перекосом в разработку). Это огромный срок и сейчас он прекрасно траблшутит и коммуницирует как на языке разработки, так и с бизнесом.
Если нет ни опыта в техподдержке, ни гигантского (и близкого по смыслу) стажа, то прямая дорога на профильные курсы. Например, Linux basic (LPIC-1) и Linux Advance (LPIC-2), где содержится то, что должен знать и уметь DevOps в базовой ОС Linux. Наряду с умением траблшутить это фундамент для развития в данном направлении. Потом на него можно накладывать сверху знания DevOps инструментов, а параллельно качать софты, которые будут своего рода смазкой, которая поможет двигаться по этим рельсам.
Комментарии (18)
itcaat
24.07.2025 12:27На самом деле все зависит от желания учиться и страдать. А страдать придется очень много: хоть из разраба приходи, хоть из админа.
Обычно приходят из админов: если человек понимает за Linux, может строчить большие скрипты это уже очень хорошая точка входа. А если под админом понимать эникей - то эникею лучше сначала в хорошего админа расти.
Ava256
24.07.2025 12:27Вот тоже хотел про это написать.Должности «админ» и «эникей» сильно зависят от конкретной конторы и человека и вообще я уже давно не встречал чтобы кого-то называли эникеем, прошло то время. Теперь есть Helpdesk и админы.
CmpeJ1ok
24.07.2025 12:27Когда начал читать статью, подобные которых валом, сразу задался вопросом кто же автор: админ или программист, но почитав понял, что максимальный уровень человека - это начальный уровень администрирования, проще говоря подай принеси, а разработчик из него такой же, как из промокашки скрипач, поэтому узнав азы программирования и языки - чувак мечтает стать гуру разработчиком, но на рынке такой не нужен недотепа, поэтому хоть и с уважением он говорит в статье - разработчик и более пренебрежительно - эникей, в итоге он сидел на мясной линии поддержки, ну и понятно с временем пытался жрать всю инфу нужную и нет, посему считает, что только так становятся девопсами, ведь в его понятии мира, админы - это те, кто зачем то постоянно чинят компы пользователям, а разрабы - только кодят, ведь чтобы создать устройство - читать схемы ненужно, надо только питон учить))))) короче очередной высер мамкиного спеца, что девопсы это отдельная каста… но в статье правда не описано чем же даже отличаются админы и программисты, потому как автор записал в минусы одни и те же навыки, которые есть только у мальчика из колцентра)))) ну действительно зачем админу компании продумывать инфраструктуру, разбираться в бизнес процессах и прочее - пришел к директору, стукнул кулаком и тебе тут же новенькие сервера и секретутку впридачу)))) а если что не заработало - та плевать на деньги компании))))) и программисту, ну нафиг знать что то о секьюрности - сделал пароль 123, а двухфакторку - пусть индус напишет)))) осциллограф? Паяльник? Это пусть инженера разбираются с девайсами каменного века, а у нас чат-gpt и код на коленках тяп ляп и в продакшен))))) а на самом деле девопс всегда был карманным админом отдела, например разрабов ну и чтобы админа не забибикивали своими проблемами - берут теперь не эникея, которых уже наверно даже нигде и нет, а спеца, которому ставишь задачу и пусть решает
hellosamurai
24.07.2025 12:27>Типичная позиция вчерашнего сисадмина: как задачу поставили, так и сделал. Но уточнять такие детали — это зона ответственности девопса, это он должен быть инициатором коммуникации
Не должен. Вы как инициатор задачи заинтересованы, чтобы она была сделана так, как вам это необходимо в рамках тех заложенных сроков, что у вас есть. Тут соре работает правило shit in -> shit out. Или разработчикам вы также ТЗ ставите, а выяснять что хотел заказчик должен сам разработчик? Если так, то у вас неправильно выстроены процессы разработки.
>Разработчики привыкли к детерминированности их вселенной: есть ТЗ — работаем по ТЗ. У DevOps зачастую задача поставлена высокоуровнево, а вот на какие грабли придется наступить в процессе — будет ясно только по факту.
Я оказался выше прав. Вы знаете, но в былые времена я слышал такую замечательную присказку, о которой также поделюсь с вами "без тз - результат хз". Она справедлива и в случае тех кто занимается эксплуатацией, и тех кто занимается разработкой. Это в общем-то как менеджера ваша задача, вы ее пытаетесь свалить на каких-то других людей и удивляетесь, что такой подход не работает.
>Если задача сформулирована «поднять сервис», он должен найти или запросить архитектурную схему проекта, выяснить, как и с чем будет взаимодействовать этот сервис, понять, какая нужна доступность (SLA) и т. п. От всех этих деталей зависит архитектура, и увы, никто не принесет их ему на блюдечке. Информацию придется добывать самостоятельно, поскольку это требования бизнеса к нему, как DevOps‑инженеру. По сути он сам должен быть немного архитектором, который может спроектировать отказоустойчивый сервис, а потом еще и помочь разработке сделать его действительно таковым. Ведь разработчики иногда совершают типичные ошибки, отражающиеся на отказоустойчивости, так что DevOps выступает еще и своего роля инструментом контроля качества.
Ну опять же у вас явно нет отдельно человека, который был бы занят архитектурой, нет аналитиков, которые бы уточняли требования, вы все спихиваете на какого-то мифического девопса, который все должен сделать и даже немного больше. Но так в жизни не работает, либо работает, но тогда такому специалисту вы вынуждены платить прямо-таки конский ценник (обычно речь про какого-то консультанта, которого вы приглашаете на проект, и он вам все такое делает под ключ), поскольку чисто из моего опыта есть полно мест, где таких требований не предъявляются, где роли распределены, а зоны отвественности устаканены, а сам процесс разработки и вывода в эксплуатацию согласован со всеми заинтересованными сторонами. Вообще это решается по-другому. Есть четкий чеклист "принятия сервиса в эксплуатацию", там обычно расписано что требуется, чтобы сервис можно было использовать в продакшене, а девопс в случае проблем смог бы подключиться и их решить, там как раз все эти моменты с SLA, отказоустойчивостью, деталей реализации архитектуры, а также многие другие важные вещи описаны, и заранее все стороны знают, что от них требуется. Вас могут за ручку провести в продакшен, но, например, ручки с метриками и правильный формат логов хоть убейте придется делать не девопсам, а разработчикам. В общем и целом, если работа построена правильно, если есть процесс, есть заявки с четким ТЗ, есть необходимые чеклисты, то никаких проблем не возникнет, в случае отсутствия всего вышегоперечисленного и формата работы "зачастую задача поставлена высокоуровнево, а вот на какие грабли придется наступить в процессе — будет ясно только по факту" будет масса сплошных неожиданностей, возникающих вследствие непонимания SDLC некоторыми менедежрами.
>Есть еще один путь — представитель техподдержки, который развился в DevOps. Причем, речь идет о классической техподдержке, например, оператора связи — т. е. о людях, помогающих решить вопросы по телефону, занимаются настройкой сетей и т. п., которым приходится много траблшутить и коммуницировать. Это может быть третья линия какого‑нибудь хостинга — ребята, которые каждый день решают бесконечную реку проблем. Но не просто решают, а потом еще и объясняют клиенту, что именно они сделали. С моей точки зрения статистически на этом пути чаще рождаются хорошие девопсы.
Ну и как вишенка на торте - вы видите в роли девопса человека уровня принеси-подай-иди-нафиг-не-мешай. Напоминаю, что этим специалистам вы платите огромные деньги за умение решать очень сложные вещи в очень сжатые сроки, у многих из этих специалистов реальное высшее образование, подкрепленное годами реальной практики, а иногда весь ваш бизнес буквально может от такого человека зависеть. Возможно, вам стоит подумать, что все-таки, если девопсы\разработчики так работают, то этому есть объяснение помимо того, что они все чудаки, и все делают неправильно, а вы сейчас их научите как верно им работать. Возможно, это вы все делаете неправильно. Почитайте, например, мифический человеко-месяц, там вообще говоря хорошо объяснены все трудности, которые возинкают в ходе разработки любого продукта. Хоть книжке уже несколько десятков лет, а очень свежо читается особенно в контексте вашего понимания, как должна быть устроена разработка и эксплуатация.
andreynekrasov
24.07.2025 12:27Нельзя просто так взять и обозвать эникейщика админом. Это отдельная и довольно высококвалифицированная работа. Без шуток. Я вот лично ноутбуки и маковские моноблоки чинить не полезу, да и винду или макось чинить не стану. И с приколами всех принтеров разбираться не хочу. Но они при этом не админы и в гробу это всё видели.
Странное предположение, что девопсам кто то платит x2-3 от разработчиков. Или я ошибаюсь насчет максимальной зп девопса в Москве/России (сеньорам больше 400т.р. в России вряд ли кто то предложит). Уверен, программисты сеньоры получают столько же или больше.
И в реальной жизни у девопсов разумеется всегда есть руководитель и не один. Команда тоже обычно есть. Редко на собеседованиях приходилось слышать, что нужен девопс-спаситель одна штука. Я от такого сразу отказывался.
lma10h
24.07.2025 12:27Без разницы, из админов или из разработчиков наш девопс.
Главное, что он понимает КАК автоматизировать рутину (CI, CD, ...), может сам это все РУКАМИ делать и имеет здравый смысл. Остальное получится :)
0x00FA7A55
Поделюсь опытом. Несколько лет руководил отделом и развивал девопс практики, в т.ч. иногда приходилось брать в команду совсем зелень. На мой взгляд у вчерашнего админа совсем другие проблемы:
Встречалось почти у всех: непонимание необходимости ведения документации; приходится прям с примерами пояснять, что будет с их фигнёй, которую они кинули а-ля я сделяль и радостно закрыли тикет.
Непомерная любовь к виртуалкам. Даже если чувак идеально проходит собес и всё знает про кубер, он вероятно в проде никогда им не пользовался. Или просто боится иметь с ним дело.
Непонимание как удобно людям и как сделать продукт, которым хочется пользоваться: баш портянки на 100500 строк, ключи ssh руками, вместо того чтоб прикрутить otp через vault, и другие моменты, банально вызванные отсуствием опыта.
Про то что он там не знает ansible или как гитом пользоваться, такие даже первичный скрининг у hr не проходят.
С вчерашними разработчиками, кстати, тоже есть списочек, к несчастью или к счастью такой у меня был только один:
Продолжает кодить и переусложнять. Ещё, зараза такая, обязательно постарается впихнуть то, чему в инфре не место, типа раста или котлина, которые кроме него никто в команде не знает. На вопрос, мол, а что не питон-то, начинает тираду про то что питон говно и вообще. На то что никто не будет после его ухода это поддерживать фыркает и говорит что ничего, перепишите. Ну не чудак ли?
Очень низкий технический уровень. Поправить ямлик он может, но если вдруг случится фигня с сетью или ещё какая засада, внезапно выясняется, что он не разбирается в этом. Можно повозражать, что это не работа девопса, но мы же знаем как у нас в большинстве компаний, так что спорить смысла особо не вижу.
Про хорошие практики тоже беда. Приходится пояснять и достаточно часто. Кажется, это беда всех зелёных
hellosamurai
>Продолжает кодить и переусложнять. Ещё, зараза такая, обязательно постарается впихнуть то, чему в инфре не место, типа раста или котлина, которые кроме него никто в команде не знает. На вопрос, мол, а что не питон-то, начинает тираду про то что питон говно и вообще. На то что никто не будет после его ухода это поддерживать фыркает и говорит что ничего, перепишите. Ну не чудак ли?
А парень ироничный попался. Обычно ведь как бывает. Разработчик говорит, что надо делать так и так, и будет нам всем счастье, а разработчику на это отвечают "Вася, все горит, давай в прод, потом если что проект перепишем". По итогу конечно никто никому рефакторинг проводить не дает, и все костыли живут до скончания времен, пока наконец сервис не складывается окончательно. А тут вам разработчик заявляет, что сделал все как надо, потом хотите переписывайте сами без меня. Умный, видно уже попадался на такие приколы, по ночам работать не хочет.