Изначально 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 инструментов, а параллельно качать софты, которые будут своего рода смазкой, которая поможет двигаться по этим рельсам.
Источник: https://habr.com/ru/articles/930108/