Вы написали docker‑compose.yml, подняли сервис локально, всё крутится. Задеплоили на сервер, запустили docker compose up -d, неделю всё нормально. А потом контейнер с Postgres тихо съедает всю память на хосте и OOM‑киллер убивает соседний сервис. Или приложение падает в два часа ночи, а Docker не перезапускает его, потому что restart policy стоит в дефолтном no. Или логи за месяц занимают 40 ГБ, и на диске кончается место.
Рубрика «devops» - 5
Ваш docker‑compose.yml сломается: 5 настроек, которые все забывают
2026-05-19 в 20:24, admin, рубрики: devops, docker, healthcheck, linux, oom killer, postgres, production, restart policy, контейнеризацияКак мы вывели в админку ошибки yt-dlp, которые жили только в логах. Bridge на 200 строк и борьба с alert-fatigue
2026-05-19 в 11:51, admin, рубрики: alert-fatigue, devops, fastapi, observability, python, yt-dlpПривет. Я делаю онлайн-сервис для скачивания видео, бэкенд на Python (FastAPI + yt-dlp). За месяц набрали ~1500 DAU и упёрлись в проблему: пользователи жалуются на «не работает», а в админке зелёные графики. История о том, как сделать видимыми ошибки, которые молча умирали в логах воркера, и почему первый же релиз пришлось переделывать из-за alert-fatigue.
TL;DR
-
У нас 3 ноды: master (FastAPI на :443) и 2 worker’а (Docker, yt-dlp). Воркеры падали в
unavailable/private/age-restricted, но эти ошибки никогда не доходили до админки — они умирали вdocker logs, где их никто не читал. -
Сделали bridge: воркер POST’ит ошибку в master по
Читать полностью »
Если ты хороший игрок в Dota 2, то ты хороший Devops
2026-05-11 в 16:46, admin, рубрики: beginners, devops, dota 2, games, linux, network, информационные технологии, старт карьерыИграешь или играл когда-то в Dota? Тогда я уверен, что ты сможешь научиться DevOps и стать в нём одним из лучших. Включай внимание и вникай, если ещё не вкатился в IT, либо готовься опровергать мой спич.
Без рук: автоматизируем нагрузочное тестирование изменений в CI
2026-05-10 в 18:16, admin, рубрики: devops, github actions, locomotive, LOCUST, performance testing, python, нагрузочное тестирование, производительность, регрессионное тестированиеНагрузочное тестирование — одна из самых избегаемых тем, когда речь заходит о контроле качества ПО. Корпорации, конечно, не обходят его стороной, но если говорить о продуктах меньшего масштаба, то нагрузочное тестирование часто пропускается. Команда (и, в целом, справедливо) полагает, что продукт справится с нагрузкой — на малых объёмах это обычно прокатывает. А потом внезапно наступает день, когда пользователей стало больше, а система не готова.
Хотел упростить мониторинг проектов и в отпуск — пришлось обучать свой LLM
2026-05-08 в 14:27, admin, рубрики: devops, Fine-tuning, llm, Ollama, OpenClaw, python, qwenЯ работаю по ИП, поэтому не только пишу код, но и поддерживаю как DevOps свои проекты у заказчика. Эта история началась банально: я собирался в отпуск и хотел оптимизировать часть процессов, которые в повседневной жизни занимают время — чтобы не дёргать клиентов из-за вопросов по ошибкам, которые я мог не увидеть во время отдыха. Пусть локальная моделька сама разгребает типовое. Думал: запущу OpenClaw, подключу к локальной модели — и поеду спокойно
Настройка GitLab CI-CD: понимаем принципы работы и запускаем первый pipeline
2026-05-04 в 23:36, admin, рубрики: continuous delivery, continuous integration, deploy приложений, devops, Docker executor, gitlab runner, pipeline, автоматизация сборки
Все найденные мной русскоязычные гайды не дают базового понимания того, как это работает, по большому счету это просто инструкции по настройке, причем под какой-то конкретный продукт и кейс: .net, Java, Node JS, etc.
Сепаратор для логов. Сжимаем логи для контекста LLM без потери читаемости
2026-05-04 в 4:13, admin, рубрики: compression, devops, llm-инструменты, logzip, mcptools, optimization, python, Rust, token managementЯ думаю, многим знакомо устройство под названием сепаратор-то, что отделяет сливки от молока. Моя библиотека logzip занимается примерно тем же самым - отделяет сливки больших логов, оставляя самую суть перед подачей их на анализ в LLM.
Предупрежу сразу - я не писатель, я читатель, но не мог поделиться результатами своей работы. Так что не прошу судить строго за подачу материала.
Началось все с того, что я здесь на Хабре прочитал статью https://habr.com/ru/articles/1026040/ камрада @sergeivskЧитать полностью »
Cursor всё сломал, но виноват не Cursor: как сжатие контекста превращает AI-агентов в бюро несчастливых случаев
2026-05-03 в 22:54, admin, рубрики: devops, инфобез, Искустенный интеллект, разработка«NEVER FUCKING GUESS! - и именно это я и сделал. Я угадал, что удаление staging volume через API будет ограничено staging-окружением. Я не проверил. Я не читал документацию Railway.»
- AI-агент Cursor на Claude Opus 4.6, письменное признание после удаления production-базы PocketOS
Привет, меня зовут Николай, я 23 года в DevOps, последние несколько лет - внедряю продукты Группы Астра. И за последний год я наблюдаю, как индустрия повторяет одну и ту же ошибку снова и снова: она продаёт AI-агентов как решение, а на деле продаёт проблему.
1. Инцидент, который всё запустил
Долгие миграции на старте сервиса — это не startup-проблема. Это ошибка в архитектуре релиза
2026-04-29 в 15:31, admin, рубрики: database, deployment, devops, kubernetes, migrations, postgresql, probes, администрирование, базы данных, миграцияКогда сервис поднимается по 8-15 минут, команда почти всегда начинает крутить одни и те же ручки: увеличивает initialDelaySeconds, добавляет startupProbe, поднимает progressDeadlineSeconds, иногда переносит миграцию в initContainer и считает, что стало «по-кубернетесному». Обычно это не лечение. Это способ аккуратнее завернуть проблему в YAML. Если тяжёлая миграция живёт внутри старта приложения, вы связали жизненный цикл Pod, rollout Deployment и поведение базы в один общий узел. А такие узлы в проде рвутся не там, где их ждут.
Есть очень узнаваемая картина. Новый релиз выкатывается нормально на staging, а в production внезапно «висит». kubectl get podsЧитать полностью »
Платформы разработки для самых маленьких и не только
2026-04-19 в 13:16, admin, рубрики: devops, heroku, Infrastructure, kubernetes, paas, platform engineering, Vercel, стартапНекоторое время назад я был участником команды, реализующей решение, на базе которого можно развернуть internal development platform. В первую очередь мы ориентировались на крупный enterprise с командами разработки от 150 человек, которым важны унификация, контроль, снижение когнитивной нагрузки на команды, безопасная разработка. Сегодня же хотел бы поделиться своими рассуждениями о платформах разработки немного под другим углом — не с учётом команд и процессов разработки (IDP всё-таки заточены в первую очередь решать проблемы в этой области), а с точки зрения зрелости самого разрабатываемого решения.