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

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

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

Спокойный сценарий часто обманывает

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

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

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

Как выбрать «худший день» без драматизации

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

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

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

Шаг первый: пройдите путь одного решения

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

Дальше полезно пройти путь прямо по ролям. Что видит менеджер? Откуда приходит значение? Может ли он отличить точные данные от предварительных? Что произойдёт, если связь со складом временно недоступна? Кто имеет право изменить обещание клиенту? Где останется след решения?

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

Шаг второй: отделите критичное от удобного

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

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

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

Шаг третий: найдите границы, которые действительно меняются

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

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

О цене будущих изменений я уже писал в статье «Архитектура — это не схема из квадратиков, а цена будущих изменений». Тяжёлый сценарий помогает эту цену увидеть не на диаграмме, а в реальном времени и ответственности людей.

Составной пример: заказ меняется в последний момент

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

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

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

Почему нельзя перекладывать всё на IT

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

Это стоит проговаривать до постановки задачи. В статье о пяти вопросах перед крупным IT-вложением есть тот же принцип: технология должна поддерживать принятое решение, а не заменять его.

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

Документы и наблюдаемость тоже часть решения

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

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

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

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

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

Чего не стоит делать после такого разбора

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

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

Что можно сделать до следующей архитектурной встречи

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

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

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

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