Привет, Хабр! Меня зовут Леша Жиряков, я руковожу бэкенд-направлением витрины KION, возглавляю гильдию по Python и пишу для блога MWS на Хабре. Сегодня на собственном примере покажу, какие задачи может вести CTO в крупной технологической компании, почему его день расписан по минутам, как распределяются ресурсы между командами и что делать, когда важный микросервис вдруг перестает видеть базу данных. Если будут вопросы по теме — пишите в комментариях, постараюсь обо всем подробно рассказать. 

Дисклеймер: как я докатился до такой жизни

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

Почему я ушел в менеджмент? Первая причина — оценка эффективности (Performance Review), которая автоматически привела именно в эту точку. Вторая — я так и не смог ответить себе на вопрос: куда деваются разработчики после 45 лет? Слишком мало их вижу в индустрии. Поэтому на всякий случай решил, что как бы ни нравилось разрабатывать, надо идти в сторону управления командой. А то непонятно, что там происходит после 45! 

Типичная рабочая неделя CTO

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

Для управления задачами я использую методологию GTD (Getting Things Done). Возможно, это совпадение, но именно после ее внедрения у меня заметно выросла эффективность — и карьера тоже пошла в гору. Суть проста: все, что нельзя решить сразу, я фиксирую в системе. Когда появляется 10–15 минут, просматриваю список и закрываю мелкие задачи. Если понимаю, что на решение нужно больше времени, переношу задачу в категорию «Важное» и возвращаюсь к ней позже. Такой подход помогает не держать все в голове и не терять фокус.

Если мне нужно сфокусироваться на задаче на все 100% — например, при планировании квартала или проработке архитектурных решений, я ставлю себе встречу в календаре. Это простой, но действенный способ: во время «встречи с собой» никто не отвлекает, и ты спокойно можешь поработать над сложными вопросами.

Направления работы и квартальное планирование

У меня есть несколько типов задач, но основные — продуктовые и core-задачи. Продуктовые — это все, что напрямую видит пользователь: новые фичи, улучшения витрины, доработки API. В основном они касаются бэкенда витрин, где каждая новая функция влияет на поведение приложения. Core-задачи — это внутренние улучшения. Иногда нужно перейти на более производительное решение, провести рефакторинг или обновить инфраструктуру. Такие задачи не видны пользователю напрямую, но именно они обеспечивают стабильность и скорость продукта.

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

Мы работаем по Agile-подходу с квартальным планированием. Фиксируем задачи, на которые коммитимся, но если что-то по объективным причинам переносится — учитываем это при следующем планировании.

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

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

Основная работа CTO — это как раз постоянное балансирование между планами, людьми и задачами. Нужно уметь смотреть на картину целиком: что команда делает сегодня, что успеем до конца квартала и где могут возникнуть узкие места. 

К моменту финального планирования у меня обычно формируется три ключевых направления работы:

• Бэкенд витрины — все, что отвечает за стабильность и скорость KION: от API до инфраструктуры.

• Продуктовые события — здесь собираем, обрабатываем и передаем все, что делает пользователь в приложении. Эти данные идут аналитикам и продактам, поэтому важно, чтобы события были чистыми и валидными — на них смотрят графики и бизнес-решения.

• Удаленный конфиг — инструмент, который позволяет гибко управлять поведением приложения без перекомпиляции и релизов.

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

Проблемы и способы их решения

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

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

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

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

Рост нагрузки сам по себе был закономерен. Во-первых, в это время шел проект переезда с платформы вендора на собственное решение МТС, что увеличило количество трафика и операций. Во-вторых, с 1 июля 2025 года в продакшене заработала функция heartbeat — механизм, с помощью которого плеер регулярно (примерно раз в 10 секунд) сообщает серверу, на какой секунде воспроизведения находится пользователь. Количество таких событий быстро выросло вместе с аудиторией KION, и в какой-то момент это дало резкий скачок по нагрузке.

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

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

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

Как проходит код-ревью и тестирование

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

У нас действительно сильная и самая лучшая команда. Ребята вовлечены, самостоятельны и всегда держат фокус на результате. Это важно, потому что просто «приходить на работу и закрывать таски» — не про нас.

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

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

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

Мы придерживаемся соглашения Definition of Done: каждое изменение должно быть покрыто тестами, как минимум интеграционными. Если на юнит-тесты не хватает времени, приоритет отдается интеграционным проверкам. В редких случаях, когда тесты по юнитам все же откладываются, за контроль покрытия отвечают OLM-специалисты.

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

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

Общение с командой и другими отделами

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

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

Отдельно про команду

Считаю, с командой мне очень повезло. В каждом из направлений все участники развиваются в T-shaped, ребята и разрабатывают, и выполняют роль системных архитекторов, и пишут тесты в шапочках QA.

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

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

Когда нужно реализовать крупное изменение — например, добавить георезерв или доработать критический сервис, мы начинаем с архитектурного согласования. Рисуем схему, готовим описание и выносим решение на обсуждение с СTO и архитекторами. На встрече разбираем детали: оцениваем плюсы, минусы, возможные риски и влияние на существующую инфраструктуру. Если команда архитекторов одобряет подход, приступаем к реализации.

Наш бэкенд играет ключевую роль в работе KION: он отвечает не только за персональные витрины, но и за определение региона пользователя — например, из России он или нет. От этого зависит, какие именно фильмы будут доступны в плеере. Для корректной работы этой логики поддерживаем обширный набор запросов и тщательно следим за их стабильностью. Именно поэтому мы активно участвуем в архитектурном комитете: такие решения нельзя принимать изолированно. Любое изменение должно быть согласовано и вписано в общую архитектуру платформы — это помогает избежать конфликтов и сохранить целостность системы.

Из регулярных внутренних взаимодействий в МТС у меня есть еще одна роль — техмастера. В этой роли я провожу технические интервью и участвую в исследовательских задачах для других команд. В компании действует единая система найма: кандидатов собеседуют специалисты из разных направлений, исходя из их технологического стека — например, Python или Go, а не только из конкретной команды. Такой подход позволяет объективно оценивать уровень кандидата и ускоряет наем.

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

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

Вот так выглядит моя работа в роли технического лидера направления. А вы умеете делегировать? Какие задачи CTO стали вызовом для вас, а с какими справиться было легче всего? Поделитесь в комментариях.