Разбор унаследованного стека за пять сессий для нового техлида

Почему унаследованные системы кажутся рискованными

Новый техлид с первого дня получает в наследство риск. Контекст приходит позже.

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

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

Проблема не в том, что каждый унаследованный стек плох. Многие вполне нормальные. Проблема в том, что сначала вы получаете риск, а уже потом карту.

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

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

Запланируйте пять рабочих сессий

Относитесь к этому как к пяти фиксированным встречам, а не к открытому аудит-процессу. Поставьте все пять в календарь до того, как вас поглотит новая работа над фичами. Если ждать спокойной недели, этого не случится.

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

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

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

Последняя часть важнее, чем ожидают команды. Фраза «проверим доступ позже» исчезает. Фраза «Нина до среды проверит, почему у двух бывших подрядчиков всё ещё есть доступ в продакшен» уже даёт встрече результат.

Такой формат ещё и защищает нового лидера от частой ловушки: собрать слишком много информации и ничего не сдвинуть. Пять коротких сессий обычно дают достаточно данных, чтобы действовать. Месяц слайдов, интервью и устаревших документов — обычно нет.

Сессия 1: разберите развёртывания

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

Покажите реальную последовательность, а не аккуратную версию, которую повторяют на встречах. Попросите инженера выкатить небольшое безопасное изменение, пока вы наблюдаете. Записывайте каждый шаг: merge, запуск CI, сборка артефакта, согласование, миграция базы данных, изменение конфигурации, очистка кэша, feature flag и проверка продакшена. Многие команды думают, что у них один процесс релиза, а на деле их два или три.

Потом проверьте доступ. Сделайте две колонки: кто может выкатывать и кто обычно это делает. Разница между ними показывает, где сидит риск. Если один человек запускает shell-скрипт с ноутбука, хранит cloud token в локальном файле или знает ручной фикс, который больше никто не может повторить, у вас есть знание одного человека в самом неудобном месте.

Откат требует той же детализации. Попросите команду показать шаги отката, а не просто сказать, что они умеют откатываться. Некоторые команды могут вернуть код, но не схему базы. Другие могут восстановить приложение, но забывают про очереди, воркеры или feature flags.

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

Небольшой пример хорошо это показывает. Если продакшен-развёртывания идут через GitLab CI, а hotfix всё ещё запускается через приватный скрипт на ноутбуке одного старшего инженера, документированный процесс верен только наполовину. Сначала исправьте карту. Потом уже решайте, что менять.

Сессия 2: проследите потоки данных

Унаследованные системы часто ломаются в промежутках между инструментами, а не внутри одного инструмента. Начните с трёх типов записей, которые обычно быстрее всего влияют на выручку и поддержку: клиентские данные, продуктовые данные и биллинговые данные. Для каждой записи спросите, где она появляется первой, кто её меняет и где она в итоге оказывается.

Запишите все системы, которые читают или пишут эти данные. Включите очевидные вещи, такие как база приложения, CRM, платёжная система и инструмент поддержки. Потом добавьте и всё то, что люди забывают: таблицы, импорты CSV, общие почтовые ящики, админ-панели и одноразовые скрипты, которые умеет запускать только один человек.

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

Это становится полезным, когда люди показывают передачу данных вместо того, чтобы просто её описывать. Если продажи каждую пятницу выгружают CSV, а финансы загружают его в другую систему, это часть потока. Если кто-то копирует данные о заказе из письма в дашборд, это тоже часть потока. Ручные шаги — это место, где данные теряются, приходят с опозданием или вносятся дважды.

Ищите четыре типичные точки сбоя. Запись создаётся в двух местах. Одна система обновляется быстрее другой. Поле меняет название между инструментами. Или никто не знает, какая система является источником истины. Для этого не нужна идеальная документация. Обычно двадцатиминутный проход с человеком, который реально делает работу, говорит больше.

Возьмём простой пример. Клиент регистрируется в приложении, биллинг стартует в Stripe, данные аккаунта синхронизируются в CRM, а поддержка смотрит отдельную админ-панель. Если синхронизация в CRM идёт раз в шесть часов, продажи могут озвучить клиенту неверный статус. Если поддержка меняет данные аккаунта в админ-панели, а биллинг этого не видит, у вас уже две версии правды.

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

Сессия 3: проверьте отслеживание ошибок

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

Начните со списка всех мест, которые собирают сигналы. Обычно сюда входят инструменты для ошибок приложения, серверные логи, проверки доступности, облачные алерты, алерты базы данных и чат или pager-канал, где люди их видят. Многие команды используют что-то вроде Sentry для ошибок приложения и Grafana, Prometheus или Loki для метрик и логов. Названия инструментов менее важны, чем понимание, за чем именно каждый из них следит.

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

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

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

Слепые зоны часто хуже, чем шумные оповещения. Проверьте фоновые задачи, расписания, webhooks, воркеры очередей, бэкапы и сбои развёртываний. Если что-то из этого ломается, а сигнал никто не получает, запишите это как пробел.

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

Сессия 4: проверьте доступы

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

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

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

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

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

Секреты требуют такого же просмотра. Проверьте, где лежат API-ключи, пароли баз данных и токены подписи. Если люди хранят их в чате, заметках или старых переменных CI, это нужно исправить как можно скорее. Также важно знать, кто их перевыпускает, как часто это делается и что ломается при смене секрета.

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

Привычный пример: три человека делят один продакшен-аккаунт, у одного бывшего сотрудника всё ещё есть VPN-доступ, и никто не знает, кто может редактировать Terraform. Этого достаточно, чтобы случился инцидент, даже если приложение само по себе стабильно.

Сессия 5: найдите утечки бюджета

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

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

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

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

Эта сессия часто находит скучную, но дорогую расточительность. Простаивающие серверы остаются включёнными после миграции. Старые staging-окружения работают днём и ночью, хотя никто не тестирует их вне рабочего времени. Базу данных когда-то увеличили под всплеск трафика два года назад и так и не уменьшили обратно. Команды ещё и платят дважды за одну работу, например за два инструмента отслеживания ошибок или пересекающиеся CI-сервисы.

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

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

Одного примера достаточно: компания платит за большую продакшен-базу данных, постоянно включённую копию staging, два продукта для логов и премиальные места для бывших подрядчиков. По отдельности эти расходы не выглядят пугающе. Вместе они могут за год съесть сумму, сравнимую с зарплатой одного инженера.

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

Простой пример первой недели

Представьте, что новый техлид приходит в SaaS-компанию после спешной передачи дел. Прежний лидер ушёл, документация тонкая, и стеку никто полностью не доверяет. На большинство вопросов отвечают «спросите Сэма», потому что один старший инженер всё ещё держит в голове почти всю систему.

Уже к первому дню становится ясно, где самый большой риск. Развёртывания зависят от локального скрипта, который только Сэм запускает со своего ноутбука. Если он заболел, команда не может уверенно выпустить исправление. Это не процесс. Это узкое место с человеческим именем.

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

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

К пятнице у нового лидера уже есть короткий список на следующий месяц:

• Перенести deploy-скрипт в систему контроля версий и запускать его через CI.
• Назначить одного владельца для каждой передачи данных.
• Убрать шумные оповещения и оставить те, что связаны с реальным ущербом для клиентов.
• Удалить устаревшие админские доступы и общие аккаунты.
• Выключить простаивающие сервисы и дублирующие инструменты, которые всё ещё стоят денег.

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

Ошибки, которые тратят время впустую

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

Самая большая потеря времени — слишком рано писать план переписывания. Новый лидер видит старый код, старые инструменты и накопленный процессный долг и сразу думает: «это надо заменить». Это кажется решительным, но скрывает настоящую проблему. Если ломаются развёртывания, оповещения никуда не приводят или биллинг завален забытыми сервисами, план переписывания — это просто более красивая бумага поверх того же беспорядка.

Старые схемы тоже съедают время, особенно когда люди принимают их за истину. Команды переименовывают сервисы, переносят задания, добавляют скрипты и забывают что-либо обновить. Проверьте продакшен, прежде чем доверять вики. Команды могут часами спорить об одном пути данных, а потом обнаружить, что живой системе уже несколько месяцев служат другой queue и другой storage bucket.

Проверка доступов — ещё одна ловушка. Люди относятся к правам как к админской бумажной работе и откладывают их на потом. Это ошибка. Общий root-доступ, старые аккаунты подрядчиков и загадочные токены могут блокировать изменения, замедлять реакцию на инциденты и создавать реальный риск уже в первый день.

У денежных вопросов есть своя плохая привычка. Команды гоняются за мелкой экономией, потому что её легко измерить. Они тратят полдня на обсуждение хранения логов в малонагруженном инструменте, пока простаивающий кластер, лишняя SaaS-лицензия или раздутый CI-job каждый день сжигают деньги. Сначала берите очевидные потери.

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

Короткие проверки перед любыми изменениями

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

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

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

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

С оповещениями нужен прямой тест. Спросите, что будило кого-то за последние 30 дней, что оказалось шумом и какой сбой всё ещё мог бы проскочить мимо. Если поддержка узнаёт об авариях раньше, чем мониторинг, исправьте это до того, как менять архитектуру.

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

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

Что делать после пяти сессий

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

Начните с малого. Исправьте по одной высокорисковой проблеме в каждой области, прежде чем что-то масштабно переделывать. Это может быть усиление продакшен-доступа, добавление недостающего оповещения, документирование одного хрупкого шага развёртывания, исправление сломанной передачи данных или отключение сервиса, которым никто не пользуется, но за который всё ещё платят.

Практичный первый месяц часто выглядит так:

• Неделя 1: остановить самые очевидные риски.
• Неделя 2: убрать один повторяющийся источник аварий или путаницы.
• Неделя 3: сократить потери, которые появляются каждый месяц.
• Неделя 4: задокументировать новую базовую линию и назначить дальнейшие задачи.

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

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

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

Если вам нужен взгляд со стороны, временный CTO может помочь расставить приоритеты и удержать первый месяц в фокусе. Олег Сотников из oleg.is делает такой практический разбор для стартапов и небольших компаний, особенно когда проблема затрагивает архитектуру, расходы на инфраструктуру, AI-инструменты и риски доставки.