Как решить техническую проблему медицинской компании за 4 часа с перерывом на кофе

Недавно у нас случился целый медицинский детектив в духе Доктора Хауса. О том, как мы “лечили” систему клиента, проводя диагностику проблемы, мягко говоря, не самым привычным способом, читайте в этом кейсе.

Как решить техническую проблему медицинской компании за 4 часа с перерывом на кофе

Анамнез

Компания разрабатывает ПО для автоматизации процессов в медицинских учреждениях — радиологические информационные системы. В частности, софт для лучевой диагностики. Эти системы могут использовать как отдельные медицинские организации, так и целые регионы.

Нужно заметить, что это не был наш клиент: они обратились к нам по рекомендации. То есть их информационную систему до этого момента мы не видели.

На что жаловался клиент

На одном из объектов, где работала система, относительно регулярно возникали проблемы с быстродействием, особенно в часы пиковой нагрузки. При этом на других аналогичных объектах, где было установлено такое же ПО и была схожая нагрузка, таких проблем не было.

Изначально клиент пришел с запросом на нагрузочное тестирование. Поэтому решено было сначала провести аудит и починку проблем со скоростью работы, а после уже — нагрузочное (если потребуется и если будет в наших силах)

Алексей Алексеенко, главный системный администратор, ITSumma.

Как ставили диагноз

Чуть больше часа мы потратили на следующие процедуры.

Сначала мы “осмотрели” систему мониторинга. Она состояла из Zabbix (open source решение для мониторинга системы) , который отображал базовые параметры сервера, и Grafana (ПО для визуализации данных мониторинга) , где снимались бизнесовые метрики из приложения и был настроен мониторинг PostgreSQL.

При этом первоначальный аудит не выявил никаких проблем. Нагрузка на сервер держалась в норме даже в часы пик, было большое количество свободных ресурсов, проблем в работе базы по мониторингу также обнаружено не было.

Отчет PostgreSQL Tuner с результатами аудита системы мониторинга. Ничего критичного, нужна лишь небольшая подстройка параметров.

Далее мы перешли к осмотру сервера. К сожалению, клиент по соображениям безопасности не мог предоставить нам доступ на серверы напрямую, поэтому пришлось импровизировать. Проверку организовали с помощью приложения удаленного доступа AnyDesk через ПК одного из штатных сотрудников, у которого уже был настроен удаленный доступ к серверу через PuTTY.

Всё как в русской народной сказке: нужно было найти иголку-проблему в зайце (AnyDesk), который спрятан в утке (PuTTY), в утке — яйцо (сам сервер)… и не факт, что иголка в яйце ещё окажется та самая!

Мы стали проверять hardware сервера. И тут нас ждал сюрприз. Помимо работавшего с задержкой в несколько секунд AnyDesk, аудит усложняла проприетарная система, которая функционировала на базе XEN — виртуального сервера, вышедшего из массового использования лет 7 назад.

Но и на этом этапе также не обнаружилось проблем, которые влияли бы на быстродействие. Поэтому пришел черед проверить, как работает софт.

Сложности в лечении

Из-за ограниченного доступа в систему мы не могли увидеть, что тормозит с точки зрения клиента, на каких страницах он испытывает проблемы, — как и не могли воспроизвести эти проблемы. Поэтому приходилось действовать вслепую, а обратную связь получать от специалиста клиента, постоянно переспрашивая: “а сейчас тормозит? а теперь тормозит? а теперь? ”

Сложность ситуации добавляла и проприетарность системы. Инфраструктура строилась на контейнерах, которые были связаны друг с другом не только по веб-протоколу, но еще и по собственному, который не был обычным http.

Вооружившись docker logs, мы начали искать хоть какие-то зацепки. Это опять же заняло у нас около часа.

В логах контейнеров, на первый взгляд, не было ничего “криминального”, без явных сообщений о таймаутах и ошибок или каких-то обрывов связи. Поэтому мы двинулись дальше, распутывая взаимодействие всех компонентов системы. В этом помогали strace и tcpdump. С их помощью мы обнаружили единственную улику: при обращении к сокет-серверу коннекты нередко доходили до него со статусом Connection Refused. Попытка его дебага strace не показала каких-либо подвисаний, в ядро процессора сокет-сервер не упирался, то есть мощности ЦП вполне хватало.

Мы предположили, что проблема кроется в недостаточном количестве воркеров Daphne. О чем и сообщили клиенту с подробным описанием симптомов и логики нашей гипотезы.

Согласно ей, клиент должен был передеплоить контейнер с увеличением числа воркеров-коннектов. Процесс занимал от шести до восьми часов, поэтому продолжить диагностику было решено на следующий день.

Ночью заказчик всё же выкатил новую версию контейнера с веб-сокетом. Утром продолжилась игра в “А сейчас тормозит? ”, которая показала, что проблема с ограниченным доступом стала единственной. Система заработала корректно и быстро. После чего мы доделали аудит системы, дали рекомендации по корректировкам параметров ОС, PostgreSQL и прочего ПО.

Итог: 2 админа, 1 монитор, 3 часа диагностики и проблема, которую клиент инхаус не мог найти примерно месяц, решена!

Что вам с этого всего?

Этот кейс навел на следующие мысли:

  • Взгляд со стороны на инфраструктуру важен и нужен, даже если у вас очень сильная IT-команда в штате.
  • Если вы наладите мониторинг по бестпрактисез — это прекрасно и замечательно. Но у каждой инфраструктуры есть особенности, которые можно выявить только во время нагрузочного тестирования или эксплуатации.
  • Взаимодействие с клиентом — это важная часть работы. Линс очень помогали нам и оперативно реагировали. Отдельно стоит отметить, что спецы клиента выкатили новую версию контейнера за ночь в авральном порядке и, более того, в какой-то момент им пришлось срочно поднимать всю систему. Но в итоге даже трудности с доступом на сервер не повлияли на результат.

Если у вас тоже есть какая-то проблема, которую вы не можете долго решить — обращайтесь, проконсультируем: consulting@itsumma.ru

1616
2 комментария

Почему на других объектах не было такой проблемы, на этом нагрузка оказалась значительно больше?

Странно, что сбой сетевого подключения (в связи с лимитом на файловые дескрипторы) не давал выраженной ошибки в логи, за исключением визуального эффекта?

Ответить

Да, всё верно, на этом объекте нагрузка была выше, заказчик обозначил это на первом же созвоне.

По поводу второго вопроса: дело не в лимите на файловые дескрипторы, об этом нигде не шла речь. Недостаток воркеров был проблемой. В итоге копилась огромная очередь, а воркер не успевал обрабатывать запросы.

Ну и ещё одна предпосылка возникновения проблемы — отсутствие постоянного подробного мониторинга, о необходимости которого мы говорим все 15 лет существования нашей компании :-)

1
Ответить