Системное администрирование *

Наше хранилище S3 недавно попало в топ-5 по функциональности и в топ-3 по поддерживаемым протоколам в рейтинге Cnews среди облачных провайдеров. В общем рейтинге мы на 7-м месте.

Хороший повод рассказать про S3 подробнее.

Хранилище работает на базе Ceph — распределенной системы хранения данных с открытым исходным кодом. Она дает вам полный контроль над данными и позволяет кратно масштабироваться.

Конкретнее о преимуществах:

1️⃣ Тройная репликация — данные хранятся в три копии на разных серверах, чтобы даже в случае отказа одного из них ваши данные были в полной безопасности.

2️⃣ Высокая производительность — для быстрого доступа мы используем горячие пулы на NVMe и холодные пулы на HDD для тех данных, которые вы не будете часто запрашивать.

3️⃣ Управление через стандартный S3 API — чтобы интегрироваться в любые системы, поддерживающие S3, мы используем интерфейс RADOS Gateway (RGW), который транслирует запросы на S3 в язык Ceph и управляет ими через API.

Кстати, спойлер: скоро планируем запускать S3 в Москве.

Начать пользоваться можно даже за 1 рубль на минималке в холодном хранилище. Пора тестить →

На площадке Networking Toolbox (GitHub) доступны более 100 сетевых инструментов для системных администраторов и сетевых специалистов, включая решения для проверки DNS, TLS, DHCP, HTTP и почтовых серверов, для конвертирования CIDR, масок, IPv4/IPv6, MAC-адресов, калькуляторы подсетей, генераторы конфигов, утилиты для тестирования производительности, шифрования и маршрутизации, а также справочники по основам сетей IPv6 и сетевым протоколам.

Ранее на Хабре был пост: "20 инструментов кибербезопасности 2025 года для пентестинга, сканирования IP-сетей, анализа трафика".

Эта миссия теперь выполнима — импортируем данные из PostgreSQL 💼

Из панели можно запустить автономный импорт данных из любой базы PostgreSQL (как с внешней, так и из нашего облака).

Как переносить: перейти в нужную базу → кнопка ☝️ → ввести креды от базы-источника и выбрать владельца новой базы → done.

👉 Автоматически можно импортировать структуру таблиц, индексы и данные. А пользователей, роли и расширения нужно добавлять уже вручную.

Рубрика вопросы:

1️⃣ Я могу перенести данные между разными версиями PostgreSQL?

➖ Да, но не получится перенести специфичные типы данных.

2️⃣ А могу выбрать уже существующую базу для импорта?

➖ Нет, новая база создается автоматически. Если в панели уже есть база с таким именем, то система выдаст ошибку.

Импортировать базу в пару кликов →

Скоро мы выпускаем новую версию платформы виртуализации zVirt 4.5. 13 ноября в 11:00 на вебинаре расскажем о ключевых обновлениях релиза:

• Папки ВМ

Группировка ВМ по папкам, 15 уровней вложения, наследуемые права доступа и изменение параметров высокой доступности одновременно для нескольких ВМ

• Обновленный v2v-конвертер

Конвертация из любых систем виртуализации и физических серверов на zVirt с минимальным простоем до 7-10 минут

• Новые функции SDN 

Запрещающие правила микросегментации, пулы IP-адресов, журналирование правил микросегментации, экспорт логических и внешних сетей в несколько дата-центров 

• Новый Terraform-провайдер 

Управление ВМ, дисками, логическими и внешними сетями, маршрутизаторами и политиками микросегментации

• Обновления Disaster Recovery 

Поддержка FC доменов хранения, репликация ВМ из нескольких ОЦОД в один РЦОД

На вебинаре проведем демонстрацию новых функций zVirt 4.5.

Присоединяйтесь, чтобы узнать подробнее о релизе!

Терминал, командная строка, консоль, shell — как правильно?

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

Всем ответившим заранее спасибо.

Привет, Хабр! Мы только что получили из типографии топовую DevOps-новинку этого года — книгу Камиль Фурнье и Иэна Ноуленда «Инжиниринг платформ: техническое и управленческое руководство». Промокод для читателей Хабра (скидка 32%) - fournier.

Переведённая нами статья Камиль Фурнье с описанием круга проблем и задач, которые решает книга - Инжиниринг платформ: не CFEngine единым / Хабр

Аннотация книги

Базовая книга по инжинирингу платформ – новому подходу к управлению программными системами, при работе с которыми требуется обслуживать множество разных аппаратных архитектур и операционных систем. Показано развитие концепции DevOps и объяснено, как  учитывать запросы и возможности пользователей независимо от способа работы с приложением, минимизировать задержки при обработке данных и упрощать масштабирование и поддержку многоплатформенных продуктов. Описан комплексный  подход к управлению продуктом с учетом потребностей клиентов, разработчиков, системных администраторов и предприятия в целом, актуальный на любых программных платформах.

Для специалистов DevOps, системных администраторов, руководителей команд

В SpaceWeb запустили новые готовые решения для VPS

Подключили в SpaceWeb три новых образа для быстрого развертывания на VPS:

• Ruby on Rails — наиболее популярный фреймворк для работы с Ruby. Для веб-приложений, API и быстрого запуска MVP-проектов;

• Zulip — серверная платформа для корпоративного обмена сообщениями с открытым исходным кодом. Альтернатива Slack с полным контролем над данными;

• DokuWiki — легковесная вики-система без базы данных. Подойдет для документации, баз знаний и внутренних корпоративных wiki.

Также в панели управления доступны свежие сборки для VPS:

• AlmaLinux 9 — стабильная и надежная альтернатива CentOS с долгосрочной поддержкой для серверов и корпоративных задач;

• Rocky Linux 9 — дистрибутив, ориентированный на продакшн-нагрузку с высокой производительностью и поддержкой современного ПО;

• MySQL 8 — популярная система управления базами данных теперь и в обновленных сборках с широким функционалом для проектов любого масштаба.

Все новые решения уже доступны для развертывания на новых и существующих VPS-серверах через панель управления на сайте SpaceWeb.

Самая короткая команда для проверки интернета: ping 1.1

Такая запись автоматически преобразуется в 1.0.0.1 Мало кто знает, что по стандарту ipv4 пропущенные октеты преобразуются в нули.

Почему-то это активно используется только в ipv6 типа fe20::baba

Вебинар "Ваша новая гиперконвергентная инфраструктура в 2026 году."

Переходите на гиперконвергентную инфраструктуру с уверенностью. Регистрируйтесь на AMA-сессию о платформе vStack и задайте все вопросы, которые вас волнуют.

Когда: 22 октября в 11.00 (МСК)

Мы поможем разобраться:

➖В чем выгода от внедрения vStack для вашей компании?
➖Чем платформа vStack отличается от конвергентных решений?
➖Как выглядит работа с платформой vStack?

Спикер: руководитель отдела по работе с партнерами Эльдар Новрузов.

Участие бесплатное по предварительной записи.

🔗 ЗАРЕГИСТРИРОВАТЬСЯ

От инцидента к контролю: как «Монитор» для 1С помогает ИТ-директору предупреждать сбои, а не тушить пожары

Что делать, если скорость проведения документов в 1С падает с трёх секунд до десяти минут? Обычно на этом этапе пользователи жалуются, сисадмины ищут узкие места, бизнес теряет время. Но есть и другой сценарий: когда проблему можно поймать до того, как она станет критичной.

14 октября в 12:00 на вебинаре «От инцидента к контролю» разберём, как инструмент «Монитор» для 1С помогает бизнесу предупреждать сбои, а не тушить пожары.

В программе:
— разбор ключевых функций «Монитора» (долгие запросы, блокировки, взаимоблокировки, ошибки технологического журнала, уведомления о событиях);
— демонстрация на реальном кейсе X-Com: «Скорость проведения документов в 1С упала с 3 секунд до 10 минут — как с помощью Монитора нашли проблемные места»;
— ответы экспертов на вопросы участников.

Спикеры:
— Андрей Бурмистров, 1С-эксперт по технологическим вопросам крупных внедрений;
— Леонид Дегтярёв, директор по информационным технологиям X-Com.

Все участники вебинара получат в подарок 30-дневную триал-версию 1С Монитора с бесплатной установкой от наших специалистов.

👉 Регистрируйтесь по ссылке

Просто напоминаю про багбаунти от Selectel с призами до 30 000 рублей

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

Количество участников ограничено: 30 человек, из которых будут выбраны 3 победителя. Регистрация уже открыта, стартуем в октябре — присоединяйтесь и покажите, на что вы способны! 

Призы:

1 место: 30 000 бонусных рублей

2 место: 20 000 бонусных рублей

3 место: 10 000 бонусных рублей

Как устроено под капотом

Мы сделали образ Keycloak в облаке Selectel. Он содержит docker-compose c Keycloak, Postgres, Nginx и скриптами бэкапов. Настраивается через cloud-init: все подставляется из user-data. Поддержка cron-задач, логика запуска, безопасность по умолчанию. Образ рассчитан на стабильную работу из коробки.

Внутри образа Nginx работает как обратный прокси, Certbot выпускает сертификаты. Есть cron-задачи для обновлений и создания дампов. Закрытые URL’ы, доступ по white-list — ради безопасности админского контура. Настройка происходит автоматически при запуске образа.

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‑шлюзов и начать оценивать реальное снижение рисков. Иначе мы рискуем повторить судьбу «облачной трансформации» — потратить миллионы, не получив существенного улучшения безопасности.

Собственный 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. В протоколе “из коробки” будет поддержка виртуальных каналов и мультисессионности.

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

Бессерверная архитектура обещает не думать об инфраструктуре, но скрывает риски 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-х. Уже сегодня нужно начинать тестирование и планирование, чтобы избежать хаотичной миграции под давлением регуляторов.

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

Когда 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