DevOps *

Как найти причину латенси в пайплайне обработки HTTP запроса за 5 минут: разбираем шаг за шагом

Я достаточно ленивый и рациональный человек. В конце прошлого года у CloudFlare и его клиентов были непростые дни и утро Infra инженеров начиналось не с кофе. Плюс, те, кто много работает с CF знают про 503 и 520 ошибки и, если вы не на Enterprise тарифе, они также могу доставить неприятности. Хочу поделиться подходом и инструментом, которые помогли решить эти проблема и рационализировать/автоматизировать их решение в последствии.

Алерт в три часа ночи: время ответа выросло с 150 ms до 1.2 секунды. Или хуже — пользователи получают 502/503/504. Дежурный инженер открывает дашборд и видит красный график. Что-то тормозит. Но что именно?

Это CDN? Ingress? Приложение? База? Сеть между чем-то из вышеперечисленного? Каждый вариант ведёт к совершенно разному исправлению: перезапуск пода не поможет, если проблема в маршрутизации CDN, а звонок в поддержку хостера бесполезен, если у вас медленный SQL-запрос. Гадать дорого — особенно в три часа ночи.

В этой статье я покажу системный подход к поиску узкого места. Шаг за шагом, с минимумом телодвижений, используя данные, которые у вас скорее всего уже есть (или которые легко начать собирать). Акцент будет на CDN, Hosting Provider, Ingress.

Путь запроса

Прежде чем искать проблему, давайте зафиксируем, через какие этапы проходит типичный HTTP-запрос. Это простая архитектура, характерная для небольшой команды — но знакомая и наглядная(межсерверное взаимодействие в Netflix в качестве примера не будем использовать):

User → CDN → SLB (Nginx) → App(POD) → Connection Pooler → RDBMS

Шесть слоёв. Каждый может вносить свою задержку, свои ошибки — и каждый дает свои сигналы для диагностики.

Ключевое наблюдение: SLB (балансировщик, Nginx, HAProxy, ALB) сидит в центре и является вашей точкой отсчёта. Его логи подскажут, куда смотреть — налево (сеть, CDN) или направо (приложение, база).

Шаг 1. Точка опоры: логи балансировщика

Это лучший стартовый шаг — особенно если у вас еще нет развитого observability-стека и внешнего мониторинга. Достаточно Nginx access log.

Два ключевых значения:

Переменная Nginx Что измеряет $request_time Полное время обработки запроса — от первого байта клиента до последнего байта ответа $upstream_response_time Время ожидания ответа от upstream (вашего приложения)

Если вы ещё не логируете эти значения, добавьте их в log_format:

log_format timing '$remote_addr - $request_uri ' 'status=$status ' 'rt=$request_time ' 'uct=$upstream_connect_time ' 'urt=$upstream_response_time'; access_log /var/log/nginx/access.log timing;

Теперь у ва

На протяжении всего моего опыта работы DevOps-инженером, я всегда терпеть не мог мониторинг, алерты и всё что с этим связано. Мало того, что я не любил всё это настраивать, но больше всего я ненавидел получать и резолвить алерты.

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

Если ты тоже смотришь на Dart как на backend-альтернативу для Node.js, лучше пройти этот путь на чужих ошибках. Полные результаты benchmark'а — Go, Node.js, Dart, Bun, Deno, .NET — с методологией, конфигурацией и сырыми цифрами лежат на GitHub. Под катом — сама история. Не технический отчёт, а инженерская драма: как 2 недели ушли на перенос архитектуры, почему всё выглядело идеально на бумаге, и как гипотеза с "экономией памяти" разбилась о реалии raw benchmark. И ещё — почему AI-агент сделал всё правильно, и именно это оказалось проблемой.

Мы пытались отправлять уведомления о деплое из GitLab CI в MAX Messenger и долго шли по ложному следу, потому что проблема выглядела как сетевая. Но MAX API честно подсказывал обратное: proto.payload означал, что запрос доходит, а ломается именно body. В итоге решение оказалось не в DNS, а в минимальном JSON payload, очистке переменных окружения и отказе от хрупких shell-конструкций внутри CI job.

Нужен был реестр артефактов. Показать студентам цепочку поставки софта: сборка, тесты, push в реестр, деплой. Стандартная задача, казалось бы. "Вошли и вышли, приключение на 20 минут."

Растянулось на несколько месяцев.

В итоге написал свой реестр. Один бинарник. 7 форматов. 12 МБ RAM. Без базы данных.

AI-агент для управления VPS через Telegram

В прошлой статье я показал идею: AI-агент на VPS, который позволяет управлять сервером через Telegram и практически забыть про SSH.

Главный вопрос в комментариях был один: «Как это повторить у себя?»

В этой статье — полный разбор и готовый open-source комплект, который можно развернуть за ~10 минут:

docker-compose конфигурация

набор bash-скриптов для управления сервером

конфиги агента

deploy-скрипт

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

Ваши логи забиты попытками входа в .env, .git и wp-login.php? Пока бот стучится в Nginx, ваш сервер уже тратит драгоценные ресурсы. Я решил перенести фильтрацию в ядро Linux и делюсь рабочим кейсом эшелонированной обороны на базе ipset и CrowdSec.

Привет! Я Алиса, DevOps-инженер в KTS.

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

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

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

Разбираю как выглядит нормальный QA-пайплайн в GitHub Actions: от линтинга до E2E тестов на Playwright. С рабочими конфигами, кэшированием и уведомлениями о падениях.

Запущенный на сервере OpenClaw решает большинство задач, которые пользователи ставят перед агентами. Для личного использования, параллельных запусков и несложной автоматизации его возможностей хватит с запасом. Одного VPS перестает хватать, когда приходят они: пиковые нагрузки.

В продакшене пиковые нагрузки у OpenClaw появляются раньше, чем можно ожидать. И когда это случается, варианта остается два: подбросить в печь больше вычислительных мощностей или пересмотреть архитектуру. Если второй вариант вам ближе, то эта статья для вас. Сегодня мы разберем контейнеризацию в Docker, отказоустойчивый деплой через Kubernetes, а также управление stateful-хранилищем, без которого стабильный запуск нескольких инстансов невозможен.

Как правило, разработчики, да и тестировщики не всегда могут заранее предусмотреть, какие именно некорректные входные данные придут в их веб-приложение. Привычные методы тестирования — ручные, интеграционные и даже unit-тесты — хорошо справляются с ожидаемыми сценариями. А вот для проверки непредсказуемых нужны другие подходы.

Привет, Хабр! Меня зовут Алексей Ломай, я младший системный инженер отдела DevOps в IBS. В этой статье расскажу о фаззинге как о мощном инструменте тестирования безопасности веб-приложений. Поговорим об истории и развитии подхода, о доступных инструментах и двух вариантах реализации в CI/CD.

Я посадил AI-агента на свой VPS и перестал открывать SSH. На сервере крутится дюжина Docker-контейнеров — клиентские проекты, SaaS, мониторинг, базы. Раньше любая мелочь требовала SSH: глянуть логи, рестартнуть контейнер, проверить место на диске.

Теперь я пишу в Telegram «память за 90%, разберись» — и через минуту получаю ответ: что случилось, что починил, сколько памяти сейчас.

В статье — реальные сценарии: SQL-запросы к PostgreSQL из Telegram, автодиагностика упавших сайтов, правка конфигов, мониторинг с авторестартом и управление задачами в YouTrack. Всё через кастомные shell-скрипты и AI-агент OpenClaw.

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

По данным Большого опроса сообщества Инфостарт за 2022, 2023 и 2025 годы, владение практиками автоматизированной сборки, тестирования и деплоя все заметнее связано с ростом дохода. Если упростить вывод до одной фразы, он будет звучать так: рынок начал платить не только за код, но и за способность поставлять изменения быстро, предсказуемо и без ручного хаоса.

Привет, Хабр! На связи — любопытный DevOps Владимир Лила, и это вторая часть материала о девконтейнерах по мотивам моего доклада для DevOps Conf. Этот материал посвящён одновременно практике организации работы команды и инструменту, реализующему эту практику.

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

Небольшой спойлер: в этой статье вас ждёт небольшой полезный подарок!

О том, как одна базовая задумка – сделать разработку управляемой, пережила эпоху тяжелых каскадных проектов, DevOps, CI/CD, и подошла к 2026 году уже в совсем зрелом виде.

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

В своих предыдущих статьях (раз, два, три) я рассказывал о зарождении идеи и первых шагах разработки Telegram-бота для управления серверами. То, что начиналось как простенький Python-скрипт для проверки uptime и перезагрузки парочки личных VPS, за последние месяцы обросло «мясом» и превратилось во взрослую экосистему с паттерном Agent-Server, своим WebUI, WAF и PWA.

Сегодня я хочу поделиться опытом, который я получил в процессе масштабного рефакторинга (от версии 1.13.0 до актуальной 1.21.x), рассказать о граблях, на которые я наступил при работе с памятью и сетью, и сравнить свой продукт с тем, что уже есть на рынке.

Сразу оговорюсь: хоть я и числюсь единственным разработчиком, проект создается не в вакууме. Во-первых, для ускорения развития продукта я активно использую инструменты ИИ. Сейчас это модно называть «вайбкодингом» (vibe-coding), но в моем случае это осознанный вайбкодинг. Я не перекладываю на нейросети проект целиком, а использую их для автоматизации рутины, сохраняя при этом полное понимание каждой строчки кода, его структуры и заложенной архитектуры. Во-вторых, у меня есть боевой товарищ — друг-тестировщик, который использует панель для своих повседневных задач, нещадно ломает новые фичи на проде, репортит баги и вносит огромный вклад в развитие. Именно благодаря такой живой обкатке инструмент получается действительно юзабельным. И, забегая вперед, вы тоже можете присоединиться к этому процессу!

Как в одиночку собрать полноценный сервис мониторинга с проверками из 10 точек мира, алертами в Telegram/Slack и собственным агентом? Делюсь личным опытом выбора стека: почему FastAPI выиграл у Django, как TimescaleDB справляется с миллионами строк логов и зачем писать агент на Go, если основной код на Python. Только практика, архитектурные решения и честный расчет стоимости инфраструктуры в €11/мес.

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

Отзывов на профиле нифига, решил от скуки написать автору. На первый взгляд всё оказалось прозрачно. Он расписал пример того, как устроен один из блоков. Подумал немного и получил заветный PDF-файлик.

Device plugin умеет выделять только целочисленные ресурсы: одну карту, две карты — или одну MIG‑партицию, но не «полкарты» и не «30% памяти». В реальности же нужны доли памяти, учёт топологии, предсказуемые обновления и изоляция, а не пулы лейблов и кастомные шедулеры. Разобрал, почему индустрия устала от костылей, как это проявляется в настоящем AI‑кластере и что именно пытается исправить DRA. Читать, если хотите управлять ресурсами явно, а не тушить пожары по расписанию.