Две компании одновременно Радикальная трансформация редко выглядит как плавный переход из одного состояния в другое. Чаще всего какое-то время организация вынуждена существовать сразу в двух реальностях. Одна часть бизнеса продолжает зарабатывать по старой модели, потому что именно она финансирует компанию сегодня. Другая — только начинает строить новую модель, которая пока требует больше ресурсов, чем приносит доходов. В этот момент возникает парадокс. Старая система ещё слишком ценна, чтобы от неё отказаться, но уже недостаточно перспективна, чтобы на неё делать ставку. Поэтому самые сложные решения во время трансформации связаны не с технологиями и даже не с организационной структурой. Они связаны с необходимостью одновременно поддерживать прошлое и инвестировать в будущее. Со стороны такой период может выглядеть как ухудшение результатов. Но иногда это не признак неудачи, а неизбежная цена смены самой логики бизнеса. Возможно, настоящая трансформация начинается не тогда, когда появляется новая бизнес-модель, а тогда, когда компания соглашается некоторое время жить сразу с двумя. Разбор книги «Радикальное изменение бизнес-модели»: www.youtube.com/...wky
Александр Пономарев | Управленческий дневник
Cilium и eBPF: Как победить «налог на наблюдаемость» и ускорить Cloud Native бизнес В распределённых системах видимость редко бывает бесплатной. Каждый новый уровень наблюдения за системой требует ресурсов — процессорного времени, памяти, сетевого трафика и человеческого внимания. Со временем это превращается в скрытую нагрузку, которая начинает конкурировать с основной работой системы. И тогда возникает парадокс: чем больше мы пытаемся понять систему, тем сильнее мы её замедляем. Классические подходы к мониторингу добавляют дополнительный слой между приложением и инфраструктурой. Этот слой растёт вместе с системой и постепенно становится частью её сложности. Но в современных архитектурах появляется другой способ видеть происходящее — ближе к самой основе исполнения, там, где поведение системы можно наблюдать без промежуточных агентов. Cilium и eBPF смещают границу наблюдаемости внутрь ядра системы, уменьшая необходимость в внешних слоях интерпретации. В этот момент наблюдаемость перестаёт быть отдельной функцией и становится частью самой инфраструктуры. Возможно, зрелость архитектуры определяется не количеством инструментов наблюдения, а тем, насколько мало они мешают работе того, что наблюдают. Подробнее эта идея разбирается в подкасте: www.youtube.com/...qvc
Как ИТ-хаос сжирает вашу прибыль? Разбор бизнес-романа «Проект Феникс» В управлении обычно ищут большие причины потерь. Плохие проекты. Ошибки стратегии. Неверные инвестиции. Но значительная часть потерь возникает в другом месте — в том, что не видно как отдельная проблема. В повседневной работе системы всегда существует слой незапланированной активности. Он не попадает в планы, не учитывается в бюджетах и почти никогда не обсуждается как отдельная категория. Однако именно он определяет, сколько энергии остаётся у организации на развитие. Каждый неожиданный инцидент, каждая срочная правка, каждое переключение внимания разрывает последовательность стратегической работы. И чем больше таких разрывов, тем меньше вероятность, что долгосрочные инициативы будут доведены до результата. Поэтому производительность системы определяется не только тем, сколько работы она делает. Но и тем, сколько незапланированной работы она вынуждена постоянно поглощать. Возможно, главные потери бизнеса происходят не из-за неправильных проектов, а из-за того, что у системы не остаётся времени на правильные. Подробнее эта идея разбирается в подкасте: www.youtube.com/...sro
Архитектор решений: Калькулятор реальности или как ИТ-архитектура спасает (или топит) ваш бизнес? Разбор книги Саурапха и Ниланжайри Шривастава «Solutions Architect» (2025). В сложных организациях редко ломаются технологии. Чаще ломается согласование между тем, как система устроена, и тем, как её представляют. Архитектор решений находится именно в этом разрыве. Он работает не с кодом и не с бизнесом по отдельности, а с ограничениями, которые возникают между ними. Любая система живёт в балансе трёх параметров: стоимость, время и риск. И любое решение — это не улучшение одного из них, а перераспределение напряжения между всеми тремя. Поэтому архитектура почти никогда не про «правильную форму». Она про цену выбора. Когда этот баланс нарушается, система начинает вести себя непредсказуемо. Технически правильные решения могут разрушать экономику продукта. Экономически выгодные — увеличивать операционные риски. Быстрые — создавать долгосрочную хрупкость. Возможно, роль архитектуры заключается не в том, чтобы строить идеальные системы, а в том, чтобы честно фиксировать стоимость каждого компромисса. Подробнее эта идея разбирается в подкасте: www.youtube.com/...jc8
Цена первой реакции О киберинцидентах обычно говорят как о технической проблеме. Но самые тяжёлые последствия нередко возникают не из-за самой атаки, а из-за первых решений после её обнаружения. Когда система перестаёт работать, естественное желание — как можно быстрее всё восстановить. Однако действия, которые кажутся правильными с точки зрения эксплуатации, могут уничтожить информацию, необходимую для расследования, юридической защиты и понимания реальных причин произошедшего. Получается парадокс. Попытка быстрее вернуть систему в рабочее состояние иногда делает ущерб значительно больше, чем сама атака. Поэтому киберинцидент — это не момент, когда ИТ-служба начинает ремонт. Это момент, когда одновременно сталкиваются интересы бизнеса, безопасности, права, репутации и непрерывности процессов. В такие ситуации компания входит с теми правилами, которые были определены заранее. Во время кризиса их уже не создают — ими пользуются. Возможно, зрелость системы безопасности проявляется не в способности остановить каждую атаку, а в способности не усугубить её последствия собственными действиями. Разбор книги «Реагирование на инциденты и компьютерная криминалистика»: www.youtube.com/...s9e
Почему ИИ-подписки заводят разработку в тупик: Конец классического IT-менеджмента Долгое время управление строилось вокруг одного принципа. Кто-то формулирует задачу, кто-то её реализует, кто-то проверяет результат. Эта цепочка выглядела естественной и почти незыблемой. Но в системах с агентной логикой часть этой конструкции начинает исчезать. Исполнение перестаёт быть ручным процессом, требующим постоянного контроля и распределения задач между людьми. Оно уходит в среду, где действия выполняются автоматически, а человек всё меньше участвует в самой реализации. В центре остаётся другой слой — формирование намерения. Не «как сделать», а «что должно быть достигнуто». Это смещение меняет саму природу управления. Контроль исполнения теряет прежнюю ценность, потому что исполнение становится распределённым и частично автономным. В такой системе ключевым становится не управление действиями, а управление смыслом действий. Возможно, граница между управлением и исполнением начинает проходить не по людям и ролям, а по разрыву между намерением и реализацией. Подробнее эта идея разбирается в подкасте: www.youtube.com/...ojm
