➡️ Миграции с VMware на отечественные платформы в 2025
Подводные камни, как минимизировать регуляторные риски и что важно для субъектов КИИ.

— Реальный опыт перехода на российскую виртуализацию: подводные камни
— Конец эпохи VMware: как российскому бизнесу избежать штрафов и простоев в 2025 году
— КИИ в 2025 году: кого коснутся изменения и как избежать проблем

⭐️ Загадка зависшего Temporal UI.
Часть 2 — параметры пула

В прошлой части рассказали как UI Temporal "падал" из-за переполненного пула соединений в pgbouncer.

Теперь разберем как держать пул под контролем.

Три главных параметра:

📍 max_client_conn
Максимальное количество клиентских соединений, которые PgBouncer может принять от приложения. Если это значение превышено, новые подключения отклоняются.

Пример: max_client_conn = 100 позволяет до 100 одновременных клиентов.

📍 default_pool_size
Размер пула соединений для каждой базы данных (по умолчанию). Это число реальных подключений к PostgreSQL.

Пример: default_pool_size = 50 значит, что PgBouncer держит до 50 открытых соединений к базе.

📍 reserve_pool_size
Резервный пул, который PgBouncer использует, если основной пул (default_pool_size) исчерпан. Новые клиенты могут временно занять место из резерва.

Пример: reserve_pool_size = 10 , добавляет 10 "аварийных" соединений.

Как это работает в аналогии:

— max_client_conn — общая вместимость автовокзала (всех ждущих пассажиров)
— default_pool_size — число регулярных автобусов на каждый маршрут (БД + пользователь)
— reserve_pool_size — дополнительные автобусы, которые подойдут при ажиотаже

⏳ Как проверить состояние пула

Подключаемся к pgbouncer и выполняем

SHOW POOLS;

Вывод будет примерно следующим

database | cl_active | cl_waiting | ...
---------+-----------+------------+------
temporal |        45 |         10 | ...

- cl_active — активные запросы
- cl_waiting — запросы, ожидающие соединения

Если постоянно высокий cl_active → возможно, нужно поднять default_pool_size

В следующей части разберем как мониторить pgbouncer.

#заметкиИнженера

⚙️ Техническая шпаргалка DevOps: ключевые метрики Postgres и PgBouncer в Prometheus.

🚛 PgBouncer Exporter
Мониторит прокси-слой PgBouncer, помогая выявить проблемы с пулом соединений.

Основные метрики:
— pgbouncer_pools_client_waiting_connections — число запросов, ждущих соединения. Если > 0, пул переполнен, как было с Temporal (8-минутные задержки UI).
— pgbouncer_pools_client_active_connections — активные клиентские соединения. Показывает текущую нагрузку на прокси.
— pgbouncer_pools_client_maxwait_seconds — максимальное время ожидания в очереди. Высокое значение сигнализирует о задержках.

🚛 Postgres Exporter
Мониторит состояние PostgreSQL, выявляя проблемы на уровне базы.

Основные метрики:
— pg_stat_activity_count — число активных запросов. Высокое значение может указывать на перегрузку.
— pg_locks_count — количество блокировок. Рост говорит о конфликтах в базе.
— pg_database_size_bytes — размер базы. Помогает заметить неконтролируемый рост данных.

pgbouncer_exporter и postgres_exporter — must-have для мониторинга PgBouncer и PostgreSQL. Они помогают поймать переполнение пула или проблемы базы до сбоя приложения.

#полезное

🖥 systemd — система инициализации и менеджер служб, ставший стандартом во многих дистрибутивах Linux (Ubuntu, Debian, Fedora и др.).

Несмотря на критику — да, знаем, что любят его не все; привет nosystemd.org — systemd прочно встроился в экосистему Linux.

Что это такое и какие типы юнитов он использует

systemd — не просто замена SysV init. Он управляет запуском системы, службами, монтированием файловых систем, таймерами и многим другим. Базовая единица конфигурации — юнит (unit): файл, который описывает, что и как запускать.

👀 Основные типы:

.service — управляет службами (демонами/процессами). Например, nginx.service запускает веб-сервер.

.socket — описывает сокеты для активации по событию (входящее соединение). systemd слушает сокет и при первом подключении запускает одноимённый .service.

.timer — планирует запуск одноимённого .service по расписанию (аналог cron по идее, но сам по себе команды не выполняет).

.path — следит за файлами/каталогами и при изменениях активирует одноимённый .service.

.mount — описывает точку монтирования ФС (имя строится из пути: /mnt/data → mnt-data.mount).

.automount — создаёт автомонтирование для соответствующего .mount: монтирование происходит при первом обращении.

.target — группирует юниты и задаёт точки синхронизации загрузки; multi-user.target примерно соответствует runlevel 3, graphical.target — runlevel 5.

Понимание этих типов юнитов даёт тонкий контроль над системой; дальше можно посмотреть и на .swap, .device, .slice, .scope.

#линуксятина

🐧 Linux. От новичка к профессионалу

Практическое руководство: от установки и рабочего окружения до сетей, безопасности и серверов. 9-е, переработанное и дополненное издание.

🔍 Рассматривается:
— установка и базовая настройка Fedora, openSUSE, Ubuntu;
— файловая система, вход в систему, графический интерфейс;
— установка ПО, сеть и Интернет;
— безопасность, резервное копирование, защита от вредоносных программ;
— развёртывание веб-сервера и сетевых сервисов;
— практические кейсы: мини-серверная, сервер видеонаблюдения, DLNA;
— виртуализация KVM (с веб-интерфейсом управления);
— сетевые настройки через Netplan;
— запуск игр в Linux через Steam;
— дополнительные главы в PDF на сайте издательства.

Автор:
Д. Н. Колисниченко
Издательство: СПб.: БХВ-Петербург, 2025, Серия «В подлиннике»

#книги #Linux

🎙️ За неделю

✉️ Новая доктрина информационной безопасности.

✉️ 60% рос­сий­ских ком­па­ний имеют кри­тичес­кие уяз­ви­мос­ти, ко­торые мо­гут при­вес­ти к зах­ва­ту кор­по­ратив­ной ин­фраструк­ту­ры.

✉️ Возвращать ли зарубежных ИТ-вендоров? Часть рынка поддерживает идею, но при условии подтверждённой безопасности и защите данных.

✉️ Импортное «железо» без нарушения закона: как работает схема «смешанных лотов»?

✉️ Повреждения подводных интернет-кабелей в Красном море стал причиной крупный сбоев в работе облачных сервисов Microsoft Azure.

🕵️‍♀️ Шифровальщики — угроза №1

Вымогатели стали главной болью российского бизнеса.
За полгода доля успешных атак дошла до 49%. Последствием являются простои, потери, штрафы...

Громкими примерами этого лета стали атаки на Аэрофлот, крупные московские аптечные сети и инцидент в сети ВинЛаб.

❕ Цель большинства шифровальщиков — деньги: выкуп за ключ расшифровки.
Как правило, его требуют в криптовалюте (из-за относительной анонимности).

Что прилетает чаще всего:
— Crypto-ransomware: шифрует файлы, система остаётся доступной: «всё на месте, но ничего не открыть».
— Locker: блокирует вход и работу устройства, а на экране появляется требование выкупа.
— Гибриды: и шифруют, и блокируют.
— Двойное/тройное вымогательство: крадут данные, шантажируют публикацией и иногда давят DDoS.
А доминирует — «вымогательство как сервис» (RaaS):
операторы дают платформу и софт, аффилиаты взламывают и делят выручку.

🔴 Шифровальщик попадает в сеть и захватывает файлы поэтапно

🟠 Вход
Через фишинговое письмо/ссылку, непропатченное ПО и плагины, слабые пароли и открытый RDP/VPN, съёмные носители и общие шары, вредоносные макросы, компрометацию подрядчика или обновлений (цепочка поставок).

🟠Закрепление
Поднимают права, отключают защиту и журналы.

🟠Шифрование
Развёртывают шифровальщик, шифруют данные и бэкапы.

⚠️ Если ваши файлы внезапно меняют расширения и не открываются, компьютер резко тормозит, исчезли точки восстановления и теневые копии, появились «READ_ME/DECRYPT»-инструкции или на экране появилось требование выкупа — вас поймали.

Но не стоит паниковать!
Следует соблюдать простые инструкции...

Если они разработаны в вашей компании - следуйте им.

Если таковых нет, можете скачать универсальный стоп-план с пошаговыми действиями от наших специалистов ИБ. 👇

#проИБ #гайды

🪖 Как минимизировать риски атак?

Подборка материалов, которые помогут выстроить процессы безопасности и защиты данных.

✅CIS: принципы и практики построения информационной безопасности в компании
✅Бэкап (backup): как сделать резервное копирование надёжным
✅Примеры ИТ-стратегий. Как провести ИТ-аудит бизнеса?
✅Как провести аудит защиты персональных данных: пошаговая инструкция
✅Кибербезопасность: инструкции и практики

⭐️ Загадка зависшего Temporal UI
Часть 3 — мониторинг PgBouncer

В прошлых частях разобрали, что UI Temporal «подвисал» из-за переполненного пула соединений в PgBouncer, и настроили max_client_conn, default_pool_size и reserve_pool_size.

📍 Как это все держать под контролем?

Для мониторинга PgBouncer используем pgbouncer_exporter.

Он собирает широкий набор метрик, среди которых наиболее показательными для мониторинга нагрузки являются:
— cl_active — активные клиентские соединения, которые сейчас обрабатываются;
— cl_waiting — клиенты, ожидающие свободное соединение (главный индикатор переполнения пула);
и отдаёт их в Prometheus.

📍 Разворачиваем pgbouncer_exporter через Docker Compose:

services:
  pgbouncer-exporter-dev:
    container_name: pgbouncer-exporter-dev
    image: pgbouncer-exporter:v0.11.0
    environment:
      - PGBOUNCER_EXPORTER_CONNECTION_STRING=postgres://pgbouncer:password@192.168.1.10:6432/pgbouncer
    ports:
      - "9127:9127"

*Примечание: с версии 0.11.0 экспортер требует PgBouncer ≥ 1.8 и открывает новое подключение на каждый скрейп. В pgbouncer.ini добавьте ignore_startup_parameters = extra_float_digits.

📍 Добавляем джобу в конфиг vmagent или Prometheus для сбора метрик:

- job_name: pgbouncer_exporter
  scrape_interval: 5s
  static_configs:
    - targets: ["192.168.1.10:9127"]  # IP, где работает экспортер

📍 Чтобы сразу ловить переполнение пула, добавляем алерт в vmalert:

groups:
  - name: pgbouncer
    rules:
      - alert: ConnectionPoolWaitCritical
        expr: sum(pgbouncer_pools_client_waiting_connections) by (database) > 0
        for: 0m
        annotations:
          summary: "Количество ожидающих подключений в базе {{ $labels.database }} = {{ $value }}"

Этот алерт срабатывает, если есть ожидающие соединения (cl_waiting > 0), сигнализируя о переполнении пула.

📍Зачем всё это

С таким мониторингом рост cl_waiting в Temporal был бы виден сразу — стало бы понятно, что не хватает соединений в пуле. Дальше — либо увеличить default_pool_size, либо оптимизировать запросы — и не ловить 8-минутные задержки UI.

#заметкиИнженера

Мониторинг PostgresSQL и PgBouncer: практические метрики и алёрты

Ключевые метрики для Grafana

👀 Очередь соединений в PgBouncer:

max_over_time(pgbouncer_pools_client_waiting_connections[5m])

👀 Максимальное время ожидания (сек):

max_over_time(pgbouncer_pools_client_maxwait_seconds[5m])

👀 Активные соединения PgBouncer:

pgbouncer_pools_client_active_connections

👀 Активные запросы в PostgreSQL:

sum(pg_stat_activity_count{state="active"})

👀 Блокировки в PostgreSQL:

pg_locks_count

Примеры алертов

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

groups:
- name: pgbouncer
  rules:
  - alert: PgbouncerQueueSlow
    expr: max_over_time(pgbouncer_pools_client_maxwait_seconds[5m]) > 1
    for: 5m
    annotations:
      summary: "Долгое ожидание в PgBouncer"
      denoscription: "maxwait_seconds > 1с последние 5м. Возможна нехватка коннектов."

Также отследим момент повышение блокировок в базах данных

- name: postgres.rules
  rules:
  - alert: PostgresLocksSpiking
    expr: sum(pg_locks_count) > 50
    for: 10m
    annotations:
      summary: "Рост блокировок в Postgres"
      denoscription: "Блокировки превышают порог > 10м. Проверьте конфликтующие транзакции."

Почему это важно:

— Раннее обнаружение проблем: алерты срабатывают до того, как пользователи заметят задержки.
— Проактивное реагирование: возможность увеличить пул соединений до возникновения очереди.
— Комплексный мониторинг: отслеживание как PgBouncer, так и PostgreSQL дает полную картину.

#полезное #разбор

🖥 find — утилита для поиска файлов в Linux

Одна из старейших и самых мощных утилит в арсенале Linux.
Появилась в Unix 5 версии еще в 1974 году и до сих пор остаётся незаменимым инструментом для работы с файловой системой.

Что умеет?
— Рекурсивный поиск по директориям
— Фильтрация по имени, размеру, времени изменения
— Выполнение действий над найденными файлами
— Поиск по типам файлов (файлы, директории, симлинки)

Основное использование:

✅ Поиск по имени:

find /home -name "*.txt"

Найти все .txt файлы в директории /home

✅ Поиск по размеру:

find /var/log -size +10M

Найти файлы больше 10 МБ в /var/log

✅ Поиск по времени изменения:

find /etc -mtime -7

Найти файлы, изменённые за последние 7 дней

✅ Поиск и удаление:

find /tmp -name "*.tmp" -delete

Найти и удалить все .tmp файлы в /tmp

✅ Поиск с выполнением команды:

find /home -name "*.jpg" -exec chmod 644 {} \;

Найти все JPEG файлы и изменить их права доступа

🤓 find может искать файлы, используя регулярные выражения с -regex, а также комбинировать условия с операторами -and, -or, -not.

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

#линуксятина

🖥 Шпаргалка по find: от базового использования до продвинутых сценариев

#полезное

🤵 Форс-мажор на сцене — как быть готовым?
(часть 3)

Идеально собранный доклад и подготовка не спасает от неожиданностей.

Сцена всегда проверяет на прочность.

Есть три источника проблем: вы, техника и зал.

1️⃣ Самочувствие спикера

Перед выходом накрывает дрожь, сухость во рту, а в голове только мысль: «Скорее бы закончить». Это нормальная реакция организма на стресс.

Что помогает

📍Выспаться. Тело и голова работают лучше после сна.
📍За час до выступления — лёгкий перекус: банан, горсть орехов или йогурт.
📍Перед выходом — короткая разминка. Пройдитесь, разомните плечи, сделайте три глубоких вдоха.
📍Разогрейте голос: улыбнитесь, произнесите скороговорку, проговорите пару фраз вслух.

Чего не делать

⚪️Не злоупотреблять кофе и энергетиками — добавят дрожь.
⚪️Не есть плотно — тяжесть в животе мешает сосредоточиться.
⚪️Не пить успокоительные «на всякий случай» — они замедляют речь.
⚪️Не зубрить текст. Держите в голове только структуру.

2️⃣ Техника и регламент

Микрофон может фонить, кликер зависнуть, проектор «съесть» цвета. Иногда вас задержат, а иногда наоборот — попросят уложиться в половину времени.

Что помогает

📍Прийти заранее, проверить микрофон, слайды, кликер.
📍Убедиться, что текст и код читаются даже с последнего ряда.
📍Держать запасной финал: пару фраз, которыми можно завершить доклад в любой момент.
📍Сбой техники обыграть шуткой: «Кажется, проектор решил взять слово».

Чего не делать

⚪️Не цепляться за слайды. План доклада должен жить в голове.
⚪️Не злиться. Зрители всегда помнят не сбой, а эмоцию спикера.

3️⃣ Аудитория

Зал — всегда непредсказуем. Кто-то внимательно слушает, кто-то скроллит ленту, кто-то зевает. А иногда прилетает резкий вопрос или провокация.

Что помогает

📍Не принимать равнодушие лично: люди могут быть уставшими или перегруженными.
📍«Разбудить» зал движением. Например, сделать самому приседание и предложить повторить зал. Смех и лёгкая активность сразу возвращают внимание.
📍Выдайте свисток кому-то из зала и скажите «Если я буду заговариваться - свистите».
📍На сложный вопрос честно сказать: «Отличный вопрос, обсудим после». Это звучит сильнее, чем выкручиваться.
📍На провокацию реагировать спокойно. Улыбнуться, перевести в шутку: «Вижу, тема задела — продолжим в кулуарах».

Чего не делать

⚪️Не оправдываться («наверное, скучно»). Это только снижает доверие.
⚪️Не спорить в лоб — спикер выигрывает, когда держит спокойный тон.
⚪️Не прятаться за слайды. Контакт глазами важнее текста на экране.

💟 Доклад держится не на технике, а на вас.
Если вы прошли все этапы — сцена перестаёт пугать.

Удачи вам и сильных докладов!

Читать (часть 1) (часть 2)

#MentalDebug

🎙️ За неделю

✉️ В российских компаниях киберзащитой довольны лишь 38% специалистов ИБ, при этом у каждого пятого проблемы связаны с многовендорными решениями (в мире — примерно у каждого второго).

✉️ Цены на SSD/HDD и технику могут вырасти. Из-за ажиотажа вокруг ИИ дорожают чипы памяти, а серверные HDD 22+ ТБ приходят с ожиданием до года.

✉️ Российские компании слабо проверяют безопасность своих ИТ-продуктов: 28% вообще игнорируют DevSecOps, ~49% используют его поверхностно, что сочетается с рекордными утечками ПДн.

✉️ Поправки от Минцифры в УК/УПК о «преступлениях с использованием ИИ» из-за расплывчатых формулировок могут фактически криминализировать всю ИИ-индустрию.

🏓 Памятка по безопасности сети: 6 типов правил для вашего файрвола

#полезное

⏰ Комплексная ИБ для пищевого холдинга

Угрозы к веб-сервисам усложнились: это уже не единичные инциденты, а связки — DDoS, боты-скрейперы, подбор учётных данных, атаки через формы и API, удары по DNS.

Подход к безопасности в таких ситуациях тоже должен быть комплексным.
Именно такую схему мы организовали в инфраструктуре крупного пищевого холдинга.

📞 Задача

— защитить веб-ресурсы от DDoS и бот-трафика;
— закрыть уязвимости приложений без ухудшения UX;
— обеспечить отказоустойчивый DNS для внешних и внутренних сервисов;
— гарантировать SLA 99,97% и поддержку 24×7.

🖲️ Решение на 4-х уровнях

L7 DDoS-защита — держит наплывы на уровне приложений.
AntiBot — отсекает вредоносных ботов, пропуская легитимных пользователей и «хороших» ботов.
WAF — блокирует опасные запросы к вебу и API до приложения.
Защищённый отказоустойчивый DNS — перенесены 76 DNS-зон, убрана «одна кнопка» отключения сервисов.

🚩 Результат
Получили непрерывную работу сервисов с подтверждённым SLA 99,97%; тонкие настройки и изменения вносятся без просадки по UX; эксплуатация ведётся 24×7 — мониторинг, быстрые правки и тюнинг правил.

На сегодняшний день контур в строю: уровни защиты регулярно актуализируются, правила WAF подстраиваются под реальный трафик, DNS остаётся отказоустойчивым — решение стабильно и безотказно.

➡️ Подробнее про кейс

#изПрактики

💻 Гибкие политики перезапуска для контейнеров

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

🔘Что это даёт?

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

В Kubernetes 1.34 появилась возможность задавать политику перезапуска для каждого контейнера отдельно. Это позволяет гибко управлять поведением контейнеров в одном поде.

🔘Где пригодится?

— Init-контейнеры: Например, init-контейнер готовит среду или загружает учётные данные и должен выполниться только один раз (restartPolicy: Never). Основной контейнер при этом может перезапускаться всегда (restartPolicy: Always).

— Многоконтейнерные поды: Если в поде несколько контейнеров (например, приложение и логгер), можно перезапускать только один из них при сбое, сохраняя стабильность остальных.

Подробнее и примеры можно посмотреть в статье.

#заметкиИнженера