«Сбои бывают у всех»: Пример AWS и немного об опыте российского IaaS-провайдера

В конце февраля компания Amazon столкнулась ^[1] с проблемой, которая нарушила работу не только крупных (и не очень) веб-сайтов, но и приложений для Интернета вещей. На восстановление функционала ушло порядка пяти часов, и в это время компания не могла обновить даже статус о состоянии своих серверов. Запуск новых инстансов EC2 в «сломанном» AWS-регионе также был невозможен.

Из-за недоступности корзин Amazon S3 в Северной Вирджинии нарушилась ^[2] работа таких сервисов, как Docker's Registry Hub, GitHub, GitLab, Quora, Medium, Twitch.tv, Heroku, Coursera, Bitbucket и др

^[3]/ фото Emilio Küffer ^[4] CC ^[5]

Инженеры Amazon сумели вернуть контроль над ситуацией в течение дня и обновить всю информацию. Согласно официальным заявлениям, функциональность сервисов была восстановлена ^[1] в течение пяти часов с момента появления первого репорта об ошибке.

Уже второго марта Amazon предоставили ^[6] подробный отчет о ситуации и проблемах, её вызвавших. В компании заявляют, что отключение было вызвано сотрудником, который решал проблему с платежной системой. Он написал неверную команду в продакшн-среде, работая над улучшением производительности.

«Команда Amazon Simple Storage Service решала проблему низкой скорости работы биллинговой системы S3. Примерно в 09:37 PST (19:37 по московскому времени) член команды, используя утвержденный план, ввел команду, которая должна была удалить небольшое число активных серверов одной из подсистем S3, – говорят представители Amazon. – К сожалению, один из операторов был введен некорректно, что привело к удалению большего числа серверов».

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

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

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

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

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

В случае с недоступностью сервисов в рамках нескольких часов размер выплат для конкретного клиента может показаться не столь весомым, но для нового IaaS-провайдера компенсация может стать ощутимым ударом по финансам. Здесь важно расчитывать свои силы и взвешивать репутационные риски.

Для нас хорошие отношения с клиентами гораздо ценнее сиюминутной экономии. Поэтому мы решили «округлить» выплаты по SLA в бОльшую сторону. Этот ход в комбинации с быстрым разрешением проблемы поспособствовал притоку огромного числа отзывов с положительной оценкой наших действий.

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

Отметим, что многие сервисы пострадали из-за ошибки Amazon, поскольку не все разработчики распределяют приложения по нескольким дата-центрам. Это нужно для того, чтобы выход из строя одной ключевой точки не тянул за собой всю платформу. На этот фактор необходимо обращать внимание при выборе ^[7] IaaS-провайдера. Его ИТ-инфраструктура должна учитывать возможные сбои и балансировать нагрузку при отказе какого-либо элемента.

P.S. В следующих сериях мы поговорим об опыте работы с различными платежными шлюзами, соответствующих сложностях с подключением и наших решениях.

P.P.S. Наши другие материалы:

Автор: 1cloud.ru

Источник ^[15]