Кто я
Привет! Мне 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 — автоматизируют процессы, объединяют разработку и эксплуатацию для ускорения релизов.
Как мы взаимодействуем друг с другом
Далее я бы хотел немного обрисовать, каким образом происходит взаимодействие между командами на примитивном кейсе. Итак, как это выглядит, поехали!
Мониторинг видит нестандартное поведение в работе системы, собирает первичную информацию и по флоу направляет инцидент в продсаппорт, либо в отдел инфраструктуры (такие инциденты могут создаваться как оператором мониторинга, так и автоматически)
Далее инженер на линии обрабатывает данный инцидент (SLA на обработку – 5 минут): определяется важность (от незначительной до критической), далее проводится анализ первичной информации, которую предоставили коллеги из мониторинга. Если информации недостаточно, инженер дополнительно исследует что произошло (проверяет логи, проверяет есть ли влияние на клиентов или внутренних пользователей, анализирует, каким образом инцидент может повлиять на систему в целом)
Допустим, что инцидент как-то связан с девопс. Вся имеющаяся информация направляется на исполнителя, исполнитель исследует имеющееся и решает проблему либо своими силами, либо привлекает коллег из отдела, которые непосредственно имеют отношение к поломке (например, проблема с упавшим приложением)
Дорогой читатель, я надеюсь, ты понимаешь, что данный пример утрирован и схематичен. В целом большое количество проблем решается примерно по такой схеме. Отдельно отмечу, что продсапорт собирает статистику инцидентов, на которые стоит обратить внимание, и проводит встречу, которую мы между собой называем «Инцидентницей». Эта встреча открыта для любого сотрудника и представляет собой некий мозговой штурм.
Глава 5. Итоги и благодарности
В каждой такой статье (а их на Хабре миллиард) принято делать какие-то выводы. Я не буду оригинален и просто опишу те моменты, которые выстроил для себя:
Общайтесь: больше всего информации вы получите от людей, которые в этом варятся.
Не бойтесь спрашивать (для меня это больная тема, потому что много раз становился и становлюсь жертвой своего страха).
Учиться не поздно и в 40, но это приятнее делать раньше, когда ты не обременен ничем и никем.
Каждое действие будет вознаграждено: тут стоит понимать, что и положительно, и отрицательно.
Работайте, тут без вариантов — будь то девопс/семья/отношения.
Я не знаю, зачем я написал этот длиннопост. Понимаю, что наловлю шпал от гуру ИТ, но могу сказать, что такой статьи во время своего становления я не нашёл. Может, кому-то пригодится.
Кому спасибо
Ну и не могу не поблагодарить ребят, которые приложили к этому руку: Женя, Илья, Лида, Дима, Асильбек, Саша и конечно же домочадцам, которые поддерживали – спасибо!