DevOps *

Хабр, привет! Есть такой тип проектов, которые начинаются со слов «а что если» и заканчиваются тем, что ты в три часа ночи объясняешь kubelet-у, что таблица — это его новый control plane. Так вышло и тут, всё родилось из субботней шутки в одном телеграм-канале по кубернетесу.

Правила игры простые: раз весь мир можно создать в эксельке, то пускай всё состояние кластера живёт внутри электронной таблицы. Не «метаданные в таблице», не «экспорт в CSV» — а буквально: Deployments, Nodes, Pods, Events — это вкладки Google Sheets (или листы Excel). Планировщик читает и пишет ячейки. kubectl-подобная утилита ходит в таблицу. И — вот это ключевое — на другом конце крутятся настоящие Docker-контейнеры. Таблица не симулирует кластер. Таблица и есть кластер.

Проект называется Sheeternetes. Это, конечно, шутка. Но шутка, которая компилируется, проходит тесты и переживает падение ноды.

Ниже — как это устроено, как это поднять у себя за пять минут, как оно работает на bare metal без интернета (в Excel и LibreOffice), как связать несколько таблиц-кластеров в федерацию с живой миграцией, почему контейнеры можно хранить прямо в ячейках, — и что это внезапно выросло в целый фонд с 30 проектами, стандартом контейнеров и системой сертификации.

Обычный вечер понедельника. Я уже собирался уходить домой после работы, как вдруг зацепился за разговор коллег о неком Gemini Notebook. Стало интересно, что это, как люди им пользуются, а главное — надо ли оно мне. Глянул пару обзорных видео, послушал про его плюсы, чудеса и все такое прочее, но больше всего зацепил меня тезис о том, что окно контекста у этой штуки — миллион токенов. Вечер перестал быть томным.

Привет, Хабр! Меня зовут Вадим Гартман, я бэкенд-разработчик в Selectel. Недавно стал одним из ответственных за поддержку terraform-provider со стороны выделенных серверов, при том что ранее работал вообще в другом направлении. Я старался быстро влиться в проект, и будто бы ИИ-RAG-инструмент, способный обрабатывать и анализировать структуры огромных монолитов, появился очень кстати.

В общем, мы с Gemini Notebook встретились в странный период моей жизни. А что из этого вышло — читайте в этой статье.

Проверял, что видно про домен заказчика снаружи, и выписал имена из журналов Certificate Transparency. В списке оказались jenkins, gitlab-runner и пара стендов с именами вида test-2 — ни одного из них в публичном DNS не было.

Имя знает не только команда. Его знает весь интернет, причём с того момента, как вы выпустили на этот хост TLS-сертификат.

Разговор с Claude Code остаётся на той машине, где начат. Разбираю, почему облачная папка эту задачу не решает, и шесть граблей, на которые я наступил, пока делал перенос сессий, памяти и инструментов между Linux, Windows и macOS.

Разговор о том, кто на самом деле контролирует облако, часто начинается с регионов: где выполняется рабочая нагрузка и где хранятся её данные. Но выбор региона — только часть картины, архитектура платформы значит ровно столько же. Особенно важно, как она разделяет между кластерами ответственность за управление, исполнение, сборку и наблюдаемость.

Недавняя публикация сообщества CNCF, «От резидентности данных к цифровому суверенитету: архитектурные паттерны для cloud native-платформ», хорошо это обосновала. Под такими режимами, как EU Data Act, NIS-2, DORA и UK Data (Use and Access) Act, платформенным командам теперь приходится показывать не только то, где выполняются рабочие нагрузки. Нужно показать и то, как платформу эксплуатируют, защищают и по каким правилам ею распоряжаются, вплоть до плоскости управления.

Та статья изложила требования и представила паттерн «кластер на тенант» как один из способов провести границы изоляции. Команда VK Cloud перевела статью, в которой на те же требования смотрят под другим, но дополняющим углом: что происходит, если считать контроль над платформой свойством топологии её плоскостей. В качестве примера, который можно изучить самому, авторы берут OpenChoreo, внутреннюю open source-платформу разработки и проект CNCF Sandbox. Впрочем, сами архитектурные идеи применимы широко.

Привет, Хабр! Меня зовут Завур, я фронтенд-разработчик в Selectel. Каждый день я работаю в привычной многим среде разработки VS Code. Однако в личных проектах, которые создаю для исследования новых инструментов и методов написания кода, часто использую Cursor.

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

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

Любой, кто ставил софт в Linux, набирал apt install или pacman -S. Внешне разница косметическая: одни команды длинные, другие короткие. Но за этими командами стоят две принципиально разные инженерные философии.

Почему pacman ощутимо быстрее, но при этом опаснее в руках новичка? Почему Arch категорически запрещает частичные обновления, а Debian их даже не замечает? И почему один менеджер задаёт вопросы про конфиги, а другой молча подкладывает .pacnew?

Разбираем, что происходит внутри при установке пакета: форматы архивов, базы данных, решатели зависимостей, скрипты и хуки. Погружаемся в устройство apt/dpkg и pacman/libalpm глубже, чем в большинстве туториалов.

Падает один шлюз - и дежурному прилетает пачка уведомлений: молчат хосты за ним, гаснет uptime-монитор, срабатывают метрические пороги, горит SLO. Событие одно, уведомлений десятки. Разбираю, как собрать такой каскад в одну карточку инцидента и почему наивная реализация ломается: почему группировать надо по верхнему упавшему предку, а не по прямому родителю; что делать, когда события приходят в обратном порядке; почему “молчит, потому что за него сказал корень” и “не эскалируется, потому что родитель лежит” - это два разных состояния, которые нельзя склеивать; и где в такой системе обязательно выбирать шум вместо тишины. С кодом обхода графа, схемой таблиц и списком граблей.

29 августа Anthropic разослала еженедельный дайджест по Claude Code. Пересказ на русском: /resume подхватывает терминальную сессию в десктопном приложении, сессию на своей машине можно запустить с телефона через Remote Control, субагенту можно дать собственную память между сессиями строкой memory в frontmatter, а /color и /rename помогают различать несколько открытых терминалов. Плюс версии 2.1.243–2.1.248: режим --restricted, автоматический баг-репорт, редактирование правил авторежима из /permissions, часовой prompt cache, zstd-сжатый бинарник CLI и починенные десктопные сессии.

Статья посвящена завершению поддержки ingress-nginx и рассматривает это событие не просто как необходимость заменить один Kubernetes-компонент на другой, а как повод пересмотреть архитектуру маршрутизации в Kubernetes-платформе. В статье показано, как со временем простой Ingress превращается в набор NGINX-specific annotations и накопленного технического долга, который сложно поддерживать и объяснять. Так же разбираются возможности Gateway API, разделение ответственности между Platform-командой и разработчиками, а также подходы к миграции существующей инфраструктуры. Особое внимание уделяется аудиту текущих Ingress, постепенному внедрению новой модели и отказу от массовой миграции ради миграции. Основная идея статьи — не просто перенести сотни Ingress в HTTPRoute, а использовать изменения для построения более понятной, управляемой и масштабируемой Kubernetes-платформы.

В рабочем чате: «Сайт не открывается, сертификат истёк», следом — скриншот с 502. Первый рефлекс — certbot renew и перезагрузить nginx. Иногда помогает. Иногда сайт после этого не поднимается совсем.

Дело в том, что «всё из-за сертификата» — это на самом деле две разные поломки с разными решениями: сертификат не продлился или продлился, но сервер отдаёт старое. В выдаче их валят в кучу, поэтому советы вроде «просто сделай certbot renew» либо не помогают, либо роняют сайт по-настоящему.

Разбираем по шагам: как за десять минут понять, какая из двух у вас, вернуть HTTPS и настроить продление так, чтобы это не повторилось.

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

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

Обычно эту плоскость собирают заново: Prometheus, Grafana, самописный health-контроллер, скрипт деплоя, чат-бот для рестартов. Времени уходит столько же, сколько на сам распил.

redb.Tsak предлагает другой обмен: плоскость эксплуатации живёт в рантайме, и она одна и та же независимо от того, запущен у вас один воркер или девять. Кластер, дашборд, REST API, CLI, пробы, метрики и трассировка не зависят от выбранной топологии. Вы решаете, как нарезать процессы, а не как их потом обслуживать.

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

Merge queue гоняет полный сьют один раз на каждый пул-реквест в группе. Четверо ждут посадки — четыре полных прогона, причём последний из них уже содержит три остальных. Обязаны ли те три прогоняться? Мы построили одноразовый стенд, прогнали на нём четыре способа останавливать лишние прогоны и померили каждый: один сажает сломанный код, один залипает намертво, один безопасен и стоит ровно столько же, сколько мы платим сейчас. Четвёртый — наш, и он экономит около 19 машинных минут на посаженный пул-реквест ценой примерно четырёх минут ожидания.

Одна минута macOS-раннера в GitHub Actions стоит десять минут Linux. Я перенёс iOS-сборку Flutter-приложения в Xcode Cloud: с ~45 оплачиваемых минут на релиз до 6, без .p12 и профилей в секретах, с тремя shell-скриптами вместо 90 строк YAML. Внутри — схема тегов ios/v* и android/v*, настройки Xcode Cloud, которые молча сжигают compute-часы, и таблица семи падений первого живого прогона — ни одно из них не было ошибкой миграции. Плюс чек-лист и открытый скилл, который из этого вырос.

ИИ-агент способен пройти путь от анализа задачи до создания и запуска сценария в Vanessa Automation. Но практический результат зависит не столько от выбранной модели, сколько от качества тест-плана, ограничений для агента и организации всей цепочки.

Вводный вебинар предварял стартующий 1 сентября 2026 года курс «Автоматизированное тестирование в 1С». Его провел ведущий разработчик ИТ-лаборатории Инфостарта и автор курса Александр Кунташов. Эксперт показал, как с помощью ИИ и Vanessa Automation пройти путь от исходной инструкции до работающего автотеста, а затем отдельно разобрал вопросы участников о безопасности данных, MCP, сопровождении сценариев и интеграции с CI/CD...

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

Ситуация, знакомая многим командам: в кластере Kubernetes живут обычные бизнес сервисы, нагрузка на которые днём растёт, а ночью падает. Обычно используют два плохих варианта: держать статический пул нод под дневной пик, которые ночью простаивают и стоят денег, или положиться на cluster autoscaling — и тогда при дневном росте нагрузки бизнес-поды проведут в статусе Pending до создания новой ноды.

Проблема ожидания, пока Cluster Autoscaler развернёт новую ноду, решается паттерном node overprovisioning, настраиваемым через PriorityClass и механизмы Cluster Autoscaler: мы заранее запускаем ничего не делающие capacity-overprovisioning поды (в документации Kubernetes они называются placeholder-подами), которые занимают небольшую часть ресурсов нод. Когда приходит нагрузка и реплики бизнес-приложений увеличиваются — поды бизнес-приложений немедленно занимают освободившееся место, вытесняя capacity-overprovisioning под за секунды. Вытесненный capacity-overprovisioning под уходит в Pending, Cluster Autoscaler добавляет ноду.

Ключевая выгода паттерна — экономия. Ночью и утром, когда нагрузка падает, KEDA снижает число реплик бизнес-приложения, Cluster Autoscaler удаляет недозагруженные ноды, и кластер схлопывается до минимального числа нод. Утром при росте нагрузки capacity-overprovisioning поды отдают место мгновенно.

В этой статье разберём, как это устроено внутри, и развернём демо-стенд: от KEDA-автоскейлинга бизнес-приложения по RPS, который генерирует генератор нагрузки, до живого вытеснения capacity-overprovisioning подов, которое можно наблюдать своими глазами в kubectl get events.

«1С тормозит» — это не техническое утверждение, а начало спора. Бизнес говорит «тормозит», подрядчик говорит «у нас всё в норме», и обе стороны правы, потому что меряют разное: пользователь меряет секунды до открытия документа, подрядчик — загрузку CPU на сервере.

Спор заканчивается там, где появляются цифры. Проблема в том, что цифры про 1С живут на трёх разных уровнях, и стоимость доступа к ним отличается на порядок. Половина разочарований в мониторинге 1С — от того, что человек ждал цифр третьего уровня, а поставил инструмент первого.

Я собираю мониторинг 1С в составе своей платформы наблюдаемости и за последние месяцы прошёл все три уровня, включая пару очень неочевидных граблей на Windows. Ниже — разбор по уровням: что видно, чего не видно, чем это ловится и где именно молча ломается.

Я в одиночку делаю и эксплуатирую платформу мониторинга: метрики, логи и трейсы для чужой инфраструктуры, мультитенантно, на VictoriaMetrics cluster / VictoriaLogs / VictoriaTraces, FastAPI, nginx и Postgres. Прод — один сервер: Debian 12, 4 CPU, 8 ГБ, четырнадцать контейнеров.

За несколько месяцев эксплуатации у меня накопилось десятка полтора отказов под нагрузкой. Ни один из них не был найден классическим нагрузочным тестом. Все — найдены постфактум, по логам, по счётчику рестартов контейнеров и по панели трафика у хостера.

Это статья не про то, «как правильно проводить НТ» — таких статей достаточно. Она про то, какие именно виды нагрузки ломают систему приёма телеметрии, почему привычный сценарий «загоним 1000 rps через k6 и посмотрим на перцентили» проходит мимо всех трёх, и как выглядит воспроизводимый прогон, который эти отказы ловит.

Все цифры ниже — с живого сервера, не синтетика.

Полгода на Arch, одно обновление ядра и AmneziaWG выходит из строя. Snapper молчит, бэкап сломан. Решил попробовать NixOS…