DevOps *

В данной статье описывается процесс реализации песочницы для регулярных выражений с помощью платформы для контейнеризации Docker и утилит Linux. Цель - получить ограниченную среду, куда пользователь может подключиться по SSH и где у него будет минимум возможностей, чтобы он ничего не сломал, но мог свободно использовать регулярные выражения как со встроенными в среду txt заготовками, так и со своим произвольным пользовательским вводом.

Всем привет! Меня зовут Анатолий Зотов, я системный архитектор SOC в RED Security. Как центр мониторинга и реагирования на кибератаки, мы должны быстро и внятно видеть, что происходит с железом и ОС на хостах: не кончается ли место на диске, не улетела ли память и не уперся ли CPU в потолок. Как это реализовать, да еще и безопасно?

Когда мы только приступали к задаче, первой мыслью, конечно, был Zabbix, как и у половины планеты. Но у нас никто не горел желанием поднимать еще одну систему, раскатывать агенты, подбирать шаблоны и разбираться с нюансами. Времени, как обычно, не завезли. А вот Grafana у нас уже была, поэтому я подумал — а что, если просто использовать то, что уже есть? Так я и наткнулся на связку «node_exporter → Prometheus → Grafana».

Эта статья для тех, кто хочет быстро начать мониторить хосты и не готов тратить вечность на внедрение тяжелой системы, особенно если Grafana уже живет в вашей инфраструктуре. Если Grafana и Prometheus у вас еще нет, то дополнительно расскажу быстрый старт через Docker Compose.

Я студент, который только начинает заходить в devops‑тематику. Сам я не админ и не держу в проде десяток серверов, поэтому решил не выдумывать «боли» из головы, а посмотреть, на что реально жалуются люди в интернете.

Одна жалоба повторялась достаточно часто: «Когда что‑то падает, приходится обходить несколько серверов, смотреть логи по отдельности и пытаться сложить картину вручную. ELK/syslog решают, но ради пары сервисов это перебор.»

После этого я решил собрать небольшой прототип LogRanger — CLI‑утилиты, которая по SSH забирает логи с нескольких серверов и открывает их в lnav одной командой. Ниже коротко расскажу, какую проблему хочу закрыть и что именно делаю.

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

Иногда компания ищет такого специалиста 2–4 месяца, проводит десятки интервью — и всё равно не находит подходящего кандидата.

Почему так происходит? За последние годы работы с техническим наймом мы выделили несколько причин, которые повторяются практически в каждом поиске.

Создать реплику PostgreSQL на базе в 1 TiB — задача, где быстро выясняется, что NVMe и сеть в 75 Гбит/с сами по себе ничего не гарантируют: упираешься в инструмент, который копирует данные в один поток. В статье разбираемся, как обойти этот потолок с помощью pgBackRest и параллельной передачи, какие настройки реально влияют на скорость, где легко потерять порядок величины на «мелочи» вроде хранилища под spool, и почему в PostgreSQL 18 внезапно стало лучше — но недостаточно.

OpenStack — это ваш собственный «Self Hosted AWS». Звучит пугающе, но с kolla-ansible развернуть его можно за вечер. Рассказываю как — от ip addr show до рабочего дашборда Horizon. Гайд, которого мне не хватало на русском.

Это перевод статьи с opensource.com, которая мне показалась особенно полезной и практичной, поэтому решил поделиться адаптированной версией для русскоязычной аудитории. Оригинал доступен по ссылке: https://opensource.com/article/22/10/docs-as-code

В статье разбирается подход Docs as Code — способ встроить документацию в процесс разработки так, чтобы она проходила через Git, ревью и автоматическую сборку вместе с кодом. Материал будет полезен разработчикам, тимлидам и тем, кто выстраивает инженерные процессы в команде.

Heartbeat-мониторинг — единственный способ проверить cron-задачи, фоновые процессы и устройства за NAT. Рассказываю, как работает эта технология в PingZen, и почему она проще и надежнее self-hosted решений.

В начале 2025 года компания MinIO в лице сооснователя Harshavardhana начала поэтапно сворачивать свою версию Community Edition. В феврале из open-source версии был вырезан веб-интерфейс администрирования - управление политиками, мониторинг, репликация, IAM - всё это переехало в коммерческий продукт AIStor с ценником от $96 000 в год. Пользователям оставили лишь базовый object browser и CLI-утилиту mc. В мае последовало удаление поддержки OIDC-аутентификации. В октябре MinIO прекратил публикацию Docker-образов и готовых бинарников - причём аккурат в момент раскрытия критической CVE-уязвимости. А в декабре 2025-го проект официально перешёл в режим maintenance mode: никаких новых фич, pull request'ы не принимаются, только точечные security-фиксы по усмотрению компании.

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

На Хабре уже есть материалы про базовую установку Synapse + Element, но моя цель чуть другая - показать сборку, где к Matrix добавляется внешний слой идентификации (OIDC), VoIP‑инфраструктура (LiveKit + TURN) и механизм подписанных обновлений Android‑клиента.

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

Всем привет! Это моя первая статья на Хабре и я надеюсь и рассчитываю на вашу критику, дельные замечания, внимание и аплодисменты. Сим я начинаю серию статей посвящённых тому как создавать SaaS продукты, как подбирать нишу, как его собственно программировать и отлаживать, как выводить на рынок и всё в таком духе. Поделюсь своим опытом, так сказать.

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

Итак, вашему внимаю представляю МЕГА ШАБЛОН УДОБНОГО БЫСТРОГО ПРОГРАММИРОВАНИЯ

«Чем же он так хорош?», спросите вы. И правильно сделаете что спросите! А я вам отвечу.

Казалось бы, сейчас мы наблюдаем всё, но факт в том, что не управляем ИТ-ландшафтом в целом. Упор на автономию команд и разрозненные инструменты приводит к «разрывам» в управлении: нет единой картины при инцидентах, SLA считаются в табличках, корреляция событий происходит «в головах людей», интеграции держатся на 1–2 специалистах, а построение CMDB и моделей ИТ ландшафта часто игнорируется. В этой статье мы постараемся переосмыслить роль зонтичного мониторинга, и докажем, что это не еще один мониторинг, а важный архитектурный слой.

AI-агент каждую сессию начинает с нуля — не помнит, что вчера разбирали архитектуру, какие баги нашли и почему выбрали именно это решение. Знакомо?
Я сделал open-source MCP-сервер на Go, который даёт агентам persistent memory с semantic search. Один memory-layer для Cursor, Claude Code и Codex — чтобы контекст не терялся между инструментами.
В статье — не обзор, а инженерный разбор: схема БД, embedding pipeline с fallback между провайдерами (и почему я в итоге от этого отказался), in-memory cosine similarity вместо vector DB, RAG-индексирование с инкрементальным обновлением, и реальные промпты для агентов.
Отдельно разобрал грабли: почему fallback между разными embedding-моделями — это не отказоустойчивость, а источник тихих багов, и как я это починил.

Google опубликовал в открытом доступе Google Workspace CLI — инструмент для системных администраторов, DevOps‑инженеров и разработчиков, которые управляют корпоративной инфраструктурой. Это интерфейс командной строки для администрирования и автоматизации работы с сервисами Google Workspace. Проект размещён на GitHub.

Фактически, это удобная прослойка между API Google Workspace и вашей консолью. Вместо того, чтобы напрямую работать с REST‑запросами, настраивать OAuth и обрабатывать авторизацию, разработчики получают готовый CLI‑инструмент. В нём уже есть описанные скиллы (команды) для типовых операций — управления пользователями, группами, файлами Drive, Gmail и другими сервисами. Это особенно удобно при создании AI‑агентов и автоматизированных сценариев. LLM может вызывать конкретные команды CLI, не дергая API напрямую и не усложняя логику авторизации.

Как мы превратили стрессовые ручные релизы в предсказуемый one-click процесс с GitOps и автоматикой. 60+ модулей, аудиторы и регуляторика — в едином шаблоне, который масштабировался на 30+ сервисов. Без магии, но с инженерной дисциплиной

Мониторинг мониторинга - звучит как масло масляное, но именно этим мы постоянно занимаемся в PingZen. Ведь наш сервис должен быть надёжнее, чем объекты, которые он отслеживает. Если PingZen упадёт, кто сообщит о падении вашего сайта?

Сегодня я залезу под капот тестирования PingZen и расскажу, как мы дошли до 10 900 автоматических тестов (5100 на бэкенде и 5812 на фронтенде). Все цифры и технологии - строго из нашего репозитория . Без хайпа, только факты, код и архитектурные решения.А статью подробнее про Pingzen можете посмотреть здесь

Кажется, мы все немного устали. Устали от унаследованного кода без владельца. От инфраструктуры, которая «как-то работает». От ИИ, который внедряют быстрее, чем понимают. От регуляторики, написанной на инопланетном языке. От SLO, которым вроде бы можно верить — но лучше бы перепроверить.

И на фоне всего этого — привычный формат конференции: два дня докладов, блокнот заметок, лёгкая эйфория… а через неделю всё растворяется в задачах.

Команда DevOpsConf в этом году честно признала: формат «послушал — вдохновился — пошёл применять» больше не тянет. Индустрия изменилась. И мероприятия тоже должны. Поэтому DevOpsConf 2026 проходит в новом формате — «конференция развития».

Расписание уже готово — можно изучить программу и собрать свой маршрут по стримам на официальном сайте. Давайте посмотрим, что получилось!

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

Однако со временем в компании была создана экосистема low-code разработки микросервисных программных продуктов Digital Q, которая позволила нашим производственным командам автоматически генерировать часть прикладного кода, что значительно ускорило разработку продуктов.

Как следствие внедрения экосистемы low-code платформ быстро росло количество продуктов и команд. В день мы делали уже более 2 000 коммитов от 100+ команд в 300+ микросервисах на 200+ проектах.

На этом этапе встал вопрос: как теперь быстро, полностью автоматически, выпускать и доставлять все это? Ответом стало решение «Диасофт» Digital Q.DevOps. Оно автоматизирует весь процесс (от сборки и выпуска продуктов до доставки на нужные стенды), включая такие важные этапы, как прохождение автотестов и проверки на уязвимости.

Привет, Хабр! Я много лет работаю в системной интеграции и занимаюсь внедрением различных проектов в области ИТ и ИБ. Меня попросили написать технический обзор MWS Container Platform, так что ловите то, что получилось. В этом материале подробно поговорим о стеке наблюдаемости (observability) и рассмотрим несколько практических кейсов по обнаружению проблем средствами стека. 

В последнее время открытых моделей сверхбольшого размера развелось неимоверное количество, даже не просто моделей, а производителей. Вариации GLM, Kimi, DeepSeek занимают по нескольку строк в топ 5-10-20. Понадобилось перебрать основные LLM для тестов и выбора "рабочей лошадки", для чего пришлось немного пошуршать в интернетах. Оставлю в качестве памятки, вдруг кому-то окажется полезным.

Всё делалось на базе образов vllm-openai, платформ B200/H200 и дров 590.48.01. На момент начала экспериментов - примерно пару недель тому назад - версии vllm 0.16 ещё не было, но, как выяснилось в итоге, это не сильно повлияло на ситуацию. Основные костыли остались теми же самыми. Разве что кастомизация образа не для каждой модели нужна теперь.

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