Как инженер учится договариваться

Сергей начал строить инфраструктуру ещё в студенческие годы: автоматизировал лабораторные работы, затем пришёл в компанию преподавателя и в 2006 году стал её руководителем. Команда выросла примерно с десяти до двадцати человек, делала систему дистанционного обучения, сайты и автоматизацию бизнеса на Java, поддерживала серверы. Конференции показали ему другую среду: сильных специалистов, более сложные задачи и возможность учиться у коллег. Почувствовав технический и организационный потолок, он переехал в Петербург. Вместо продолжения управленческой карьеры выбрал позицию ведущего инженера в проекте для «Инвитро»: хотелось спокойно перевезти семью и заниматься интересной системой. Но управленческий опыт проявился и здесь — Сергей начал организовывать работу вокруг себя и фактически выполнять роль технического лидера. Возвращение к коду не обнулило умение брать ответственность и доводить общее дело до результата.

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

В 2023 году MTS Web Services предложила Сергею превратить опыт внутренней инфраструктуры в отдельную команду платформы разработки нового облака. Первые полгода он собирал её ядро. Написать базовый код самому было возможно, но масштабирование требовало людей, на которых можно опереться. Затем задача найма вышла за пределы собственного подразделения: Сергей готовил задания, проводил первые интервью, обучал коллег и собирал внутреннее сообщество интервьюеров вместе с рекрутерами. Ориентиром были пять рабочих дней от знакомства с кандидатом до принятого предложения; отдельные случаи удавалось провести за этот срок. Такой процесс тоже стал инфраструктурой, которой пользовались другие команды. При этом техническую платформу не разрабатывали изолированно: её инженеры приходили к продуктовым коллегам, помогали писать управляющие системы и одновременно проверяли на реальной работе, какие общие инструменты нужны. Это позволяло показать пользу платформы через решённую задачу.

Сергей выделяет четыре направления: базовый код для Go, инструменты для управляющих систем на Kotlin, развёртывание сервисов и общий API. Последнее включает договорённости об OpenAPI, генерацию и шлюзы доступа, а не только библиотеки. Лиды продуктовых команд регулярно обсуждают потребности своих команд; отдельно приходится согласовывать решения с владельцами Kubernetes, управления доступом, наблюдаемости и CI/CD. Не все эти команды подчиняются Сергею, поэтому технические компоненты сами по себе не создают общих правил. Чтобы изменения приняли, надо понимать людей и разговаривать с ними заранее. Бизнесу при этом важны сроки и довольные пользователи, а не устройство развёртывания. Инфраструктуре нужны выделенные люди и ответственность, однако её внутренние вопросы часто приходится решать самостоятельно. Скрывать цену компромиссов опасно: когда технический долг увеличивает стоимость каждой новой функции, бизнес продолжает ожидать прежней скорости, потому что ему не объяснили, что изменилось.

Работа с инцидентами показывает, зачем нужна общая ответственность. В облаке есть дежурный руководитель, выполняющий роль duty CTO: он следит, чтобы проблему решали быстро и качественно, а пользователям сообщали о происходящем. Даже правильная работа инженеров не снимает тревогу клиента, если снаружи видна только тишина. Ниже этого уровня продуктовые команды дежурят по своим компонентам; руководители должны распределять знания, чтобы отпуск одного специалиста не останавливал восстановление. Но научить каждого всему слишком дорого. Единая платформа и похожие способы развёртывания уменьшают объём специальных знаний, необходимый для поддержки. После восстановления нужны хронология, причины и конкретные меры против повторения; для важных инцидентов предусмотрена дополнительная проверка разбора. Обещание быть внимательнее такой мерой не является. Александр добавляет: надо возвращаться к задачам из разборов, потому что записанное исправление может месяцами оставаться в планах или быть закрыто без решения исходной проблемы.

С появлением AI-агентов договорённости становятся ещё одним интерфейсом платформы. Документацию в Markdown команда Сергея делает доступной через MCP, а практики написания и развёртывания кода описывает в инструкциях для агентов. Он предлагает создавать точки интеграции и наблюдать, как инженеры применяют новые инструменты. При этом границы данных сохраняются: в компании есть пользовательские данные, которые нельзя передавать наружу. Сам по себе сгенерированный код не заменяет организацию работы; сценарий, где руководитель приносит команде свой результат и требует его поддерживать, собеседники считают неудачным. В финале Сергей предлагает смотреть и на команду как на систему: собирать сведения о работе, понимать потребности соседей и готовиться к разговору с ними. Если внутренним продуктом не пользуются, сначала стоит разобраться в ситуации его потребителей, участниках решений и мотивах. Александр формулирует управленческую задачу так: создать команду, которая сможет создавать продукт, и следить за её состоянием.