💀 5 механизмов деградации OSS

В понедельник было:
«Open Source повзрослел».

Сегодня – как именно.
Пять механизмов.

---

1. Закрытие функций

Функция была бесплатной.
Добавили проверку лицензии.
Один if – и функция платная.

• Grafana: разграничение прав → Enterprise
• GitLab: расширенная синхронизация LDAP → EE
• Nexus: сканирование уязвимостей → Pro

---

2. Смена лицензии

Лицензия становится жёстче.

• MinIO: Apache → AGPL
• Terraform: MPL → BUSL → форк OpenTofu
• Redis: BSD → «код открыт, но не свободен»

---

3. Контроль сборок

Код открыт.
Готовых релизов – нет.

MinIO:
• сообщество – исходники
• коммерция – готовые сборки

Итог:
• своя сборка
• свой конвейер
• своя ответственность

---

4. Деградация интерфейса

Интерфейс формально есть.
Пользы – почти нет без коммерческой версии.

MinIO:
• администрирование – ограничено
• мониторинг – ограничен
• командная строка – осталась

---

5. Победитель становится драконом

Проект победил монополию.
Стал стандартом.
Потом – бизнесом.
Потом – новым драконом.

Облака

Код берут.
Сервис продают.

• Elasticsearch → OpenSearch
• Elastic → смена лицензии
• MongoDB → смена лицензии

Корпорации

Проект покупают.
Приоритеты меняются.

• MySQL → Oracle
• Java → Oracle
• Kafka → рост влияния IBM через Red Hat

Kafka назван в честь писателя о бюрократии.
Ирония получилась точной.

---

📌 Итог

Цикл всегда один:

1. Проект ломает старую монополию
2. Становится массовым
3. Контроль уходит корпорациям или облакам
4. Автор защищается лицензией
5. Сообщество возмущается

Это не про жадность.
Это про конфликт интересов.

Сегодняшний освободитель – завтрашний тиран.

---

➡️ Пятница: «Чеклист оценки Open Source перед внедрением»

💬 Видели, как проект проходил этот путь?


#мышление #devops

🎯 Чеклист перед внедрением OSS

Как не попасть в ловушку.

---

А вот по себе знаю:

Раньше выбирал инструмент так:
• Нашёл на Хабре
• Поставил за вечер
• Заработало - отлично

2020+:
• Поставил MinIO
• Через год AGPLv3
• Через два - интерфейс деградировал
• Спасибо за рыбу - мигрируем

Просчитался, но где? Можно было заранее понять?

---

📋 Чеклист перед внедрением

Лицензия

• AGPLv3 / SSPL / BUSL → юристы нервничают
• Apache / MIT / BSD → спокойнее
• Менялась за 3 года? → будет ещё
• Один гигант контролирует? → завтрашний дракон

---

Управление проектом

• Все разработчики из одной компании → риск
• Проект под фондом (Apache, CNCF) → безопаснее
• Недавнее поглощение (IBM/Oracle) → жди изменений
• Несколько спонсоров → стабильнее

---

Коммерческая версия

• Все нужные функции только в коммерции → проблема
• Бесплатная версия деградирует (функции уходят) → тревожный знак
• Интерфейс только в коммерции → команде неудобно
• Бесплатная версия полнофункциональна → хорошо

---

Зрелость

• Проект < 2 лет → рано для production
• 3-10 лет + регулярные релизы → норм
• Нет альтернатив → привязка к поставщику
• Есть 2-3 здоровых альтернативы → можно мигрировать

---

Технические риски

• Только исходники, нет готовых сборок → барьер
• Командная строка для всего → команде неудобно
• Интерфейс деградировал → будет хуже
• Проприетарный протокол → нельзя мигрировать
• Готовые бинарники / Docker → удобно
• Совместимость со стандартами (протокол S3) → можно сменить

---

Бизнес

• Одна компания платит всем → зависимость
• Лицензия менялась за год → будет ещё
• AWS продаёт, автор в конфликте → смена лицензии близко
• Множественное финансирование → стабильнее
• Прозрачный план развития → предсказуемо

---

Как оценить

Прошёлся по чеклисту.
Посчитал риски.

• 0-2 риска -> можно брать
• 3-5 рисков -> осторожно, план миграции нужен
• 6+ рисков -> лучше альтернативу

---

Примеры

Kafka (2025):

• Apache 2.0 ✅
• Под фондом Apache ✅
• IBM влияние растёт ⚠️
• Альтернативы: Pulsar, NATS ✅

Итого: 1 риск
Вывод: можно брать, но следить

---

MinIO (2025):

• AGPLv3 ⚠️
• Интерфейс деградировал ⚠️
• Только исходники ⚠️
• Одна компания ⚠️

Итого: 4 риска
Вывод: высокий риск, нужен план Б

---

Grafana (2025):

• AGPL ⚠️
• Коммерция: разграничение прав, отчёты ⚠️
• Бесплатная версия базовая есть ✅
• Альтернативы есть ✅

Итого: 2 риска
Вывод: приемлемо

---

💡Инженерные приметы

Раньше (2010-е):
Поставил → работает → забыл

Сейчас (2020-е):
Поставил → через год лицензия → через два интерфейс деградировал → мигрируем

Что делать:

❌ Выбирать, потому что "модно"
❌ Выбирать, потому что "бесплатно"
❌ Думать, что инструмент навсегда

✅ Проверить лицензию
✅ Оценить риски
✅ Держать план миграции

---

📌 Правда жизни

Open Source повзрослел.

Инструменты меняются.
Драконы неизбежны.
Попасть в ловушку - это выбор.

---

💬 Сталкивались с ловушками OSS?
Как проверяете проекты перед внедрением?

#мышление #devops

🔥 Протоколы есть. Стандарты есть.

А люди всё равно не понимают друг друга.

Странно. Парадоксально:
люди, которые хотят одного и того же, в итоге ругаются.

Мы научились собирать системы, которые работают
почти без сбоев.
CI/CD, оркестрация, отказоустойчивость.

Но система из людей
до сих пор остаётся
самой нестабильной.

И непонятно, что сложнее:
укротить техномустанга
или понять его наездников.

---

⚔️ Одна фраза — два смысла

Вопрос «Кто последний коммитил?» — информационный.
Но слышится как обвинение.

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

«Почему так долго?» — уточнение.
Но воспринимается как «ты медленный».

Это не токсичность.
Это разрыв между интенцией и интерпретацией.

Ты имел в виду одно.
Человек услышал другое.
Оба уверены, что правы.

---

💀 Коммуникативный долг

Есть технический долг — все знают.
Есть коммуникативный — о нём молчат.

Он копится так же:
• мелкие недопонимания
• непроговорённые ожидания
• обиды, которые «ладно, проехали»

А потом — взрыв на ровном месте.
Или тихий уход человека из команды.

Разница с техдолгом:
Техдолг можно рефакторить.
Коммуникативный — только предотвращать.

---

🛠 Один принцип, который меняет всё

Культура без обвинений (blameless).

Не «кто виноват?», а «что пошло не так?»

Звучит просто.
На практике — ломает привычку искать крайнего.

Когда команда перестаёт защищаться — она начинает говорить.
Когда начинает говорить — проблемы всплывают раньше.
Когда всплывают раньше — чинятся дешевле.

Это не про «быть добрым».
Это про эффективность.

---

📌 Что с этим делать

Культура не внедряется сверху.
Она создаётся в каждом сообщении.

Перед тем как отправить — один вопрос:
«Как это услышит человек на другом конце?»

Не «что я хочу сказать».
А «что он поймёт».

Иногда достаточно переформулировать одну фразу.

---

📖 Если тема зацепила — написал подробный разбор:

• откуда берётся разрыв между интенцией и интерпретацией
• табличный паттерн: как фраза звучит → как слышится → как сказать лучше
• чек-лист проверки сообщения перед отправкой
• кейс команды, которая сократила время код-ревью на 30%

👉 Читать в Telegraph: Коммуникативные неудачи в DevOps-культуре

---

💬 А вы ловили себя на том, что сказали одно — а человек услышал совсем другое?

🔥 — да, регулярно
😎 — научился это отслеживать
👍 — у нас в команде с этим порядок

---

#мышление #devops

🚧 Почему «токсичный, но умный» не растёт

---

🧠 Есть миф: если ты технически силён – вырастешь в любом случае.

Реальность жёстче.

«Токсичность» не про характер. Это про повторяющееся поведение в коммуникации. Не ярлык, а паттерн.

---

⚙️ Что такое Senior на самом деле

Senior – это не «знает больше».
Это «делает продуктивными других».

• Менторит джунов
• Проводит ревью так, что люди учатся, а не защищаются
• Участвует в архитектурных обсуждениях и его слушают

Если с тобой не хотят работать – ты не масштабируешься.
А Senior без масштаба – это просто дорогой Middle.

---

🚫 Почему «токсичный гений» застревает

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

2. Команда обходит.
Задачи, где нужна коммуникация, уходят другим.
Ты остаёшься с тем, что можно делать в одиночку.

3. Lead-позиции закрыты.
Tech Lead – это на 50% переговоры, синхронизация, конфликты.
Токсичный человек на этой роли – риск для всей команды.

---

📊 Данные, а не мнение

Google в проекте Aristotle исследовал, что делает команды эффективными.

Главный вывод: состав команды – кто в ней – менее важен, чем то, как люди взаимодействуют.

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

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

Токсичный человек эту безопасность убивает.
Даже если он гений.

Хорошая новость: это паттерн поведения, а не черта личности.
Паттерны можно менять.

---

📌 Вывод

Коммуникативный долг конвертируется в карьерный потолок.

Можно быть умным.
Можно быть правым.
Но если с тобой не хотят работать – расти некуда.

---

💬 Встречали «гениев», которые застряли на одном уровне годами?

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

---

#карьера #devops

🔥 Обновлена вся серия: FreeIPA для промышленной эксплуатации

Централизованная аутентификация + безопасное хранилище + управление секретами — всё в трёх статьях!

📋 Что внутри:

Часть 1: Установка FreeIPA
✅ LDAP + Kerberos + DNS + центр сертификации в одном решении
✅ Конфигурация для промышленной эксплуатации
✅ Управление пользователями и правилами sudo
✅ Резервное копирование

Часть 2: Сетевое хранилище + Автомонтирование
✅ Безопасная настройка сетевого хранилища
✅ Автоматическое монтирование домашних директорий
✅ Шифрование через Kerberos
✅ Правильные параметры монтирования (hard vs soft)
✅ Контрольный список перед запуском

Часть 3: Интеграция с Hashicorp Vault
✅ Подключение Vault к FreeIPA LDAP
✅ Централизованное управление секретами
✅ Политики доступа на основе групп
✅ Динамические учётные данные для баз данных
✅ Журналирование всех операций

💪 Результат: Корпоративная инфраструктура с централизованной аутентификацией, безопасным хранилищем и управлением секретами

👉 Читать серию: гайды

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

📝 Нашли неточность или есть предложения? Пишите в комментариях — сделаем материалы ещё лучше вместе!

#миникурс #devops

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

---

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

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

---

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

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

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

В комментарии к 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