⚡️ Бесплатный пилот — путь в никуда

Бесплатный пилот в нашем GovTech — самый надежный способ добровольно похоронить свой ИТ-продукт.

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

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

А дальше начинается океан.

Руководителя, который всё это поддерживал, внезапно переводят в другое ведомство. Приходит новый человек, которому твои наработки абсолютно не интересны. Никто не хочет брать ответственность и подписывать бумаги. Начинаются бесконечные согласования с ГТС, юристами и безопасниками. Все трясутся перед силлвиками, кооорым по идее и своих работ много. В итоге твой продукт ложится в стол, салам алейкум.

Поэтому мы б жестко запретили своей команде вписываться в бесплатные внедрения. Никаких «давайте покажем ценность, а потом нам заплатят».

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

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

В системе, где внедрить что-то новое сложнее, чем найти причину это отменить, бесплатный статус проекта обесценивает его до нуля. Уважают и доводят до конца только те контракты, за которые кто-то несет реальную финансовую ответственность.

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

Недавно попалась на глаза интересная публикация от Elastic, и я поймал себя на мысли, что тема Observability vs Security до сих пор остаётся одной из самых недооценённых слепых зон в архитектуре многих SOC и ИТ-блоков.

Захотелось поделиться своим мнением на этот счёт.

Если очистить термины от маркетинга, обе системы смотрят на одну и ту же инфраструктуру, но из разных сторон:
Observability (ИТ-наблюдаемость) - это врач скорой помощи. Ей важен пульс и давление системы: чтобы ничего не «падало», CPU не грелся, а сервисы откликались быстро.
Задаётся вопросом: «Почему всё тормозит?» - и стремится решить проблему как можно быстрее.
 
Security Monitoring (Мониторинг ИБ) - это детектив. Ему не так важна производительность, ему важен умысел.
Задаётся вопросом: «Кто это сделал и куда утекают данные?», то есть разбирает ситуацию с точки зрения причинно-следственной связи.
 
В чём главный конфликт и где кроются риски?
На практике эти два направления почти всегда разведены по разным платформам и командам. В итоге мы получаем две классические проблемы:
1.Экономическая: компании дважды платят за обработку и хранение одних и тех же данных (Syslog, NetFlow, DNS) в двух разных «корзинах».
2.Операционная (самая опасная): атаки сегодня идеально маскируются под обычный инфраструктурный шум.

Классический кейс из статьи Elastic: ночью у сервера взлетает CPU до 97%. Дежурный инженер IT/DevOps заходит в консоль мониторинга, видит аномальную нагрузку, перезагружает хост и со спокойной душой закрывает тикет со статусом «Resolved».
А что на самом деле? За 6 часов до этого туда задеплоили майнер, замаскированный под системный поток ядра. В итоге ИТ отчиталось об устранении сбоя, Security вообще ничего не узнало, а хакеры спокойно продолжают крутить свои процессы.

Резюмируя, можно сказать следующее:
Observability отвечает на вопрос «Система жива?», а Security - «Систему не взломали?». Пока они живут в разных системах, мы видим только половину картины. Общий контекст - это не просто экономия на хранении логов, это единственная возможность оперативно выявить и заблокировать атаку до того, как она превратится в инцидент.

Ссылка на ту самую статью Elastic: elastic.co/blog