В репозитории:

• NodeGroupConfiguration, который блокирует загрузку модуля и выгружает его, если он загружен;

• FalcoAuditRules для детекта попыток эксплуатации (доступно в DKP EE и CSE).

Применяется через kubectl apply, подробности и инструкции в README.

Рассказываем про большое обновление ИИ-помощника, встроенного в консоль Cloud.ru. В этом релизе расширили возможности работы с виртуальными машинами и добавили три специализированных сценария.

🖥️Несколько ВМ в разных конфигурациях

Гига-помощник научился создавать сразу несколько виртуальных машин за один запрос и управлять ими по команде: может добавлять и удалять диски, менять конфигурации и выполнять другие повседневные операции. Теперь вы сможете легким движением руки развернуть сразу dev, stage и prod или подготовить все необходимое для нагрузочного тестирования. 

🤖Три новых сценария 

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

• 🛠 DevOps-агент — разворачивает и обслуживает популярные сервисы по текстовому промпту: PostgreSQL, Kafka, WordPress, GitLab и другие. Не нужно держать в голове порядок шагов или обращаться к документации, достаточно описать задачу.

• 📡 SRE-агент — настраивает мониторинг и алертинг, а также помогает разбирать инциденты. Удобен, когда нужно быстро поднять наблюдаемость для нового сервиса или разобраться в причинах сбоя.

• 💰 FinOps-агент — находит забытые и неиспользуемые ВМ и предлагает их удалить, чтобы исключить лишние расходы. Показывает топ дорогих ресурсов и позволяет сравнивать траты за разные периоды.

Ищите Гига-помощника в правом нижнем углу главной страницы консоли

Системному администратору всё чаще приходится отвечать не только за серверы, доступы и инциденты, но и за пайплайны доставки, K8s, безопасность, нагрузку, API Gateway и наблюдаемость. И чем сложнее инфраструктура, тем дороже обходятся решения, принятые «на глаз» или завязанные на опыт одного-двух человек.

В сегодняшней подборке — бесплатные демо-уроки OTUS по DevSecOps, Ansible, self-service-деплою, Kubernetes, Nginx/Angie, OpenTelemetry, CD через GitLab CI и нагрузочному тестированию. Их проводят преподаватели-практики: можно посмотреть на формат обучения, познакомиться с экспертами, задать вопросы и закрыть отдельные пробелы в рабочих темах.

• 30 апреля, 20:00. Планируем внедрение DevSecOps — что следует учесть?

• 30 апреля, 20:00. Битрикс24 + MAX: разработка чат-ботов и автоматизация коммуникаций

• 5 мая, 20:00. Ansible: быстрый старт

• 7 мая, 20:00. Стоп рутина: как self-service деплой экономит ресурсы команды

• 7 мая, 20:00. От кода до Kubernetes за полтора часа

• 14 мая, 19:00. Оптимизация Nginx и Angie под высокие нагрузки

• 18 мая, 20:00. Деплой на стероидах: ускоряем доставку через Golden Path

• 18 мая, 20:00. Основы Kubernetes: архитектура и абстракции

• 18 мая, 20:00. DevSecMLOps: как безопасно внедрять ИИ в процессы разработки и эксплуатации

• 19 мая, 20:00. Навыки нагрузочного тестирования и их роль в развитии инженера

• 19 мая, 20:00. Организуем CD с помощью Ansible и GitLab CI

• 19 мая, 20:00. Введение в OpenTelemetry и основы наблюдаемости

• 21 мая, 20:00. API Gateway и не только: шаги к идеальной архитектуре внешних API

Больше полезных материалов для решения практических инфраструктурных задач — в тематическом дайджесте по Kubernetes, DevSecOps, Ansible, Nginx и смежным темам.

DevSecOps часто начинают с инструментов: добавить сканер в CI/CD, включить проверки зависимостей, собрать отчёты по уязвимостям. Но на практике быстро выясняется, что проблема глубже: непонятно, кто отвечает за найденные риски, какие проверки действительно нужны, как не утопить команду в ложных срабатываниях и где проходит граница ответственности между разработкой, эксплуатацией и ИБ.

30 апреля в 20:00 пройдёт бесплатный демо-урок «Планируем внедрение DevSecOps — что следует учесть?».

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

Записаться на урок можно на странице курса «Внедрение и работа в DevSecOps».

Если хочется шире посмотреть на инфраструктуру, Kubernetes, DevSecOps, observability, Ansible, Nginx и не только — в дайджесте собрали больше бесплатных уроков и гайдов по этим темам.

🌲 Открываем регистрацию на Дебаг Кемп

Мы придумали формат, который давно хотели сами: выбираешься из города, два дня в сосновом лесу на Карельском перешейке — маршрут, костёр, мастер-классы по выживанию, нетворкинг без слайдов и питчей. Просто люди, с которыми интересно, и никакого Slack-а.

📅 6–7 июня 2026 (выходные) 👥 Всего 25 мест — маленький формат, это принципиально.

Цена растёт по мере приближения к дате. Оплатить можно частями через сплит → регистрация

Если вы 💎 практик сообщества — скидка 15% применяется при регистрации автоматически. Ещё не практик, но думаете? Сейчас самый разумный момент.

👀 Узнать больше · 📝 Регистрация

Вопросы — в чат, мы там живём.

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

Через час выясняется – у 400 пользователей сломалась связка UPN‑sAMAccountName.

Причина – логическая ошибка в условии.
Тест на 10 объектах её просто не поймал.

Дальше обычно три сценария.

Первый – откат из резервной копии.
Но копию сделали 18 часов назад. За это время уже:

– создали новые аккаунты;
– поменяли пароли;
– выдали права.

Откат чинит одно и ломает другое.

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

Обычно это уже режим «админской археологии».

Третий – взять снимок состояния до запуска и вернуть только нужные атрибуты у нужных объектов.

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

Не «когда всё поехало», а до того, как нажали Enter.

Массовое изменение без снимка перед изменением – это не автоматизация.

Это ставка на то, что скрипт идеален.

Обычно – нет.

Две попытки миграции FineBI, поломанная синхронизация кластера и выводы, которые пригодятся и вам

На FineBI 6.0 единственным способом резервирования было копирование папки через rsync. Восстановление медленное, переключение на резервный сервер требовало ручной правки конфигураций. Проще было чинить прод, чем восстанавливаться из бэкапа.

В ОТП Банке решили мигрировать сразу на 7.0: нужен был кластер, нормальное резервирование и новые фичи. Первая попытка выглядела логично, прошла без ошибок, но на выходе получился кластер с поломанной синхронизацией между нодами. Как нашли рабочую схему со второй попытки, почему заменили стандартный балансировщик на корпоративный и какие точки отказа остались, расскажет Евгений Иванов на FineDay Online.

📅 22 апреля | 15:00 МСК | FineDay Online 2026

Бесплатно, онлайн, ~3 часа

→ Регистрация

Мы в Хайстекс любим API-интеграции, это стандарт и архитектурная основа нашего продукта. Когда нужно мигрировать сотни машин в зрелые публичные облака, API — оптимальный выбор. Но у любого вендора СРК и миграции есть бэклог с кейсами, где API превращается из помощника в серьезную издержку.

Этот пост — для инженеров и архитекторов, которые занимаются миграциями ВМ и регулярно упираются в стоимость и сроки поддержки API-интеграций под каждую новую целевую площадку.

При переносе виртуальных машин между облаками и частными контурами API-интеграция дает максимум автоматизации «на бумаге». Но как только целевых площадок становится больше одной-двух или в проекте появляется специфическая (иногда собранная «на коленке») платформа, выясняется, что у этой автоматизации высокая цена. Вместо быстрого переезда миграция через API превращается в отдельный проект на недели разработки, тестирования и ожидания поддержки со стороны конкретной платформы.

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

Если API целевой среды — это нестабильная переменная, логично вывести её за скобки. Так появилась архитектура Direct2Target (D2T). Это метод, позволяющий сделать целевую сторону миграции полностью воспроизводимой без зависимости от API конкретного облака. В сценарии D2T целевая ВМ-«болванка» подготавливается заранее — вручную или с помощью ваших привычных скриптов («инфраструктура как код»). Решение не тратит время на попытки договориться с облаком о создании ресурсов, а сразу приступает к главной задаче: доставке данных напрямую в диски подготовленной машины.

D2T — не замена API-подходу, это «план Б». Функция позволяет развернуть машину в условиях архитектурных ограничений целевой площадки, не дожидаясь доработок со стороны провайдера.

О том, как реализовать миграцию «в обход» API, почему это в 5 раз быстрее и как перестать превращать переезд в вечную разработку — поговорим на вебинаре 29 апреля в 11:00 (МСК). Регистрация по ссылке.

В программе:

• Прикладные сценарии: когда D2T эффективнее классической интеграции по времени и ресурсам.

• Технологический стек: как обеспечить воспроизводимость миграции на любых площадках без зависимости от API.

• Live Demo: подготовим таргет-ВМ и запустим миграцию в прямом эфире.

Приносите в комментарии баги облачных API, из-за которых сроки проектов улетали в бесконечность. Обсудим, как D2T мог бы упростить вам жизнь в тех кейсах. 

Какие кейсы разберем:

• SSH сломался после обычной операции с архивом

• Сервер не запускается на нужном порту — без очевидной причины

• После обновления ядра система начинает вести себя странно

• Сеть в ВМ ломается после добавления интерфейса

• Балансировщики с одинаковыми конфигами дают разный результат

Обсуждение почти как на офисной кухне, только с логами и командами. А еще дарим мерч, если отправить свой кейс на разбор.

Подробности и регистрация по ссылке.

Прямо сейчас в кинотеатре «КАРО 11 Октябрь» на Новом Арбате в Москве начинается ежегодная конференция про ИИ и облака GoCloud 2026. Нет возможности прийти? Тогда жмите кнопку «Смотреть трансляцию» на сайте и присоединяйтесь к нам удаленно.

После открытия выбирайте вкладку интересного вам трека — Инфраструктура, Прикладной ИИ, Приложения и разработка, Данные и аналитика — и смотрите выступления более чем 40 спикеров. Вопросы можно задавать в чате.

👉 Присоединиться к трансляции

Компании переходят от внешних поставщиков искусственного интеллекта к собственной инфраструктуре ради контроля данных, безопасности, предсказуемых затрат и независимости. Разберем, как построить платформу искусственного интеллекта полного цикла на голом железе: от запуска вывода моделей до тонкой настройки. Покажем, как объединение узлов с графическими ускорителями через InfiniBand превращает серверы в кластер суперкомпьютера и как масштабировать ИИ-нагрузку по всем канонам высокопроизводительных вычислений.

Спикер: Александр Шакмаев — менеджер продукта, Cloud.ru

Трек: Инфраструктура

📅 Когда: 9 апреля в 14:40–15:20 мск
👉 Зарегистрироваться

А пока ждете выступление, загляните в блог: Тестируем B200: живые бенчмарки с GLM-4.7

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

Также покажу, как одни и те же блоки выполняются в разных окружениях и как ИИ-ассистент ускоряет сборку полного цикла: от архитектуры и непрерывной интеграции до бизнес-логики приложений.

Спикер: Антон Щеколдин — менеджер продукта, Cloud.ru

Трек: Приложения и разработка

📅 Когда: 9 апреля в 12:50–13:30 мск
👉 Зарегистрироваться

А пока ждете выступление, загляните в блог: Практическое применение eBPF: serverless-платформа с поддержкой TCP-приложений

SpaceWeb запустил в частном облаке серию готовых open-source сервисов для командной разработки. Каждый разворачивается независимо — можно выбрать только то, что нужно под конкретную задачу. В набор вошли четыре инструмента:

• MinIO — S3-совместимое объектное хранилище для бэкапов, логов, артефактов сборки и статики;

• Zulip — командный чат с тематическими ветками для асинхронной работы;

• Zabbix — мониторинг серверов и приложений: CPU, память, диски, базы данных, веб-серверы;

• n8n — конструктор автоматизации без кода: соединяет сервисы, ловит вебхуки, создает тикеты, управляет файлами.

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

Подробности — на сайте SpaceWeb.

Покажем, почему ML-системы начинаются не с моделей, а с дата-инфраструктуры. Разберем роль PostgreSQL, Kafka, Redis, ClickHouse и OpenSearch в реальных сценариях машинного обучения клиентов. Обсудим, как управляемые дата-сервисы становятся фундаментом ИИ-нагрузок, и какие продуктовые требования меняются — превращая дата-платформу в IaaS-слой для машинного обучения.

Спикер: Сергей Геворкян — менеджер продукта, Cloud.ru

Трек: Данные и аналитика

📅 Когда: 9 апреля в 15:35–16:05 мск
👉 Зарегистрироваться

А пока ждете выступление, загляните в блог: Как мы разгрузили базу данных в проде и не сломали систему

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

Спикер: Владислав Янковский — старший Go-разработчик, Cloud.ru

Трек: Прикладной ИИ

📅 Когда: 9 апреля в 16:40–17:00 мск
👉 Зарегистрироваться

А пока ждете выступление, загляните в блог: NoCode инструменты для создания AI-приложений с RAG: быстрый старт

Database as a Service — подход, в котором базами данных управляют как платформенным сервисом: с автоматизацией и предсказуемым жизненным циклом. Вместо ручного администрирования каждой БД по отдельности — единый процесс от создания и развёртывания до обновлений и оптимизации.

Мы реализовали этот подход в Deckhouse Kubernetes Platform. На вебинаре 3 апреля покажем, как он работает, и расскажем:

• что Cloud Native-подход меняет в управлении сервисами данных;

• как устроен DBaaS в Deckhouse: жизненный цикл БД и платформенные модули;

• как реализовать облачные принципы управления БД в закрытом контуре.

Регистрируйтесь и подключайтесь 3 апреля в 12:00 по Москве, если используете БД или хотите применить DBaaS-подход в своей инфраструктуре.

Я не программист, языков не знаю, я небольшой руководитель отдела в айти, неплохо знаю серверную архитектуру. Но у меня была простая боль: недавно завел для себя и родни сервер Hysteria 2, до этого было с VLESS на сервере и устал каждый раз руками править YAML, когда нужно:

добавить или удалить пользователя, выдать доступ, проверить статус, перезапустить сервис и при этом ничего не сломать

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

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

Почему не SSH?

Да, можно через SSH, nano и systemctl. Но когда делаешь это регулярно — растёт шанс ошибки.

Хотелось проще: открыть Telegram, нажать пару кнопок и выдать доступ без ручного редактирования config.yaml.

Веб-панель тоже рассматривал, но бот оказался быстрее и удобнее “на ходу”.

Что умел MVP

Минимум, который был нужен:

/status — жив ли сервис /users — список пользователей add / delete / enable / disable генерация hy2:// ссылки /logs — последние логи /restart — перезапуск с подтверждением

Звучит просто. Пока не думаешь о безопасности.

Главная проблема: бот ≠ root

Первая (и плохая) идея — дать боту полный доступ: пусть сам правит YAML, дергает systemctl и читает логи.

Это почти готовый root-доступ извне.

Я сделал иначе:

Бот — это интерфейс, не исполнитель.

Бот хранит данные (SQLite) Все опасные действия делает отдельный helper на сервере Helper: генерирует YAML делает backup валидирует только потом применяет и перезапускает

В sudoers разрешены только конкретные команды helper-а, а не shell.

Безопасность (без этого смысла нет)

Сделал максимально жёстко:

deny by default доступ только по Telegram user ID (не username) админ-команды только в личке в группах — никаких опасных действий delete/apply/restart — через подтверждение audit log: кто, когда и что сделал

Бот должен быть параноидальным, а не “удобным для всех”.

Грабли, на которые я наступил

1. Права на конфиг permission denied на /etc/hysteria/config.yaml — лечится не перезапуском, а нормальными правами.

2. Cert/key Один неправильный путь — сервис не стартует. Плюс легко сломать доступ к privkey.pem.

3. URI и userpass

hy2:// и hysteria2:// формат username:password спецсимволы нужно кодировать

Очень легко получить “почти рабочую” ссылку.

4. Клиенты На iOS импорт URI иногда работает хуже, чем ручной ввод.

5. OpenWrt + sing-box Сначала “не работает”, потом “работает, но не так”, и только после настройки DNS и роутинга — всё нормально.

Что получилось

Сейчас это нормальный админ-пульт:

управляю доступами из Telegram не трогаю YAML руками опасные действия подтверждаются и главное — нет полного root-доступа у бота

Удобство появилось без видимых дыры в безопасности.

Про LLM

Да, я использовал нейронку. Но это не “магическая кнопка”.

Без продуманной архитектуры (права, границы, apply, валидация, rollback) получилась бы просто опасная игрушка.

Что бы сделал иначе сразу делал бы helper-архитектуру добавил бы audit log с самого начала разделил бы read и write операции по правам сделал бы preflight-проверки перед apply

Что дальше

Планирую:

улучшить UX, возможно добавить лёгкую веб-панель, оставить Telegram, как быстрый пульт

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

P.S. Это моя первая статья, готов ко всем минусам, хейту и так далее. Единственная цель этого поста - рассказать о боте и дать его в народ

ссылка не репу https://github.com/Ramisya4ka/hysteria-bot-manager (внутри есть очень подробное Readme)

Один из треков ежегодной конференции GoCloud 9 апреля будет про приложения и разработку в облаке. Без воды, только то, с чем команды сталкиваются в реальных проектах: сборка сценариев, управление артефактами, безопасность приложений и монетизация через маркетплейс.

Вот что разберут в докладах:

• AI Assisted Cloud Workflow: автоматизация облачных сценариев в эпоху ИИ — поделимся инструментом, который убирает ручную склейку сервисов: просто берете готовый шаблон, а ИИ-ассистент помогает собрать все от архитектуры до бизнес-логики. Полезно тем, у кого нет выделенного архитектора на каждый проект.

• Артефакты в масштабе: история роста и эволюции Evolution Artifact Registry — как устроено централизованное хранилище артефактов, как оно дружит с Kubernetes и что анонсируют из новых функций в этом году. Полезно командам, у которых артефакты разбросаны по разным местам.

• Evolution Container Apps: платформа для платформ — как на базе одного сервиса поднять изолированные среды для разработки, тестирования и обучения. Разберут на примерах: от личного ноутбука до учебной платформы в стиле «Школы 21».

• Снижаем рутину в облаке: новые сценарии Гига-помощника — как ИИ-помощник теперь умеет разворачивать сразу несколько продуктов и настраивать мониторинг. Покажут живьем, без слайдов с обещаниями.

• Защита cloud native приложения: от GUI до ИИ — как атакуют контейнеры и где типичные дыры в Kubernetes. На практике покажут, как закрыть угрозы через Evolution Container Security за несколько кликов.

• От сервиса до экосистемы: как Маркетплейс Cloud.ru ускоряет путь продукта к клиенту — как устроен путь от первого релиза до выплат, сколько это стоит и сколько экономит. Будут реальные цифры и разбор типичных ошибок.

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

Регистрируйтесь и до встречи на GoCloud 2026! 

С помощью Stackland можно как настроить среду для разработки собственных сервисов, так и быстро внедрять облачные решения. Это готовая инфраструктура со встроенными управляемыми базами данных, контейнерным оркестратором, объектным хранилищем, а также инструментами для управления доступом к графическим ускорителям, которые помогут решать задачи инференса при разработке ИИ‑решений. Выдавать доступы к разработке можно гранулярно, используя встроенные средства безопасности.

Платформу можно развернуть на любых виртуальных, арендованных или собственных серверах, а также интегрировать с уже существующими корпоративными системами. Также она позволяет без дополнительной интеграции внедрять готовые сервисы Yandex Cloud, доступные по модели on‑premises. Сейчас в Stackland доступны инструмент для речевой аналитики Yandex SpeechSense и BI‑система Yandex DataLens, в ближайшее время появится ещё несколько решений, в том числе Yandex AI Studio для разработки ИИ‑приложений и агентов.

Подробнее о разработке опенсорс‑решения для бэкапов CloudNativePG в Stackland и предыстории платформы мы уже рассказывали в отдельной статье.

Для получения доступа к Yandex Cloud Stackland оставьте заявку.

Я мне нужен был инструмент, который показывает все сессии в виде дерева, но загружает их только когда я впервые перейдёте в одну из них.

Так родился lazy-tmux, написанный на Go. Ключевые фичи:

• Сохраняет текущую сессию, конкретную сессию или все сессии целиком. Снимки сохраняют окна, панели, layout, команды (например, npm, docker-compose, редакторы) и опционально scrollback историю шела.

• Ленивое восстановление: поднимается только выбранная сессия. RAM не расходуется на всё сразу.

• Интерактивный TUI браузер с деревом сессий, окон и панелей, таблицей с активными командами, временем последнего снимка, количеством окон/панелей и статусом сессии. Поддержка fuzzy search для быстрого поиска.

• Навигация и полное управление сессиями и окнами с клавиатуры в TUI браузере сессий.

• Гибкая сортировка сессий и окон через флаги --session-sort и --window-sort

• Можно заменить встроенный TUI на fzf, использую облегчённый бинарник.

• Автосейв через фоновый демон, периодически снимающий все сессии на диск.

• Восстановление при старте tmux для автоматизации workflow.

Проект ещё молодой, но буду рад любой помощи и идеям по улучшению: GitHub issues

За моими новостями можно следить в Telegram-канале

24 марта 2026 года репозиторий kubernetes/ingress-nginx переведён в архив и стал read-only.

Проект просуществовал более восьми лет, набрал 20 тысяч звёзд на GitHub и стал стандартом для HTTP-маршрутизации в Kubernetes. Теперь поддержка и разработка полностью прекращена: новых релизов, багфиксов и патчей безопасности не будет.

Причина архива: ресурс Ingress изначально был слишком ограничен. Весь расширенный функционал реализовали через vendor-специфичные аннотации, нормального RBAC не было, протоколы: только HTTP/HTTPS. Gateway API решает все эти проблемы на уровне спецификации.

Мейнтейнеры рекомендуют переходить на реализации Gateway API:

"If you are not already using ingress-nginx, you should not be deploying it as it is not being developed. Instead you should identify a Gateway API implementation and use it."

Источник

Актуальные варианты: NGINX Gateway Fabric, Cilium, Envoy Gateway, Istio, Traefik.

Что, если post-script не отработал? Моргнула сеть или случился таймаут. Внешний оркестратор просто пишет в лог failed и снимает задачу. А вот PostgreSQL об этом не знает. База остается в режиме бэкапа и начинает непрерывно копить WAL-файлы, ожидая команды на завершение.

Получается, что инструмент для защиты бизнеса от даунтайма, своими руками этот даунтайм и устроил.

Уметь дернуть pg_backup_start( ) — мало. Если СРК не имеет встроенного watchdog-механизма для сброса зависших сессий, резервное копирование превращается в угрозу доступности. Разделение ответственности — правильный архитектурный подход, но он означает, что защита базы от переполнения диска полностью ложится на ваши плечи.

О зависшем backup mode, разрывах PITR и других неудобных вопросах эксплуатации PostgreSQL совместно с Акурой поговорим в режиме live-демо на вебинаре 26 марта в 11:00 (МСК).

Регистрация по ссылке. Приносите в комментарии свои вопросы.

Хочу поделиться своим open-source проектом для мониторинга SIP-трафика — SIP-exporter. Это сервис, который использует eBPF для захвата пакетов прямо в ядре Linux и экспортирует метрики в Prometheus.

SIP-exporter — сервис, который захватывает SIP-пакеты (UDP/5060-5061) через eBPF socket filter, использует ringbuf для zero-copy передачи в userspace, парсит SIP в Go и экспортирует 40+ метрик в Prometheus, включает готовый дашборд для Grafana.

Архитектура: SIP Traffic → NIC → eBPF socket filter → ringbuf → Go poller → SIP parser → Prometheus

SIP-exporter экспортирует: активные SIP сессии (диалоги), SIP запросы по методам: INVITE, BYE, REGISTER, OPTIONS... SIP ответы по кодам: 1xx, 2xx, 4xx, 5xx, 6xx-, сессии.

• GitHub: https://github.com/aibudaevv/sip-exporter

• Docker Hub: https://hub.docker.com/r/frzq/sip-exporter

Мы разработали собственную IDP — Deckhouse Development Platform, которая уже доступна для внедрения. 26 марта покажем её демо и расскажем: 

• что вообще такое IDP и когда она будет полезна; 

• на какие DORA-метрики влияет внутренняя платформа разработки;

• для каких сценариев подойдёт Deckhouse Development Platform.

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

Вокруг бэкапа PostgreSQL легко создать иллюзию, что все уже решено. Достаточно добавить в текст WAL, PITR, пару слов про консистентность и назвать агент «умным». Проблема в том, что в проде такие формулировки мало что гарантируют.

Можно ли вообще считать решение PostgreSQL-aware, если оно не живет внутри логики самой СУБД? Где проходит граница между нативными механизмами PostgreSQL и внешней платформой? Что происходит, если не доехал WAL-сегмент, не завершился post-script или восстанавливать нужно не весь инстанс, а один объект?

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

План такой:

• отдельно пройтись по WAL, PITR и консистентности;

• обсудить, где файловый агент уместен, а где уже нет;

• разобрать сценарии с ошибками pre/post-скриптов;

• поговорить про восстановление в безопасную локацию и ручной recovery;

• отдельно затронуть вопрос масштаба: почему на двух базах хватает shell-скриптов, а на пятидесяти уже начинается совсем другая жизнь.

26 марта 2026, 11:00 (МСК) Регистрация по ссылке. Приносите в комментарии вопросы, которые особенно хочется поднять в эфире.

Infrastructure as Code в компаниях нередко развивается стихийно: Terraform-скрипты копятся годами, репозитории разбросаны по командам, стандарты не зафиксированы. В результате инфраструктура остаётся сложной для понимания и управления.

Модель BSA (Base, Service, Application) помогает навести порядок: структурировать код, распределить ответственность и сделать процессы поставки предсказуемыми. На совместном вебинаре «Экспресс 42» и «Магнит OMNI» расскажем, как это работает на практике.

Вы узнаете:

• как работает трёхуровневая модель BSA и как она распределяет зоны ответственности;

• как устранить «функциональные колодцы» между DevOps-командами и инфраструктурными инженерами;

• какие результаты дало внедрение BSA в «Магнит OMNI» и с чего начать в своей компании.

Регистрируйтесь по ссылке и подключайтесь 13 марта в 12:00, если вы управляете инфраструктурным кодом, развиваете платформенные сервисы или отвечаете за процессы поставки.

Сегодня мы открываем доступ к Monium — платформе для мониторинга и анализа работы IТ‑систем. Новое решение собирает и анализирует большое количество телеметрических данных, в том числе логов, трейсов и метрик в едином интерфейсе, а также позволяет визуализировать их в виде дашбордов. С помощью Monium можно следить за работой сервисов, приложений, а также ИИ‑агентов — независимо от того, где они находятся: в облаке или на ваших собственных серверах (on‑premises).

Изначально observability‑платформа была разработана командой Yandex Infrastructure для обеспечения стабильной работы внутренних сервисов компании. Сейчас с Monium ежедневно работают 16 тысяч сотрудников Яндекса, платформа обрабатывает 50 гигабайт логов в секунду. При возникновении проблем ответственным дежурным отправляются автоматические уведомления через различные каналы: мессенджеры, почту, звонки и другие системы.

Monium использует современные механизмы аутентификации и авторизации, а данные о пользователях на платформе шифруются. Платформа соответствует требованиям международных и российских стандартов безопасности, в том числе ISO, PCI DSS и ГОСТ Р 57580.

Yandex Monium находится в общем доступе — зайти и оценить фичи платформы можно из облачной консоли.

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

В новом выпуске к нам в гости заглянул Антон Егорушков — DevOps-эксперт и автор канала сыча. Вместе с Алексеем Костюковым, DevOps Lead в MWS, и Ариной Зайцевой, Senior DevOps в MWS, поговорили про то, как все меняется в профессии сейчас и что будет в будущем.

Обсудили:

• что мотивирует в работе и профессии,

• использование ИИ в рабочих задачах, 

• варианты реализации IaC и EaC,

• как лучше размещать инфраструктуру: on-prem, hybrid, one-cloud или multi-cloud,

• каких изменений в DevOPS ожидать в ближайшие пару лет.

Смотрите и слушайте на удобной площадке: в VK Видео или на YouTube. 

Если было интересно — вступайте в сообщество МТС True Tech, чтобы быть в курсе лучших практик в ИТ.

Прошу помощи. Не могу найти документацию на плату. Купил когда-то на а**-э*****сс, но к ней не было в комплекте вообще ничего. За время поисков удалось найти только два фрагмента схемы. Мб есть у кого такая....

DevSecOps — это подход, при котором безопасность перестает быть отдельным этапом перед релизом и становится частью всего жизненного цикла продукта. Проверки уязвимостей, контроль зависимостей и анализ конфигураций встраиваются прямо в CI/CD-пайплайн — команда получает обратную связь сразу, а не после деплоя в продакшн.

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

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

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

У нас есть готовое решение для такого случая. На вебинаре 27 февраля мы расскажем о Deckhouse Code — единой платформе для непрерывной разработки и управления жизненным циклом ПО:

• Покажем, как настроить правила слияния, CODEOWNERS, push rules и безопасно хранить секреты вне платформы.

• Обсудим, как сократить нагрузку на команды за счёт managed-подхода.

• Проведём живое демо от коммита в консоли до артефакта в registry.

Регистрируйтесь и подключайтесь, если вы отвечаете за CI/CD в корпоративной среде. Автор лучшего вопроса в чате вебинара получит персональное демо под свою задачу.

Что умеет:

• Все 7 фигур с wall kick при повороте

• Превью следующей фигуры

• Очки, линии, уровень

• Скорость растёт с уровнем

• Рекорд за сессию

• Пауза, рестарт на ходу, экран game over

• Центрируется в окне терминала

Видео геймплея
GitHub

Установка:

curl -sSL https://raw.githubusercontent.com/oakulikov/tetris/main/install.sh | bash

На Windows: открыть WSL/Ubuntu терминал и выполнить ту же команду.
Потом просто tetris.

Периодически Redis падает по OOM.

Интересно послушать разные мнение , на что стоит обратить внимание. Есть решение , почему происходит OOM .

Буду очень признателен комментарию . 🤝

Можете ставить на свои VPS-ки одной командой: 

curl -sSL https://raw.githubusercontent.com/itcaat/mtproto-installer/main/install.sh | bash

Исходники тут: https://github.com/itcaat/mtproto-installer

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

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

Что делать в такой ситуации? Самый эффективный путь — не дать дефекту шанса появиться в коде. Именно эту задачу решает политика нулевой терпимости к ошибкам.

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

В статье обсудим, что такое политика нулевой терпимости и то, как статический анализ и ASOC помогут её достичь.

cli-stash - tui-тулза для добавления терминальных команд в избранное, с возможностью переноса из истории

Кейсы использования такие:

1. Вы хотите параметр заменить на какое то ключевое слово. Например, я хочу в избранное добавить команду dig для определения NS серверов, которые отдает нам 1.1.1.1. Я не хочу видеть захаркорженные значения. И чтобы было красиво меняю их просто на ключевые слова. Это дает больше эстетического удовольствия при использовании команды - не более.
   Ну и в будущем я подвезу автосинк с шарингом на команду, так что может быть полезно.

2. Да просто надо поменять команду - почему бы не дать такую возможность =)

Кстати, тут вопрошали сколько 🌟 наберет тулза в github - пока всего 37. Ну а что это за инструмент и чем он может быть полезен можно подробнее прочитать в предыдущем посте.

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Она решает простую боль: сложные команды (docker, kubectl, ffmpeg) постоянно забываются, а копаться в history каждый раз это страдание.

Что умеет:

• Сохраняет ваши команды в избранном

• Возможность добавить из истории шелла

• Нечеткий поиск

• Сортировка по частоте использования
  

И самое крутое, что команда вставляется прямо в терминал. Таким образом вам не надо ничего копипастить: нашел → выбрал → enter → команда уже в cli.

# Установка в Linux
go install github.com/itcaat/cli-stash@latest

# Сборка из исходников
git clone https://github.com/itcaat/cli-stash.git
cd cli-stash
go build -o cli-stash .
sudo mv cli-stash /usr/local/bin/

В macOS поставить изян brew install itcaat/tap/cli-stash

Исходники и инструкция по использованию есть на github.

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Периодически в разные частях документации или статьях про Docker вы будете встречать "манифесты". Обычно это звучит как что-то второстепенное: мол, есть какая-то мета-информация, по которой Docker собирает образ из слоёв.

Но на деле это одна из ключевых деталей, которая отвечает за то, что контейнеры:

• воспроизводимы

• одинаковые на разных машинах

• и не превращаются в "ну у меня работало".

Я попытаюсь все описать максимально просто.

Docker Manifest - это JSON-документ, который описывает образ. Можно представить его как схему или инструкцию, по которой Docker понимает:

• какие слои относятся к образу

• какие контрольные суммы должны быть у каждого слоя

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

• для какой ОС и архитектуры этот образ подходит

И важный момент: когда ты делаешь docker pull, Docker сначала получает манифест, а уже потом начинает скачивать слои.

Как посмотреть манифест самому: docker manifest inspect nginx:latest.

Тут можно заметить, что один тег (nginx:latest) может ссылаться сразу на несколько вариантов образа - например под amd64 и arm64. Это как раз история про multi-arch. Иногда под словом manifest имеют в виду не сам образ, а manifest list (index). Это как меню: Docker смотрит на твою платформу и выбирает подходящий вариант (amd64/arm64).

Каждый слой Docker-образа имеет SHA256-хеш, который вычисляется из его содержимого.

Логика максимально простая:

• поменялся файл

• поменялось содержимое

• поменялся хеш

• значит получился другой слой

По сути это очень похоже на философию Git: всё завязано на содержимое, а не на "имя файла".

Docker Registry использует Content Addressable Storage - то есть хранит и раздаёт данные не по названию, а по их хешам.

Что происходит при push / pull?

Если упростить до понятной схемы, то процесс примерно такой:

• клиент сначала отправляет/получает манифест

• registry проверяет хеши и наличие слоёв

• передаются только те слои, которых ещё нет

• каждый слой проверяется по SHA256

То есть никакой лишней передачи данных и никаких "примерно совпало".

Комбинация манифестов и хешей даёт сразу несколько сильных преимуществ:

• Безопасность - слой нельзя незаметно подменить

• Экономия места - одинаковые слои не хранятся по сто раз

• Целостность - скачанное гарантированно равно загруженному

• Версионирование - образ это конкретная комбинация слоёв, а не “что-то похожее”

Именно поэтому условный nginx:latest на dev и на prod - это реально один и тот же образ, а не "почти такой же, но чуть другой". Ладно, давайте будем более дотошными. На самом деле нет - использовать latest плохая практика. За время пока образ приехал,- там уже могут быть разные образы.

Как минимум используйте конкретный тег, а еще лучше даже sha256 docker pull nginx@sha256:...

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Речь про vi...😱 

Как выйти из vi? Никак. Это не редактор, это пожизненный контракт.

Я открыл vi один раз в 2009 году. С тех пор у меня один и тот же терминал, потому что я всё ещё пытаюсь выйти.

Если ты случайно запустил vi на проде — проще выкинуть сервер, чем найти правильную комбинацию клавиш.

Это тот самый редактор, который в обычной жизни можно спокойно не трогать годами… А потом ты оказываешься в air-gap, где:

• нет vscode

• нет nano

• нет mc

• иногда даже less нет и кажется, что у тебя есть только vi и судьба

И вот ты открываешь конфиг… и мозг такой: эээээ мы не умеем, всё, до свидания.

Давай разберёмся, как перестать бояться vi и научиться выживать с ним спокойно.

Почему vi вызывает ступор? Потому что он не работает как обычные редакторы. Ты нажимаешь клавиши - а текст не печатается. Пытаешься выйти - не выходит. И где-то рядом уже открывается вкладка “как выйти из vi”, но интернет… в другой реальности.

Главное, что нужно понять - в vi есть несколько режимов:

1. Normal mode - это режим команд и перемещения. Тут ты не печатаешь текст, а управляешь редактором.

2. Insert mode - это режим, где можно реально редактировать и вводить текст.

3. Command mode (через :) - cохранение, выход, всякие служебные команды и тд

Минимальный набор клавиш, чтобы выжить:

• Войти в редактирование -> i, a, o

• Вернуться обратно в команды -> Esc

• Сохранить файл -> :w

• Выйти -> :q

• Сохранить и выйти -> :wq

• Выйти без сохранения -> :q!

Полезные команды, которые реально пригодятся:

• удалить строку -> dd

• вставить строку ниже -> o

• отменить действие -> u

• повторить последнее действие -> .

• поиск: / и дальше текст который ищем

Пример: быстро поправить конфиг и уйти живым

vi /etc/hostname

Дальше всё по шагам:

1. нажми i и внеси правки

2. нажми Esc

3. введи :wq

4. готово - конфиг сохранён, ты победил

А если ты хочешь владеть vi как ниндзя, то вот тебе Vim Cheat Sheet https://vim.rtorr.com/

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩

Наверняка знакомо ощущение: смотришь логи через tail -f, делаешь какое-то действие - рестарт сервиса, деплой, правку конфига - и потом пытаешься глазами понять, где закончился старый вывод и началось новое. Спойлер: это не всегда просто.

Для таких случаев существует крошечная, но очень полезная утилита
spacer: https://github.com/samwho/spacer

Она вставляет визуальные разделители прямо в поток вывода и отлично работает в реальном времени. Без магии, без лишних настроек - просто аккуратно отделяет "было" от "стало".

В итоге это неожиданно удобно:

• при отладке,

• при сопровождении сервисов,

• при поиске изменений в логах после конкретных действий.

Отдельный плюс - минимализм. Никаких зависимостей, ничего лишнего: скачал, поставил, используешь. Именно тот случай, когда инструмент делает ровно одну вещь - и делает её хорошо.

_________________

Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩