DevOps *

Каждый composer install — это акт доверия: вы запускаете на CI и в проде код, который собрал и опубликовал кто‑то другой, а проверяете обычно лишь хеш в composer.lock. Но хеш отвечает на вопрос «тот же ли это байт, что вчера», а не «кто и из чего его собрал».

Реальные инциденты показывают цену этого доверия: в 2021-м в исходники PHP закоммитили бэкдор от имени Расмуса Лердорфа; в xz вредонос жил в release‑архиве, которого не было в git; у популярного GitHub Action переписали теги и слили секреты из тысяч пайплайнов. Между кодом на ревью и артефактом в вашем vendor/ — длинная цепочка, и атаковать можно любое звено.

В статье сначала разбор: как устроены эти атаки и почему GPG, хеши и composer audit закрывают цепочку лишь частично. Затем ответ индустрии — Sigstore: подпись без управления ключами. И главное — практика на PHP: подписываем релиз в GitHub Actions без единого секрета, проверяем эталонным gh, из CLI и прямо из кода с типизированным SLSA‑провенансом, мониторим журнал Rekor. С рабочим кодом и честной моделью угроз: что подпись ловит, а что нет.

Практически все современные системы управления инфраструктурой опираются на один и тот же фундаментальный механизм — сохранённое состояние (persistent state).

Terraform хранит состояние в .tfstate, Crossplane использует Kubernetes API как систему записи, GitOps-решения строят дополнительные слои поверх Kubernetes. Архитектурные различия между этими инструментами огромны, но их объединяет одна идея: между конфигурацией и реальной инфраструктурой существует некоторое долговременное представление мира, которое считается авторитетным.

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

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

В какой-то момент возникает вопрос: а обязателен ли вообще persistent state как архитектурный элемент? Можно ли построить систему, которая будет работать напрямую с реальной инфраструктурой, не поддерживая отдельный долговременный слой состояния?

Штатная ситуация оказалась задачей со звёздочкой: кластер кинул алерт о том, что заканчивается сеть подов, но ни одно решение «из методички» не подходило, а вытаскивать кластер из прода было нельзя.

В статье расскажу, как мы не просто расширили подсеть подов, но сделали это на работающем кластере и не потеряли при этом данные. Что важно — трюк сработает на любом дистрибутиве Kubernetes и CNI.

Если у вас приватные репозитории на GitHub и команда, которая регулярно упирается в лимит времени GitHub Actions, эта статья сэкономит вам пару недель экспериментов. Рассказываем, как мы подняли self-hosted раннеры в Docker, настроили их репликацию через Docker Compose и почему в итоге пришли к Docker-in-Docker. Разобрали по шагам эволюцию решения от Bare Metal раннеров до докеризованной конфигурации. Репозиторий с настройкой находится в открытом доступе.

11 июня 2026 HashiCorp перевела в GA официальный Terraform MCP Server 1.0 — прокладку между LLM и Terraform Registry, чтобы AI писал HCL по актуальной схеме провайдера, а не по памяти годичной давности. Разбираю по официальным докам: что под капотом (toolsets и конкретные tools), как поднять стенд за один docker run, чем отличаются stdio и streamable-http, что даёт доступ к приватному registry в HCP/Terraform Enterprise — и почему деструктивные операции выключены по умолчанию. Отдельно — модель угроз самой HashiCorp (prompt injection, tool poisoning, rug pull) и практический чеклист, чтобы агент однажды не снёс staging.

Запустил эксперимент: автономный AI-пайплайн принимает заявки игроков из Telegram, сам правит одну общую браузерную игру и без ручного ревью кода катит изменения в живой прод. Меряю, что при этом происходит с нагрузкой на меня как на человека-в-петле и с кодовой базой, включая техдолг. Это n-of-1, рассчитан на ~60 дней, итоговых выводов пока нет — показываю, как это устроено, почему такое не разносит прод, и зову участвовать.

Читать статьи и веб-материалы через суммаризацию от LLM — это уже почти норма. Даже один только разбор общей картины плюс диалоговые вопросы заметно поднимают эффективность обучения.

Но такой способ замыкается в одной сессии. А то, что по-настоящему определяет качество исследования и обучения, — это инсайты, рождающиеся из связей между материалами, прочитанными в разное время.

Удерживать эти связи силами человека тяжело. У памяти есть предел: детали статьи, прочитанной полгода назад, забываются. Держать в голове отношения между статьями — где они противоречат друг другу, где дублируются — это высокая нагрузка.

В апреле 2026 Андрей Карпатый опубликовал в X паттерн построения персональной базы знаний (LLM Wiki) с помощью LLM. Твит вызвал большой резонанс, и позже подробности были выложены в GitHub Gist.

Я прогонял этот паттерн месяц — и сильнее всего почувствовал, что настоящая сила LLM не в суммаризации, а в умении связывать. (В Obsidian это видно в graph view: узлы — это страницы, рёбра — [[wikilink]] между ними.)

Структура статьи: сначала разбор того, что такое LLM Wiki, затем два конкретных примера инсайтов от «связывания», потом шаги по внедрению — и в конце про потолок: про то, что узким местом оказывается чтение и понимание самим человеком.

В первой части я ускорил большой интеграционный pytest-сьют с получаса до полутора минут за счёт инфраструктурных правок. Во второй проверяю следующий очевидный слой оптимизации — pytest-xdist.

Результат оказался не магическим, но полезным: -n auto дал ещё ×3.4 локально и около ×2.7 в CI. В статье показываю, почему xdist не заменяет дешёвый setup, а только домножает его; как разводить БД и Redis по воркерам; где упираются соединения Postgres; и почему память Docker VM и тюнинг Postgres не сдвинули потолок.

Про безопасные миграции написано уже тысячу раз. Мы все наизусть знаем и про expand/contract, и про обратную совместимость, и про то, что схему нельзя ломать под трафиком. А потом всё равно наступаем на эти грабли.

Вот свежий случай. Была задача на полчаса, надо было переименовать две перепутанные колонки. Прод целиком не лёг, но за одну выкатку я собрал сразу два инцидента. Причём один прилетел изнутри сервиса, а второй снаружи, оттуда, откуда я вообще не ждал.

Дальше расскажу, как так вышло

Если у вас в начале июня внезапно завис git clone, а pip install начал валиться на каждом втором пакете — выдохните, дело не в вас и не в карме. С мая 2026 доступ к ключевым инструментам разработчика из России потихоньку деградирует. 8 июня Роскомнадзор предложил отрасли решение, и отрасль встретила его, мягко говоря, без оваций. Давайте по порядку: что сломалось, почему достаётся именно репозиториям, что это за «ГосVPN» такой, почему инженеры от него отмахиваются и что можно сделать прямо сейчас — без шаманства, обычной инженерной гигиеной.

Сразу одна важная вещь. Дальше я честно помечаю, где у меня твёрдый пруф, а где — реконструкция по одному источнику или просто разумное предположение. РКН официально отрицает блокировки PyPI и GitHub, часть атрибуций («это ТСПУ») технически правдоподобна по характеру сбоев, но ведомством не подтверждена. Так что местами я буду оговариваться — это не занудство, это честность.

Полгода назад я написал здесь разбор «почему VLESS работает» — он собрал 169 тысяч просмотров и под тысячу закладок. Я тогда уверенно заявил: REALITY не отличить от обычного HTTPS, поэтому он держится там, где всё остальное давно отвалилось. Прошло полгода — и оказалось, что я был прав ровно наполовину.

В феврале ТСПУ перешёл на поведенческий анализ, а в июне — на то, что в чатах называют «заморозкой по fingerprint». И тут разом перестали подключаться мои собственные конфиги — и конфиги тысяч других людей. Приложение бодро рапортует «connected», а трафика нет. А привычный совет «обнови клиент» вдруг превратился в пустой звук.

Вот я и вернулся — посмотреть, что осталось от моих же выводов. Это разбор со стороны клиентского устройства — угла, который обычно недозанят. Что на самом деле творится в телефоне, когда «всё зелёное, а интернета нет». Как устроена новая детекция. И как измерить её самому, чтобы не потерять доступ к легальным сервисам, которые попали под ложные срабатывания.

Пара слов о том, чему верить. Тема скользкая, источников мало, и я не хочу делать вид, что у меня на руках спецификация системы. Поэтому дальше честно помечаю, где у меня твёрдый пруф, а где — реконструкция по одному источнику. Самое важное сразу: ядро всей новой схемы (разделы 2–4) собрано по одному структурированному первоисточнику — посту в Obsidian/Zapret, где автор разбирает поведение через инструмент dpi-ch. Это не выписка из документа РКН и не консенсус исследователей ТСПУ. Академические работы (ensafi/IMC 2022, gfw.report) такой схемы вообще не описывают — как и кодового имени, под которым она ходит в обсуждениях. Так что всё про конкретные пороги — «>3 хендшейка», «350–400 мс», «120/600 с» — это инженерная реконструкция чёрного ящика по одному наблюдению, а не доказанное устройство системы. Числа читайте как рабочие гипотезы.

В рамках проекта etcd-operator сообщество развивает оператор для развёртывания и сопровождения кластеров etcd в Kubernetes. На днях он был передан проекту Cozystack (CNCF Sandbox). Перед этим команда опубликовала написанную с нуля реализацию оператора с новой версией API — etcd-operator.cozystack.io/v1alpha2. Эта версия пришла на смену etcd.aenix.io/v1alpha1. Вместо управления узлами через StatefulSet новый оператор напрямую задействует штатный Membership API etcd (операции MemberAdd, MemberPromote и MemberRemove), что позволяет ему полностью контролировать состав кластера. Автор новой реализации — Тимофей Ларкин, один из мейнтейнеров прежнего оператора (старый код остался в ветке v1alpha1). Проект написан на Go и распространяется под лицензией Apache 2.0.

На третий день в проде мой support-агент на LangGraph и GPT-4o слил email одного клиента в переписку с другим. Причина банальна: модель вставила сырой контекст из базы прямо в ответ, и ничто в пайплайне это не проверяло. Фреймворки для агентов дают оркестрацию, вызов инструментов и память — но не безопасность. В этой статье разбираю стек из четырёх guardrails (валидация входа, валидация выхода, circuit breaker по расходам и проверка вызова инструментов), который умещается в ~200 строк Python и добавляет менее 40 мс latency. С рабочим кодом, схемой пайплайна и честным разбором того, что эти guardrails ловят, а что — нет.

Скриптов «забэкапь мне сайт» в интернете тысячи. Большинство падает на shared-хостинге, потому что там либо нет crontab -e, либо нет rsync, либо mysqldump лежит в нестандартном месте, либо у вас нет root, чтобы починить права на /tmp. А ещё — почти все игнорируют ротацию, и через два месяца ваш FTP забит 300 архивами по 200 МБ каждый.

В этой статье — рабочая схема для типичного клиентского сайта на Beget/Timeweb/Rusonyx-подобном хостинге, без панельных «бэкап-сервисов» за деньги, с дампом базы, ротацией и без хранения паролей в git.

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

В статье разбираем, как измерять архитектурный долг через метрики, находить реальные точки трения и не допускать превращения проекта в Big Ball of Mud.

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

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

Именно для этого существуют Deployment Strategies — набор подходов, которые определяют, каким образом новая версия приложения попадает в продакшен. В этой статье разберём самые популярные стратегии деплоя: Recreate, Rolling Update, Blue-Green, Canary и Shadow, посмотрим их плюсы и минусы, а также выясним, в каких сценариях каждая из них действительно полезна.

Привет, Хабр! Я Миша Онянов, Python-разработчик и платформенный инженер в крупнейшем проекте MAGNIT TECH – F&R. Из статьи вы узнаете, как с помощью механизма Cluster Policies в Apache Airflow вынести требования к DAG’ам в исполняемый код:

- Поговорим о том, когда и зачем нужен отдельный слой Policies.

- Посмотрим на примеры требований в больших data-инженерных проектах и способ их реализации с помощью политик.

- Покажу нашу архитектуру, примеры кода и способы внедрения.

- Сделаем выводы из моих ошибок, допущенных при разработке и внедрении.

- В конце посмотрим, в каких ещё системах используется аналогичный механизм.

Материал будет полезен всем, кто собирается внедрять или уже работает с Apache Airflow ✌️🥸

Я работаю в IT-консалтинге первый год и параллельно веду несколько пет-проектов вместе с Claude Code. И в какой-то момент меня начало беспокоить одно и то же:

«А код, который мне написал AI, вообще безопасный?»

Несколько личных проектов я собрал в связке с Claude Code, и раз уж большую часть code review я отдаю модели, то вполне реально, что куда-нибудь просочится:

Когда Docker-образ backend-приложения начинает весить 1,5 GB, это уже хороший повод хотя бы посмотреть, что вообще лежит внутри. Пока все работает, мало кто задумывается, сколько мусора, dev-зависимостей и ненужных файлов уезжает в production вместе с приложением. Но на самом деле от «лишнего веса» нужно избавляться, потому что каждый лишний мегабайт — это более долгие сборки и дополнительные сложности.  

В прошлой статье цикла мы закончили разворачивать инфраструктуру будущего РБПО: установили GitLab, Nexus, HashiCorp Vault, Dependency-Track и DefectDojo, подготовили отдельную виртуальную машину с инструментами безопасности и убедились, что все сервисы успешно запускаются.

Но установить сервисы — это только половина дела. Теперь их нужно настроить и подготовить к совместной работе. Без этого GitLab останется просто GitLab, Vault — просто хранилищем секретов, а DefectDojo и Dependency-Track — красивыми веб-интерфейсами без практической пользы.

В этой статье займемся базовой конфигурацией. Настроим GitLab и GitLab Runner, подготовим Nexus к приему артефактов, научим Vault доверять GitLab через JWT-аутентификацию и создадим необходимые сущности в DefectDojo и Dependency-Track.

Документация открыта, терминал запущен, банка кваса на месте. Начинаем настройку инструментов.