В таблице сопоставления было 1 449 ключей. Битыми оказались 1 370 из них, 94,55 процента.
Причина - один символ, которого никто не добавлял. Он появился сам, при штатном преобразовании числа в строку, и отличается от обычного пробела только кодом. Визуально это пробел. Для сравнения строк - посторонний символ.
Самое неприятное в этой истории даже не масштаб. Дефект годами не проявлялся, хотя работал с первого дня. И последнее, о чём лучше подумать заранее: починка одной стороны сопоставления ломает то, что до этого работало. Про это в конце.
Сразу оговорюсь: это вторая часть
Про тот же символ я уже писал - "Как неразрывный пробел мешает миграции MS SQL → PostgreSQL на Windows Server". Читать её необязательно, здесь всё самодостаточно, но если попадалась, полезно понимать, чем эта история отличается.
Там неразрывный пробел приехал в базу снаружи: копипастом из внешних таблиц и с сайтов поставщиков. И ломал он построение уникального индекса при переносе на PostgreSQL. Библиотека сравнения строк ICU (International Components for Unicode), через которую PostgreSQL сравнивает значения, считает неразрывный пробел равным обычному: два разных значения схлопываются в одно, и уникальный индекс отказывается строиться. Там символ делал разные строки одинаковыми.
Здесь всё зеркально. Символ вставляет сама платформа, руками его никто не заносил, и эффект обратный: два визуально одинаковых значения перестают быть равными. Первая история была про лишнее равенство, эта - про пропавшее.
Тема тоже сместилась. Первая часть отвечала на вопрос "что это за символ и как его поймать". Эта - на два других: почему испорченные данные годами вели себя как здоровые и сколько стоит их вылечить. Символ здесь скорее повод; интересно то, что вокруг него выросло.
Что произошло с ключами
Ключ сопоставления собирался из числового кода. Ожидалось значение вида шести цифр подряд. Фактически в базе лежала строка из семи символов: шесть цифр и один разделитель между третьей и четвёртой.
Сравнение с таким ключом не находит ничего. Совсем ничего, даже похожего: строки разной длины и разного состава не равны, и никакая нормализация регистра тут не поможет.
Последствие у этого ровно одно и совершенно тихое. Механизм отрабатывает от начала до конца и ошибок не выдаёт. Сопоставленных записей при этом ноль. Ни исключения, ни предупреждения - пустой результат по нормально отработавшей процедуре.
И вот почему это худший из возможных сценариев. Упавшая обработка сама сообщает, что с ней что-то не так, и её чинят в тот же день. Обработка, которая молча возвращает пустоту, живёт до тех пор, пока кто-то не сверит результат руками. А сверять результат руками никто не будет: механизм ведь работает.
1 370 ключей из 1 449 были в таком состоянии. Уцелело 79, это 5,45 процента, и почему уцелели именно они - разберём отдельно, потому что это и есть доказательство механизма.
Откуда берётся лишний символ и как его убрать
Число превращается в строку не само по себе. Речь про самое обычное Строка(Значение) - то, что пишут не задумываясь. Эта функция форматирует число так, как принято показывать человеку: с разделителем групп разрядов.
То есть она делает ровно то, что должна. Она про представление числа человеку; цифры из неё доставать никто не обещал. Шестизначное число она честно превращает в семизначную строку.
Ошибка не в функции. Ошибка в том, что её результат пошёл в идентификатор, хотя рассчитан был на надпись на экране.
Практическое правило, и оно шире этого случая. Любое значение, которое пойдёт в ключ, в сопоставление, в имя файла или во внешнюю систему, должно формироваться преобразованием без форматирования. Если вы вызвали функцию, которая умеет форматировать, вы обязаны явно сказать ей этого не делать.
Почему разделитель именно этот
Разделителем групп разрядов работает неразрывный пробел, код 160. Обычный пробел - код 32.
Отсюда все дальнейшие неприятности с поиском.
Вы открываете значение в отладчике - видите пробел. Копируете в текстовый редактор - видите пробел. Пишете условие поиска с обычным пробелом - не находите ничего. Пишете отбор "содержит пробел" - получаете пустой результат при том, что пробел прямо перед глазами.
Все привычные способы искать лишний пробел ищут другой символ. Именно поэтому дефект такого рода можно разглядывать глазами сколько угодно и не увидеть.
Надёжный способ один: смотреть коды символов, а не символы. Развернуть строку посимвольно и посмотреть на числа. Ноль двусмысленности, ноль зависимости от шрифта и редактора.
Длина растёт нелинейно, и на этом ломается самая очевидная проверка
Тут есть тонкость, которая портит первую же самодельную проверку.
Разделитель ставится между группами по три цифры. У шестизначного числа группы две, разделитель один, строка вырастает с 6 символов до 7. У семизначного групп уже три, разделителей два, и длина становится 9. То есть прирост длины зависит от разрядности исходного числа.
Отсюда простое следствие. Любая проверка вида "длина ключа отличается от ожидаемой ровно на один символ" ловит один диапазон значений и пропускает соседний. На той же таблице она честно найдёт шестизначные и тихо пройдёт мимо семизначных - и вы получите отчёт "всё исправлено", в котором исправлено не всё.
Правильный порог для проверки по длине один: "длина отличается от ожидаемой", без указания, на сколько именно. А ещё лучше вообще не опираться на длину, об этом ниже.
Как это чинится
Лечится одной строкой: при преобразовании явно указать нулевое число групп разрядов. Вместо Строка(Значение) - Формат(Значение, "ЧГ=0"). Функция форматирования это умеет с самого начала, просто по умолчанию ведёт себя иначе, и умолчание тут работает против вас.
Для буквенно-цифровых значений исправление безопасно: то, что не число, возвращается как есть. Это важно, потому что в одном и том же поле часто лежит вперемешку и числовой код, и артикул с буквами, и разбирать их по типам перед сборкой ключа никто не будет.
Правка тривиальная, и именно поэтому её легко сделать не везде. Место, где формируется ключ, обычно не одно: тот же приём пишут в загрузке, в выгрузке, в отчёте сверки и в обработке ручного заполнения. Исправив один участок, вы получите систему, где половина значений чистая, половина с посторонним символом. Один класс несовпадений сменится другим, менее заметным. Поэтому первым делом стоит найти все места, а править уже потом, одним заходом.
Ищутся такие места по коду, признак у них общий: преобразование числа в строку внутри построения ключа. Одно правило поиска, результат сразу.
Чем чинить нельзя
Два способа, которые напрашиваются и оба вредны.
Нельзя убирать из значений все пробелы. В артикулах поставщиков пробелы бывают значимой частью, и массовая зачистка создаст новый пласт несовпадений вместо старого. Причём этот пласт будет тише: он не даст обвала на девяносто с лишним процентов, он даст редкие точечные несовпадения, которые никто не заметит. Убирать надо один конкретный код символа.
Хуже другое. Порча ключа функцией форматирования обратима: значение можно пересобрать заново из того же числа. Стёртый пробел внутри артикула поставщика восстановить неоткуда, если исходник уже не подтянуть. Обратимую ошибку меняют на необратимую.
Нельзя проверять результат сравнением длины. Разбор выше: у семизначного числа разделителей два, и проверка, рассчитанная на одну единицу, пропустит часть случаев.
Единственная надёжная проверка - посимвольная, по кодам. Пройтись по строке КодСимвола() и убедиться, что все коды лежат в диапазоне цифр. Дорого по сравнению с поиском пробела и абсолютно однозначно.
Тут же вылезает вторая ловушка, симметричная первой. Проверка "есть ли в значении пробел" даёт ложные срабатывания в обе стороны сразу: обычный пробел не находится там, где сидит символ 160, и находится там, где он законный - внутри буквенно-цифрового артикула. Такая проверка врёт и про битые значения, и про целые.
Почему дефект жил годами
Вот главный вопрос всей истории. Механизм работал с первого дня, а сломалось всё в какой-то момент.
Ответ: обе стороны сопоставления портились одинаково.
Ключ формировался тем же кодом и там, и там. Слева получалась строка с неразрывным пробелом, справа - точно такая же строка с неразрывным пробелом. Они совпадали. Сопоставление работало.
Дефект был, а последствий не было, потому что ошибка была симметричной. Причём система в этот момент вела себя абсолютно правильно: испорченный ключ равен испорченному ключу, равенство сохраняется. Ошибки нет ни на одном уровне - платформа сравнила строки честно, сравнение честно вернуло истину. Ловить тут было нечего, и никакой мониторинг не помог бы.
Симметрия ломается в момент, когда одна из сторон начинает формироваться иначе: подключается новый источник, кто-то загружает данные выгрузкой, кто-то заполняет вручную, кто-то переписывает один из двух участков кода. С этого момента слева семь символов, справа шесть, и совпадений больше нет.
Это отдельный класс дефектов, и он самый неприятный из всех. Ошибка, которая присутствует в обеих половинах системы, невидима, пока половины меняют вместе. Она не деградирует постепенно и не даёт предупреждений - она выстреливает целиком в день, когда половины разошлись.
И этот день назначаете не вы. Его назначает подключение нового поставщика, переписанный кем-то модуль или обычный ручной ввод. Для того, кто в этот день дежурит, всё выглядит как "сломалось от новой интеграции", хотя интеграция ни при чём: она первой сделала ключ правильно.
Проверить систему на такое можно единственным способом: брать значение по отдельности и мерить его об ожидаемый формат. Сравнение половин между собой тут бесполезно по построению. Сверка "наши ключи против их ключей" проходит успешно и ничего не показывает - обе стороны испорчены одинаково.
Проверка объяснения: почему уцелели 79
Механизм даёт предсказание, и оно проверяемо.
Разделитель групп разрядов появляется только тогда, когда группы есть, то есть начиная с четырёхзначных чисел. У числа меньше тысячи разделять нечего, строка получается чистой.
Значит, уцелевшие 79 ключей обязаны быть либо короткими числами, либо буквенно-цифровыми значениями, которые преобразование не трогает.
Скажу честно: эту проверку я привожу как предсказание, а не как выполненный замер. Запрос, который разложил бы уцелевшие по длине, стоит одного захода, и в разборе его не сделали. Если среди 79 найдётся четырёхзначное числовое значение - механизм описан неполно, и об этом надо будет знать.
Пишу это здесь потому, что предсказание, которое можно проверить и не проверили, честнее выдавать ровно за то, что оно есть.
Риск, который создаёт само исправление
Теперь про то, что надо просчитать до выкатки правки.
Из механизма симметричной порчи следует неприятное. Там, где обе стороны формировались одинаково испорченно, сопоставление сейчас работает. Вы чините одну сторону - и эти совпадения ломаются.
То есть правка, объективно верная, может уронить часть работающих связей. Причём именно тех, что никого не беспокоили.
Из этого следует порядок действий, и он важнее самой правки:
Сначала посчитайте обе стороны. Сколько значений с посторонним символом слева, сколько справа. Если испорчены обе - правьте обе одновременно, одним заходом.
Потом посчитайте пересечение. Сколько связей держится сейчас на совпадении двух испорченных значений. Это ровно то, что сломается, и об этом размере лучше знать заранее, чем узнавать от пользователей.
И только потом правьте, вместе с разовым приведением уже накопленных данных.
Разбор, на котором основана статья, до этой части не дошёл: что стало после исправления, сколько ключей поднялось и не сломалось ли что-то - не зафиксировано. Риск здесь выведен из механизма. Замера под ним нет, так его и читайте.
Как проверить это у себя за один заход
Порядок, который я бы взял, если бы лез в чужую базу с нуля.
Шаг первый, данные. Возьмите таблицу, где лежат ключи, и постройте распределение длин значений. Не ищите символ, просто посмотрите, какие длины есть и сколько значений в каждой. Ожидаемая длина будет видна сразу, а рядом с ней окажется группа значений длиннее. Это и есть кандидаты.
Шаг второй, коды. Возьмите из подозрительной группы несколько значений и разверните их посимвольно через КодСимвола(). Символ 160 виден мгновенно, и разговор "может, это у нас шрифт такой" на этом заканчивается.
Шаг третий, код конфигурации. Глобальным поиском по Строка( найдите все места, где ключ собирается из числа. Именно все, не первое попавшееся. Пока не найдены все, править нельзя: получится наполовину чистая система, а это состояние хуже исходного, потому что часть связей рвётся, а объяснение неочевидно.
Шаг четвёртый, обе стороны. Посчитайте битые значения слева и справа и пересечение, которое сейчас держится на двойной порче. Только после этого правьте код и приводите накопленные данные - одним заходом.
Первые два шага не требуют ни отладчика, ни разбора модулей и отвечают на вопрос "есть ли у меня такое" раньше, чем на вопрос "где именно". Начинать надо с них.
Границы применимости
Механизм работает для чисел от четырёх знаков. Всё, что меньше тысячи, разделителя не получает.
Симметричная порча - условие невидимости. Если у вас ключи формируются в одном месте и сравниваются с внешним источником, дефект вылезет в первый же день. Годами он живёт только там, где обе стороны портит один и тот же код.
Не проверено, сколько ещё мест в коде формируют ключи тем же способом. Один найденный участок почти наверняка не единственный: приём "преобразовать число в строку" пишут по привычке, а привычка одна на всю команду.
Замера "после" нет. Ни числа поднявшихся ключей, ни числа сломавшихся связей.
И честно про метод поиска. Версий тут не перебирали: дефект нашёлся сразу, как только посмотрели на коды символов вместо самих символов. Отклонённых гипотез в этой истории не было, и придумывать их ради красивой структуры я не стану.
Открытый вопрос
Вопрос, на который у меня нет ответа. Симметричные дефекты этого типа - когда ошибка есть в обеих половинах и потому не видна - ловятся только проверкой значения против ожидаемого формата. Сверка двух половин друг с другом их пропускает по построению. У кого-нибудь есть работающая практика такой проверки на больших справочниках: не разовый скрипт после аварии, а что-то, что идёт постоянно и не стоит как отдельный проект?
Симметричную порчу ключей внутри базы обработка не поймает, это я сказал выше честно. А вот несимметричную, ту самую, которая валит построение уникального индекса на переносе, ищет Проверка базы перед миграцией на PostgreSQL: она проходит по реквизитам и показывает значения, которые ICU схлопнет в одно, вместе со списком индексов, встающих на этом.
Другие наши инструменты для проверки базы:
- Проверка базы перед миграцией на PostgreSQL - где пробелы и регистр схлопнут разные значения в одно и какие уникальные индексы после этого не соберутся.
- Анализ кода внешних обработок - найти остальные места, где число превращают в строку тем же способом. Один найденный участок почти наверняка не единственный.
- Чек-ап чистоты базы 1С - сколько такого мусора в справочниках накопилось и что сломается, если его убрать.
- Проверка базы перед переносом на MS SQL Server - то же самое для обратного маршрута, там свой набор ловушек со сравнением строк.
Вступайте в нашу телеграмм-группу Инфостарт