🎙️ За неделю

✉️ Искусственный интеллект станет главным направлением, проекты с ним будут получать поддержку государства в первую очередь.

✉️ DDoS-атаки на фармкомпании в России резко выросли: с начала августа их стало на 82 % больше.

✉️ Российские производители предложили усложнить госзакупки иностранной электроники.

✉️ Главная угроза электросетям — скачки энергопотребления от ИИ-систем, которые могут физически повредить инфраструктуру.

⚖️ Законы для ИТ и связи: что изменилось с 01.09.2025

👀 Персональные данные: отдельное согласие, обезличивание и передача в НСУД
Закон: 233-ФЗ (08.08.2024) , ПП №702 (22.05.2025) , №740 (28.05.2025 ), №961 (26.06.2025) , Приказ РКН №140 (19.06.2025).

Что изменилось:
📍Согласие на обработку ПДн теперь оформляется отдельным документом — нельзя прятать в договор или анкету.
📍По запросу Минцифры компании должны передавать обезличенные данные в гос­платформу (НСУД).
📍Данные нужно хранить раздельно: исходные и обезличенные. Требуются внутренние правила (локальные акты) по обезличиванию.

👀 Экстремизм и VPN: ответственность за умышленный поиск + запрет рекламы VPN
Закон: 281-ФЗ, 332-ФЗ (31.07.2025)

Что изменилось:
📍Появилась ответственность за умышленный поиск и доступ к экстремистским материалам (в т.ч. через VPN).
📍Рекламу VPN и сервисов обхода блокировок размещать нельзя.

👀 Абонентские номера и учётные записи: запрет длительной передачи третьим лицам
Закон: 281-ФЗ (31.07.2025); ПП №1050 (12.07.2025)

Что изменилось:
📍Нельзя надолго передавать свой номер (SIM) третьим лицам.
📍Нельзя передавать чужие логины/пароли без ведома владельца.
📍Краткая личная передача и передача близким/из перечня — допустима.

👀 Реклама на ресурсах нежелательных/заблокированных организаций — под запретом
Закон: 72-ФЗ (07.04.2025).

Что изменилось:
📍Запрещено размещать рекламу на сайтах/в приложениях нежелательных или экстремистских организаций, а также на ресурсах с ограниченным доступом в РФ.

👀 Предустановка ПО: MAX в перечне, RuStore обязателен (включая iOS/HyperOS)
Закон/акты: 194-ФЗ (07.07.2025); Распоряжение Правительства №2240-р (19.08.2025).

Что изменилось:
📍В перечень предустановки включили MAX (вместо VK Messenger).
📍RuStore обязателен на Android, HarmonyOS, iOS и HyperOS.
📍Нельзя ограничивать установку, использование и оплату приложений через RuStore. Иначе — товар считается с недостатком.

#ИТиЗАКОН

🎚 Управляемая деградация

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

Наш инженер вспомнил, как на заре своей карьеры попал в такое “боевое крещение”:

«Мы пилили один интернет-сервис. Предпраздничные дни, нагрузка выросла в 4 раза и сервера начали гудеть, как старый трактор. Главный архитектор сказал: «Всё, режем жир». Выключили аналитику, убрали тяжёлые картинки, закрыли пару второстепенных API — и дожили до вечера без падения. Клиент платил, корзина работала, авторизация держалась. Остальное вернули позже — по плану.»

❕ Управляемая деградация это отличный инструмент, но в нем есть подводные камни и преимущества

➡️ Минусы

🔴Надо знать, что резать.
Если рубанёшь не то, то вместо мягкой посадки получится эпичный краш. Нужно заранее иметь «список жертвенных функций».

🔴Пользователь всё равно что-то заметит.
Да, он останется в системе, но может выказать недовольства. Особенно, если отключили то, к чему он привык.

🔴Соблазн оставить всё как есть.
Иногда после аварии всё чинить лень, и «режим урезанной функциональности» живёт годами. А это уже не управляемая деградация, а технический долг.

➡️ Плюсы

🟢Выживание.
Главное — система остаётся на ногах, даже если хромает. Это спасает репутацию и деньги ( SLI/SLO/SLA).

🟢Гибкость.
Можно быстро адаптироваться под нагрузку, экономить ресурсы и отложить катастрофу.

🟢Хороший тест для архитектуры.
Если можно отключить второстепенные части и сервис при этом не падает — значит, архитектура живая.

➡️ Как готовиться и действовать:

🟡 Шаг 1 — подготовка
— Задать пороги включения деградации: что именно и при каких метриках выключаем.
— Составить матрицу приоритетов A/B/C и согласовать список «жертвенных».
— Внедрить переключатели фич, лимитирование трафика, автоматические “отсекатели” и брокер очередей.
— Потренировать переключения на учениях.

🟡 Шаг 2 — Отключение
— Отключать по приоритетам: сначала C, затем B; A — неприкасаемые (авторизация, корзина, оплата).
— Решения фиксировать: кто, что, когда отключил и на какой срок.
— Коротко сообщить пользователю: статус-страница или баннер «часть функций временно недоступна».

🟡Шаг 3 — Возврат
— Определить критерии отката: возвращаем функциональность, когда метрики стабильно в зелёной зоне.
— Восстанавливать в обратном порядке: B → C, с мониторингом.
— Короткий разбор: что сработало, что улучшить; обновить пороги и список «жертвенных».

🤔 Когда может пригодиться:

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

Управляемая деградация — как режим энергосбережения для сервиса и часть общей операционной устойчивости: вместе с DR-планом и регулярными учениями.

⭐️ Загадка зависшего Temporal UI. Часть 1 — расследование

Развернули Temporal (оркестратор workflow) в Docker и подключили две PostgreSQL-базы (основная и visibility).

Всё шло гладко. Через какое-то время от разработчиков прилетел запрос: «UI Temporal отдаёт 200 ОК, но ничего не грузит. Страница открывается, но данные не появляются.»

📍Проверили:
— Нагрузка на ноды в норме
— CPU/память без пиков, диски не забиты
— Алерты молчат.

Пробовали масштабировать Temporal и облегчить «тяжёлые» воркфлоу — без эффекта.
Подключили детальный мониторинг БД — и словили сюрприз: задержка отдельных запросов доходила до ~8 минут.

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

📍Что такое PgBouncer
— это лёгкий прокси для PostgreSQL, который управляет пулом соединений. Он ограничивает число одновременных коннектов от приложений, чтобы не положить базу. Когда пул переполнен, новые запросы встают в очередь и ждут свободного «слота». В этот момент UI кажется «зависшим»: страница уже вернула 200 ОК, но данных нет — запросы стоят в очереди на соединение.

Простая метафора
Запросы — пассажиры на остановке.
Пул соединений — парк автобусов с фиксированным числом машин(например 50).
База — конечная точка пути.
Пока все автобусы заняты, новые пассажиры стоят в очереди. Чем длиннее очередь, тем дольше UI «ничего не показывает».

Как это выглядит в архитектуре:

[Приложение / Temporal UI] → запросы → [PgBouncer] → очередь → [PostgreSQL]

📍Как мы подтвердили узкое место
— На дашбордах выросло время ответа БД и число «висящих» запросов
— В PgBouncer cl_active упёрся в лимит пула, а cl_waiting начал расти

Во второй части разберем:
— Подробный разбор: max_client_conn, default_pool_size, reserve_pool_size
— Что это такое и как работает — на аналогии с «автопарком» и очередью
— Как подобрать значения под вашу нагрузку и ограничения Postgres.

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

💳 Broadcom закручивает гайки

Не будем лукавить, многие до сих пор держат прод на стеке VMware/Bitnami — и теперь это бьёт по воспроизводимости.

Bitnami закрывает бесплатный доступ к версиям образов: публично остаются лишь :latest, версионированные теги уводятся в docker.io/bitnamilegacy (без обновлений и поддержки), а поддерживаемые и безопасные образы доступны в платной линейке Bitnami Secure Images.

🔘 Какие есть альтернативы

Бесплатно:
Docker Official Images (Postgres, NGINX, Redis и т. д.), официальные чарты от вендоров и community-чарты от проектов: grafana/helm-charts, prometheus-community, ingress-nginx.

Безопасно:
Docker Hardened Images, Chainguard Images (distroless/Wolfi), Red Hat UBI + официальные образы приложений.

Самостоятельно:
Собрать образы и чарты из исходного кода и опубликовать их в приватный реестр.

🔘 Что сделать сейчас

— Временно переключить образы на docker.io/bitnamilegacy/<image>:<tag> под теми же тегами, чтобы сервисы не упали. Это только на период миграции: в bitnamilegacy не будет обновлений и патчей.

— Запретить :latest во всех деплоях и прикрепить версии по digest . Политики можно зафиксировать admission-контроллером/OPA.

— Поднять локальный pull-through cache/реестр, например Harbor, и прописать registry mirrors в containerd/docker и CI — это снизит риск сбоев из-за потери связи с основным реестром (например, при его недоступности или удалении).

— Заменить Bitnami-образы на аналоги из Docker Official Images или «закалённые» по одному сервису за раз (canary/rolling). Проверить несовместимости: переменные окружения, пути, права пользователя, probes.

— Обновить Helm-values: image.repository, image.tag (или digest). При миграции на другие чарты сохранить PVC/секреты и аккуратно пробросить совместимые ENV.

— Включить сканирование образов и SBOM в CI/CD (например, Trivy/Grype/Docker Scout), верификацию подписи Sigstore (cosign), и настроить автоматические обновления зависимостей через Renovate/Dependabot.

👍 Ещё один способ не зависеть от Bitnami и других поставщиков образов и чартов: Nexus Repository как приватный реестр и pull-through cache.
Мы сами его активно используем.

⭐️ Sonatype Nexus Repository — универсальный менеджер артефактов для команд разработки и DevOps.
Централизует хранение, проксирование и раздачу пакетов/образов, ускоряя сборки и упрощая CI/CD.

Поддерживаемые форматы: Maven, npm, PyPI, NuGet, Docker Registry (OCI-совместимые образы), Helm, Go Modules, Cargo, Conan, APT/Yum, Conda, Git LFS, Hugging Face и др.

✅ Основной функционал:
— Хостинг приватных и проксирование внешних репозиториев (Maven, npm, PyPI, NuGet, Docker и др.)
— Групповые репозитории: один URL для клиентов и пайплайнов
— Редакции: Community Edition (СЕ) и Professional (Pro)
— Кэш зависимостей; для изолированных прокси-кэш (CE) + Content Replication (Pro)
— Роли и права (RBAC), LDAP; SSO/SAML (Pro)
— Политики очистки, soft-квоты; blob-хранилища: файловая система (CE), S3 (CE), Azure/GCS (Pro)
— REST API и вебхуки для автоматизации
— Лёгкое подключение в Jenkins, GitHub Actions, GitLab CI/CD, Azure DevOps
— Высокая доступность и кластеризация (Pro)
— Публикация и раздача внутренних пакетов, образов и release-артефактов

👉 Git
#полезное

🤵 Секреты сильного спикера: выступление без волнения (часть 2) (часть1)

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

🎧 Важна еще работа над собой

1️⃣ Снизьте волнение

Оно есть у всех - это нормальная реакция тела. Плюс в том, что адреналин мобилизует.

Что помогает:

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

✏️ Д.З.
Перед важной встречей или звонком попробуйте дыхательную разминку и отметьте, как меняется состояние.

2️⃣ Разогрейте голос и речевой аппарат

Это убирает зажимы и делает речь более уверенной и чёткой.

Что помогает:

🟢дыхание:
— вдох через нос, выдох ртом со звуком «ссс» или «шшш» как можно дольше;
— протяжные звуки «ааа», «ммм», «ууу»;

🟢артикуляционная гимнастика:
— вытяните губы «трубочкой», затем улыбнитесь максимально широко;
— покрутите языком по кругу за щёками, будто «разминаете» рот изнутри;
— сделайте несколько быстрых чередований: «па-па-па», «та-та-та», «ка-ка-ка»;

🟢скороговорки:

«То ли Толя — кореш Коли, то ли кореш Толи — Коля. Коли Коля — кореш Толи, то и Толя — кореш Коли»

«Откуда на просеке просо?
Просыпали просо здесь просто.
Про просо просянки прознали.
Без спроса все просо склевали.»

кто прочитал Просе́кко - вам пора отдохнуть 🥂

✏️ Д.З.
Выберите одну скороговорку и повторяйте её утром и вечером в течение недели.

3️⃣ Контролируйте темп и паузы

Волнение ускоряет речь. Чтобы не «срываться в бег», держите ритм.

Что помогает:

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

✏️ Д.З.
запишите на диктофон/видео кусок доклада и послушайте. Отметьте места, где хочется добавить паузы.

4️⃣ Привыкайте к микрофону

Микрофон усиливает не только голос, но и ошибки: шёпот, дыхание, резкие движения.

Что помогает:

🟢проверить звук заранее, сказать несколько фраз;
🟢держать микрофон на одном расстоянии (5-7 см от губ);
🟢потренироваться заранее, хотя бы с диктофоном на телефоне, чтобы привыкнуть к своему голосу.

✏️ Д.З.
Сделайте запись с микрофоном или на телефон и послушайте. Сначала голос покажется чужим, но привыкание наступает быстро.

💎
Работа со своим состоянием — это про уверенность.
Каждое выступление делает вас сильнее.

В третьей части разберём, какие неожиданности могут ждать на сцене и как быть к этому готовым.


#MentalDebug

😨 всем теплых осенних выходных 🐾

🎙️ За неделю

✉️ Траты на ИТ-услуги в России в 2024г выросли на 23% до 883,3 млрд ₽ и продолжают расти в этом году. Быстрее всего это происходит в облаках и кибербезопасности — из-за импортозамещения, интереса к ИИ и желания экономить на «железе».

✉️ Ввод мощностей ЦОД в РФ просел: 3,7 тыс. стоек за I полугодие 2025 — втрое меньше, чем в I полугодии 2024.

✉️ Рынок ИБ вырастет к 2030 году для малого и среднего бизнеса в России с 15 до 35–37 млрд ₽: кибератак становится больше, регулирующие законы ужесточаются и цифровизация ускоряется.

✉️ Растет продажа доступов к ИТ-сетям российских компаний на теневых площадках: в 2025-м объявлений стало в 2,5–3 раза больше, средний чек около $500, и такие доступы чаще всего служат входом для атак-вымогателей или для кражи данных.

🔍 Периодическая таблица Кубернетиса

120 элементов k8s в одном месте.

#полезное #красивое

Миграция с VMware на Zvirt в КИИ компании

Первыми об импортозамещении задумались энергетики.
Ещё в 2022 с такой задачкой к нам пришёл ДИТ крупного поставщика электроэнергии.

📞 Что нужно было сделать:

— заменить VMware на отечественную платформу;
— мигрировать сервисы без остановки бизнес-процессов;
— обеспечить непрерывность и дать все три линии поддержки.

🚩 Что сделали:

Компания получила полностью импортонезависимую виртуализационную платформу:
— инфраструктура переведена на Zvirt без потери данных и сбоев в работе сервисов;
— повышены управляемость и отказоустойчивость;
— обеспечены поддержка и развитие решения силами российских специалистов.

В течение трёх лет не возникало сбоев и проблем.

📍 Как все было на практике?

Инженер виртуализации Cortel

Раньше даже миграция с VMware на VMware была марафоном: масса подготовки, ночные окна, много ручной рутины. Готовых «миграторов» не было и мы таскали машины бэкапами, конвертерами и т. п.

Теперь задача ещё интереснее: уйти с VMware на импортозамещённую платформу.

Провели исследование и по ряду критериев выбрали Zvirt. Они одни из первых предложили универсальный конвертер — то, что делалось часами, можно сделать за минуты.

Но на практике оказались нюансы… Миграция всё ещё требует тщательной подготовки и много ручного труда, а местами «допиливание напильником».

Какие были ограничения:
— в автоматическом режиме часть сетевых настроек внутрь ВМ не попадает, хотя в задаче они прописаны и приходилось заходить в каждую машину и править сеть руками;
— отказаться от этих «автонастроек» при создании задач было нельзя — это добавляло время простоя;
— не все ВМ стартовали на целевой площадке без предварительной ручной проверки.

Важно заложить ресурсы на весь цикл: аудит и подготовку, тестовые прогоны, окна простоя, ручные правки (сеть/драйверы), проверку сервисов после старта и возможный откат. По опыту, время «от заявки до стабильной работы» занимает в 1,5–2 раза больше, чем чистая конвертация ВМ

👉 Подробнее про кейс читаем тут

#изПрактик

➡️ Миграции с 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