✨ "Как правильно отвечать на вопрос о конфликте с помощью STAR-метода - структура, которая работает"

На собесе вопрос: "Расскажи о проблемах во время релиза"

90% кандидатов:
"Ну, у нас собираются... Опрашивают, я сообщаю... Потом решили..."

Интервьюер думает: "Хаос. Никакой структуры. Как он будет разруливать проблемы в продакшене?"

---

⚡️ STAR-метод — твоя структура для любого поведенческого вопроса

📋 Сохрани эту карточку:

┌───────────────────────────────────┐
  S - СИТУАЦИЯ (что было)           
  "Команда спорила Jenkins vs       
   GitLab CI. 2 дня на выбор"       
└───────────────────────────────────┘
              ↓
┌───────────────────────────────────┐
  T - ЗАДАЧА (что нужно сделать)    
  "Выбрать инструмент, иначе        
   не начнём проект"                
└───────────────────────────────────┘
              ↓
┌───────────────────────────────────┐
  A - ДЕЙСТВИЯ (что ты сделал)      
  "Матрица критериев → оценка →     
   голосование на основе данных"    
└───────────────────────────────────┘
              ↓
┌───────────────────────────────────┐
  R - РЕЗУЛЬТАТ + УРОК              
  "Выбрали GitLab. Метод теперь     
   используем для всех споров"      
└───────────────────────────────────┘

💡 Пример использования STAR-метода

⚡️ STAR делает любой твой ответ структурированным и чётким

---

📖 Пример из жизни

Тимур на собесе в крупной корпорации:

❌ "Pod не запускался. Гуглил, смотрел логи, починил"
→ Хаос, нет структуры

✅ "Контейнер падал в CrashLoopBackOff (S). Нужно было починить за 2 часа (T). Проверил конфигурацию → нашёл проблему с подключением хранилища → неправильное имя класса хранилища → исправил (A). Контейнер запустился, добавил проверку в чек-лист команды (R)"
→ Системный подход, работа под давлением

Результат: оффер 🎉

---

🎯 Где применять STAR-метод

🤝 Конфликт в команде
Например: конфликт из-за выбора решения по CI/CD (Jenkins vs GitLab). Покажи, как организовал процесс выбора на основе данных

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

📋 Работа с критикой
Например: на code review указали на проблемы с производительностью. Покажи, как исправил и оптимизировал код

⚠️ Ошибка и как исправил
Например: баг в конфигурации приводил к сбоям на проде. Расскажи, как нашёл причину, исправил и добавил автоматические проверки

---

💡 Для российских компаний: В банках/госкомпаниях несколько этапов собесов с разными людьми. STAR помогает каждому интервьюеру понять твой подход - структура запоминается лучше хаоса.

---

🚀 Готов к собеседованиям?

Пройди SFIA Assessment, чтобы составить персональный план подготовки и почувствовать уверенность на собеседовании!

👉 @devitway_sfia_bot

Скоро новые возможности 😉 следите за обновлениями
#DevITWay #собеседование #STAR

📌 "Твои вопросы работодателю (без них не возьмут)"

❗️ Фраза "Есть вопросы к нам?" — НЕ формальность.

Если отвечаешь «Нет» - для многих это красный флаг.

Интервьювер думает:
«Не интересуется. Пойдёт куда угодно. Не выбирает, соглашается.».

---

📖 История из практики

Кандидат прошёл технику идеально.

Финальный вопрос: "Есть вопросы к нам?"
Ответ: «Нет, всё понятно, спасибо».

Результат: отказ.
Комментарий: «Сильный кандидат, нулевая мотивация, ему будет скучно у нас».

---

Почему так происходит:

В крупных российских компаниях (банки, телеком, госкорпорации) критично:
- как ты работаешь в процессах
- как взаимодействуешь с командой
- насколько хочешь работать именно у них

---

Что проработать для увеличения шанса:

На следующем интервью спроси:
- как устроен онбординг
- какой стек и мониторинг
- как команда делится знаниями

---

💬 Что спрашивать (и зачем)

1️⃣ 👥 Команда

"Как проходит типичный день DevOps?"
→ Плановая работа или постоянные пожары

"Какого размера команда? Как распределены роли?"
→ Часть команды или «единственный DevOps на всё»

"Есть ли наставник? Какой опыт у команды?"
→ У кого учиться и как быстро расти

---

2️⃣ ⚙️ Технологии и процессы

"Какие технологии сейчас в проде? Что планируете менять?"
→ Легаси или современный стек

"На чём CI/CD?"
→ GitLab / Jenkins / кастом или деплой по ssh «в 3 ночи»

"Есть ли IaC — Terraform / Ansible?"
→ Автоматизация или «кликаем в GUI»

💡 Реалии РФ: Zabbix, GitLab/Jenkins, самописные пайплайны.
Вопросы про это показывают, что ты понимаешь рынок.

---

3️⃣ 📈 Рост и развитие

"Есть ли обучение или бюджет на сертификаты?"
→ Растят людей или нет

"Как выглядит путь от джуна до мидла?"
→ Есть ли прогнозируемый рост

---

4️⃣ 🚩 Риски (вежливо)

"Почему открылась позиция?"
→ Рост команды или текучка

"Как устроен on-call? Часто ли бывают ночные вызовы?"
→ Зрелый алертинг или хаос

---

💡 Зачем задавать вопросы

✓ Показываешь мотивацию
✓ Оцениваешь компанию — ты тоже выбираешь
✓ Снимаешь риски — заранее понимаешь, куда идёшь

---

❌ Антипример

"Выдают ли маки? Сколько отпуск? Можно только удалёнку?"

Почему стоит осторожно:
Если задать такие вопросы в начале единственного интервью, это создаёт впечатление, что тебе важны только личные условия, а не работа, команда и процессы.

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

---

📌 Главное правило

На собеседовании выбирают оба.

А хорошие вопросы — твой инструмент показать уровень и осознанность.

---

🚀 Готовься системно

Пройди SFIA Assessment — определишь уровень и получишь персональный план подготовки.

👉 @devitway_sfia_bot

#DevITWay #собеседование #карьера

🔥 Тебя зовут, но место ещё тёплое. Идти или разворачивать?

Бывает оффер на столе, стек норм, деньги норм, а внутри свербит: «Подвох?»
Ты улыбаешься, говоришь «спасибо за доверие», и всё равно ощущение, что что-то не так.

И это не паранойя.
Это инстинкт самосохранения.

---

🚩 Когда лучше притормозить

1) «Мы ищем замену, но не можем сказать кого»
Значит, ушли не очень красиво. Конфликт? Выгорание? Токс? Молчат – уже ответ.

2) Слишком быстрое «подходишь!»
Ещё не спросили про стек, а уже: «Когда выйдешь?»
Так делают, когда горит или никто не держится.

3) Собеседующие путают роль и задачи
У каждого своё видение, зачем ты нужен. На месте будет ещё веселее.

4) Ты наследуешь долги
«Тут задачки, которые надо было вчера».
Беги, пока не стал пожарным по умолчанию.

5) Интервью ради галочки
Ты приходишь, чтобы кто-то закрыл KPI по собесам, а не чтобы тебя реально нанять.
Я сам сидел на таких: по резюме видно мискаст, все понимают, но очередь дошла, надо отстреляться.

---

🟢 Когда идти можно, но с открытыми глазами

* Честно рассказали, почему человек ушёл
* Дали познакомиться с командой
* Показали продукт, а не только «красивый питч»
* У ожиданий есть метрика успеха на 3 месяца
* Руководитель знает, зачем ты ему

Прозрачность вместо «просто поверь».

---

❓Вопросы, которые ставят всё на место

Задай спокойно и уверенно:

* Кто делал эти задачи до меня и почему его больше нет?
* Какие 3 главные проблемы мне нужно закрыть, чтобы вы сказали: «Он справился»?
* Сколько людей пришло / ушло за год в команде и почему?
* Какие процессы живые, а какие только «в Confluence»?

После этих вопросов маски обычно падают сами.

---

🎙 Две мини-истории из реальности

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

🟥 «Скиловой, но не к нам»
Коллеге после выключения записи говорят:

«Ты классный, но вакансий в нашей команде нет»
Звучит абсурдно? На самом деле – честно.
Хуже, когда берут «потому что надо закрыть слот», а потом делают пешкой в чужой игре.

---

🎯 Главное

Идти – это нормально.
Главное – понимать, куда.

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

Вопросы – это зрелость.
Сомнения – это опыт.

Если внутри щёлкает «что-то не так» – прислушайся.
Это твой лучший софт-скил.

---
#DevITWay #DevITWay_карьера #CareerTrap #DevOps #Собеседования

💀 "Open Source умер". Или просто повзрослел?

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

5 лет назад я ставил Grafana, Nexus, MinIO –
всё работало «из коробки», интерфейс удобный, документация понятная.

2025: те же инструменты, но:
• Grafana – базовый интерфейс есть, но всё для команд → Enterprise
• Nexus Repository – OSS версия ограничена, управление ролями и безопасность → Enterprise
• MinIO – AGPLv3, коммерческий продакшн теперь де-факто лицензируемый

Первая реакция: "Нормально же ведь сидели работали!? Чего началось-то?"
Вторая (спустя время): "А как иначе?"

---

Что мы привыкли считать OSS

✅ Бесплатный
✅ С удобным интерфейсом
✅ Готовый к боевому использованию
✅ "Поставил и забыл"

Это была иллюзия 2010-х, когда:
• Рынок был маленьким
• Облачные сервисы только развивались
• Коммерциализация казалась далекой

---

Что есть сейчас (реальность 2025–2026)

⚠️ Open Core (ядро бесплатно, всё полезное – платно)
⚠️ Интерфейс урезан или полностью отсутствует
⚠️ Community Edition = для тестов и экспериментов
⚠️ Enterprise-only функции = для прода

И это не жадность разработчиков.
Это экономика выживания.

---

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

"Open Source" не значит "бесплатно для бизнеса".
Это значит "открытый исходный код".

Автор может:
✅ Открыть код
✅ Поставить условия использования
✅ Зарабатывать на своём труде

И это нормально.

---

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

Раньше (2010-е):

OSS проект → Пользователь ставит сам
→ Платит за поддержку/консалтинг
→ Автор зарабатывает

Сейчас (2020-е):

OSS проект → AWS/Google берут код
→ Продают как облачный сервис с управлением
→ Зарабатывают миллиарды
→ Автор получает лайки на GitHub 

Пример Elastic:
• 2019: AWS запустил OpenSearch (форк Elasticsearch)
• AWS зарабатывает миллиарды на чужом коде
• Elastic меняет лицензию на SSPL
• Сообщество: "Elastic предали OSS!"

Вопрос: а как должен был поступить Elastic? Работать бесплатно, пока AWS забирает рынок?

---

Что изменилось для DevOps

Плохая новость:
Эпоха «скачал, поставил, забыл» закончилась.

Хорошая новость:
Это заставляет думать об архитектуре, а не о конкретном инструменте.

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

❌ Не полагайтесь на «бесплатность» OSS в долгосрочной перспективе
✅ Проектируйте так, чтобы можно было заменить инструмент
✅ Читайте лицензии (да, скучно, но важно)
✅ Держите стратегию миграции в запасе

---

Примеры изменений инструментов (2025)

* Redis: BSD → больше не OSI open source, source-available + enterprise
* MongoDB: AGPL → SSPL (для защиты от облачных провайдеров)
* Terraform: MPL 2.0 → BUSL 1.1 → OpenTofu форк
* Grafana: Apache 2.0 → AGPL + Enterprise UI
* MinIO: Apache 2.0 → AGPLv3 + коммерческая лицензия
* Nexus Repository: OSS ограничен, управление ролями и безопасность → Enterprise

Паттерн: Успешный OSS → Облачные компании забирают рынок → Автор меняет лицензию

---

📌 Мораль

Мы вошли в эпоху post-open-source.
Код открыт, модель – коммерческая.

Это не плохо.
Плохо делать вид, что ничего не изменилось.

Хороший DevOps в 2026 –
это не тот, кто верит во «всё бесплатно»,
а тот, кто готов платить или мигрировать.

Инструменты меняются. Архитектуры остаются.

---

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

Сталкивались с ситуацией, когда OSS-проект вдруг стал платным?
Как решали: платили, мигрировали или форкали?

Напишите в комментариях – интересно узнать ваш опыт!

➡️ Среда: «5 паттернов, как OSS медленно становится неудобным»

#мышление #devops

💀 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