APDEX в 1С: как измерить реальную скорость работы бухгалтера, а не ощущения

Спор «стало медленнее» против «вам кажется» неразрешим, пока нет чисел. В типовых конфигурациях 1С есть встроенный механизм замеров, который эти числа даёт — и почти нигде не включён. Разберём, как его завести за полчаса, какие операции измерять, как выбрать целевое время и что показывать руководителю, чтобы разговор про модернизацию сервера шёл на цифрах.

APDEX — индустриальный стандарт оценки отзывчивости приложений. Идея в том, чтобы свести распределение времён выполнения к одному числу от 0 до 1.

Механика простая. Для операции задаётся целевое время T. Дальше все замеры делятся на три корзины:

• выполнено быстрее T — пользователь доволен;
• от T до 4T — терпимо;
• дольше 4T — раздражает.

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

Шкала оценок принята такая:

Главное достоинство метрики — она понятна нетехническому человеку. «Индекс упал с 0,91 до 0,63 за квартал» директор понимает без объяснений, в отличие от «средняя длина очереди к диску выросла до 12».

Механизм встроен в БСП и есть во всех типовых конфигурациях на управляемых формах. Отдельно ничего ставить не нужно.

Включается в разделе администрирования, в блоке оценки производительности. Ставится галка, задаётся периодичность записи замеров — по умолчанию раз в минуту.

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

Смотреть результаты — там же, отчётом по оценке производительности. Он строится по периодам и по операциям, с разбивкой по пользователям.

Накладные расходы минимальны. Замер — это запись строки в регистр сведений при завершении операции. На нагрузке офиса до сотни пользователей влияния на производительность мы ни разу не наблюдали. Не бойтесь включать на боевой базе.

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

Это самый содержательный шаг, и он не технический. Целевое время задаёт не администратор, а совместно с теми, кто работает.

Дефолтные значения в типовых конфигурациях условны. Их надо пересматривать под конкретную компанию.

Ориентиры, из которых мы исходим:

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

Ставить заведомо достижимые значения бессмысленно. Индекс будет 1,00 всегда, и метрика превратится в украшение. Ставить недостижимые — тоже: индекс залипнет внизу и перестанет реагировать на улучшения.

Мы делаем так: включаем замеры на две недели с дефолтными порогами, смотрим фактические медианы, и целевое время задаём чуть ниже текущей медианы. Тогда метрика сразу показывает реальную картину и есть куда расти.

Соблазн включить всё и смотреть общий индекс велик. Он вреден.

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

Работающий подход — выбрать 5–8 операций, которые действительно определяют рабочий день, и следить за ними отдельно.

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

Наш типовой набор для бухгалтерии:

• открытие списка документов поступления;
• проведение поступления товаров;
• проведение реализации;
• открытие карточки контрагента;
• формирование ОСВ за месяц;
• формирование карточки счёта;
• проведение банковской выписки;
• открытие журнала операций.

Для торговли добавляются подбор номенклатуры и проведение перемещения, для зарплаты — расчёт по сотруднику и формирование ведомости.

Несколько ловушек, в которые попадают при первом использовании.

Ловушка среднего. Среднее время операции почти бесполезно. Одно зависание на четыре минуты испортит среднее за день, при том что 99 % замеров были быстрыми. Смотрите медиану и 90-й перцентиль — они честнее.

Ловушка одной точки. Индекс за один день ничего не значит. Ценность появляется в динамике: график за месяц показывает тренд и реакцию на изменения.

Ловушка пользователя. Разбивка по пользователям иногда показывает, что «система тормозит» ровно у двух человек. Тогда это не система, а их рабочие места, права или Wi-Fi. Мы находили так и вполне бытовые причины — например, сотрудницу, которая держала открытыми одновременно четырнадцать форм списков.

Ловушка периода. Сравнивать надо сопоставимые периоды. Последняя неделя квартала в бухгалтерии всегда медленнее обычной — нагрузка кратно выше. Сравнение «эта неделя против прошлой» в такой момент даст ложный сигнал.

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

Главная практическая ценность замеров — не техническая, а переговорная.

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

С замерами разговор меняется. Вы приносите график: индекс по проведению реализации упал с 0,94 в январе до 0,61 в августе. Показываете, что это значит: операция, которая занимала 2,4 секунды, теперь занимает 11.

Дальше — арифметика, которую руководитель делает сам. В компании восемь человек проводят в среднем по 60 документов в день. Разница 8,6 секунды на документ — это 8,6 × 60 × 8 = 4128 секунд, около 69 минут в день. Больше человеко-часа ежедневно, примерно 23 часа в месяц.

Дальше остаётся сравнить стоимость этих часов со стоимостью решения. Обычно решение оказывается дешевле, и вопрос закрывается за одну встречу.

Мы такой расчёт делаем в каждом отчёте по производительности. Он занимает три строки и переводит разговор из плоскости «айтишники опять что-то хотят» в плоскость обычного управленческого решения с понятной окупаемостью.

Метрика работает и в обратную сторону — иногда она экономит деньги.

Клиент — юридическая фирма, 22 рабочих места, бухгалтерия на 1С. Управляющий партнёр был убеждён, что нужен новый сервер: «люди жалуются, программа медленная, серверу пять лет».

Мы включили замеры и подождали две недели, прежде чем что-либо предлагать.

Картина получилась неожиданная. Общий индекс держался на 0,89 — «хорошо». Из восьми ключевых операций семь были в зелёной зоне. Проваливалась ровно одна: формирование отчёта по расчётам с контрагентами, индекс 0,22, медиана 74 секунды.

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

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

Правка запроса заняла у программиста полтора часа. Медиана отчёта упала с 74 секунд до 4. Общий индекс вырос до 0,96.

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

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

1. День 1. Включаем замеры в базе, оставляем дефолтные целевые времена. Настраиваем удаление старых данных.
2. Дни 2–10. Ничего не трогаем, копим статистику. Важно захватить и обычные дни, и пиковые.
3. День 11. Смотрим фактические медианы, выбираем 5–8 ключевых операций, задаём под них реалистичные целевые времена.
4. День 12. Опрашиваем пользователей: какие операции они делают чаще всего. Сверяем со списком — обычно два-три пункта надо поменять.
5. Дальше. Еженедельно снимаем отчёт, складываем в общую таблицу, раз в месяц отправляем сводку руководителю.

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

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

Одна оговорка напоследок.

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

Это не недостаток. Это разделение труда: APDEX отвечает на вопрос «есть ли проблема и насколько она велика», диагностика — на вопрос «в чём именно она состоит». Пытаться заменить одно другим — обычная ошибка, из-за которой замеры либо не включают вовсе, либо включают и разочаровываются.

Включайте. Ждите две недели. Потом разговаривайте.

Замедлит ли включение замеров работу базы?

Практически нет. Замер — это запись строки в регистр сведений по завершении операции. На нагрузке офиса до сотни пользователей влияния не заметно. Следить стоит только за ростом таблицы замеров: настройте удаление данных старше шести-двенадцати месяцев.

Какое целевое время ставить для проведения документа?

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

Почему нельзя смотреть просто среднее время операции?

Одно зависание на несколько минут искажает среднее за весь день, хотя 99 % замеров были быстрыми. Медиана и 90-й перцентиль отражают реальный пользовательский опыт гораздо честнее.

Сколько операций держать под контролем?

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