Часть 1. Хирургия головного мозга 1С: как бизнесу предлагали удалить «почку», когда болела поясница
Представьте ситуацию. У вас заболела поясница — ну, потянули где-то на даче или в зале. Вы идёте к терапевту, жалуетесь на боль. Врач выслушивает, кивает:
— А, я про такое слышал. Вам срочно нужно удалить почку. Вот направление к хирургу.
Вы приходите к хирургу, он смотрит на бумажку:
— Ну раз надо, давай удалим. Зачем анализы? Зачем МРТ? Режем.
После операции вам выкатывают пациента и говорят:
— Почку мы удалили. Но за компанию прихватили ещё и половину печени — так, на всякий случай. Не переживайте, она восстановится. Ну, или если что, она в холодильнике лежит, если сильно прижмёт — пришьём обратно. А за работу с вас 2,5 миллиона рублей, пожалуйста.
Звучит как абсурдный анекдот? Добро пожаловать в реальный мир корпоративного IT, где базы данных иногда лечат именно так.
Пациент
К нам на аудит попала крупная производственная компания (пищевая промышленность, круглосуточное производство, ночная смена). История классическая, вы её наверняка узнаете: предприятие несколько лет росло, обрастало кастомными доработками от разных подрядчиков, бизнес-процессы усложнялись, каждая новая «срочная» правка ложилась поверх предыдущей. В какой-то момент база 1С:ERP разрослась до 2,5 ТБ и начала тяжело вздыхать в пиковые часы — примерно как первоклассник, которому задали на дом тридцать страниц.
Что делает обычный здравый человек, когда болит? Идёт на обследование.
Что делает крупный бизнес, когда сталкивается с авторитетным брендом? Доверяет «профессионалам».
Руководство наняло команду известных «федеральных франчайзи», которые позиционировали себя как гуру масштабных свёрток — директор искренне верил, что «они лучшие в свёртках». Справедливости ради — базу подрядчик перед стартом обследовал. Только вывод обследования подозрительно совпал с тем, что он умел продавать: «База огромная, значит, она умирает. Её надо сжать». Когда у тебя в руках молоток, любая база выглядит как гвоздь. Проект стартовал в январе.
Второе мнение
Мы зашли на объект в июне, спустя полгода после начала свёртки, и первым делом сделали то, что обычно делают до операции, а не после: собрали технологический журнал, замерили нагрузку, посмотрели, кто и на чём реально держит сервер.
Картина за один типичный рабочий день: 243 оборванных сеанса, 58 таймаутов на блокировках, 110 операций длиннее минуты. И четыре источника всей этой боли — ни один из которых не был связан с объёмом данных:
- Маркировка. Одно ночное задание по кодам маркировки работало от 38 до 97 минут и съедало всё ночное окно. Не потому, что кодов много, а потому, что на каждый код открывалась своя транзакция.
- Обмен с бухгалтерией. Один цикл — около девяти часов. При любом сбое цикл начинался с нуля. Узкое место — не сеть, не диски, а логика сборки сообщения.
- Ветеринарный госконтроль. Постоянный опрос очереди — 8 365 вызовов за сутки. Система спрашивала «есть что-нибудь?» примерно каждые десять секунд. Обычно ничего не было.
- Расчёт себестоимости. Запускался в рабочее время и конкурировал с людьми за процессор.
Ни один из четырёх пунктов не лечится уменьшением базы. Если убрать половину истории, ночное задание по маркировке будет открывать столько же транзакций, обмен будет собирать сообщение той же логикой, а госконтроль будет опрашивать очередь с той же частотой. Свёртка не решала ни одну из реальных проблем — она решала проблему, которую сама же и придумала.
Первое, что я сказал руководству:
— База в 2,5 ТБ для промышленной ERP — это не мега-размер, это ещё подросток. Она не умирает. Её зажали кандалами из кривого кода и блокировок. Никакую почку резать не нужно.
Нам не поверили сразу — и это нормально. За спиной подрядчика был бренд, за нашими словами — пока только цифры из журнала.
Приёмка первая: «а где, собственно, свёртка?»
Примерно в те же дни подрядчик прислал первую версию свёрнутой базы «на тестирование». Пользователи зашли — и сразу словили системные ошибки.
Мы открыли журнал регистрации и обнаружили удивительное. В присланной базе не было признаков свёртки. Зато было много другого: пропали пользовательские варианты отчётов (при свёртке такого не бывает физически), у части объектов метаданных поменялись внутренние идентификаторы (то есть объекты были удалены и созданы заново — привет, система прав доступа), не завершилось обновление информационной базы, отвалилась интеграция с внешним сервисом проверки контрагентов.
Подрядчик выполнил не свёртку, а незавершённое обновление конфигурации. Продолжая медицинскую аналогию: вместо удаления почки пациенту пересадили чужую печень, забыли зашить и отправили домой.
Мы написали директору сдержанное письмо с четырьмя пунктами и просьбой показать протокол работ и резервную копию «до». Так началась история двух параллельных треков: подрядчик ушёл готовить следующую версию свёртки, а мы начали лечить живую базу — прямо на рабочем сервере, без остановки производства.
Мы открыли капот
Честно скажу: мы ожидали увидеть внутри просто уставшую систему, которая за годы обросла жирком. Мы увидели нечто куда более интересное — что-то среднее между музеем и полигоном для испытаний.
И, забегая вперёд, почти ничего из найденного не было делом рук подрядчика по свёртке. У него в этом музее будет всего один зал. Но зато какой.
Это первая часть. Дальше: музей архитектурных ужасов внутри базы, живые бои на производственной площадке и финал — приёмка, минус в себестоимости и фраза «на боевой всё пересчитается само».
Продолжение — в части 2: контур обмена документами, который сошёл с ума, ночное обслуживание базы, которое никогда не заканчивалось и раздуло служебную базу до 25 гигабайт, «мёртвые души» в планах обмена с КПД меньше тысячной доли процента и таблица, на которую сервер тратил 45 часов процессорного времени в сутки. Да, в сутках 24 часа. Мы тоже удивились.
Технические подробности для коллег
Чтобы статья не выглядела рассказом без доказательств — вот как собиралась картина.
Чем измеряли. Технологический журнал с фильтром по длительности (события CALL, DBMSSQL, TTIMEOUT, EXCP, TLOCK), сутки непрерывного сбора; параллельно — Query Store на стороне SQL Server и системные представления sys.dm_db_index_physical_stats, sys.dm_db_stats_properties для оценки индексов и статистик.
Что показал журнал за сутки: 243 события разрыва сеанса, 58 TTIMEOUT (ожидание блокировок свыше 20 с), 110 вызовов длительностью больше минуты. Профиль ожиданий важнее самих цифр: у проблемных операций dur в разы превышал CpuTime, то есть время уходило не на счёт, а на ожидание — либо ответа СУБД, либо чужой блокировки. Это сразу отсекает гипотезу «не хватает мощности процессора» и переводит разговор в плоскость блокировок и планов запросов.
Почему объём данных был ни при чём. Каждая из четырёх найденных причин имеет сложность, не зависящую от глубины истории:
маркировка — O(N) по количеству кодов в текущей партии, транзакция на код;
обмен — время сборки сообщения зависит от объёма изменений за период, а не от размера базы;
опрос очереди госконтроля — фиксированная частота обращений, 8 365 вызовов в сутки;
расчёт себестоимости — конкуренция за ресурсы, вопрос расписания, а не объёма.
Свёртка уменьшает историю, но не меняет ни одну из этих величин. Отсюда и вывод, с которого началась вся работа: лечить надо код и настройки, а не резать данные.
Что было не так с присланной свёрнутой базой. Диагноз ставился по журналу регистрации: удаление пользовательских вариантов отчётов (при свёртке невозможно), смена GUID у части объектов метаданных (объекты пересозданы — ломается система прав доступа и ссылочная целостность в подсистемах, которые хранят ссылки на идентификаторы), незавершённое ОбновлениеИнформационнойБазы (отсутствовали предопределённые элементы), сломанная интеграция с внешним сервисом. Совокупность признаков однозначно указывает на прерванное обновление конфигурации, а не на свёртку.
Вступайте в нашу телеграмм-группу Инфостарт