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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если у вас тоже есть какая-то проблема, которую вы не можете долго решить — обращайтесь, проконсультируем: [email protected]