1) «Создаём документ, если не нашли»
Симптом: логика вида «если документа нет — создадим». Поиск — по дате/номеру/контрагенту/сумме.
Означает: нет ключа операции, нет управления состоянием процесса.
Последствия:
- 2-й порядок: дубли, расхождение остатков, ручные зачистки.
- 3-й порядок: бизнес перестаёт доверять данным → появляется «теневой учёт» в Excel.
Что делать: вводить бизнес-ключ (внешний ID/транзакция/хеш), журнал обработки, правило «повтор = noop/обновление/отказ».
2) Регламентное задание «дописывает приращения»
Симптом: расчёт за период и дописать в регистр/таблицу итоги.
Означает: результат зависит от истории выполнения (неидемпотентность).
Последствия:
- 2-й порядок: перезапуск = задвоения/дыры.
- 3-й порядок: страх перезапуска → задания не трогают → копится технический долг.
Что делать: пересчёт от первичных данных или «расчёт состояния → синхронизация», контрольные точки.
3) «Флаг обработано» вместо инварианта
Симптом: реквизит/регистр сведений «Обработано = Истина».
Означает: идемпотентность подменена маркером, без проверки факта результата.
Последствия:
- 2-й порядок: флаг выставили, а действие не завершилось (или наоборот) → рассинхрон.
- 3-й порядок: нужны «спецлюди», которые знают как чинить.
Что делать: проверять целевое состояние (инвариант), а флаг — максимум оптимизация.
4) «Транзакция» размазана по процедурам без границ
Симптом: одна операция меняет много объектов; нет явной точки коммита; логика разбросана.
Означает: процесс не атомарен, восстановление невозможно.
Последствия:
- 2-й порядок: падение посередине оставляет систему в «полусостоянии».
- 3-й порядок: запреты на развитие («не трогайте, развалится»).
Что делать: выделять границы операции, фиксировать шаги/состояния, проектировать перезапуск.
5) «Проведение документа» как гарантия выполнения бизнес-операции
Симптом: “если документ проведён — значит всё сделано”.
Означает: путаница уровня «документ» и уровня «процесс/операция».
Последствия:
- 2-й порядок: повторное проведение/отмена/перепроведение ломают связанный контур.
- 3-й порядок: закрытие периода превращается в лотерею.
Что делать: бизнес-операция должна иметь ключ, а документ — быть проекцией результата (или строго управляемой сущностью).
6) Нет «журнала входящих» в интеграциях
Симптом: сообщение обработали и забыли; повтор пришёл — обработали снова.
Означает: система не умеет отличать повтор от нового события.
Последствия:
- 2-й порядок: дубли документов/движений.
- 3-й порядок: интеграции начинают «душить» проверками и ручным контролем.
Что делать: журнал входящих + ключ сообщения + стратегия повторов.
7) «Ссылки на всё подряд» без контрактов и слоёв
Симптом: любой модуль вызывает любой; общие модули — свалка.
Означает: отсутствие архитектурных слоёв и контрактов.
Последствия:
- 2-й порядок: любое изменение ломает неизвестно что.
- 3-й порядок: команда боится рефакторинга → деградация ускоряется.
Что делать: слои (UI/Domain/App/Infra), контракты, правила зависимости, ревью на «запретные связи».
8) «Поддержка» через копипасту обработок и внешних отчётов
Симптом: один и тот же алгоритм размножен в 5 местах.
Означает: нет повторного использования и единого источника истины.
Последствия:
- 2-й порядок: правки расходятся, баги «плывут».
- 3-й порядок: стоимость изменения растёт экспоненциально.
Что делать: выделять доменные сервисы/общие модули/библиотеки, единый алгоритм.
9) Тихие «Попытка…Исключение…КонецПопытки» без логирования
Симптом: ошибки глушатся.
Означает: система предпочитает «казаться работающей».
Последствия:
- 2-й порядок: данные портятся без инцидента.
- 3-й порядок: расследования невозможны → вечные «мистические» баги.
Что делать: политика ошибок: критичные — падаем, некритичные — логируем и сигналим, метрики/алерты.
10) Нет корреляции и трассировки процессов
Симптом: невозможно ответить «почему создался этот документ».
Означает: наблюдаемость отсутствует.
Последствия:
- 2-й порядок: инциденты чинятся руками «по ощущениям».
- 3-й порядок: управляемость системы падает, решения принимают по слухам.
Что делать: correlationId на процесс, лог событий, связность: вход → шаги → результат.
11) Блокировки — «как получится»
Симптом: периодические взаимоблокировки, «сеанс завершён», пляски с УТ/ERP в пике.
Означает: конкурентность не спроектирована.
Последствия:
- 2-й порядок: падение производительности в неожиданных местах.
- 3-й порядок: ограничения бизнеса («не работайте в это время»).
Что делать: проектирование конкурентного доступа, минимизация транзакций, очереди, пакетирование, явные уровни изоляции.
12) Нельзя безопасно пересчитать ключевые показатели
Симптом: «главное не трогать, пересчёт сломает».
Означает: система не воспроизводима; источники данных невалидны.
Последствия:
- 2-й порядок: любой спор с бухгалтерией/финансами заканчивается ручной правкой.
- 3-й порядок: деградация доверия до уровня «ERP как витрина».
Что делать: обеспечить воспроизводимость: первичные факты → расчёт → витрины/итоги.
Быстрый тест хрупкости (10 вопросов архитектора)
Если хотя бы на 2–3 вопроса ответ «ну… зависит» — система хрупкая:
- Повтор сообщения создаст дубли?
- Перезапуск регламентного задания безопасен?
- Можно восстановить процесс после падения на середине?
- Есть ключи операций (не GUID ради GUID)?
- Можно пересчитать итоги и сравнить контрольные суммы?
- Есть журнал входящих/исходящих в интеграциях?
- Есть корреляция процесса (след в логах) от входа до результата?
- Ошибки не глушатся молча?
- Слои и зависимости контролируются?
- Проведение/перепроведение не ломает связанные контуры?
Альтернативная версия (когда «хрупкость» допустима)
Иногда сознательно допускают хрупкость:
- прототип/пилот,
- маленький контур без интеграций,
- временное решение с коротким сроком жизни.
Но тогда обязательно:
- письменная фиксация рисков,
- «красная линия» (когда переделывать),
- стоимость владения и план вывода в промышленный уровень.
Что если я заблуждаюсь?
- Ты можешь переоценивать угрозу повторов — если интеграций нет и процессы строго ручные.
Проверка: сколько реальных повторов/перезапусков было за 6–12 месяцев? - Можно чинить руками дешевле — если объёмы малы.
Проверка: посчитать стоимость инцидентов и ручных корректировок за год. - Часть «хрупкости» — следствие требований бизнеса (скорость важнее качества).
Проверка: есть ли SLA/штрафы/стоимость простоя, которые поменяют экономику?
+ There are no comments
Add yours