В этой статье вы узнаете, как проверить достоверность результатов DES-симуляции (дискретно-событийного моделирования) и убедиться, что система достигла стационарного режима (steady state). Вы научитесь читать вкладку «Динамика и достоверность», интерпретировать проверку закона Литтла, понимать, что такое warm-up, и разбирать время ожидания на две части: ожидание по календарю и очередь к ресурсам. Это поможет определить, когда результатам можно доверять, а когда нужно увеличить прогон.

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

## Где находится вкладка «Динамика и достоверность»

1. Откройте завершённую симуляцию и перейдите на вкладку **«Результаты»**.
2. В шапке отчёта выберите вкладку **«Динамика и достоверность»** (она находится после вкладки «SLA»).

На этой вкладке отображаются два ключевых индикатора и несколько графиков, описанных ниже.

## Проверка закона Литтла

В верхней части вкладки находится блок **«Закон Литтла»** с одним из двух статусов:

* **«Проверено»** — расчёт прошёл внутреннюю самопроверку. Значит, система корректно посчитала среднее число заявок в системе, среднее время пребывания и интенсивность потока. Результатам можно доверять.
* **«Не пройдено»** — обнаружено расхождение (допуск 10 %). Это сигнал, что результаты пока недостоверны. Возможные причины: слишком короткий прогон, высокая вариативность или нестабильный поток. В этом случае увеличьте количество заявок или время симуляции и перезапустите расчёт.

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

## Стационарный режим (steady state) и warm-up

Рядом с проверкой закона Литтла находится блок **«Steady State»** со статусом:

* **«Достигнут»** — система стабилизировалась. Показаны дополнительные данные: «Система стабилизировалась через …» (время или количество заявок, после которых показатели перестали меняться) и «% в Steady State» (доля прогона, приходящаяся на стабильную фазу).
* **«Не достигнут»** — прогон закончился до того, как система вышла на устойчивый режим. В этом случае цифры в отчёте отражают «разгон» (warm-up), а не реальный режим работы. Увеличьте число заявок или длительность прогона и запустите симуляцию заново.

**Warm-up** — это начальная фаза прогона, когда система «набирает обороты»: заполняются очереди, ресурсы переходят в рабочий ритм. На таймлайне прогона (вкладка «Диаграмма») эта фаза помечена бейджем **«Warm-up»**, а стабильная часть — бейджем **«Стационарный режим»**. В расчёте итоговых метрик warm-up исключается, но если стационарный режим не достигнут вообще, исключать нечего — и цифры будут завышены или занижены.

## Декомпозиция времени в системе

Ниже индикаторов находится блок **«Декомпозиция времени в системе»**, который разбивает общее время пребывания заявки на составляющие:

* **Время обработки** — время, когда заявка активно обрабатывается ресурсом.
* **Ожидание (всего)** — суммарное время, когда заявка ждёт.

Ожидание, в свою очередь, делится на две части:

* **Очередь к ресурсам** — время, когда заявка ждёт свободного исполнителя. Лечится увеличением численности ресурсов или ускорением обработки.
* **Ожидание по календарю** — время, когда заявка ждёт, потому что ресурс не работает (выходной, ночь, перерыв). Лечится изменением графика работы или расширением календаря.

Эта разбивка помогает понять, что именно менять: если основная доля ожидания — «очередь к ресурсам», добавьте исполнителей или сократите время обработки. Если доминирует «ожидание по календарю», пересмотрите расписание или добавьте смену.

## Графики динамики

Во вкладке отображаются несколько графиков, которые наглядно показывают, как менялись показатели во время прогона:

* **«Размер системы и очередь»** — количество заявок в системе и в очередях по времени.
* **«Среднее время в системе (W)»** — динамика среднего времени пребывания заявки.
* **«Пропускная способность и утилизация»** — throughput и утилизация ресурсов.
* **«Утилизация ресурсов»** — с линиями порогов **«Перегрузка (80%)»** и **«Недозагрузка (30%)»**.
* **«Средняя длина очереди»** — динамика очереди.
* **«Обработано заявок по батчам»** — накопительная кривая обработанных заявок.

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

## Что делать, если проверки не пройдены

1. **Закон Литтла «Не пройдено»** — увеличьте количество заявок (например, с 100 до 500) или время прогона и перезапустите симуляцию. Если расхождение сохраняется, проверьте, не слишком ли высока вариативность длительностей задач.
2. **Steady State «Не достигнут»** — увеличьте длительность прогона. Если вы запускаете по количеству заявок, добавьте заявок; если по времени — увеличьте период. После перезапуска убедитесь, что доля «% в Steady State» составляет хотя бы 70–80 %.
3. **Ожидание по календарю доминирует** — измените график ресурсов (например, добавьте вторую смену) или настройте поток заявок так, чтобы он совпадал с рабочими часами.
4. **Очередь к ресурсам доминирует** — добавьте ресурсы или сократите время обработки. Подробнее о поиске узких мест см. в статье «Как анализировать загрузку ресурсов и находить узкие места».

## Частые формулировки

«достоверность результатов симуляции», «стационарный режим не достигнут», «закон Литтла не пройден», «warm-up в des-симуляции», «проверка расчёта симуляции», «почему цифры в отчёте не совпадают с реальностью», «увеличить прогон des», «ожидание по календарю или очередь к ресурсам», «как понять, что симуляция стабилизировалась».