Первые шаги спасения проекта: заморозьте объём, доступ и права на релиз

Почему дебаты об архитектуре тратят первый день зря

Дискуссии об архитектуре кажутся продуктивными, потому что звучат серьёзно. Кто‑то указывает на старый фреймворк, неясные границы сервиса или медленный запрос и говорит: «Это проблема». В первый день спасения это часто не та битва.

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

Вот почему ранние дебаты об архитектуре обычно ни к чему не приводят. Чистый перепис под текущий план может оказаться неверным утром следующего дня, если план снова изменится. Баг, который появился в 10:00, говорит мало, если в 12:00 кто‑то внёс «маленькое исправление» и забыл об этом упомянуть. Логи перестают помогать, когда слишком много людей могут менять живые системы. Команда начинает спорить о корнях проблем без стабильной временной линии.

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

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

Заморозьте объём прежде чем смотреть дизайн

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

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

Это звучит жёстко. Обычно так экономят дни.

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

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

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

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

Одна маленькая SaaS‑команда узнала это на собственном опыте. Они хотели разбирать грязный бэкенд, пока продажи просили тонкие правки отчётов. Лид спасения заморозил объём на пять дней и разрешил только баги, влияющие на биллинг и аптайм. Через два дня стало ясно, что бэкенд — не первопричина. Причина — постоянный поток запросов. После остановки этого потока настоящие дефекты стали очевидны.

Заморозьте доступ прежде чем доверять данным

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

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

Начните с одного простого списка мест, которые важны: исходники, облачные аккаунты, продакшен‑данные, бэкапы, CI/CD, регистры пакетов, билд‑инструменты, магазины приложений, домены, аналитика, платёжные системы и инструменты поддержки. Затем запишите, кто имеет права администратора, кто может делать деплой, кто может читать данные клиентов и кто может менять секреты.

Имена важны. Важны и роли.

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

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

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

Держите экстренные контакты в одном месте. Укажите владельца домена, биллинга облака, продакшен‑БД, магазинов приложений и DNS. Добавьте телефонные номера и запасные контакты, а не только мессенджеры. Когда продакшен упадёт в два часа ночи, никто не должен копаться в старых письмах в поисках единственного человека, который может разблокировать аккаунт.

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

Заморозьте права на релиз прежде чем следующий деплой

Спасение может погибнуть из‑за одного неосторожного релиза. Если трое могут пушить в продакшен, плохой деплой может стереть улики и добавить новый аутедж к старому.

Прежде чем кто‑то начнёт менять код или конфиг, назначьте одного владельца релиза на период заморозки. Один человек решает, что идёт в продакшен, когда это происходит и стоит ли ждать.

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

Автодеплои полезны, когда команда стабильна и система понятна. В спасении они — ловушка. Приостановите любые пайплайны, которые могут попасть в продакшен без человеческой проверки. Это включает деплой при мердже в main, плановые релизы и админ‑ярлыки, обходящие ревью.

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

Добавьте заметки по откату до того, как кто‑то нажмёт «deploy». Если изменение провалится, кто его вернёт, сколько это займёт и что может сломаться при откате? Если никто не может ответить на эти вопросы простым языком, релиз не готов.

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

Это даёт чистую временную линию. Архитектуру можно инспектировать позже. Сначала остановите изменения в продакшене под ногами.

Первые 24 часа — в правильном порядке

Когда команда в беде, порядок важнее скорости. Трогать архитектуру слишком рано — и земля под ногами продолжит двигаться.

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

До конца дня соберите реальный список аккаунтов. Это значит: хостинг кода, доступ в облако, CI/CD, магазины приложений, домены, аналитика, платёжные инструменты, системы поддержки и любые общие админ‑логины. Одновременно документируйте, как сегодня происходит релиз в продакшен.

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

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

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

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

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

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

Такая смесь может разрушить спасение за неделю.

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

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

Затем фиксируют права на релиз. Один человек становится «вратами» деплоя. Никто не шипит с личного ноутбука. Никто не делает merge и сразу же не деплоит. При необходимости горячего фикса тот же человек утверждает релиз и фиксирует причину.

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

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

Ошибки, которые замедляют спасение

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

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

Ещё одна ошибка — держать админ‑доступ «на всякий случай». Лидеры так поступают, потому что боятся, что им может понадобиться быстрый фикс. Результат обычно хуже, чем риск, которого они боялись. Пять человек всё ещё имеют права в проде, трое могут менять биллинг, и никто не знает, какой аккаунт что трогал. Уберите лишние права сначала. Если кому‑то действительно понадобится доступ позже, верните его с чётким обоснованием и сроком.

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

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

Одна громкая встреча может свести на нет всю заморозку. Основатель нервничает, клиент жалуется, менеджер настаивает на «маленьком исключении». Тогда объём снова открывается, люди возвращают старые права, и побочные фиксы начинают лететь.

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

Короткая, строгая дисциплина обычно экономит больше времени, чем любое хитрое техническое решение.

Короткая проверка на первые 48 часов

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

Если какой‑то ответ расплывчат, держите заморозку.

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

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

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

Что делать после заморозки

Заморозка даёт редкое: несколько дней честного сигнала. Используйте это время разумно.

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

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

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

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

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

Если в команде нет нейтрального технического лидера, внешняя помощь может быстро навести порядок. Oleg Sotnikov на oleg.is работает со стартапами и малыми бизнесами как внештатный CTO и советник, включая спасение в доставке, инфраструктуре и практическом внедрении ИИ. Такая поддержка особенно полезна, когда команде нужны чёткие права принятия решений до того, как начнутся очередные архитектурные споры.

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