DevOps *

Мониторинг часто воспринимают как «ещё одну панель», на которую нужно иногда поглядывать. Открыть браузер, зайти в дашборд, проверить зелёные кружочки, закрыть. Но что, если сделать его частью вашего повседневного инструментария - как git, как curl, как любимая IDE? Именно для этого мы добавили в PingZen поддержку MCP.

Сегодня я расскажу, как мы превратили наш сервис в MCP-сервер с 126 инструментами, почему выбрали MCP SDK и как вы уже сейчас можете управлять мониторингом из Claude Code, Cursor и других AI-агентов. Без переключения контекста, без лишних движений - только нужные действия там, где вы работаете.

Привет, Хабр! Меня зовут Марат Мустафин, я ведущий системный архитектор в «Стрим 1С» группы МТС. Мы поддерживаем и развиваем внутреннюю 1С-экосистему для дочерних компаний, обслуживаем около 1000 пользователей и выпускаем релизы раз в неделю. В этом материале расскажу, как мы выработали подход, сочетающий современные практики DevOps (Development & Operations — разработка и эксплуатация/поддержка) со спецификой платформы, а также поделюсь процессами разработки и нашими ключевыми принципами.

«Стрим 1С» появился в группе МТС в 2021 году как продуктовая команда, которая закрывает автоматизацию ключевых внутренних бизнес-процессов дочерних компаний. У нас работают около 50 специалистов: разработчики, аналитики, архитекторы, QA-инженеры, а также Product Owners и CTO. Функции DevOps в основном закрываем силами архитекторов, но иногда привлекаем профильные команды под конкретные задачи. Формально наш «Стрим 1С» состоит из нескольких команд, отвечающих за свои продукты, но об этом расскажу чуть подробнее дальше.

За время существования «Стрим 1С» мы собрали экосистему, которая обеспечивает:

• еженедельные релизы с высоким уровнем качества, автоматизированный путь от разработки до публикации и надежной инфраструктурой с георезервированием;

• разделение ответственности между продуктовыми командами, отлаженные Agile-процессы с регулярными ретроспективами, а также культуру код-ревью (code review — проверка кода другим разработчиком) и коллективной ответственностью за качество;

современный стек мониторинга и наблюдаемости, комплексное автоматизированное тестирование и инфраструктура как код через Jenkins и Gitlab CI.

В этом нам помогли несколько принципов:

• Автоматизация рутины. Мы отслеживали повторяющиеся действия от сборки релизов до развертывания тестовых контуров и старались уменьшить число ручных операций. За счет этого команда тратит больше времени на бизнес-задачи.

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

• Наблюдаемость системы. Комплексный мониторинг позволяет заранее замечать проблемы и разбирать их по данным.

• Распределенная экспертиза. Разделение ответственности с инфраструктурными командами дает возможность каждому уровню делать свою работу профессионально, без распыления и в итоге повышает общую эффективность.

В этом материале я покажу, как мы реализуем эти принципы, как встроены в корпоративные процессы и как развили разработку 1С до полноценного направления.

Внедрили таск-трекер для ускорения — а команда стала тратить 40 минут в день на костыли. Рассказываю, как за полтора года у нас накопилось 11 обходных путей, почему онбординг новичков растянулся до трёх недель и что мы с этим сделали. Внутри — чек-лист «тормозит ли вас ваш инструмент» и пошаговый план действий.

У вас в GitLab несколько проектов с одинаковым CI? Или просто надоела копипаста в пайплайнах? Каждое изменение нужно отразить в 10 местах? Рассказываем, как сократить код на 56 %, убрать дублирование и сделать один CI для всей группы проектов. Шаблоны, матрицы и практика.

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

У одного из наших заказчиков вся инфраструктура расположена в Yandex Cloud и для доступа во внутреннюю сеть ко внутренним ресурсам компании а-ля Grafana, Prometheus, Elasticsearch и т.д. использовался VPN-сервис на базе Self-Hosted OpenVPN. При этом аутентификация пользователей VPN осуществлялась просто по локальным учетным записям на сервере через конфигурацию сервера вида

Меня зовут Дмитрий Синявский, я SRE в Ви.Tech, IT дочке «ВсеИнструменты.ру». В какой то момент я поймал себя на мысли, что вокруг DevOps снова спорят как в начале десятых: одни уверяют, что он умер, другие переименовывают все в platform engineering, третьи ждут, что ИИ наконец сделает всю грязную работу за инженеров. Мы с Владимиром Утратенко, который прошел путь от техподдержки до техдиректора и сейчас развивает платформу «Штурвал», спокойно разложили это по полочкам.

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

На любой DevOps-конференции рано или поздно возникает один и тот же момент. Слушаешь про архитектуру, пайплайны, масштабирование, observability — всё звучит разумно и красиво. А потом в голове появляется простой вопрос: «Окей, а чем вы это всё делаете?». То есть буквально: какие инструменты стоят под капотом, как они внедрялись, где с ними было больно и где они действительно экономят время команде.

Именно для таких бесед на DevOpsConf 2026 будет отдельное пространство — продуктовая аллея!

Привет! Меня зовут Иван Откидач, я DevOps-инженер в команде DBA. Моя основная специализация — NoSQL-базы данных, в частности Redis и MongoDB. С каждым месяцем количество Redis, находящихся на нашей поддержке, растёт, поэтому обеспечение их стабильной и надёжной работы — один из приоритетов нашего подразделения. В этой статье мы разберем, как устроен механизм отказоустойчивости в Redis Cluster и почему он может давать сбои в multi-AZ-инфраструктуре. Также покажем один из практических подходов к решению этой проблемы.

По данным Financial Times, AI-агент Amazon получил operator-level доступ к продакшену - и выбрал «удалить окружение» как оптимальный способ починить баг. 13 часов аутейджа. Собрал хронологию трёх инцидентов марта 2026 и разбираюсь, что именно пошло не так на уровне permissions, review gates и CI/CD.

ИИ‑фреймворки давно въехали в прод, но к ним часто относятся как к «научной приблуде», а не к ещё одному входу в ваши данные и инфраструктуру. Spring AI и ONNX крутятся где‑то между ML‑командами, продуктами вендоров и внутренними ассистентами, и на определённом этапе за ними перестают успевать архитектура и безопасность.

В марте в обзорах уязвимостей рядом всплыли несколько критичных багов именно в этих штуках. Там есть и SQL‑инъекции, и JSONPath‑инъекции, и обход проверки доверия при загрузке моделей. В статье разбираю, что это значит для тех, кто уже тащит ИИ в прод, и даю чек‑лист, который можно прямо отнести своей команде.

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

Выкатили приложение, а через час — таймауты? Redis отключился, а вы узнали об этом от клиентов?

В этой статье на реальном примере покажу, как Spring Boot Actuator превращает ваше приложение из «чёрного ящика» в прозрачную систему. Разберём:

➡ Что такое Actuator и зачем он нужен.
➡ Как настроить эндпоинты, чтобы не открыть дыру в безопасности.
➡ Какие метрики реально помогают найти узкие места (история, как мы ускорили приложение на 40%).
➡ Кастомные метрики для бизнес-показателей.
➡ Лучшие практики продакшена: liveness/readiness probes, изоляция портов, кастомные HealthIndicator.

Разбираем все горячие клавиши Claude Code — что делает каждая, когда нажимать и где подвох. Этот AI-ассистент работает прямо в командной строке и напичкан сочетаниями, о которых большинство пользователей даже не подозревает. Двойной Escape откатывает изменения в коде, Ctrl+B отправляет задачу в фон, а Shift+Tab переключает режим работы на лету. Мы разобрали каждую клавишу до винтика: в каком сценарии пригодится, где конфликтует с tmux или браузером и как переназначить под себя.

Всем привет! Меня зовут Антон Ильичев, я сетевой инженер в Авито. В этой статье расскажу, зачем мы централизованно собираем и анализируем маршрутную информацию с сетевых устройств, причём тут протокол BMP и как устроена наша система мониторинга. В конце вас будет ждать лаба на docker-compose, которую вы можете запустить у себя и посмотреть на систему в действии.

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

С конца 2025 года известная многим, кто работает с object storage, система Minio начала издавать тревожные сигналы: разработчики полностью перестали принимать новые правки, прекратили обновлять Docker образ, убрали веб-интерфейс из опенсорсной версии, а с 13 февраля проект на GitHub полностью заморожен и стал архивом. Можно провести связь с покупкой Broadcom компании VMware, которой и принадлежит Minio, и последующим выжиманием денег из клиентов.

Но мы не будем строить теории, есть вопрос интереснее: кто убережёт наши объекты, если не Minio? Давайте попробуем узнать на примере Garage и SeaweedFS. Мы будем бросать эти системы об стену, и смотреть, что получится на выходе. Так работает chaos testing. Наверное.

24 контейнера на одном VPS за $30/мес: Elasticsearch, Redis, MySQL, nginx, headless Chrome, llama.cpp и еще 18 сервисов. Реальные docker-compose файлы, конфиги nginx, потребление RAM каждого контейнера и честный список того, что не работает. Сравнение стоимости с managed-сервисами в облаке.

Привет, хабр! Решил поделиться с миром своим проектом, который делался в свободное время и был мне полезен на моей текущей работе. Ссылка на гитхаб https://github.com/simplepersonru/SimpleOntoDoc

Проект - генератор статического сайта документации для онтологической модели данных
Онтологическая модель данных — это способ формального описания предметной области, в основе которого лежат три главные вещи:

1. Классы (типы объектов, «сущности»).
2. Атрибуты (свойства этих классов).
3. Связи (отношения между классами).

Под катом:

+ Мотивация (зачем мне это нужно)
+ Как это выглядит (с опубликованным примером)
+ Как можно применить (зачем Вам это нужно)

AI дисклеймер - при написании статьи активно использовалась нейросеть головного мозга, будьте осторожны

Всем привет. Я Backend разработчик, в основном на Python и немного Go. Хотел бы рассказать про свой опыт оптимизации docker образов и написать некий «туториал». Он скорее будет полезен для разработчиков или начинающим DevOps. Для опытных DevOps инженеров, возможно будет мало интересного и полезного.

Привет, хабровчане!

Мы команда «Исходного кода» и уже полгода системно занимаемся нагрузочным тестированием (НТ). Раньше такие проверки были от случая к случаю - оттуда и взяли базу знаний. Сегодня хотим поделиться историей одного показательного фейла, который заставил нас пересмотреть весь подход и прийти к системе, которая показала себя, как работающая. 

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

Главный толчок был простой и жизненный: уже на стадии рассмотрения сервиса мы понимаем, какая нагрузка на него ляжет, поэтому мы выводили правило: «Сервис должен стабильно держать N запросов в секунду», и мы берем эту планку и начинаем работу.

Меня зовут Дмитрий, я руковожу отделом ИТ-инфраструктуры и сервисов в Ви.Tech, IT-дочке ВсеИнструменты.ру. Когда у компании одновременно есть свои датацентры, частное облако и несколько публичных облаков, вопрос стоимости вычислительных ресурсов быстро перестает быть бухгалтерской формальностью. Без понятной модели невозможно нормально распределять затраты, сравнивать варианты размещения и объяснять, почему одна и та же виртуальная машина в разных контурах обходится по-разному.

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

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

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

Поэтому дальше я сосредоточусь именно на частных системах виртуализации и на простом примере покажу, как посчитать стоимость 1 ядра CPU и 1 GB RAM.

Для простоты будем считать, что кластер виртуализации состоит из однотипных серверов. Допустим, в каждом сервере установлены 2 CPU по 64 ядра и 1024 GB RAM. Тогда стоимость сервера складывается из стоимости памяти, стоимости процессоров и стоимости платформы, куда входит все остальное: сетевые карты, материнская плата, корпус, блоки питания и прочие компоненты.