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

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

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

Что плохо:

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

Что хорошо:

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

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

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

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