DevOps *

Один из самых распространённых вопросов от стартапов и разработчиков: «Нам нужно зарегистрировать программу в Роспатенте — это же обязательно для защиты?»

Нет. И это не единственное заблуждение вокруг регистрации программ для ЭВМ.

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

Играешь или играл когда‑то в Dota? Тогда я уверен, что ты сможешь научиться DevOps и стать в нём одним из лучших. Включай внимание и вникай, если ещё не вкатился в IT, либо готовься опровергать мой спич.

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

Уже начинаете понимать, к чему я клоню? Да, это очень похоже на реальную жизнь, в принципе: наши уровни — это как минимум наши годы, с течением которых мы становимся старше и встречаем «новые» проблемы. Мне нравилось играть, и я хотел с таким же интересом работать на своей будущей работе. Пока я учился, я узнавал новые приёмы и места, где их применять. Так я изначально и познакомился с компьютерными сетями: с тем, как общаются маршрутизаторы и коммутаторы, да и с тем, как вообще устроен интернет. За любой компанией стоит инфраструктура, где запущены серверы, а серверы соединены в локальную сеть благодаря сетевому оборудованию.

Продолжаем серию про файнтюнинг и создание DevOps‑агента Oni. В прошлой части я встретился с реальностью — ни одна локальная модель не справилась с простой задачей «зайди на сервер, посмотри в контейнере backend — логи». Я решил попробовать дообучить модель на базе qwen3:14b. Раньше никогда не сталкивался с обучением моделей, и представление было такое: всё происходит по кругу — взял модель, обучил, протестировал, выявил ошибки, снова обучил, снова протестировал. И постоянно совершенствуешь одну модель, дообучая её. Как‑то так. Дошёл до oni:v8 с 11/11 на Django scaffold — а дальше любая попытка добавить новый скилл ломала старое: 11/11 → 9/11 → 4/11 → 4/11 → 3/11 → 0/11. Эта статья про то, как я сам себя дообучил в дообучении моделей.

n8n запускается одной командой docker run и через пять минут вы видите логин-форму. Это маркетинговый ролик. Реальный production-конфиг - с persistent storage, корректными webhook-URL, ретраями, бэкапами PostgreSQL и мониторингом - выглядит сильно иначе. В этой статье - конфигурация, которую я держу на 12 проектах в течение полутора лет. Плюс три грабли, на которые наступал лично.

Все примеры - community-edition, без коммерческой лицензии. На проде у меня сейчас крутится 2.19.5, но в image: стоит n8nio/n8n:latest плюс Watchtower (про него ниже) - он подтягивает свежий образ ночью. Внутри 2.x API/env-переменные стабильны, рекомендую :latest + Watchtower на проектах где простой 5 минут утром не критичен, и закреплённый минор (:2.19.5) - на проектах где даунтайм нельзя.

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

Я назвал его TLSS, или TLS Service — карманный pki сервис.

Каждый месяц с карты списываются деньги за подписки. Spotify, Яндекс Плюс, Notion, Obsidian Sync, Google One — суммы небольшие по отдельности, в сумме набегает заметно. Параллельно с этим у меня работает VPS с несколькими проектами, на роутере крутится OpenWrt с AdGuard Home, в ноутбуке стоит Docker. Инфраструктурный опыт есть. Дома при этом — никакого сервера, всё в облаке.

Это начинает раздражать не только из-за денег. Сервисы меняют каталоги без предупреждения, поднимают цены, требуют доплат за объём, периодически ломают регионы. Контроль над собственными фотографиями, заметками и медиатекой постепенно перестал быть моим.

Решил спланировать переезд на свой мини-ПК. Пока разбирался с железом и стеком, обнаружил, что нормальной системной дорожной карты «бери и иди» в 2026 году нет. Есть каталоги «50 self-hosted сервисов», восторженные посты про конкретные приложения, треды на Reddit. Структурированного маршрута для нового человека — нет.

Этот текст — попытка такой маршрут собрать. Не «топ приложений», а архитектура от железа до приложений по слоям, с обоснованием каждого выбора, с тем, что я планирую поставить, и с тем, что осознанно не ставлю.

Я делал AI Review как простой инженерный инструмент. Но реальный фейл оказался не в архитектуре и не в LLM — а в том, чего люди от него ждали.

В статье описаны результаты, которые получил в поисках ответа на вопрос «можно ли решать реальные задачи диагностики и исправления проблем инфраструктуры на слабом MacBook в агентском режиме (да, но)».

Нагрузочное тестирование — одна из самых избегаемых тем, когда речь заходит о контроле качества ПО. Корпорации, конечно, не обходят его стороной, но если говорить о продуктах меньшего масштаба, то нагрузочное тестирование часто пропускается. Команда (и, в целом, справедливо) полагает, что продукт справится с нагрузкой — на малых объёмах это обычно прокатывает. А потом внезапно наступает день, когда пользователей стало больше, а система не готова.

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

В CI/CD мы хотели простую штуку: на каждый PR запускать короткий перф‑смоук и получать ответ уровня «PASS / WARNING / DEGRADATION», а не 15 минут медитировать над CSV и тратить ценное время на анализ, который, вероятно, не пригодится в ближайшей перспективе.

Развернём нагрузочное тестирование на своих мощностях. Без ДД (долго, дорого). k6, VPS, сценарий на JavaScript, метрики в Grafana Cloud. Полчаса на настройку и встраивание в CI/CD. Для тестировщиков, разработчиков и всех, у кого есть пет-проекты.

Когда я начал разбираться, чем в open source можно закрыть задачу ASOC / Vulnerability Management, выбор оказался довольно грустным. По сути единственный известный вариант это DefectDojo. Сам я его в production не тащил, но от коллег регулярно слышал одну и ту же боль: на больших объёмах findings он начинает захлёбываться, в UI быстро не хочется заходить, а аналогов с человеческим интерфейсом и БДУ ФСТЭК «из коробки» в open source я просто не нашёл. Так и появилась моя ASOC-платформа: Go + PostgreSQL + Redis Streams + React, развёртывание одной командой docker compose up, миллион findings без тормозов (почти), обогащение из 7 источников, формула приоритизации, которая учитывает не только CVSS, но ещё EPSS, CISA KEV и БДУ ФСТЭК. В статье расскажу про архитектурные решения, грабли и почему я выкинул ORM ещё до первой строчки SQL.

Это не статья про готовый коммерческий продукт и не пиар-релиз. Скорее разбор того, как и почему был спроектирован Red Lycoris, open source платформа для централизованного хранения, дедупликации, обогащения и приоритизации уязвимостей. Я делаю её один, и если кому-то она пригодится, буду только рад. Если найдёте, где я ошибся в архитектуре, буду рад вдвойне.

В первой части я показывал agent-memory-mcp v0.1.0: MCP-сервер на Go + SQLite, который даёт AI-агентам persistent memory, semantic search и RAG по документации проекта.

Во второй части разбираю, что изменилось после нескольких месяцев реального использования. Почему fallback между embedding-моделями оказался опаснее отказа, зачем понадобились local-only режим и reembed, почему одного semantic search мало для инженерной памяти, как появились session close, Claude Code hooks, canonical knowledge, stewardship, sedimentation и multi-hop recall.

Это не changelog, а разбор эволюции архитектуры: как простой memory tool вырос в memory backbone для инженерных агентов — слой, который не просто хранит заметки, а помогает поддерживать актуальное, проверенное и полезное знание проекта.

Настраивать оборудование можно разными способами. Можно ходить от одной железки к другой и делать всё руками, но это медленно и непродуктивно, сгодится максимум для дома. Можно использовать скрипты, но это может не всегда работать и вызывать проблемы. А можно использовать подход, который сейчас называют Infrastructure as Code, то есть описать в каком состоянии Вы хотите видеть свою инфраструктуру, а программа сделает всё сама. Вот про одну из таких программ, которая активно завоёвывает рынок, мы и поговорим, а именно об Ansible.

Загнивая от усталости, дописывая последнюю строчку последнего (или не очень) модуля системы, теша себя мыслями о скорой зарплате, каждый уважающий себя философ задаётся вопросом - а как контролировать в бою всё то, что мы написали¿¿

Глупец скажет - никак, мы же покрыли тестами.

Хитрец скажет - Grafana+Prometheus отдельными сервисами.

Психопат на крайней стадии выгорания скажет - поднимем отдельную админку и будем собирать метрики и инциденты без прометеуса, снимая снимки системы каждую минуту асинхронными воркерами под каждый компонент платформы, включая сервер, базу данных, объектное хранилище и кэш. На лету будем высчитывать дельты серверных метрик, а в завершение отрисуем всё это дело без графаны, силами Recharts и Святого Духа, упакуем в отдельную панель для технических администраторов и наконец - сделаем клиентский status-page платформы.

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

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

На примере Modus BI разберём пять багов, которые нашли с помощью ручного тестирования. Это не история про «кликнуть по кнопке и сверить текст». Каждый кейс показывает конкретный тип логической проблемы...

Один из самых болезненных сценариев в IT-бизнесе: ключевые разработчики увольняются, открывают собственную компанию и выпускают продукт, подозрительно похожий на ваш. Или обратная ситуация — вы сам разработчик, который ушёл строить своё, а бывший работодатель уже звонит юристам.

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

Ручной деплой через SSH и bash-скрипты – это практика, которая рано или поздно приводит к инцидентам. В этой статье разбираем, как построить предсказуемый Continuous Delivery с помощью Ansible и GitLab CI. Обсуждаем реальный кейс миграции, пишем плейбуки, настраиваем zero-downtime rolling update и автоматические откаты.

Я работаю по ИП, поэтому не только пишу код, но и поддерживаю как DevOps свои проекты у заказчика. Эта история началась банально: я собирался в отпуск и хотел оптимизировать часть процессов, которые в повседневной жизни занимают время — чтобы не дёргать клиентов из-за вопросов по ошибкам, которые я мог не увидеть во время отдыха. Пусть локальная моделька сама разгребает типовое. Думал: запущу OpenClaw, подключу к локальной модели — и поеду спокойно.

Через две недели — вместо отпуска — я сидел и обучал Qwen3 на Nvidia RTX 3090 24GB, потому что ни одно из существующих решений у меня не работало. Дальше расскажу, как до этого докатился — с цифрами, граблями и бенчмарками.

Всем привет!

Хочу поделиться историей, как я решил попробовать сделать для себя тот самый саморазвивающийся ИИ-стартап и что из этого вышло.

Начну с предыстории. В 2022 году я переехал в Грузию, в Батуми. Здесь я практически сразу начал учить язык, и мне захотелось чуть упростить себе этот процесс — сделать это я решил с помощью своего Telegram-бота. Почему бота? Всем известно, что материал усваивается быстрее и проще, если не садиться за него раз-два в неделю, а стараться изучать что-то небольшое каждый день. Тут мне бы очень помог Duolingo. Но там грузинского нет, хотя есть клингонский. Короче, было решено сделать свой Duolingo из Telegram-бота, только для грузинского.

Сначала получилось что-то совсем простое: перевести / сохранить слово / устроить с новыми словами квиз. Долгое время этого функционала мне хватало, и бот я не развивал, но вот решил попробовать автоматизировать его при помощи современных LLM. Идея была такая — ночью агенты кодят. А утром я читаю чейнджлог и наслаждаюсь новыми функциями. Что получилось на деле —можно почитать под катом.

В эпоху вайбкодинга удивить кого‑то базовым веб‑интерфейсом сложно. Но сделать его понятным и простым в поддержке — другой вопрос. Если вы хотите обернуть свои скрипты\автоматизацию в красивую обертку, а также сделать это быстро и просто — я нашел для вас классную библиотеку на python.

Цель статьи — поделиться классным инструментом и замотивировать вас к созданию нового. Поехали!