Для CTO продуктовых команд 10–100 человек
Внешний инженерный руководитель: инфраструктура, релизы, инциденты, наблюдаемость, ручные операции. От двухнедельного аудита до фракционного Head of Infrastructure на 0,25–1 ставку.
Когда меня зовут
Инцидентов больше, релизы дороже, ownership размыт. Ответственные тонут в операционке и тушат пожары вместо развития.
Брать человека в штат рано или дорого, а зона уже требует управленческой руки: приоритеты, стандарты, отчётность бизнесу.
CTO нужно понять, где реальные риски, что чинить первым и во сколько это обойдётся — без внутренней политики и слепых зон.
Симптомы
Мониторинг либо спамит, либо молчит ровно тогда, когда падает прод.
Rollback неочевиден, критичные действия живут в чьей-то голове.
Поддержка тонет в повторяющихся операциях — ошибки и зависимость от людей.
Сервисов больше, документации меньше. Никто не держит картину целиком.
Инженеры знают, что «плохо лежит», но нет понятной приоритизации и оценки.
Cloud-биллы и лицензии увеличиваются без модели стоимости владения.
Опубликованные результаты
Форматы работы
Точная вилка по объёму и стоимости — после вводного созвона: нужно понять контекст, доступы и владельцев систем.
Внешний взгляд на инфру, релизы, инциденты и observability. На выходе — карта рисков, quick wins и план на 30–60 дней.
Берём приоритеты из аудита и доводим до результата: мониторинг, релизы, автоматизация рутин, runbook’и.
Беру часть нагрузки инженерного руководителя: приоритеты, стандарты, найм, отчётность бизнесу — до появления штатного Head of Infra.
Процесс
Контекст, боли, ограничения, ожидания. Если задача не моя — говорю сразу и предлагаю альтернативы.
Короткое письмо: что делаем, в какие сроки, какие артефакты, что нужно от команды, сколько стоит.
Минимальные доступы (часто хватает read-only), знакомство с владельцами сервисов, фиксируем коммуникацию.
Раз в неделю короткий статус: что сделано, что в работе, где блокеры, что меняется в приоритетах.
Артефакты, runbook’и, ownership, открытые вопросы и рекомендации по следующим шагам.
Что остаётся у команды
Сервисы, инструменты, источники сигналов, каналы реакции и владельцы. Где пробелы и риски.
Риски и деградации с вероятностью, влиянием и детектируемостью. Приоритеты и предложенные меры.
Приоритизированный план: quick wins / medium / long, зависимости и рекомендации по ownership.
Что делать при основных алертах: что проверить, какие команды и ссылки, где границы ответственности.
Обо мне
Руководитель инфраструктурного, DevOps/SRE и platform-направления. Работаю в инженерной логике: измеримые метрики, прозрачные артефакты, понятный процесс. Управлял managed services-направлением и командами DBA / Windows / Linux / DevOps, отвечал за production-среды.
Фокус — на стыке инфраструктуры, эксплуатации, поддержки и управленческой отчётности. Помогаю переводить технический долг и инфраструктурные риски на язык метрик, приоритетов и решений.
FAQ
Связаться
Быстрее всего — Telegram. Через форму отвечу в течение рабочего дня и предложу время вводного созвона.