Поправил настройки, теперь можно копировать и пересылать)

🧠 Как превратить собеседование из рулетки в инженерный процесс?

Если вы устали искать «идеальных» кандидатов и обжигаться на тех, кто "вроде норм", эта статья — для вас.
Разложил по полкам:

✅ как понять, кто вам реально нужен
✅ как проверять не знание, а мышление
✅ как интервью становится не фильтром, а усилением

Без воды. С примерами. Готово к применению.
📎 Читаем на Хабре: [ссылка]

#ПорядокИзХаоса #CTO #Hiring #TechLead #Интервью #Найм #Команды #Практика #БезВоды

🥳 Первая сотня — есть. Спасибо, что читаете)

🔥[Debug карьеры] От бригадира до CTO: как превращать опыт в преимущество в IT
🎬 ВК-видео 🎬 YouTube 🎬

Заберете за один кофе-брейк:
• Лидер ведет, тиран толкает — и почему страх разоряет бизнес.
• Делегирование спасает 8 часов сна, а не прикрывает лень.
• Как победить синдром самозванца и разрешить себе руководить.
• Ошибка «сделали звезду лидом» и как исправить.
• Как превратить интуицию в чек-лист действий.
А какую свою рабочую фишку вы бы добавили сюда?

Канал ведущей Юлии Уваровой — @julia_uvarova_psy_cab

#ПорядокИзХаоса #CTO #Лидерство #DebugКарьеры

🔥 Новая статья: “1-on-1? А смысл?”

Если вы:
— проводите 1-on-1, но не видите эффекта,
— пытаетесь внедрить формат, но всё буксует,
— или просто хотите понять, как делать это системно

Разложил по полкам:
✅ зачем вообще нужны 1-on-1 (в цифрах и деньгах)
✅ как построить доверие и не скатиться в формальность
✅ шаблоны, чек‑листы, инструменты — запускаете за 1 день
✅ признаки, что формат не работает (и как перезапустить)

📌 Для тимлидов, техлидов, менеджеров, кто хочет делать 1-on-1 с результатом.

📝 Статья на Хабре

Привет

Я открываю несколько бесплатных 30-минутных слотов на разбор инженерных процессов.

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

Сделал короткую Google-форму — это чек-лист зрелости процессов: релизы, PR, CI/CD, инциденты, документация. Заполнение займёт 5–10 минут и поможет вам понять, что у вас уже отлажено, а где ещё остаются пробелы.

Я свяжусь с теми, кто в форме отметит, что хочет консультацию.

Ссылка на форму: https://forms.gle/KhURLZGbE3qXmoDV7

Если будут вопросы или предложения — пишите)

Привет!
Хочу попробовать новый формат — «10 постов на тему».
Ритм простой: по одному посту в день, с понедельника по пятницу.
Две недели — и тема раскрыта со всех сторон.
Начну с самой близкой и понятной всем — GitFlow и культура релизов.
Следом пойдёт Observability & Quality — поговорим про SLI, SLO и SLA.
А дальше темы будем выбирать голосованием, если формат «зайдёт».
Первый пост выйдет сегодня в 18:00.
А вот во сколько удобно получать следующие — давайте решим вместе.

Серия: Gitflow & Release discipline.
Пост 1/10 — ветки не спасут без релизной дисциплины.

Когда у вас следующий релиз? Если ответ — «как соберём» или «к концу спринта», на самом деле ответа нет. У релиза нет ритма и хозяина.

Gitflow сам по себе не даёт стабильности. Любая схема ломается, если релиз ведёт «кто свободен», а не назначенный владелец — DRI (Directly Responsible Individual, единолично отвечает за прохождение релиза по шагам). Без DRI срывается ритм, PR-ы тянутся неделями, растут «служебные» ветки ради видимости порядка — а хаос остаётся.

Мы видели это десятки раз: «по готовности» релизы копятся, баги приезжают пачками. Стоило ввести недельный ритм и DRI — и хаос начал исчезать.

Что работает: фиксированный ритм (например, раз в неделю), явный DRI на каждый выпуск и минимальные релиз-гейты — короткий список обязательных проверок.
Базовый набор: суточная заморозка релизов перед выкладкой, smoke-тест сразу после, готовый план роллбэка. Тогда ветки — инструмент управления риском, а не «магия из блога».

🗓️ Сегодня: за 15 минут зафиксируйте две ближайшие даты и частоту релизов. Назначьте DRI на каждый выпуск.
Завтра — чек-лист релиза на один экран: что проверить до/во время/после, чтобы ничего не упустить.

Как вы решали вопрос релизного ритма до сегодняшнего дня: фиксированные релизы, по готовности или «как получится»?
#GitFlowRelease

Серия: Gitflow & Release discipline.
Пост 2/10 — релиз как процесс: «до / во время / после».

Релиз — это не кнопка «выкатить». Это процесс с тремя разными шагами и режимами ответственности.
Больше всего факапов случается на стыках — особенно между «во время» и «после», когда пропадает владелец шага и за продом никто не следит.
Чек-лист (в файле) закрывает именно эти стыки ответственности.

Если мыслить датой релиза — управлять рисками негде.
Мыслите фазами.
«До» — подготовка: freeze изменений, согласованный набор задач, план отката и чёткие критерии go/no-go. Цель — предсказуемость.
«Во время» — окно релиза: нужные люди на связи, сборка воспроизводима, быстрый smoke-тест, наблюдаемость в норме.
«После» — наведение порядка: back-merge, релиз-ноты, заметки по инцидентам, проверка алертов и таймингов.

Сегодня: назначьте владельцев для «до», «во время» и «после».

Завтра: покажу как выбрать схему ветвления под ваш контекст


💾 Сохраните пост и файл, поделитесь с тимлидом и QA.

#GitFlowRelease

Серия: Gitflow & Release discipline.
Пост 3/10 — как выбрать схему ветвления под свой контекст.
 
Что выбрать, gitflow или trunk? 🤨
Если выбирать только из 2 — вы потеряли минимум пару вариантов.
У нас есть 5 схем (не считая вариации), и у каждой своя польза, цена, и риск.
И важно не «что сейчас модно», а чего вы хотите избежать — потери скорости или потери предсказуемости.
 
Trunk-based — для быстрых циклов и фич под флагами. Минимум веток, максимум автоматизации. Стильно, модно, молодежно, микросервисно.
Gitflow (классика) — релизные ветки, freeze и кандидаты. Хорош, если есть QA-окна и регресс-пакеты.
GitLab Flow — упрощённая адаптация Gitflow под CI/CD: main + feature + hotfix, деплой по тегам.
Release Train Flow — "поездатый ритм" и фиксированные даты, работает при большом масштабе.
Environment Flow — отдельная ветка на среду, когда релизы проходят аудит (CAB, ISO, GxP). Динозавр из нулевых (крупные банки, фарма, телеком), сейчас используется редко.
Custom Mix — гибрид из trunk и release под ваш контекст, свои правила тегов, гейтов и вообще чего угодно. Опасно, но продуктивно — если знаешь, что делаешь.

Файл с матрицей и гайд — в следующем сообщении.
 
Сегодня: пройди матрицу выбора (5 стратегий × 16 критериев) — за 10 минут поймёшь, какой флоу минимизирует твой риск. (Может пора менять текущий?)
Завтра — разберем чем может пахнуть флоу.

А у вас — «сам решу» или «так исторически сложилось»? Будете менять?

Серия: Gitflow & Release discipline.
Пост 3/10 — как выбрать схему ветвления под свой контекст.

Серия: Gitflow & Release discipline.
Пост 4/10 — чем пахнет ваш флоу.

Знаете, чем пахнет огонь? Он пахнет палёными волосками в носу.
Вряд ли вы стали бы терпеть этот запах, или пробовать ещё раз.

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

Нам кажется, что вроде всё работает как нужно, не замечая или игнорируя запахи.
А на деле наш флоу медленно расползается. Ошибки копятся и приводят к сбоям в системе.

Все знают, что по пятницам релизить нельзя. Это уже мем.
Но я готов поспорить — среди нас есть герои, у которых релизы проходят именно по пятницам.
Отзовитесь в комментах, расскажите свою печальную историю — пусть она спасёт кого-то.

Топ-5 причин, разрушающих процессы
0️⃣ Пятничный мердж (вне топа)
Релизы и крупные вливания делаются «перед выходными».
Плохо: повышает риск аварий и хотфиксов в субботу. Мы же любим работать по ночам и на выходных — никто не мешает.
Фикс: freeze с четверга, пятница — только хотфиксы и ретро.

1️⃣ PR/MR-кладбище
Десятки реквестов висят неделями без ревью.
Плохо: теряется контекст, растут конфликты, ревью становится фикцией.
Я не помню, что утром делал — а тут попробуй вспомни, о чём реквест, который был две недели назад…
Фикс: SLA на ревью ≤48 ч, дробите на более мелкие (в идеале < 400 LOC).

2️⃣ Слепой апрув
«Апрув веры». Или «лени». Или «заколебали, дайте поработать».
В общем, ревью на отвали — ради галочки, что ревью есть.
Плохо: ошибки уходят в прод, качество падает, ревью перестаёт быть префильтром и инструментом инженерной культуры.
Фикс: ≤3 ревью в день на человека; smoke-тест перед апрувом (если возможно); ревьюер несёт ответственность за мерж.

3️⃣ Плавающий релиз
Релиз «по готовности».
Плохо: предсказуемости нет, QA не успевают, разработка, тестирование и деплой живут в разных ритмах.
Фикс: фиксируйте день и час релиза.
Если не успели запилить фичу — не сдвигаем релиз на завтра, а переносим её в следующий релиз.

4️⃣ Долгие freeze’ы
В преддверии релиза всё замирает на несколько дней или даже недель.
Плохо: копятся долги, фичи, команда теряет темп.
Фикс: freeze ≤ 48 ч; включайте фичи под флагами, чтобы не блокировать разработку. (если применимо)

5️⃣ Дежурный герой
Один человек знает весь процесс и тащит всё сам.
Плохо: bus factor = 1. Отпуск, заболел, уволился — релизы встали колом.
Фикс: ротация DRI и явный протокол релиза (чтобы любой мог провести релиз при необходимости).


Сегодня: выберите один запах, который нервирует вас больше всего, и наметьте план фикса (или даже пофиксите).
Завтра — кейс как из «мерж, молись, деплой» вышли к стабильному ритму и нулевому CFR. (и такое бывает)

Кто релизит по пятницам — признавайтесь в коментах.

#GitFlowRelease

Серия: Gitflow & Release discipline. Пост 5/10 — трустори.
Все имена и события вымышлены. Любые совпадения случайны.
Далее — рассказ от имени моего воображаемого друга, который, конечно же, не я.

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

Мы старались, правда старались. Но раз в пару недель — обязательный факап.
Любой релиз был стрессом для всей команды.
Вероятность, что что-то отвалится, была сильно не нулевая.
А релизы у нас шли «как бог на душу положит»: то ни одного за две недели, то два за день.

Если два за день — это волнительно, то представьте, что творилось, когда накапливался мегапак за 2–3 недели.
Сто процентов что-то пойдёт не так.
А значит — нас снова ждёт лекция о «криворуких» и «уволить всех к чёртовой матери».
Мне кажется, я не один с такой историей.
 
Отчёт Harness — The State of Software Engineering Excellence 2025 говорит:
50 % деплоев всё ещё делаются вручную.
64 % пайплайнов содержат ручные шаги.
67 % команд не могут собрать и протестировать dev быстрее чем за 15 минут.
И 10 % компаний регулярно (!) ловят критические (!) баги на проде.

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

Ладно, поныли — теперь про хэппи-энд.

Сначала мы внедрили CI/CD-пайплайны.
Они убрали часть человеческих ошибок при деплое и упростили ролбэк.
Потом защитили master — теперь влить можно только через merge request с обязательным ревью.
Благо, с ревью проблем не было.
Дальше — зафиксировали даты релизов.
Ввели фриз за сутки: чтобы попасть в релиз, фича должна пройти локальное тестирование.
Менеджерам сначала досталось — клиенты привыкли «хочу здесь и сейчас».
Но доводы про качество подействовали.
И внезапно стало нельзя обещать всё на свете к следующему демо — пришлось сокращать скоуп спринта.
И о чудо:
ёмкость команды выросла,
багов стало меньше,
разработка — предсказуемее.
Даже QA вздохнули: очередь на smoke-тесты резко сократилась.
Фейл на проде стал событием из ряда вон, а не «ну мы же релизились, чего вы хотели».

Видели ли мы картину целиком, когда всё это начинали? Конечно нет.
Просто шаг за шагом делали чуть лучше. День за днём, неделя за неделей.
Итог — факапы в проде упали с 2-3 в месяц до 0 за квартал.

Это очень большой повод для гордости.
Если получилось у нас — получится и у вас.

Сегодня: делай ничего. Сегодня пятница, никаких изменений по пятницам.
В понедельник — протокол релиза end-to-end: шаги, роли, тайминги — чтобы «спокойно» стало нормой.

#GitFlowRelease

Когда-то у нас в команде была практика парных ночных релизов.

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

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

Уже немного сомнительно, да?

И вот на одном из релизов «знающий» уснул. Просто вырубился от усталости. Ни докричаться в хадле, ни дозвониться на мобильный.
А второй, с руками но без контекста, остался в одиночестве посреди ночи.
Закончилось всё хэппи-эндом. К пяти утра, наощупь, методом проб и ошибок он всё-таки собрал релиз.

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

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

У вас релизы на людях или на процессах?
#GitFlowRelease

Вчера я упомянул протокол релиза.
А в этом посте писал про чеклист релиза.

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

В аттаче — базовый шаблон протокола релиза.

#GitFlowRelease

На заре своего становления как программиста я использовал trunk-based development (TBD).
Если это подходит для Гугла, Нетфликса и Фейсбука, с их тысячами коммитов в день — подойдёт и для меня. Логично же. Там не тупые ребята сидят, между прочим.

Я проработал так примерно полгода, пока на проект не пришли ещё два трейни.
И этот ваш TBD оказался полной хренью. Ну неудобно же! Постоянно конфликты, постоянно что-то отваливается. Кто это вообще придумал?
Мы тут с тремя коммитами справиться не можем, а они в своём Гугле тысячу в день льют...
В общем, мы посовещались — и перешли на GitFlow.

А всё почему?
А всё потому, что мы неправильно понимали TBD.
Оказалось, что это не ARAM (All Random All Master).
Если ты пушишь в мастер по вечерам, а утром пуллишь обратно — это не TBD.
Даже если ты пушишь с ребейзом, запустил тесты локально, делаешь merge request вместо прямого пуша в мастер — это все равно не trunk-based development...

Сейчас trunk уже нельзя представить без Merge Queue / Train — чтобы никто не ломал master.
- Без быстрого CI/CD — иначе ваши частые мержи будут висеть на длинных пайплайнах. (А если нет частых мержей, зачем вообще брали trunk?)
- Без feature flags — иначе вы не сможете запушить незавершённые фичи или быстро отключить фичу в случае фейла.
- Без короткоживущих, атомарных, итеративных веток — иначе получите большой дрейф и конфликты. Короткие MR — это основа trunk-ритма.
- Без быстрых автотестов (unit + integration) на каждый мерж.
- Без observability и алертов. (Формально это про CD Maturity, но я готов спорить до хрипоты, что это неотъемлемая часть любого флоу.)

Вот и получается, что trunk — это не про одну ветку и не про “пушим в мастер”,
а про зрелость команды и процессов, без которых всё превращается в ARAM и merge-hell.

Если у тебя эталонный trunk — похвастайся, бахни 😇 (если только на словах — 👻)

#GitFlowRelease

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

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

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

но, "я своё отбоялся. отплакался, отбоялся, ваще по цензура" (с), поэтому я в поиске драйверов, которые дадут максимум профита с минимальным усилием всем и каждому.

на стартовом наборе данных уже нащупал корреляцию между скоростью пайплайнов и качеством код-ревью, между алертингом и качеством релизов. даже наличие или отсутствие конкретной роли в команде может очень сильно поменять картинку. например одна роль поднимает удовлетворение от релизов на 4 пункта (это просто пропасть). угадаете какая?

сейчас мы собираем расширенный набор данных, чтобы убрать шум и подтвердить предположения.
поэтому прошу каждого, кто добрался до этих строк, пройти опрос (ссылка на форму).
да, он не маленький, порядка 60 вопросов, но он работает в 2 стороны. не только помогает нам со сбором данных, но ещё и является чек-листом зрелости инженерных процессов внутри компании. 7-10 минут — и вы поймёте, что у вас не так.

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

PS. сбрось, пожалуйста, ссылку ребятам, кому может быть это интересно, особенно тем кто постоянно жалуется на процессы). чем больше респондентов, тем смелее мы сможем говорить о корреляциях (а там есть очень и очень любопытные)
PPS. спасибо всем, кто уже поддержал сбор данных в своих каналах, вы очень сильно забустили)

Сегодня вышел пятничный пост на Хабре — про петуха на проекте.
Не с целью оскорбить тимлидов, а рассказать, какие бывают 🙂

Но кроме тимлидов у нас есть и другие роли.
- Ворона (PM). Сидит на заборе, громко каркает: «Мало яиц! Лиса близко! Корм заканчивается!». Не помогает, но информирует и следит, чтобы все были в курятнике вовремя. Иногда ворует яйца, но делает вид, что не она. Петух с ней не дружит, но на заборе достать не может.
- Белка (QA). Таскает яйца в разные места. «Из дупла выкатится? А если закопаю — протухнет? А если уронить — треснет?». Часть теряет, часть разбивает. Но те, что возвращает — проверены на все случаи жизни. Петух скрипит зубами, но терпит, качество дороже.
- Кролик (BA). Копается в куче соломы. «По статистике, 70% яиц несутся по утрам, 30% — когда фермер не смотрит!». Множит документацию на капустных листах и диаграммы из морковок. Куры в шоке. Петух косится подозрительно. Никто не признаётся, что документацию не читал.
- Выдра (DevOps). Живёт возле поилки, зачем-то крякает и ругается на тех, кто трогает воду руками. Может уронить корзину с яйцами просто проходя мимо. Петух постоянно чего-то от неё хочет, но не может объяснить что. Автоматизировала доставку яиц из гнезда в корзину, но все по старинке носят вручную.

Всем хорошей пятницы)

Ребят, а вы знаете свою среднюю задержку по сервису?
Если да — вы уже делаете то, чего большинство не делает.

Если вы знаете задержку для каждого эндпоинта, участвующего в CUJ — это ещё круче.
Правда, тут легко наступить на грабли. Начнёте мониторить каждый эндпоинт отдельно — можете случайно положить свой мониторинг от кардинальности. Или получить красивый счёт от облачного провайдера. Даже не знаю что лучше.

Но главная проблема не в этом. Без p95/p99 у вас получается как в старом анекдоте — директор ест мясо, рабочие едят капусту, в среднем по компании все едят голубцы.

Окей, следим за p95/p99. Теперь-то точно всё под контролем?
Почти. Но есть нюанс.

Важно помнить, что перцентили не складываются и не усредняются — потому что это квантиль распределения, а не среднее значение. Считайте p95 через агрегированные гистограммы (суммируйте бакеты, потом считайте квантиль).
Если вы усредняете поминутные p95 за день — вы измеряете не задержку, вы измеряете надежду.

Это уже 3 из 5 уровней зрелости в работе с задержкой:
1) Нет измерений, "работает же".
2) Среднее время отклика.
3) Перцентили, но без latency budget.
4) E2E-бюджет, мониторинг хвоста, SLO.
5) Управление бюджетом и отмена запросов, прогнозирование.

Большинство компаний застряли на 2 уровне, искренне считая, что у них всё под контролем, и не могут перешагнуть на следующую ступеньку. Не потому что им не хватает мотивации или нет инструментов, а потому что 3-я ступенька — это про другое мышление. Переход от реактивного тушения пожаров к проактивному проектированию надёжности.

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