Одним из проявлений имперскости является потеря смысла. Поясню на простом примере.

В ИТ-каптиве есть любимый KPI — решать обращения в заданные сроки.
На бумаге всё логично: чем быстрее решаем, тем лучше сервис.
Но жизнь, как известно, не бумага.
Иногда нет оборудования. Иногда нет лицензий. Иногда просто нет свободных рук.
И тогда исполнитель ставит заявку «в ожидание», чтобы время не тикало, пока он ищет способ всё это добыть.

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

И тут начинается самое интересное.
Система радуется: теперь никто не может ставить «ожидание», KPI будет чище, отчёт — ровнее.
А люди начинают делать то, что умеют лучше всего — приспосабливаться.
Закрывают заявку и открывают заново. Меняют формулировки.
На экране — успех, в жизни — тот же хаос, только под гримом.

Имперскость всегда выбирает контроль вместо смысла.
Она верит, что можно улучшить реальность, подправив показатели.
Но реальность упряма — она всегда возвращает долг за фальшь.

Настоящее развитие начинается не с запрета, а с любопытства.
Не с KPI, а с вопроса: почему люди вынуждены ставить «в ожидание»?

Ведь если метрика перестала показывать реальность — это не повод запрещать реальность.

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

Чтобы переломить это, нужно изменить сигналы обратной связи — что считается успехом.

Если карьерный рост зависит от результатов на человека, от производительности без расширения штата, от снижения числа обращений при той же нагрузке, то руководитель начинает искать не новые ставки, а новые решения.

Пример.
Было: руководитель гордится тем, что у него 30 инженеров.
Стало: руководитель гордится тем, что 15 инженеров справляются с тем же объёмом за счёт автоматизации и профилактики.
И это уже повод для повышения, а не для урезания.

Так формируется здоровая отрицательная обратная связь: рост штата перестаёт быть единственным способом показать значимость.
А настоящая карьера строится на умении делать больше — меньшими силами и с большим умом.

Имперскость питается количеством.
Зрелость начинается там, где результат становится важнее масштаба.

Имперскость ИТ-каптива и управляемый конфликт

1. Проблема
Когда у заказчика нет выбора, конфликт направлен наружу.
ИТ-каптив превращается в «империю процессов»:
бизнес жалуется, ИТ оправдывается, энергия уходит на защиту границ.

2. Решение
Создать внутри каптива несколько моделей взаимодействия:

Ресурсная — заказчик управляет людьми и задачами сам.

Сервисная — фокус на SLA и чётких обязательствах.

Партнёрская — совместная работа на бизнес-эффект.

3. Что происходит
Конфликт не исчезает, но перемещается внутрь.
Теперь спорят не бизнес и ИТ, а разные команды внутри каптива —
о подходах, эффективности, удовлетворённости заказчиков.

Вы скажете — дублирование.
Я отвечу — воздух для идей и управленческих решений.
Без параллельных подходов не возникает сравнения,
а без сравнения не рождается развитие.

4. Результат

Между бизнесом и ИТ — доверие и прозрачность.

Внутри каптива — здоровая конкуренция.

Империя превращается в экосистему, где конфликт работает на развитие, а не на оборону.

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

Результаты голосования говорят сами за себя.
Две трети выбрали партнёрскую модель — «мы часть бизнеса».
Лишь 2% готовы быть просто ресурсом.
Это не про форму взаимодействия, а про внутренний запрос на субъектность — право влиять, а не только исполнять.

Когда-то в одной крупной корпорации проводили исследование социального климата под руководством Александра Аузана.
И выяснили: самые низкие показатели удовлетворённости — у ИТ-специалистов.
При том что у основного бизнеса ситуация была заметно лучше.

Причина, по мнению исследователей, в высокой объектности ИТ.
Сотрудники чувствуют себя исполнителями, которые всё время «виноваты» и редко понимают, когда становятся «хорошими» в глазах своей компании.
Не хватает не похвалы — её достаточно, — а осознания результата и влияния на общий успех.

Партнёрская модель — это не просто формат взаимодействия.
Это попытка вернуть ИТ ощущение смысла:
не обслуживать бизнес, а работать вместе с ним, видеть результат, участвовать в создании ценности.

Генри Форд однажды шел по цеху: конвейер работает, а рабочие сидят.
Инженеры возмутились — мол, бездельники.
А Форд сказал: «Я им плачу не за то, что они работают. Я им плачу, чтобы конвейер не вставал.»

Он понимал: ценность не в движении, а в стабильности.

В ИТ мы ценим скорость реакции — кто быстрее чинит, кто закрывает больше заявок.
Но настоящий профессионал — тот, у кого заявок нет вообще.

MTTR — это шаг к зрелости,
а следующий шаг — считать неслучившиеся инциденты:
Неслучившиеся = Прогнозируемые − Фактические.
Где прогнозируемые — это среднее число инцидентов × коэффициент риска изменений.

Если ожидалось 120, а случилось 30 —
значит, 90 не случилось.
И, возможно, именно за эти девяносто стоит оценивать команду.

Что думаете об этой цели — оценивать за тишину, а не за героизм?

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

Мы нашли три инструмента, чтобы искать этот «лучше».

Первый — коммерческая утилизация активов. Мы начали считать не только, сколько стоит, но и сколько живёт. Актив без пользы — как пылесос без розетки: вроде есть, а толку ноль. Конечно, бывают переподписки и простои. Но если простой бьёт по показателям — команда шевелится, ищет, куда этот ресурс пристроить. Так появляется здоровая тревожность.

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

И третий — цели по эффективности. Например, не перекладывать инфляцию в тариф, а перекрывать её ростом производительности. Скромно? Может быть. Но вы посчитайте сложный процент — через пять лет это уже не скромность, а разница между теми, кто живёт на субсидиях, и теми, кто стоит на своих ногах.

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

Из опыта скажу — тарифы ИТ-каптива часто оказываются ниже рынка. Это не потому, что он «не считает деньги». Наоборот — считает, просто по-другому.

Во-первых, норма прибыли.
У каптива она нормирована, единицы процента. Цель не в том, чтобы заработать на корпорации, а чтобы не тратить лишнего. Рынок живёт иначе — двузначные проценты заложены в саму бизнес-модель. Там прибыль — воздух. У нас — побочный продукт.

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

И в-третьих, расходы на эксперименты.
Рынок постоянно проверяет гипотезы: «А пойдёт ли эта новая услуга?», «А нужно ли клиентам это облако?» — и платит за ошибки. Мы инвестируем только в то, что нужно корпорации. Каталог предложений не раздуваем, работаем ближе к сути.

Так что, когда кто-то удивляется, почему у каптива дешевле, ответ простой: не потому что «хуже», а потому что без избыточности. Это, пожалуй, и есть редкий случай, когда экономия не убивает качество, а вытесняет шум.

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

А у венчура — другая паранойя. Он боится упустить “тот самый” проект, который вырастет в единорога. Поэтому покупает всё подряд: стартапы, лицензии, консалтинги, амбиции. Делает десять ставок, зная, что девять сгорят. Платит не за результат, а за надежду.

Две крайности: одна боится лишнего, другая — недополученного.
Одна держит мечту в узде, другая готова сжечь себя в её погоне.

Можно ли совместить их в одной культуре?
Чтобы контроль не убивал мечту,
а мечта не превращалась в имперскость.

Результаты голосования показали: большинство — за мечту.
Но мечта без меры быстро превращается в новую империю.
А если слишком считать — ничего не вырастет.

Значит, теперь вопрос не в выборе стороны,
а в том, как жить между ними.
Как искать новое, не теряя почву под ногами.
Как разрешать противоречия — не лозунгами, а практиками.

Мониторинг — это взгляд в прошлое.
Он отвечает на вопрос: что произошло?
Система собрала метрики, зафиксировала события, выдала алерт.
Мы реагируем, исправляем, двигаемся дальше.

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

Мониторинг говорит: «заметь, что случилось».
Цифровой след — «пойми, почему».
Цифровой двойник — «посмотри, что будет дальше».

И в этом контексте вопрос звучит иначе:
стоит ли инвестировать в импортозамещение старых систем мониторинга —
или логичнее сразу строить новую архитектуру, где цифровой след и двойники станут её естественным ядром?

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

Я верю в три гипотезы:

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

2. Чат-бот поддержки с поиском по базе знаний и переформулированием ответов сократит время реакции.

3. Быстрый поиск релевантной информации ускорит разбор причин инцидентов и повысит точность решений.

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

В какие гипотезы верите вы?

Важная метрика, которая есть не у всех — MTTR (Mean Time To Repair) — среднее время восстановления сервиса. Простая метрика, которая показывает, насколько быстро команда возвращает систему в рабочее состояние.

Пять причин, почему MTTR стоит использовать как целевую метрику:

1. Фокус на реальном результате.
MTTR измеряет не процесс, а факт — сколько времени система была недоступна.

2. Проверка эффективности процессов.
Сокращение MTTR происходит только при реальных изменениях: автоматизации, стандартизации, улучшении диагностики.

3. Связь ИТ и бизнеса.
Время восстановления напрямую влияет на потери и выручку, поэтому метрика понятна обеим сторонам.

4. Выявление узких мест.
MTTR показывает, где тормозит реакция: в мониторинге, коммуникациях или исполнении.

5. Основа для профилактики.
Анализ причин длительных восстановлений помогает устранять источники инцидентов заранее

📍Как построить экосистему телеметрии вместо монолита

Ключевые понятия:

Telemetry — данные о работе систем: метрики, логи, трассы.

Метрики — числовые показатели (нагрузка, задержка, ошибки).

Логи — текстовые события, фиксирующие действия и ошибки.

Трасса (trace) — цепочка операций, показывающая путь запроса через сервисы.

OpenTelemetry (OTel) — открытый стандарт и инструменты для сбора телеметрии.

OTLP (OpenTelemetry Protocol) — протокол передачи метрик, логов и трасс в любые системы.

Collector — шлюз, принимающий телеметрию по OTLP, фильтрующий и пересылающий её.

Lakehouse — архитектура, сочетающая гибкость озера данных и структуру хранилища.

Семплинг (sampling) — сбор только части телеметрии (например, 10% трасс или все ошибки) для снижения объёма.

---

🎯 Цель:
Снизить MTTR и TCO, перейти к мультивендорной модели, где инструменты можно менять без переделки всей системы.

---

⚙️ Принципы:

Инструментировать один раз — использовать во множестве систем.

Collector — единая шина телеметрии.

Lakehouse — дешёвое и масштабируемое хранилище.

Общие атрибуты: service, env, owner, sla.

---

🗓 План на 90 дней:

1–2 недели: запустить Collector, включить OTLP, настроить семплинг.

3–6 недель: подключить 5–10 ключевых сервисов, собрать данные в lakehouse.

7–12 недель: масштабировать, внедрить аналитику MTTR и отчёты.

---

🚀 Быстрые эффекты:

Единый поток телеметрии, меньше агентов.

Поиск по логам, метрикам и трассам из одной точки.

Видимость SLO и MTTR по всем сервисам.

---

⚠️ Риски и ответы:

Рост хранения данных → применяем ретеншн — задаём срок хранения (например, 30 или 90 дней).
Старые данные архивируем или удаляем, чтобы не платить за избыточный объём.

Перегруз метрик → используем rollup — укрупняем данные (секундные значения сворачиваем в минутные или часовые).
Это снижает объём без потери тенденций.

Сопротивление команд → готовим шаблоны включения OTel и минимальные требования к телеметрии.
Цель — «включил и работает».

Мультивендор → храним первичные данные в Lakehouse, чтобы свободно подключать разные инструменты визуализации и аналитики, не завися от одного решения.

Я обещал, что в этом блоге будут идеи. Блог начался с поста о том, как важно превратить идею в веру, хотя бы для самого себя. А для этого мне важно понимать, как это могло бы работать.

Быстрая замена как новый стандарт сервиса

Apple и Samsung давно меряют качество не количеством обращений, а временем, когда пользователь остаётся без устройства.
Это главный KPI сервисного опыта.

Сегодня похожая логика приходит и в корпоративный сегмент.
Например, Velocity Smart реализует модель умных постаматов для замены устройств: сотрудник создаёт заявку, получает код, забирает новое оборудование — всё без участия инженера.

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

Добавляем сюда удалённый сервис — и получается комбинация, которая:

- сокращает время восстановления рабочих мест,

- снижает выезды и затраты,

- заметно повышает удовлетворённость пользователей.

https://www.velocity-smart.com/

Не нашел нормального перевода этого термина, поэтому оставил так. Дословный перевод — Основатель, соответствующий рынку.

Почему Founder-Market Fit решает больше, чем идея

В венчуре есть негласное правило: если у команды сильный Founder-Market Fit, можно простить сырой продукт.
Если его нет — проект, скорее всего, не взлетит, как бы красиво ни выглядел питч.

Founder-Market Fit (FMF) — это степень совпадения личного опыта и компетенций основателя с проблемным полем рынка, на котором он строит продукт.
Проще говоря — когда фаундер глубоко понимает рынок, его игроков и боли клиентов, потому что сам из этого мира.

FMF — это не про интуицию, а про три вещи:

1. Опыт: фаундер жил в этой среде и видел её ограничения изнутри.

2. Доступ: он знает, с кем говорить и кому верить.

3. Мотивация: его движет личная потребность что-то изменить, а не случайная идея.

Примеры:

Бывшие логисты делают сервисы для цепочек поставок — и за месяц находят пилотов.

Врачи создают медтех — и сразу говорят о безопасности, а не о «прорывных алгоритмах».

Инженеры из прома запускают B2B SaaS — и не путают PoC с внедрением.

FMF ускоряет всё:

гипотезы валидируются быстрее,

продажи начинаются раньше,

решения принимаются осознаннее,

пилоты становятся не экспериментом, а шагом к бизнесу.

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

🧭 Кризис и три северные звезды каптива

Итак, пришёл кризис.
Бюджеты режут. В том числе — на ИТ-сервисы.

Можно сделать по-старому:
📉 разослать разнарядку “минус 20% всем”.
Просто. Быстро. Безумно.

А можно — управленчески.
Через три северные звезды каптива 👇


---

СЗ-1. Консолидация платформ
Убираем дубли. Объединяем мощности.
Чем меньше зоопарк технологий — тем ниже TCO и проще поддержка.

СЗ-2. Взвешиваем SLA по приоритетам
Не все сервисы равны.
Для критичных держим уровень, для вспомогательных — снижаем.
Надёжность должна быть по ценности, а не по среднему.

СЗ-3. Снижаем тарифы за счёт эффективности
Не «срезать маржу», а уменьшить себестоимость:
автоматизация, дистанционная поддержка, self-service, FinOps.