Почему системы «умирают» сразу после запуска, хотя на тестах всё работало идеально? Проблема часто не в количестве пользователей и не в железе, а в неправильном подходе к нагрузочному тестированию.
Знаете, это вечная история. Внедряют систему, все вроде тестируют, всё летает. А как выкатывают на боевую — коллапс. Пользователи матерятся, кассиры в слезах, очередь в магазине, а айтишник сидит и не понимает: «Дома-то всё работало!». В чем тут фокус?
Обычно мы очень любим средние значения. Ну, это же удобно. Тысяча накладных в час, значит, каждую минуту штук 16-17 проводим — красота. Равномерно, гладко, сервер не кряхтит. В отчете всё идеально. Но реальность, как тот сосед с перфоратором в 8 утра, любит резкие и громкие сюрпризы.
На деле ни один бухгалтер не сидит и не вбивает накладные как робот ровно каждые 3,7 секунды. У него всё рывками: сначала кофе попил, потом накладная на 5000 строк прилетела, потом банк-клиент потащил — и в этот момент все легли. И вот тут и кроется главный обман.
В статье, на которую наткнулся, парни умные вещи рассказывают про математику для 1С. Основная мысль: "нельзя мерять среднюю температуру по больнице, если кто-то в этой больнице в морге лежит, а кто-то в сауне парится". Нужно искать пики, а не равнины.
Представьте, что у вас склад. На тестах вы гоняете документы с одной строкой. А в жизни кладовщик раз в час оформляет отгрузку, где 100 позиций, каждая со своим весом, серией и сертификатом. Вы этот пик не учли — вы железо под среднее значение выбрали. А в реальности в 10:15 процессор вскипает, и система встает. И вы не понимаете, почему.
Ещё про ночь забывают. Кажется, что ночью все спят, нагрузка минимальная. А там, блин, обмены с сайтом ползут, фоновые задания жрут процессор на 97%, и к утру база еле дышит. Только пользователи зашли, а она уже в коме. Сценариев должно быть несколько: утро, день, вечер, ночь — и желательно учесть тот момент, когда секретарша решила распечатать годовой отчет в 14:45 прямо перед обедом.
К чему это всё? Если честно, без нормального нагрузочного тестирования с анализом ВАРИАЦИЙ (то есть разброса данных) вы просто гадаете на кофейной гуще. Просто взять лог и пройти по нему разок — это как прочитать сценарий фильма и сказать, что он скучный, не глядя на спецэффекты. Надо вытащить те самые блокировки, те самые редкие, но жирные операции, которые жрут ресурс.
Поэтому, когда в следующий раз кто-то скажет: «У нас в системе 500 пользователей, но в среднем активны 150, всё будет летать» — не верьте. Лучше спросите: «А покажите мне самый жирный час самого жирного дня и что там происходило с APDEX (это типа индекс счастья пользователя, если грубо)». А иначе вместо гладкого полета получите веселые горки с остановкой на верхней точке. И слезами.
====================================================
Подписывайтесь на Telegram-канал. Там публикуются материалы по ERP, нагрузочному тестированию, архитектуре 1С, автоматизации бизнеса и цифровой трансформации.
Если у вас тормозит 1С, с нами можно обсудить грамотное нагрузочное тестирование: erp.lab@1cbit.ru.