Из сетевых администраторов в CloudOps: особенности перехода и онбординга

Меня зовут Люба Руденко. В прошлом году я сменила сферу —  перешла из телеком-компании к облачному провайдеру. Прошла тернистый путь новичка испытательный срок и сейчас работаю младшим системным администратором в инфраструктуре облака Selectel. 

В тексте расскажу о своем опыте карьерного перехода: как однажды захотела стать DevOps-специалистом, но в итоге решила расти в CloudOps. Опишу с позиции джуна, чем работа сетевого администратора отличается от сисадмина облачной инфраструктуры, а чем, наоборот, схожа. Остановлюсь также на том, как адаптировалась на новом месте, решала первые задачи и восполняла недостаток знаний в процессах и командах.

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

Дисклеймер: весь текст основан на субъективном опыте. Это не руководство к действию, а мой личный путь, который только начался.

Как я попала в сети

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

Проработала в этом месте четыре года и попробовала себя в разных задачах. Например, сопровождала ЛВС (локально-вычислительную сеть) здания, в котором работала, проектировала схемы прокладки оптоволокна, настраивала сетевое оборудование для узлов связи. «Вишенкой на торте» стало сопровождение ЛВС крупного ЦОД компании. 

Спойлер: этот ЦОД, а точнее опыт его обслуживания, вдохновил меня учиться новому и «привел»‎ в Selectel. 

Когда начала работать в дата-центре, столкнулась с серверами в разных исполнениях: блейды, физические серверы на 1-3 юнита, в том числе под облачные сервисы. Все это нужно было подключать к сетевому оборудованию, поэтому я стала взаимодействовать с сисадминами и программистами. 

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

Например, иногда они не могли понять, какой тип подключения и какие VLAN нужны. Также возникали сложности в обозначениях одного и того же: в сетях агрегат интерфейсов называют port-channel или ether-channel, а сисадмины чаще называют эту технологию bond. Сейчас уже привычно это слышать, но тогда резало слух.

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

Что я изучала, чтобы обогатить свой «сетевой»‎ багаж знаний:  

• Читала документацию по технологиям. Например, про Ansible, Git и Gitlab, Docker, Kubernetes и другое.
• Изучала видеоуроки на YouTube. Смотрела лекции технического директора Selectel Кирилла Малеванова, образовательные ролики на ADV-IT.
• Создала тестовый стенд, который стоял на балконе: сервер с гипервизором и кучей виртуалок, на котором прокачивала свои знания в Linux.
• Сходила на несколько собеседований, чтобы разобраться в запросах работодателей и актуальных темах. Самые популярные вопросы были: «Как выйти из vim»?‎ или «В чем отличие виртуализации от контейнеризации?»‎.
• Общалась с коллегами и друзьями, которые уже стали девопсами.

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

Облака и сети: сходства и различия

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

Работая в облаке, я обслуживаю серверы, на которых находятся проекты клиентов. В телекоме у меня была другая роль — настраивала сети для системных администраторов (по сути для таких, как я сейчас). Этот опыт помогает мне смотреть на роли, работу и обеспечение услуг с разных сторон.

Сначала расскажу про точки пересечений.

Что общего в работе в телекоме и у облачного провайдера?

Общий подход к установке и поддержке

Любое оборудование, серверное или сетевое, нужно настроить, поставить в стойку и поддерживать в актуальном состоянии для качественного обеспечения услуг. Например, обновлять или заменять комплектующие (вентиляторы, плашки памяти), чистить от пыли, обновлять программное обеспечение, устранять появляющиеся баги, оптимизировать сеть и стек оборудования. Также необходимо поддерживать производительность и следить, чтобы не было перегрева.

ПО сетевого оборудования, с которым я много работала до Selectel, основано на FreeBSD. Это система семейства Unix. Сейчас я в контакте с серверами на Ubuntu — это дистрибутив, основанный на Debian GNU/Linux. У этих систем есть схожие команды проверки маршрутизации, уровней сигнала оптических портов или расположения логов.  

Кроме того, устройство и сетевого, и серверного оборудования примерно одинаковое: есть оперативная память, кулер , корпус, материнская плата и процессор. Если какую-то железку поставили в ЦОД, это не на один день, и нужно следить за ее состоянием. Отсюда вытекает следующий пункт.

Мониторинг 

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

Подход и в сетях, и в облаке по сути один и тот же: приходит аллерт, нужно как можно быстрее его обработать без потери качества. Самому или с привлечением коллег из смежных команд. 

Какие проблемы могут возникать? Самые разные: вышли из строя кулер или карта памяти, возникли ошибки на интерфейсах разного типа, появились задержки, перестали работать экспортеры, система мониторинга больше не видит оборудование.

Алерты могут быть плановыми (при проведении работ) и внеплановыми. О них нужно оповещать смежные отделы. Еще — следить за сообщениями и отключать мониторинг, чтобы неважные или запланированные алерты не тревожили несколько команд сразу. 

→ В облаке Selectel мы обращаемся к ИТО в случае аппаратной неисправности. К дежурным из сетевого департамента — в случае проблем с сетью, к ceph-team — при проблемах с Ceph. Алерты могут прийти даже при первичной настройке оборудования, что помогает не ввести в эксплуатацию заведомо неисправное железо. Все инциденты приходят в специально созданные чаты в мессенджере.

→ Когда я работала в сетях, алерты обрабатывал или отдел, специализирующийся на них, без привлечения дневных специалистов, если это не крупная авария, или несколько людей в команде.

Дежурства и смены 

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

В облаке и сетевых службах есть свои системы, где дежурный отвечает за происходящее и реагирует на инциденты. Само устройство мониторинга и слежения за алертами различается. Об этом расскажу в следующей части.

Новые технологии и оптимизация

Развитие не стоит на месте. И в той, и в другой сферах нужно держать руку на пульсе: появляются новые версии и релизы компонентов железа и ПО, периодически его нужно обновлять. Обновления несут за собой апдейты (модификации сетевых карт, контроллеров) и новые задачи. Следовательно, текущую инфраструктуру нужно поддерживать и оптимизировать. 

Что касается оптимизации внутренних процессов, в облаке мы используем средства автоматизации. Они помогают выполнять рутинные задачи в разы быстрее — за 10 минут вместо 2-3 часов. Так, например, знание Ansible и Puppet я постепенно прокачиваю не на тестовом стенде, а в продуктовых реалиях.

Что разного?

Выше я описала общее в обеих сферах, но есть и немало различий. Часть исходят из специфики компании, в которой работаешь. 

Разница в подходах к работе

Одно из различий — это способ поддержания актуальности кода и конфигураций. В сетях у меня были свои базы данных с конфигурациями, которые сливаются каждый день — например, в 5 утра. Доступ предоставляется только к оборудованию из твоей зоны ответственности.  

В облаках у нас в команде, да и в компании в целом, используется система управления конфигурацией Puppet и инструмент для хранения и управления репозиториями — Git и Gitlab. Получается, удаленные репозитории, которые содержат конфигурации устройств, непрерывно обновляются и поддерживаются в актуальном состоянии. Для всей команды это открытый код. Значит, больше прозрачности и универсальности.

Придя в Selectel, я впервые столкнулась с системой «спринтов»‎ и «планингов»‎. Задачи ставятся на неделю или более глобально — на месяц. Так проще отслеживать объем проделанной работы и планировать время. Хотя пятницы лично для меня стали более напряженными — хочется «закрыть»‎ все задачи из спринта, но часть из них объемны и занимают не одну неделю.

Мониторинг

Что касается мониторинга, то могут использоваться разные системы. Следовательно, различаются способы ввода и вывода оборудования. Например, когда работала в сетях, в системе отслеживания задач выставлялось определенное время простоя. В облаке же ввожу определенную команду на оборудовании, с которым работаю,‎ или выставляю параметры на общем алерт-менеджере, которые помогут не допустить ложное срабатывание алертов.

Отработка инцидентов и дежурства

В облаке есть отдельная группа, которая следит за алертами, — Cloud Duty. Она охватывают весь пул проблем. В случае непонятной ситуации, большого количества алертов или массовой аварии сотрудники «призывают»‎ специалистов из смежных групп — например, из команды инфраструктуры облака, объектного хранилища, Сeph и других.

Чтобы не дергать сразу всех членов команды, существуют дежурства. Конкретно у нас смена длится неделю: с утра понедельника до утра следующего понедельника. Дежурный должен быть доступен даже ночью — иметь при себе ПК, чтобы оперативно подключиться к решению проблемы. При этом у каждого дежурного есть напарник, который может подстраховать и взять на себя часть нагрузки.

В сетях — точнее конкретно в тех организациях, где я работала —  дежурства были устроены чуть по-другому. Был отдел, который круглосуточно занимался только инцидентами. Другие отделы подключались в случае, если это было вызвано плановыми работами у конкретного специалиста или если проблема глобальная. Чаще работа данных отделов не пересекалась. Организованных дежурств в профильных группах где-то не было и вовсе. В каких-то организациях был график дежурств у основного состава, где дежурные от отдела менялись не 4 раза в месяц, а каждый день.

Переход из сетей в облако: начало онбординга и первые сложности

Страхи

Вернемся к моему пути. Когда я перешла в Selectel, столкнулась с классической проблемой новичка: было страшно, что не справлюсь, не разберусь в новой для себя сфере.

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

Влиться в процессы и упорядочить знания мне помог план адаптации. В нем понедельно было расписано, что я должна делать: какие системы изучить более глубоко и какой результат показать по итогам испытательного. Например, там было зафиксировано, что на 1-3 месяце работы я должна настраивать серверное оборудование в staging и testing регионах, а на 2-3 — самостоятельно настраивать их уже в production, уметь диагностировать проблемы при настройке хостов и т.д.

Также в Selectel у каждого нового сотрудника есть бадди — это коллега по команде или в отделе, который является твоим неформальным наставником. К нему можно обратиться с любыми вопросами — от того, куда лучше сходить пообедать, до оформления задач в рабочих системах. В первые дни мой бадди подсказывал, где находятся переговорки и кофе-поинты, как мне заказать монитор для работы или какие доступы запросить для выполнения задач, делился рабочими лайфхаками и т. д.

Пробелы в знаниях

В самом начале я спотыкалась о многие задачи: не хватало знаний о том, какие команды использовать или как процесс организован именно в Selectel. Последнее — из серии, когда не знаешь, что именно гуглить.

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

Другой пример: у меня была простейшая задача на распортовку для переключения серверов в системе учета, но она не сохраняла данные. Все из-за того, что у меня не было доступа на запись, только на чтение.  

Таких проблем было много, но все они благополучно решались с помощью коллег, бадди и моих усилий.

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

Результаты испытательного и планы на будущее

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

Мне удалось влиться в команду — в ней 14 человек. Кстати, это одна из самых больших команд в облаке. При этом начинающих специалистов не больше трети. Остальные — мидлы и синьоры — активно делятся опытом и знаниями с новенькими. Нам есть, на кого равняться и кому предлагать свои идеи по улучшению процессов.

Еще мне нравится, что в команде каждый может выполнять базовые задачи — например, сетапы хостов, а также отвечает за что-то свое: автоматизацию, сетевую часть в серверах, решение проблем в нашей зоне ответственности, тестирование новых компонентов, организационные моменты, пленнинги. Также помогает активное взаимодействие со смежными командами, которые отвечают, например, за Ceph или объектное хранилище.

Считаю, что за минувшие месяцы мой уровень как специалиста сильно вырос. Я узнала подробнее об устройстве серверов. Еще о том, какие проблемы могут быть, например, когда на сетевой карте неактуальная прошивка, проблемы с кулерами, IPMI, самой платформой. Сейчас я активно изучаю ОС Linux, а именно Ubuntu, способы разметки дисков, сборку raid10 и другие темы. 

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