DevOps *

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

В статье разбираемся, почему культура поиска виновных делает инфраструктуру хрупче, как работает blameless‑подход, зачем командам error budget и какие управленческие механизмы помогают превращать инциденты в системные улучшения.

25 апреля 2026, пятница вечером. Jer Crane, основатель PocketOS, смотрит, как AI-агент Cursor удаляет его production-базу. Со всеми бэкапами. За 9 секунд.

Потом Jer спрашивает у агента — почему? И получает дословное признание: «I guessed instead of verifying. I violated every principle I was given».

Модель помнит правила. Цитирует их. И всё равно нарушает.

Это разбор трёх таких случаев — и трёх защит, которые я внедрил у себя после.

Локально docker-compose.yml обычно выглядит «рабочим» ровно до момента, пока сервис не уезжает на сервер. Потом внезапно заканчивается память, контейнеры не поднимаются после падения, логи разрастаются на десятки гигабайт, а Docker продолжает считать зависшее приложение живым.

В статье — пять настроек Compose, про которые почти всегда вспоминают уже после первого инцидента в проде: лимиты ресурсов, restart policy, healthcheck, ротация логов и работа с volumes.

В прошлой статье было показано, что обычный MacBook Pro M2 16GB может с оговорками решать инфраструктурные проблемы используя локальную LLM. В этой статье будут показаны результаты решения более сложных инфраструктурных задач на более тяжеловесных моделях.

Мой личный выбор - Qwen3.6-35-A3B для проблем, которые сформулированы общими словами, Gemma4-26B-A4B - для чётко описанных проблем. Далее обо всём этом подробнее.

Настройка CI/CD часто кажется новичкам чем-то сложным и доступным только DevOps-инженерам. На самом деле автоматизировать рутину Python-проекта можно всего за полчаса. В этой статье мы по шагам разберем, как с нуля настроить GitHub Actions для простого FastAPI-приложения: от автоматического запуска тестов и быстрого линтера Ruff до сборки Docker-образа и публикации его в Docker Hub.

GitHub Actions давно стал одной из самых опасных точек в supply chain. Ошибка в workflow может открыть доступ к секретам, токенам и инфраструктуре — именно так развивались атаки на tj-actions, Ultralytics и Trivy.

В статье разберем, как работают уязвимости вокруг pull_request_target, expression injection и сторонних actions, и почему «просто CI» сегодня требует полноценной threat model.

История о том, как сделать видимыми ошибки yt-dlp, которые молча умирали в логах воркера. Bridge на 200 строк, классификатор content vs infra, борьба с alert-fatigue.

Если вы разрабатываете на Битрикс24 и поддерживаете несколько окружений — тест, стейдж, прод — вы знаете эту боль. Настроил воронку, добавил пользовательские поля, написал робота с десятком условий, всё это поправил в карточке, назначил права. А потом нужно повторить то же самое на проде. Руками. Забыв половину.

Конфигурация CRM — это не код. Она живёт в базе данных, не попадает в git, и нет адекватного механизма переноса между окружениями. При этом объём этой конфигурации на реальных проектах значительный: десятки смарт-процессов, сотни пользовательских полей, сложные роботы с условиями, матрицы прав доступа, кастомные виды карточек. Всё это нужно как-то синхронизировать.

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

Мы прошли этот путь и в итоге написали набор Version Builder'ов для модуля sprint.migration, покрывающих основные сущности CRM Битрикс24. В этой статье — о самой задаче, подходе и подводных камнях.

Пишите в личку по вопросам.

Где-то с 2021 года программистам обещают, что: ИИ оставит их без работы, 30% мест исчезнут, дипломы обесценятся и вообще все станут бесполезными. В декабре 2025 это уже стало походить на правду, теперь, какой-нибудь Claude, действительно, выдает рыночный результат. А если сравнить стоимость генерации за ноль рублей с любой оплатой труда, то тут победить ИИ - крайне сложно.

Что касается профессий уровня аналитиков, то джуны не нужны, по моим ощущениям, с 2023 года, а на текущий момент вообще аналитики не особо нужны. Тут уже, к сожалению, так как в моей профессии присутствует слово аналитик.

Про замену управленческих кадров и уровня С, пошли прогнозы на конец 2026 года. Это уже касается лично меня и моей текущей работы. Но начиная с того самого 2021 года, я сменил 3 компании, пережил два кризиса в найме и как итог два ребрендинга собственной карьеры.

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

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

Когда продакшен падает в три часа ночи, строка ERROR Something went wrong не помогает никому. В статье разбираем, почему привычные текстовые логи быстро превращаются в шум при реальной нагрузке, как перейти на structured logging, зачем каждому запросу нужен request_id и как настроить нормальные JSON‑логи в Python и Go без лишней инфраструктуры.

Собрал MCP-сервер для Windows: 42 инструмента в 8 модулях

Тут собраны Services, Event Viewer, Task Scheduler, Processes, Network, Diagnostics, Observability, Safety. Одна команда npx windows-admin-mcp, и Claude Desktop / Cursor / Claude Code получают полный доступ к администрированию Windows. TypeScript, MIT, npm. Внутри: диагностика служб за один вызов, анализ трендов ошибок, отслеживание изменений в системе, защита от случайных bulk-операций.

Пользуюсь сам каждый день. Буду рад фидбеку: что добавить, что лишнее, где можно лучше.

Kubernetes, Go, LLM, нагрузочное тестирование, observability, AI‑агенты, CTE, API Gateway и безопасность — в мае у OTUS много открытых уроков для тех, кто хочет быстро погрузиться в актуальные IT‑темы без долгого выбора курса.

Собрали расписание на 18–28 мая: можно выбрать направление под свои задачи, посмотреть формат обучения и понять, какую тему стоит разобрать глубже.

Не так давно AI-агент для разработки кода (Cursor на базе модели Anthropic Claude Opus 4.6) получил задачу и выполнил её буквально. Слишком буквально. За 9 секунд он уничтожил базу данных компании вместе с резервными копиями. Когда его спросили об этом, агент ответил: "Я нарушил каждый принцип, который мне дали". Этот случай произошел в стартапе PocketOS

В этой статье я расскажу Вам, при помощи какого инструмента в Google Cloud можно избежать подобных ситуаций.

Подробно разберем что такое Agent Gateway, из чего он состоит, какие плюсы он нам даст, и стоит ли рассматривать его в проекте.

npm снова горит — и на этот раз атакующим даже не пришлось ломать код.

Разбираем свежую supply chain-атаку на node-ipc, где доступ к популярному npm-пакету получили через… просроченный домен за $9. Без взлома npm, без bypass 2FA — только forgotten password и DNS.

В статье: как payload крал AWS, SSH и .env, почему эксфильтрация шла через DNS TXT, почему SIEM почти ничего не увидел, как dormant-аккаунты становятся оружием — и почему подобные атаки скоро станут массовыми.

Если у вас есть CI/CD, npm-зависимости или production на Node.js — это стоит прочитать.

AI стал писать код быстрее, чем я успевал удерживать контекст работы. Код вроде написан, diff вроде разумный — но почему именно так, какие варианты отбросили, что обещали не трогать, куда делись follow-ups? Всё это жило в чате, а репозиторий видел только финальный diff.

Это третья статья серии про память AI-агентов. В первых двух — https://habr.com/ru/articles/1006756/ и https://habr.com/ru/articles/1033388/ — разбирал устройство Memory MCP Server: зачем агенту постоянная память, semantic search, грабли по дороге. Память помогла, но довольно быстро выяснилось, что «помнить» и «вести задачу до конца» — разные навыки.

В этой статье — про следующий слой: Solo Kanban, git-native delivery loop для одного разработчика и AI-агентов. Planning files, task workspace, risk-based gates, обязательный verify перед closure. Это не «новый Scrum для одного человека», а набор safety rails: минимальные файлы и gate’ы, которые не дают агенту потерять scope, пропустить проверку или оставить follow-up только в чате.

Внутри: pipeline с risk-based выбором tier’а, мини-пример сквозной задачи, связка с Memory MCP, антипаттерны из реальных кейсов (включая reviewer-LLM, который approveнул нулевую реализацию). Метод вынесен в отдельный фреймворк: https://github.com/ipiton/solo-kanban-framework (MIT, v1.0.0).

Задача звучит просто: взять чистый образ Linux, засунуть туда Docker, контейнерные образы, скрипты настройки — и сделать так, чтобы при первом запуске все заработало без единого обращения в сеть. Как консервная банка: открыл — и готово.

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

В начале года я рассказывал, как мы запустили программу подготовки DevOps-инженеров для вузов. Сейчас в программе участвуют почти 40 вузов, через курс прошли тысячи студентов. Некоторые выпускники уже работают в моей команде. Успех? Успех. Кажется, процессы отлажены, материалы написаны, нужно только их поддерживать. Однако прошлый год преподнес сюрприз. Обычно мы запускаем три потока обучения в год, но тогда партнеры решили иначе: один поток, но с тройным количеством участников. Больше ста преподавателей вузов, которым нужно получить актуальные знания, обновленные материалы и доступ к стенду. А у нас немного устаревший курс и мало людей на сопровождение. В общем, есть место для подвига.

Первая статья из цикла о каналах обмена сообщениями. Разбираем архитектурные дилеммы, конкурирующих потребителей, message storm, гарантированную доставку и лучшие практики команд, работающих с JMS и Kafka.

Цель: сделать мобильный прокси.

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

«Кто виноват и что делать?» — эти два вопроса, которые классики русской литературы адресовали обществу, сегодня как никогда актуальны для IT‑директоров и финансовых руководителей. Только «виноват» не конкретный человек, а не оптимально работающая инфраструктура, а ответ на вопрос «что делать?» — внедрять FinOps.

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