Об админах, девопсах, бесконечной путанице и DevOps-трансформации внутри компании
Что нужно для успеха IT-компании в 2019 году? Лекторы на конфах и митапах говорят много громких и не всегда понятных нормальным людям слов. Борьба за время деплоя, микросервисы, отказ от монолита, DevOps-трансформация и много-много чего ещё. Если отбросить словесную красоту и говорить прямо и по-русски, то всё сводится к простому тезису: делайте качественный продукт, причем делайте его с комфортом для команды.
Последнее стало критически важно. Бизнес наконец-то пришел к мысли, что комфортный процесс разработки повышает продуктивность, а если все отлажено и работает как часы, то ещё и даёт некоторое пространство для маневра в критических ситуациях. Когда-то ради этого маневра некий умный человек придумал бэкапы, но индустрия развивается, и мы пришли к DevOps-инженерам — людям, которые превращают процесс взаимодействия разработки и внешней инфраструктуры во что-то адекватное и не связанное с шаманизмом.
Вся эта история от «по модулю» прекрасна, но… Так получилось, что часть админов резко окрестили в DevOps, а от самих DevOps-инженеров стали требовать, как минимум, навыков телепатии и ясновидения.
Прежде чем говорить о современных проблемах обеспечения инфраструктуры, давайте определимся, что мы под этим термином подразумеваем. К текущему моменту ситуация сложилась таким образом, что мы вышли на двойственность этого понятия: инфраструктура может быть условно внешней и условно внутренней.
Под внешней инфраструктурой стоит подразумевать всё то, что обеспечивает работоспособность сервиса или продукта, разработкой которой занимается команда. Это серверы приложения или сайта, хостинг и прочие сервисы, обеспечивающие работоспособность продукта.
Внутренняя инфраструктура включает в себя сервисы и оборудование, которыми пользуется сама команда разработки и прочие сотрудники, коих обычно тоже немало. Это внутренние серверы систем хранения кода, локально развернутый таск-менеджер и всё-всё-всё, что существует в рамках корпоративного интранета.
Чем же занимается в компании системный администратор? Кроме работы по администрированию этого самого корпоративного интранета, на нем частенько лежит груз хозяйственных забот по обеспечению работоспособности офисного оборудования. Админ — это тот самый парень, который быстро притащит из подсобки новый системник или готовый к работе запасной ноутбук, выдаст свежую клавиатуру и будет ползать на четвереньках по кабинетам, протягивая Ethernet-кабель. Админ — это локальный хозяин и повелитель не только внутренних и внешних серверов, но еще и хозяйственник. Да, некоторые администраторы могут работать только в системной плоскости, без железа. Их стоит выделить в отдельный подкласс «инфраструктурных системных администраторов». А кто-то специализируется на обслуживании исключительно офисного оборудования, благо, если компания насчитывает больше сотни человек, работа не кончается никогда. Но ни те, ни другие девопсами не являются.
А кто такие DevOps? Девопсы — это ребята, которые про взаимодействие разработки программного обеспечения с внешней инфраструктурой. Точнее, современные девопсы вовлечены в процессы разработки и деплоя намного глубже, нежели были когда-либо вовлечены админы, просто заливавшие апдейты на ftp. Одна из ключевых задач DevOps-инженера сейчас — это обеспечение комфортного и эффективно выстроенного процесса взаимодействия команд разработки и инфраструктуры продукта. Именно эти люди ответственны за развёртывание систем откатов и деплоя, именно эти люди снимают часть нагрузки с девелоперов и максимально концентрируются на своей крайне важной задаче. При этом девопс никогда не будет протягивать новый кабель или выдавать новый ноутбук из подсобки © КО
В чём подвох?
На вопрос «А кто такой DevOps?» половина работников сферы начинает отвечать что-то вроде «Ну, это, короче, такой админ, который…» и далее по тексту. Да, когда-то давно, когда профессия DevOps-инженера только-только выпочковывалась из самых талантливых в плане обслуживания сервисов админов, различия между ними были не всем очевидны. Но сейчас, когда функции девопса и админа в команде стали радикально различаться, путать их между собой, а то и вовсе ставить между ними знак равенства — недопустимо.
Но во что это выливается для бизнеса?
Найм, всё дело в нем.
Вы открываете вакансию «Системный администратор», а там перечислены требования «взаимодействие с разработкой и заказчиками», «система доставки CI/CD», «обслуживание серверов и оборудования компании», «администрирование внутренних систем» и так далее; вы понимаете, что наниматель несет какую-то чушь. Подвох в том, что вместо «Системный администратор» в заголовке вакансии должно стоять «DevOps-инженер», и если этот заголовок поменять, то все становится на свои места.
Однако какое впечатление создается при прочтении такой вакансии? Что компания ищет многостаночника, который и систему контроля версий и мониторинга развернет, и витуху обожмет зубами…
А ведь для того, чтобы не повышать градус наркомании на рынке труда, достаточно называть вакансии своими именами и чётко понимать, что DevOps-инженер и системный администратор — это две разные сущности. Вот только неуёмное желание некоторых работодателей предъявить к кандидату как можно более широкий список требований приводит к тому, что «классические» системные администраторы перестают понимать, что происходит вокруг них. Что, профессия мутирует и они отстали от жизни?
Нет, нет и ещё раз нет. Инфраструктурные админы, которые будут рулить внутренними серверами компании, или занимать позиции L2/L3-саппорта и помогать другим сотрудникам, никуда не делись и деваться не собираются.
А могут ли эти специалисты стать DevOps-инженерами? Конечно, могут. По факту, это родственная им среда, которая требует навыков системного администрирования, но помимо этого, добавляется работа с мониторингом, системами доставки и, в целом, плотное взаимодействие с командой разработки и тестирования.
Еще одна проблема DevOps
На самом деле, только наймом и постоянной путаницей между админами и девопсами всё не ограничивается. В какой-то момент бизнес столкнулся с проблемой доставки обновлений и взаимодействия команды разработки с конечной инфраструктурой.
Возможно, это было тогда, когда на сцену какой-то конференции поднялся дядя с горящими глазами и сказал «А мы делаем вот так и называем это DevOps. Эти ребята решат все ваши проблемы» — и начал рассказывать, как хорошо живется в компании после внедрения DevOps-практик.
Однако недостаточно нанять DevOps-инженера для того, чтобы все стало работать «как надо». Компания должна целиком пройти DevOps-трансформацию, то есть роль и возможности нашего девопса должны четко осознавать ещё и на стороне команды разработки и тестирования продукта. На эту тему у нас есть «прекрасная» история, которая в полной мере иллюстрирует всю происходящую местами жесть.
Ситуация. От девопса требуют развернуть систему отката версий, особо не вникая, как она будет работать. Предположим, внутри системы Users — это отдельные поля под имя, фамилию и пароль. Выходит новая версия продукта, но для разработчиков «откат» — это просто волшебная палочка, которая всё починит, и они даже не представляют, как она работает. Так вот, к примеру, разработчики в очередном патче объединили поля имени и фамилии, выкатили это в прод, а версия тормозит по каким-то причинам. Что происходит? Руководство приходит к девопсу и говорит «Дёргай рубильник!», то есть просит его откатиться на предыдущую версию. Что делает девопс? Он откатывается на предыдущую версию, но так как разработчики не захотели разбираться, как делается этот откат, то никто девопсу не сказал, что откатить нужно еще и базу. В итоге у нас падает вообще всё, и пользователи вместо тормозящего сайта видят ошибку »500», потому что старая версия не работает с полями новой базы. Девопс об этом не в курсе. Разрабы молчат. Руководство начинает терять нервы и деньги и вспоминает о бэкапах, предлагая откатиться с них, чтобы «хоть что-нибудь да работало». В результате пользователи теряют все свои данные за какой-то промежуток времени.
На орехи достается, конечно же, девопсу, который «не сделал правильную систему отката», а то что лоси в этой истории — разработчики, никого не волнует.
Вывод простой: без нормального подхода к DevOps как таковому толку от него не очень много.
Главное, что нужно помнить: DevOps-инженер — не волшебник, и без качественных коммуникаций и двустороннего взаимодействия с разработкой он не будет справляться со своими задачами. Девопсов нельзя оставить один на один с их «проблемами» или дать команду «не лезь к разрабам, их дело кодить», а потом надеяться, что в критический момент всё будет работать, как надо. Так это не работает.
По сути, DevOps — это компетенции на грани между менеджментом и технологиями. Причём, далеко не очевидно, что в этом коктейле технологий должно быть больше, чем менеджмента. Если вы действительно хотите построить более быстрые и эффективные процессы разработки, вы должны доверять своему девопсу. Он знает нужные инструменты, он реализовывал подобные проекты, он знает, как делать. Помогите ему, прислушайтесь к его советам, не пытайтесь изолировать в какое-то автономное подразделение. Если админы могут работать сами по себе, то девопсы в таком случае бесполезны, они не смогут помочь вам стать лучше, если вы сами не захотите эту помощь принять.
Ну и ещё: хватит обижать администраторов-инфраструктурщиков. У них свой, крайне важный фронт работ. Да, админ может стать DevOps-инженером, но это должно происходить по желанию самого человека, а не из-под палки. И нет ничего плохого в том, что системный администратор хочет остаться системным администратором — это его отдельная профессия и его право. Если же есть желание пройти профессиональную трансформацию, то надо ни в коем случае не забывать, что наращивать придется не только технологические навыки, но еще и управленческие. Всех этих людей сводить вместе и учить общаться на одном языке, скорее всего, придется именно вам как руководителю.
