Отчет об инциденте 21 сентября 2022 года

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

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

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

Что произошло 21 сентября?

Основные компоненты нашей вычислительной платформы оказались в состоянии разделения системы на несколько частей, каждая из которых продолжала функционировать независимо от другой (т.н. split-brain problem‎). Данная ситуация лучше всего объясняется, следующим образом: несколько вычислительных ресурсов считают себя ведущими, при этом каждый такой ведущий ресурс – единственным ответственным за согласованность данных в резервированной системе высокой доступности.

Это вызвало рассогласованность базовой инфраструктуры и, в свою очередь, привело к тому, что множество других сервисов периодически оказывались недоступными.

В BitMEX для защиты нашей системы от попыток DDoS-атак и другого вредоносного трафика и поведения используется Cloudflare. Наши клиенты отправляют свои запросы в Cloudflare, которые затем направляются на серверы BitMEX. Принимается только трафик, непосредственно отправленный с IP-адресов Cloudflare. 

После устранения проблемы и перезапуска сервисов половина наших экземпляров сервисов не смогла пройти аутентификацию в Cloudflare (не по вине Cloudfare). Это привело к тому, что эти сервисы не доверяли запросам, поступающим с IP-адресов Cloudflare, что, в свою очередь, повлекло за собой ошибки аутентификации 403 по запросам, поступающим к этим сервисам.

Проблема усугублялась еще двумя техническими аспектами:

  1. При запуске сервиса запрос на аутентификацию Cloudflare был реализован таким образом, что он не выполнялся без каких-либо уведомлений и по умолчанию выдавал пустой список доверенных IP-адресов. Проще говоря, это означало, что API получил инструкции не доверять никаким запросам. 
  2. Код ошибки, выдаваемый в ответ на ненадежный IP-адрес, – 403. Это тот же ответ, который обычно выдается при проблемах с аутентификацией обычного пользователя.

Какие последствия ощутили пользователи?

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

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

Что предпринимается для того, чтобы это не повторилось?

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

Мы постоянно работаем над улучшением наших систем мониторинга, чтобы выявлять системные проблемы, подобные той, что возникла 21 сентября, в упреждающем порядке, до того, как они приведут к каким-либо последствиям для наших пользователей. Это непрерывное внимание уделяется обеспечению бесперебойной торговли и улучшению качества обслуживания. 

Обратите внимание, что с самого начала нашей работы мы обеспечиваем полную информационную прозрачность в отношении функционирования нашей системы на странице статуса. 

Как я могу защитить себя от рисков, связанных с простоем системы?

Торговая платформа BitMEX предоставляет ряд сложных инструментов и настроек, с помощью которых трейдеры могут регулировать риски, возникающие в результате простоев.

Трейдерам, использующим наш API, мы предлагаем функцию «аварийной блокировки» (т.н. dead man’s switch), которая позволяет трейдерам установить максимальное время ожидания, по истечении которого происходит отмена ордеров в случае, если трейдер не может связаться с площадкой. Подробную информацию о реализации и пример установки времени ожидания можно найти в документации к этой функции.

Для повышения уровня защиты трейдеры могут установить цену срабатывания стоп-ордера по последней цене, цене маркировки или цене базового индекса. Когда биржа вновь заработает после простоя, могут произойти резкие колебания последней цены. Чтобы избежать срабатывания стоп-ордеров при резких колебаниях последней цены, трейдеры могут настроить срабатывание стоп-ордеров по цене маркировки или цене базового индекса, а не по последней цене.

Это лишь два примера возможностей платформы BitMEX, которые позволяют нашим трейдерам контролировать риски и уменьшать влияние времени простоя. Наша служба поддержки может предоставить дополнительную информацию об этих (и любых других) инструментах управления рисками на платформе.

Выводы 

За короткое время криптовалютная индустрия проделала большой путь. Мы знаем, что предъявляемые к нам ожидания возросли, поэтому мы постоянно работаем над дальнейшим повышением стабильности нашей платформы. 

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

Как всегда, мы призываем всех заинтересованных пользователей и тех, кто непосредственно столкнулся с последствиями этого сбоя, обращаться в службу поддержки. Всем пользователям, которые попали под ликвидацию в результате сбоя 21 сентября, была предоставлена соответствующая компенсация.