Первый внешний клиент и год неверного учёта: что находишь когда копаешь руками

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

13 мая начал сначала — с готового установщика. К обеду клиент развёрнут. А вторая половина дня преподнесла сюрприз: полез считать прибыль одной из своих вилл за первый квартал — и нашёл год неверного учёта. В сводной формуле P&L не было налогов и маркетинга. В другой строке расходы занесены с ошибкой в тысячу раз — миллиарды вместо миллионов рупий.

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

День первый: почему я потратил сутки на ручную работу при готовом установщике

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

Почему так? Готовый установщик кажется ограниченным: а вдруг у клиента другое окружение, а вдруг установщик не учтёт специфику. Удобнее кажется «сделать руками, чтобы контролировать каждый шаг». Это ошибочная логика, и к вечеру первого дня я это понял.

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

Это классическая ловушка «знаю как делаю у себя». Когда у тебя один продакшн-сервер, который настраивал месяцами, ты знаешь его наизусть. Ты помнишь где что лежит, какие версии стоят, какие переменные окружения прописаны. Переходя на чужой сервер, бессознательно применяешь те же предположения. Но у клиента Ubuntu другой версии, PostgreSQL другой минорной версии, systemd сконфигурирован иначе. Всё начинает ломаться не системно, а в случайных точках — именно потому что идёшь по памяти, а не по инструкции.

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

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

День второй: установщик спотыкается — и это ценно

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

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

Что конкретно споткнулось: разные пути к директории данных PostgreSQL в разных Ubuntu-версиях, отличающийся формат строки подключения в одной из зависимостей, таймаут при первом запуске на чистой машине без предустановленного браузера. Все три — типичные «первый раз на чужой машине» проблемы. Все три теперь закрыты в установщике. Следующий клиент на следующей неделе уже не споткнётся на этих же точках.

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

О том, почему системы, которые умеют исправлять себя сами, стоят дороже простого автопилота — в статье про self-healing боты и самовосстанавливающиеся системы.

Вторая половина дня: год неверного учёта в формуле P&L

После обеда сел считать прибыль одной из своих вилл за первый квартал 2026. Управляю примерно 16 активными виллами на Бали — lifetime-портфель 65 объектов. По каждому есть автоматический P&L: выручка из PMS-системы, расходы из нескольких источников, итог — прибыль для инвестора.

Открыл формулу. Стал смотреть что входит в расходы. И увидел: нет налогов. Нет маркетинга. Эти статьи есть в детализированных финансовых отчётах. Они есть в банковских выписках. Но в сводной формуле P&L по вилле их нет. Получается, весь год смотрел на доходность с заниженными расходами — и принимал решения на основе завышенной прибыли.

Насколько критично? Конкретно по этой вилле — не катастрофически: налоги и маркетинг составляли примерно 8–12% от расходов. Но сам факт: год учёт шёл с дырой, и я об этом не знал. Потому что система работала, дашборд показывал числа, всё «считалось само».

Почему эта статья выпала из формулы? Формула P&L была написана на раннем этапе, когда налоги ещё не были отдельной строкой — они входили в общий блок административных расходов. Потом структура расходов изменилась: налоги выделили в отдельную категорию для более детального учёта. Формулу не обновили. Она продолжала работать — просто без этой статьи. Никакой мониторинг это не поймает, потому что система не знает что «правильно», она знает только что «работает».

Ошибка в тысячу раз: миллиарды рупий в строчке расходов

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

Как это попало в систему? Вероятно, при ручном вводе расхода перепутали единицы: занесли сумму не в тысячах рупий как принято в форме, а в полных рупиях. Система приняла число без возражений — потому что валидации на реалистичность суммы не было. Число в допустимом диапазоне типа данных — значит ошибки нет. Что ремонтные расходы в 10 000 раз превышают среднемесячную выручку виллы — система не заметила.

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

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

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

Парадокс масштаба: автоматика даёт скорость, ошибка живёт дольше

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

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

Автоматизация хорошо ловит операционные сбои — когда что-то упало, не запустилось, не ответило. Это мониторинг, алерты, health-checks. По данным исследований операционных практик, команды тратят в среднем 6–8 минут на диагностику падения системы, но недели и месяцы не замечают логических ошибок в данных, которые система продолжает «успешно» выдавать. Но логические ошибки — когда система работает, но считает неверно — мониторинг не ловит, потому что мониторинг не знает что считается правильно. Для этого нужен человек с контекстом и готовность периодически выходить из режима «всё работает само» в режим «посмотрю руками».

В командной работе этот контекст распределён: финансист проверяет баланс, операционный директор смотрит на P&L, разработчик проверяет логи. У каждого своя область, и аномалию замечает тот, кто отвечает за неё. При полной автоматизации без команды этот распределённый контроль исчезает. Нет кого-то, кто «просто смотрит» на цифры с другой точки зрения.

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

Как проводить ручной аудит когда «всё считается само»

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

Выборочный пересчёт с нуля. Раз в квартал — взять один случайный объект (в моём случае одну виллу) и пересчитать P&L от первичных документов. Не проверить формулу, а именно пересчитать: открыть банковские выписки, OTA-отчёты, договоры с подрядчиками и собрать итог вручную. Сравнить с тем что выдаёт система. Расхождение укажет на баг. Занимает 2–3 часа на один объект, находит проблемы которые автоматика не замечает.

Граничные условия на уровне данных. Скрипт, который запускается ежедневно и проверяет не бизнес-логику, а здравый смысл: расходы по вилле за месяц не могут быть больше её годовой выручки, выручка не может быть отрицательной, сумма ремонта не может превышать стоимость всего объекта, одна строка расходов не может быть в 100 раз больше среднего за последние 6 месяцев. Если нарушено — алерт в лог и на проверку, не молчание.

Сверка с внешним источником. Раз в полгода — взять итоговые цифры из системы и сравнить с OTA-отчётами (Booking.com, Airbnb дают свою статистику по бронированиям) или с банковской выпиской. Если расходятся больше чем на 5% — идти искать причину. Внешний источник не знает о ваших формулах, он знает только факт.

Чеклист при закрытии месяца. 5–7 строк: налоги учтены, комиссии OTA учтены, конвертация по правильному курсу, расходы маркетинга включены, депозиты не попали в доходы. Занимает 10 минут в конце каждого месяца. Ловит большинство системных пропусков до того как они накопятся на год.

Об автоматическом мониторинге финансов — как строить систему алертов которая работает сама — в статье про автоматический мониторинг финансового учёта.

Что изменилось после этих двух дней

Три конкретных изменения в том, как работаю с автоматизацией после 12–13 мая.

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

Второе: в финансовой системе добавлены граничные условия. Скрипт ежедневно проходит по всем объектам и проверяет 7 параметров здравого смысла. Первый запуск нашёл ещё 3 аномалии в исторических данных по другим виллам — не критичные, но требовавшие ручной проверки. Теперь ошибка в тысячу раз не проживёт и недели — вылезет при ближайшем запуске.

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

Юрий Солар, основатель Solar Property и 4bos.ru: «Главный урок этих двух дней не в том, что нашёл ошибку. А в том, что она жила год и никто — ни система, ни я — об этом не знал. Автоматизация убирает рутину, но не убирает необходимость думать руками хотя бы иногда».

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

Валидация данных на входе: как предотвращать тихие ошибки до их появления

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

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

Конкретно для финансового учёта по виллам я добавил три уровня валидации.

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

Второй уровень — категорийная логика. Налоги не могут быть больше 30% выручки (для Бали типичная ставка — 10–15%). Комиссия OTA не может быть меньше 10% (Booking.com и Airbnb берут от 15%). Если соотношения нарушены — запись помечается флагом для ручной проверки, не отклоняется автоматически.

Третий уровень — сверка с PMS. Раз в неделю скрипт берёт выручку из PMS-системы (eZee) и сравнивает с тем что записано в учёте как выручка. Расхождение больше 5% — алерт. Это ловит случаи когда бронирование отменено в PMS, но учёт уже обновился, или наоборот.

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

Три правила по итогам двух дней

Если сформулировать в виде правил для работы с автоматизацией, эти два дня дали три конкретных:

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

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

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

Масштаб без проверок — это скорость накопления незамеченных ошибок. Скорость с регулярными проверками — это настоящий масштаб.

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

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