Когда запросы к LLM приходят лишь несколько раз в день, GPU большую часть времени простаивает, но платить за ноду приходится круглосуточно. Хочется освобождать карту между запросами: удалять поды с моделью, когда нагрузки нет, и запускать их снова, когда она появляется. Для обычного веб-приложения такая схема работает с задержкой в несколько секунд, и это вполне допустимо. LLM же после запуска пода нужно загрузить веса и прогреть движок, поэтому первый запрос может ждать ответа несколько минут.

В июле команда H Company рассказала, что новая реплика их крупнейших моделей выходила в готовность до 27 минут. Команда использует vLLM на GPU-нодах Kubernetes и добавляет реплики по мере роста нагрузки от агентов. Автоскейлер быстро увеличивает число подов, но дальше начинаются скачивание образа, загрузка весов, компиляция и прогрев движка. Ускорить эти этапы настройками масштабирования не получится.

Я ожидал, что большую часть времени занимает загрузка весов, и решил посмотреть публичные замеры. У Tensorfuse запуск Llama 3.1 8B на L40S занял 294 секунды, из которых на скачивание модели и перенос весов в GPU ушло только 94. Остальные 200 секунд потребовались на компиляцию, захват CUDA graphs, инициализацию движка и импорты. Значительную часть этой работы новый под повторяет при каждом старте, хотя её результаты можно сохранить на ноде.

В статье разберём, как настроить запуск LLM из нуля и сократить холодный старт: откуда KEDA получает сигнал о нагрузке, пока подов нет, что стоит заранее закэшировать и какие таймауты позволят первому запросу дождаться модели. На публичных замерах посмотрим, сколько времени дают эти оптимизации, а затем перейдём к манифестам KEDA HTTP Add-on, DaemonSet для предзагрузки и настройкам vLLM. Это поможет платформенным инженерам оценить, подходит ли такой режим их нагрузке или лучше оставить тёплую реплику.

При создании кейса на в моем тренажере, который я рассказывал ранее, возникло следующее: добавление пустой колонки выглядит безобидной миграцией: переписывать данные не нужно. Но такой ALTER TABLE может остановить новые чтения таблицы ещё до изменения её структуры. Достаточно старой транзакции, которую забыли завершить. Поясню эту цепочку на отдельном PostgreSQL 17.11 с таблицей orders из одной строки.

Сначала первая сессия выполняет BEGIN и SELECT id FROM orders, после чего остаётся открытой. Сам запрос уже завершён, но транзакция продолжает держать AccessShareLock. Это не мешает другому обычному SELECT: такие блокировки совместимы. Проверка до запуска миграции возвращает строку без ожидания старой транзакции.

Затем вторая сессия запускает ALTER TABLE orders ADD COLUMN note text. Для этого изменения нужна AccessExclusiveLock, несовместимая с блокировкой первой сессии. Миграция встаёт в очередь. Если теперь третья сессия выполнит SELECT id FROM orders, она тоже будет ждать. Её AccessShareLock совместима с уже выданной блокировкой первой сессии, однако впереди стоит запрос миграции на исключительный доступ.

На снимке консоли видна вся цепочка. Сессия old_tx находится в состоянии idle in transaction и держит выданную блокировку: granted = t. У migration блокировка ещё не выдана, а blocked_by указывает на old_tx. Новый запрос api также имеет granted = f, но его blocked_by указывает уже на migration. Таким образом, источник ожидания и непосредственный блокировщик запроса — разные сессии. После ROLLBACK в old_tx миграция завершается, а новый SELECT получает результат.

IBM Cost of a Data Breach 2024 оценивает среднюю стоимость утечки в 4.88 млн долларов. В России штрафы за утечку персональных данных переведены в оборотную модель (ст. 13.11 КоАП в редакции 420-ФЗ).

Илья Чиркин, обучивший ИИ более 300 человек, формулирует барьер так: “Сразу надо определить, какие данные можно отдавать ИИ, а какие нет”.

Локальный контур снимает сам вопрос: данные не покидают периметр. Ниже — архитектура, честная экономика и границы применимости.

Привет, Хабр! Меня зовут Данил, я работаю системным инженером в Selectel и в свободное время потихоньку развиваю свою лабораторию. Мне нравятся маломощные и компактные устройства, но проблема заключается в том, что не все рабочие инструменты доступны на таком железе. 

Я решил погрузиться в вопрос и начал изучать решения, но концепция удаленного доступа к ПК мне не понравилась. Разные операционные системы и платформы сильно ограничивают в выборе привычных инструментов, а быстро подправить код бывает нужно здесь и сейчас. Поэтому я решил развернуть собственный code-server на персональном домене и с готовым SSL-сертификатом.

Пайплайн зелёный, а релиз не состоялся. Образ на всех этапах один и тот же, но это не точно. Отдельные хуки и скрипты вместо единого конвейера .gitlab-ci.yml. Привычный CI/CD с GitOps перестаёт существовать.

В статье расскажу, когда для восстановления связи CI и CD подойдёт простая автоматизация, а когда нужен серьёзный инструмент, покажу, как работают разные решения, как выбрать лучшее и не напороться на грабли (я собрал их за вас).

Так было с 14 сентября по 1 октября, а потом ещё раз 5 октября. Причины разные, результат один: тишина. Ниже оба сбоя с конфигами, кодом и тем, что мы поменяли.

В статье — вариант реализации стандарта OAuth 2.0 (RFC 6749).
Цель схемы «Dual JWT» — минимизировать потребление ресурсов инфраструктуры при сохранении достаточно высокого (но не максимального) уровня безопасности. Разберём, как устроена схема аутентификации, параметры её безопасности, а также экономику решения: за счёт чего схема снижает затраты (FinOps).
Суть схемы: access в заголовке + refresh в cookie, оба — stateless-JWT, плюс deny list в Redis для отзыва сессий.

Клиенты пишут в бота MAX, операторы отвечают из Chatwoot на своём сервере, а между ними мост на Python. По дороге выяснилось, что Chatwoot не шлёт вебхуки во внутреннюю сеть, API MAX работает на сертификате Минцифры, а один и тот же ответ норовит уйти клиенту дважды. Ниже о том, как устроен мост и какие решения пришлось принять.

Kubernetes в проде держат 80% организаций по опросу CNCF за 2024 год, против 66% годом раньше. В России адопшн ниже, но того же порядка: около 60% крупных компаний используют Kubernetes. Спор об управлении кластером в облаке обычно сводится к интерфейсу: консоль или CLI вроде eksctl. Но жизненный цикл кластера всё равно должен кто-то исполнять. Именно здесь и проходит реальная граница между инструментами.

В этой статье мы разбираем пользовательский жизненный цикл кластера второго поколения Managed Kubernetes в VK Cloud: создание, нод-группы, масштабирование, обновление версии и аддоны. За точку сравнения берём eksctl как привычный инструмент управления EKS. Дальше — таблица соответствия задач eksctl операциям VK Cloud, HCL-листинги Terraform-провайдера для кластера, нод-группы и аддона, числовые пороги автоскейлинга мастеров, процедура апгрейда со скрытым control plane и список мест, где обе абстракции дают сбой.

Это статья для инженеров, которые выбирают или эксплуатируют managed Kubernetes в российских облаках и хотят понимать, какие операции берёт на себя платформа. Для платформенных команд, переводящих кластеры в IaC. Если у вас самосборный Kubernetes, разделы об апгрейдах и запасе узлов тоже пригодятся: они описывают механику самого Kubernetes.

Насколько тяжёлым должен быть Kubernetes-кластер, чтобы на нём можно было тестировать решения из промышленной инфраструктуры? Автор собрал такой стенд на одном мини-ПК с потреблением около 10 Вт: с реплицируемым хранилищем, полноценным LoadBalancer и Gateway API. В статье — подробный разбор конфигурации, неожиданных проблем и компромиссов, благодаря которым удалось уместить почти продовый Kubernetes в столь скромные ресурсы.

В предыдущих статьях цикла мы разобрали, как сканируем код и блокируем релизы через Security Quality Gate. Теперь движемся дальше по пайплайну: к артефакту. В этой статье — как устроен полный цикл контроля Docker-образов в ecom.tech: от манифеста разрешённых базовых образов до Kyverno, который не пускает в прод ничего без подписи и аттестации с результатами проверок.

Приглашаю вас окунуться в страшную историю о том, как мы посреди тёмной ночи, пока никто не видит, на велосипеде перевезли 400 сервисов между кластерами KaaS. И всё это с возможностью отката.

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

Краткий экскурс в страшный сон девопса: переезд ядра банка между кластерами k8s или особенности национальной инфраструктуры.

Попросите агента «поставь нам LLM-шлюз», и он уверенно придумает переменные окружения, которых не существует. Поэтому у Keystone есть плагин для Claude Code: восемь скиллов, которые знают настоящие команды, флаги и поля конфига, и MCP-сервер, через который агент видит, что запущено. Ключи при этом в чат не попадают.

Keystone. The Model Switchboard. (KTMS) — self-hosted LLM-шлюз на Go: сервисы ходят в одну точку, а он хранит ключи вендоров, выбирает модель по правилам, переключается при отказах и держит лимиты расходов. Про сам шлюз была релизная статья, здесь — как его поставить за один разговор с агентом.

Когда API долго ждёт зависимость, хочется сократить таймаут. Запрос быстрее получит ошибку, освободит ресурсы и перестанет висеть. Но сразу возникает следующий вопрос: что приложение сделает после этой ошибки? Если оно без паузы повторит тот же вызов, короткое ожидание может превратиться в большую очередь на другой стороне.

В моём проекте Prod is Down есть учебный кейс с такой цепочкой: первое исправление вскрывает проблему с повторами. Для этого разбора я собрал отдельный локальный стенд и сравнил четыре варианта настроек.

Условия простые: шесть клиентов обращаются к небольшому TCP-сервису на 127.0.0.1. Одновременно сервис обрабатывает три задания. Первые две секунды обработка занимает 250 мс, затем возвращается к 20 мс. Каждый клиент начинает следующую операцию после завершения предыдущей и небольшой паузы. Каждый вариант запускается на шесть секунд с пустой очередью.

Важное условие: принятое задание продолжает выполняться, даже если клиент уже закрыл соединение. Так устроена наша тестовая зависимость - отмену принятой работы мы здесь не реализуем. В конкретном приложении это поведение нужно проверять отдельно.

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

Теперь меняем только время ожидания: вместо 1000 мс ставим 50 мс. Повторы по-прежнему бесконечные, паузы между ними нет. В настройках нашего стенда это MAX_ATTEMPTS=0 и BACKOFF_BASE=0. Ноль здесь означает отсутствие ограничения, у других библиотек такое значение может иметь другой смысл.

Привет! Я Виталий, iOS-разработчик в платформенной команде hh.ru.

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

Главная цель проекта это сделать нормальную систему для игр и работы, где сразу решены частые проблемы linux. К примеру: фризы в играх, лаги звука, вылеты из-за нехватки памяти и неудобный запуск android программ(в моей ос в отличии от остальных предусмотрен WayDroid + libndk).

Так выглядит Агора сейчас. 4 ноября 2026 года (agorasocial.ru)

2 ноября сервер моей соцсети «Агора» на Beget перестал отвечать. 3 ноября хостинг подтвердил: данные VPS обнулены, бинарные бэкапы потеряны. Меня спасли три вещи: зашифрованные офсайт-бэкапы базы, которые я настроил за день до аварии; escrow-ключ для личных сообщений, заложенный в схему ещё раньше; и скрипты переезда, которые я успел написать в репозитории. Агора открылась на новом сервере примерно через 3 часа после того, как Beget подтвердил потерю. Цена: около суток данных и целая коллекция граблей, о которых ниже. Главная моя ошибка: мастер-ключ шифрования лежал только в окружении серверного процесса и в бэкап не входил.

Хаборовчане и гости привет!

Вкратце суть того что произошло. По сути фильм ужасов от Бегет.

В ночь с 1 на 2 ноября 2026 года на нашу инфраструктуру была совершена кибератака с получением доступа к управляющему контуру всей архитектуры и последующим запуском обнуляющих скриптов.... К сожалению, бинарные бэкапы VPS полностью утеряны. Остаётся возможность восстановления данных из файловых бэкапов.... В облачной инфраструктуре (VPS, S3 и Kubernetes) все данные были утрачены.... Настройки CDN, IP утрачены. Мы не сдаёмся и продолжаем поиск способов восстановить эти данные.
Источник https://vk.ru/begetru?w=wall-2782733_35546

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

Почему free в Docker врёт и ещё три сюрприза PID 1: systemctl, journalctl, free: что ломается, когда сервер - это контейнер?

На этой неделе в топе снова всплыла старая история: свежий VPS, ufw default deny incoming, наружу только 22, 80 и 443, а потом в compose-файле появляется ports: - "5432:5432" — и через пару дней в базе лежит записка с биткойн-кошельком. Почему так происходит, уже разобрали подробно. Я хочу про другое: как сделать так, чтобы такой compose-файл вообще не доехал до сервера.

Ниже — два небольших скрипта на Python. Первый проверяет compose-файлы до деплоя и падает с ненулевым кодом, если порт опубликован на все интерфейсы. Второй смотрит, что реально слушает на машине, без ss и netstat, прямо из /proc. Весь код я запускал на Python 3.13 и PyYAML 6.0.3, вывод в статье — настоящий.

AI‑агент исправил упавший CI, сборка стала зелёной — можно мержить? В эксперименте с двумя AI‑ассистентами выяснилось, что при конфликте тестов со спецификацией агенты могут менять сами тесты, подгоняя результат под ожидаемый. В статье разбираем шесть ошибок в организации работы с AI‑агентами и способы защитить тестирование от незаметной подмены требований.

Привет! Меня зовут Илья Садыков, я работаю в команде TestOps в PaaS Авито. Мы отвечаем за инструментарий хаос-тестирования — подхода, при котором в систему намеренно внедряются сбои для её проверки. 

В этой статье я покажу карту нашего хаос-ландшафта, расскажу, зачем нам собственный оркестратор, и подробно разберу, как во всё это встроена LLM. Рассмотрим кейсы от автоматического разбора прошлых инцидентов (LSR) до генерации AI-conclusion по конкретным экспериментам. Все архитектурные решения, о которых расскажу в статье, — из нашего реального продакшена.

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

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

Когда мы решили переезжать с Airflow 2 на Airflow 3, мы прочитали официальный migration guide и думали, что основная работа — переименовать параметры и импорты. Спойлер: переименование заняло один вечер, а вся миграция — четыре месяца, несколько десятков коммитов и одну полную смену архитектурного решения на ходу. Ниже — честный разбор по следам нашей git-истории.

Сначала хронология: это была не миграция, а жизнь на двух мажорах

Если восстановить события по коммитам, картина выглядит так.

Новый репозиторий под тройку мы завели в начале марта — и с первого же коммита положили в него constraints-файлы для обеих линеек: и для Airflow 3.1.x, и для старого доброго 2.10.5. Страховка с нулевого дня, и, как показала практика, не лишняя.

Дальше две недели шла интенсивная работа в ветке airflow-3: даги, плагин, логирование, типы. Но в конце марта — после того как «миграция уже почти закончена» — в develop влилась параллельная ветка airflow-2.11 с фиксами для старой линии. Продакшен всё ещё жил на двойке, и его надо было обслуживать.

Последствия этого мерджа обнаружились в начале апреля: рефакторинг дагов под новый API пришлось делать заново, потому что develop «отъехал» к дагам в старом стиле. Та же самая правка, что была сделана в середине марта, во второй раз прошла по тем же файлам в начале апреля. Отдельно весной мы продолжали латать сборку двойки: откаты транзитивных зависимостей и свежие constraints для 2.11.x датированы апрелем — когда, казалось бы, мы уже «на тройке».

Проверка отката видит ноль записей v2 и допускает старого читателя. Поздний INSERT ломает следующее чтение. Разбор выполненного стенда Python/SQLite: транзакционная проверка политики, оба порядка commit и условия допуска старой версии. Полный код стенда и все тесты приведены в статье в раскрывающихся блоках.

Типичная картина при переезде на свежий VPS. Подняли чистую Ubuntu или Debian под новый проект, сразу навели базовый порядок: ufw default deny incoming, снаружи оставили только 22, 80 и 443. Глянули ufw status — всё четко, лишнего не торчит. Дальше ставится Docker, через компоуз взлетает бэкенд с PostgreSQL и Redis. Чтобы удобно ходить в базу с ноута через DBeaver и гонять миграции, на автомате дописываем ports: - "5432:5432". Кажется, что мы в домике: наружу ничего не светит, фаервол же режет всё, кроме веба и SSH.

А через пару дней прилетает абуза от хостера или срабатывает алерт в мониторинге: все ядра в полке, в htop резвится какой‑нибудь kdevtmpfsi или kinsing, а вместо таблиц в базе лежит одна записка README_TO_RECOVER с биткойн‑кошельком. Грабли старые, как сам Docker. Но на них с завидной регулярностью наступают и джуны, и вполне опытные админы, привыкшие доверять выводу ufw status.

Сам Konflux, пожалуй, стоит представить отдельно, потому что за пределами Red Hat о нём пока мало кто слышал. Это открытая Kubernetes‑native система сборки. Kubernetes‑native в самом буквальном смысле: пайплайны здесь — это кастомные ресурсы, которые лежат в кластере и выполняются как поды, и никакого отдельного сервера сборки рядом не стоит. От обычного раннера пайплайнов его отличает то, что он построен вокруг безопасности цепочки поставок. Сборка идёт с отключённой сетью, образы подписываются, на выходе появляются SBOM и провенанс SLSA, а перед релизом стоит гейт, который решает, можно ли вообще выпускать то, что получилось. Ничего из этого включать не надо. Это поведение по умолчанию.

Но вот в чём штука. Эксплуатировать инфраструктуру под инструментом и пользоваться самим инструментом, это две разные вещи. Konflux я неплохо знал со стороны самой инфраструктуры и куда хуже,‑ со стороны человека ('end‑user'), которому просто надо выкатить контейнерный образ. Поэтому я решил собрать что‑нибудь сам, от начала до конца, как это сделал бы любой пользователь. В основном чтобы наконец разобраться.

Почти каждый, кто выкатывал релизы, видел такую картину. Сайт открывается, сервер отвечает 200, сертификат в порядке, и мониторинг весь вечер показывает зелёный статус. А кнопка «Оформить заказ» после релиза перестала работать, и узнают об этом утром из писем покупателей.

Обычная проверка доступности такой сбой не заметит: она узнаёт, отвечает ли сайт, а не можно ли им пользоваться. Чтобы это узнать, проверка должна сама пройти путь пользователя: открыть страницу, войти в кабинет, положить товар в корзину. Так в Statuser появились сценарные проверки: тесты на Playwright, которые мы запускаем по расписанию в настоящем браузере.

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

Меня зовут Михаил Шпаков, я развиваю Statuser. В прошлых статьях я рассказывал, зачем научил Statuser следить за DNS и почему 200 OK от гейтвея ничего не значит, а сегодня расскажу, как устроены сценарные проверки.

Через ноутбук атакующий добрался до service container и оттуда отправил транзакции на вывод. Ключи от кошельков не утекли: транзакции подписала сама система биржи, потому что запрос пришёл изнутри.

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

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

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

Так появился особый дистрибутив для инженеров Яндекса, попавших в ад, Яnetes.

Почти весь код своего проекта kb-engine я писал вместе с ИИ-агентом и быстро понял: правило, которое можно пропустить, когда неудобно, никто соблюдать не будет. Работает только то, что проверяет код.

Сейчас в проекте 21 автоматическая проверка. Вот пять историй, и в нескольких из них проверка была зеленой и при этом ничего не проверяла.

С 11 октября 2026 года корень DNS подписывает набор ключей только новым KSK-2024 (38696). За четыре дня до смены Эфраин Гарай показал, что BIND из Debian 11 с одним старым ключом при первом запуске сам начинает доверять новому. Через 20 дней после смены я запустил тот же BIND с пустым состоянием, как в пересозданном контейнере: SERVFAIL на всё, включая неподписанный google.com. Для unbound такой старт спасает unbound-anchor, но только при открытом HTTPS к data.iana.org, а при неудаче пишет старый ключ и выходит с кодом 0. dnsmasq из Debian 12 со своим файлом якорей отказывает на всём, а с якорями, где есть 38696, работает: их подставляет сервисная обёртка дистрибутива.

Недавние истории с блокировками от Anthropic заставили меня всерьез задуматься, как я буду работать, если и мой аккаунт отлетит в бан.

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

Но самое главное в другом: я осознал, что меня пугает возврат назад...

Как вариант, можно взять, да хоть на примере питона, нужный официальный образ в докере. Да и пользоваться.

Казалось бы, проблема решена. Но есть нюанс (с). Добро пожаловать под кат.

Я DevOps-инженер. В DevOps я перешел незадолго до начала этой истории, а до того год работал в сопровождении с элементами SRE. Еще раньше я сидел в центре мониторинга сетей у телеком-оператора. Дома у меня мини-ПК и медиасервер, которым каждый вечер пользуется семья. На этом медиасервере я и учился тому, за чем пришел в профессию: Kubernetes, Istio, Jenkins.

Медиасервер у меня собран из целого arr-стека. Так называют набор self-hosted сервисов, которые сами находят, качают и раскладывают по папкам фильмы и сериалы. Смотрим мы все в Jellyfin, это медиасервер, что-то вроде домашнего КиноПоиска. Заявки принимает Seerr (раньше он назывался Jellyseerr): выбрал фильм на витрине, и заявка ушла дальше. Фильмами занимается Radarr, сериалами Sonarr. Оба спрашивают Prowlarr, а тот ищет раздачи по торрент-трекерам. Если трекер закрыт капчей Cloudflare, Prowlarr проходит ее через FlareSolverr. Качает qBittorrent, субтитры подбирает Bazarr. Когда все работает, человек нажимает одну кнопку, и через какое-то время фильм появляется в Jellyfin.

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

Пишу я это прежде всего для себя. С конца мая по конец октября 2026 года я сделал много отдельных кусков и ни разу не видел путь целиком. Хочу собрать его в одном месте и понять, что вообще произошло. Текста вышло на три статьи. Эта первая, про кластер, хранилище, Istio и платформу вокруг. Во второй будет свой сервис, сборка с проверками безопасности и то, как код у меня начал писать агент. В третьей Helm, фронт, возвращение к Istio, просмотр фильма, пока он качается, и Argo CD.

Сколько у вас в инфраструктуре версий PostgreSQL? А какие из них уже не поддерживаются? А сколько CVE висит на том nginx, который «работает — не трогай»?

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

У нас под постом про ЦОДы развернулась дискуссия: какой должна быть ракета, чтобы устроить дата-центру пробитие. Я почувствовал себя среди оружейных баронов и экспертов по уничтожению дата-центров.

Знаете, у нас есть некоторая экспертиза в этом. Потому что сгоревших ЦОДов мало, а вот попадавших из-за кривых рук — очень много. Поэтому мы тут решили на Хэллоуин сравнить разные технологии с тем, как бы выглядело оружие на их базе.

Кроме MongoDB без чеки из заголовка у нас есть ещё 20 не менее убойных штук.

Привет, я Сергей, DevOps-инженер в KTS. Перейду сразу к делу.

К отказу отдельной виртуалки вы наверняка готовы. Но не все готовы к другому классу аварии: к потере площадки, на которой находятся почти все ВМ проекта.

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

Авария затронула инфраструктуру Yandex Cloud, где работали сервисы нашего заказчика. Восстановить работу системы на прежней площадке в тот момент было невозможно, а очередь за новыми ресурсами обрабатывалась несколько дней.

Заказчика и его внутренние системы я называть не буду, статья не о нем. На его примере я хочу поговорить о механике восстановления: что происходит после потери основного дата-центра и какие инженерные практики помогают вернуть бизнес в рабочее состояние.

Long story short.

У меня все еще работает CHUWI CoreBox, который уже появлялся в предыдущих статьях: Core i7-13620H, 16 ГБ LPDDR5 (а жаль!), SSD на 512 ГБ. Он успел побыть прокси, NAS, VPN, сервером Lineage 2 и складом 3D-моделей для печати. Склад потом переехал на отдельный накопитель, а сбор моделей я остановил. Даже качественные модели скачивались гораздо быстрее, чем я успевал их печатать. На освободившемся мини-ПК шла разработка своего продукта, ибо я привык к linux, и там же крутились тесты. С обычными проверками еще можно было жить, но мутационное тестирование занимало часы. Хотелось продолжать работу, пока оно выполняется, а свободных ресурсов на той же машине было немного.

Зато рядом стоял мой любимый игровой компьютер: Ryzen 9 9950X3D и золотые 64 ГБ Kingston FURY Beast DDR5-6000 CL30. Память до 64 ГБ я докупал в 2026 году. Кто в этом году собирал комплуктер, тот понимает, почему я сейчас это упоминаю и ставлю на этом акцент.
К этому моменту я уже смотрел по квартире, у чего еще есть оперативка. Поглядывал дергающимся глазом на робот-пылесос и духовку. Если они подключаются к Wi-Fi, значит, они чем-то думают и чем-то помнят.

Но начал все-таки с ПК. Windows оставил на месте, потому что игры нужно на чем-то играть, поставил WSL с Ubuntu и отдельным Docker. Разработку оставил на мини-ПК, а тяжелые проверки решил вынести на игровую машину. Первый измеренный запуск PIT на ней занял больше девяти часов и закончился с ошибкой памяти. Это же разочарование я ловил много раз на мини-пк, разбирал по этому разочарованию логи, в течение десятков часов, в надежде исключить дефицит памяти. Смотрим.