DevOps *

Всем привет! Это моя первая статья на Хабре и я надеюсь и рассчитываю на вашу критику, дельные замечания, внимание и аплодисменты. Сим я начинаю серию статей посвящённых тому как создавать 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 нету (особенно после того, как почитаешь китайские форумы в поисках нюансов). Но если бы кто-то посидел заранее и собрал советы в одном месте - жизнь была бы немного проще )) поэтому делюсь.

Как запустить AI code review по git diff на своей машине через Ollama - без облака и API-ключей? Установка, конфиг и пример отчёта.

Десятилетия терминальных мультиплексеров, одна хроническая боль и маленькая тулза на C, которая наконец всё починила.

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

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

В разработке происходит ровно то же самое, только в роли зерен здесь выступают npm-пакеты. Плантация превращается в GitHub, а подозрительные примеси представляют собой вредоносный код в легитимном релизе. И вы узнаете о проблемах не по вкусу, а по инциденту в проде.

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

10 лет назад OpenVPN считался надёжным инструментом. Сегодня он блокируется за секунды. За это время сменилось пять поколений протоколов — каждый новый ро��дался как ответ на то, чему научился цензор. Это история гонки вооружений между математикой и политикой. И она ещё не закончена.

И где мы сейчас ?

🚀 Nginx на автопилоте: Как я перестал тратить время на конфиги и SSL

Бывает так: у тебя есть крутая идея для проекта, ты быстро кодишь бэкенд, но когда дело доходит до деплоя... Вечер превращается в бесконечную настройку Nginx, борьбу с Certbot, прописывание HSTS-заголовков и попытки вспомнить, как там правильно настраивается кеширование.

Знакомо? Мне — да. Именно поэтому я собрал nginx-template — инструмент, который превращает администрирование сервера в удовольствие. 🛠

Это не просто набор файлов, это полноценный пульт управления вашим сервером через один скрипт — manage.sh.

Почему вам стоит это попробовать:

🔹 Скорость деплоя: Добавление нового домена с автоматической выдачей Let's Encrypt занимает ровно одну команду. Без правок конфигов руками и перезагрузок.

🔹 Image Proxy из коробки: Хотите ресайзить аватарки на лету прямо через Nginx? Теперь это делается одной командой без сторонних микросервисов.

🔹 Умный CDN: Поднимайте кеширующие узлы для статики за секунды. Разгружайте основной сервер и радуйте пользователей мгновенной загрузкой.

🔹 Профессиональная безопасность: Конфиги уже оптимизированы под требования SSL Labs (рейтинг A+), включают защиту от эксплойтов и автообновление IP Cloudflare.

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

Пора тратить время на код, а не на настройку прокси. ⚡

🔗 Забирайте готовый стек здесь: github.com/Arlandaren/nginx-template

Понравился подход? Ставьте ⭐ на GitHub — это лучший способ сказать «спасибо» и поддержать развитие Open Source!

Последнее время вся моя работа связана с энтерпрайзом и бигтехом. Но так было не всегда. Лет 12-15 назад работал в производственной компании, и там довелось создать «на коленке» систему мониторинга для промышленного оборудования.

У компании были современные импортные станки с проприетарным софтом, дорогим обслуживанием. Непрерывное круглосуточное производство. Но собственная IT-инфраструктура была слаба – всего несколько разработчиков, а аналитики бизнесовые. Всё же бизнесу нужно было следить за оборудованием: кто работает, кто простаивает, кто отключает датчики. Крайне необходимо было снизить вероятность поломок и простаивания.

В статье расскажу, как «на коленке» собрали многомодульную систему.

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

Этот бинарник — sudo.

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

Вот о чём эта статья: что это за работа, как она обросла такой сложностью, и как маленькая программа на C справляется с ней лучше.

Монолит без тестов.
Деплой только ночью.
Пять минут гарантированного простоя на каждом релизе.
Логи — в файле.
О проблемах узнаём от клиента.

Малый/средний бизнес МФО, без отдельного DevOps-инженера.
“Специально обученный тимлид”, который знает, какие костыли подпирают систему.

Рассказываю, как из этого получился production baseline: Kubernetes, GitLab CI/CD и наблюдаемость, после которых релизы стали скучными.

На связи — Катя Лысенко и третья часть статьи о системе онбординга. В первых двух (ч.1 и ч.2) мы разобрали основы: как подготовить почву, выстроить маршрут и создать понятный трек для новичка. Но структура — это только половина системы. Вторая половина — то, что делает её живой: регулярная рефлексия, честный разговор и поддерживающая среда, где человек не боится расти и пробовать.

Привет, Хабр! (И тебе, страдалец, который три недели смотрит на мёртвого бота в Битриксе. И тебе, админ, который уже устал объяснять руководству, почему «оно перестало работать». И тебе, безопасник, который узнал, что данные компании летают через какой-то curator.pro и чуть не уронил кружку.)

Помните мою прошлую статью про разработку Битрикс-бота? Ту самую, где я рассказывал, как документация врала, облака смеялись, а трафик зачем-то летел через сторонние сервера? Так вот - продолжение банкета.

Спойлер: стало хуже. Но мы справились.