На прошлой неделе сервис Amazon Web Services столкнулся с одним из самых серьезных сбоев в работе сервиса облачных вычислений. Сбой вызвал волновой эффект на многих веб-сайтах, таких как Quora и HootSuite , которые были полностью отключены во время сбоя. Другие сайты, такие как Reddit , были, по крайней мере, частично затронуты.
Происходят сбои, и, как бы ни была молода индустрия облачных вычислений, я уверен, что это не будет последним или самым большим простоем.
Но с этим инцидентом (с обеих сторон) было несколько проблем, которые могут научить нас всем планированию и урегулированию кризисов.
Как вы общаетесь в условиях кризиса, очень важно
Amazon, как и следовало ожидать, подвергается критике за сбой AWS. Но самая жесткая критика, которую я видел, касается не продолжительности простоя или того факта, что он был в первую очередь. Наихудшая критика, которую я прочитал, касалась отсутствия у Amazon какого- либо ответа в течение более 40 минут после начала отключения — вечность, когда ваш сайт не работает.
Поскольку перебои в работе продолжались, многие клиенты были расстроены тем, что обновления выглядели так, как будто они были написаны юридическим отделом (и, судя по задержке в получении обновлений, они могли быть), а не написаны реальными людьми, которые работали над решить проблему.
Урок здесь очевиден — когда у вас возникают какие-либо кризисы, общение с пострадавшими крайне важно. В аварийном режиме, возможно, не удастся поднять трубку телефона, чтобы поговорить с клиентом или клиентом, но обновление вашего веб-сайта или изменение сообщения голосовой почты может оказать существенное влияние.
Когда вы общаетесь со своими клиентами о проблеме, будьте честными и искренними. Удивительно, как мало искренности может сделать, чтобы успокоить расстроенного клиента. 37 сигналов является отличным примером. Когда у их службы Basecamp происходит сбой (который встречается крайне редко), они отвечают подробным объяснением и сочувствующими извинениями, которые мы еще не увидели в Amazon.
Иметь план действий в чрезвычайных ситуациях
Поскольку я слышал о том, что некоторые чрезвычайно большие веб-сайты были полностью отключены из-за сбоя AWS, я не мог не задаться вопросом, почему они создали свои системы без какой-либо избыточности или плана резервного копирования. Облачные вычисления — это относительно молодая отрасль, и, хотя Amazon Web Services очень надежны, случаются сбои. Вы не остановите резервное копирование своего компьютера только потому, что у вас никогда не было сбоя жесткого диска — это должно произойти рано или поздно.
Одним из самых больших преимуществ облачных вычислений является их быстрая масштабируемость. Вполне возможно настроить две совершенно разные облачные среды, одну в AWS и одну в Rackspace, например, и просто иметь одну резервную копию, готовую для масштабирования до производства в случае сбоя (вручную или автоматически).
Теперь, что это значит для вас и меня?
В моем бизнесе электронной коммерции мы в значительной степени полагаемся на поисковые системы для увеличения трафика (и доходов). В 2003 году обновление Google привело к тому, что наш веб-сайт опустился с верхней части первой страницы примерно до 50 для почти каждой ключевой фразы. Наш трафик (и доходы) исчез за одну ночь. Мы пытались привлечь трафик через поисковый маркетинг и другие возможности, но к этому моменту было уже слишком поздно. Это был наш напряженный сезон, и клиентов не было.
Каждый раз, когда у вас есть возможность для одной точки отказа вызвать полный сбой проекта или службы, вы просто напрашиваетесь на неприятности. Я видел, как это происходит снова и снова, когда компании нанимают одного подрядчика для программирования приложения в сжатые сроки или полагаются на одного клиента почти для всего своего дохода.
Решение в нашем бизнесе электронной коммерции состояло в том, чтобы диверсифицировать нашу маркетинговую стратегию. Мы по-прежнему получаем значительный объем трафика от поисковых систем, но также увеличиваем доходы за счет поискового маркетинга, маркетинга по электронной почте, социальных сетей и других форм рекламы. Если другое обновление вызовет падение, мы определенно будем затронуты, но это не будет разрушительным.
Независимо от того, есть ли у вас несколько подрядчиков, которые могут вмешаться для оказания помощи в проектах в чрезвычайных ситуациях, или же вы работаете над тем, чтобы разнообразить свой список клиентов, чтобы ваш самый крупный клиент не приносил большую часть вашего дохода, вам следует изучить способы ограничения влияния любого из них. один случай в вашем бизнесе.