Сверка по количествам зелёная, а перенесённое не работает

В ленте портала 154 поста. После переезда в коробку их тоже 154, счёт сошёлся. Только в 32 постах вместо картинок висит текстом метка DISK FILE ID с числом.

Случай с нашего проекта: портал Битрикс24 переезжал из облака в коробку. Меня зацепила не сама ошибка. Зацепило, что честный счёт рядом с ней ничего не заметил.

Всё ниже - наблюдения одного портала, а не правило для любого Битрикса.

Если вы переносите портал через API, начните с меток вложений внутри текстов. У каждой выясните, в каком счёте живёт её число: у нас одна буква отличала объект Диска от привязки к посту. Шаблоны роботов с номерами пользователей я бы проверил отдельно - там подвела замена по началу строки.

Что переносили и чем считали

Инструмент переноса у нас свой: облако читает через REST, в коробку пишет тоже через REST, а сообщения и часть служебных полей - прямой записью в базу.

Вопросов к данным у инструмента было три:

• у всех ли 22 783 залитых файлов сошёлся размер;

• совпадают ли поля записей: сверка срезами по сущности, проекту и человеку печатает расхождения;

• одинаково ли число записей в коробке, в карте соответствий и в облаке, а если нет, то где расхождения.

Все три - о полноте. Работает ли приехавшее, не спрашивает ни один.

Одна буква в метке вложения

У метки вложения в облаке две законные формы, и обе встречаются на одном портале. С буквой n число указывает на объект Диска. Без буквы - на привязку вложения к посту.

Метки стояли только в постах ленты: 39 штук в 32 постах. Метки одного поста коробки по этапам, номера настоящие:

облако: [DISK FILE ID=n<номер объекта Диска облака>]
после переноса: тег остался облачным — числа в коробке нет, виден текстом
после первой починки: [DISK FILE ID=n539] [DISK FILE ID=n540] [DISK FILE ID=n541]
поле вложений поста: a:3:{i:0;i:539;…} ← 539–541 — номера привязок
после второй починки: [DISK FILE ID=n18974] … ← n + объект Диска коробки

Первая починка взяла 539 из поля вложений поста: число коробочное, но из счёта привязок. Букву n починка не тронула, и [DISK FILE ID=n539] ядро прочитало как объект Диска 539.

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

Форма [DISK FILE ID=539] без n заработала бы. Мы выбрали другое правило: облачная форма остаётся, число подставляется из того же счёта.

Проверка “есть ли такой объект в коробке”, по-моему, могла и не спасти: объект Диска 539 в коробке мог существовать.

Я бы сверял другое: ведёт ли метка в коробке к тому же файлу, к которому вела в облаке.

Робот молчит, хотя стадии на месте

Люди начали работать в коробке 17.09, и симптом всплыл в тот же день. Робот “Сменить стадию” в смарт-процессе не срабатывал и молчал.

Цели в своей воронке робот не видел, а руками заявка по стадиям переходила.

Причину нашли назавтра, 18.09. Пустой оказалась принадлежность к воронке - у стадий, которые завёл перенос. Исправили все 12.

Сверка смарт-процессов в ночном прогоне 16.09 провела 161 заявку через одно сравнение: облачная стадия против коробочной. Два расхождения нашлись, но с другой причиной.

Заявки стояли где надо. А пустое поле у самой стадии в такое сравнение не попадает.

У себя я бы сделал так - это рассуждение, а не опыт проекта. Создать одну стадию руками в приёмнике и сравнить её со стадией из переноса по всем полям подряд. Поле, пустое только у второй, - первый кандидат в молчаливый дефект.

Ещё я бы прогнал на тестовой заявке каждого робота, который двигает стадии: ручной перевод у нас работал, а робот - нет.

Правило “36 → 21” и пользователь, которого не было

Адресатов в шаблонах автоматизации переводили с облачных ключей на коробочные одним проходом. Одно из правил было “облачный 36 → коробочный 21”. Раскладка ниже моя, значения в ней настоящие:

правило замены:        облачный 36 → коробочный 21
в шаблоне робота:      user_365
после замены:          user_215
исправленное правило:  номер заменяется, только если сразу за ним не идёт ещё одна цифра

Пользователя 365 не существовало и в облаке. Битая ссылка переехала вместе с шаблоном, и строки для неё в таблице замен не было. Зато нашлось правило для 36: ключ user_36 совпал с началом строки, хвост “5” остался.

Записи 215 коробка не знала никогда и ссылку на неё приняла молча. Робот, дойди до него очередь, остался бы без адресата.

На другой паре вышло бы хуже. Пример разработчика: при правиле “12 → 77” user_1234 стал бы user_7734, а там оказался бы живой человек.

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

Поймал бы такое аудит ссылок? Его тогда не было: в репозитории он впервые зафиксирован 22.09, после стадий. И шаблонов автоматизации, смарт-процессов и стадий в нём нет. Покрывает он задачи, проекты, участников, комментарии задач и календарь - 12 проверок на всё.

Аудиту достаточно, что запись есть, пусть даже пользователь удалён или заблокирован. Отсюда моё рассуждение: подмену вроде “12 → 77” в участниках задачи он не заметит, ведь ссылка вела бы на существующего человека, просто не на того.

Чат показывает только последние 25 сообщений

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

Переписка при этом цела: в чате, где заметили баннер, 112 сообщений в облаке и столько же в коробке.

Окно в 25 сообщений нашлось у 3 125 чатов. Один из них - “Заметки”, 49 принадлежат проектам, остальные 3 075 - задачам.

По объяснению нашего разработчика, окно чата строится на методе, который всегда подкладывает в него первое по номеру сообщение. В чате задачи первым стоял баннер, и окно считало, что история на нём кончилась. Баннер ядро ставит в момент, когда чат задачи появляется, а история из облака ложится позже и получает номера выше.

Служебную строку убрали за пять проходов и то же сделали в самом переносе.

Сверка молчала, потому что все проверки чатов до 09.09 сравнивали состав с облаком. А состав сходился полностью.

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

Шаг с такой проверкой появился у нас 09.09, из этого дефекта, и в выводе у него строка “порядок сообщений”.

Проверка порядка не увидит потерю, которая порядок не ломает, - это моё рассуждение. Пропавшее сообщение номера и даты остальных не перепутает.

Панель “Файлы” как эталон

Уборку дублей файлов в чатах запустили 10.09. Эталоном она взяла панель “Файлы” чата в облаке и сняла 298 объектов в 78 чатах.

Панель для этого не годилась. Файл, приложенный к двум сообщениям, она показывает одной строкой, а в коробке это два объекта. Часть файлов не показывает вовсе. Больше 200 строк в ней не бывает.

Ошибку увидела сверка по истории сообщений: она сопоставляет пары “сообщение + файл” в облаке и в коробке. Так нашлись 8 законных файлов, снесённых в 5 чатах из 78.

Файлы догрузили из облака к своим сообщениям, а уборку переписали на ту же сверку. По оценке нашего разработчика, сухой прогон этой сверки поймал бы их ещё до уборки.

Граница у сверки по истории тоже есть - это я вывожу из её устройства. Пара говорит, при каком сообщении какой файл лежит. Цел ли сам файл, из пары не видно.

Панель годится как сигнал, что чего-то не хватает. Доказать ею, что файл лишний, нельзя.

Как выглядит зелёный вывод

Строки обезличенного вывода нашего инструмента за ночь 16.09, пропуски - многоточием:

приёмка: проекты — проверено 49, полей 713 — расхождений нет
приёмка: порядок сообщений — чатов 5488, строк впереди истории 0
...
целостность залитых файлов — 22 783: размер сошёлся у всех, потеряно 0
...

Про принадлежность стадий к воронке не спрашивает ни одна из этих строк.

По-моему, под каждой строкой вывода стоит подписать, чего она не сравнивает. Например, строка “целостность залитых файлов” сравнивает размер, а не содержимое.

Довод против этой статьи

Статья про проверки, а из дефектов с постами, воронкой, чатами и файлами проверка заметила один: снесённые файлы нашла сверка пар “сообщение + файл”. Нерабочие посты и окно в 25 сообщений увидели глазами. Сломанные стадии выдал робот, когда в коробке уже работали люди.

Проверка порядка сообщений и аудит ссылок появились после дефектов.

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

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

0%Ничего, количества достаточно0

0%Открываю выборку записей глазами0

0%Сверяю значения полей, а не только число записей0

0%Проверяю, что ссылки между записями ведут на существующие объекты0