Покажем Internal Development Platform от Deckhouse на вебинаре 26 марта
Внутренние платформы разработки позволяют командам перейти от разрозненного набора инструментов к сервисному подходу. Разработчики получают self-service доступ ко всему необходимому — от создания окружений до управления quality gates и релизами — и могут работать автономно, не привлекая DevOps-команду.
Мы разработали собственную IDP — Deckhouse Development Platform, которая уже доступна для внедрения. 26 марта покажем её демо и расскажем:
что вообще такое IDP и когда она будет полезна;
на какие DORA-метрики влияет внутренняя платформа разработки;
для каких сценариев подойдёт Deckhouse Development Platform.
Регистрируйтесь и подключайтесь, если вы отвечаете за зрелость процессов разработки, масштабирование команд или платформенные сервисы.
Неудобные вопросы про бэкап PostgreSQL: открытый разбор на вебинаре
Вокруг бэкапа PostgreSQL легко создать иллюзию, что все уже решено. Достаточно добавить в текст WAL, PITR, пару слов про консистентность и назвать агент «умным». Проблема в том, что в проде такие формулировки мало что гарантируют.
Можно ли вообще считать решение PostgreSQL-aware, если оно не живет внутри логики самой СУБД? Где проходит граница между нативными механизмами PostgreSQL и внешней платформой? Что происходит, если не доехал WAL-сегмент, не завершился post-script или восстанавливать нужно не весь инстанс, а один объект?
Из таких вопросов и вырос отдельный вебинар про PostgreSQL в Акуре, в формате открытого инженерного разбора: что здесь должна делать сама СУБД, что имеет смысл выносить во внешний слой, где начинаются реальные эксплуатационные проблемы и какие ограничения в таком подходе нельзя замалчивать.
План такой:
отдельно пройтись по WAL, PITR и консистентности;
обсудить, где файловый агент уместен, а где уже нет;
разобрать сценарии с ошибками pre/post-скриптов;
поговорить про восстановление в безопасную локацию и ручной recovery;
отдельно затронуть вопрос масштаба: почему на двух базах хватает shell-скриптов, а на пятидесяти уже начинается совсем другая жизнь.
26 марта 2026, 11:00 (МСК) Регистрация по ссылке. Приносите в комментарии вопросы, которые особенно хочется поднять в эфире.
Разделяй и властвуй: вебинар про BSA-модель для IaC и опыт её применения «Магнит OMNI»
Infrastructure as Code в компаниях нередко развивается стихийно: Terraform-скрипты копятся годами, репозитории разбросаны по командам, стандарты не зафиксированы. В результате инфраструктура остаётся сложной для понимания и управления.
Модель BSA (Base, Service, Application) помогает навести порядок: структурировать код, распределить ответственность и сделать процессы поставки предсказуемыми. На совместном вебинаре «Экспресс 42» и «Магнит OMNI» расскажем, как это работает на практике.
Вы узнаете:
как работает трёхуровневая модель BSA и как она распределяет зоны ответственности;
как устранить «функциональные колодцы» между DevOps-командами и инфраструктурными инженерами;
какие результаты дало внедрение BSA в «Магнит OMNI» и с чего начать в своей компании.
Регистрируйтесь по ссылке и подключайтесь 13 марта в 12:00, если вы управляете инфраструктурным кодом, развиваете платформенные сервисы или отвечаете за процессы поставки.
Запустили Yandex Monium — observability‑платформу собственной разработки
Сегодня мы открываем доступ к Monium — платформе для мониторинга и анализа работы IТ‑систем. Новое решение собирает и анализирует большое количество телеметрических данных, в том числе логов, трейсов и метрик в едином интерфейсе, а также позволяет визуализировать их в виде дашбордов. С помощью Monium можно следить за работой сервисов, приложений, а также ИИ‑агентов — независимо от того, где они находятся: в облаке или на ваших собственных серверах (on‑premises).
Изначально observability‑платформа была разработана командой Yandex Infrastructure для обеспечения стабильной работы внутренних сервисов компании. Сейчас с Monium ежедневно работают 16 тысяч сотрудников Яндекса, платформа обрабатывает 50 гигабайт логов в секунду. При возникновении проблем ответственным дежурным отправляются автоматические уведомления через различные каналы: мессенджеры, почту, звонки и другие системы.
Monium использует современные механизмы аутентификации и авторизации, а данные о пользователях на платформе шифруются. Платформа соответствует требованиям международных и российских стандартов безопасности, в том числе ISO, PCI DSS и ГОСТ Р 57580.
Yandex Monium находится в общем доступе — зайти и оценить фичи платформы можно из облачной консоли.
Как сейчас живется DevOps в разных компаниях и что будет дальше? Обсудили в новом выпуске подкаста МТС True Tech Talks 🎧
Это подкаст, где мы говорим о технологиях и людях, которые их создают. А еще разбираем новости и тренды, обсуждаем личный опыт и карьерные нюансы в ИТ.
В новом выпуске к нам в гости заглянул Антон Егорушков — DevOps-эксперт и автор канала сыча. Вместе с Алексеем Костюковым, DevOps Lead в MWS, и Ариной Зайцевой, Senior DevOps в MWS, поговорили про то, как все меняется в профессии сейчас и что будет в будущем.
Обсудили:
что мотивирует в работе и профессии,
использование ИИ в рабочих задачах,
варианты реализации IaC и EaC,
как лучше размещать инфраструктуру: on-prem, hybrid, one-cloud или multi-cloud,
каких изменений в DevOPS ожидать в ближайшие пару лет.
Прошу помощи. Не могу найти документацию на плату. Купил когда-то на а**-э*****сс, но к ней не было в комплекте вообще ничего. За время поисков удалось найти только два фрагмента схемы. Мб есть у кого такая....
DevSecOps: как встроить безопасность в разработку и не тормозить релизы
DevSecOps — это подход, при котором безопасность перестает быть отдельным этапом перед релизом и становится частью всего жизненного цикла продукта. Проверки уязвимостей, контроль зависимостей и анализ конфигураций встраиваются прямо в CI/CD-пайплайн — команда получает обратную связь сразу, а не после деплоя в продакшн.
Чем раньше находишь проблему, тем дешевле ее исправить. Поэтому DevSecOps особенно актуален для облачных и микросервисных архитектур, где ручной контроль уже не справляется со скоростью изменений.
Подробнее о принципах DevSecOps, инструментах для каждого этапа разработки и пошаговом плане внедрения читайте на сайте Рег.облака.
Где хранить код и как настроить CI/CD, если GitLab CE уже не хватает
Иногда возможностей бесплатного GitLab уже недостаточно, при этом платная версия по понятным причинам недоступна. Собственные форки требуют постоянной возни с обновлениями и закрытием CVE, а написание своей системы — больших затрат ресурсов.
У нас есть готовое решение для такого случая. На вебинаре 27 февраля мы расскажем о Deckhouse Code — единой платформе для непрерывной разработки и управления жизненным циклом ПО:
Покажем, как настроить правила слияния, CODEOWNERS, push rules и безопасно хранить секреты вне платформы.
Обсудим, как сократить нагрузку на команды за счёт managed-подхода.
Проведём живое демо от коммита в консоли до артефакта в registry.
Регистрируйтесь и подключайтесь, если вы отвечаете за CI/CD в корпоративной среде. Автор лучшего вопроса в чате вебинара получит персональное демо под свою задачу.
Ребята, в свете блокировок Telegram я накидал bash-скрипт который сделает всю магию и поднимет вам прокси за пару минут. На выходе получите адрес прокси и сразу им поделиться с друзьями...
Статический анализ и ASOC: нулевая терпимость к ошибкам в проекте
В современной разработке цена обнаруженной после релиза уязвимости катастрофически высока: дефект, приводящий к утечке данных, или критический сбой в системе — это большой удар по репутации и бюджету. И в отношении таких дефектов традиционный подход "найди и исправь" часто не работает — он слишком медленный, дорогой и ненадёжный.
Что делать в такой ситуации? Самый эффективный путь — не дать дефекту шанса появиться в коде. Именно эту задачу решает политика нулевой терпимости к ошибкам.
Причём внедрение такой политики не заканчивается на установке новых инструментов. Безопасность должна стать неотъемлемой части процесса разработки, а не проверяться постфактум. Такой подход позволяет не просто выявлять уязвимости, а предотвращать их попадание в основную ветку.
В статье обсудим, что такое политика нулевой терпимости и то, как статический анализ и ASOC помогут её достичь.
Только что я релизнул cli-stashv0.2.9. Теперь можно редактировать сохраненную команду.
cli-stash - tui-тулза для добавления терминальных команд в избранное, с возможностью переноса из истории
Кейсы использования такие:
Вы хотите параметр заменить на какое то ключевое слово. Например, я хочу в избранное добавить команду dig для определения NS серверов, которые отдает нам 1.1.1.1. Я не хочу видеть захаркорженные значения. И чтобы было красиво меняю их просто на ключевые слова. Это дает больше эстетического удовольствия при использовании команды - не более. Ну и в будущем я подвезу автосинк с шарингом на команду, так что может быть полезно.
Да просто надо поменять команду - почему бы не дать такую возможность =)
Пример редактирования
Кстати, тут вопрошали сколько 🌟 наберет тулза в github - пока всего 37. Ну а что это за инструмент и чем он может быть полезен можно подробнее прочитать в предыдущем посте.
_________________
Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩
Ребята, я сегодня релизнул cli-stash. Это TUI-утилита на Go + Bubble Tea для сохранения shell-команд в "избранном".
Пример использования cli-stash
Она решает простую боль: сложные команды (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 собирает образ из слоёв.
Но на деле это одна из ключевых деталей, которая отвечает за то, что контейнеры:
воспроизводимы
одинаковые на разных машинах
и не превращаются в "ну у меня работало".
Я попытаюсь все описать максимально просто.
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 есть несколько режимов:
Normal mode - это режим команд и перемещения. Тут ты не печатаешь текст, а управляешь редактором.
Insert mode - это режим, где можно реально редактировать и вводить текст.
Command mode (через :) - cохранение, выход, всякие служебные команды и тд
Минимальный набор клавиш, чтобы выжить:
Войти в редактирование -> i, a, o
Вернуться обратно в команды -> Esc
Сохранить файл -> :w
Выйти -> :q
Сохранить и выйти -> :wq
Выйти без сохранения -> :q!
Полезные команды, которые реально пригодятся:
удалить строку -> dd
вставить строку ниже -> o
отменить действие -> u
повторить последнее действие -> .
поиск: / и дальше текст который ищем
Пример: быстро поправить конфиг и уйти живым
vi /etc/hostname
Дальше всё по шагам:
нажми i и внеси правки
нажми Esc
введи :wq
готово - конфиг сохранён, ты победил
А если ты хочешь владеть vi как ниндзя, то вот тебе Vim Cheat Sheet https://vim.rtorr.com/
_________________
Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩
Иногда самые полезные вещи - это вовсе не большие системы и не новые фреймворки, а маленькие утилиты, которые внезапно делают жизнь проще. На днях вспомнил про одну такую находку и решил поделиться.
Наверняка знакомо ощущение: смотришь логи через tail -f, делаешь какое-то действие - рестарт сервиса, деплой, правку конфига - и потом пытаешься глазами понять, где закончился старый вывод и началось новое. Спойлер: это не всегда просто.
Она вставляет визуальные разделители прямо в поток вывода и отлично работает в реальном времени. Без магии, без лишних настроек - просто аккуратно отделяет "было" от "стало".
В итоге это неожиданно удобно:
при отладке,
при сопровождении сервисов,
при поиске изменений в логах после конкретных действий.
Отдельный плюс - минимализм. Никаких зависимостей, ничего лишнего: скачал, поставил, используешь. Именно тот случай, когда инструмент делает ровно одну вещь - и делает её хорошо.
_________________
Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩
Чем дольше я работаю с инфраструктурой, тем чаще ловлю себя на мысли: главный навык здесь - не конкретный инструмент и даже не стек, а способность заставить что-то работать в самых странных условиях.
Ответ неожиданно нашёлся в одном месте - canitrundoom.org. Это не сайт и не галерея, а настоящий музей инженерного безумия, где люди снова и снова доказывают, что если есть процессор и немного упрямства, то DOOM запустится.
В коллекции устройства, которые точно не проходили ревью на "игровую платформу": - офисная техника, - измерительное оборудование, - городские экраны, - железо, побывавшее в космосе
Смотришь на всё это и вдруг понимаешь: пределы возможностей куда дальше, чем кажется. Если DOOM смог заработать там, где для этого не было ни интерфейсов, ни смысла - то уж доставить очередной говнокод в прод - вообще же плевое дело.
Очень рекомендую заглянуть и дать мозгу немного свободы.
_________________
Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩
“Наши руки не для скуки” (с). Я давно хотел накидать скрипт для супер быстрой диагностики Linux. Конечно, это не замена полноценному мониторингу. Это дополнительный инструмент, который вы можете использовать в своем арсенале чтобы упростить себе жизнь. Самое главное что он сэкономит кучу времени.
В отчете вы получите:
Системную информацию - версия ОС, ядро, архитектура, uptime, внешний IP
Аппаратные ресурсы - CPU, RAM, Swap, температура процессоров
Дисковое пространство - занятое место, inodes, SMART статус
Тест скорости дисков - скорость записи/чтения (100MB тест)
Сетевые интерфейсы - статус, ошибки, активные соединения
Тест сети - ping до шлюза, ya.ru и 8.8.8.8 (по 10 пакетов каждый), скорость интернета
Пример запуска (можно без sudo - но там не будет всех показателей):
curl -o ~/linux-diag-script.sh https://gist.githubusercontent.com/itcaat/45edeaf15f2d508bee766daa9a97400c/raw/linux-diag-script.sh
chmod +x ./linux-diag-script.sh
sudo ./linux-diag-script.sh
# Одной командой
curl https://gist.githubusercontent.com/itcaat/45edeaf15f2d508bee766daa9a97400c/raw/linux-diag-script.sh | sudo bash
Бонусом в скрипте встроена возможность получать Telegram уведомления и сам отчет при обнаружении проблем. Для этого надо создать бота и добавить в выполнение скрипта в cron.
Теперь можешь добавить в cron (подставь свой botToken и chatId) и будешь получать уведомление в telegram если будет обнаружена какая то проблема.
# Проверка каждые 6 часов
0 */6 * * * root TELEGRAM_BOT_TOKEN="your_token" TELEGRAM_CHAT_ID="your_chat_id" /usr/local/bin/linux-diag-script.sh >/dev/null 2>&1
Актуальная версия скрипты доступна на GitHub Gist. Вы можете модифицировать его под свои нужды, добавлять новые проверки или как то интегрировать в runbook-и.
Пишите что еще можно добавить - я добавлю.
---
Хватит читать DevOps-статьи от людей без продакшена. Я рассказываю про свой реальный опыт в своем Telegram-канале DevOps Brain 🧠 ↩
Скрытые уязвимости в CI/CD: что мы упускаем и как защитить процесс доставки
CI/CD давно перестал быть просто удобным способом ускорить релизы. Сегодня это критическая часть цепочки поставки, через которую проходит весь код, зависимости и инфраструктурные изменения. Именно поэтому пайплайн всё чаще становится целью атак, при этом многие уязвимости остаются незаметными годами.
Одна из самых недооценённых проблем — избыточные права. Токены доступа, используемые в пайплайнах, часто имеют больше разрешений, чем требуется для конкретного шага. Компрометация такого токена даёт атакующему доступ не только к репозиторию, но и к облачной инфраструктуре, артефактам и секретам.
Вторая зона риска — зависимости и сторонние экшены. Автоматизация строится на готовых шагах и шаблонах, которые редко проходят полноценный аудит. Обновление популярного экшена или контейнерного образа может незаметно внести вредоносный код в процесс сборки, и он будет исполняться с доверенными правами.
Отдельного внимания заслуживает хранение секретов. Даже при использовании секретных хранилищ они нередко утекaют в логи, артефакты или кэши. Проблема усугубляется тем, что логи CI часто доступны большему кругу людей, чем production-системы.
Неочевидная, но опасная категория уязвимостей — доверие к окружению сборки. Самохостинг раннеров без изоляции, повторное использование виртуальных машин и отсутствие очистки после джобов позволяют атакующему закрепиться в системе и влиять на последующие сборки.
Защита CI/CD начинается с принципа минимальных привилегий. Каждый токен, сервисный аккаунт и ключ должен иметь строго ограниченный набор прав и короткий срок жизни. Второй шаг — контроль цепочки зависимостей: фиксация версий, проверка хэшей, собственные зеркала и регулярный аудит используемых экшенов и образов.
Важно также относиться к пайплайну как к коду: проводить ревью изменений, логировать подозрительные действия и мониторить аномалии. Изоляция окружений, одноразовые раннеры и автоматическая ротация секретов значительно снижают потенциальный ущерб от атаки.
CI/CD — это не просто автоматизация, а часть поверхности атаки. Чем раньше это осознаётся, тем меньше шансов, что уязвимость проявится уже после успешного релиза.
А какие риски в своих пайплайнах вы обнаружили только со временем?
