Привет! Меня зовут Алиса, и сейчас я руковожу командой разработки продукта «Штурвал». У нас работает около пятидесяти человек: инженеры, безопасники, девопсы, фронтендеры, бэкендеры на Go и тестировщики, которые ломают всё, что мы строим. Но сегодня я хочу рассказать не о них. Сегодня балом правят аналитики. И ниже на основе личного опыта объясню, почему.
По нашим наблюдениям, рынок труда в 2025–2026 годах (да и раньше) лихорадит от дефицита инженеров со знанием Kubernetes. Данные hh.ru подтверждают, что спрос на DevOps‑инженеров и K8s‑специалистов стабильно рос, а зарплатные вилки пробили космические отметки — по крайней мере, для специалистов того уровня, который подходит под нашу специфику. С сетевиками и безопасниками — та же беда, но даже редких и дорогих их можно встретить в природе чаще.
Особенности работы в разработке мультикластерной платформы
Проблема не в том, что хороших аналитиков мало. Проблема в том, что при работе с Kubernetes есть свои нюансы. Чтобы понять боль, нужно заглянуть под капот нашей платформы.
Это продукт собственной разработки. В его основе — Kubernetes, а вокруг него роится еще с три десятка компонентов: Cilium, Cert-Manager, Velero, Victoria Metrics… Тут тебе и Cluster API, и интеграции со сторонними платформами, LDAP-каталоги, OIDC-провайдеры... а если копнуть глубже, то и всякие Multus с GPU-операторами найдутся. Всё это дружно живет в формате мультикластерной архитектуры, имеет несколько вариантов инсталляции, «зоопарк» поддерживаемых операционных систем, и постоянно обновляется (тоже, конечно, с вариантами). Пользователям хорошо, им удобно. Инсталлировали и работают на всем готовеньком.
Но именно здесь и кроется дьявол. Если инженер или разработчик отвечает за свою конкретную часть, то в голове аналитика всё это обязано сосуществовать одновременно. Причем не просто сосуществовать, а выстраиваться в стройную картину. Нужно в любой момент времени помнить, что, в каком виде и было сделано, скажем, в прошлогодних релизах, и как это скажется на продукте сейчас. Знать, где какие conditions могут быть и что они значат. Уметь объяснить, где какие данные в каком виде хранятся и почему.
Найти специалиста-аналитика с такими компетенциями сложнее, чем найти живого летающего единорога. Вот высокоуровневое сравнение функций среднестатистического аналитика и аналитика в мире контейнеров:
Компетенция | Классический бизнес-системный аналитик | Аналитик мультикластерной контейнерной платформы |
Цель анализа | Выявить потребности бизнеса и перевести их в требования к информационной системе, повышающие ценность продукта | Обеспечить стабильность и развитие платформы: предвидеть проблемы, корректно встроить новый функционал в сложную систему из множества компонентов и быстро помочь команде разобраться в инцидентах |
Основной фокус | Бизнес-процессы, пользовательские сценарии, метрики, ценности | Полный состав компонентов платформы, критические зависимости, особенности настройки, поведение платформы во всех вариантах инсталляции и обновления |
Технический бэкграунд | Понимание принципов работы систем, баз данных, API на уровне «черного ящика» | Уверенная работа с kubectl и Kubernetes API (знать, как формируются YAML-объекты, которые отправляются в кластер), чтение логов подов, анализ conditions, практические навыки установки платформы разными способами, понимание работы сертификатов, firewalls и др. |
Понимание предметной области | Быстрое погружение в разные домены (финансы, логистика, ритейл), изучение процессов конкретного заказчика | Глубокое знание собственной платформы как уникального «домена»: история релизов, совместимость версий компонентов, зоопарк поддерживаемых ОС и варианты инсталляции |
Работа с требованиями | Сбор требований у стейкхолдеров, приоритизация бэклога, user story mapping | Анализ нативного функционала Kubernetes и новых сервисов, проработка концепта внедрения в платформу, постановка задач в разработку (не проектируя API, так как back — обертка над kubectl), сбор обратной связи от заказчиков |
Ключевые артефакты | Vision & Scope, Use Cases, User Stories, BPMN/EPC-диаграммы, прототипы интерфейсов | Описание концепций внедрения новых сервисов, сценариев установки, эксплуатации и обновления, ведение задач в трекере и документации для пользователей и администраторов |
Взаимодействие с командой | Плотная связка с product-менеджером и заказчиком; взаимодействие с разработчиками на этапе уточнения требований | Полное погружение в команду: работает как первая линия поддержки (анализ инцидентов по логам и conditions), ставит задачи, контролирует разработку и сопровождает тестирование, консультирует инженеров |
Типичные вызовы | «Как должен выглядеть процесс оформления заказа, чтобы клиент не уходил?» | «Как изменится работа с ресурсами после обновления компонента? Что нужно поменять в GUI и настройках, чтобы поддержать новую фичу K8s версии Y?» |
Навыки прогнозирования | Предсказывает изменения бизнес-показателей и пользовательского поведения | Регулярно изучает релиз ноутсы входящих компонентов, анализирует будущие изменения, которые потребуются в платформе, и предугадывает потенциальные точки отказа |
Самообучение и поиск информации | Изучение нормативных документов, рынка, методик анализа | Чтение документации, исследовательская работа в платформе (установка, управление ресурсами из консоли, разбор инцидентов) |
Т.е. немножко DevOps, немножко безопасник, чуть-чуть архитектор, ложечка от UI-UX дизайнера… сборная солянка под флагом аналитики.
Первый аналитик на деревне
В аналитике я с 2019 года. Начинала с установки CRM-систем (анализ бизнес-процессов в компаниях), потом поработала пару лет с госами, и после этого меня закрутили лезвия заказной разработки. Слово Kubernetes — да что там, даже Docker — я тогда не слышала даже краем уха. Я планомерно росла в архитектора, пока не попала в эту команду.
В команду «Штурвала» пришла, когда она представляла собой совсем небольшую группу энтузиастов: трое инженеров, фронт, бэк и тестировщик. У платформы только-только появился мажорный релиз, в котором добавили свой сервис аутентификации вместо Keycloak (который весил больше основного состава «Штурвала» втрое). Я была первым и единственным аналитиком. Никаких мануалов «Как анализировать платформу уровня Enterprise» не существовало. Меня позвали описать as is, что за балалайка этот «Штурвал». Мой путь был тернист и напоминал исследование Мории: сначала я просто читала документацию Kubernetes, тыкалась вслепую в первые сырые версии продукта и, как настоящий акын, описывала то, что вижу.
Это было описание из серии: заходите на фронт и видите такие поля вот с таким текстом. А что они делают? Одному богу известно… в смысле, ну вы же девопсы, вам виднее.
Постепенно, погружаясь в процессы всё глубже, через боль и дебри спецификаций, я начала прозревать. Я стала понимать не просто кнопки, а суть: зачем эта платформа нужна, какие реальные задачи она помогает решать заказчикам, в какую сторону её хочет развивать CTO. Я перестала быть «переводчиком заметок CTO на язык разработчиков» и превратилась в соавтора.
Первыми моими заметными зонами ответственности стали построение политики аудита и ролевой модели. Политика превратилась в полноценную песочницу для создания YAML в графическом интерфейсе — подробнее рассказывала об этом на выступлении на конференции «БеКон». А ролевую модель «Штурвала» презентовала на конференции Merge в Иннополисе и частично — на PHDays Fest. Последние два года мы с CTO совместно составляем планы на каждый релиз, потому что находимся в равной вовлеченности по каждой запланированной фиче.
Со временем в моей команде появился новый аналитик. Такой же упорный, неудержимый в тяге к познаниям, готовый разбирать сетевые политики и тонкости Gateway, плакать, но тыкаться не только в GUI, но и в команды в консоли до тех пор, пока они не станут полностью покрыты документацией, а значит — прозрачными и понятными для пользователей.
Инженерная аналитика как новая реальность
Наше направление я бы выделила в отдельную специализацию: «DevOps-аналитика» или «Инженерная аналитика». Это давно не просто сбор обратной связи и пожеланий с заказчиков вроде: «Когда вы добавите поддержку Talos, прикольно же?» или «Хотим хорошо. Плохо не хотим». Здесь нужно уметь предугадать, что у заказчика заболит в будущем, и заранее позаботиться, чтобы эти проблемы не появились.
И скажу вам, что аналитик всё чаще чувствует себя той самой скрепкой-ассистентом из старой версии MS Word:«Похоже, вы пытаетесь поставить четвертый Control Plane-узел. Не желаете ли проверить, как его наличие повлияет на жизнеспособность кластера?».
Мы стали для команды «Google на минималках». И мы делали это задолго до того, как нейросети стали мейнстримом. Пока все вокруг учатся писать промпты, мы продолжаем учиться задавать правильные вопросы самим себе, держа в уме карту из десятков сервисов и пары сотен репозиториев в гите.
Да, идиллия случается не всегда. До сих пор очень часто, вместо того чтобы проводить первичный анализ, инженеры или разработчики уходят в создание Proof of Concept. Это не потому, что не доверяют аналитикам, а потому что такова природа сложных систем: чтобы разобраться, как новый механизм работает, и, главное, как подружить его с остальными составляющими этого кипящего гумбо, нужно пощупать его руками. Но именно в этот момент аналитики приходят и помогают отделить зерна от плевел, превращая хаос PoC в стройную документацию и ТЗ.
Потому что мы разрабатываем не один сервис. Мы разрабатываем охапку сервисов, объединенную в платформу, благодаря которой стабильно работают гиганты российского (и не только) бизнеса. И чтобы пользователи могли получить удобную и безопасную среду, аналитикам приходится быть и картографами, и предсказателями, и немного волшебниками.
Путь Туда и Обратно пройден. Дальше — больше.
***
P.S. Если вам кажется, что аналитик в вашей команде — это тот, кто просто «рисует схемки», приглядитесь. Возможно, прямо сейчас кто-то в одиночку удерживает в голове всю вашу архитектуру, пока остальные самоотверженно копают свои грядки. И чем сложнее платформа, тем ценнее эта роль. Берегите таких «единорогов»!
