DevOps *

В прошлый раз я писал про рекурсивную задачу мониторинга: кто мониторит монитор? Если Prometheus упал — вы не видите ничего, и самое коварное тут в том, что отвалившийся мониторинг внешне неотличим от идеальной стабильности. Та статья заканчивалась честно и немного грустно: чистого решения нет, есть только слои подстраховки и остаточный риск, с которым приходится жить.

В российском вебе за неделю сломалось две вещи. 13 июня GlobalSign начал массовый отзыв сертификатов у российских компаний — до 20 000 доменов второго уровня под ударом. Let’s Encrypt 4 июня формализовал санкционные ограничения в новой редакции пользовательского соглашения. Я держу около десятка сайтов, все на Let’s Encrypt; сел и прошёл их по списку — какой issuer у каждого, кому грозит и в каком порядке, какие альтернативы реально работают в 2026 году. Внутри: пайплайн инвентаризации через openssl и crt.sh, конфиг Caddy с двумя issuer-ами в fallback, разбор Google Trust Services, НУЦ Минцифры и тех, кто уже выбыл (Buypass) или присоединился к ограничениям (ZeroSSL).

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

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

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

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

Теперь настало время собрать все эти инструменты в единый пайплайн. В этой статье напишем GitLab CI/CD-конвейер, который автоматизирует сборку приложения, проверки безопасности, генерацию SBOM и публикацию результатов в настроенные ранее сервисы.

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

Block (Square, Cash App, Tidal) рассказала, как у неё устроена разработка: внутренний Builderbot делает 200 000+ операций в день, мержит ~1500 PR в неделю и отвечает за ~15% всех изменений прод-кода. Фон невесёлый — всё это после сокращения ~4000 человек. Разбираю, что реально под капотом (Builderbot — control plane поверх открытого фреймворка Goose: Slack-тред → ветка → PR → CI-петля), и главное — что из этого может украсть обычная команда без своего фреймворка. Острый угол: на масштабе кодинг-агент — это не про модель, а про обвязку (CI, права, аудит, очереди PR), то есть чистый DevOps. Плюс честно про маркетинг в их цифрах и про 4000 человек за кадром.

Экран, в котором я живу 4 месяца. Не открываю IDE — всю god crm пишу внутри god crm.

Всё на скрине — строки одной postgres-таблицы. заметка, тикет, агент — одна сущность. поэтому заменило мне ноушн, обсидиан и мессенджер сразу.

Код открыт, mit: github.com/holetron/godcrm

Я больше года не пишу код руками — всё пишет ИИ. Но я не вайбкодер, и это две разные профессии. Рассказываю, в чём разница, почему она скоро будет стоить компаниям дорого, и при чём тут Git-клиент, который я написал, чтобы пройти корпоративную ИБ.

Типовая ситуация: Terraform-конфигурация выглядит привычно, а ИИ-агент экономит время на рутинных операциях. Но потерянный state-файл и один terraform destroy способны за минуты снести прод вместе с базой данных и снапшотами.

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

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

Эта статья написана по мотивам моего выступления на DevOpsConf 2026. Поговорим о Time-to-Market: как разложить его на части, найти узкое место и подобрать под это узкое место инженерную практику, которая действительно сдвинет метрику. Сразу предупрежу, что универсального рецепта на все случаи здесь не появится. Это и есть главная мысль всего материала.

Рассказываем и показываем, как можно использовать мониторинг за кастомизациями Битрикс24. Для работы используем телеметрическую инфраструктуру на базе OpenTelemetry Collector — проект github.com/bitrix-tools/b24-ai-starter-otel.

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

Open source всё чаще закрывает двери перед ИИ: Zig и NetBSD банят AI-generated контрибьюции, curl под потоком нейрослопа сворачивает баг-баунти. DHH, создатель Ruby on Rails, называет это новым луддизмом и гейткипингом. ThePrimeagen возражает: дело не в зависти, а в том, что мейнтейнеров завалили низкокачественными PR.

Мне понятна злость DHH: я сам видел, как в индустрии судят не код, а человека, который его принёс. Но не каждый запрет на ИИ — снобизм. Иногда это попытка сберечь внимание мейнтейнеров, защитить качество и юридическую чистоту проекта. В этой статье разберёмся, где проходит граница, и почему вместо вопроса «кто написал код?» пора задавать другой: «прошёл ли код наш пайплайн качества?»

4 июня 2026 вышла PostgreSQL 19 Beta 1. Все пишут про графовые запросы SQL/PGQ, но главная операционная новость в другом: в ядро завезли команду REPACK с неблокирующей опцией CONCURRENTLY — перепаковку раздутых таблиц без ACCESS EXCLUSIVE lock и без внешнего pg_repack. Разбираю по официальному анонсу и release notes: как это работает (спойлер — через слоты репликации, отсюда max_repack_replication_slots), чем отличается от VACUUM FULL и pg_repack, и что именно стоит прогнать на staging до GA — дисковый оверхед, documented-ограничения (команда не MVCC-safe!), бюджет слотов. Плюс честный разбор SQL/PGQ: GRAPH_TABLE убирает отдельный Neo4j для связей фиксированной глубины, но обходы переменной длины в бете пока не поддерживаются. Без ‘я проверил в проде’ — beta в прод не ставят.

Привет, Хабр! С вами эксперты ИнфоТеКС. В современной ИТ-индустрии контейнеризация стала неотъемлемой частью разработки и эксплуатации систем. Docker, как один из ключевых инструментов, прочно вошёл в повседневную практику. Однако с ростом сложности проектов, особенно в микросервисной архитектуре, возникает проблема, которая может существенно замедлить процесс разработки — скорость сборки Docker-образов.

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

В какой‑то момент у меня накопилось несколько VPS у разных провайдеров. Не десятки, но уже достаточно, чтобы каждый месяц ловить себя на одной и той же мысли: «А этот сервер когда оплачивать?»

Ссылка на биллинг — где‑то в закладках. Дата продления — в Telegram. Пароль от кабинета — в другом месте. Таблицы, заметки, все разбросано. Пока серверов немного, это ещё работает. Когда их перевалило за 15, начинаешь постоянно все терять. Кто хостер, а что там крутится, вкладки, вкладки, вкладки!

Так появилась идея: сделать личный кабинет для своих серверов.

Недавно на вебинаре Хайстекс разбирались реальные сценарии DR на практике. В чате трансляции зрители задали ряд технических вопросов, наиболее интересные из них легли в основу этого разбора.

Каждый 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 раннеров до докеризованной конфигурации. Репозиторий с настройкой находится в открытом доступе.