⚖️ Код-ревью: где ломается коммуникация

---

💬 Код-ревью – одна из самых опасных речевых ситуаций в разработке.

Не потому что люди злые.
А потому что формат провоцирует конфликт.

---

⚠️ Почему письменный формат всё усложняет

Когда говоришь голосом:
• тон
• выражение лица
• паузы

Всё это контекст.
Он смягчает, уточняет, корректирует.

В комментарии к PR этого нет.
Только текст.

«Здесь можно проще» – это предложение или претензия?
Зависит от того, как читатель себя чувствует в этот момент.

---

⚖️ Асимметрия ролей

Автор: вложил время, думал, старался.
Ревьюер: смотрит свежим взглядом, видит проблемы.

Автор в позиции защиты.
Ревьюер в позиции оценки.

Даже если оба хотят хорошего – динамика конфликтная.

---

🛠 Что помогает: префиксы

Простая система:

• [мелочь] (nit) – косметика, можно проигнорировать
• [вопрос] (question) – не замечание, хочу понять
• [блокер] (blocking) – без этого не апрувлю

Зачем:
Автор понимает, на что тратить время.
Ревьюер явно обозначает вес комментария.

Без префиксов – всё выглядит одинаково важным.
И человек либо правит каждую запятую, либо спорит о каждой.

---

✅ Правило «сначала хорошее»

Прежде чем писать замечания, отметь, что сделано хорошо.

Не потому что «надо быть милым».
А потому что это:
• снижает защитную реакцию
• показывает, что ты видишь не только ошибки
• делает критику конструктивной, а не атакующей

Одна строка – «Хорошо вынес в отдельный модуль».
И весь тон ревью меняется.

---

📌 Вывод

Код-ревью – это не проверка кода.
Это коммуникация о коде.

И качество этой коммуникации определяет, будет команда расти или воевать.

---

💬 Кем вы чаще бывали на код-ревью?

🔥 — Автором, который защищается
😎 — Ревьюером, который давит
👍 — Побывал в обеих ролях

---

#мышление #devops

🛠 Инцидент: 5 фраз, которые делают хуже

---

🔥 Продакшн лежит. Алерты орут. Все на созвоне.

Первые слова во время инцидента решают всё.

Если это:
«Кто это сделал?» –
поздравляю, время восстановления только что выросло.

---

🚫 Фразы, которые ломают инцидент

1. «Кто это сделал?»
Слышится: ищем виноватого.
Люди начинают защищаться вместо того, чтобы чинить.

→ Лучше: «Когда это началось? Какой компонент затронут?»

---

2. «Почему не проверили?»
Слышится: вы облажались.
Включается режим оправданий.

→ Лучше: «Какие проверки у нас есть? Что они могли пропустить?»

---

3. «Опять твой код»
Слышится: ты постоянно ломаешь.
Человек замыкается, перестаёт делиться информацией.

→ Лучше: «Какой сервис? Давай смотреть логи»

---

4. «Я же говорил»
Слышится: я умный, вы нет.
Самая дорогая фраза. Не помогает никак. Только бесит.

→ Лучше: не говорить. Вообще. Просто помочь решить.

---

5. «Это не моя зона»
Слышится: мне плевать.
Команда фрагментируется в момент, когда нужна синхронность.

→ Лучше: «Я могу помочь с X. Кто возьмёт Y?»

---

🛠 Принцип: разделяй «тушим» и «разбираем»

Во время инцидента только факты и действия.
• Что сломалось
• Что делаем
• Какой статус

Анализ причин потом, на разборе инцидента (post-mortem).
Там можно и нужно копать глубоко.

Но не в моменте.
В моменте чиним.

---

📌 Вывод

Слова во время инцидента стоят дороже, чем обычно.
Одна фраза может ускорить восстановление.
Или замедлить его на часы.

---

💬 Какая фраза больше всего бесит вас во время инцидента?

🔥 – «я же говорил»
😎 – «это не моё»
👍 – у нас с этим уже порядок

---

#мышление #devops

Стендап за 10 минут: формат против хаоса

⏰ Стендап должен быть 10–15 минут.
На практике часто 30–40. Почему?

🎭 Защита вместо синхронизации

Стендап превращается в отчёт: «Я делал это, потом то»
Человек защищает работу, а не синхронизируется.

🔄 Как это выглядит

❌ «Вчера работал над тикетом 123, была проблема с базой, исследовал, нашёл проблему, понял, что нужен DBA, написал, жду ...»

✅ «Вчера: тикет 123, жду DBA. Сегодня: 123, начну 124. Блокер: DBA.»

Умножь на 8 человек.

🛠 Формат: 3 пункта

1. Что сделал
2. Что буду делать
3. Что мешает

Детали после, с теми, кому нужны.

⏱️ Таймер – инструмент культуры

2 мин на человека. Таймер видят все.
- даёт право закончить
- снимает давление
- делает формат предсказуемым

📌 Вывод

Стендап – синхронизация, не отчёт.
15 мин достаточно. Если нет, проблема не в стендапе.

💬 Сколько длится ваш стендап?
🔥 30+ мин, больно
😎 15 мин, чётко
👍 нет стендапов

🎄 С наступающим! Берегите время – самый дорогой ресурс.
Здоровья вам и вашим близким!

#мышление #devops

😬✉️ Почему ваши сообщения читают как наезд и как это проверить за 10 секунд

---

✉️ Вы написали сообщение.
Отправили.
В ответ – тишина, «???» или напряжённое «ок».

И вы не понимаете, что пошло не так.

---

🎯 Проблема не в том, что вы написали
А в том, как это было прочитано.

Вы знаете свою интенцию.
Получатель нет.

Он видит только текст.
Без интонации, мимики и контекста –
особенно в чатах, тикетах и коротких «пингах».

Он достраивает смысл сам.
Через своё состояние, усталость и прошлый опыт.

Вы хотели уточнить – он услышал претензию.
Вы хотели помочь – он прочитал «ты не справляешься».

---

✅ 5 вопросов перед отправкой

1. Какова моя цель?
Информировать? Попросить? Выразить отношение?
Если вы сами не можете сформулировать цель — получатель её точно не угадает.

2. Может ли это быть понято иначе?
Прочитайте сообщение глазами человека, у которого плохой день.
Если его можно прочитать как наезд – его так и прочитают.

3. Достаточно ли контекста?
«Посмотри» – что именно? Где? Зачем? Насколько срочно?
Три секунды на уточнение экономят часы переписки и объяснений.

4. Чего я жду в ответ?
Действие? Подтверждение? Просто FYI?
Скажите явно:
«Нужен ответ до вечера» или «Просто информирую».

5. Правильный ли это канал?
Срочное – голосом.
Сложное – документом.
Быстрое уточнение – в чате.
Важные решения – фиксируйте письменно, даже если обсудили голосом.

---

🔁 Один сдвиг фокуса

Не:
«Что я хочу сказать?»

А:
«Что он поймёт, когда это прочитает?»

Это не про угодничество.
Это про эффективность.

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

---

📌 Вывод

10 секунд на проверку интенции
перед каждым сообщением, которое важнее «ок».

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

---

💬 Было сообщение, которое хотелось бы переписать задним числом?

🔥 — да, до сих пор помню
😎 — проверяю интенцию до отправки
👍 — пишу идеально с первого раза (и себе верю)

---

#мышление #devops

⏳😑 Метавопросы: сообщения, которые крадут время

---

💬 «Привет»

И тишина.

Ты смотришь на экран.
Ждёшь продолжения.
Его нет.

Проходит минута. Пять. Десять.

«Можно вопрос?»

Ты уже потерял фокус.
А вопроса всё ещё нет.

---

🚫 Метавопросы – сообщения о сообщениях

«Привет» – без продолжения.
Человек ждёт, пока ты ответишь «привет», чтобы написать суть. Пинг-понг вместо коммуникации.

«Можно вопрос?» – это уже вопрос.
Но бесполезный. Ты не знаешь тему и не можешь оценить приоритет.

«Кто делал X?» – вместо сути.
Ты ищешь человека. Хотя можно было сразу написать, что именно нужно по X.

«Ты занят?» – ловушка.
Скажешь «нет» – как будто обязан помочь.
Скажешь «да» – чувствуешь вину.
А задача, возможно, на 30 секунд.

---

⏱️ Почему это особенно больно

В синхронном разговоре это нормально.
«Привет» → пауза → продолжение.
Всё укладывается в секунды.

В асинхронной коммуникации – это катастрофа.

Ты:

* отвлёкся на уведомление
* переключил контекст
* ждёшь
* не дожидаешься
* возвращаешься к работе
* снова уведомление
* снова переключение

Итог: 10 минут на то, что могло быть одним сообщением.

---

✅ Простое правило
Одно сообщение = всё, что нужно

Контекст + суть + ожидание от человека

❌ «Привет»
❌ «Привет, можно вопрос?»
❌ «Кто делал деплой?»

✅
«Привет! Вопрос по деплою: сервис X не стартует после отката.
Можешь глянуть логи, когда будет минута?»

Человек сразу видит:

* что случилось
* что от него нужно
* насколько это срочно

Он может ответить сразу.
Или отложить.
Но осознанно, а не через пинг-понг.

---

🔗 Культурные референсы

Это не частное мнение, а устоявшаяся практика:

* nometa.xyz – почему «привет» без контекста – антипаттерн
* nohello.club – почему «можно вопрос?» – пустой ход

Иногда проще скинуть ссылку, чем объяснять.

---

📌 Вывод

Метавопросы – это вежливость, которая крадёт время.

Уважение к собеседнику –
не в «привет» и ожидании ответа,
а в сообщении, на которое можно ответить сразу.

---

💬 Бесит, когда пишут «Привет» и молчат?

🔥 — да, каждый раз
😎 — сам так делал, но исправился
👍 — у нас команда уже обучена

---

#мышление #devops

🐳 Docker Buildx и GitLab Registry – "закрыто как won't fix"

---

Собираешь образ через docker buildx, пушишь в GitLab Registry:
⚠️ ERROR: unsupported: OCI manifest found...

GitLab v18.4.1 – вроде свежак. Должно работать?
❌ Не-а. И не будет. Никогда.

---

🐛 Что случилось

- BuildKit создаёт SLSA Provenance attestation (крипто-подпись сборки)
- GitLab Registry формально поддерживает OCI с v16+
- Но: не переваривает OCI manifest с аттестациями
- Issue #388865 закрыта в янв 2023 как “documented workaround” 😅

---

🧩 Системная закономерность

"Закрыто как won't fix" – признак того, что:

1. Проблема в архитектуре (GitLab Registry – обёртка над Docker Distribution)
2. Реальный фикс требует переписывания legacy
3. Команда выбрала задокументировать костыль вместо рефакторинга

Это не баг. Это технический долг, ставший фичей.

---

✅ Решение

docker buildx build \
  --provenance=false \
  --push \
  -t registry.example.com/app:latest .

Один флаг экономит час разбирательств ⏱️

---

🚀 Бонус: Registry cache

docker buildx build \
  --provenance=false \
  --cache-from type=registry,ref=$IMAGE:cache \
  --cache-to type=registry,ref=$IMAGE:cache,mode=max \
  --push \
  -t $IMAGE:latest .

Результат:

– Первая сборка: ~ 180 сек
– Вторая сборка: ~ 10 сек
– В 18 раз быстрее ✅

---

🛠 В CI/CD

build_backend:
  stage: build
  script:
    - docker buildx create --use --name cibuilder || docker buildx use cibuilder
    - docker buildx build
        --provenance=false
        --cache-from type=registry,ref=$CI_REGISTRY_IMAGE:cache
        --cache-to type=registry,ref=$CI_REGISTRY_IMAGE:cache,mode=max
        --push
        -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .

---

🌐 Альтернативы с нормальной OCI:

– Harbor (v2+) (работает из коробки)
– GitHub Container Registry (работает)
– AWS ECR / GCR / Azure CR (все работают)

Но если GitLab – держи флаг наготове 🏁

---

📝 Урок

– Issue закрыта ≠ проблема решена
– Иногда “documented workaround” – это способ сказать:
"Мы не будем это фиксить. Привыкайте."

---

❓ Вопрос к вам:

– Сталкивались с подобным в GitLab Registry?
– Какие ещё “won’t fix” живут в вашем стеке годами?

---

#кейс #devops

🔧 Под капотом DevITWay Academy

Цикл: как мы строим инфраструктуру академии


---

FreeBSD + pfSense → OPNsense → VyOS

---

🔹 Контекст

Раньше в академии использовали FreeBSD + pfSense → попробовали OPNsense (интерфейс красивый, вроде удобнее) → при масштабировании виртуалок и виланов перешли на VyOS.

Почему VyOS?

---

❌ Проблема OPNsense

– Интерфейс не дружит с автоматизацией
– Настройка фаервола / NAT / VPN → кликай вручную
– Версионировать конфиг → экспорт XML, импорт может сломаться

Интерфейс в приоритете ≠ автоматизация в приоритете

---

✅ VyOS в деле

Инфраструктура как код из коробки

– Весь конфиг — текст, версионируется в Git
– Применяется через Ansible, откатывается одной командой
– Один плейбук = одинаковая настройка на всех машинах

Философия фаервола:
– OPNsense: шаблоны часто выглядят как "разрешить всё, потом запретить пару вещей"
– VyOS: запретить всё → явно разрешить только нужное
– Результат одинаковый, но VyOS прозрачнее и воспроизводимее

---

⏱️ Пример: развёртывание виланов для студентов

OPNsense: ~2 часа ручной работы
VyOS: 3 минуты через Ansible

---

⚠️ Грабли при миграции

1. Старая виртуалка в сети
Оба роутера пытаются быть шлюзом по умолчанию → сеть упала

Урок: выводи старую виртуалку из работы – остановка + отключение сетевухи или удаление из влана

2. Правила не один в один
– В OPNsense приходилось подстраивать шаблоны
– VyOS: запретить всё + явно разрешить – легко тестировать

---

🔑 Закономерность

Интерфейс против консоли = разные подходы, а не удобство

– Интерфейс: настрою один раз
– Консоль: настрою тысячу раз одинаково

Когда OPNsense/pfSense:
– Домашние лабы
– 1–2 роутера
– Разовые настройки

Когда VyOS:
– N машин в виланах
– Конфиг в Git
– Автоматизация обязательна

---

🏁 Итог

Выбрали VyOS для академии:
– Автоматизация – все настройки текстом, плейбуки
– Масштабируемость – одинаковая конфигурация на десятки виртуалок
– Воспроизводимость – откаты и тесты без кликанья
– Прозрачность – каждый параметр видно и версионируется

---

❓ Вопрос

– Используете VyOS или OPNsense/pfSense?
– Автоматизируете сетевую инфру или кликаете руками?
– Были грабли при миграции?

Пишите 👇

---

#кейс #devops

🤖 Как я вывел AI-наставника из домашней лабы в Telegram (пилот)

Есть AI-ментор.
Не абстрактный «чатик», а предобученная модель-наставник и интервьювер.
Она умеет задавать вопросы, давить, направлять и проверять мышление.

Модель крутится дома. RTX 3090. Ollama.
Студентов в Telegram ещё нет. Бота тоже нет.
Но пилот уже хочется пощупать: подключиться, погонять сценарии, проверить стабильность.

И тут вопрос:
как безопасно вывести домашний AI в интернет, не открывая порты и не светя IP?

Ответ оказался простым – SSH reverse tunnel через VPS.

---

💡 Идея простая:
дом сам выходит наружу.

🏠 Домашний AI → 🔐 SSH → ☁️ VPS → 📱 (будущий Telegram-бот)

AI-сервер подключается к VPS по SSH
и говорит:

> «Все запросы, которые прилетят к тебе на порт 11434 – отправляй мне»

В итоге:
* дома нет белого IP
* никакие порты не проброшены
* VPS – единая точка входа
* модель можно хоть каждый день переносить между серверами

---

⚙️ Минимальная настройка пилота

На домашнем сервере:

# SSH ключ
ssh-keygen -t ed25519 -f ~/.ssh/vps_tunnel

# SSH config
cat >> ~/.ssh/config << EOF
Host vps-ai
  HostName your-vps-ip
  User your-user
  IdentityFile ~/.ssh/vps_tunnel
  ServerAliveInterval 60
EOF

# Копируем ключ на VPS
ssh-copy-id -i ~/.ssh/vps_tunnel vps-ai

# Туннель
ssh -R 11434:localhost:11434 vps-ai

Проверка на VPS:

curl http://localhost:11434/api/tags
# Должен вернуть список моделей Ollama

Автозапуск через systemd:

sudo systemctl enable vps-ollama-tunnel
sudo systemctl start vps-ollama-tunnel

✅ Без VPN.
✅ Без NAT.
✅ Без боли.

---

Пока нет бота, нет FastAPI, нет студентов.
Но инфраструктура уже готова.

Когда пилот взлетит –
подключится Telegram,
добавится RAG,
появятся сценарии интервью и обучения.

А фундамент уже стоит.

---

🔧 Если ты тоже держишь AI или сервис в домашней лабе –
SSH-туннель может быть самым быстрым и безопасным стартом.

#кейс #ai

📁 Файлы везде, VPN не всегда вариант

Реальный кейс из практики.

Когда была разъездная работа:
ноут со мной,
дома – сервер с файлами,
VPN – не всегда поднимается (корпсети, мобильный интернет, отели).

Нужно было решение, где:
– файлы всегда локально
– работает без постоянного VPN
– переживает обрывы связи
– не отдаёт данные в публичные облака

Вот тогда я и нагуглил Syncthing.

Как это выглядит:
– ноут – домашний сервер
– если можно – прямое соединение
– если нельзя – через relay
– без белого IP
– без VPN
– всё шифруется из коробки

Ключевой момент – другая модель.

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

Утром поработал дома – файлы ушли на сервер.
Днём в дороге – VPN мёртв, а файлы уже на ноуте.
Вечером появился интернет – всё само досинхронизировалось.

Без ручных rsync и плясок с сетью.

Грабли есть:
– при параллельном редактировании будут конфликтные копии
– первая синхронизация больших объёмов, понятно, долгая
– relay медленнее прямого канала

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

Это не замена VPN.
Это другой подход к файлам.

Если работаете в разъездах – очень рекомендую попробовать.

---

❓ Вопрос:
Как решаете проблему доступа к файлам в разъездах?

#кейс #devops

Как дать студенту право «сломать всё» и не бояться за инфраструктуру?

В DevITWay Academy мы используем nested virtualization.

Уровни погружения

L0 Хост
Физическое железо:

• изолированные сети
• выделенные ресурсы
• стабильность

Фундамент, который никто не трогает.

---

L1 Песочница студента

Студент получает VM с --cpu host
и ставит Proxmox внутри.

Это даёт:

• обучение на реальном гипервизоре
• эксперименты с кластерами
• HA
• k8s

Потеря производительности 15–20%
для лабораторных работ незаметно.

---

L2+ Кроличья нора

Если идти глубже:

• CPU инструкции сыпятся
• VT-x и AMD-V проксируются хуже
• производительность ниже 30%

Здесь виртуализация превращается
в медленную эмуляцию.

---

Итог

Двух уровней хватает, чтобы:

• студент безопасно разнёс инфраструктуру
• понял работу гипервизора
• не задел соседей

Ограничение не в Proxmox.
Ограничение в железе и CPU.

❓ Использовали nested virtualization
в проде или только для лаб?

#кейс #devops

🐿 Бурундуки спешат на помощь. Завтра.

Мы выкинули Nexus и Harbor. И стало легче.

Вести интенсив в Академии – это постоянно сталкиваться с реальностью. Когда мы переходили от монолита к микросервисам и GitOps, встал вопрос: где хранить артефакты?

Стандартные пути: 🐢 Nexus – монстр на Java, который съедает 4-8 ГБ оперативки на завтрак и грузится вечность. 🏗 Harbor – мощно, но поднимать 10 контейнеров ради простого registry? Оверхед.

Попробовали GitLab Registry, но и там свои "приколы" (писал об этом недавно).

В итоге я решил: если нет идеального инструмента, который просто работает и не жрёт ресурсы как не в себя, его нужно написать.

Завтра покажу, что получилось. Инструмент, который заменяет всё вышеперечисленное, весит 32 МБ и запускается за 3 секунды. 🦀

Ставьте 🔥, если тоже устали тащить тяжёлый софт в инфраструктуре!

#кейс #rust

🎉 Представляю NORA — быстрое хранилище артефактов на Rust 🦀

NORA — замена Nexus, Artifactory и Harbor. Без Java, тяжелых микросервисов и долгого старта.

🐿 NORA (НОРА) — автономное убежище для ваших сборок. Наш маскот Чиппи (Chippy) наводит порядок в хранении:
• Docker-образы,
• Maven (Java),
• npm (JS),
• Cargo (Rust),
• PyPI (Python)

⚡️ В чем профит:
• Легкость: < 100 МБ ОЗУ (Nexus: 2–4 ГБ).
• Скорость: Запуск < 3 сек (вместо минуты ожидания).
• Минимализм: Один бинарник 32 МБ.
• S3-native: Хранение локально или в S3-облаках.
• Dashboard: Web UI и метрики Prometheus из коробки.
• Open Source: Лицензия MIT и мощь Rust.

🚀 Запуск одной командой:
docker run -d -p 4000:4000 --name nora ghcr.io/getnora-io/nora:latest

🌐 Сайт: getnora.io
🧪 Демо: demo.getnora.io
💻 Код: github.com/getnora-io/nora

Будем публично разбирать архитектуру и безопасность. Присоединяйтесь!

#кейс #rust

🤖 AI-агент в терминале: почему OpenWebUI ломает DevOps-флоу

В DevITWay Academy всё завязано на единый LDAP: один логин для всего.
Для AI я сначала взял OpenWebUI. Инструмент отличный, но в нём нет поддержки пока SSO. Студентам приходилось вводить креды и прыгать в браузер.

DevOps-инженер живет в консоли, а не в веб-чатах.

🛠 Решение: RTX 3090 + Local AI

В итоге я настроил официальный Claude Code CLI для работы поверх локальной Ollama.

Получился гибрид: удобный UX от Anthropic, а данные и модели полностью локальные, внутри периметра.

Почему это важно для студентов:

* Они не учатся «копипастить ошибки в чат».
* Они думают и дебажат прямо в рабочей среде, не теряя контекст.

Как это выглядит на практике:

claude "почему этот плейбук падает на этой таске?"

⏱️ 20–30 секунд работы RTX 3090
✅ Разбор ошибки с учетом контекста файлов.

Скоро выложу в блоге гайд, как собрать такую связку.

❓ Где вы используете AI: в браузере, IDE или уже в терминале?

#кейс #ai

🤖 AI-ментор: Как я приручал RAG на одной RTX 3090

Краткая сводка для тех, кто ценит время и VRAM:
Задача была амбициозной: создать ИИ, который «съест» 891 файл учебного курса и перестанет придумывать то, чего в материалах нет.

Что в итоге взлетело:

Стек: Ollama + Qdrant + Claude Code CLI.
База знаний: 11,307 чанков в векторном хранилище.
Скорость: ~10-15 секунд на честный, аргументированный ответ прямо с домашнего железа.

Мои «грабли»:

❌ Llama 3.1: Оказалась знатным фантазером. Вместо того чтобы читать файлы, она с уверенным видом сочиняла их содержимое.
❌ Fine-tuning: Модель внезапно «сменила пол» и превратилась в Марию, коуча по позитивному мышлению.
❌ GLM-4.7-flash: Поймали неприятный баг, в режиме размышления (thinking mode) выдавала пустые ответы.
✅ Qwen3:30b-a3b (MoE): Наш фаворит. Качество на уровне 30B, скорость как у 3B, и идеально помещается в 24GB видеопамяти.

Подробнее 👇
https://telegra.ph/Kak-ya-priruchal-RAG-na-RTX-3090-II-mentor-kotoryj-pochti-ne-vret-02-02

#кейс #ai

🦀 NORA в бою: Опыт внедрения в K8s

Обкатал NORA в инфраструктуре DevITWay Academy.

Сетап: 3 кластера K8s (9 нод), GitLab CI → NORA ← ArgoCD. План: docker run и в прод. По факту немного "фичей". 😅

Установка
getnora.io/install.sh - 404 на момент внедрения. Ставил вручную. Завёл issue #1 сделаю инсталлер по канонам rustup.

TLS и сертификаты
Nginx + FreeIPA не взлетели: containerd проверяет только SAN. Подключались по IP, а IP в сертификате не было, поэтому TLS не сходился. Временно включил insecure_skip_verify на нодах, думаю над issue #2 - нативным TLS.

Rate Limit
При старте 7 подов словили 429. Ресурсы ок, упёрлись в лимиты.
Решение: выставил NORA_RATE_LIMIT_* через ENV, теперь держит.

Итог:
✅ RAM (RSS): ~2.4 МБ в idle / low load
✅ Деплой: ~87 сек до Running
✅ Rust против Java - без шансов

Если нужен просто registry без enterprise-комбайна - NORA отлично закрывает задачу.

#кейс #rust

🛠 Локальный ИИ-ассистент: пошаговый гайд

Отвечаю на вопрос про загрузку доков в Qdrant. В паре абзацев не вышло - ловите полноценный туториал, как собрать своего «Джарвиса» в терминале.

Стек (красивый Франкенштейн): Claude Code CLI + Ollama + Qdrant RAG + MCP-протокол.

Что внутри:
✅ Основа: Запуск Qwen3:30b-a3b (MoE) локально.
✅ Мост: Настройка LiteLLM для подмены API Anthropic на Ollama.
✅ Память: Python-скрипт для нарезки чанков и заливки в Qdrant (с метаданными и overlap).
✅ Руки: MCP-сервер, чтобы агент сам гуглил по вашей базе знаний.

Теперь на вопрос claude "почему nginx выдает 502?" ассистент сам найдет инфу в ваших .md файлах и предложит фикс. Без облаков, VPN и подписок.

🔗 Гайд

#миникурс #ai

AI DevOps: почему это стоит дорого

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

Что внутри:

Экономика GPU. Видеокарта дорогой актив. Нужно уметь делить мощности и управлять очередями, чтобы не сжигать бюджет. Масштабирование сложнее, чем просто добавить ноды.

Архитектура. Работа с кэшем и сжатием моделей. Балансируем по пропускной способности токенов, а не по CPU.

Контроль. Промпт-инъекции не решаются файрволом. Инфраструктура сама становится слоем фильтрации ответов и изоляции контекста.

Итого: Если пробовали локальный запуск и векторные базы, вы на верном пути. Скоро нейросети станут базой, как Docker. Изучайте экономику инференса сейчас, иначе рынок вас обгонит.

❓ Кто внедрял GPU: во что уперлись? Квоты, мониторинг или бюджет?

#мышление #ai

Guacamole vs RustDesk vs Teleport: выбор доступа

Ставили как-то товарищу Guacamole за Кинетик на малинку. Вместо 20 минут, 3 часа борьбы с зависимостями. Спас Docker. Повод сравнить стек для дома и Академии. Мой флоу: браузер → Jump-сервер → SSH → Nested Proxmox. Периметр закрыт снаружи.

Почему остальное мимо:

• RustDesk. Peer-to-peer модель - это рутина при 30+ студентах. В Free-версии нет LDAP, а установка софта учеником, увы, лишний барьер.

• Teleport. Заточен под SSH/K8s аудит. Для GUI-задач избыточен, Desktop Access сложен в настройке под каждую лабу.

Плюсы Guacamole:
• Zero Client: только браузер, без VPN.
• Gateway-centric: нативно встает в изолированный периметр.
• SSO: интеграция с LDAP/GitLab.

Итог:
Дома за Кинетиком - RustDesk. В лабах Академии Guacamole, имхо, лучший компромисс.

❓ Как изолируете тестовые среды?

#кейс #devops

14 февраля: как баг видеодрайвера VMware «ронял» MS Exchange

Для меня 14 февраля — это теперь навсегда своеобразный «вьетнамский флешбэк» и своего рода ПТСР.

Итак, тоже суббота и тоже 14 февраля.
Пустой офис. Руководитель конторки на месте и периодически пингует меня, как ослик из «Шрека»: «Ну что, приехали? Уже работает? А сейчас?». Я гуглю под таким давлением, что IQ падает вдвое.

Кейс: Почтовик на MS Exchange (бизнес-критикал), крутится на виртуалке VMware.
Проблема: Сервер ловит критическую нестабильность. Процессы отваливаются, система ведет себя как при остром дефиците ресурсов, хотя физической оперативной памяти в достатке. Поднимаешь -> живет -> снова в аут.

🔍 Симптомы и ложные следы

Типичная ловушка: когда падает Exchange, ты копаешь внутри самого Exchange. Тюнинг кэша Jet Blue, лимиты памяти Store.exe и всё мимо.

Контекст: за месяц до моего прихода в офисе был жесткий блэкаут. Сервера ребутались по питания несколько раз. Тогда это проигнорировали, «ну завелось же».

Нахожу на StackOverflow (тогда еще живом) тред, где чувак пишет:

«Проверь аллокацию видеопамяти в настройках ВМ».

Моя первая мысль: «Что за бред? Где почта, а где видеокарта?». Но это был последний шанс перед полным фиаско.

⚙️ Root Cause: Истощение Nonpaged Pool

Захожу в настройки VMware. Флаг видеопамяти стоит в «Auto». Выставляю жесткий лимит. Ребут.
Супостатина стабилизировалась.

Что произошло технически:
Это не была нехватка физических планок памяти. Это был классический Nonpaged Pool exhaustion (истощение невыгружаемого пула ядра).

После блэкаута и кривого старта драйвер VMware SVGA начал вести себя неадекватно.

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

В Windows Server того времени (2008 R2 / 2012) лимиты этого пула были довольно жесткими.

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

Как только видеодрайвер из-за бага «отъедал» лимит невыгружаемой памяти ядра, ОС теряла возможность выделять ресурсы под системные структуры. Итог: сбой сетевого стека, ошибки ввода-вывода и аварийное завершение процессов Exchange. Судя по всему, фиксация объема видеопамяти в настройках ВМ изменила логику инициализации драйвера и прекратила утечку.

💡 Системный вывод

Инженер, который мыслит слоями (Приложение → ОС → Ядро/Драйвер → Гипервизор), выигрывает у того, кто копает только в конфигах софта.

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

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

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

❓ Вопрос:
Были случаи, когда софтверную проблему лечили через настройки гипервизора? Когда интуиция вытащила там, где логи молчали?

Пишите в комменты 👇

#кейс #devops

P.S. Желаю, чтобы в это 14 февраля «ослики» тебя не беспокоили, а системы работали как часы.

🛠 Доверяй, но поднимай стенд: Как системные требования ИИ врут в глаза

В ИТ есть золотое правило: «Доверяй, но проверяй». Когда Gemini с умным видом заявляет, что твоя видяха «не потянет», рука сама тянется закрыть терминал. Я решил не верить прогнозам на слово и поднял стенд.

Дано:
Обсуждали в чате локальный запуск ИИ для кодинга. Gemini выдал базу: «На 12 ГБ VRAM (RTX 4070) даже не суйся в сторону моделей 30B+. Скорость упадет до 1-2 токенов в секунду. Бери DeepSeek-Coder-V2-Lite, это потолок».

Тест в реальности (RTX 4060 8GB Laptop, Ollama, Q4_K_M, контекст до 4k):
Я пошел дальше и запустил всё на 8 ГБ VRAM. По логике «экспертов», мой ноут должен был превратиться в тыкву.

📊 Результаты бенчмарка:

Qwen3:30b-a3b (архитектура MoE)
Прогноз Gemini: 1-2 tok/s.
Реальность: 27-32 tok/s! 🚀

Почему так? Общий вес модели (~18 ГБ) перестал быть главным ограничителем. В архитектуре MoE (Mixture of Experts) на каждый токен активируется лишь малая часть параметров (в данном случае ~3B). Ollama выкинула часть весов в системную оперативку, и за счет малого числа активных параметров гибридный режим выдал отличную скорость.

Парадокс 14B Dense vs 30B MoE

Qwen2.5:14B (Dense) — полностью влезла в GPU, но выдала всего 11 tok/s.
Qwen3:30B (MoE) — в гибридном режиме выдала 27+ tok/s.

Вывод: Модель, которая в 2 раза «тяжелее» по весу, работает в 2.5 раза быстрее. Архитектура теперь важнее объема.

Битва за код: Qwen vs DeepSeek на 8 ГБ VRAM

DeepSeek-Coder-V2 (16b): 42 tok/s. Код чистый, но сухой.
Qwen2.5-Coder (7b): 53 tok/s. Дает doctests, примеры использования и шикарные комменты.
CodeLlama (7b): Рекордные 60 tok/s, но по качеству документации проигрывает Qwen.

Вывод: Для карт с 8-12 ГБ памяти Qwen2.5-Coder сейчас — самый практичный выбор.

🎯 Итоговый вердикт:

Миф: 30B на средних картах — это всегда слайд-шоу.
Факт: MoE-модели (в Q4 квантовании) — это чит-код. По качеству логики они на голову выше моделей 7B-8B и вплотную приближаются к облачным решениям прошлого поколения.

Миф: Нужно смотреть только на объем VRAM.
Факт: Нужно смотреть на тип модели (MoE vs Dense) и на то, как движок (Ollama/llama.cpp) умеет в offload.

Мораль:
Не слушайте советы облачных ИИ про локальные ИИ. Они часто экстраполируют поведение старых тяжелых моделей. На RTX 4070 (12GB) в тех же условиях можно смело ожидать 35–45 tok/s.

Хочешь знать правду? Поднимай стенд, засекай время и меряй всё руками.

#кейс #ai

Клод код кли? 403. Квен код кли? Погнали! 🚀

Пока Anthropic закручивает гайки и выдает «403 Forbidden» на CLI-инструменты для нашего региона, в солопренерстве работает правило: риск бездействия выше риска ошибки. Не тратим время на VPN-костыли, идем по пути локального импортозамещения.

Вчера товарищ жаловался, что не может пощупать Claude Code. Я решил не ждать милости от облаков и развернул Qwen Code CLI на Ubuntu. Китайцы сейчас делают очень бодро, а архитектура MoE позволяет летать даже на среднем железе.

Почему это маст-хэв для терминала:

1. Локально. Поднимаешь Ollama, тянешь qwen2.5-coder (7b — база, 30b — для серьезного дебага). Данные не покидают периметр.

2. Бесплатно. Никаких инвойсов на 85 евро и битвы с продавцами за возврат. Твое железо — твои правила.

3. Вайбкодинг. Он так же пишет код, правит конфиги и находит баги в соседних файлах, как и Клод, но делает это «лампово», прямо у тебя на ноуте.

Что пошло не так при установке (грабли):

>Node.js. Стандартная 18-я версия из репозиториев Ubuntu — мимо. Qwen требует 20+. Пришлось сносить старую и ставить через NodeSource.

>Кладбище ядер. При обновлении словил dpkg error 11 из-за битых хедеров старых ядер Linux. Пока не вычистил «хвосты» через dpkg --purge, npm отказывался ставить пакеты.

>PATH. После установки через npm -g команда qwen часто не видна. Лечится банальным символическим линком в /usr/local/bin.

Итог:
Модель qwen2.5-coder:7b на локалке выдает шикарные комменты и doctests. Это именно тот уровень автономии, который нужен, когда хочешь кодить в самолете или из-за «забора».

Наберем 5 огоньков 🔥 или лайков -> выкачу подробный пошаговый гайд с командами: как победить зависимости Node.js, починить битый dpkg и завести Qwen CLI через локальную Ollama за 5 минут.

#кейс #ai