СЭД: неочевидные причины, влияющие на быстродействие

Пользователи жалуются, что в системе невозможно работать, все тормозит. Администраторы говорят: «Всё работает, смотрите, по Графане 0 проблем». А пользователи всё равно мучаются.

В большинстве случаев проблема не в коде. И не в самой СЭД. Она в архитектуре и настройках. И эти причины не видны на первый взгляд. И их не увидит 99,9% узких спецов. И разработчики их не решат.

Пример 1. Виртуальные сервера.

Одна виртуалка обрабатывает огромный поток запросов пользователей — и начинает захлёбываться. Решение? Размножить её. Сделать несколько копий, которые параллельно обрабатывают запросы. Нагрузка распределяется, система оживает. Например, у меня в СЭДе было 3 виртуальных серверов приложений. Я сделала 6.

Никакого изменения кода. Только архитектурное решение.

Пример 2. Шедулеры.

Шедулер — это планировщик задач, который обрабатывает очереди документов. Иногда один документ «подвешивает» всю очередь. И все остальные стоят, пока он не пройдёт.

Решение? Настроить шедулер так, чтобы «зависший» документ искусственно снимался с обработки, пользователю возвращалось «запрос не обработан», а очередь шла дальше.

Это не про код. Это про логику обработки.

Как я это делаю.

Я — не технарь. Я не пишу код и не настраиваю сервера. Моя задача — видеть картину целиком. Мне не надо уметь кодить,чтобы решать проблемы.

Я анализирую заявки и мониторинг. Вижу повторяющиеся паттерны. «У пользователей по адресу Х не грузятся PDF», «в очереди висит документ», «нагрузка на сервер растёт».

Я спрашиваю у технарей: «Почему это происходит? Что можно сделать? Какие есть варианты?». Разбираюсь в механизме. Слушаю предложения. Предлагаю сама. Ищу через ии. Выбираю оптимальное. Выбираю логикой и общим знанием всей инфраструктуры, процессов, всей предметной сферы. И реализую — через управленческое решение, а не через код.

Технари делают технику. Управленец выявляет проблему; делает выбор решения, который ее устранит; обеспечивает реализацию.

К чему это.

Если ваша СЭД или любая другая инф система тормозит — не спешите нанимать разработчиков. Сначала посмотрите на архитектуру. На виртуалки. На шедулеры. На очереди.

И задайте себе вопрос: «Какое управленческое решение я могу принять, чтобы система ожила?»

Иногда ответ проще, чем кажется.

Кейс верен в отношении любых информационных систем.

#СЭД #быстродействие #управление #архитектура #опытБорисовской

СЭД: неочевидные причины, влияющие на быстродействие | Сетка — социальная сеть от hh.ru СЭД: неочевидные причины, влияющие на быстродействие | Сетка — социальная сеть от hh.ru