В ленте портала 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 сообщений увидели глазами. Сломанные стадии выдал робот, когда в коробке уже работали люди.
Проверка порядка сообщений и аудит ссылок появились после дефектов.
Боюсь, класс, которого мы ещё не встречали, пройдёт их так же тихо, как пустая принадлежность к воронке прошла сравнение с облаком. Как ловить заранее то, чего ещё не видел, я не знаю.