Сегодня в OTUS в чате преподавателей вышел пост делюсь с вами

Рубрика «Знакомство с преподавателями»

Привет, коллеги! 👋
Сегодня познакомим вас с экспертом, который знает всё о том, как выстроить эффективные процессы разработки и тестирования.

Алексей Рахманов — руководитель департамента разработки и тестирования в компании Fun&Sun, а также преподаватель курса Chief Technical Officer (CTO) в OTUS. Его практический опыт и экспертные знания помогают студентам осваивать навыки технического лидерства.

Если хотите глубже погрузиться в тему управления IT-проектами, подписывайтесь на канал Алексея — IT Шишка @itknar. Там он делится полезными материалами и разборами.

🔗 Интересный пост от автора:
Неделя, которая зарядила меня на месяцы вперед
https://t.iss.one/itknar
Заглядывайте! Будет полезно 🔥

Привет, Шишкины читатели!
Обращаюсь к своей команде знаю вас тут много .

Когда-то в далеком 1971 году профессор Стэнфорда, уважаемый Фил Зимбардо, провел эксперимент в подвале университета, где студентов разделили на 'заключенных' и 'надзирателей'. Сам черт знает, что там пошло не так, но эксперимент закончился галопом по Европам и ушел в историю как ужасная иллюстрация человеческой жестокости. Но не бойтесь, мы не собираемся конвертировать наш Telegram-канал в политологию. Это вам для контекста.

Суть дела в том, что в эту пятницу мы собираемся провести свой эксперимент. Чудесный сборище всей нашей айтишечки и просто тех, кто любит умные мысли.

Мы запустили анонимный опрос. Да-да, мои дорогие, анонимный. Никто не узнает, кто есть кто. Не совсем, конечно, как у Филушки, но тоже интересно.

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

Что вас беспокоит? Какие проблемы есть у нас? Давайте подсветим наши проблемы, чтобы всем было хорошо.
Нельзя решить проблему, которую не видишь. Так что говорите.

Но помните — здесь нет "заключенных" и "надзирателей", только мы.

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

Ребята, с урока по процессам в OTUS — просто огонь! 🔥

Только что отгремел легендарный урок в OTUS на тему, которая рушит мозг: «Как построить процессы, а не проблемы». Не для галочки, а чтобы наконец-то перестать тушить пожары и начать делать работу с кайфом!

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

Мы сконцентрировались на главном: как перестать быть пожарными и стать архитекторами своих рабочих потоков.

Так в чём же мораль всей этой истории? 🧠

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

Настоящее решение всегда на уровень выше:

Остановиться. Вместо того чтобы бросаться тушить очередной пожар, сделать паузу и спросить: «Почему этот пожар у нас вообще возник? Что в нашем процессе сломалось?»

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

Внедрять изменения осознанно. Не ломать всё сразу, а искать точечное изменение в процессе, которое предотвратит целый класс одинаковых проблем в будущем.

Надо не быстрее бегать с ведром, а провести пожарные шланги и поставить датчики дыма.

Кто был — отпишитесь в комментах, на какую больную мозоль вам захотелось наступить после урока? 👇 Для тех, кто не был — следите за каналом, тут только хардкорные инсайты и никакой воды!

https://t.iss.one/itknar

#процессы #системноемышление #отис #менеджмент #рабочие_потоки@itknar

Kubernetes Community Day продолжает радовать! 🎁

фидбек от организаторов — и он идеально соответствует духу конференции: технично и с душой.

Шоппер с провокационной надписью «Лёгкий путь в Kubernetes» — для тех, кто знает, что лёгких путей у нас не бывает 😂 И джин — видимо, тот самый инструмент, который и делает любой путь легче.
Проверим в продакшене! 🧪

Ещё раз огромное спасибо организаторам и всем участникам!
Вы — те, кто делает индустрию живой , человечной и самое главное профессиональной.

https://t.iss.one/itknar

🚨 Инцидент SEV-1: топливная система под угрозой

🌅 Утро, ⛽ заправка, 🚙 два автомобиля в семье: один дизель, один бензин.

🧠 Высокая когнитивная нагрузка, отсутствие ☕ — и вот уже рука тянется не к тому пистолету.

⏰ 11:02 — запах топлива кажется странным.
⏰ 11:04 — внутренний «мониторинг» сигналит: это бензин.
⏰ 11:05 — 🤬 *ять! (Эмоции)
⏰ 11:06 — ✅ решение принято: двигатель не запускаем.
⏰ 11:07 — 📞 вызван ЭКСПЕРТА
⏰ 11:20 — 🔧 снять предохранитель на топливный насос
⏰ 12:30 — 💦 промывка топливного бака на месте

📊 Severity: SEV-1.

💸 Потенциальный ущерб: ремонт двигателя и downtime на недели.

💰 Фактический ущерб: 1,5 часа простоя и стоимость промывки (≈1% от worst-case).

🕵️ Root Cause Analysis

🔑 Root Cause: нарушение процедуры double-check перед заправкой.

➕ Contributing factors:

🚗 два автомобиля с разным типом топлива;

🌙 утро, 😴 усталость, отсутствие ☕;

🔄 схожесть пистолетов.
🛡️ Detection & Mitigation

👃🖐️ Detection: сенсорные «сигналы» (обоняние, тактильные ощущения) + внутреннее правило мониторинга.

🛑 Mitigation: двигатель не был запущен (операция остановлена до «деплоя»), 🚀 эскалация по заранее известному сценарию.

💻 Параллели с нашим миром.

🚀 Запустить двигатель = деплой уязвимого билда в прод.

↩️ Отмена запуска = pre-deployment rollback.

👨‍🔧 Эксперт + промывка = hotfix-процедура.

🏷️ Стикер «DIESEL ONLY» = pre-deploy checklist.

📌 Action Items

🏷️ Наклеить визуальную метку «DIESEL ONLY» на люк бака (до 25.08).

📋 Ввести «pre-fuel checklist» — аналог pre-deploy checklist (до 01.09).

👀 Подумать о дополнительных визуальных/тактильных сигнализаторах (до 15.09).

📚 Lesson Learned
Инцидент-менеджмент — это не про отсутствие ошибок.

Это про то, чтобы:

👀 Обнаруживать проблему до
того, как она превратится в катастрофу.

🧭 Реагировать по плану, а не в панике.

📖 Учиться на ошибках и обновлять правила.

❓ А у вас были «житейские инциденты», которые отлично легли на IT-практики?

За кулисами ПыхConf:

Вчера отыграл роль ведущего на ПыхConf и вернулся с абсолютно перепрошитым мозгом. Это был не просто ивент, а громкое заявление всего PHP-сообщества.

Организация — на высшем уровне, атмосфера — заряжающая.

Хочу выделить три ключевых инсайта, которые перевернули мое восприятие:

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

Личный разрыв шаблона: Drupal. 15 лет назад я его «щупал», и у меня было одно, очень крепкое мнение на букву Г. Он казался неудобным и переусложненным.

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

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

Архитектурный инсайт:

Вселенная, где в центре — Событие.

Казалось, что я отлично знаю подход Event Sourcing; но один гениальный доклад всё перевернул.

Провели аналогию: раньше мы думали, что Вселенная крутится вокруг Земли (в коде это какая-то главная сущность). Чтобы описать процессы, приходилось городить сложную логику.

А потом Коперник переместил центр на Солнце — и орбиты стали простыми эллипсами.

Так вот, Событие (Event) — это новое Солнце.

Смотришь на это через призму «центра вселенной» — и мозг буквально взрывается. Задаёшь себе вопрос а что если центр вселенной не там. Тогда все играет другими красками. Начинаешь совершенно по-другому видеть архитектуру прошлых и текущих проектов. Кажется, что знал всё это и раньше, но такой ракурс меняет сознание.
Философский взгляд и пожалуй я готов к эксперементам.


ПыхConf — это именно про такие инсайты. Про то, как выглядит по-настоящему зрелое и гостеприимное tech-сообщество, которое заставляет думать и расти.

Огромный респект организаторам и каждому участнику. Вы зажгли огонь.

Отдельное спасибо за новый ракурс Игорю Маркину с докладом про Event Sourcing

Всем,кто ещё сомневается в силе PHP-экосистемы — настоятельно рекомендую сходить в следующий раз.

🚨 [ЗАКРЫТ] Инцидент SEV-1: Топливная система под угрозой. RCA соблюден.

Помните наш пост про инцидент с заправкой не тем топливом? 🚙⛽ Время отчитаться о выполнении Action Items.

Система защиты от человеческого фактора получила долгожданный патч.

🛡️ Representational State of KOT

В рамках мер по недопущению повторения инцидента (п. «Подумать о дополнительных визуальных сигнализаторах») в архитектуру топливной системы был внедрен новый компонент.

Встречайте: Визуальный Валидатор Конфигурации «Дизель».

Техдол! Придуманная история про не придуманные проблемы.

Привет шишкины читатели! 👋

Знакомьтесь, это Андрей — новый технический директор на современной АЭС. Его первый рабочий день, а система мониторинга уже показывает сбой в контуре аварийного охлаждения. Инженеры разводят руками: "Так исторически сложилось".

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

Но шли годы, и "временное решение" обрастало зависимостями:

2005 год: к лампе подключили систему диагностики
2010 год: через ее цоколь пустили заземление контрольной аппаратуры
2015 год: обнаружилось, что нагрев лампы регулирует чувствительность датчиков
2018 год: выяснилось, что стеклянный колпак создает нужный микроклимат для реле

Каждый новый инженер, узнавая о "лампе-стороже", лишь разводил руками: "Работает же, не трогай".

Цена вопроса 🔤

Андрей считает:

Сегодня: замена лампы = остановка реактора на 2 недели → 2 млн $ убытка

Через год: потребуется перепроектирование подсистемы + 2 месяца работ → 15 млн $

Через 3 года: полная переработка архитектуры + 6 месяцев → 50 млн $ и риск потери лицензии

Вызвали того самого инженера (уже пенсионера). Тот ахнул: "Вы до сих пор эту лампочку не заменили? Я же оставил схему для временного решения!"

О чем это вам? 🙈

Если вы заказчик/менеджер:

Техдолг = скрытая ипотека. Платить все равно придется, но с процентами

"Временное решение" живет дольше, чем ваш проект

Цена исправления растет экспоненциально с каждым годом

Если вы разработчик:

"Костыли" обрастают мясом и становятся частью архитектуры

Чем дольше тянете, тем страшнее прикасаться к системе

Ваша задача — не молчать о проблемах, даже если "и так работает" Ваша задача показать что будет. Какова цена отсрочки?

Что делать? 🧹

1. Регулярный аудит технического долга

2. Приоритизация: что опасно уже сегодня

3. Выделение 20% времени на "техническое здоровье"

4. Прозрачность для бизнеса: показывайте стоимость отсрочки

Потому что техдолг — это не про "плохой код". Это про управление рисками и деньгами. Вопрос не в том, "будем ли мы платить", а в том, "когда и сколько".

А в ваших проектах есть такие "лампочки"? Поделитесь историями — обсудим, как с ними бороться! 👇

Как я играл в IT Poker от K2 Cloud

Хочу поделиться крутым опытом и поблагодарить команду K2 Cloud за приглашение на IT POKER. Мне посчастливилось стать участником проекта, который ломает все стереотипы о покере.

Что это было?

Это не просто карточная игра. Представьте себе гибрид покерного турнира и стратегической сессии по проектированию архитектуры.

Суть в том, чтобы собирать "руки" не из карт, а из микросервисов.

Для мозга это был настоящий челлендж — непривычно и безумно интересно.

Классное комьюнити. Было здорово пообщаться вживую с коллегами из индустрии, обсудить общие боли и найти неожиданные решения.

Спасибо организаторам и съёмочной группе за безупречную работу и атмосферу. Вы создали не просто шоу, а уникальную площадку для айти-мышления.

Это тот самый случай, когда хобби и профессиональные навыки слились воедино. Уверен, что у проекта большое будущее, и он откроет покер для новой, tech-ориентированной аудитории.

Первый выпуск уже скоро в сети. Очень рекомендую к просмотру!

Спасибо вам!

Лидерство в изменениях: как не уплыть по течению, а построить свой флот

Всем привет! ✌️ Только вернулся с мощного обучения по «Лидерству в изменениях». Не курс, а настоящий тренинг по управлению хаосом. Делюсь инсайтами и проводим яркую параллель.

Если в двух словах: управление изменениями — это не про то, чтобы тушить пожары, а про то, чтобы строить пожарные депо и учить команду ими пользоваться. А теперь — с погружением в историю!

«Зачем меняться?» или «Эпоха застоя»

Бывает такое: вроде все работает, «так всегда и делали», процессы отлажены. Но мир вокруг уже изменился. Пока мы довольствуемся свечой, мир изобрел электричество. Так и в IT: пока мы используем устаревшие инструменты, конкуренты уже выпускают фичи раз в день.

Историческая аналогия: Любая эпоха технологического застоя. Представьте общество, которое гордится своими телегами, пока соседи уже запускают первые паровозы. Стабильность есть, а будущего — нет.

Вывод для нас: Комфорт — главный враг прогресса. Если не инициировать изменения самим, они придут извне, и тогда придется не строить, а догонять.

Посмотрите на картинку вся правда жизни.

«Создание видения и работа с сопротивлением» или «Великие реформы»

Вот ты, как лидер, видишь светлое будущее: agile-команды, DevOps-культура, TTM за неделю. А команда видит лишь «болезненный и непонятный отказ от привычного». «Зачем нам этот ваш новый фреймворк? У нас и так все работало!»

Снова смотрим на картинку.

Историческая аналогия: Эпоха масштабных преобразований — основание нового города, создание флота, переход на новые технологии.

Видение: «Мы станем лидерами рынка, на который выйдем первыми».

Действия: Строительство новой инфраструктуры, внедрение современных стандартов, переобучение команд.

Сопротивление: Саботаж, консерватизм, страх перед новым.

Методы: Четкое донесение выгод + создание новой системы мотивации (карьерный рост, признание, бонусы).

1. Видение должно быть кристально ясным. Не «внедрим CI/CD», а «сократим время выпуска релиза с месяца до одного дня, чтобы обгонять конкурентов».

2. Сопротивление неизбежно. Его нужно не давить, а понимать. Люди боятся не изменений, а потери статуса, компетенций, комфорта.

3. Нужны «агенты изменений». Найдите в команде  — тех, кто горит идеей. Их энергия заразит остальных.

«Управление кризисом» или «Смутное время»

А что делать, когда изменения не ты инициировал, а они на тебя свалились? Кризис, паника, нет лидера, все рушится.

Историческая аналогия: Смутное время. Старые структуры рухнули, царит неразбериха, цели непонятны. Казалось бы, конец.

В кризис нужен не менеджер, а лидер.

Собирается ополчение (кросс-функциональная команда), которое не ждет указаний сверху, а берет на себя ответственность.

Ставится четкая и простая цель («Освободить Москву» / «Восстановить работоспособность системы»).

Ключевая мысль: Кризис — это время возможностей. Он ломает старые, неэффективные процессы и дает шанс построить новые, более сильные.

🛠️ Резюме и практические инструменты:

1. Будьте архитектором, а не пожарным. Стройте прочные процессы, а не героически тушите костры.

2. Создавайте правильную мотивацию. Изменения должны быть выгодны команде. Новая система грейдов, обучение за счет компании, понятный карьерный трек.

3. Помните про волю к действию. В кризис не паникуйте, а берите на себя ответственность, объединяйте людей и ведите их к цели.

Лидер в изменениях — это не тот, кто просто объявляет о новом курсе. Это тот, кто сам становится штурманом, прокладывает путь через сопротивление и неопределенность и ведет свою команду к новой, более сильной версии себя и продукта.

А у вас были свои «Великие реформы» или «Смутные времена» в проектах? Делитесь опытом в комментах! 👇

День отца

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

Сначала это казалось багом. Потом — фичей. Теперь я понимаю: это чистый репозиторий.

И у меня есть доступ на запись. Право и возможность собрать с нуля то, чего не было у меня.

Я не могу коммитнуть исправление в свое прошлое. Но я могу создать новый проект. Проект под названием «Отец».

Архитектура: Безопасность и доверие.

Стек: Любовь, терпение и принятие.

Документация: История нашей семьи, которую я напишу сам.

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

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

И мой главный коммит в этом мире — не код в репозитории, а уверенность в глазах моих детей. Осознание, что его система — их жизнь — собрана на надежном и любящем фундаменте.