Внутренняя CRM для операционной команды: один экран вместо пяти вкладок

Шесть источников параллельно — и честная деградация

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

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

Уход с чужой машины: локальные зеркала вместо похода по ssh

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

Теперь база канала покупки зеркалится локально раз в 10 минут. Снимок берётся штатным механизмом резервной копии на стороне источника: копия файла под записью даёт рваный снимок, который открывается и врёт. Принимается только читаемая база осмысленного объёма, замена атомарная. Заказы обоих магазинов идут напрямую по токенам, положенным на сервер CRM по тем же путям, — поэтому один и тот же текст скрипта исполняется и локально, и по ssh, и восемь функций карточки переписывать не пришлось. Готовностью прямого пути считается наличие токенов обоих магазинов: половина токенов дала бы правдоподобно урезанную картину. При протухшем зеркале работает прежний медленный путь, и переход пишется в журнал.

Первый боевой прогон: 1,8 МБ зеркала и 777 покупок, полнота канала 42 из 42 за трое суток, расчёт по локальным зеркалам сверен с прежним путём побайтно. По 5 тестов на каждую часть, включая предохранитель от подстановки в запрос; все падают до правки.

Безопасность внутреннего инструмента

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

Отдельно починена привязка сессий: смену пароля переживали 34 живые сессии из 38, из них 26 административных. Отпечаток был 16 символов, из которых на соль приходилось два — 256 значений на 4000 хешей; стал 48. Обе правки проверены мутацией, по два красных теста на каждую.

Индексы вместо стрима всего корпуса

Почта двух ящиков — 94 800 разобранных писем, корпус в сотни мегабайт. Первая версия на каждый просмотр карточки читала его целиком: отсюда 5,8 секунды на поиск писем по клиенту.

Построил два индекса:

• Адрес → смещения строк — открыть корпус, прыгнуть по offset, прочитать только нужные письма
• Номер заказа → клиент — индекс номеров, вытащенных из тел писем: покупатель пишет с личного адреса, а заказ оформлен на рабочий — карточка всё равно находится

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

Разбор почты изначально держал весь массив писем в памяти — на прежней машине с 961 МБ это заканчивалось тем, что система убивала процесс из-за нехватки памяти. Переписал на потоковый разбор: письма пишутся на диск по одному, в памяти остаётся только лёгкая проекция заголовков. Пик памяти упал с 985 МБ до 256 МБ (на самом сервере — 215 МБ), при этом результат побайтово идентичен: то же количество писем и переписок, контрольная сумма содержимого (sha256) совпала.

Корпус для базы знаний забирается с сервера готовым

Рабочая машина выкачивала 34 ГБ сырой почты ради 459 МБ разобранного корпуса. На сервере разобранный корпус уже лежит: весит 450 МБ и полнее локального — 94 800 разобранных писем. Выключатель выкачки заведён по ящику, поэтому переводить оба сразу не требуется.

Главное здесь — предохранитель против потери истории: файл заменяется, только если он не короче локального. Он сработал на первом же боевом прогоне — замену по второму ящику отклонил (8 022 против 7 985) и сохранил 34 письма, которых на сервере не хватало. Это тот же тезис, на котором держится весь кейс: неполный источник обязан объявлять себя неполным.

Заодно пересмотрена метрика «упущенные лиды» — по замечанию оператора поддержки. 82% выборки оказались машинными уведомлениями магазина и склада, а среди человеческих писем почти половина безответных — благодарности. И снята сборка индекса на 103 МБ, которая шла каждые 15 минут без единого потребителя.

Всё, что нужно, чтобы не выходить из окна

• Отправка и пересылка писем с вложениями через очередь — интерфейс не блокируется на SMTP
• Персональные шаблоны и подписи у каждого сотрудника
• AI-черновик ответа — по контексту треда и данным карточки; редактируется перед отправкой
• Персональные аккаунты с памятью устройства — не логиниться заново каждое утро
• Аудит-лог «кто / что / чем кончилось» — по любому действию видно, кто его сделал и чем оно завершилось
• Блок складских остатков из Lark — прямо в карточке, без отдельной таблицы
• Полноценная мобильная вёрстка — проверено на 390px, отвечать можно с телефона
• Экран «Гипотезы» — план против факта с историей снимков; каждый снимок ложится в журнал, а линия тренда появляется со второй точки
• Экран «Инфра и подписки» — что оплачено, до какого числа и во сколько обходится месяц
• Экран «Что говорят покупатели» — ответы послепродажного опроса; отдельный тест краснеет, если в разметку попадёт текст ответа покупателя или адрес почты

Шесть аналитических экранов на движке вечерней сводки

Внутри CRM выросла своя аналитика: экраны «День», «Период», «Товары», «Ссылки», «Пробелы» и «Гипотезы». Произвольное окно дат, готовые календарные периоды, сравнение с прошлым окном, выгрузка в CSV с BOM и точкой с запятой — чтобы Excel открывал файл сразу. Доступ только у роли администратора.

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

Замеры: первый заход занимал 6,9 с и стал мгновенным — прогрев платится один раз, при рестарте сервиса. Вкладка «Товары»: холодная сборка 7,5 с, из кэша 0,00 с. Сумма по товарам сходится с общей выручкой до цента, доли в каждом фильтре дают ровно 100%.

• Единый счёт товарных метрик — сборщик топа считал сам и завышал выручку на 8,54%; после перевода на общее ядро сверка на живом окне в 30 дней дала расхождение 0,00 при 324 заказах. Ключ строки — идентификатор товара: артикул заполнен у 12% строк против 97% у идентификатора
• Реестр гипотез «план против факта» — 7 гипотез с историей снимков. Три правила закреплены в коде: вердикт выносится по истечении срока при цикле покупки 2–3 месяца; вывод делается при достаточном числе наблюдений; привязка к источнику засчитывается как привязка, дополнительная выручка требует отдельного доказательства. Предохранитель требует назвать в примечании того, кто утвердил цель
• Общий след интеграций — страница знала состояние 5 сервисов из 14. Подключены все 9 недостающих, введено 5 состояний, и отказ оставляет последний успех на экране
• Сравнение окон — на частичном перекрытии оно врало: окно против предыдущего, где данных всего 8 дней, показывало рост 320% по выручке на ровном месте, а период «90 дней» делил выручку 69 дней на 90 и занижал средний день на 23%

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

Переезд на выделенный сервер — за один день

Сначала CRM жила на общем сервере вместе с трекером — соседство, при котором любой всплеск нагрузки бьёт по обоим. Вынес на отдельный сервер за nginx с сертификатами Let’s Encrypt: почта проверяется каждые 15 минут, монитор раз в час, копии по ночам. Переезд проверен по счётчикам: письма, переписки и заказы на экране сошлись один в один со старой установкой.

Эксплуатация: сторожа переехали на сервер

Два сторожа — зависших заказов и спорных списаний — переведены с ноутбука под systemd-таймеры на сервере. На ноутбуке сторож заказов был мёртв: у процессов под launchd нет доступа к ключу, процесс выходил с ошибкой и писал «источник не отдал заказов — молчу», и это молчание читалось как «зависших заказов нет».

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

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