Многие сервисы пытаются тщательно скрывать информацию о сбоях в работе. Считают, что рассказывая о проблеме, они теряют репутацию. Узнавать факты о скрытии проблем не приятно, особенно если из-за сбоя могли потеряться данные или утечь пароли. Проблема в том, что пользователи сервиса не понимают, что произошло и какова вероятность повторного сбоя. Доверять таким сервисам не хочется.

Вообщем, у нас был сбой. 19 мая в 6:06 по Москве Бипиум стал с переменами отвечать на запросы к данным у части компаний. Остроту проблемы удалось снизить в 9:12 и полностью решить только в 9:59.

Проблема началась в 4 утра и связана с тем, что один из серверов API перестал завершать некоторые соединения с одним из серверов баз данных. Соединения подвисали и накапливались, пока база данных не отказалась принимать новые. В результате Бипиум не мог получать записи из базы данных и отдавать их в приложении. Часть клиентов видела пустой экран приложения Бипиум. При этом сервер базы данных и сервер API стояли с нулевой загрузкой. По этому автоматика облака не распознала проблему и не попыталась её решить или уведомить нас о проблеме. Хуже всего, что мы узнали о проблеме только от одного из клиентов в 8:42.

Что плохо:

• Часть клиентов практически не могли работать почти 3 часа, до 9:12,
• Автоматика облака не распознала проблему и не уведомила нас,
• Сбой не связан с кодом Бипиума, по этому повлиять на него сложно.

Что хорошо:

• Данные клиентов не были потеряны,
• Приватные данные (логины, пароли) не утекли наружу,
• Сбой произошел только у части клиентов и рано с утра.

Как исправим:

• Обновим сервера базы данных до последней версии, в новой версии есть механизм защиты от подвисших соединений,
• Создадим скрипт, который будет отслеживать и убивать подвисшие соединения раз в 5 минут,
• Добавим в систему мониторинга показатель по подвисшим соединениям, чтобы узнавать о проблеме раньше,
• Изучим какие методы защиты можно создать в коде.

Приносим извинения за сбой. Спасибо, что выбрали нас. Надеемся, следующий будет не скоро.