Можно построить идеальную инженерную платформу, которой никто не хочет пользоваться! 😁 И самое забавное, что с точки зрения инженерных метрик у вас всё будет прекрасно! Короче, сходил я тут к ребятам из подкаста «В SREду на кухне» поговорить о том, зачем инженерам продуктовое мышление. И, кажется, это одна из моих любимых тем! Я вообще считаю, что одна из главных проблем платформенных команд — мы слишком часто думаем о том, что и как построить, и слишком редко о том, зачем это кому-то нужно. В итоге получаем технически прекрасные решения, которые либо никто не использует, либо используют исключительно потому, что выбора нет. О чём поболтали: 1. Зачем инженерам продакты? И в какой момент внутренний инструмент вообще становится продуктом? 2. Как измерять успех платформы? Вот у вас 100% adoption. Это успех или просто разработчикам запретили пользоваться альтернативами? 😁 3. Зачем нужны контрметрики? Можно же здорово ускорить разработку, а заодно уронить надёжность. Или сделать супернадёжную платформу, на которой невозможно работать. 4. Алертинг как продукт. Почему даже такую сугубо инженерную штуку можно и нужно проектировать вокруг пользовательского опыта? 5. Кто вообще заказчик надёжности? И почему пользователь, заказчик и тот, кто за всё это платит, — далеко не всегда один человек? 6. Что важнее — надёжность или Developer Experience? И почему вообще приходится выбирать между этими двумя вещами? Ну и поговорили про SLO, исследования пользователей, продуктовые метрики и прочие штуки, от которых у настоящего инженера иногда начинает дёргаться глаз. В общем, если вы строите внутренние платформы, инженерные инструменты или просто хотите понять, зачем в инженерных командах нужны продуктовые менеджеры — рекомендую посмотреть! Смотреть и слушать: 📺 YouTube 📱 VK Видео 📺 Rutube 🎧 Mave Ну и приходите в комментарии спорить!

Писал как-то про DORA - метрики скорости и стабильности DevOps-процессов. В продолжение темы несколько слов о фреймворках SPACE и DevEx, нацеленных на разрабов. Их можно использовать в комплексе вместе с DORA.

SPACE - это фреймворк для измерения продуктивности разработчиков, разработан в Microsoft в 2021. Это акроним.

▪️Satisfaction and well-being (Удовлетворенность и благополучие) — насколько разработчики довольны своей работой, инструментами и балансом (оценивается через опросы). ▪️Performance (Производительность) — качество и результативность работы (не объем кода, а то, какой ценный продукт выдан в срок). ▪️Activity (Активность) — базовые количественные показатели (например, количество пулл-реквестов, сборок, коммитов — но только как часть общей картины, а не единственный критерий). ▪️Communication and collaboration (Коммуникация и взаимодействие) — как команды общаются, насколько прозрачно идет обмен знаниями и документацией. ▪️Efficiency and flow (Эффективность и состояние потока) — насколько легко разработчик доводит задачу от старта до финиша, не утопая в прерываниях и бюрократии.

DevEx (Developer Experience, опыт разработчика) - это концепция (и одноименный фреймворк), которая фокусируется на удобстве повседневной работы программиста. Она отвечает на вопрос: «Насколько легко разработчику делать свою работу, или же он постоянно борется с медленными билдами, плохой документацией и сложными процессами?».

В DevEx есть три главных измерения: ▪️Петли обратной связи (Feedback loops) — как быстро разработчик узнает результат своих действий (например, сколько минут собирается проект или проходят тесты). ▪️Когнитивная нагрузка (Cognitive load) — сколько лишней сложной информации в голове нужно держать программисту, чтобы просто внести простую правку (сложная архитектура, запутанный легаси-код). ▪️Состояние потока (Flow state) — может ли человек часами глубоко концентрироваться на задаче или его постоянно дергают на созвонах, в чатах и решают мелкие блокеры. DevEx исследует среду и «трение» (что мешает писать код быстрее и с меньшим стрессом). SPACE дает верхнеуровневый, комплексный взгляд на команду и продуктивность сразу по пяти направлениям. Вот тут и тут подробнее сравнивают эти подходы. #process

OpsDeck: собрал рабочее место DevOps-инженера в одном окне и выложил в Open Source Терминал здесь, Grafana там, пароль в KeePass, ранбук в Obsidian, а алерт уже прилетел в Telegram. Автору надоело постоянно прыгать между окнами, поэтому он собрал OpsDeck и выложил проект в Open Source. Внутри терминал понимает, чем закончилась команда, и предлагает спросить ИИ об ошибке. Локальная модель подхватывает знакомые команды из истории и заметок, Kubernetes можно открыть рядом с алертами, а пароль из KeePass использовать там же, не бегая между окнами. Для прода предусмотрен отдельный режим только для чтения. Получилось не просто окно с ярлыками на привычные инструменты. Разделы OpsDeck знают друг о друге и позволяют переносить контекст между задачами без постоянного копирования руками. А сколько всего туда уже успело поместиться, лучше видно в экскурсии по проекту.

Как в MWS Cloud Platform тестируют Kubernetes‑операторы В Kubernetes-кластер добавили новую ноду. Теперь cloud provider должен связать её с виртуальной машиной, заполнить внутренний IP и снять ограничение на размещение подов. Только происходит всё это асинхронно — тесту нужно дождаться обработки объекта и убедиться, что необходимые действия выполнены. В MWS Cloud Platform подобные сценарии проверяют при интеграционном тестировании компонентов Managed Kubernetes. С операторами задача ещё шире: за одним Custom Resource может стоять целая иерархия связанных объектов, а их состояния способны меняться в любой момент. Добавим зависимость от Kubernetes-окружения — и привычных подходов к тестированию бэкенда уже недостаточно.

Как мы с дружбаном сэкономили $1800/мес на google cloud В посте про followthrough я показывал, как мы оценивали результаты оптимизации в google cloud —> это была часть работы, которая шла несколько недель. Результат - на 40% снизили затраты на google cloud (см аттач) Собственно, по мотивам сделал скилл - вдруг и вам такое надо :) Главный урок:

Мерить расходы в облаке сложнее, чем их резать o__O.

Идеи-то все известные: выключить простаивающее, уменьшить раздутое, удалить забытое. А вот, к примеру: 1) настроить выгрузку в bigquery, чтобы видеть нормальную детализацию, 2) адекватно замерять простаивающее и неиспользуемое, когда у вас работающая инфрастурктура (тест, стейдж, прод) с вариативной нагрузкой 3) аккуратно накатывать эти изменения, при этом ничего не сломав, и откатывать, если не помогло (см followthrough как раз) В общем, пользуйтесь + скилл предусматривает настройку регулярных чеков - я себе поставил раз в 2 недели: https://github.com/BayramAnnakov/gcp-cost-review

Знаете, что такое Хабраэффект? Это ситуация, когда все решили зайти на ваш сайт одновременно. Ну и сайт, конечно, не вывез. Конкретно этот термин связан с популярной площадкой Хабр. Но вообще эффект замечен ранее и в документах значится, как Слэшдо́т-эффе́кт. Когда я участвовал в разработке платформы лояльности, у нас было старое легаси-ядро, без всяких кэшей и очередей. Вот оно и падало перед Новым годом, потому что не могло обслужить такое количество пользователей, желающих лояльности. Чтобы до такого не доводить и заранее понимать, где бутылочное горлышко по Голдратту, надо делать нагрузочное тестирование. 🔹Вот, например, Apache JMeter как раз для такого. Опенсорсный инструмент, написанный на Java, который симулирует тяжелую нагрузку на серверы и целые сети. Имитирует пользователей, отправляет HTTP-запросы, работает с API, базами данных и другими протоколами. Позволяет строить сценарии: авторизация, поиск, добавление данных и так далее. Там даже есть специальная Test IDE для создания и отладки тест планов. 🔹У Grafana тоже есть свой тестировщик нагрузки - k6. Они используют подход "тест как код", можно писать скрипты тестирования на JS/TS, хранить в репозитории и встраивать их в CI/CD. Нативно интегрируется с Grafana. 🔹Еще вариант - Locust, тоже опенсорсный. В нем тоже пишутся сценарии в виде скриптов, но уже на Python. То есть если у вас питонисты в команде, то можно не распыляться, использовать обычные библиотеки. Но есть и UI. 🔹А если у вас пишут на Scala, Java или Kotlin, то можно посмотреть на Gatling. Принципы те же, что и в предыдущих, язык другой. Высокая производительность, асинхронная архитектура. 🔹Ну и есть отечественный инструмент - Yandex.Tank, тоже опенсорсный, поддерживает разные генераторы нагрузки. Только тестируйте аккуратно, не уроните прод раньше времени 😉 #tools

В последние 3 недели делаю много PR-ов на пару с дружбаном, и, признаться, через день уже не сразу помню что и для чего я сделал, когда надо замерить эффект и тп. Поэтому у меня была открыта куча сессий в терминале , потому что в каждой из них была напоминалка, и из-за этого я даже не мог перезагрузить комп... В общем, полный mess Поэтому мы с дружбаном сели и подумали, что не дело это все, и запилили простую утилиту - followthrough. Эдакий журнал изменений и проверок, которые по каждому надо сделать, чтобы принять решение: оставлять или откатывать. Как работает: 1) когда агент что-то выкатывает, скилл просит записать: что поменяли, чего ждём - например, меньше ошибок определенного типа или ниже latency, и как это проверить 2) когда пришла пора проверить, то прилетает пуш - см аттач - и по клику открывает сессию с готовой инструкцией, что и как проверять. Я спецом пока не сделал запуск автоматом; как почувствую, что доверяю и все устраивает, включу и это 3) каждая проверка в итоге заканчивается вердиктом: сработало / нет / частично / непонятно или требует проверки позже из-за недостатка данных (например, трафика не было достаточно, чтобы вынести суждение) —> тогда проверка сама переносится. Вот, например, час назад пришла проверка счета за мониторинг в google cloud: 4 дня назад с агентом сделали оптимизацию, чтобы сократить расходы, и что ожидаем падения счета по этой статье с $66 до $9 в месяц. Собственно, вердикт - сработало, и даже лучше ожидаемого - ожидаемые затраты будут в районе $2.65 Мне супер полезно + я доволен, что появляется дисциплина каждый PR четко соотносить с ожидаемым эффектом, и культура followup-ов. А не просто катнули в прода и забыли. https://github.com/BayramAnnakov/followthrough

Агент с токеном из гита работает так быстро, что кластер не отличает его от атаки Пока ИИ-ассистент просто подсказывает фрагмент кода, риск детский, ну примет кто-то плохое предложение молча, ну утечёт лог с секретом. Совсем другое дело, когда агенту вручают токен из гита, облачные креды или ServiceAccount в кластере. Теперь он создаёт, меняет и сносит ресурсы с такой скоростью, что Kubernetes не поймёт, это атака или просто сработала слишком мощная автоматизация. И вот в эту секунду удобный помощник по продуктивности превращается в новую нечеловеческую идентичность со своими правами, зоной поражения и пропиской в вашей модели угроз. А инъекцию он подхватит откуда угодно, хоть из README, хоть из лога сборки, который никто и не думал считать опасным. Спорить, будут ли разработчики этим пользоваться, поздно. Уже пользуются. Обсудим, как удержать агента там, где его видно и можно остановить.

В фоне 3 дня без перерыва крутится self-evolve / founder-agi-researcher. Буду периодически сюда присылать интересные апдейты (надо прочитать, их уже 100+ штук за 14 часов и я уже не успеваю обрабатывать информацию) ⚠️ [OUROBOROS SYSTEM] BATCH NOTIFICATION (CONT.) --- tg_message_110.html --- L2 Tick 110 & L1 Tick 60: Closed-Loop Control (MOD-136) 🏃‍♂️ Что сделано (What): 1. Завершен фоновый процесс (Task-5052) по сбору данных. Из нового OSINT-отчета osint_pipeline_report_20260910_141827.md извлечены SOTA-паттерны управления (Agentic Deep Graph Reasoning и Prompt-to-Graph-to-Prompt control). 2. Сформулирован и внедрен инвариант MOD-136 (Closed-Loop Prompt-to-Graph-to-Prompt Control) . Отныне агенты не используют огромные монолитные промпты для сложных задач. Вместо этого они генерируют граф шагов, выполняют каждый узел изолированно, оценивают результат (Evaluation) и формируют новый промпт для следующего шага. 3. Запущен следующий L1 цикл глубокого сбора (Task-5081). 4. Начата подготовка к решению проблемы "Bitbucket 100MB limit", блокирующей git push на ветке evolution/mas-v102-mojo-transpilation (скрипт анализа истории коммитов в разработке). Зачем / Почему (Why): Монолитные промпты теряют контекст и приводят к "зависанию" логики. Подход MOD-136 (Prompt-Graph-Prompt) заставляет систему действовать детерминированно: каждый шаг проверяется перед началом следующего. Это предотвращает цепные ошибки. Какая Польза (Value): Вы получаете математическую предсказуемость исполнения задач. Агент больше не "сходит с рельсов" на полпути, так как граф контролирует передачу состояния (State Transfer) между шагами. Ваш 10-часовой марафон продолжает уверенное движение. Итерация 110 пройдена блестяще! 🚀 --- tg_message_111.html --- L2 Tick 111: Memory Audit & Git Resilience 🏃‍♂️ Что сделано (What): 1. Глубокий OSINT-поиск (Task-5081) продолжает анализировать новые документы в фоновом режиме. Передача состояния выполняется строго по графу, как требует инвариант MOD-136. 2. Идентифицирована причина блокировки git push (Bitbucket 100MB limit) на ветке evolution/mas-v102-mojo-transpilation . 3. Обнаружен огромный лог-файл 16_AI_graph_brain/telemetry_trace.jsonl (106 MB), который случайно попал в индекс и присутствовал в истории на протяжении десятков коммитов. 4. Подготовлен скрипт для удаления этого файла из всей истории коммитов с помощью git filter-branch . Зачем / Почему (Why): Сырая телеметрия не должна храниться в системе контроля версий, так как ее объем бесконечно растет. Блокировка git push со стороны Bitbucket полностью парализует распределенную работу команды (и других агентов). Простое удаление файла через git rm не поможет, так как его огромный размер останется в истории старых коммитов. Нужно полное хирургическое переписывание Git-дерева. Какая Польза (Value): Стабилизация DevOps-конвейера. После очистки истории вы снова сможете беспрепятственно сохранять свои наработки на Bitbucket. Никакие внешние технические барьеры не способны прервать наш 10-часовой марафон. Итерация 111 выполнена успешно! 🚀

Сетапим окружение с нуля Коротко: mise умеет сетапить не только версии языков под проект, но и настраивать все окружение, по сути упрощая настройку как машины так и проекта до буквально одного файла. Я буквально на этой неделе перевел на него и свои dotfiles (https://github.com/mokevnin/dotfiles) и проекты. Кто-то скажет, нафига мне это надо у меня все в докере. У меня на этот счет два соображения, даже если у вас язык в докере, снаружи часто есть разного рода cli, которые нужны всем (и нам и агентам). Сюда относятся cli агенты, терминалы, docker compose, kube, helm, git, google cloude, oh my zsh и еще тыща приблуд, которые хочется сетапить. И второе, есть немало людей, которые разрабатывают не только готовые приложения, но и библиотеки, например, я работаю с большим количеством опенсорса, где докера нет и нафиг не нужен (с ним тупо сложнее, а стейта там нет). Напомню, что mise (придеший на замену asdf) это, пожалуй, самый классный способ управлять версиями языков в конкретном проекте. Он работает универсально для любого стека и ставит ровно то что нужно чтобы работал конкретный проект делая сетап независимым. В принципе это давно существующая штука и под каждый язык есть менеджер версий (не путать с пакетным менеджером). Но mise пошел дальше и сделал декларативный способ указывать что засетапить, какие симлинки создать и так далее. Причем он не пытается построить абстракцию поверх существующих решений (как некоторые devops тулзы), в нем явно описывается что откуда ставить. А уже дальше, когда будет выполняться настройка, mise сам определит что конкретно запускать на текущей системе. Если у нас mac, то он не будет запускать apt, но запустит brew. Кусочек файла mise.toml:

[settings]
idiomatic_version_file_enable_tools = []
dotfiles.root = "~/dotfiles"
dotfiles.default_mode = "symlink"

[tools]
node = "26.7"
ruby = "latest"
pnpm = "latest"
overmind = "latest"
caddy = "latest"
docker-cli = "latest"
docker-compose = "latest"
fzf = "latest"

[bootstrap.packages]
"brew:libpq" = "latest"
"brew:vips" = "latest"
"apt:git" = "latest"
"apt:libpq-dev" = "latest"
"apt:libvips" = "latest"

[bootstrap.repos]
"~/.oh-my-zsh/custom/plugins/you-should-use" = { url = "https://github.com/MichaelAquilina/zsh-you-should-use.git", ref = "master" }

[dotfiles]
"~/.config/nvim" = "nvim"
"~/.config/mise/config.toml" = { source = "mise.toml", mode = "symlink" }

В общем я попросил клод проанализировать мою систему и проекты. В результате он добавил mise.toml в несколько основных проектов и полностью пересобрал мои dotfiles, удалив кучку всяких скриптов и make тасков. Заодно я попросил его подсказать, что еще классного есть в мире cli что стоит поставить. Он нашел десяток полезнях, которые я теперь юзаю. Например он поставил какую-то прикольную штуку, которая меняет поиск через "вверх" в терминале, когда жмякаешь эту кнопку, то он сразу показывает список всего что было набрано до этого.

Открытие дня. Все же знают dependabot, который обновляет зависимости всего и вся на гитхабе? Причем речь не только про пакетные менеджеры всех языков, но и например github actions и даже версии образов в Dockerfile. Так вот есть такое же решение, не привязанное к вендору. Небольшая предыстория. Помимо гитхаба у нас есть свой гитлаб с большим количеством реп, в котором так же находится инфраструктура запуска практик Хекслета. В нее входит репа с кучей Dockerfile под разные экосистемы, которые мы используем как базовые образы для практик запускающихся в браузере. В этой репе есть просто все что только можно себе представить: версии образов, версии дев тулов, версии зависимостей, причем часто указываемые напрямую в Dockerfile. Обновлять все это добро раньше было отдельным приключением. С иишкой стало проще, но один фиг это процедура, которой надо заниматься. А на днях делая очередное обновление, я подумал какого хрена, по-любому должно же что-то быть. Попросил клод найти и он нашел. Оказалось что есть такая штука как Rennovate, которая очень похожа на dependabot, но работает еще круче. Мало того, что она может обновлять все версии в стандартных случаях, так эта фигня умеет обновлять версии, которые заданы числами в разных местах за счет спец разметки:

# renovate: datasource=maven packageName=org.apache.maven:maven
ARG MAVEN_VERSION=4.0.0-rc-6
# renovate: datasource=java-version packageName=java-jdk
ARG JAVA_VERSION=25

Все это расставил сам клод и написал мне такую таску:

make deps-check 
images/base/Dockerfile            setuptools       83.0.0  -> 84.0.0
images/java-base/Dockerfile       java-jdk       25      -> 25.0.4+7.0.LTS
images/multi-language/Dockerfile  java-jdk   25      -> 25.0.4+7.0.LTS

Ну и все это добро отлично подключается к ci и шлет пулреквесты с обновками. Пользуйтесь

Перезапустили приложение, а все его файлы исчезли. В Kubernetes такое случается часто. Контейнеры могут удаляться и запускаться заново, а всё, что хранилось только внутри них, пропадает. Чтобы этого не происходило, приложениям подключают отдельные диски. Kubernetes сам находит или создает подходящее хранилище, подключает его к приложению и следит, чтобы данные остались на месте даже после перезапуска. Автор объясняет эту систему на простом тестовом кластере. Показывает, откуда берется диск, как Kubernetes его подключает, где искать ошибки и что проверять, если хранилище вдруг не заработало. Это небольшой гайд для начинающего сисадмина.

Почему Docker не всегда лучший выбор и чем его заменить Один бэкенд, одна база и nginx на дешёвом VDS с парой гигабайт памяти. Заворачиваешь всё в Docker по привычке, а дальше следишь за образами и логами, чистишь диск от старых слоёв, лезешь в цепочку DOCKER-USER, чтобы фаервол вёл себя предсказуемо, и на скудной памяти повышаешь риск словить OOM killer. К обычному Linux ты просто добавил вторую систему управления, которую надо понимать не хуже первой. И вот тут выясняется, что контейнеры-то были не обязательны. Для одиночного сервера набирается целый ряд замен под разные задачи, а на одном из вариантов автор прямо роняет мысль, что иногда лучший контейнер тот, которого нет вовсе.

⚡️ Снизили стоимость AI-оркестрации на -92.5% при росте точности до 97.8%: Разбор Архитектуры Monosnap SOTA v3.3 Пока большинство промптит единичные модели, мы перевели нашу мультиагентную систему на 4-уровневый Гибридный Спекулятивный Роутинг (Tier 0–3) + 5-слойную защиту контекста. 🛠 Как устроена система под капотом: 1️⃣ Черновой слой (Tier 0 SLM): Amazon Nova Micro ($0.035/1M) за 100мс делает триаж и черновой patch. 2️⃣ Кодирующий слой (Tier 1): Claude 3.7 Sonnet на AWS Bedrock. За счет выравнивания промптов по границам 4096t получаем 90% скидку на чтение кэша ($0.30/1M). 3️⃣ Совет Судей (Model Council): OpenAI GPT 5.6 (логика) + Google Gemini 3 Pro (визуальный UI) верифицируют черновик с конформным порогом (>= 0.70). 4️⃣ Защита Контекста: Вынос логов в SQLite FTS5 (SearchOS Lake) + офф-тред субагенты удерживают активное окно контекста на уровне 6–11% (18K-22K токенов) даже после 500+ шагов! 📊 Метрики бэктестов (N=500 прогонов): — Стоимость 500 задач: $0.0185 USD (vs $0.2475 baseline, -92.53% экономии) — Качество кодинга (Pass@1): 97.8% (vs 81.6% baseline, +16.1 п.п.) — Латентность: 2.12s (vs 6.84s baseline, -68.9% ускорения) — Статистическая значимость: Z = 95.70σ 🖼 В аттаче — подробные схемы архитектуры общего оркестратора, кэширующего прунера и би-темпоральной памяти CoALA. #AI Architecture #Agents #LLM #DevOps #SOTA2026

Вышел TypeScript 7.0 стал быстрее в 10 раз. что сделали: - Переписали компилятор на Go → нативная скорость + многопоточность - Ускорение сборки: x7.7 – x11.9 на реальных проектах - VS Code (repo): 125.7s → 10.6s - Sentry: 139.8s → 15.7s - Playwright: 12.8s → 1.47s - Память: -6% до -26% - First error в редакторе: 17.5s → 1.3s (x13 быстрее) Реальные кейсы: - Slack: -40% времени merge, CI check 7.5 мин → 1.25 мин - Microsoft: -400 часов в месяц на сборку билдов - Canva: ошибки в редакторе 58s → 4.8s Вопрос: сколько стоит 1 минута ожидания в вашей команде? Это классический эффект второго порядка. Вы ускоряете не билд. Вы ускоряете итерацию гипотез. - Было: 5–10 циклов в день - Стало: 30–50 циклов А значит: - быстрее проверка фичей - меньше batch-thinking - выше скорость обучения команды Это уже не DevEx. Это growth-фактор продукта.

Сайты падают по расписанию рабочей недели, а в выходные почти нет В четверг сайты падают на треть чаще, чем в воскресенье. Серверам к концу недели не тяжелее, просто в выходные никто не деплоит и не трогает прод. Сайты ломают люди, а не энтропия. Та же логика в графике по часам: главный пик приходится на рабочий день, но пятый по аварийности час суток это полночь, когда стартуют кроны и ночные выкатки в духе «всё равно никто не смотрит». За год мониторинга 6 500 сайтов набежало 108 312 инцидентов, и картина выходит скучнее любых страшилок про взломы и DDoS. Половина всех падений это простой таймаут, когда сервер жив, но задумался. А самое обидное ждёт ночью. Короткие сбои чинит автоматика, которой всё равно, который час, но если она не справилась, длинные инциденты в темноте закрывают на 35% дольше, потому что дальше всё зависит от человека, а человек спит. Выясним, сколько сайтов на деле держат обещанные три девятки аптайма и что за аномалия случилась в июне.

Pico Claw. Настройка за 15 минут Примерно с мая этого года использую Pico Claw для агентских сценариев. Меня спрашивали что это и как его настроить — записал на эту тему ролик. PicoClaw — AI-агент, который ест <10 МБ RAM и работает на любом железе. Я сам лично его использую для проверки разных гипотез применения ИИ-агентов в моих задачах. Ничем не хуже опенкло и гермеса для моих задач, но весит в десятки-сотни раз меньше. В ролике — полная установка на пустой VPS: безопасность (SSH, fail2ban), установка одной командой, подключение к ИИ-мозгам (без VPN), веб-интерфейс, Telegram-бот и ограничение доступа по IP. Ссылки на ролик на всех площадках: 📹 YouTube | VK | Rutube | Dzen 📹