DevOps *

Привет, Хаброжители! Сегодня мы хотим рассказать вам побольше о нашем новинке: «Метрики программной архитектуры. Кейсы, повышающие качество ПО».

Это не монография, а сборник из десяти самостоятельных глав от десяти архитекторов (Форд, Фарли, Лилиенталь, Вудс, Роза и другие), объединённых темой измерения качества архитектуры. Единой теории в книге нет, но есть рабочий код, формулы и параметры оценки, которые можно перенести в проект сразу — от DORA-метрик и фитнес-функций до GQM-подхода.

По данным Stack Overflow Developer Survey, классический Visual Studio Code удерживает абсолютное лидерство среди IDE с долей 75,9%. Однако с каждым днем все больше на пятки ему наступают специализированные ИИ-форки: один только Cursor в 2025 году стремительно взлетел и забрал себе 17,9% рынка, а что покажут результаты 2026 года, нам еще предстоит узнать.

У разработчиков здесь есть два пути: полностью мигрировать на новый ИИ-ориентированный форк или прокачать привычный VS Code до его уровня. Оригинальный редактор за счет расширений хорошо адаптируется под любые современные задачи — от запуска ИИ-агентов до управления облачной инфраструктурой.

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

Привет, это Антон Пионтковский из команды Monium Metrics, и вместе с коллегами мы создаём observability‑платформу для сбора, хранения и анализа телеметрии Yandex Monium. Мы храним миллиарды метрик и обрабатываем 50 гигабайт логов в секунду, а внутри Яндекса с Monium работают 16 тысяч сотрудников.

Чтобы справиться с объёмом метаданных метрик Kubernetes, мы научились фильтровать их по времени. Сначала наивно с помощью линейного сканирования, и потому только для небольшого круга пользователей. Но результат нам так понравился, что мы захотели включить фильтр для всех. Поскольку первоначальный подход нельзя было скейлить, мы использовали специальный — range encoded bit sliced — индекс, и получили ускорение в 6–20 раз, а в удачных случаях — до двух порядков.

Расскажу, как мы дошли до такой жизни, как устроен этот индекс, и что потребовалось сделать, чтобы всё в продакшн‑среде работало быстро.

Что делать, если Docker Desktop и L2 multicast живут в разных мирах, а доказать failover кластера перед тегом v1.3.0 всё равно нужно? Под капотом: SSH-контейнеры, unicast keepalived, 9 PASS / 0 SKIP и пара неожиданных багов с Alpine и CRLF.

Всем привет! Хотел бы поговорить о мониторинге наших web, да и не только web, приложений, в первую очередь, о проблемах, с которыми мы сталкиваемся. В этой статье я буду использовать язык python и популярные сервисы, чтобы содержимое было максимально понятно большинству.

У GitPython есть защита от опасных опций git. Я передал ей --upload-pack=/srv/lab/helper.sh, она отказала. Передал то же самое записью короче, -u/srv/lab/helper.sh, и она пропустила: скрипт выполнился. Это CVE-2026-67324, уязвима 3.1.50, исправлено в 3.1.51. Ниже стенд, живой вывод обеих попыток и разбор, почему шестистрочная проверка промахнулась.

Изначально это был монолитный портал на Laravel 8, где user фронт и admin фронт лежали рядом с беком в одной папке. 

Проект ставился каждому клиенту на его собственный хостинг, и единого портала «для всех» не существовало, между клиентами отличался и бек, и фронт. 

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

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

Поэтому, когда появилось время, я занялся этим проектом. Сразу поставил рамку, фреймворк не меняю, остаёмся на Laravel 8. Хотелось не переходить на другой язык, не заниматься переписыванием всего огромного бека, отделить всё в модули и переписывать уже поэтапно отдельные куски.

Стандартная (для многих) история. Отдаём какие-то данные в реальном времени через server-side web-gRPC стримы.

Цепочка: балансировщик, дальше Envoy с grpc-web, дальше бэкенд. Все проверки зелёные: TCP поднят, хендшейк проходит, /healthz отвечает 200, в графане/slack'e тишина. А фронтенд у клиентов замёрз. И узнали мы об не от мониторинга.

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

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

В статье разберём, как OpenTelemetry объединяет телеметрию распределённых систем, где в этой архитектуре находится Collector и какие ошибки чаще всего мешают получить действительно полезную наблюдаемость.

В компании есть Kubernetes, GitLab с пайплайнами и стена дашбордов в Grafana. А деплоить всё равно страшно — по пятницам нельзя, релиз согласовывают в личке, о падении прода первым сообщает клиент. Если картинка знакомая, то у меня плохие новости в формате чек-листа. Ниже десять симптомов карго-культа с проверочными вопросами.

До этого момента мы изучали Terraform локально. Теперь пришло время применить эти знания в реальной среде.

В этой статье мы подключим Terraform к облачному провайдеру, создадим первую инфраструктуру, разберём процесс создания сети и виртуальной машины, а также сравним особенности AWS, Microsoft Azure, Google Cloud Platform (GCP) и Yandex Cloud. Несмотря на различия между облачными платформами, вы увидите, что принцип работы Terraform остаётся практически одинаковым.

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

Наша команда отвечает за подсистему оценки платежеспособности клиентов (в народе - скоринг). Стек - классический джентльменский набор для java команды - последняя LTS версия Java, Spring Boot (с Hibernate), база PostgreSQL, брокер сообщений RabbitMQ, авторизация через Keycloak, кэш Redis, собираем в docker контейнеры с помощью jib и деплоим в k8s через gitlab, arttifactory используем для хранения стартеров и библиотек.

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

С точки зрения кластеров k8s наша подсистема полностью изолирована и не зависит от других подсистем компании. Другими словами, все необходимые для работы подсистемы ресурсы мы хостим и поддерживаем сами. Redis, Keycloak, S3 - всё это работает внутри каждого из наших кластеров, обеспечивая достаточное резервирование. Всё, кроме Redis.

Хочу поделится с более конкретным примером и подробным описанием настройки плагинов для ArgoCD чем это описано в их офф документации.

В прошлой статье я писал о WIE - userspace эмуляторе, который через JIT позволяет запускать PE64 бинарники на Apple Silicon. Казалось бы проект шел хорошо - почему делаешь новое? Дело в том, что я уперся в ужасную скорость - 7zip реальный проект на 200+ мб сжимал в 80-100 раз медленнее, чем нативный macOS бинарник. И это исправить без радикальной переработки проекта и разрушения самой концепции невозможно. Поэтому его разработка к сожалению была приостановлена.

Но мне хотелось попробовать сделать то, что сохранит идею переноса бинарника одной OS на другую, но без JIT. И я нашел. И имя ему Kakehashi

Пользователи почти не сообщают о багах: напишет 1 из 20, остальные молча уйдут. На прод-логи мы посадили автономного ИИ-агента: 300 тысяч строк в сутки, цикл раз в полчаса, молчание в 9 случаях из 10 — и алерты с цифрами в Telegram. За 84 дня — 113 алертов, две пойманные галлюцинации и фикс. Внутри архитектура, экономика ($10/мес) и каркас, который собирается за день.

Два коммерческих сайта на WordPress, оба на одном VPS. Клиенты в одном городе, я сам в другом.

Начало июня. Клиенты жалуются, что сайт не открывается без VPN.

Мало ли, подумал я — ограничения, белые списки и т.д.

Потом сайт перестал открываться у меня. По проводу. Дома.

Три дня был потный танец с бубном:

Привет! Я Даниил, DevOps-инженер в KTS.

Недавно я поработал со Stackland. Концепция облачноподобной платформы с кучей коробочных сервисов на своем железе в закрытом контуре давно была любопытна нам (и нашим заказчикам), так что пройти мимо готового решения от Яндекса было бы преступлением. По горячим следам я решил написать эту статью, чтобы поделиться опытом развертывания Stackland на голом железе. Так что ниже вас ждет скорее не обзор, а туториал.

Коротко о том, как это было: сначала я подготовил L2-сеть, бастион с NAT, DNS и NTP, три сервера, образ Stackland и YAML-конфиги. Затем запустил sladm install и через час получил консоль, готовый мониторинг с визуализацией в Grafana и возможность по кнопке в UI поднять managed PostgreSQL, Kafka, ClickHouse и другие сервисы.

Подробнее о том, как это было, рассказываю ниже.

Grafana показывала, что горит, Mattermost доставлял уведомления, но после смены дежурного приходилось заново выяснять, кто занимается проблемой и когда ждать результат. Рассказываю, как мы собрали поверх них рабочее место с владельцами, ETA, общей историей, группировкой каскадных алертов, инцидентами и postmortem — без отдельной базы данных и без передачи управления состоянием LLM.

10 июля мы выпустили Monq 9.2.0. Если описать релиз одной фразой: пороги получили собственное рабочее пространство, научились учитывать расписание, автоматически находить свою КЕ в CMDB и хранить прогноз собственного состояния. Для работы на больших объёмах хранение порогов перенесено из PostgreSQL в ClickHouse, а связанный конвейер сервисов переработан.

Перед вами обзор обновления отечественной observability платформы зонтичного мониторинга от вендора. Тут не будет обещаний «предсказать любую аварию» и общих слов про AIOps. Разберём точную механику, новые фичи, работу дежурной смены, нюансы обновления и честную границу между тем, что уже работает в 9.2, и адаптивными порогами, которые появятся в 9.3.

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