DevOps *

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

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

Привет, Habr!

Мы разрабатываем IncidentRelay - self-hosted систему для on-call scheduling, маршрутизации алертов и доставки уведомлений. Идея простая: дать командам SRE, DevOps, platform и operations понятный инструмент, который можно развернуть у себя, подключить к мониторингу и использовать без зависимости от внешней incident-management платформы.

В статье — разбор основ Ansible: как писать идемпотентные плейбуки, не класть продакшен сухими прогонами и встроить Ansible в CI/CD.

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

Когда я начал пользоваться Claude Code, у меня было ощущение, что я дал умному человеку доступ только к одной папке на компьютере. Он видит код, помогает с задачами — но не знает, что происходит снаружи. Нет доступа к чатам, к базе данных, к GitHub issues. Всё это приходилось копировать руками и вставлять в контекст.

Потом я узнал про MCP.

Вчера pypi.org несколько часов был недоступен из российских сетей. Для кого-то это «подождём», а для CI/CD, прода и просто рабочего дня — это вставший pip install и красные сборки.

Причина системная: pypi.org и хранилище пакетов files.pythonhosted.org живут на CDN Fastly, у которого нет точек присутствия в России и доступ к которому уже не раз ограничивался. Вчерашняя недоступность — не первая и почти наверняка не последняя.

Хорошая новость: чтобы застраховаться, не нужно зеркалировать весь PyPI (это терабайты и постоянная синхронизация). Достаточно поднять лёгкий реверс-прокси на nginx. В этом гайде соберём такой с нуля — с кешированием и прозрачным переключением для pip.

Не хотите хостить сами? Есть уже готовое зеркало — pypi.depkit.ru. Оно работает на российских IP, имеет большой объём кеша под пакеты и отдаёт их очень быстро. Можно просто подставить его в index-url (как — в конце статьи) и пропустить всю настройку. Дальше — для тех, кому интересно поднять своё.

На кону финансовые данные клиентов, а странный и неуловимый баг в Cilium не даёт как следует настроить сетевую безопасность.

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

Команда VK Cloud перевела статью для тех, кто разбирает инциденты в Kubernetes с помощью kubectl debug. Автор разбирает незаметный пробел в данных: после завершения debug-сессии API Kubernetes не сохраняет контекст ее завершения — код возврата, длительность сессии и целевой контейнер исчезают при первом же изменении состояния пода. В статье как воспроизвести это тремя командами, почему так устроено на уровне спецификации API, чем это грозит при разборе инцидентов и комплаенсе и что можно сделать уже сегодня.

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

Но довольно быстро стало понятно, что с временными и ресурсными ограничениями лучше не пытаться написать маленький PagerDuty. Поэтому я сузил задачу до более реалистичного ядра: локального RAG-сервиса, который ищет по документации, ранбукам и коду, а затем передаёт найденный контекст в LLM.

Так появился llmortem — FastAPI-сервис, который можно подключить к OpenWebUI как OpenAI-compatible backend.

В статье расскажу, как устроена архитектура, почему я начал с BM25, зачем индексировать docstring’и и какие ограничения у такого подхода.

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

В этой части речь пойдёт о следующем этапе — масштабировании и удешевлении. О том, что происходит, когда SLA считается корректно, цифрам уже доверяют, но компания продолжает развиваться. У неё кратно растёт количество разработчиков, архитектура усложняется и количество сбоев тоже растёт. Инциденты и сбои это наши обиходные синонимы и по ITIL это не одно и тоже, уж простите. С ростом ограничением становится не математика и перегибы полиномов высоких порядков, а люди, ручной труд, коммуникации и скорость реакции. О том, что со всем этим делать и поговорим.

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

На демо всё красиво: задачки бегают, доски сияют, отчёты рисуются. Через полгода команда уточняет статусы в чате, релизы сверяет в таблице, а тимлид перед стендапом открывает пять вкладок. Разбираем четыре ошибки выбора системы управления разработкой и даём чеклист из 12 вопросов, которые стоит задать до покупки.

1.   Введение

Всем привет! Меня зовут Яблоков Олег, я — ведущий инженер ИТ-отдела Navio и отвечаю за систему мониторинга основной инфраструктуры компании. Это работа на стыке разработки и эксплуатации (development & operations, DevOps), наблюдаемости (Observability) и обеспечения надёжности сервисов (Site Reliability Engineering, SRE). Моя основная задача не просто собирать метрики, а сделать так, чтобы по ним можно было быстро понять статусы сервисов и не утонуть в шуме оповещений.

Когда я пришел в компанию около года назад, система мониторинга уже существовала и закрывала базовые задачи. В наборе технологий использовались Prometheus, Thanos, Alertmanager, Grafana, Elasticsearch и различные наборы оповещений. Со временем количество компонентов и инструментов увеличилось, что усложнило их сопровождение и масштабирование.

В этой статье я расскажу, как происходила миграция мониторинга в Kubernetes, почему в качестве основной базой данных временных рядов (Time Series Database, TSDB) была выбрана Victoria Metrics, как мониторинг связали с Gitlab и Argo CD, пересобрали систему оповещений (alerting) и начали постепенно двигаться от инфраструктурного мониторинга к сервисному подходу и практикам обеспечения надёжности сервисов (Site Reliability Engineering, SRE). 

2. С чего все начиналось.

Изначально мониторинг представлял собой связку Prometheus, Thanos, Alertmanager, Grafana и Elasticsearch. Разворачивалось все через Docker Compose на отдельных серверах, а сама система постепенно росла вместе с инфраструктурой.

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

Вызубрить десяток флагов для docker run — недостаточно. Интервьюеры хотят видеть, что вы понимаете саму архитектуру контейнеризации: как работает изоляция процессов, почему данные внезапно исчезают после рестарта, чем слои отличаются от томов и что будет, если PID 1 внутри контейнера завершит работу.

Привет, Хабр! Меня зовут Михаил, я backend-разработчик в команде Managed Kubernetes в VK Cloud. При работе с K8s всем нам приходится сталкиваться с множеством конфигураций, которые мы используем постоянно, и Service не является исключением. И вот тут мне стало любопытно: а может ли с виду безобидный конфиг Service сломать нам весь кластер? Ну или хотя бы подпортить жизнь какому-то сервису?

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

Статья будет полезна DevOps, безопасникам, админам и просто юным любителям Kubernetes. 

В прошлой статье цикла «РБПО для бедных» мы разобрались, что такое разработка безопасного программного обеспечения, зачем она нужна стартапам и как может выглядеть минимальный конвейер безопасной разработки. Теперь пора переходить от схем и планов к практике.

В этом материале мы рассмотрим:

— создание виртуальных машин в VirtualBox для сервисов безопасной разработки ПО;

— подготовку виртуальных машин к дальнейшей работе;

— установку Ubuntu Server с ручной настройкой статического IP;

— первичную настройку серверов: часовой пояс, базовые утилиты, брандмауэр UFW, установку Docker и docker‑compose.

Мы создадим и подготовим пять виртуальных машин, на которых в следующих частях будем разворачивать сервисы безопасной разработки. К концу статьи у нас будет готова инфраструктурная основа будущего конвейера РБПО.

Так что запасаемся терпением, запускаем VirtualBox и начинаем строить нашу небольшую лабораторию безопасной разработки.

Как мы избавили общепит от часа ручной работы каждое утро: разобрали реальный кейс синхронизации стоп-листа из СБИС 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.