Хабрахабр

Об админах, девопсах, бесконечной путанице и DevOps-трансформации внутри компании

Лекторы на конфах и митапах говорят много громких и не всегда понятных нормальным людям слов. Что нужно для успеха IT-компании в 2019 году? Если отбросить словесную красоту и говорить прямо и по-русски, то всё сводится к простому тезису: делайте качественный продукт, причем делайте его с комфортом для команды. Борьба за время деплоя, микросервисы, отказ от монолита, DevOps-трансформация и много-много чего ещё.

Бизнес наконец-то пришел к мысли, что комфортный процесс разработки повышает продуктивность, а если все отлажено и работает как часы, то ещё и даёт некоторое пространство для маневра в критических ситуациях. Последнее стало критически важно. Когда-то ради этого маневра некий умный человек придумал бэкапы, но индустрия развивается, и мы пришли к DevOps-инженерам — людям, которые превращают процесс взаимодействия разработки и внешней инфраструктуры во что-то адекватное и не связанное с шаманизмом.

К текущему моменту ситуация сложилась таким образом, что мы вышли на двойственность этого понятия: инфраструктура может быть условно внешней и условно внутренней. Вся эта история от «по модулю» прекрасна, но… Так получилось, что часть админов резко окрестили в DevOps, а от самих DevOps-инженеров стали требовать, как минимум, навыков телепатии и ясновидения.
Прежде чем говорить о современных проблемах обеспечения инфраструктуры, давайте определимся, что мы под этим термином подразумеваем.

Это серверы приложения или сайта, хостинг и прочие сервисы, обеспечивающие работоспособность продукта. Под внешней инфраструктурой стоит подразумевать всё то, что обеспечивает работоспособность сервиса или продукта, разработкой которой занимается команда.

Это внутренние серверы систем хранения кода, локально развернутый таск-менеджер и всё-всё-всё, что существует в рамках корпоративного интранета. Внутренняя инфраструктура включает в себя сервисы и оборудование, которыми пользуется сама команда разработки и прочие сотрудники, коих обычно тоже немало.

Кроме работы по администрированию этого самого корпоративного интранета, на нем частенько лежит груз хозяйственных забот по обеспечению работоспособности офисного оборудования. Чем же занимается в компании системный администратор? Админ — это локальный хозяин и повелитель не только внутренних и внешних серверов, но еще и хозяйственник. Админ — это тот самый парень, который быстро притащит из подсобки новый системник или готовый к работе запасной ноутбук, выдаст свежую клавиатуру и будет ползать на четвереньках по кабинетам, протягивая Ethernet-кабель. Их стоит выделить в отдельный подкласс «инфраструктурных системных администраторов». Да, некоторые администраторы могут работать только в системной плоскости, без железа. Но ни те, ни другие девопсами не являются. А кто-то специализируется на обслуживании исключительно офисного оборудования, благо, если компания насчитывает больше сотни человек, работа не кончается никогда.

Девопсы — это ребята, которые про взаимодействие разработки программного обеспечения с внешней инфраструктурой. А кто такие DevOps? Одна из ключевых задач DevOps-инженера сейчас — это обеспечение комфортного и эффективно выстроенного процесса взаимодействия команд разработки и инфраструктуры продукта. Точнее, современные девопсы вовлечены в процессы разработки и деплоя намного глубже, нежели были когда-либо вовлечены админы, просто заливавшие апдейты на ftp. При этом девопс никогда не будет протягивать новый кабель или выдавать новый ноутбук из подсобки (с) КО Именно эти люди ответственны за развёртывание систем откатов и деплоя, именно эти люди снимают часть нагрузки с девелоперов и максимально концентрируются на своей крайне важной задаче.

В чём подвох?

На вопрос «А кто такой DevOps?» половина работников сферы начинает отвечать что-то вроде «Ну, это, короче, такой админ, который…» и далее по тексту. Да, когда-то давно, когда профессия DevOps-инженера только-только выпочковывалась из самых талантливых в плане обслуживания сервисов админов, различия между ними были не всем очевидны. Но сейчас, когда функции девопса и админа в команде стали радикально различаться, путать их между собой, а то и вовсе ставить между ними знак равенства — недопустимо.

Но во что это выливается для бизнеса?

Найм, всё дело в нем.

Подвох в том, что вместо «Системный администратор» в заголовке вакансии должно стоять «DevOps-инженер», и если этот заголовок поменять, то все становится на свои места. Вы открываете вакансию «Системный администратор», а там перечислены требования «взаимодействие с разработкой и заказчиками», «система доставки CI/CD», «обслуживание серверов и оборудования компании», «администрирование внутренних систем» и так далее; вы понимаете, что наниматель несет какую-то чушь.

Что компания ищет многостаночника, который и систему контроля версий и мониторинга развернет, и витуху обожмет зубами… Однако какое впечатление создается при прочтении такой вакансии?

Вот только неуёмное желание некоторых работодателей предъявить к кандидату как можно более широкий список требований приводит к тому, что «классические» системные администраторы перестают понимать, что происходит вокруг них. А ведь для того, чтобы не повышать градус наркомании на рынке труда, достаточно называть вакансии своими именами и чётко понимать, что DevOps-инженер и системный администратор — это две разные сущности. Что, профессия мутирует и они отстали от жизни?

Инфраструктурные админы, которые будут рулить внутренними серверами компании, или занимать позиции L2/L3-саппорта и помогать другим сотрудникам, никуда не делись и деваться не собираются. Нет, нет и ещё раз нет.

Конечно, могут. А могут ли эти специалисты стать DevOps-инженерами? По факту, это родственная им среда, которая требует навыков системного администрирования, но помимо этого, добавляется работа с мониторингом, системами доставки и, в целом, плотное взаимодействие с командой разработки и тестирования.

Еще одна проблема DevOps

На самом деле, только наймом и постоянной путаницей между админами и девопсами всё не ограничивается. В какой-то момент бизнес столкнулся с проблемой доставки обновлений и взаимодействия команды разработки с конечной инфраструктурой.

Эти ребята решат все ваши проблемы» — и начал рассказывать, как хорошо живется в компании после внедрения DevOps-практик. Возможно, это было тогда, когда на сцену какой-то конференции поднялся дядя с горящими глазами и сказал «А мы делаем вот так и называем это DevOps.

Компания должна целиком пройти DevOps-трансформацию, то есть роль и возможности нашего девопса должны четко осознавать ещё и на стороне команды разработки и тестирования продукта. Однако недостаточно нанять DevOps-инженера для того, чтобы все стало работать «как надо». На эту тему у нас есть «прекрасная» история, которая в полной мере иллюстрирует всю происходящую местами жесть.

От девопса требуют развернуть систему отката версий, особо не вникая, как она будет работать. Ситуация. Выходит новая версия продукта, но для разработчиков «откат» — это просто волшебная палочка, которая всё починит, и они даже не представляют, как она работает. Предположим, внутри системы Users — это отдельные поля под имя, фамилию и пароль. Что происходит? Так вот, к примеру, разработчики в очередном патче объединили поля имени и фамилии, выкатили это в прод, а версия тормозит по каким-то причинам. Что делает девопс? Руководство приходит к девопсу и говорит «Дёргай рубильник!», то есть просит его откатиться на предыдущую версию. В итоге у нас падает вообще всё, и пользователи вместо тормозящего сайта видят ошибку «500», потому что старая версия не работает с полями новой базы. Он откатывается на предыдущую версию, но так как разработчики не захотели разбираться, как делается этот откат, то никто девопсу не сказал, что откатить нужно еще и базу. Разрабы молчат. Девопс об этом не в курсе. В результате пользователи теряют все свои данные за какой-то промежуток времени. Руководство начинает терять нервы и деньги и вспоминает о бэкапах, предлагая откатиться с них, чтобы «хоть что-нибудь да работало».

На орехи достается, конечно же, девопсу, который «не сделал правильную систему отката», а то что лоси в этой истории — разработчики, никого не волнует.

Девопсов нельзя оставить один на один с их «проблемами» или дать команду «не лезь к разрабам, их дело кодить», а потом надеяться, что в критический момент всё будет работать, как надо. Вывод простой: без нормального подхода к DevOps как таковому толку от него не очень много.
Главное, что нужно помнить: DevOps-инженер — не волшебник, и без качественных коммуникаций и двустороннего взаимодействия с разработкой он не будет справляться со своими задачами. Так это не работает.

Причём, далеко не очевидно, что в этом коктейле технологий должно быть больше, чем менеджмента. По сути, DevOps — это компетенции на грани между менеджментом и технологиями. Он знает нужные инструменты, он реализовывал подобные проекты, он знает, как делать. Если вы действительно хотите построить более быстрые и эффективные процессы разработки, вы должны доверять своему девопсу. Если админы могут работать сами по себе, то девопсы в таком случае бесполезны, они не смогут помочь вам стать лучше, если вы сами не захотите эту помощь принять. Помогите ему, прислушайтесь к его советам, не пытайтесь изолировать в какое-то автономное подразделение.

У них свой, крайне важный фронт работ. Ну и ещё: хватит обижать администраторов-инфраструктурщиков. И нет ничего плохого в том, что системный администратор хочет остаться системным администратором — это его отдельная профессия и его право. Да, админ может стать DevOps-инженером, но это должно происходить по желанию самого человека, а не из-под палки. Всех этих людей сводить вместе и учить общаться на одном языке, скорее всего, придется именно вам как руководителю. Если же есть желание пройти профессиональную трансформацию, то надо ни в коем случае не забывать, что наращивать придется не только технологические навыки, но еще и управленческие.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть