В конце февраля компания Amazon столкнулась с проблемой, которая нарушила работу не только крупных (и не очень) веб-сайтов, но и приложений для Интернета вещей. На восстановление функционала ушло порядка пяти часов, и в это время компания не могла обновить даже статус о состоянии своих серверов. Запуск новых инстансов EC2 в «сломанном» AWS-регионе также был невозможен.
Из-за недоступности корзин Amazon S3 в Северной Вирджинии нарушилась работа таких сервисов, как Docker's Registry Hub, GitHub, GitLab, Quora, Medium, Twitch.tv, Heroku, Coursera, Bitbucket и др
/ фото Emilio Küffer CC
Инженеры Amazon сумели вернуть контроль над ситуацией в течение дня и обновить всю информацию. Согласно официальным заявлениям, функциональность сервисов была восстановлена в течение пяти часов с момента появления первого репорта об ошибке.
Уже второго марта Amazon предоставили подробный отчет о ситуации и проблемах, её вызвавших. В компании заявляют, что отключение было вызвано сотрудником, который решал проблему с платежной системой. Он написал неверную команду в продакшн-среде, работая над улучшением производительности.
S3 за последние несколько лет испытал огромный рост, поэтому процессы перезапуска и поддержки сервисов, а также проведение необходимых проверок безопасности заняли длительное время, большее, чем ожидали в команде поддержки.
Подобные ситуации могут случиться даже с самыми именитыми провайдерами. Мы и сами испытывали на себе проблемы самого различного характера. Дело в том, как компания реагирует на подобные ситуации — огромную роль играет человеческий фактор. Он же зачастую и является основной причиной возникновения неисправностей.
Одна из крупнейший аварий, которая произошла у нас, затронула порядка 10% от общего числа клиентов. Произошел полный отказ сетевых служб на границе с нашим облаком, но нам удалось в рамках пары часов выявить неисправность и проанализировать действия, которые привели к ее возникновению.
Быстрый анализ в подобной ситуации возможен исключительно на основе имеющего опыта решения подобных проблем и наличия достаточного числа компетентных специалистов, которые готовы выйти на связь даже ночью. Экспресс-оценка — первое, что стоит сделать. Именно так мы и поступили, собрав экстренный конф.колл без малейшей мысли об ожидании следующего рабочего дня.
Далее следует оповещение клиентов, в рамках которого важно предоставить максимально полную информацию, которую получится собрать на этот момент. По итогам более детального расследования стоит определить размер выплат клиентам в качестве компенсации в соответствии с SLA.
В случае с недоступностью сервисов в рамках нескольких часов размер выплат для конкретного клиента может показаться не столь весомым, но для нового IaaS-провайдера компенсация может стать ощутимым ударом по финансам. Здесь важно расчитывать свои силы и взвешивать репутационные риски.
Для нас хорошие отношения с клиентами гораздо ценнее сиюминутной экономии. Поэтому мы решили «округлить» выплаты по SLA в бОльшую сторону. Этот ход в комбинации с быстрым разрешением проблемы поспособствовал притоку огромного числа отзывов с положительной оценкой наших действий.
По итогам подобных событий всегда следует работа над ошибками. В Amazon говорят, что примут меры предосторожности, чтобы избежать повторения подобной ситуации в будущем, включая ограничение возможностей инструментов отладки и разделение сервиса на более маленькие ячейки, дабы уменьшить потенциальный ущерб. Компания также планирует улучшить процессы проведения аудита, чтобы гарантировать организацию всех необходимых проверок.
Отметим, что многие сервисы пострадали из-за ошибки Amazon, поскольку не все разработчики распределяют приложения по нескольким дата-центрам. Это нужно для того, чтобы выход из строя одной ключевой точки не тянул за собой всю платформу. На этот фактор необходимо обращать внимание при выборе IaaS-провайдера. Его ИТ-инфраструктура должна учитывать возможные сбои и балансировать нагрузку при отказе какого-либо элемента.
P.S. В следующих сериях мы поговорим об опыте работы с различными платежными шлюзами, соответствующих сложностях с подключением и наших решениях.
P.P.S. Наши другие материалы:
Из-за недоступности корзин Amazon S3 в Северной Вирджинии нарушилась работа таких сервисов, как Docker's Registry Hub, GitHub, GitLab, Quora, Medium, Twitch.tv, Heroku, Coursera, Bitbucket и др
/ фото Emilio Küffer CCИнженеры Amazon сумели вернуть контроль над ситуацией в течение дня и обновить всю информацию. Согласно официальным заявлениям, функциональность сервисов была восстановлена в течение пяти часов с момента появления первого репорта об ошибке.
Уже второго марта Amazon предоставили подробный отчет о ситуации и проблемах, её вызвавших. В компании заявляют, что отключение было вызвано сотрудником, который решал проблему с платежной системой. Он написал неверную команду в продакшн-среде, работая над улучшением производительности.
«Команда Amazon Simple Storage Service решала проблему низкой скорости работы биллинговой системы S3. Примерно в 09:37 PST (19:37 по московскому времени) член команды, используя утвержденный план, ввел команду, которая должна была удалить небольшое число активных серверов одной из подсистем S3, – говорят представители Amazon. – К сожалению, один из операторов был введен некорректно, что привело к удалению большего числа серверов».
S3 за последние несколько лет испытал огромный рост, поэтому процессы перезапуска и поддержки сервисов, а также проведение необходимых проверок безопасности заняли длительное время, большее, чем ожидали в команде поддержки.
Подобные ситуации могут случиться даже с самыми именитыми провайдерами. Мы и сами испытывали на себе проблемы самого различного характера. Дело в том, как компания реагирует на подобные ситуации — огромную роль играет человеческий фактор. Он же зачастую и является основной причиной возникновения неисправностей.
Одна из крупнейший аварий, которая произошла у нас, затронула порядка 10% от общего числа клиентов. Произошел полный отказ сетевых служб на границе с нашим облаком, но нам удалось в рамках пары часов выявить неисправность и проанализировать действия, которые привели к ее возникновению.
Быстрый анализ в подобной ситуации возможен исключительно на основе имеющего опыта решения подобных проблем и наличия достаточного числа компетентных специалистов, которые готовы выйти на связь даже ночью. Экспресс-оценка — первое, что стоит сделать. Именно так мы и поступили, собрав экстренный конф.колл без малейшей мысли об ожидании следующего рабочего дня.
Далее следует оповещение клиентов, в рамках которого важно предоставить максимально полную информацию, которую получится собрать на этот момент. По итогам более детального расследования стоит определить размер выплат клиентам в качестве компенсации в соответствии с SLA.
В случае с недоступностью сервисов в рамках нескольких часов размер выплат для конкретного клиента может показаться не столь весомым, но для нового IaaS-провайдера компенсация может стать ощутимым ударом по финансам. Здесь важно расчитывать свои силы и взвешивать репутационные риски.
Для нас хорошие отношения с клиентами гораздо ценнее сиюминутной экономии. Поэтому мы решили «округлить» выплаты по SLA в бОльшую сторону. Этот ход в комбинации с быстрым разрешением проблемы поспособствовал притоку огромного числа отзывов с положительной оценкой наших действий.
По итогам подобных событий всегда следует работа над ошибками. В Amazon говорят, что примут меры предосторожности, чтобы избежать повторения подобной ситуации в будущем, включая ограничение возможностей инструментов отладки и разделение сервиса на более маленькие ячейки, дабы уменьшить потенциальный ущерб. Компания также планирует улучшить процессы проведения аудита, чтобы гарантировать организацию всех необходимых проверок.
Отметим, что многие сервисы пострадали из-за ошибки Amazon, поскольку не все разработчики распределяют приложения по нескольким дата-центрам. Это нужно для того, чтобы выход из строя одной ключевой точки не тянул за собой всю платформу. На этот фактор необходимо обращать внимание при выборе IaaS-провайдера. Его ИТ-инфраструктура должна учитывать возможные сбои и балансировать нагрузку при отказе какого-либо элемента.
P.S. В следующих сериях мы поговорим об опыте работы с различными платежными шлюзами, соответствующих сложностях с подключением и наших решениях.
P.P.S. Наши другие материалы:
- Тренды облачной безопасности
- Немного о безопасности в «облаке»
- Нюансы соглашения об уровне оказываемых услуг
- Дайджест об облаках, дата-центрах и разработке сервисов
- Мифы об облачных технологиях (часть 1, часть 2 и часть 3)
- Что нужно знать об IaaS-провайдере до начала работы
