DevOps *

В прошлом году я писал на Хабре про Telescope - инструмент для просмотра логов через веб-интерфейс. Тогда основной сценарий был связан с ClickHouse, и в комментариях логично возник вопрос: не "прибит" ли инструмент к одной базе данных.

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

В версии 0.0.24 добавлен ещё один тип источника логов - Kubernetes. Теперь Telescope может напрямую читать логи pod-ов через Kubernetes API, сохраняя ту же модель прав доступа и язык фильтрации.

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

Все, кто плотно сидит на C++ и использует Conan, знают: сам по себе пакетный менеджер — это только полдела. Настоящее веселье начинается, когда нужно раскатать одинаковые настрйки на всю команду и десяток CI-нод. Репозитории, профили, хуки, кастомные настройки всё это хозяйство нужно как-то синхронизировать.

Раньше у нас был conan config install, который тянул конфиги из git-репозитория или zip-архива. Решение рабочее, но с душком: попробуйте воспроизвести сборку двухлетней давности, если за это время мастер-ветка с конфигами улетела далеко вперед.

В Conan версии 2.x (и последних минорных обновлениях) завезли киллер-фичу: conan config install-pkg. Теперь конфигурация — это полноценный пакет. Давайте разберемся, почему это меняет правила игры.

CLI-обёртка над git worktree на чистом Bash. Автоименование worktrees, централизованное хранение в ~/.git-wt/, копирование .env файлов, shell-автодополнение и поддержка AI-агентов через SKILL.md. Сделана для параллельной работы нескольких Claude Code / Cursor / Windsurf на одном репозитории, но полезна и для код-ревью, хотфиксов и тестирования. Ноль зависимостей, установка за 5 секунд.

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

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

В прошлой статье я рассказывала о том, какие подходы и инструменты мы используем в «Базисе» для реализации DevSecOps. Сегодня же хочу поделиться своим опытом выстраивания организационных процессов безопасной разработки.

Казалось бы, права на чтение — что с них взять? Оказывается, в Kubernetes разрешение nodes/proxy GET позволяет выполнять любой код в любых подах кластера. Уязвимость уже нашли в популярных Helm-чартах, включая Prometheus, Datadog и Grafana. И да, команда Kubernetes решила это не исправлять.

Всем привет! На связи команда «Клаудмастер» («Инферит FinOps»). Хотим рассказать вам про то, как мы используем ИИ в нашей работе.

Помните март 2025-го? Дарио Амадей, генеральный директор Anthropic, обещает, что очень скоро почти весь код будет писать ИИ, регуляторы и рынок труда должны будут адаптироваться (ну вы поняли). 

Тогда мы с командой спешно затеяли эксперимент: решили проверить, каков реальный КПД от ИИ на практике и стоит ли нам в него вложиться.

Для многих технических специалистов AWX на протяжении многих лет был синонимом «бесплатного Ansible Tower» — надёжным и функциональным решением для управления Ansible-автоматизацией. Это был стандарт де-факто для тех, кто хотел получить удобство (практически) "коробочного" решения и функциональность корпоративного уровня, не вкладываясь в лицензии коммерческого решения.

Однако 2 июля 2024 года вышел релиз AWX версии 24.6.1, который стал последним на данный момент выпуском проекта. С тех пор прошло более полутора лет, а новых релизов так и не появилось. В репозитории проекта на GitHub висит предупреждение: «Releases of this project are now paused during a large scale refactoring». Для сообщества, активно использующего или планирующего использовать AWX как основной инструмент централизованного управления Ansible-автоматизацией, эта ситуация вызывает закономерные вопросы: Что происходит с проектом? Есть ли у него будущее?

Для конечного пользователя не совсем очевидно, но AWX не умирает, а кардинально трансформируется. В данной статье мы разберем текущую ситуацию вокруг AWX, опираясь на официальные анонсы, технические дискуссии разработчиков и статусы ключевых проектов. Проанализируем архитектурные изменения проекта. Разберемся, почему эти изменения были неизбежны, что именно было «вырезано» из проекта и что всё это значит для вас — инженеров ИТ инфраструктуры и архитекторов автоматизации, которые используют AWX в своей работе и проектах.

Вы когда-нибудь писали плагин для semantic-release? А хотели бы? Если да, то идем дальше. Расскажу, как это сделать и самое главное это не сложно. А в конце Вас ждет репозиторий, который вам поможет начать проект.

Привет! Меня зовут Алексей, я работаю в команде Авторизации Банки.ру. Сегодня хочу познакомить Вас с тем, как можно написать свой плагин для semantic-release.

Цель проекта — проверить отказоустойчивость Strimzi Kafka в Kubernetes с помощью chaos-экспериментов (Chaos Mesh). Для этого разворачивается полный стенд: кластер Kafka (KRaft, 3 контроллера + 3 брокера), мониторинг (VictoriaMetrics K8s Stack, Grafana), сбор логов (VictoriaLogs), верификация сквозной доставки сообщений через Redis и Go-приложения producer/consumer. Затем последовательно применяются chaos-сценарии (pod-kill, network partition, CPU/memory stress, IO/DNS/JVM/HTTP chaos и др.) и проверяется, что кластер корректно восстанавливается без потери данных.

У меня небольшой бюджет на AI-ассистент — $20 в месяц. Хватает, но только если понимаешь как работает тарификация. Я потратил время чтобы разобраться что именно ест токены, и написал framework который пытается решить эти проблемы. Расскажу про оба.

Шестая статья цикла о построении CDC-пайплайна с нуля. Данные уже текут из PostgreSQL в Kafka, но дальше просто исчезают по retention. Сегодня пишем Consumer на Python, реализуем криптографическую верификацию сообщений и строим трёхслойную архитектуру данных.

Утилита mise (полное название MISE-EN-PLACE) настраивает необходимое для разработки окружение:

Для разработчика это глобальный набор инструментов (от языков программирования до мелких утилит) нужных версий.

Для проектов это аналогичный набор инструментов (специфичных для этого проекта версий, одинаковых у всех разработчиков и на CI) плюс конфигурация (переменные окружения/зашифрованные секреты для конкретного dev/staging/prod/… окружения плюс локальные отличия) плюс задачи (скрипты) для сборки/тестирования/деплоя/….

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

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

Это история о том, как желание просто проверить, жив ли мой блог, привело к трём дням танцев с бубном вокруг SSL-сертификата, а затем — к созданию собственного сервиса мониторинга, который теперь используют сотни разработчиков. Расскажу, почему существующие решения перестали устраивать, как мы реализовали поддержку UDP и ICMP в облаке и почему мониторинг должен быть «скучным».

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

Проверять каждый вручную — мучение. Я нашел элегантное решение: связал Cursor IDE и свой MCP-сервер для проверки WHOIS. Теперь агент сам предлагает и сразу проверяет доступность доменов. В статье делюсь конфигом и показываю, как это настроить за 5 минут.

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

Если вы когда-нибудь сталкивались с задачей запуска сотен изолированных фоновых процессов на одном сервере (будь то парсеры для клиентов, торговые боты или обработчики данных в SaaS), то вы знаете, как быстро всё усложняется.

Можно, конечно, вручную поднимать Docker-контейнеры и писать костыли для мониторинга. Можно развернуть полноценный Kubernetes, но для одной ноды это часто — оверкилл, требующий отдельного администратора. Можно использовать Celery, но он управляет задачами, а не контейнерами, и изоляция на уровне процессов — это не тоже самое, что изоляция на уровне контейнеров.

Мы столкнулись с этой болью и написали инструмент, который закрывает этот пробел. Встречайте: RedTailFox — легковесный оркестратор на Python, который управляет Docker-контейнерами с вашими воркерами на одном сервере. Он сам решает, когда поднять новый контейнер, сам следит за здоровьем слотов и сам себя чинит.

09:12 — db-replica-02 connection timeout

HTTP 5xx = 0.2%
HAProxy зелёный
p50 = 38-42ms

Replica в другой стойке недоступна
Отказоустойчивость потеряна
Инцидент не объявлен

Недавно наткнулся на статью про Echovault на Хабре — инструмент для памяти AI-агентов, написанный на Python. Автор описывал ровно ту же боль, что и я испытывал месяцами. Идея хорошая, реализация — рабочая. Но Python. Я ничего не имею против языка, просто не мой выбор для инструментов, которыми пользуюсь каждый день. Люблю скомпилированные бинарники: кинул файл — и работает, без virtualenv, без pip, без «а какая у тебя версия питона». Поэтому я взял идею и переписал её с нуля на Go. Получился Pantry.

Расскажу, зачем это вообще нужно и что внутри.

Привет, меня зовут Станислав Пьянов, я DevOps-техлид в KTS.

За годы работы мы сформировали свою практику для аудита инфраструктуры. Мы не придумали для нее громкого цепляющего названия, но это не мешает ей приносить пользу. Она стабильно помогает нам выявлять и устранять недостатки в «подкапотном пространстве» совершенно разных бизнесов.

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

Всем привет! 👋

Запускаю серию постов по техничке антифрода — для подписчиков и всех, кто копает в сторону фрода

Разберём ежедневку: User-Agent, куки, хедеры, отпечатки устройств, IP и другие “невидимые” детали, которые отличают честных юзеров от мошенников

Начнём с базового, но ключевого — User-Agent. Покажу, что это и как его едят

Что такое User-Agent и зачем он нужен

User-Agent (UA) — это текстовая строка, которую браузер автоматически отправляет серверу при каждом запросе. Это как "визитка" браузера: сервер смотрит на неё и понимает, с какого устройства и браузера зашёл пользователь

Зачем это антифроду: — Мошенники часто подделывают UA, чтобы притвориться обычным пользователем с мобилки, когда на самом деле сидят с ПК через эмулятор — Если UA меняется между сессиями у одного пользователя — это красный флаг — Несовместимые комбинации (например, Windows + iPhone Safari) выдают фрод

Структура User-Agent: разбираем по кусочкам

Берём реальный пример:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36

Выглядит страшно, но на самом деле тут всего 5 частей. Разберём каждую из них

Часть 1: Mozilla/5.0

Это исторический префикс, который есть у всех современных браузеров — Chrome, Edge, Firefox, Safari, Opera и т.д.

В 90-х годах браузер Netscape назывался "Mozilla", и сайты проверяли эту строку, чтобы понять, что это современный браузер. Когда появились другие браузеры, они тоже начали писать "Mozilla/5.0", чтобы сайты их не отсекали как старые