Нажали «Сохранить» в правах CRM и потеряли 90 ролей

В день обновления платформы внутреннюю поддержку завалили заявками: у сотрудников не открываются лиды, пропали сделки, нет доступа к CRM. На странице прав CRM от длинного списка ролей осталось около пяти: те, что настраивали в смарт-процессе.

Исчезли 90 ролей, почти все, что были на этой странице, а с ними тысячи настроек доступа и сотни привязок к сотрудникам и отделам. Среди пропавших были «CRM: Администратор», «CRM: Менеджер» и «Директор». Вернули все за полтора часа, уцелевшие роли не тронули ни на строку. А причина оказалась простой, и от нее не застрахован ни один портал.

Сначала доступ, потом разбор

Пока люди не могут открыть карточку клиента, искать причину некогда. Первым делом завели временную роль «Все»: просмотр и добавление в CRM для всех сотрудников, 232 настройки. Решение грубое, теперь каждый видит все. Зато продажи и поддержка снова работают, а у админа есть время разобраться без паники.

У такой роли есть цена: про нее легко забыть. Убирать ее надо осознанно, после проверки, что штатные права вернулись и работают.

Смотреть в базу, а не на экран

Страница прав показывала почти пустой список. Если верить ей, пропало почти все. Первый же запрос к базе показал картину точнее: роли смарт-процессов и их настройки остались на месте. Значит, удаление было точечным.

Насколько велик ущерб, показала разбивка по разделам CRM. У лидов осталось 6 строк настроек из 121. У заказов, счетов старого типа и событий не осталось ни одной. А права смарт-процессов уцелели полностью: они настраиваются на других страницах, и сохранение на общей странице CRM их не касалось. Пропали ровно те роли, которые видны на этой странице.

Отсюда и почти пустой экран. Он не был причиной аварии, он был ее следствием: роли этого раздела уже удалили, остались только те, что настраивали в смарт-процессе.

Кто нажал и когда

Журнал событий Битрикс24 изменений прав CRM не пишет, там видно только входы пользователей. Ответ нашелся в журнале веб-сервера: запрос на сохранение прав с внутреннего адреса пришел за семь секунд до того, как открылась страница с пропавшими ролями. Админ нажал «Сохранить».

Позже, уже разбирая код, я нашел, что у CRM есть свой журнал прав. На каждую удаленную роль он пишет запись с номером пользователя, который ее удалил. Но хранит записи 30 дней. Когда я добрался до этого журнала, срок уже вышел.

Почему откатить базу было нельзя

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

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

Как вернули за полтора часа

Выручила ночная копия: резервное копирование на портале идет каждый день. Разворачивать ее целиком на отдельном сервере не пришлось. Файл таблицы MySQL из копии можно подключить к живому серверу во временную базу:

CREATE DATABASE restore_copy;
CREATE TABLE restore_copy.b_crm_role_perms LIKE sitemanager.b_crm_role_perms;
ALTER TABLE restore_copy.b_crm_role_perms DISCARD TABLESPACE;
-- скопировать файл .ibd из копии, выдать права mysql
ALTER TABLE restore_copy.b_crm_role_perms IMPORT TABLESPACE;

Условие одно: структура таблицы не менялась с момента копии. Модуль CRM в обновлении не участвовал, поэтому все сошлось.

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

Последней шла проверка. Уцелевшие роли сверили с копией по содержимому, а не по счетчикам: ни одной пропавшей строки и ни одной новой.

Почему это случилось

Админ начал работать с ролями еще до обновления, и вкладка с правами оставалась открытой. Платформу обновили, а браузер продолжал выполнять старый скрипт страницы из кэша. Работу с ролями продолжили в той же вкладке. Старый скрипт неправильно понял данные, которые сервер после обновления отдает по-новому, и при сохранении отправил 90 ролей как удаленные.

Код новой версии это подтверждает. Сервер удаляет только те роли, номера которых страница сама прислала в списке удаленных. Даже пустая страница прислала бы пустой список, и ничего бы не случилось. А на новой странице роль попадает в этот список только одним путем: кнопкой «Удалить роль» над ее столбцом и подтверждением во всплывающем окне. Удалить 90 ролей одним нажатием там нельзя. Значит, список собрал старый скрипт.

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

Что проверить у себя

• После обновления закрыть старые вкладки с настройками и обновить страницы со сбросом кэша (Ctrl+F5). Предупредить об этом всех, кто настраивает портал. Если экран настроек выглядит странно, ничего не сохранять.
• Ежедневная копия базы. Важно не только снимать ее, но и уметь достать из нее одну таблицу, а не разворачивать базу целиком. Здесь это решило дело.
• Регулярная выгрузка матрицы прав: роли, настройки, кому выданы. Своей истории изменений у прав CRM нет, а такая выгрузка в Excel показывает, что было до аварии.
• Журнал прав CRM хранит записи 30 дней. Срок задает параметр permissions_logger_ttl модуля CRM, в часах, по умолчанию 720. Если разбор аварии затянется дольше месяца, ответ на вопрос «кто удалил» пропадет вместе с журналом. Стоит увеличить срок заранее.