DevOps *

Мой сайт ведут ИИ-агенты. Они пишут код, правят тексты, проводят ревью, собирают и выкатывают. 207 коммитов.

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

Две цифры для затравки:

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

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

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

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

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

В этой статье я запущу тестовую сюиту на стеке JUnit + Gradle + GitHub Actions, и опробую различные способы перезапуска конкретных тестов в ней.

График CPU может выглядеть спокойно, пока контейнеры уже теряют время на троттлинге, ожидании памяти или вводе‑выводе. В Kubernetes 1.36–1.37 для такой диагностики появились более полезные сигналы и возможность менять ресурсы работающих подов без пересоздания.

Разберём, как читать PSI, отличать реальное ресурсное давление от обычной утилизации и связывать эти данные с ресайзом подов.

Ох уж этот «ИИ-пентест» (AI Pentest) — за последнее время я очень много о нём наслышан, чуть ли не из каждого утюга (и из моих собственных рекомендаций в том числе). А как же защита? Кто будет защищать сервисы, пока все обсуждают атаку? Сегодня поговорим про open-appsec, поделюсь с вами опытом использования, покажу, как его настроить, а в конце статьи будут полезные «бонусы» и одна небольшая просьба к читателям. Проект подойдёт, если у вас есть homelab или небольшой/средний продакшн и вы хотите закрыть веб-сервисы адекватным WAF без раздутого стека и без обязательной привязки к облаку. Моя личная оценка после нескольких месяцев использования: open-appsec — достаточно «умный» щит для небольшой homelab, с парой шероховатостей, о которых я расскажу отдельно.

Pod'ы в Kubernetes появляются, исчезают и меняют IP. Разбираемся, как Service даёт приложению стабильную точку доступа, как работает ClusterIP, DNS, selectors, EndpointSlice и readiness - и как запрос в итоге попадает на конкретный Pod.

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

У нас начали активно появляться кластеры на Talos Linux, в том числе и небольшая песочница для тестирования продуктов, о которой пойдёт речь далее. Доступы раздавались через обмен рутовыми kubeconfig'ами в yopass. Быстро, привычно и, к сожалению, абсолютно неуправляемо.

Проблема даже не в самом факте передачи файла. Проблема в том, что лежит внутри: клиентский сертификат, который выписан на год, работает всегда и отовсюду, не привязан ни к какому конкретному человеку и не отзывается ничем, кроме ротации CA всего кластера. Сотрудник уходит из компании — его kubeconfig продолжает работать. Ноутбук потеряли — конфиг продолжает работать. Кто-то выполнил kubectl delete не в том кластере — найти его не удастся. Blameless culture в чистом виде.

Хотелось получить другое поведение:

«У меня всё открывается» — прекрасная фраза. В ней есть уверенность, оптимизм и результаты мониторинга ровно из одной точки.

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

Мы развиваем RMON, чтобы такие ситуации было проще замечать и разбирать. Это система мониторинга доступности сайтов, API и сетевых сервисов из разных точек. Вы задаёте, что проверять, откуда и какой ответ считать правильным. Агенты выполняют проверки, RMON собирает результаты, показывает историю и отправляет уведомления.

Иногда мне нужно быстро проверить свой VPS: посмотреть нагрузку, глянуть логи или перезапустить сервис. Каждый раз открывать ноутбук и подключаться по SSH ради пары команд было неудобно, поэтому я решил сделать Telegram‑бота. Сначала думал, что всё будет довольно просто: Telegram → SSH → сервер. Но по ходу разработки выяснилось, что само SSH‑подключение — как раз самая простая часть. В статье расскажу, с какими проблемами я столкнулся и как в итоге их решил.

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

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

В статье я расскажу, как нам удалось ускорить сборку Python до 20 раз.

TL;DR. Мы выкатили Татарнетес — национальную обёртку над Kubernetes, где команды, сообщения, ошибки и даже перерывы на чай с чак-чаком и т.п. на татарском. Рядом — TatarOS Linux (обёртка над Talos, которая поднимает кластер с Татарнетесом) и Татарнетес UI (панель на фоне татарского келәма). Всё под собственной лицензией Tatarch 2.0.

Под капотом i18n на чистом bash 3.2 без единой зависимости, три системы письма (кириллица, яңалиф, гарәп язуы), детерминированный чайный график (кластер рандомно останавливается на попить чай с молоком и бабушкиными кыстыбыями) и первый черновик татарской IT-терминологии Kubernetes. А ещё мы прогнали всё на реальном кластере CozyStack — с живыми kubectl/talosctl, RBAC, метриками и одним пойманным багом.

Репозитории tatar-ncf: tatarnetes · tataros · tatarnetes-ui. Лицензия — Tatarch 2.0.

Проект посвящается Саше, Роме, Максу и Рамилю из одного замечательного кубер-чатика.

Почему ограничение полномочий модели ещё не означает, что AI-система действительно стала read-only. Разбираем runtime control на примере n8n + DeepSeek + HubSpot.

На одном из проектов нам потребовалось развернуть систему централизованной аутентификации и авторизации для 25 000 – 30 000 активных пользователей, территориально распределенных по всей стране. Такая специфика диктует жесткие требования к масштабируемости и надежности системы. Наш выбор пал на Keycloak как на популярное open-source решение.

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

В этой статье рассказываем про наш опыт развертывания кластера Keycloak на трех изолированных виртуальных машинах с Embedded Infinispan и JGroups. Расскажем, почему выбрали именно такую архитектуру, как настраивали, что сломалось при тестировании отказоустойчивости и как мы это чинили (включая баг, который нашли и исправили вместе с командой Keycloak).

Часто ли вы сталкиваетесь с проблемой потери данных, неконсистентными состояниями или ошибками в Sentry о внезапно закрытых соединениях при рестарте сервисов? Если вы когда-нибудь пытались это исправить, то наверняка слышали про Graceful Shutdown.

Привет! Меня зовут Антон, я бэкенд-разработчик Python в Selectel. В этой статье поделюсь опытом внедрения Graceful Shutdown в наши сервисы и расскажу, с какими сложностями мы столкнулись.

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

Первая версия - прокси-репозиторий перестал кешировать. Полез в его настройки, там всё в порядке.

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

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

Мы выпустили очередной релиз NEOMSA ESB. Фокус этого цикла — состав поставки: мы прошли по всем контурам сборки, сформировали SBOM, устранили уязвимости уровня Critical и High и зафиксировали версии так, чтобы они не «уехали» при следующей сборке.

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

Привет, Хабр! Я Руслан Боярский, SRE в Т-Банке, отвечаю за надежность платформы Sage и принимаю активное участие в ее развитии. Sage — это платформа наблюдаемости, где мы собираем телеметрию. И я регулярно убеждаюсь, что в ИТ мы не можем существовать без метрик.

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

А еще опишу проблемы, с которыми можно столкнуться, и расскажу, как мы их решали. Попутно будет пара историй про инциденты. Поехали.

Всем привет! Нашел в блоге Kubernetes интересную статью о том, как написать собственный экспортер метрик на Go и подключить его к Prometheus. Автор разбирает весь путь: от выбора показателей и первых строк кода до развертывания в кластере и проверки сбора данных. Перевел материал и делюсь.

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

В ноябре 2025 года мы выпустили федерацию VK WorkSpace для двух On-Premise-инсталляций. В релизе 26.2, вышедшем в июле 2026 года, сняли ограничение на парное взаимодействие: теперь в одном чате могут работать участники из нескольких независимых контуров. В статье разберем, как устроена модель доверия, почему мы выбрали репликацию данных на стороне каждой организации, что пришлось изменить в клиентских приложениях и какие ограничения у решения остаются.

Меня зовут Андрей Ковайкин, я старший менеджер продукта направления Мессенджер в команде VK WorkSpace. Мы развиваем единый контур корпоративных коммуникаций, а федерация решает его внешний сценарий: позволяет организациям общаться между собой, не объединяя инфраструктуру, администрирование и политики безопасности.