Сижу иногда в холле в клиниках у Заказчика, наблюдаю за очередью в регистратуре. И ловлю себя на мысли: я вижу ровно то же самое, что вижу в мониторинге нагруженного сервера в час пик. Только вместо запросов - люди, а вместо процессорных ядер - окна администраторов.
Это не метафора. Это буквально одна и та же системная проблема - узкое место, bottleneck.
Вот смотрите.
1. Принцип очереди (queue theory). Он везде одинаковый.
Неважно, что стоит в очереди - HTTP-запросы на авторизацию или пациенты с паспортами. Если скорость обработки (processing rate) на точке ниже, чем скорость поступления (arrival rate) - очередь будет расти. В IT мы видим растущий latency, таймауты. В клинике - это нервные люди, которые уже двадцать минут ждут запись.
2. Нужно искать не самую длинную очередь, а её причину.
Можно поставить пятого администратора, но если проблема в том, что медсестра не успевает готовить кабинеты к приёму, и врачи простаивают - толку не будет. Ровно как и добавить сервер в кластер, когда узкое место - тормозная база данных. Нагрузка просто переместится, упрётся в следующее слабое звено, а деньги на железо будут потрачены впустую.
3. Планирование мощности.
Никто же не запускает продажи билетов на концерт без расчёта, выдержит ли сайт. Но в клиниках сплошь и рядом: запускают акцию на популярную услугу, а потом удивляются, что два телефонных номера не справляются, регистратура в панике, а врачи сидят без работы, потому что запись расписана на три недели вперёд. Не спланировали «пиковую нагрузку». В итоге - потерянные пациенты здесь и сейчас и срыв планов по выручке.
4. Буфер и балансировка.
Умные ИТ-системы используют кэши и балансировщики, чтобы сгладить пики. В клинике эту роль играет, например, предварительная запись. Это и есть распределение нагрузки. Но если этот буфер не настроен (скажем, нельзя записаться онлайн или запись открывается только на две недели), то вся нагрузка ложится на точку входа в момент открытия дверей. И мы получаем тот самый утренний час пик и стресс для всех.
5. Мониторинг и метрики.
По серверам у меня есть графики: загрузка CPU, длина очереди запросов, время ответа. По работе регистратуры таких метрик часто просто нет. А они нужны: среднее время обслуживания одного пациента, пиковые часы, процент отказов (когда человек не дождался и ушёл). Без цифр мы не управляем процессом, а тушим пожары по наитию.
Получается, что я, как аналитик, смотрю на клинику как на живую распределённую систему. Поток пациентов - это трафик. Кабинеты и специалисты - это сервисы и ноды. Документооборот - это сетевой обмен данными.
И оптимизация везде работает по одним законам:
- Найти настоящее узкое место (а не то, которое всем кажется проблемой).
- Измерять всё, что движется.
- Сглаживать пики и создавать буферы.
- И главное - понимать, что добавление ресурсов в случайное место системы чаще всего даёт нулевой эффект.
В следующий раз, когда увидите очередь, попробуйте мысленно наложить на неё вот эту схему. Становится гораздо понятнее, куда копать, чтобы её устранить. Не расширять помещение, а, возможно, просто переставить стол или изменить скрипт разговора администратора.
А вам приходилось видеть такие «системные» проблемы в своих процессах? Не обязательно в медицине.
#системныйанализ #очереди #оптимизация #логистика #процессы #управление #ITмышление #bottleneck #клиника