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

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

    Из-за недоступности корзин 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. Наши другие материалы:


    1cloud.ru 162,51
    IaaS, VPS, VDS, Частное и публичное облако, SSL
    Поделиться публикацией
    Комментарии 0

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

    Самое читаемое