Кто я

Привет! Мне 37 лет, и я — джун-девопс. Да, звучит немного забавно, когда говоришь о возрасте и понимаешь, что к этому моменту многие уже заканчивают свой путь в ИТ и уходят в плотники, столяры или фермеры. А меня, наоборот, захватил природный интерес, который в итоге привёл к работе мечты! В этой статье я попробую разложить всё по полочкам и рассказать о нюансах своего пути.

Глава 1. Начало

Я родился и вырос в маленьком городке в центре России, и увидеть ИТ в том виде, к которому привыкли сверхразумы из Яндекса с макбуками и айфонами, мне не удалось. Cвой путь я начал как стандартный «виндовый» админ в конторах, где надо было менять картриджи и ползать под столами в бухгалтерии. 

Но время шло, я набирался опыта, иногда релевантного, иногда не очень. 
В 2018 году я «дорос» до начальника отдела в нашем региональном отделении «Газпрома».
Задачи были самыми разнообразными, но именно с того момента начинается история, приближенная к тому, чем занимается опс в привычном понимании.

Вместе с коллегами мы занимались различными задачами: переехали с платной VMware на бесплатный Proxmox, настроили стабильную связь между удаленными объектами и автоматизировали всю рутину (правда, ещё не в том виде, в котором это представляет себе девопс). Время шло, зарплата не росла, мотивации оставаться не было, и весь отдел дружно вышел на вольные хлеба, начав искать место под солнцем.

Глава 2. Prod Support

В 2021 году, волею судьбы и по приглашению бывшего/нынешнего коллеги, я попал в продсаппорт команду компании. 

EXANTE – брокерская компания с собственной трейдинговой платформой на которой можно торговать по всему миру – больше 50 доступных рынков можно использовать с единого мультивалютного счета. Основные клиенты – профессиональные трейдеры и институциональные клиенты.

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

Несколько слов о том как устроена Команда Prod Support.

По факту это техническая поддержка в L2-L3, где самая важная обязанность команды – следить за состоянием продакшн-окружения и реагировать как на нестандартные ситуации, связанные с работой системы в целом, так и на локальные инциденты: от проблемы рядового пользователя (то что не решили на первой линии), до инцидентов, связанных с отдельными компонентами системы. 

На команде, помимо описанного, лежит ответственность за релизный процесс. Инцидент менеджмент, релиз менеджмент и полное управление production средой – это все в их руках. 

Инженер продсаппорта — это человек, который:

  • И сторожит покой продакшна,

  • И тушит пожары,

  • И крутит релизы,

  • И знает, куда бить молотом знаний, если всё же что-то упало.

Почти 90% моих коллег это бывшие сисадмины, которые имели в арсенале знания из различных областей, по большей части линуксоиды. Стандартный стек для коллеги продасспорта – это знание линукса, понимание того как работает сеть, мониторинг (по больше части Zabbix/Grafana), понимание веб-технологий, ну и дальше кто-что (чем больше, тем лучше). В частности, очень ценились умения, связанные с биржевой торговлей.

Отдельное приключение для новичка – это процесс онбординга. Он длится 6 недель и все это время ты просто закапываешься в огромное колличество информации. И как итог, инженер продсапа – это тот человек, который имеет максимально полную информацию о том, как работает система в целом. 

Как раз поэтому данная команда – кузница кадров для IT Operations, и не только. Четыре коллеги из пяти, уходя из команды, остаются в компании – и переходят в разработку, тестирование или девопс.

Когда я начал втягиваться в работу, в голове звучало: «Какой Линукс, какие логи, как я работать буду? Выгонят через неделю!». Несмотря на рой сомнений, кушать хотелось, платили хорошо, а главное — можно было сидеть дома и чувствовать себя настоящим удалёнщиком. После ковида это было очень круто.

Глава 3. Обучение. Пет-проект

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

Маленький, но приятный момент – компания оплатила мне половину стоимости курса. И вот, с ноября я — студент, «будущий девопс» на одном из курсов по обучению IT специалистов.

Давайте в нескольких словах опишу работу DevOPS & Infrastructure команды.

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

Представьте себе, что в одной компании существует таинственный отдел «Девопс и инфраструктура». Говорят, у них всегда включён свет и пульсируют огоньки на серверах (как в научно-фантастических фильмах, правда мы этих огоньков не видим – вся наша инфра в облаках). Заходишь к ним — а там ребята как тайный орден: сидят в худи, вокруг них пантеон мониторов, и они беспрерывно шепчут заклинания вроде «kubectl apply», «terraform plan» и «docker-compose up».

Чем же они занимаются?

1. Заклинания и ритуалы на серверах:

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

2. Покорение туманных облаков:

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

3. Автоматизация, или «ленивые, но умные»:

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

4. Контейнеры — новые матрешки:

Они могут засунуть сервер в контейнер, контейнер в сервис, а сервис — обратно в контейнер! В общем, Docker — это как русские матрешки, только в мире IT.
И это очень удобно: хочешь потестить новую версию? Пожалуйста, щёлк — и новая матрешка готова.

5. Обнимашки с мониторингом и логами:

Девопс-инфраструктурщики обожают следить за показателями (CPU, память, диски, настроение кошек в офисе — всё, что можно измерить).
Если что-то пошло не так, они обычно первыми видят тревожные сигналы и бегут тушить «виртуальный пожар».

6. Герои невидимого фронта:

Если всё работает гладко — никто о них не вспоминает (ведь проблем нет).

Но стоит упасть одному маленькому сервису, и все кричат: «Спасите, помогите! Где же наши Девопсы?!» — а они уже там, в первом ряду, в обнимку с логами, а в руках гаечный ключ и Python-скрипт.

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

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

Дорогой читатель спросит: «А чего не учиться там, где работаешь?» И будет прав. Но нельзя просто прийти и сказать: «Ща я вам тут всё поправлю». Поэтому в голове возникла мысль, что неплохо было бы придумать проект, в котором пригодились бы мои полученные, сырые знания.

Тут сразу отмечу: в продсаппорте работа была сменной, график менялся, а это значило, что я мог спокойно распределять своё время, разделяя его между работой, учебой, семьей и проектом. Да, было тяжело, и делать такие вещи надо не в 35 лет, как я, а лет в 20: и мозги работают быстрее, и спать можно по 3 часа в сутки, и спина не беспокоит, не говоря уже о детях-школьниках и их домашних заданиях.

Но цель поставлена, дело за малым — придумать такой проект. 

Я решил не гадать и обратиться к коллегам напрямую. Они с готовностью мне помогли – не долго думая, ребята накидали проект, в котором хотели видеть все то, что должен уметь джун. Пилотно требовалось развернуть ансибл, настроить его, написать некие плейбуки и обкатать их. В задаче было все, что меня интересовало: кубернетес, гит, докер и т.д.  Проектная работа: есть задача и есть срок. 
Ребята давали задания и контролировали их выполнения, попутно приглашая в миты, на которых они устраивали мозговые штурмы (по правде сказать 60% того, о чем они говорили на тот момент мне не было понятно, но сейчас-то я знаю где собака зарыта). Помимо этого, я забирал текущие задачи, которые сыпались и описывал их решение.
Работа закипела: основная работа шла в штатном режиме, обучение двигалось, а полученные знания реализовывались на «пет-проекте». Да, это был тяжёлый период в жизни, потому что балансировать в таком режиме было довольно трудно. Сколько раз я корил себя за то, что не познакомился с этим раньше, но история не имеет сослагательного наклонения.

Глава 4. Junior Dev Ops. IT Operations 

Проект и обучение одновременно подходили к концу. За это время я познакомился с основными для девопс-инженера инструментами: Docker, Kubernetes, облачными решениями (правда, это был Яндекс, который мы не используем), Git, Ansible и т. д. Обучение подошло к концу, я сдал дипломную работу и получил «корочку» цельного девопс-инженера, до которого, как мне кажется, мне ещё далеко, как до Китая пешком.

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

Переход произошёл — я джун-девопс, цель достигнута! Хотелось бы немного рассказать о онбординге в команду: ребята используют бадди-подход — это когда ты закреплён за более опытным коллегой. Это не значит, что остальная команда стоит в стороне и наблюдает, как ты тонешь. Тут работает принцип кнута и пряника — сделал хорошо — молодец, не сделал — надают в панамку, да так, что следующим твоим желанием будет пойти в слесари/плотники/столяры, но отмечу, что никто никого никогда не бросает и помогает до конца – до тех пор, пока ты не поймешь где ошибся и как это исправить. Также ребята навешивают на нового коллегу работу с внутренними чатами команд, так ты коммуницируешь с коллегами из сторонних отделов, решаешь их проблемы и задачи, погружаясь в специфику. В общем, продолжаем работать и познавать новое.

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

На этой схеме выделены основные команды проекта. 
На этой схеме выделены основные команды проекта. 

Production Support

Инженер продсаппорта это техническая поддержка в L2-L3, самая важная обязанность – это следить за состоянием продакшн-окружения, реагировать на нестандартные ситуации связанные с работой системы в целом, а также реагировать на локальные инциденты

Monitoring

Это глаза нашей инфраструктуры. Основная задача ребят отслеживать изменения в работе инфраструктуры, чтоб предотвратить серьезные инциденты, которые бы парализовали работу системы. Команда использует стандартный набор инструментов: Zabbix, ELK, Graylog и т.д.

DevOPS & Infrastructure

Кратко опишу тем, чем занимаются ребята. Ops — управляют серверами, сетями, обеспечивают стабильность IT-инфраструктуры. DevOps — автоматизируют процессы, объединяют разработку и эксплуатацию для ускорения релизов.

Как мы взаимодействуем друг с другом

Далее я бы хотел немного обрисовать, каким образом происходит взаимодействие между командами на примитивном кейсе. Итак, как это выглядит, поехали! 

  1. Мониторинг видит нестандартное поведение в работе системы, собирает первичную информацию и по флоу направляет инцидент в продсаппорт, либо в отдел инфраструктуры (такие инциденты могут создаваться как оператором мониторинга, так и автоматически)

  2. Далее инженер на линии обрабатывает данный инцидент (SLA на обработку – 5 минут): определяется важность (от незначительной до критической), далее проводится анализ первичной информации, которую предоставили коллеги из мониторинга. Если информации недос��аточно, инженер дополнительно исследует что произошло (проверяет логи, проверяет есть ли влияние на клиентов или внутренних пользователей, анализирует, каким образом инцидент может повлиять на систему в целом)

  3. Допустим, что инцидент как-то связан с девопс. Вся имеющаяся информация направляется на исполнителя, исполнитель исследует имеющееся и решает проблему либо своими силами, либо привлекает коллег из отдела, которые непосредственно имеют отношение к поломке (например, проблема с упавшим приложением)

Дорогой читатель, я надеюсь, ты понимаешь, что данный пример утрирован и схематичен. В целом большое количество проблем решается примерно по такой схеме. Отдельно отмечу, что продсапорт собирает статистику инцидентов, на которые стоит обратить внимание, и проводит встречу, которую мы между собой называем «Инцидентницей». Эта встреча открыта для любого сотрудника и представляет собой некий мозговой штурм. 

Глава 5. Итоги и благодарности

В каждой такой статье (а их на Хабре миллиард) принято делать какие-то выводы. Я не буду оригинален и просто опишу те моменты, которые выстроил для себя:

  1. Общайтесь: больше всего информации вы получите от людей, которые в этом варятся.

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

  3. Учиться не поздно и в 40, но это приятнее делать раньше, когда ты не обременен ничем и никем.

  4. Каждое действие будет вознаграждено: тут стоит понимать, что и положительно, и отрицательно.

  5. Работайте, тут без вариантов — будь то девопс/семья/отношения.

Я не знаю, зачем я написал этот длиннопост. Понимаю, что наловлю шпал от гуру ИТ, но могу сказать, что такой статьи во время своего становления я не нашёл. Может, кому-то пригодится.

Кому спасибо

Ну и не могу не поблагодарить ребят, которые приложили к этому руку: Женя, Илья, Лида, Дима, Асильбек, Саша и конечно же домочадцам, которые поддерживали – спасибо!