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

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

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.

FSM (Field Service Management) — это система управления выездными сервисами: помогает планировать маршруты, контролировать выполнение заявок и повышать эффективность работы полевых специалистов.

🚗 FSM и ИИ: как умное планирование экономит километры
Современные FSM-платформы вроде Microsoft Dynamics 365 Field Service и ServiceNow FSM уже не просто фиксируют выезды — они сами перестраивают маршруты и графики в реальном времени.

📍 Как это работает
Copilot в Dynamics 365 за секунды перераспределяет заявки при отменах или пробках.
Модуль RSO минимизирует пробеги, учитывает навыки и зоны.
ServiceNow FSM предлагает аналогичные функции — AI-powered dynamic scheduling и route optimization прямо в интерфейсе диспетчера.

⚙️ Где FSM-оптимизация даёт эффект
Сотни заявок и широкая география.
Разные навыки и склады.
Частые отмены, простои и трафик.
📉 Гигиена данных решает
ИИ не спасёт, если адреса и длительности заявок устарели — получится «идеальный» маршрут в никуда.

🇷🇺 А что в России? Реальные пилоты FSM уже идут
Вайнах Телеком — телеком-оператор Чеченской Республики.

👉 Автоматизация выездного обслуживания с помощью SNRD FSM, повышение утилизации инженеров и сокращение времени подключений.
🔗 Кейс Вайнах

ICL Services — российский ИТ-провайдер.
👉 Разрабатывает решения с модулем FSM для заказчиков с выездными бригадами.
🔗 Российская сфера ИТ переходит к комплексным решениям

HubEx — отечественная FSM-платформа, обслуживающая более 20 000 объектов в России и СНГ.
👉 Реализует отраслевые FSM-решения для сервиса, логистики и инфраструктуры.
🔗 HubEx — управление выездным сервисом

📊 Вывод
FSM в России уже выходит за стадию экспериментов: появляются зрелые решения, интеграции с логистикой и элементами ИИ-оптимизации.

Продуктовый подход в операторе

Когда говорят «продуктовый подход», часто вспоминают стартап: гипотезы, команда, инвесторы.
В операторской модели, где услуги отлажены и работают по SLA, продуктовый подход нужен для осознанного управления услугами и их экономикой.

1. Почему у продукта должен быть P&L
P&L показывает, из чего складывается результат — какие есть доходы, расходы и маржа.
Без этого продукт остаётся просто статьёй затрат.
Когда владелец продукта видит финансовый результат, он может принимать решения, исходя из реальной эффективности, а не из ощущения загруженности.

2. Роль владельца продукта и ответственность за P&L
Владелец продукта отвечает за экономику услуги — маржинальность, себестоимость, устойчивость.
В каптивной модели продажи ведут внутренние коммерческие подразделения, но ответственность за выручку остаётся у владельца продукта.
Для этого он должен знать своих клиентов, понимать прогнозы потребностей, собирать данные от коммерческих служб, проводить корпоративный маркетинг и анализировать спрос.

3. Кто считает тарифы
Расчёт тарифов — зона ответственности владельца продукта совместно с финансовой службой и экономикой оператора.
Владелец продукта формирует модель себестоимости (ресурсы, лицензии, труд, инфраструктура), прогнозирует объёмы потребления, а финансовая служба проверяет корректность расчётов и формирует общую тарифную матрицу.
Тариф должен отражать реальную стоимость услуги и стимулировать эффективное использование ресурсов.

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

Вывод:
Продуктовый подход в операторе — это управление услугами как самостоятельными экономическими единицами.
Когда у продукта есть клиент, P&L и тариф, появляется прозрачность и возможность принимать решения на основе данных.

Архитектор и владелец продукта: роли и границы ответственности

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

2. Кто отвечает в итоге
Окончательная ответственность — на владельце продукта. Он принимает решения, влияющие на экономику, и несёт последствия этих решений.
Архитектор предоставляет информацию о технических рисках, стоимости изменений и долгосрочных эффектах.

3. Если на хорошую архитектуру нет денег
Архитектор обязан предложить решение, соответствующее возможностям бизнеса: без избыточности, но с соблюдением минимальных требований к надёжности и поддерживаемости.
Экономия не должна создавать скрытый технический долг, который потом будет дороже.

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

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

Мультисервисная площадочная команда

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

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

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

Команда мотивируется сбалансировано — на ИТ-показатели (время реакции, MTTR, качество обслуживания) и на результаты актива, который она поддерживает.
Так достигается связь между эффективностью сервиса и результатом бизнеса.

Если инженеру добавляют обязанности по новому сервису,
допуск к этим работам осуществляется по результатам обучения и проверки квалификации.
Это обеспечивает качество и безопасность выполнения задач.

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

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

А может, и нам стоит оценить эффект от перехода к такой модели в ИТ-сервисе?

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

В «Управлении гневом» Джек Николсон смотрит прямо в глаза и спрашивает:
— Кто ты, Дейв?
И в этот момент понимаешь — не так-то просто ответить, если всё, чем ты себя определял, связано с работой.

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

Когда ты это знаешь — корпорация становится твоей сценой, а не клеткой.

А ты собираешь свою личную идентичность или растворён в корпорации?

В 1917 году датский инженер Агнер Эрланг разработал формулу для расчёта нагрузки на телефонные станции.
Она позволила определить, сколько операторов нужно, чтобы система оставалась устойчивой при любом потоке звонков.

Сегодня этот принцип применим и к IT-сервисам.
Когда поток обращений приближается к максимальной пропускной способности команды, качество обслуживания падает не постепенно, а резко.
При сокращении численности даже на 10–20 % вероятность нарушения SLA растёт нелинейно.

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

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

Догадка — случайность.
Интуиция — закономерность, основанная на опыте.

В управлении это особенно важно: решение часто нужно до анализа.
Интуиция даёт направление, аналитика подтверждает.

Как у Джона Нэша в «Играх разума»:
сначала он видит закономерность,
а потом строит доказательство.

Красная или синяя?

В ИТ-каптиве синяя таблетка — это стабильность, SLA и контроль.
Красная — риск, гипотезы, внешние клиенты и рост.

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

Амбидекстрия — это не компромисс.
Это умение держать обе таблетки в руках:
одной — обеспечивать порядок, другой — строить будущее.

А вы верите, что в ИТ-каптиве можно удержать два независимых контура — и не потерять баланс?

AI-SLA — это соглашение об уровне сервиса для систем, использующих искусственный интеллект.
Оно определяет не только доступность сервиса, но и качество работы модели: точность, актуальность данных, стабильность алгоритма и скорость реакции на деградацию.

AI-SLA вводит метрики предсказуемости и способности системы обрабатывать события без участия человека, сохраняя при этом управляемость и прозрачность решений.

Примеры метрик AI-SLA:
— Accuracy drift — постепенное снижение точности модели со временем.
— Data drift — изменение характеристик входных данных, влияющее на качество предсказаний.
— Retraining interval — периодичность переобучения модели.
— Explainability score — насколько решения модели могут быть объяснены пользователю.
— Human-in-the-loop rate — доля решений, требующих проверки человеком.
— Response integrity — доля корректных ответов без галлюцинаций.

AI-SLA становится обязательным элементом при внедрении корпоративных ИИ-сервисов. Он помогает управлять рисками, связанными с качеством данных и неконтролируемыми изменениями моделей.

Можно ли доверять сервису, который принимает решения, но не может объяснить, почему именно так?

Agile и мультисервисная команда

Agile — как Уотни из «Марсианина».
Он действует в неопределённости, пробует, адаптируется, выживает без инструкций.
Его среда — изменения.
Его сила — гибкость.

А на Земле — команда NASA.
Они не импровизируют. Их работа — точность, устойчивость, расчёт.
Каждый отвечает за свой участок, но вместе они держат систему.

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

Мотивация — сбалансированная:
и на ИТ-показатели (MTTR, SLA, качество обслуживания),
и на результаты актива, который команда поддерживает.

Agile создаёт новое.
Мультисервисная команда обеспечивает устойчивость.
Без первых нет движения вперёд.
Без вторых — шанса дойти.

ИИ — это помощник для тех, кто мыслит,
и замена для тех, кто перестаёт думать.

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

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

Пока мы используем ИИ как инструмент — мы остаёмся авторами.
Когда начинаем ему подыгрывать — превращаемся в зрителей.

Что вы думаете о таком будущем —
где думать становится опцией, а не обязанностью?

Новый купол

Мы хотели удобства —
и получили алгоритмы.

Такси приезжает само,
еда прилетает к окну,
товары находят нас раньше, чем мы их ищем.

Роботы пылесосят, нейросети пишут,
а мы — просто подтверждаем.

Каждый сервис решает проблему,
но вместе они решают нас.

Если мы всё превратим в технологию —
мы построим идеальный мир без ошибок.
И попадём в Шоу Трумана,
где всё работает,
но никто больше не живет.

Что делает с нами само стремление всё превращать в технологию?

Эпоха ×200

Почему ×200?
Потому что раньше разница между хорошим и средним была ×2.
Теперь — ×200.
ИИ не заменяет людей,
он просто увеличивает дистанцию между теми,
кто двигается,
и теми, кто ждёт инструкций.

Главная ошибка — думать, что ИИ это инструмент.
Инструмент можно выключить.
А ИИ — это среда, в которой мы уже живём.
Как воздух.
Он повсюду — в бизнесе, новостях, решениях, даже в бездействии.

Мы продолжаем думать по-старому:
что хаос закончится,
что опыт защитит,
что знания дадут преимущество,
что контроль возможен.
Но эпоха ×200 не вернётся к равновесию —
она и есть равновесие.

Что остаётся?
Держать фокус,
собирать свою экосистему,
делать реальные вещи,
не выгорать.
И главное — иметь волю.

Паровой двигатель усилил волю к движению.
Интернет — к объединению.
ИИ — к созданию.
Если воли нет — технологии просто ускорят пустоту.

Мы уже внутри новой среды.
Она не спрашивает, готов ли ты.
Просто движется дальше.

Ты готов ×200?