DevOps *

Как мы избавили общепит от часа ручной работы каждое утро: разобрали реальный кейс синхронизации стоп-листа из СБИС Presto в каталог на Tilda через CommerceML. Поток на Python/FastAPI, дебаунс через SHA-256, eventual consistency без очередей и грабли, на которые наступили в проде.

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

За 7 месяцев работы были запущены 6 продуктов:

Я ожидал, что прогнозирующий контроллер обгонит HPA на коротком пике. Но в Kubernetes всё упёрлось не только в алгоритм: пик длился 30 секунд, а новые Pod становились Ready примерно через 40.

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

Решение — свой GitLab Runner на VPS: без чужих джоб, под полным контролем. Такой раннер не имеет лимитов по времени, кроме ресурсов самого сервера. В статье за вечер собираем такой раннер с нуля на Ubuntu 24.04 LTS, поднимаем пайплайн на три стадии (тесты, сборка Docker-образов, пуш в GitLab Container Registry), добавляем кэширование, безопасность и автообновление.

Для многих обывателей, да и инженеров, которые не углублялись в тему, работа с LLM выглядит как работа с обычным сервисом: мы просто кидаем запросы по нужному endpoint и получаем JSON с ответом. Но на деле появляется много вопросов: как здесь работает кэш? От чего зависит время ответа? Что делать с огромным контекстным окном? И если у нас один GPU-сервер, на котором происходят все вычисления, то это не так и важно. Но что делать с масштабными распределёнными системами? Обычный Kubernetes не понимает, как устроен запрос языковой модели. Однако за последний год платформенные инженеры очень хорошо продвинулись в этом вопросе. И в этой статье я хочу подробно разобрать, как именно строится K8s-кластер под высоконагруженные LLM.

Всем привет, меня зовут Илья и я хочу вам рассказать как я после небольшой правки в тераформ я потерял все мастера в кластере Elasticsearch. ЧатГПТ и гугл уже принесли мне лопату чтобы похоронить эти сервера, но начальство сказало: "Может что нибудь придумаешь?". В итоге 6 часов работ и кластер снова живой и зеленый. Хотите знать больше?

Сейчас ландшафт сетей Kubernetes переживает самую значительную трансформацию со времен появления Ingress API в 2015 году. Gateway API прошел путь от бета-версии до General Availability и продолжает развиваться: к 2026 году — версия 1.4. Это фундаментальная переархитектура того, как трафик моделируется, управляется и защищается в Cloud-Native-окружениях. Это руководство — исчерпывающий анализ экосистемы вокруг этого стандарта: разбираем архитектурные подходы, характеристики производительности и наборы функций ведущих реализаций.

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

Команда VK Cloud перевела статью для тех, кто уже несколько лет живет с зоопарком Ingress-аннотаций под NGINX, Traefik и ALB и сейчас выбирает, на что мигрировать. Автор разбирает Gateway API в его нынешнем состоянии (версия 1.4, GA), сравнивает пять Production-Ready-реализаций — Envoy Gateway, Istio в Ambient Mode, Cilium, Kong и NGINX Gateway Fabric — и дает фреймворк выбора под конкретный профиль нагрузки. Никакого маркетинга и «лучшего решения для всех»: цифры по Latency и CPU, архитектурные компромиссы, явные пределы масштабирования каждой модели.

Рассказываем про инструмент для наблюдения за кастомизациями Битрикс24 — телеметрическую инфраструктуру на базе OpenTelemetry Collector. Для проектов Битрикс24 эту роль выполняет репозиторий github.com/bitrix-tools/b24-ai-starter-otel.

В статье объясним, зачем это надо, подключим Collector к уже существующему приложению чат-бота и покажем, как работает и выглядит сбор метрик.

Это статья из цикла туториалов, где мы показываем полезные вещи, которые можно сделать на своём портале с помощью стартер-кита для ИИ-ассистированной разработки: github.com/bitrix-tools/b24-ai-starter.

Что мы уже сделали и разобрали в других статьях:
— Пишем первое приложение с AI-стартером, чтобы видеть прибыли и убытки
— Добавляем в бизнес-портал Битрикс24 роботов для автоматизации
— Что даёт воспроизводимая среда разработки и как развернуть контейнеры на VPS.
— Анализ и модернизация коннектора баз данных с помощью AI-агентов
— Создание чат-бота в портале Битрикс24 с помощью AI-агентов
— Как стартер-кит может стать стандартом разработки
— OTel Collector в кастомизации Битрикс24: подключаем Observability (вы здесь)

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

Реализация построена на FluxCD с использованием директивы postBuild для шаблонизации манифестов через переменные. Каждое окружение получает собственный namespace, базу данных, TLS‑сертификат и уникальный URL — и всё это без ручного вмешательства. Разбираем структуру CI/CD пайплайна, слоёвую организацию GitOps‑репозитория и автообновление образов через ImagePolicy.

Работая с GitLab каждый день, повторяешь кучу одинаковых действий которые хотелось бы делать быстрее чем позволяет UI. Надоело, запилил Chrome-расширение.

В статье рассказываю как устроено внутри: авторизация через session cookies без токенов, цепочки действий в background worker, борьба с постоянно меняющимся DOM GitLab (Vue-миграция между версиями сломала все селекторы несколько раз).

Из фич: кнопки на MR странице (rebase, bump версии, auto-merge, ship), Jira-сайдбар прямо в GitLab, бейджи размера/конфликтов/тредов на списке MR, cherry-pick в несколько веток, command palette.

На днях я заметил, что квота Ollama Cloud Pro тратится быстрее обычного. Значительно быстрее. За семь дней я сжёг 603 миллиона токенов и не понимал, куда они уходили.

Я открыл логи Hermes Agent и нашёл то, о чём не знал: блок auxiliary: с двенадцатью фоновыми задачами. Сжатие контекста, извлечение из веба, vision, поиск по сессиям, подбор навыков — всё это молча запускалось при каждом моём сообщении. Каждая задача стояла на provider: auto. И поскольку у меня не было ключей для цепочки fallback, каждая молча откатывалась на kimi-k2.6, мою основную модель на триллион параметров.

Я понятия не имел, что это происходит. Пока я печатал одно сообщение, агент отправлял одиннадцать других в фоне — через ту же модель, из того же квоты, не показывая мне промпты. Только сжатие контекста срабатывало 10–20 раз за длинную сессию, каждый раз отправляя всю историю.

Домашний удалённый доступ без панели: эксперимент с Xray, Docker Compose и локальным CLI

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

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

На этом этапе обычно появляется знакомый выбор: открыть SSH, поправить JSON руками, рестартануть контейнер и пообещать себе «потом нормально оформлю». Через пару месяцев «потом» превращается в маленький прод: пользователи, секреты, квоты, бэкапы, мониторинг, логи, обновления и вопрос, какие изменения на сервере были осознанными, а какие - следами экспериментов.

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

Но и жить в режиме ssh -> vim -> docker compose restart мне тоже не хотелось.

Поиск по open source проектам — не дал результата. Многое из того, что я пытался ставить, либо не запускалось, либо было написано на bash, где было много хардкода, который приходилось переписывать под мои VDS. Потратив несколько вечеров - я понял, что есть запрос на простое решение по оркестрации self-hosted VPN серверов с локальным хранилищем и удобным масштабированием.

Хотел ленту новостей без двух вещей: дублей (одно событие из пяти каналов с разными заголовками) и потока негатива по утрам.

Получился Telegram-бот, который по умолчанию показывает только хорошие и нейтральные новости — а тяжёлый контент включается в настройках на 4 уровнях. Плюс он убирает дубли, переводит RU↔EN и подстраивает выдачу под твои реакции 🔥 ❤️ 😢.

Но самое интересное — он живёт на одной машине Fly.io за ~$5 в месяц. В статье разбираю, как:

заменил Postgres + pgvector на встраиваемый sqlite-vec и убрал отдельную БД-машину;

гоняю типизацию, перевод и оценку тональности через бесплатные LLM на OpenRouter (счёт $0–1/мес);

считаю эмбеддинги локально на fastembed/ONNX без внешних API;

собрал рекомендательное ядро на «векторе вкуса» с EWMA и анти-баблом.

И, конечно, грабли: sqlite-vec, который ломался на arm64; vec0 без INSERT OR REPLACE; fastembed, сменивший пулинг между версиями; и LLM, которая «подкручивала» оценки негатива, пока я не дал ей чёткую рубрику.

👉 Бот живой, можно потрогать: @futur_e_news_bot

Запрос «а дайте саппорту возможность заходить под пользователем» почти всегда звучит как простая фича. На практике это изменение в модели авторизации, аудита и ответственности. В терминах Keycloak задача формулируется не как «войти под пользователем», а как «разрешить субъекту A получить токен, в котором он будет субъектом Б, с контролируемыми правами и прозрачным аудитом». Это принципиально важно, потому что Keycloak оперирует токенами, клиентами и правами на их выпуск, а не кнопками на экране.

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

Сразу — не надо так!

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

Держать proto-контракты в одном репозитории удобно, но подключать их целиком в каждый сервис — не очень. Разберём, как автоматически генерировать Go-стабы из proto-файлов, версионировать их как отдельные Go-модули и публиковать через GitLab CI/CD. Бонусом — swagger-документация и GitLab Pages.

Привет, Хабр!

Контейнеризация уже давно стала стандартом де-факто для современной разработки. Но вместе со скоростью и гибкостью Kubernetes и Docker принесли и новые головные боли для команд безопасности. Как защитить то, что живет всего несколько часов? Как внедрить DevSecOps и не свести с ума разработчиков? И как вовремя поймать уязвимость еще на этапе сборки образа?

Мы в Positive Technologies ежедневно решаем эти задачи. И сегодня мы запускаем новую рубрику «Спросите эксперта».

Если вам интересно, как устроена безопасность контейнеров «под капотом», столкнулись со сложным кейсом в Kubernetes или хотите покритиковать/похвалить наш продукт для комплексной защиты контейнерной инфраструктуры в гибридных облаках — добро пожаловать в комментарии!

Сказка — ложь, да в ней намек, разработчикам урок.

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

И закипела работа, и стартовали один за другим спринты. Фичи выкатывались, метрики росли, разработчики героически коммитили по ночам. Вот только о безопасности в стартапе вспоминали примерно никогда. Некому было охранять секреты пользовательские, деньги виртуальные да API-ключи заветные. А хранилось всё это, прямо скажем, не самым надежным образом.

На ту беду нашлись хакеры с купленным эксплойтом, и наступили у стартапа времена невеселые. Третьи точки горели, базы данных утекали, пользователи разбегались, а данные разлетались по самым темным уголкам интернета.

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

Так появился этот цикл статей — про то, как собрать на коленке минимальный, но рабочий конвейер безопасной разработки. 

Долго сказка сказывается, да только CI/CD-пайплайн собирается еще дольше. Так что устраивайтесь поудобнее — расскажу, как строил «РБПО для бедных».

Всем привет!

Наверняка большинство инженеров, работающих с высоконагруженными системами, слышали о Aerospike.

Для тех, кто всё ещё не знает, что это, приведу короткую цитату из документации:

Всем привет! С вами Песковацков Илья (@ilia_peskovatskov), лид DevOps-направления. Мы два года жили прекрасно с Istio Sidecar, решали свои проблемы, в частности, с метриками и безопасностью. Но просто спокойно работать любознательным инженерам скучно и мы решили посмотреть на новый режим Ambient. В статье расскажу, как мы прорабатывали, провели и с чем столкнулись в рамках миграции своих кластеров Istio с Sidecar режима на Ambient.

Вроде познакомились, тогда погнали.