Короткий ответ

Если коробочный Битрикс24 тормозит, первым делом смотрят на сервер, тариф и размер базы. В нашей практике причина чаще оказывается в другом: портал перегружен собственными автоматизациями.

На одном из разобранных порталов мы насчитали 270 бизнес-процессов на шести воронках продаж. Большая часть не доходила до конечной точки и оставалась висеть в системе, часть конфликтовала с соседними процессами. Клиент при этом пришёл с формулировкой «коробка сильно тупит» и был готов обсуждать железо.

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

С каким запросом пришёл клиент

Обычная ситуация: коробочная редакция, живёт несколько лет, работает. Жалоба сформулирована так, как её чувствует пользователь: открывается долго, списки грузятся, иногда отваливается.

Дальше по логике владельца следует разговор про мощности. Добавить памяти, перенести на диск побыстрее, обновить версию. Иногда это помогает — на несколько недель, пока нагрузка снова не догонит.

Мы пошли считать, что портал делает сам с собой, когда его никто не трогает.

Тот разбор, кстати, был ручным — до того, как мы сделали программного аудитора. Именно такие задачи и подтолкнули к нему: ручной подсчёт процессов по шести воронкам занимает часы и делается один раз, а проблема возвращается.

Что нашли в портале

270 активных бизнес-процессов на шести воронках продаж.

Само по себе число ещё ничего не доказывает: бывают компании со сложным производством, где сотня процессов оправдана. Важно, что было дальше.

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

Часть процессов конфликтовала между собой. На одной воронке два процесса меняли одно и то же. Один переводил сделку на следующую стадию по своему условию, второй по своему возвращал обратно. Снаружи это выглядит как мистика: сделка «сама» меняет стадию, ответственный «сам» меняется, менеджеры перестают доверять системе и заводят параллельный учёт в таблице.

Откуда берутся 270 бизнес-процессов

Вот это — самая полезная часть, и она не про Битрикс24.

Права администратора были у всех, кому они когда-либо понадобились. Сотрудники, по выражению самого клиента, «сами с усами»: разбирались, настраивали, автоматизировали свою работу сами. Каждый решал реальную задачу и делал это добросовестно.

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

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

За несколько лет так набирается 270.

Чем роботы отличаются от бизнес-процессов

Их постоянно считают вместе, а нагрузку они дают разную.

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

Бизнес-процесс — это запущенный экземпляр со своим состоянием, который живёт до конечной точки. Он может ждать событие, таймер или действие человека. Пока ждёт — существует. Вот они и накапливаются.

Практический вывод: если портал тормозит, считайте в первую очередь незавершённые экземпляры процессов. Если поведение системы непредсказуемо — сделка сама меняет стадию, ответственный сам переназначается, — смотрите на роботов, конфликтующих на одной стадии.

Почему в коробке это заметнее, чем в облаке

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

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

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

Если вы ещё выбираете между редакциями, разница в поддержке — один из тех факторов, которые в сравнении лицензий не видны. Мы разбирали это в отдельной статье про облако и коробку.

Почему такие проблемы не находятся вручную

Чтобы увидеть проблему, недостаточно открыть список бизнес-процессов. Нужно по каждому понять: запускается ли он ещё, доходит ли до конца, сколько экземпляров висит незавершёнными, не пересекается ли по действиям с соседним.

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

Что делать, если портал уже тормозит

1. Проверьте гипотезу. Сравните скорость портала в час пик и вечером, когда в системе два человека. Если разницы почти нет — нагрузка фоновая.

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

3. Инвентаризация, а не чистка. Не удаляйте ничего сразу. Часть процессов встроена в реальную работу, и их отключение остановит продажи. Сначала список: что это, кто создал, что делает, работает ли ещё.

4. Выключите заведомо мёртвые. Процессы на воронках, которых больше нет; процессы, привязанные к полям, которые не заполняются; процессы, чьи авторы давно уволились, а результат никому не нужен.

5. Разберите конфликтующие пары. Ищите процессы, которые на одной воронке меняют одно и то же: стадию, ответственного, сумму. Оставляйте один, остальные переписывайте под другие условия.

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

Как не довести портал до такого состояния

Правило простое: автоматизация — это тоже система, и у неё должен быть владелец. Не запрет на автоматизацию, а один человек, который знает, что на портале запущено и зачем.

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

Если разбирать уже поздно и портал тормозит сейчас — начните с бесплатного аудита. Роботы и бизнес-процессы — одна из двенадцати зон, которые мы проверяем, и на неё смотрят отдельно от прав и брошенных сделок.

Если некому держать это в порядке — смотрите сопровождение Битрикс24.