В этой статье вы узнаете, как проверить достоверность результатов DES-симуляции (дискретно-событийного моделирования) и убедиться, что система достигла стационарного режима (steady state). Вы научитесь читать вкладку «Динамика и достоверность», интерпретировать проверку закона Литтла, понимать, что такое warm-up, и разбирать время ожидания на две части: ожидание по календарю и очередь к ресурсам. Это поможет определить, когда результатам можно доверять, а когда нужно увеличить прогон.
Перед тем как анализировать метрики SLA, загрузку ресурсов или экономику, важно убедиться, что расчёт корректен. Вкладка «Динамика и достоверность» в отчёте симуляции содержит автоматические проверки, которые подтверждают или ставят под сомнение надёжность полученных цифр.
Где находится вкладка «Динамика и достоверность»
- Откройте завершённую симуляцию и перейдите на вкладку «Результаты».
- В шапке отчёта выберите вкладку «Динамика и достоверность» (она находится после вкладки «SLA»).
На этой вкладке отображаются два ключевых индикатора и несколько графиков, описанных ниже.
Проверка закона Литтла
В верхней части вкладки находится блок «Закон Литтла» с одним из двух статусов:
- «Проверено» — расчёт прошёл внутреннюю самопроверку. Значит, система корректно посчитала среднее число заявок в системе, среднее время пребывания и интенсивность потока. Результатам можно доверять.
- «Не пройдено» — обнаружено расхождение (допуск 10 %). Это сигнал, что результаты пока недостоверны. Возможные причины: слишком короткий прогон, высокая вариативность или нестабильный поток. В этом случае увеличьте количество заявок или время симуляции и перезапустите расчёт.
Закон Литтла — это фундаментальное соотношение теории очередей: среднее число заявок в системе равно произведению интенсивности потока на среднее время пребывания заявки. Если система не может его подтвердить, значит, данные прогона ещё не стабилизировались.
Стационарный режим (steady state) и warm-up
Рядом с проверкой закона Литтла находится блок «Steady State» со статусом:
- «Достигнут» — система стабилизировалась. Показаны дополнительные данные: «Система стабилизировалась через …» (время или количество заявок, после которых показатели перестали меняться) и «% в Steady State» (доля прогона, приходящаяся на стабильную фазу).
- «Не достигнут» — прогон закончился до того, как система вышла на устойчивый режим. В этом случае цифры в отчёте отражают «разгон» (warm-up), а не реальный режим работы. Увеличьте число заявок или длительность прогона и запустите симуляцию заново.
Warm-up — это начальная фаза прогона, когда система «набирает обороты»: заполняются очереди, ресурсы переходят в рабочий ритм. На таймлайне прогона (вкладка «Диаграмма») эта фаза помечена бейджем «Warm-up», а стабильная часть — бейджем «Стационарный режим». В расчёте итоговых метрик warm-up исключается, но если стационарный режим не достигнут вообще, исключать нечего — и цифры будут завышены или занижены.
Декомпозиция времени в системе
Ниже индикаторов находится блок «Декомпозиция времени в системе», который разбивает общее время пребывания заявки на составляющие:
- Время обработки — время, когда заявка активно обрабатывается ресурсом.
- Ожидание (всего) — суммарное время, когда заявка ждёт.
Ожидание, в свою очередь, делится на две части:
- Очередь к ресурсам — время, когда заявка ждёт свободного исполнителя. Лечится увеличением численности ресурсов или ускорением обработки.
- Ожидание по календарю — время, когда заявка ждёт, потому что ресурс не работает (выходной, ночь, перерыв). Лечится изменением графика работы или расширением календаря.
Эта разбивка помогает понять, что именно менять: если основная доля ожидания — «очередь к ресурсам», добавьте исполнителей или сократите время обработки. Если доминирует «ожидание по календарю», пересмотрите расписание или добавьте смену.
Графики динамики
Во вкладке отображаются несколько графиков, которые наглядно показывают, как менялись показатели во время прогона:
- «Размер системы и очередь» — количество заявок в системе и в очередях по времени.
- «Среднее время в системе (W)» — динамика среднего времени пребывания заявки.
- «Пропускная способность и утилизация» — throughput и утилизация ресурсов.
- «Утилизация ресурсов» — с линиями порогов «Перегрузка (80%)» и «Недозагрузка (30%)».
- «Средняя длина очереди» — динамика очереди.
- «Обработано заявок по батчам» — накопительная кривая обработанных заявок.
Если кривые на графиках вышли на плато — стационарный режим достигнут. Если к моменту завершения прогона кривые ещё растут или колеблются — прогон слишком короткий.
Что делать, если проверки не пройдены
- Закон Литтла «Не пройдено» — увеличьте количество заявок (например, с 100 до 500) или время прогона и перезапустите симуляцию. Если расхождение сохраняется, проверьте, не слишком ли высока вариативность длительностей задач.
- Steady State «Не достигнут» — увеличьте длительность прогона. Если вы запускаете по количеству заявок, добавьте заявок; если по времени — увеличьте период. После перезапуска убедитесь, что доля «% в Steady State» составляет хотя бы 70–80 %.
- Ожидание по календарю доминирует — измените график ресурсов (например, добавьте вторую смену) или настройте поток заявок так, чтобы он совпадал с рабочими часами.
- Очередь к ресурсам доминирует — добавьте ресурсы или сократите время обработки. Подробнее о поиске узких мест см. в статье «Как анализировать загрузку ресурсов и находить узкие места».
Частые формулировки
«достоверность результатов симуляции», «стационарный режим не достигнут», «закон Литтла не пройден», «warm-up в des-симуляции», «проверка расчёта симуляции», «почему цифры в отчёте не совпадают с реальностью», «увеличить прогон des», «ожидание по календарю или очередь к ресурсам», «как понять, что симуляция стабилизировалась».