Администрирование

Привет, небольшой апдейт. Добавил еще один тип k8s объектов который теперь можно тыкать kui'ем - volumeattachment

Творите, выдумывайте, пробуйте!)

Привет, как узнать % использования PVC? Kui поможет! Добавил команду PVC Usage

PVC это абстракция поэтому прямого пути (команды) узнать использование PVC нет. Как сделано? Ищем стручек (pod) который использует искомый PVC:

pvc_used_in=$(
    kubectl -n $namespace get po -o \
    jsonpath='{range .items[*]}{.metadata.name}{" "}{range .spec.volumes[*]}{.name}{" "}{.persistentVolumeClaim.claimName}{" \n"}{end}{end}' | \
    grep " $pvc_name "
)
raw=($pvc_used_in)
pod_name=${raw[0]}
mnt_name=${raw[1]}

Находим точку g монтирования:

pod_mount_name=$(
    kubectl -n $namespace get po/$pod_name -o \
    jsonpath='{range .spec.containers[*]}{range .volumeMounts[*]}{.name}{" "}{.mountPath}{"\n"}{end}{end}' | \
    awk "/$mnt_name /"'{print $2}'
)

Проверяем использование диска (PVC):

pvc_usage=$(
    kubectl -n $namespace exec po/$pod_name -- df -h $pod_mount_name
)

Выводим результат:

echo "PVC capacity: $pvc_capacity"
echo "PVC used in:"; echo "$pvc_used_in"
echo "PVC usage:"  ; echo "$pvc_usage"
PVC capacity: 750Gi
PVC used in:
kafka-dev-broker-1 data data-kafka-dev-broker-1 
PVC usage:
Filesystem      Size  Used Avail Use% Mounted on
/dev/rbd4       738G   44G  695G   6% /bitnami/kafka

Бонусом добавил возможность прибивать PVCишки kui'ем, добавил команды Delete и Terminate.

Творите, выдумывайте, пробуйте!)

Роли в FinOps

Как бы странно это ни звучало, но главное, на чем держится FinOps, — это общий язык, на котором говорят и финансисты, и технари. При этом у каждого из них есть своя роль:

➖  инженеры и DevOps, которые запускают ресурсы и должны видеть их стоимость

➖  продакты и бизнес-менеджеры, которые отвечают за ценность и окупаемость

➖  финансисты и закупки, которые смотрят на бюджеты и договоры

➖  руководители и C-level, которые принимают стратегические решения

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

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

Близка тема, где финансы и инженеры наконец говорят на одном языке? Заглядываем в «Практики FinOps», там выходят кейсы, доклады, лайфхаки и немного самоиронии про жизнь в облаке.

Как масштабировать ресурсы без увеличения бюджета? Рассказываем на примере истории SaaS-разработчика Ракета

Когда IT-инфраструктура перестает справляться с ростом продукта, это сразу отражается на скорости, стабильности и бизнес-показателях. Команда IT-компании Ракеты столкнулась с тем, что старые выделенные серверы перестали выдерживать нагрузку, а бюджет на масштабирование оставался прежним.

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

Под капотом:

• выделенные серверы на AMD EPYC и Ryzen для телеметрии и автотестов;

• отказоустойчивая конфигурация для стабильной работы без простоев;

• возможность увеличивать мощности без изменения бюджета.

В результате — рост ресурсов примерно на 30% при тех же затратах и стабильная работа внутренних сервисов даже под нагрузкой. Подробнее о решении и технической реализации читайте на сайте Рег.облака.

Эгегей! Радость, kui снова подрос! Добавлена команда 'SSL update' для обновления сертификатов и ключей в секретах типа 'kubernetes.io/tls'. Как это работает?

• Кладете в какую-нибудь папку новый сертификай, файл должен называться tls.crt и ключ с именем tls.key

• Запускаете kui в этой папке, находите секрет с сертификатом который необходимо обновить

• Обновляете через 'SSL update'

Под капотом, обновление выполняется вот такой командой:

printf -v ssl_patch_data '{"data": {"tls.crt": "%s", "tls.key": "%s"}}' "$(base64 -w0 tls.crt)" "$(base64 -w0 tls.key)"
kubectl patch secret/<secret_name> -n <namespace> --patch="$ssl_patch_data"

Творите, выдумывайте, пробуйте!)

Zero Trust: почему мы все делаем это неправильно

За последние три года я и мои знакомые из сферы участвовали во внедрении Zero Trust в 12 компаниях разного масштаба. Пришли к неутешительному выводу: 90% организаций реализуют Zero Trust как более сложную версию VPN. Мы подменяем философию технологиями, забывая о фундаментальных принципах.

Миф об «упрощенной безопасности»

Многие верят, что Zero Trust — это просто замена VPN на ZTNA. На практике мы получаем распределенный VPN с более сложной аутентификацией. Настоящий Zero Trust требует пересмотра архитектуры приложений, а не просто установки шлюза доступа.

Я видел implementations, где:

• Микросервисы общаются через сервис‑меш внутри доверенной сети

• Базы данных остаются в общем сегменте

• Аутентификация сводится к проверке сертификатов

Это не Zero Trust. Это периметровая безопасность с дополнительными факторами аутентификации.

Проблема наследия

Legacy‑системы — главное препятствие для настоящего Zero Trust. Когда 70% бизнес‑логики работает на AS400 и Windows Server 2008, о сегментации на уровне приложений говорить не приходится. Мы создаем костыли: прокси, врапперы, шлюзы — все, что угодно, лишь бы не переписывать системы.

Данные против политик

Самый болезненный момент — управление данными. Zero Trust предполагает, что мы знаем:

• Какие данные где хранятся

• Кто имеет к ним доступ

• Как они перемещаются

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

Излюбленный человеческий фактор 2.0))))

Zero Trust не решает проблему социальной инженерии. Фишинг эволюционировал вместе с технологиями. Я наблюдал случаи, когда злоумышленники:

• Обходили MFA через усталость пользователя (push‑уведомления)

• Использовали легитимные OAuth‑приложения

• Крали сессии с доверенных устройств

Технологические разрывы

Рынок инструментов Zero Trust фрагментирован. Мы имеем:

• 5+ стандартов для device attestation

• 3 конкурирующих протокола для ZTNA

• Десятки несовместимых решений для микросегментации

Интеграция превращается в кошмар: Palo Alto Prisma, CrowdStrike Identity, Cisco Duo — каждый тянет одеяло на себя.

Культурный шок

Самое сложное в Zero Trust — изменить мышление команды. Админы привыкли к «доверенным сетям». Разработчики не хотят переписывать auth‑логику. Руководство требует быстрых результатов.

Я видел проекты, где после года внедрения:

• Сотрудники использовали корпоративные устройства для личных нужд

• Админы создавали бэкдоры для «удобства поддержки»

• Руководители требовали исключений из политик

Что в сухом остатке?

Zero Trust — это не продукт и не проект. Это бесконечный процесс переосмысления безопасности. Успешные implementations, которые я наблюдал, имели общие черты:

• Поэтапный переход (3-5 лет)

• Глубокая модернизация инфраструктуры

• Изменение процессов, а не только технологий

• Постоянное обучение и тестирование

Мы должны признать: не каждой компании нужен «полный» Zero Trust. Иногда достаточно микросегментации критических активов и строгого контроля доступа. Гонка за модным термином не должна подменять собой здравый смысл.

Сегодня я скорее рекомендую «Zero Trust mindset», чем конкретные технологии. Начинать стоит с инвентаризации активов, классификации данных и построения карты потоков. Технологии — вторичны.

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

Дайджест Рег.облака за сентябрь

Осень началась с крупных новостей — мы выпустили ИИ-ассистента, открыли новую московскую локацию и прокачали S3-хранилище. Всё это делает работу в Рег.облаке еще удобнее, безопаснее и мощнее.

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

• Открыли новую локацию — Москва-2
  Добавили новый регион для заказа серверов в дата-центре «Медведково-2», сертифицированном по Tier III Facility. Здесь появилась линейка тарифов «Стандартные+» с дисковой подсистемой на NVMe SSD — она работает в 5–10 раз быстрее классических «Стандартных». Протестировать и заказать облачные серверы в новой локации можно на сайте Рег.облака.

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

• Рассказали, как построить отказоустойчивую систему для ритейла в облаке
  На примере кейса мебельного ритейлера «169» показали, как полномасштабная миграция в облако помогла повысить производительность СУБД, а затраты на администрирование IT-инфраструктуры сократились на 30% за счет автоматизации и Pay-as-you-go-модели.

• Провели вебинар и запланировали еще один
  В конце сентября прошел вебинар по ФЗ-152, а уже 14 октября мы встретимся на следующем — про 1С:УНФ и автоматизацию малого бизнеса.

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

Управлять облачными расходами часто сложнее, чем кажется

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

Чтобы помочь компаниям системнее подойти к FinOps, мы собрали FinOps Community Bot. Это Telegram-бот, который объединяет несколько инструментов:

• Тест по FinOps. 9 вопросов за 5–7 минут. Бот рассчитает уровень зрелости вашей компании в управлении облачными затратами и подскажет следующие шаги.

• База знаний. Подборка статей, инструкций и практических материалов по FinOps.

• Календарь событий. Митапы, вебинары и конференции для специалистов и руководителей.

• Закрытый чат. Возможность обсудить опыт с коллегами и задать вопросы сообществу.

Бот полезен для любых ролей: CEO увидит картину в целом, CFO получит идеи по оптимизации расходов, DevOps-инженеры и CTO — практические шаги для улучшения процессов.

Начать просто: пройдите тест, получите рекомендации и используйте остальные функции бота для глубокого погружения и обмена опытом.

👉 Попробовать

В репозитории Awesome First Pull Request Opportunities больше сотни проектов, в которые новички могут делать пул-реквесты и получать обратную связь и даже советы по изучению программирования. Все проекты разделены по языкам и темам: C#, C++, Java, JS, фронтенд, бэкенд, информбезопасность, мобильная разработка под iOS и Android. Каждый найдет проект и стек. Проекты и репозитории ведут реальные разработчики и постоянно их поддерживают. Каждая команда всегда читает пул-реквесты, часто дает советы по разработке и обучению, обратную связь новичкам и даже шанс попасть на стажировку.

Собственный VDI и протокол: подробности

Привет, Хабр! Мы расширяем портфель решений — теперь в нашей экосистеме есть новая функциональность виртуализации рабочих столов и приложений (VDI) в рамках интеграции продуктов zVirt и Termit. Благодаря ей заказчики могут прямо в пользовательском интерфейсе Termit настроить автоматическое создание групп виртуальных рабочих мест из шаблона. 

Это стало возможно благодаря глубокой интеграции с системой виртуализации zVirt. В интерфейсе Termit можно настроить сопряжение с zVirt, там же создать группу виртуальных рабочих мест, и в нее автоматически будут добавляться виртуальные машины, создаваемые в zVirt по заданному шаблону — “золотому образу”. Они также автоматически будут вводиться в домен. На стороне виртуализации нужно только настроить “золотой образ”, все остальные операции можно совершать в интерфейсе Termit.

VDI в наших продуктах обеспечивает возможность создания как сессионных, так и персонализированных виртуальных машин, а также поддерживает кроссплатформенность, многофакторную аутентификацию и SSO, протоколы X2Go, RDP и Loudplay, перенаправление устройств, различные ОС: Windows, Astra Linux, РЕД ОС, ОС Альт. Функциональность представлена как отдельно в рамках продукта Termit, так и в новом модуле платформы виртуализации zVirt Apps and Desktops.

Среди других обновлений релиза Termit 2.4 — улучшение пользовательского опыта и усиление безопасности. В частности, появилась возможность настройки перемещаемых профилей для Linux. Теперь, когда пользователь отключается от рабочего стола, все его актуальные настройки и изменения остаются в удаленном хранилище и при следующем подключении перемещаются за пользователем на новый сервер или виртуальную машину. Это позволяет сохранять единое рабочее окружение для сотрудников и снижает количество обращений в техподдержку.  

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

Кроме того, мы начали разработку собственного протокола доставки удаленного рабочего стола и терминального доступа. Он будет реализован внутренними силами и без использования Open Source.

Мы изучили существующие на рынке разработки и патенты, наняли сильных специалистов и в этом году начали разработку собственного протокола. Мы пишем его сами, не используем ни X2Go, ни SPICE, ни FreeRDP. Это в первую очередь UDP, но одновременно будет реализована и поддержка TCP. В протоколе “из коробки” будет поддержка виртуальных каналов и мультисессионности.

Репозиторий с тысячами приложений, которые можно захостить на своем сервере. Больше 50 категорий приложений, внутри которых сотни инструментов под различные задачи. Есть всё для аналитики, бронирования ресторанов и отелей, автоматизации рутины, чтения книг и журналов. Можно использовать файлообменники, парсеры, приложения для мониторинга и многое другое. Каждая программа работает только локально.

Бессерверные вычисления: почему ваш код может стать заложником провайдера

Бессерверная архитектура обещает не думать об инфраструктуре, но скрывает риски vendor lock-in, которые проявятся слишком поздно. Пока вы наслаждаетесь отсутствием серверов, ваша бизнес-логика медленно превращается в заложника облачного провайдера.

Проблема:

• Cold start в критичных приложениях достигает 10-15 секунд

• Стоимость непредсказуема при скачках нагрузки

• Локальная разработка и отладка превращаются в квест

Реальные кейсы:

python

# Проблема: разрыв между продакшеном и локальной средой
def lambda_handler(event, context):
    # На локальной машине работает
    # В AWS Lambda падает с таймаутом
    return expensive_operation()  # 25+ секунд

Что мониторим в бессерверной среде:

1. Performance

   • Холодные/горячие старты

   • Потребление памяти

   • Execution duration

2. Безопасность

   • Права IAM-ролей

   • Доступ к секретам

   • Цепочки вызовов функций

3. Экономика

   • Стоимость вызова

   • Количество параллельных исполнений

   • Использование сторонних сервисов

Когда бессервер оправдан:

• Обработка событий с неравномерной нагрузкой

• Фоновые задачи (генерация отчетов, ночные джобы)

• API с низким RPS

Альтернативы:

• Kubernetes + Knative — гибридный подход

• Cloudflare Workers — edge-вычисления

• Self-hosted FaaS — полный контроль

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

ITAMday 2025: играем и выигрываем с «Инферит ИТМен»

Привет, Хабр! 👋
Меня зовут Данила Трусов, я директор продукта «Инферит ИТМен».

31 октября в Москве пройдет юбилейная X конференция ITAMday 2025 — ключевое событие для специалистов по управлению ИТ-активами. Ежегодно она собирает сотни практиков и экспертов, чтобы обсудить лучшие кейсы, обменяться опытом и взглянуть в будущее индустрии.

В этом году я выступлю с докладом «Агрегация — это еще не все: почему рынку требуется отдельный класс инструментов дискаверинга с гибкой настройкой под любую инфраструктуру в 2025–2028 годах».

Мы разберем:

• почему российские вендоры и аналитики делают ставку именно на дискаверинг, а не на простую агрегацию;

• зачем отдельный класс решений по дискаверингу необходим для ITSM/ ITAM/ SAM;

• какие подходы позволяют добиться 100% прозрачности и безопасности инфраструктуры;

• на что обратить внимание при выборе и настройке решений enterprise-уровня;

• как сохранить мультивендорность при контроле ИТ-ландшафта.

А еще мы подготовили для участников активность от «Инферит ИТМен» — динамичный онлайн-квиз. Проверите знания, получите драйв и сможете выиграть крутые призы:

🎁 Главный приз — ноутбук бизнес-класса INFERIT Mercury 15.6" i5-1334U
🥈 Подарки за второе и третье место
📸 Отдельный приз победителю фотоконкурса

ITAMday — это не только про доклады и нетворкинг, но и про живые впечатления. Будет азартно, полезно и кто-то уйдет домой с ноутбуком под мышкой 😉

📅 Когда: 31 октября 2025
📍 Где: Radisson Blu Олимпийский, Москва

Жду вас на ITAMday 2025 — на своем докладе и в квизе от «Инферит ИТМен»!

Контейнеры не панацея: скрытые затраты на содержание Kubernetes, о которых молчат вендоры

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

Что не учитывают при внедрении:

• Эффективность нод: В среднем 35-40% ресурсов простаивают "на всякий случай"

• Стоимость сетей: Service mesh + CNI добавляют 15-20% к потреблению CPU

• Трудозатраты: 1 инженер на 3-5 кластеров — утопия для средних компаний

Реальные метрики из практики:

bash

# Анализ утилизации за 3 месяца
kubectl top nodes | awk '{sum += $3} END {print "Средняя загрузка:", sum/NR "%"}'
# Результат: 41% по CPU, 28% по памяти

Где теряем деньги:

1. Overprovisioning
   "На всякий случай" развертываем на 200% больше ресурсов

2. Сложность мониторинга
   Требуется отдельный стек: Prometheus + Grafana + Alertmanager

3. Безопасность
   Pod Security Policies, network policies — +20% к времени развертывания

Когда Kubernetes оправдан:

• 50+ микросервисов

• Непредсказуемая нагрузка

• Команда из 3+ DevOps инженеров

Альтернативы для средних проектов:

• Nomad — проще оркестратор без привязки к контейнерам

• Docker Swarm — для простых сценариев

• Managed k8s — если нет своей экспертизы

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

#Kubernetes #DevOps #контейнеризация #TCO #микросервисы

А как у вас с реальной утилизацией ресурсов в k8s? Делитесь наблюдениями в комментариях.

Записки параноика: почему Zero Trust — это не мода, а новая реальность для ИТ-инфраструктуры

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

Почему Zero Trust — это не просто buzzword:

• 68% компаний сталкивались с инцидентами внутренних угроз

• Среднее время обнаружения нарушителя в сети — 207 дней

• Традиционные VPN стали главным вектором атак в 2024

Как мы внедряли Zero Trust без переписывания всей инфраструктуры:

Сегментация на микроуровне:

yaml

# Instead of: Allow 10.0.0.0/8
# We use: 
- name: db-access
  source: app-server-01
  destination: postgres-01
  port: 5432
  auth: mTLS + service-account

Service Mesh вместо VPN:

• Istio для взаимной аутентификации сервисов

• Автоматическое шифрование всего трафика

• Детальный контроль доступа на уровне L7
  
  Непрерывная верификация:

bash

# Проверка целостности хостов каждые 30 сек
sudo attestation-agent verify --policy strict

Технические вызовы, с которыми столкнулись:

• Производительность: Overhead Istio ~3ms на hop

• Сложность отладки: Трассировка запросов через 5+ сервисов

• Миграция: Постепенный перенос legacy-систем

Метрики после 6 месяцев работы:

• Время сдерживания атаки сократилось с часов до минут

• Количество инцидентов снизилось на 73%

• Audit trail для compliance стал детализированным

Ключевые инсайты:

1. Начинайте с идентификации — без точной инвентаризации сервисов ничего не выйдет

2. Поэтапное внедрение — от критичных workload к периферии

3. Автоматизация политик — ручное управление не масштабируется

Zero Trust — это не продукт, а архитектурный принцип. И да, он требует изменений в менталитете команды больше, чем в технологиях.

Post-Quantum Cryptography: тихая революция в инфраструктуре, которую нельзя игнорировать

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

Проблема:

Современные алгоритмы (RSA, ECC) могут быть взломаны квантовыми компьютерами в обозримом будущем. Миграция на PQC — не вопрос «если», а вопрос «когда».

Что меняется:

• Размер ключей увеличивается в 5-10 раз

• Процессоры испытывают нагрузку на 30-50% выше

• TLS-хендшейки становятся значительно объемнее

Наши тесты с OpenSSH 9.8:

bash

# Стандартный ключ Ed25519: 68 байт
# PQC-ключ Dilithium3: 1842 байта
# Рост трафика при подключении: ~2700%

Практические рекомендации:

1. Аудит инфраструктуры:

python

# Скрипт для поиска уязвимых сервисов
import ssl
for protocol in ['TLSv1.2', 'TLSv1.3']:
    ctx = ssl.create_default_context()
    ctx.set_ciphers(protocol)

2. План миграции:

• 2025: Тестирование гибридных схем (PQC + традиционные алгоритмы)

• 2026: Перевод внутренних сервисов

• 2027: Полный переход для внешних endpoint

3. Аппаратные требования:

• CPU с поддержкой AVX2/AVX-512

• Увеличение буферов сетевых карт

• +30% к оперативной памяти для сертификатов

Метрики производительности после перехода:

• 📉 Throughput VPN: снижение на 15%

• 📈 Потребление CPU: рост на 40%

• ⏱️ Время TLS-хендшейка: +80 мс

Вывод:

Откладывание перехода на PQC аналогично игнорированию проблемы Y2K в 90-х. Уже сегодня нужно начинать тестирование и планирование, чтобы избежать хаотичной миграции под давлением регуляторов.

Уже проводили тесты с постквантовыми алгоритмами? Делитесь результатами в комментариях — соберем статистику по разным конфигурациям.

Привет, потенциал kui еще немного увеличился! Случилось то что случилось, в продской cronjoпеb'е что-то застряло. Добавил в kui ручной запуск кронжоб и kui'ем протолкнул застрявшее в кронжобе ...

Творите, выдумывайте, пробуйте!)

Когда TLS 1.3 ломает мониторинг: тонкая настройка под новые протоколы

С переходом на TLS 1.3 многие системы мониторинга внезапно "ослепли". Старые методы перехвата трафика перестали работать, а бизнес требует полной видимости. Разбираем, как адаптировать мониторинг под современные стандарты безопасности.

Проблема:

• eSNI и Encrypted Client Hello шифруют метаданные подключения

• PFS (Perfect Forward Secrecy) делает историческую расшифровку трафика невозможной

• 70% инструментов мониторинга показывают "encrypted traffic" вместо полезных метрик

Решение через eBPF:

bash

# Вместо SSL-инспекции - анализ системных вызовов
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_connect {
    printf("%s → %s:%d\n", comm, args->uservaddr, args->port);
}'

Наша реализация:

1. Мониторинг на уровне ядра - eBPF-программы для анализа сокетов

2. Анализ временных метрик - latency между SYN и ACK без расшифровки содержимого

3. Косвенные метрики - количество новых соединений, размер передаваемых данных

Конфигурация для Prometheus:

yaml

- job_name: 'ebpf_metrics'
  static_configs:
    - targets: ['node-exporter:9100']
  metrics_path: /ebpf
  params:
    module: [tcp_tracer]

Результаты:

• Обнаружили 40% неоптимальных TLS-хендшейков

• Снизили время диагностики проблем с подключением с 25 до 3 минут

• Соответствуем требованиям GDPR и PCI DSS (без декриптации трафика)

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

#eBPF #TLS1.3 #мониторинг #кибербезопасность #observability

Какие подходы к мониторингу зашифрованного трафика используете вы? 

Grafana: когда красивые графики становятся рабочим инструментом

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

Проблема типового подхода:

• Собираем все метрики подряд — «на всякий случай»

• Создаём дашборды с 20+ графиками, где невозможно найти нужную информацию

• Система есть, а пользы нет

Как мы построили эффективный мониторинг:

1. Инфраструктура сбора данных

text

Prometheus → Grafana (визуализация)
Loki → Grafana (логи)
Alertmanager → Grafana (алерты)

Один стек — единая картина происходящего.

2. Три уровня дашбордов:

• Оперативный (NOC): 3-5 ключевых метрик — доступность, ошибки, нагрузка

• Тактический (инженеры): детализация по сервисам + связанные логи

• Стратегический (руководство): SLA, бизнес-метрики, тренды

3. Пример полезного дашборда для веб-сервиса:

sql

- HTTP-коды ответов (1xx, 2xx, 3xx, 4xx, 5xx) 
- Latency: p50, p95, p99
- Rate of errors (> 5%)
- SLO: доступность за последний час

4. Интеграция логов и трейсов:
Теперь не просто видим, что latency вырос, а сразу находим причину в логах конкретного микросервиса.

Реальные результаты:

• Время диагностики инцидентов сократилось с 40 до 8 минут

• Количество ложных алертов уменьшили в 5 раз

• Единая система вместо 3 разных инструментов мониторинга

Ошибки, которых стоит избегать:

1. Не создавайте дашборды «для галочки»

2. Настройте meaningful алерты, а не «disk usage > 90%»

3. Используйте единый стек данных (метрики + логи + трейсы)

Вывод:
Grafana — это не про красивые графики, а про единое информационное пространство для принятия решений. Когда каждый инженер видит одну и ту же картину — проблемы решаются в разы быстрее.

А какие подходы к мониторингу используете вы? Делитесь кейсами в комментариях!

#grafana #мониторинг #prometheus #loki #devops #sre

Когда мониторинг слепнет: почему 90% алертов — это ложные срабатывания и как с этим жить

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

Проблема ложных срабатываний

• 📊 15% нагрузки на Zabbix/Prometheus — сбор и обработка бесполезных метрик

• ⏰ До 3 часов в день senior-инженеры тратят на фильтрацию алертов

• 🔕 68% инженеров признаются, что пропускали важные уведомления из-за "алертной усталости"

Почему это происходит

1. Мониторим всё подряд — собираем метрики "на всякий случай"

2. Неправильные пороги — одинаковые thresholds для dev и prod

3. Отсутствие бизнес-логики — система не понимает контекст сбоя

Решение: умный мониторинг

# Вместо этого:
alert: CPU > 90%

# Мониторим так:
alert: 
  condition: CPU > 90% 
  and LoadAverage > 5
  and duration > 5m
  and business_impact = true

Что внедрили у себя

1. Сезонные пороги — разные thresholds в рабочее/нерабочее время

2. Корреляцию событий — не алертим о высокой нагрузке, если это время бэкапов

3. Бизнес-метрики — мониторим не "доступность сервера", а "доступность оплаты"

Результаты через 3 месяца

• ✅ Снизили количество алертов в 7 раз

• ✅ 98% срабатываний требуют реакции

• ✅ Время реакции на реальные инциденты сократилось с 25 до 8 минут

Вывод
Мониторинг должен говорить, когда бизнес теряет деньги, а не когда у сервера чихнул процессор. Лучше 10 точных алертов, чем 1000 мусорных.

А как у вас с алертами? Тоже тонете в ложных срабатываниях?

#мониторинг #zabbix #prometheus #алерты #devops #sysadmin

P.S. В комментах жду ваши кейсы борьбы с алертной усталостью — соберем лучшие практики!