Кто лучший DevOps: админ, который освоил разработку, или разработчик, который освоил инфраструктуры
Изначально 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 инструментов, а параллельно качать софты, которые будут своего рода смазкой, которая поможет двигаться по этим рельсам.