Коммерциализация каптива по-венчурному
Когда каптивная ИТ-компания решает выйти на рынок, это не про масштаб, а про гипотезы.
Венчурная логика — маленькими шагами проверять, где есть реальная ценность, а не красивая презентация.
Компания даёт стартовые инвестиции и инфраструктуру.
Авторы проекта вносят личную ставку — идею, время, репутацию.
Если не разделяют риски — в проект не инвестируем.
Без этого автор превращается в рассказчика, а не предпринимателя.
За успех — доля в прибыли или опцион.
Компания получает не только выручку, но и новую управленческую культуру — предпринимательскую.
А на следующем этапе важно выйти за пределы корпорации и привлечь внешнего инвестора.
Если рынок готов вложиться — значит, он верит в идею и готов разделить риски.
Это и есть настоящая проверка зрелости продукта.
Когда каптивная ИТ-компания решает выйти на рынок, это не про масштаб, а про гипотезы.
Венчурная логика — маленькими шагами проверять, где есть реальная ценность, а не красивая презентация.
Компания даёт стартовые инвестиции и инфраструктуру.
Авторы проекта вносят личную ставку — идею, время, репутацию.
Если не разделяют риски — в проект не инвестируем.
Без этого автор превращается в рассказчика, а не предпринимателя.
За успех — доля в прибыли или опцион.
Компания получает не только выручку, но и новую управленческую культуру — предпринимательскую.
А на следующем этапе важно выйти за пределы корпорации и привлечь внешнего инвестора.
Если рынок готов вложиться — значит, он верит в идею и готов разделить риски.
Это и есть настоящая проверка зрелости продукта.
👍10
Так как предыдущий пост про венчурную модель коммерциализации особого интереса не вызвал (а зря — на мой взгляд, это самый рациональный путь), вернемся к каптиву.
Есть две понятные цели, которые помогают развивать каптив внутри корпорации:
— снизить долю теневого ИТ,
— увеличить долю операторских (то есть стандартных и тиражируемых) услуг.
И в том, и в другом случае есть общий риск — рост «имперскости» каптива. Когда центр ИТ-услуг начинает считать, что именно он знает, как должно быть правильно, и превращается не в сервис, а в мини-государство. Об этом — в одном из следующих постов.
А пока — о плюсах.
Снижение доли теневого ИТ
Это не про контроль ради контроля. Это про безопасность, прозрачность и эффективность.
Когда теневое ИТ уменьшается —
— снижается число уязвимостей и инцидентов,
— сокращаются избыточные расходы (ведь двойные лицензии и неучтённые подписки — типичная история),
— выравниваются стандарты качества,
— упрощается поддержка и развитие инфраструктуры,
— появляется единая архитектура, а не «зоопарк решений».
Рост доли операторских (стандартных) услуг
Это про зрелость. Когда компания не изобретает велосипед под каждое подразделение, а строит повторяемую модель.
— снижается себестоимость и упрощается масштабирование,
— появляются понятные SLA и SLO,
— освобождаются ресурсы для развития, а не на ручное тушение пожаров,
— улучшается предсказуемость бюджета и план-факт,
— повышается утилизация инфраструктуры — меньше простаивающих мощностей, больше пользы с каждого сервера, канала и лицензии,
— оператор эффективно перераспределяет ресурсы между потребителями, направляя мощности туда, где они приносят наибольшую пользу бизнесу,
— проще внедрять автоматизацию и ИИ-инструменты.
В итоге каптив перестаёт быть просто «центром затрат» и становится инфраструктурным оператором, который повышает эффективность всей корпорации.
А вот как не скатиться при этом в «империю» — об этом поговорим отдельно.
Есть две понятные цели, которые помогают развивать каптив внутри корпорации:
— снизить долю теневого ИТ,
— увеличить долю операторских (то есть стандартных и тиражируемых) услуг.
И в том, и в другом случае есть общий риск — рост «имперскости» каптива. Когда центр ИТ-услуг начинает считать, что именно он знает, как должно быть правильно, и превращается не в сервис, а в мини-государство. Об этом — в одном из следующих постов.
А пока — о плюсах.
Снижение доли теневого ИТ
Это не про контроль ради контроля. Это про безопасность, прозрачность и эффективность.
Когда теневое ИТ уменьшается —
— снижается число уязвимостей и инцидентов,
— сокращаются избыточные расходы (ведь двойные лицензии и неучтённые подписки — типичная история),
— выравниваются стандарты качества,
— упрощается поддержка и развитие инфраструктуры,
— появляется единая архитектура, а не «зоопарк решений».
Рост доли операторских (стандартных) услуг
Это про зрелость. Когда компания не изобретает велосипед под каждое подразделение, а строит повторяемую модель.
— снижается себестоимость и упрощается масштабирование,
— появляются понятные SLA и SLO,
— освобождаются ресурсы для развития, а не на ручное тушение пожаров,
— улучшается предсказуемость бюджета и план-факт,
— повышается утилизация инфраструктуры — меньше простаивающих мощностей, больше пользы с каждого сервера, канала и лицензии,
— оператор эффективно перераспределяет ресурсы между потребителями, направляя мощности туда, где они приносят наибольшую пользу бизнесу,
— проще внедрять автоматизацию и ИИ-инструменты.
В итоге каптив перестаёт быть просто «центром затрат» и становится инфраструктурным оператором, который повышает эффективность всей корпорации.
А вот как не скатиться при этом в «империю» — об этом поговорим отдельно.
👍16🔥3❤2
❤2
Одним из проявлений имперскости является потеря смысла. Поясню на простом примере.
В ИТ-каптиве есть любимый KPI — решать обращения в заданные сроки.
На бумаге всё логично: чем быстрее решаем, тем лучше сервис.
Но жизнь, как известно, не бумага.
Иногда нет оборудования. Иногда нет лицензий. Иногда просто нет свободных рук.
И тогда исполнитель ставит заявку «в ожидание», чтобы время не тикало, пока он ищет способ всё это добыть.
И вот перед системой встаёт выбор.
Можно разбираться с причинами ожиданий — устранять дефициты, улучшать процессы.
А можно просто запретить ожидания.
Так сказать, ударить по проблеме регламентом.
И тут начинается самое интересное.
Система радуется: теперь никто не может ставить «ожидание», KPI будет чище, отчёт — ровнее.
А люди начинают делать то, что умеют лучше всего — приспосабливаться.
Закрывают заявку и открывают заново. Меняют формулировки.
На экране — успех, в жизни — тот же хаос, только под гримом.
Имперскость всегда выбирает контроль вместо смысла.
Она верит, что можно улучшить реальность, подправив показатели.
Но реальность упряма — она всегда возвращает долг за фальшь.
Настоящее развитие начинается не с запрета, а с любопытства.
Не с KPI, а с вопроса: почему люди вынуждены ставить «в ожидание»?
Ведь если метрика перестала показывать реальность — это не повод запрещать реальность.
В ИТ-каптиве есть любимый KPI — решать обращения в заданные сроки.
На бумаге всё логично: чем быстрее решаем, тем лучше сервис.
Но жизнь, как известно, не бумага.
Иногда нет оборудования. Иногда нет лицензий. Иногда просто нет свободных рук.
И тогда исполнитель ставит заявку «в ожидание», чтобы время не тикало, пока он ищет способ всё это добыть.
И вот перед системой встаёт выбор.
Можно разбираться с причинами ожиданий — устранять дефициты, улучшать процессы.
А можно просто запретить ожидания.
Так сказать, ударить по проблеме регламентом.
И тут начинается самое интересное.
Система радуется: теперь никто не может ставить «ожидание», KPI будет чище, отчёт — ровнее.
А люди начинают делать то, что умеют лучше всего — приспосабливаться.
Закрывают заявку и открывают заново. Меняют формулировки.
На экране — успех, в жизни — тот же хаос, только под гримом.
Имперскость всегда выбирает контроль вместо смысла.
Она верит, что можно улучшить реальность, подправив показатели.
Но реальность упряма — она всегда возвращает долг за фальшь.
Настоящее развитие начинается не с запрета, а с любопытства.
Не с KPI, а с вопроса: почему люди вынуждены ставить «в ожидание»?
Ведь если метрика перестала показывать реальность — это не повод запрещать реальность.
👍14🔥12👏3
В ИТ-каптиве руководители часто меряют свой вес численностью команды.
Больше людей — значит, важнее.
Больше тикетов — значит, нужна структура побольше.
Так рождается имперскость: управленец растёт за счёт разрастания системы, а не за счёт её эффективности.
Чтобы переломить это, нужно изменить сигналы обратной связи — что считается успехом.
Если карьерный рост зависит от результатов на человека, от производительности без расширения штата, от снижения числа обращений при той же нагрузке, то руководитель начинает искать не новые ставки, а новые решения.
Пример.
Было: руководитель гордится тем, что у него 30 инженеров.
Стало: руководитель гордится тем, что 15 инженеров справляются с тем же объёмом за счёт автоматизации и профилактики.
И это уже повод для повышения, а не для урезания.
Так формируется здоровая отрицательная обратная связь: рост штата перестаёт быть единственным способом показать значимость.
А настоящая карьера строится на умении делать больше — меньшими силами и с большим умом.
Имперскость питается количеством.
Зрелость начинается там, где результат становится важнее масштаба.
Больше людей — значит, важнее.
Больше тикетов — значит, нужна структура побольше.
Так рождается имперскость: управленец растёт за счёт разрастания системы, а не за счёт её эффективности.
Чтобы переломить это, нужно изменить сигналы обратной связи — что считается успехом.
Если карьерный рост зависит от результатов на человека, от производительности без расширения штата, от снижения числа обращений при той же нагрузке, то руководитель начинает искать не новые ставки, а новые решения.
Пример.
Было: руководитель гордится тем, что у него 30 инженеров.
Стало: руководитель гордится тем, что 15 инженеров справляются с тем же объёмом за счёт автоматизации и профилактики.
И это уже повод для повышения, а не для урезания.
Так формируется здоровая отрицательная обратная связь: рост штата перестаёт быть единственным способом показать значимость.
А настоящая карьера строится на умении делать больше — меньшими силами и с большим умом.
Имперскость питается количеством.
Зрелость начинается там, где результат становится важнее масштаба.
👍10❤9💯9👌2🔥1
Имперскость ИТ-каптива и управляемый конфликт
1. Проблема
Когда у заказчика нет выбора, конфликт направлен наружу.
ИТ-каптив превращается в «империю процессов»:
бизнес жалуется, ИТ оправдывается, энергия уходит на защиту границ.
2. Решение
Создать внутри каптива несколько моделей взаимодействия:
Ресурсная — заказчик управляет людьми и задачами сам.
Сервисная — фокус на SLA и чётких обязательствах.
Партнёрская — совместная работа на бизнес-эффект.
3. Что происходит
Конфликт не исчезает, но перемещается внутрь.
Теперь спорят не бизнес и ИТ, а разные команды внутри каптива —
о подходах, эффективности, удовлетворённости заказчиков.
Вы скажете — дублирование.
Я отвечу — воздух для идей и управленческих решений.
Без параллельных подходов не возникает сравнения,
а без сравнения не рождается развитие.
4. Результат
Между бизнесом и ИТ — доверие и прозрачность.
Внутри каптива — здоровая конкуренция.
Империя превращается в экосистему, где конфликт работает на развитие, а не на оборону.
Вывод:
Перенос конфликта внутрь — не угроза, а механизм взросления.
Только там, где есть выбор, конкуренция и немного дублирования, появляется воздух — и движение вперёд.
1. Проблема
Когда у заказчика нет выбора, конфликт направлен наружу.
ИТ-каптив превращается в «империю процессов»:
бизнес жалуется, ИТ оправдывается, энергия уходит на защиту границ.
2. Решение
Создать внутри каптива несколько моделей взаимодействия:
Ресурсная — заказчик управляет людьми и задачами сам.
Сервисная — фокус на SLA и чётких обязательствах.
Партнёрская — совместная работа на бизнес-эффект.
3. Что происходит
Конфликт не исчезает, но перемещается внутрь.
Теперь спорят не бизнес и ИТ, а разные команды внутри каптива —
о подходах, эффективности, удовлетворённости заказчиков.
Вы скажете — дублирование.
Я отвечу — воздух для идей и управленческих решений.
Без параллельных подходов не возникает сравнения,
а без сравнения не рождается развитие.
4. Результат
Между бизнесом и ИТ — доверие и прозрачность.
Внутри каптива — здоровая конкуренция.
Империя превращается в экосистему, где конфликт работает на развитие, а не на оборону.
Вывод:
Перенос конфликта внутрь — не угроза, а механизм взросления.
Только там, где есть выбор, конкуренция и немного дублирования, появляется воздух — и движение вперёд.
👍9🤔5
Результаты голосования говорят сами за себя.
Две трети выбрали партнёрскую модель — «мы часть бизнеса».
Лишь 2% готовы быть просто ресурсом.
Это не про форму взаимодействия, а про внутренний запрос на субъектность — право влиять, а не только исполнять.
Когда-то в одной крупной корпорации проводили исследование социального климата под руководством Александра Аузана.
И выяснили: самые низкие показатели удовлетворённости — у ИТ-специалистов.
При том что у основного бизнеса ситуация была заметно лучше.
Причина, по мнению исследователей, в высокой объектности ИТ.
Сотрудники чувствуют себя исполнителями, которые всё время «виноваты» и редко понимают, когда становятся «хорошими» в глазах своей компании.
Не хватает не похвалы — её достаточно, — а осознания результата и влияния на общий успех.
Партнёрская модель — это не просто формат взаимодействия.
Это попытка вернуть ИТ ощущение смысла:
не обслуживать бизнес, а работать вместе с ним, видеть результат, участвовать в создании ценности.
Две трети выбрали партнёрскую модель — «мы часть бизнеса».
Лишь 2% готовы быть просто ресурсом.
Это не про форму взаимодействия, а про внутренний запрос на субъектность — право влиять, а не только исполнять.
Когда-то в одной крупной корпорации проводили исследование социального климата под руководством Александра Аузана.
И выяснили: самые низкие показатели удовлетворённости — у ИТ-специалистов.
При том что у основного бизнеса ситуация была заметно лучше.
Причина, по мнению исследователей, в высокой объектности ИТ.
Сотрудники чувствуют себя исполнителями, которые всё время «виноваты» и редко понимают, когда становятся «хорошими» в глазах своей компании.
Не хватает не похвалы — её достаточно, — а осознания результата и влияния на общий успех.
Партнёрская модель — это не просто формат взаимодействия.
Это попытка вернуть ИТ ощущение смысла:
не обслуживать бизнес, а работать вместе с ним, видеть результат, участвовать в создании ценности.
👍21❤5🔥3🤔2
Генри Форд однажды шел по цеху: конвейер работает, а рабочие сидят.
Инженеры возмутились — мол, бездельники.
А Форд сказал: «Я им плачу не за то, что они работают. Я им плачу, чтобы конвейер не вставал.»
Он понимал: ценность не в движении, а в стабильности.
В ИТ мы ценим скорость реакции — кто быстрее чинит, кто закрывает больше заявок.
Но настоящий профессионал — тот, у кого заявок нет вообще.
MTTR — это шаг к зрелости,
а следующий шаг — считать неслучившиеся инциденты:
Неслучившиеся = Прогнозируемые − Фактические.
Где прогнозируемые — это среднее число инцидентов × коэффициент риска изменений.
Если ожидалось 120, а случилось 30 —
значит, 90 не случилось.
И, возможно, именно за эти девяносто стоит оценивать команду.
Что думаете об этой цели — оценивать за тишину, а не за героизм?
Инженеры возмутились — мол, бездельники.
А Форд сказал: «Я им плачу не за то, что они работают. Я им плачу, чтобы конвейер не вставал.»
Он понимал: ценность не в движении, а в стабильности.
В ИТ мы ценим скорость реакции — кто быстрее чинит, кто закрывает больше заявок.
Но настоящий профессионал — тот, у кого заявок нет вообще.
MTTR — это шаг к зрелости,
а следующий шаг — считать неслучившиеся инциденты:
Неслучившиеся = Прогнозируемые − Фактические.
Где прогнозируемые — это среднее число инцидентов × коэффициент риска изменений.
Если ожидалось 120, а случилось 30 —
значит, 90 не случилось.
И, возможно, именно за эти девяносто стоит оценивать команду.
Что думаете об этой цели — оценивать за тишину, а не за героизм?
🔥19👍13🤔5💯5❤4
Конечно, «открытая книга» — вещь полезная. Клиент видит, из чего складывается стоимость услуги: сервер, лицензия, человек, ещё один человек, кофе. Всё вроде честно. Но дальше возникает старый как мир вопрос — а можно было лучше?
Мы нашли три инструмента, чтобы искать этот «лучше».
Первый — коммерческая утилизация активов. Мы начали считать не только, сколько стоит, но и сколько живёт. Актив без пользы — как пылесос без розетки: вроде есть, а толку ноль. Конечно, бывают переподписки и простои. Но если простой бьёт по показателям — команда шевелится, ищет, куда этот ресурс пристроить. Так появляется здоровая тревожность.
Второй инструмент — сравнение тарифов с рынком. Если наши услуги дороже — спрашиваем, почему. Если дешевле — тоже спрашиваем, почему. Разница — это не повод для драмы, а повод для разговора. А разговор — лучшая форма терапии для системы, которая слишком уверена в своей исключительности.
И третий — цели по эффективности. Например, не перекладывать инфляцию в тариф, а перекрывать её ростом производительности. Скромно? Может быть. Но вы посчитайте сложный процент — через пять лет это уже не скромность, а разница между теми, кто живёт на субсидиях, и теми, кто стоит на своих ногах.
Имперскость любит расти ради роста. Экономика — ради смысла. И это, пожалуй, единственный вид роста, который не стыдно измерять.
Мы нашли три инструмента, чтобы искать этот «лучше».
Первый — коммерческая утилизация активов. Мы начали считать не только, сколько стоит, но и сколько живёт. Актив без пользы — как пылесос без розетки: вроде есть, а толку ноль. Конечно, бывают переподписки и простои. Но если простой бьёт по показателям — команда шевелится, ищет, куда этот ресурс пристроить. Так появляется здоровая тревожность.
Второй инструмент — сравнение тарифов с рынком. Если наши услуги дороже — спрашиваем, почему. Если дешевле — тоже спрашиваем, почему. Разница — это не повод для драмы, а повод для разговора. А разговор — лучшая форма терапии для системы, которая слишком уверена в своей исключительности.
И третий — цели по эффективности. Например, не перекладывать инфляцию в тариф, а перекрывать её ростом производительности. Скромно? Может быть. Но вы посчитайте сложный процент — через пять лет это уже не скромность, а разница между теми, кто живёт на субсидиях, и теми, кто стоит на своих ногах.
Имперскость любит расти ради роста. Экономика — ради смысла. И это, пожалуй, единственный вид роста, который не стыдно измерять.
👍15🔥4🤷♂2❤1🤔1
Из опыта скажу — тарифы ИТ-каптива часто оказываются ниже рынка. Это не потому, что он «не считает деньги». Наоборот — считает, просто по-другому.
Во-первых, норма прибыли.
У каптива она нормирована, единицы процента. Цель не в том, чтобы заработать на корпорации, а чтобы не тратить лишнего. Рынок живёт иначе — двузначные проценты заложены в саму бизнес-модель. Там прибыль — воздух. У нас — побочный продукт.
Во-вторых, утилизация инфраструктуры.
Каптив лучше знает свой спрос. Мы видим план работ, понимаем, что будет запущено через квартал, и не закупаем «впрок». Меньше складов, меньше простаивающего железа. Сбыт предсказуем — это редкая роскошь, которую рынок компенсирует ценой.
И в-третьих, расходы на эксперименты.
Рынок постоянно проверяет гипотезы: «А пойдёт ли эта новая услуга?», «А нужно ли клиентам это облако?» — и платит за ошибки. Мы инвестируем только в то, что нужно корпорации. Каталог предложений не раздуваем, работаем ближе к сути.
Так что, когда кто-то удивляется, почему у каптива дешевле, ответ простой: не потому что «хуже», а потому что без избыточности. Это, пожалуй, и есть редкий случай, когда экономия не убивает качество, а вытесняет шум.
Во-первых, норма прибыли.
У каптива она нормирована, единицы процента. Цель не в том, чтобы заработать на корпорации, а чтобы не тратить лишнего. Рынок живёт иначе — двузначные проценты заложены в саму бизнес-модель. Там прибыль — воздух. У нас — побочный продукт.
Во-вторых, утилизация инфраструктуры.
Каптив лучше знает свой спрос. Мы видим план работ, понимаем, что будет запущено через квартал, и не закупаем «впрок». Меньше складов, меньше простаивающего железа. Сбыт предсказуем — это редкая роскошь, которую рынок компенсирует ценой.
И в-третьих, расходы на эксперименты.
Рынок постоянно проверяет гипотезы: «А пойдёт ли эта новая услуга?», «А нужно ли клиентам это облако?» — и платит за ошибки. Мы инвестируем только в то, что нужно корпорации. Каталог предложений не раздуваем, работаем ближе к сути.
Так что, когда кто-то удивляется, почему у каптива дешевле, ответ простой: не потому что «хуже», а потому что без избыточности. Это, пожалуй, и есть редкий случай, когда экономия не убивает качество, а вытесняет шум.
👍11🔥2👏2
Я много писал про борьбу с имперскостью.
Про то, как каптиву важно не разрастись до размеров собственного мифа — не строить башни, не копить полномочия, не превращать рост в самоцель.
Это паранойя выживания — считать, ограничивать, контролировать.
А у венчура — другая паранойя. Он боится упустить “тот самый” проект, который вырастет в единорога. Поэтому покупает всё подряд: стартапы, лицензии, консалтинги, амбиции. Делает десять ставок, зная, что девять сгорят. Платит не за результат, а за надежду.
Две крайности: одна боится лишнего, другая — недополученного.
Одна держит мечту в узде, другая готова сжечь себя в её погоне.
Можно ли совместить их в одной культуре?
Чтобы контроль не убивал мечту,
а мечта не превращалась в имперскость.
Про то, как каптиву важно не разрастись до размеров собственного мифа — не строить башни, не копить полномочия, не превращать рост в самоцель.
Это паранойя выживания — считать, ограничивать, контролировать.
А у венчура — другая паранойя. Он боится упустить “тот самый” проект, который вырастет в единорога. Поэтому покупает всё подряд: стартапы, лицензии, консалтинги, амбиции. Делает десять ставок, зная, что девять сгорят. Платит не за результат, а за надежду.
Две крайности: одна боится лишнего, другая — недополученного.
Одна держит мечту в узде, другая готова сжечь себя в её погоне.
Можно ли совместить их в одной культуре?
Чтобы контроль не убивал мечту,
а мечта не превращалась в имперскость.
🔥7🤔3❤1
А какой Ваш выбор?
Anonymous Poll
28%
Каптив, так надёжнее
31%
Венчур, я за мечту
41%
Я в сторонке постою, посмотрю кто куда
Результаты голосования показали: большинство — за мечту.
Но мечта без меры быстро превращается в новую империю.
А если слишком считать — ничего не вырастет.
Значит, теперь вопрос не в выборе стороны,
а в том, как жить между ними.
Как искать новое, не теряя почву под ногами.
Как разрешать противоречия — не лозунгами, а практиками.
Но мечта без меры быстро превращается в новую империю.
А если слишком считать — ничего не вырастет.
Значит, теперь вопрос не в выборе стороны,
а в том, как жить между ними.
Как искать новое, не теряя почву под ногами.
Как разрешать противоречия — не лозунгами, а практиками.
💯3🤔1👌1
Мониторинг — это взгляд в прошлое.
Он отвечает на вопрос: что произошло?
Система собрала метрики, зафиксировала события, выдала алерт.
Мы реагируем, исправляем, двигаемся дальше.
Цифровой след и цифровые двойники — следующий шаг.
Цифровой след показывает, как система живёт и меняется во времени, связывая события и причины.
Цифровой двойник добавляет возможность моделировать будущее — проверять сценарии, искать уязвимости, прогнозировать сбои и оптимизировать работу заранее.
Мониторинг говорит: «заметь, что случилось».
Цифровой след — «пойми, почему».
Цифровой двойник — «посмотри, что будет дальше».
И в этом контексте вопрос звучит иначе:
стоит ли инвестировать в импортозамещение старых систем мониторинга —
или логичнее сразу строить новую архитектуру, где цифровой след и двойники станут её естественным ядром?
Он отвечает на вопрос: что произошло?
Система собрала метрики, зафиксировала события, выдала алерт.
Мы реагируем, исправляем, двигаемся дальше.
Цифровой след и цифровые двойники — следующий шаг.
Цифровой след показывает, как система живёт и меняется во времени, связывая события и причины.
Цифровой двойник добавляет возможность моделировать будущее — проверять сценарии, искать уязвимости, прогнозировать сбои и оптимизировать работу заранее.
Мониторинг говорит: «заметь, что случилось».
Цифровой след — «пойми, почему».
Цифровой двойник — «посмотри, что будет дальше».
И в этом контексте вопрос звучит иначе:
стоит ли инвестировать в импортозамещение старых систем мониторинга —
или логичнее сразу строить новую архитектуру, где цифровой след и двойники станут её естественным ядром?
👍6💯4🔥3❤2🤔2👌2
Ключевая метрика цифрового следа в обслуживании инфраструктуры и пользователей — для 90% инцидентов есть данные, которые позволяют установить причину.
Я верю в три гипотезы:
1. Классификация обращений по контексту позволит быстро группировать похожие случаи и видеть повторяющиеся проблемы.
2. Чат-бот поддержки с поиском по базе знаний и переформулированием ответов сократит время реакции.
3. Быстрый поиск релевантной информации ускорит разбор причин инцидентов и повысит точность решений.
Прогнозная аналитика и автоматический поиск причин требуют практики и накопления данных — здесь важно идти через опыт, а не ожидания.
В какие гипотезы верите вы?
Я верю в три гипотезы:
1. Классификация обращений по контексту позволит быстро группировать похожие случаи и видеть повторяющиеся проблемы.
2. Чат-бот поддержки с поиском по базе знаний и переформулированием ответов сократит время реакции.
3. Быстрый поиск релевантной информации ускорит разбор причин инцидентов и повысит точность решений.
Прогнозная аналитика и автоматический поиск причин требуют практики и накопления данных — здесь важно идти через опыт, а не ожидания.
В какие гипотезы верите вы?
🔥4👍3❤2
Важная метрика, которая есть не у всех — MTTR (Mean Time To Repair) — среднее время восстановления сервиса. Простая метрика, которая показывает, насколько быстро команда возвращает систему в рабочее состояние.
Пять причин, почему MTTR стоит использовать как целевую метрику:
1. Фокус на реальном результате.
MTTR измеряет не процесс, а факт — сколько времени система была недоступна.
2. Проверка эффективности процессов.
Сокращение MTTR происходит только при реальных изменениях: автоматизации, стандартизации, улучшении диагностики.
3. Связь ИТ и бизнеса.
Время восстановления напрямую влияет на потери и выручку, поэтому метрика понятна обеим сторонам.
4. Выявление узких мест.
MTTR показывает, где тормозит реакция: в мониторинге, коммуникациях или исполнении.
5. Основа для профилактики.
Анализ причин длительных восстановлений помогает устранять источники инцидентов заранее
Пять причин, почему MTTR стоит использовать как целевую метрику:
1. Фокус на реальном результате.
MTTR измеряет не процесс, а факт — сколько времени система была недоступна.
2. Проверка эффективности процессов.
Сокращение MTTR происходит только при реальных изменениях: автоматизации, стандартизации, улучшении диагностики.
3. Связь ИТ и бизнеса.
Время восстановления напрямую влияет на потери и выручку, поэтому метрика понятна обеим сторонам.
4. Выявление узких мест.
MTTR показывает, где тормозит реакция: в мониторинге, коммуникациях или исполнении.
5. Основа для профилактики.
Анализ причин длительных восстановлений помогает устранять источники инцидентов заранее
👍15❤1
📍Как построить экосистему телеметрии вместо монолита
Ключевые понятия:
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, чтобы свободно подключать разные инструменты визуализации и аналитики, не завися от одного решения.
Ключевые понятия:
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, чтобы свободно подключать разные инструменты визуализации и аналитики, не завися от одного решения.
❤3👍3🤯3🤣3🔥1
Я обещал, что в этом блоге будут идеи. Блог начался с поста о том, как важно превратить идею в веру, хотя бы для самого себя. А для этого мне важно понимать, как это могло бы работать.
👍1
Быстрая замена как новый стандарт сервиса
Apple и Samsung давно меряют качество не количеством обращений, а временем, когда пользователь остаётся без устройства.
Это главный KPI сервисного опыта.
Сегодня похожая логика приходит и в корпоративный сегмент.
Например, Velocity Smart реализует модель умных постаматов для замены устройств: сотрудник создаёт заявку, получает код, забирает новое оборудование — всё без участия инженера.
Некоторые ячейки таких шкафов оснащены питанием и сетью, что позволяет удалённо настраивать, обновлять и тестировать устройства прямо внутри постамата.
Добавляем сюда удалённый сервис — и получается комбинация, которая:
- сокращает время восстановления рабочих мест,
- снижает выезды и затраты,
- заметно повышает удовлетворённость пользователей.
https://www.velocity-smart.com/
Apple и Samsung давно меряют качество не количеством обращений, а временем, когда пользователь остаётся без устройства.
Это главный KPI сервисного опыта.
Сегодня похожая логика приходит и в корпоративный сегмент.
Например, Velocity Smart реализует модель умных постаматов для замены устройств: сотрудник создаёт заявку, получает код, забирает новое оборудование — всё без участия инженера.
Некоторые ячейки таких шкафов оснащены питанием и сетью, что позволяет удалённо настраивать, обновлять и тестировать устройства прямо внутри постамата.
Добавляем сюда удалённый сервис — и получается комбинация, которая:
- сокращает время восстановления рабочих мест,
- снижает выезды и затраты,
- заметно повышает удовлетворённость пользователей.
https://www.velocity-smart.com/
👍9🔥2💯1