Облако и коробка: разные правила
В облаке обновления ставятся автоматически и без вашего участия. Плюс очевиден: ничего не надо делать. Минус тоже: вы не выбираете момент, и если что-то перестало работать, узнаёте об этом от менеджеров.
В коробочной версии решение за вами: когда ставить, на какой версии задержаться, что проверить до. Платой за контроль становится ответственность — сервер, обновления, совместимость с доработками и резервные копии ваши.
Отсюда разная стратегия. В облаке работа сводится к тому, чтобы быстро обнаружить проблему и знать, куда идти. В коробке — к тому, чтобы обновление не доходило до боевого сервера непроверенным.
Что обычно ломается
Доработки на старых методах. Самая частая причина. Код, написанный под прошлое поведение платформы, перестаёт работать, когда поведение меняется. Чем больше нестандартного, тем выше риск.
Интеграции через внешние приложения. Коннектор телефонии, обмен с учётной системой, выгрузка на сайт. Ломается обычно не сам обмен, а формат данных на одной стороне.
Бизнес-процессы и автоматические действия. Шаблоны, которые собирались долго и правились разными людьми, чувствительны к изменениям в условиях перехода между стадиями.
Права доступа. После крупных изменений в модели прав роли иногда начинают видеть больше или меньше положенного. Заметно это не сразу — и в обе стороны неприятно.
Внешний вид и привычки. Формально ничего не сломалось, но кнопка переехала, и отдел продаж полдня ищет действие, которое делал на автомате.
Подготовка: что сделать до
Знать, что у вас нестандартного. Список доработок, приложений и интеграций с указанием, кто их делал и кто чинит. Без этого списка разбор поломки начинается с археологии.
Резервная копия, которую проверяли. Копия, которую никогда не разворачивали, — это предположение, а не копия. Для коробки это обязательный пункт, для облака — выгрузка критичных данных.
Тестовая среда для коробки. Обновление сначала там, затем проверка сценариев, затем бой. Для облака аналог — читать описание изменений заранее и знать, что поменяется.
Список сценариев для проверки. Пять-семь действий, которые должны работать всегда: создать сделку, провести по стадиям, принять звонок, выставить документ, получить отчёт. Этот же список пригодится при приёмке любых работ.
После обновления: порядок проверки
Проверять стоит в том же порядке, в каком работает отдел, а не в порядке пунктов меню.
Сначала вход и права: все ли видят то, что должны. Затем создание сделки и её движение по стадиям с автоматическими действиями. Затем входящий и исходящий звонок с записью и привязкой к карточке. Затем обмен с внешними системами — выгрузка и загрузка в обе стороны. И в конце отчёты, по которым принимаются решения.
На всё это уходит меньше часа, если список готов заранее. Без списка то же самое занимает неделю и обнаруживается по жалобам.
Отдельно: не стоит откладывать проверку на следующий рабочий день. Если обновление прошло ночью, самый дешёвый момент найти поломку — утро до начала активной работы.
Если всё-таки сломалось
Первое — зафиксировать, что именно не работает, на конкретном примере: какой пользователь, какое действие, что ожидали, что получилось. Формулировка «не работает CRM» не продвигает разбор ни на шаг.
Второе — отделить платформу от доработок. Если то же действие в стандартном интерфейсе проходит, а в вашем сценарии нет, проблема в доработке, и идти нужно к тому, кто её писал.
Третье — решить, откатывать или чинить. В коробке откат возможен, если есть проверенная копия, и чаще всего это правильный ход при массовой поломке. В облаке откат недоступен, поэтому остаётся обходной путь на время починки.
И отдельный пункт, который экономит больше всего: заранее знать, кто отвечает. Если ответ на вопрос «кому звонить, когда встало» ищут в момент поломки, простой растягивается на день.
Как это ведётся на сопровождении — на странице сопровождения Битрикс24.
Как часто обновляться и когда это делать
Для коробки вопрос реальный: можно задержаться на версии, можно идти следом за вендором. Обе крайности плохи.
Жить на старой версии долго означает копить разрыв: чем больше версий пропущено, тем дороже и рискованнее переход, когда он всё-таки понадобится — а понадобится он обычно срочно, из-за уязвимости или несовместимости с чем-то внешним. Обновляться в день выхода — значит ловить чужие ошибки за свой счёт.
Рабочая середина: ставить обновления с задержкой в несколько недель, когда критичные проблемы уже всплыли у других, и не пропускать подряд больше одного-двух релизов. Исключение — обновления безопасности: их ставят сразу.
По времени суток и недели: не в пятницу и не перед длинными выходными. Если что-то отвалится, чинить это будет некому, а отдел продаж выйдет в понедельник в сломанную систему. Лучшее окно — вечер вторника или среды, когда впереди несколько рабочих дней.
И отдельно про сезон: в периоды пикового спроса обновления откладываются. Экономия от свежей версии никогда не перекрывает стоимость простоя в высокий сезон.
Доработки как источник проблем
Почти все сложности с обновлениями упираются в нестандартное. Это не повод отказываться от доработок — это повод относиться к ним как к обязательству на будущее.
Несколько правил, которые снижают цену каждого следующего обновления.
Писать на публичных методах. Код, который лезет напрямую в таблицы базы или опирается на недокументированное поведение, ломается первым и чинится дольше всего.
Документировать, что и зачем сделано. Через год автор не вспомнит, а новый подрядчик будет разбираться по коду. Короткого описания на каждую доработку достаточно, чтобы при поломке не начинать с нуля.
Периодически выбрасывать лишнее. Часть доработок делалась под процесс, который давно поменялся. Они продолжают выполняться, ломаться и требовать починки. Ревизия раз в год окупается.
Проверять, не появилось ли это в платформе. Вендор регулярно добавляет штатно то, что вы когда-то дописали руками. Перейти на штатное — значит снять с себя обязательство поддерживать свой код.
Техническая задолженность в CRM ведёт себя так же, как в любой системе: пока её не трогают, она не видна, а счёт за неё приходит в самый неудобный момент.
Люди: обновление, которое формально ничего не сломало
Отдельный тип проблем после обновления — когда технически всё работает, а отдел продаж встал. Причина в том, что интерфейс изменился, а привычка осталась.
Стоимость этого недооценивают. Менеджер, который делал действие на автомате, теперь тратит на него минуту и раздражается. Умноженное на отдел и на неделю, это ощутимее многих поломок.
Что помогает. Предупредить заранее, если изменение заметное: короткое сообщение с одним скриншотом до того, как люди увидят новое сами. Обновить внутреннюю инструкцию в тот же день, а не через месяц. Назначить человека, к которому идут с вопросами в первые дни, — иначе вопросы идут к руководителю отдела и съедают его время.
И последнее: собрать жалобы за первую неделю и посмотреть, что из этого настраивается обратно. Часть изменений в интерфейсе можно отключить или вернуть, и об этом обычно никто не знает.
Короткий чек-лист
Постоянно: знать список своих доработок и интеграций с ответственными; держать проверенную резервную копию; иметь список из пяти-семи сценариев, которые должны работать всегда.
До обновления: прочитать, что меняется; для коробки — поставить на тестовой среде и прогнать сценарии; выбрать окно в начале недели; предупредить отдел, если меняется интерфейс.
Сразу после: пройти сценарии в том порядке, в каком работает отдел — вход и права, сделка по стадиям, звонок, обмен с внешними системами, отчёты. Уложиться в час.
Первая неделя: собрать жалобы, отделить поломки от непривычек, починить первое и обновить инструкции по второму.
Если на каком-то пункте выясняется, что ответственного нет, это и есть главная находка обновления — она дешевле обходится сейчас, чем в следующий раз.
Кто за это отвечает
Последний вопрос, который стоит закрыть заранее: кто у вас владеет системой. Не кто ею пользуется, а кто принимает решение обновляться, кто ведёт список доработок и к кому идут, когда встало.
В облаке это может быть руководитель отдела продаж или администратор на часть ставки. В коробке без технического ответственного или подрядчика на сопровождении обойтись не получится: сервер, копии и совместимость требуют человека, а не доброй воли.
Пока такого человека нет, любой из описанных выше пунктов будет выполняться через раз — и обнаружится это ровно в тот момент, когда обновление что-нибудь сломает.