СЭД: неочевидные причины, влияющие на быстродействие
Пользователи жалуются, что в системе невозможно работать, все тормозит. Администраторы говорят: «Всё работает, смотрите, по Графане 0 проблем». А пользователи всё равно мучаются.
В большинстве случаев проблема не в коде. И не в самой СЭД. Она в архитектуре и настройках. И эти причины не видны на первый взгляд. И их не увидит 99,9% узких спецов. И разработчики их не решат.
Пример 1. Виртуальные сервера.
Одна виртуалка обрабатывает огромный поток запросов пользователей — и начинает захлёбываться. Решение? Размножить её. Сделать несколько копий, которые параллельно обрабатывают запросы. Нагрузка распределяется, система оживает. Например, у меня в СЭДе было 3 виртуальных серверов приложений. Я сделала 6.
Никакого изменения кода. Только архитектурное решение.
Пример 2. Шедулеры.
Шедулер — это планировщик задач, который обрабатывает очереди документов. Иногда один документ «подвешивает» всю очередь. И все остальные стоят, пока он не пройдёт.
Решение? Настроить шедулер так, чтобы «зависший» документ искусственно снимался с обработки, пользователю возвращалось «запрос не обработан», а очередь шла дальше.
Это не про код. Это про логику обработки.
Как я это делаю.
Я — не технарь. Я не пишу код и не настраиваю сервера. Моя задача — видеть картину целиком. Мне не надо уметь кодить,чтобы решать проблемы.
Я анализирую заявки и мониторинг. Вижу повторяющиеся паттерны. «У пользователей по адресу Х не грузятся PDF», «в очереди висит документ», «нагрузка на сервер растёт».
Я спрашиваю у технарей: «Почему это происходит? Что можно сделать? Какие есть варианты?». Разбираюсь в механизме. Слушаю предложения. Предлагаю сама. Ищу через ии. Выбираю оптимальное. Выбираю логикой и общим знанием всей инфраструктуры, процессов, всей предметной сферы. И реализую — через управленческое решение, а не через код.
Технари делают технику. Управленец выявляет проблему; делает выбор решения, который ее устранит; обеспечивает реализацию.
К чему это.
Если ваша СЭД или любая другая инф система тормозит — не спешите нанимать разработчиков. Сначала посмотрите на архитектуру. На виртуалки. На шедулеры. На очереди.
И задайте себе вопрос: «Какое управленческое решение я могу принять, чтобы система ожила?»
Иногда ответ проще, чем кажется.
Кейс верен в отношении любых информационных систем.
#СЭД #быстродействие #управление #архитектура #опытБорисовской