100% время безотказной работы веб-приложения

Вот это ВикипедияУдобная таблица погони за девятками:

Интересно только 3 из 20 лучших сайтов смогли достичь мифических 5 девяток или 99,999% времени безотказной работы в 2007 году. Это были Yahoo, AOL и Comcast. За первые 4 месяца 2008 г. некоторые из самых популярные социальные сети, даже близко не подошли к этому.

Из диаграммы должно быть очевидно, насколько нелепо стремление к 100% работоспособности ...

Попросите их определить 100% и как это будет измеряться В течение какого периода времени. Вероятно, они имеют в виду настолько близкие к 100%, насколько они могут себе позволить. Дайте им смету.

Чтобы уточнить. На протяжении многих лет я вел дискуссии с клиентами с предположительно смехотворными требованиями. Во всех случаях они просто использовали недостаточно точный язык.

Довольно часто они создают вещи, которые кажутся абсолютными - например, 100%, но на самом деле при более глубоком исследовании они достаточно разумны, чтобы провести анализ затрат / выгод, который требуется при представлении данных о затратах на снижение рисков. Спросить их, как они будут измерять доступность, - важный вопрос. Если они этого не знают, тогда вы можете предположить, что это нужно сначала определить.

Я бы попросил клиента определить, что произойдет с точки зрения влияния на бизнес / затрат, если сайт выйдет из строя в следующих обстоятельствах:

• В самые загруженные часы в течение x часов
• По крайней мере, их часы занятости в течение x часов

А также как они это будут измерять.

Таким образом, вы можете работать с ними, чтобы определить правильный уровень «100%». Я подозреваю, что задавая подобные вопросы, они смогут лучше определить приоритеты своих других требований. Например, они могут захотеть заплатить определенные уровни SLA и поставить под угрозу другие функции, чтобы достичь этого.

Ваши клиенты сумасшедшие. 100% работоспособность невозможно независимо от того, сколько денег вы на это потратите. Просто и понятно - невозможно. Посмотрите на Google, Amazon и т. Д. У них есть почти бесконечные суммы денег, которые они могут потратить на свою инфраструктуру, и все же у них все же случаются простои. Вы должны донести до них это послание, и, если они будут продолжать настаивать, предъявите разумные требования. Если они этого не узнают некоторые количество простоев неизбежно, тогда откажитесь от них.

Тем не менее, похоже, что у вас есть механизм масштабирования / распространения самого приложения. Сетевая часть должна будет включать в себя избыточные восходящие каналы к разным интернет-провайдерам, получение ASN и выделение IP-адресов, а также использование BGP и реального механизма маршрутизации, чтобы при необходимости пространство IP-адресов могло перемещаться между провайдерами.

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

Что ж, это определенно интересно. Я не уверен, что хотел бы получить обязательство по контракту 100% времени безотказной работы, но если бы мне пришлось, я думаю, это выглядело бы примерно так:

Начните с общедоступного IP-адреса на балансировщике нагрузки, полностью вне сети, и создайте как минимум два из них, чтобы один мог переключиться на другой. Такая программа, как Heatbeart, может помочь с их автоматическим переключением.

Varnish в первую очередь известен как решение для кэширования, но он также выполняет очень приличную балансировку нагрузки. Возможно, это было бы хорошим выбором для балансировки нагрузки. Он может быть настроен так, чтобы иметь от 1 до n бэкэндов, необязательно сгруппированных в директорах, которые будут балансировать нагрузку случайным образом или циклически. Varnish можно сделать достаточно умным, чтобы проверять работоспособность каждой серверной части и выводить нездоровые задние части из цикла, пока она не вернется в рабочее состояние. Серверные ВМ не обязательно должны быть в одной сети.

В наши дни мне нравятся эластичные IP-адреса в Amazon EC2, поэтому я, вероятно, построил бы свои балансировщики нагрузки в EC2 в разных регионах или, по крайней мере, в разных зонах доступности в одном регионе. Это даст вам возможность вручную (не дай бог) развернуть новый балансировщик нагрузки, если вам нужно, и переместить существующий IP-адрес записи A в новый ящик.

Однако Varnish не может завершить работу SSL, поэтому, если это вызывает беспокойство, вы можете вместо этого взглянуть на что-то вроде Nginx.

У вас может быть большая часть ваших серверных модулей в сети ваших клиентов, а одна или несколько - вне их сети. Я верю, но не уверен на 100%, что вы можете расставить приоритеты для бэкэндов, чтобы компьютеры ваших клиентов получали приоритет до тех пор, пока все они не перестанут работать.

Вот с чего я бы начал, если бы у меня была эта задача, и, несомненно, совершенствовал бы ее по мере продвижения.

Однако, как заявляет @ErikA, это Интернет, и всегда будут части сети, которые находятся вне вашего контроля. Вы должны убедиться, что ваш юрист связывает вас только с тем, что находится под вашим контролем.

Нет проблем - правда, текст договора немного изменен:

... гарантировать время безотказной работы 100% (с округлением до нуля десятичных знаков).

Если Facebook и Amazon не могут этого сделать, то и вы не сможете. Это так просто.

Добавить ответ Оконнора из Hacker News

Я не понимаю, в чем проблема. Клиент хочет, чтобы вы спланировали катастрофу, а он не ориентирован на математику, поэтому требование 100% вероятности звучит разумно. Инженер, как это делают инженеры, вспомнил свой первый день проверки и статистики 101, не подумав о том, что клиент может этого не делать. Когда они говорят это, они не думают о ядерной зиме, они думают о Фреде, выливающем кофе на офисный сервер, о сбое диска или о выходе из строя интернет-провайдера. Более того, вы можете это сделать. Благодаря географически разнесенным, независимым серверам с самоконтролем у вас практически не будет простоев. С 3 серверами, работающими с независимой (1) надежностью 3 9, с хорошими режимами аварийного переключения, ожидаемое время простоя составляет менее секунды в год (2). Даже если это произойдет сразу, вы по-прежнему находитесь в рамках разумного SLA для веб-соединений, и поэтому простоев практически не существует. Клиенту по-прежнему приходится иметь дело со сценариями судного дня, но, исключая Годзиллу, у него будет служба, которая «всегда» работает.

(1) Сервер в Лос-Анджелесе в достаточной степени независим от сервера в Бостоне, но да, я понимаю, что есть некое пересечение, связанное с ядерной войной, китайскими хакерами, ломающими электросеть и т. Д. Я не думаю, что ваш клиент будет расстроен этот.

(2) Отработка отказа DNS может добавить несколько секунд. Вы по-прежнему находитесь в сценарии, когда клиент должен повторять запрос один раз в год, что, опять же, находится в рамках разумного SLA и обычно не рассматривается в том же ключе, что и «простои». С приложением, которое автоматически перенаправляет доступ к доступному узлу в случае сбоя, это может быть незаметно.

Вас просят о невозможном.

Просмотрите другие ответы здесь, сядьте со своим клиентом и объясните ЗАЧЕМ это невозможно, и оценить их реакцию.

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

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

Это сделал провайдер на моей последней работе. У нас был выбор между «обычной» линией DSL с временем безотказной работы 99,9% за 40 долларов США в месяц или тремя связанными T1 с временем безотказной работы 99,99% за 1100 долларов США в месяц. Были частые перебои в работе на 10+ часов в месяц, из-за чего время безотказной работы было значительно ниже 40 долларов в месяц DSL, но нам вернули только около 15 долларов или около того, потому что это то, что в итоге получилось за час * часов. Они как бандиты разобрались со сделкой.

Если вы выставляете счет в размере 450 000 долларов в месяц за 100% безотказной работы и получаете только 99,999%, вам нужно будет вернуть им 324 доллара. Я готов поспорить, что затраты на инфраструктуру, которые достигнут 99,999%, находятся в районе 45000 долларов в месяц при условии полностью распределенного коло, нескольких восходящих каналов 1 уровня, оборудования fancypants и т. Д.

Есть два типа людей, которые требуют 100% времени безотказной работы:

1. Люди, не имеющие абсолютно никаких знаний о компьютерах, компьютерных системах или Интернете. *
2. Те, кто намеренно издевается над собой, либо чтобы проверить вашу способность сказать «нет» (Google «тест апельсинового сока»), либо попытаться получить какое-то контрактное плечо SLA, чтобы потом не платить вам.

Мой совет, поскольку я много раз страдал от обоих этих типов клиентов, не принимайте этого клиента. Пусть сведут кого-нибудь с ума.

* Этот же человек может без смущения спросить о путешествиях «быстрее света», «вечном движении», «холодном синтезе» и т. Д.

Если профессионалы задаются вопросом, если Доступность 99,999% [является] когда-либо практической или финансово жизнеспособной возможностьюто доступность 99,9999% еще менее возможна или практична. Не говоря уже о 100%.

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

Я бы связался с клиентом, чтобы выяснить, что именно означает 100% время безотказной работы. Возможно, они действительно не видят разницы между временем безотказной работы 99% и временем безотказной работы 100%. Для большинства людей (т.е. не администраторов серверов) эти два числа совпадают.

Это просто. В соглашении об уровне обслуживания Amazon EC2 четко указано:

«Годовой процент времени работоспособности» рассчитывается путем вычитания из 100% процента 5-минутных периодов в течение года обслуживания, в течение которого Amazon EC2 находился в состоянии «Регион недоступен».

http://aws.amazon.com/ec2-sla/

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

Кроме того, стоит отметить, что весь смысл SLA состоит в том, чтобы определить ваши обязательства и что произойдет, если вы не сможете их выполнить. Неважно, просит ли клиент 3 девятки, 5 девяток или миллион девяток - вопрос в том, что они получат, когда / если вы не сможете выполнить поставку. Очевидный ответ - предоставить позицию со 100% временем безотказной работы по 5-кратной цене, которую вы хотите взимать, а затем они получат 4-кратное возмещение, если вы пропустите эту цель. Вы можете забить!

100% время безотказной работы?

Вот что вам понадобится:

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

Убедитесь, что DNS-серверы настроены правильно и TTL правильно распознается.

Вы знаете, что это невозможно.

Несомненно, клиент нацелен на то, чтобы увидеть «100%», поэтому лучшее, что вы можете сделать, это пообещать 100%, за исключением [всех разумных причин, которые не являются вашей виной].

Изменения DNS требуют времени, только если они настроены на время. Вы можете установить TTL для записи равным одной секунде - ваша единственная проблема будет заключаться в том, чтобы обеспечить своевременный ответ на DNS-запросы и что DNS-серверы могут справиться с этим уровнем запросов.

Именно так GTM работает в F5 Big IP - TTL DNS по умолчанию установлен на 30 секунд, и если один член кластера должен взять на себя управление, DNS обновляется, и новый IP-адрес используется почти сразу. Максимум 30 секунд простоя, но это крайний случай, в среднем 15 секунд.

Честно говоря, 100% - это полное безумие без хотя бы колебания с точки зрения хакерской атаки. Лучше всего делать то, что делают Google и Amazon, поскольку у вас есть решение для географически распределенного хостинга, в котором ваш сайт и БД реплицируются на нескольких серверах в разных географических точках. Это гарантирует это во всех случаях, кроме серьезной катастрофы, такой как подключение магистрали Интернета к региону (что время от времени случается) или чего-то почти апокалиптического.

Я бы добавил пункт только для таких случаев (DDOS, отключение магистрали Интернета, апокалиптическая террористическая атака или большая война и т. Д.).

Помимо этого, обратите внимание на облачные сервисы Amazon S3 или Rackspace. По сути, облачная установка будет предлагать не только избыточность в каждом месте, но также масштабируемость и географическое распределение трафика, а также возможность перенаправления в неудачные географические области. Хотя я понимаю, что геораспределение стоит больше денег.

Хотя я сомневаюсь, что это возможно на 100%, вы можете рассмотреть возможность использования Azure (или чего-то с аналогичным SLA). Что происходит:

Ваши серверы - это виртуальные машины. Если когда-либо возникает проблема с оборудованием на одном сервере, ваша виртуальная машина перемещается на новую машину. Балансировщик нагрузки заботится о перенаправлении, поэтому клиент не должен видеть простоев (хотя я не уверен, как это повлияет на состояние ваших сеансов).

Тем не менее, даже с этим переключением при отказе разница между 99,999 и 100 граничит с безумием.

Вам нужно будет полностью контролировать следующие факторы.
- Человеческий фактор, как внутренний, так и внешний, злоба и бессилие. Примером этого является то, что кто-то помещает что-то в производственный код, что приводит к остановке сервера. Еще хуже, а саботаж?
- Деловые вопросы. Что, если ваш провайдер прекратит работу, забудет оплатить счета за электричество или просто решит прекратить поддержку вашей инфраструктуры без достаточного предупреждения?
- Природа. Что, если не связанные друг с другом торнадо одновременно поразят достаточное количество центров обработки данных, чтобы перегрузить резервные ресурсы?
- Полностью свободная от ошибок среда. Ты конечно нет ли крайнего случая с каким-либо сторонним или основным системным элементом управления, который не проявил себя, но все еще мог бы проявить себя в будущем?
- Даже если у вас есть полный контроль над вышеуказанными факторами, уверены ли вы, что программное обеспечение / человек, отслеживающий это, не представят вам ложноотрицательных результатов при проверке работы вашей системы?

Хотя некоторые люди здесь отметили, что 100% - это безумный или невозможно, они как-то упустили суть. Они утверждали, что причина этого в том, что даже лучшие компании / услуги не могут этого достичь.

Что ж, это намного проще. Это математически невозможно.

У всего есть вероятность. Во всех местах хранения серверов может произойти одновременное землетрясение, которое приведет к их уничтожению. Приятно, что это смехотворно малая вероятность, но это не 0. Все ваши интернет-провайдеры могут столкнуться с одновременной террористической / кибератакой. Опять же, маловероятно, но и не ноль. Что бы вы ни предлагали, вы можете получить сценарий с ненулевой вероятностью, который приведет к остановке всей службы. Потому что при этом и ваше время безотказной работы не может быть 100%.

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

Если у вас большой веб-сайт, время безотказной работы совершенно бесполезен. Если вы отбрасываете запросы на 10 минут, когда они больше всего нужны вашим клиентам (пик трафика), это может нанести более серьезный ущерб бизнесу, чем часовой перерыв в 3 часа ночи в воскресенье.

Иногда крупные веб-компании измеряют доступность или надежность, используя следующие показатели:

1. процент запросов, на которые даны успешные ответы, без ошибка на стороне сервера (HTTP 500).
2. процент запросов, на которые даны ответы ниже определенного целевого показателя задержка.
3. отброшенные запросы должны учитываться в вашей статистике (см. ниже).

Наличие должно не быть измеренным с помощью пробников, о чем могут сообщить внешние объекты, такие как pingdom и pingability. Не полагайтесь только на это. Если ты хочешь сделать это правильно, каждый запрос должен учитываться. Измеряйте свою доступность, глядя на свой фактический предполагаемый успех.

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

Процент отброшенные запросы также должны учитываться в вашей статистике. Это может быть учтено в том же сегменте, что и ошибки на стороне сервера. Если есть проблемы с сетью или другой инфраструктурой, такой как DNS или балансировщики нагрузки, вы можете использовать простую математику, чтобы оценить, сколько запросов вы потерянный. Если вы ожидали X запросов в этот день недели, но получили X-1000, вы, вероятно, отбросили 1000 запросов. Распределите трафик в виде графиков запросов в минуту (или секунду). Если появляются пробелы, вы сбросили запросы. Использовать базовая геометрия чтобы измерить площадь этих пробелов, что даст вам общее количество отброшенных запросов.

Обсудите эту методологию со своим клиентом и объясните ее преимущества. Установить исходный измеряя их текущую доступность. Им станет ясно, что 100% - это невыполнимая цель.

Затем вы можете подписать контракт, основанный на улучшении базовой линии. Скажем, если они в настоящее время испытывают 95% доступности, вы можете пообещать улучшить ситуацию. в десять раз доходя до 98,5%.

Примечание: у этого способа измерения доступности есть недостатки. Во-первых, сбор журналов, обработка и создание отчетов могут быть нетривиальными, если вы не используете для этого существующие инструменты. Во-вторых, ошибки приложения может повредить вашу доступность. Если приложение низкого качества, оно будет обслуживать больше ошибок. Чтобы решить эту проблему, нужно учитывать только 500, созданные балансировщиком нагрузки, а не те, которые поступают из приложения.

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

Я просто хотел добавить еще один голос к этому жестяная банка (теоретически) надо делать "вечеринку".

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

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

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

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

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

мои 2 цента. Я отвечал за очень популярный веб-сайт компании из списка Fortune 5, которая размещала рекламу для суперкубка. Мне приходилось иметь дело с огромными скачками трафика, и я решил эту проблему с помощью службы вроде Akamai. Я не работаю в Akamai, но их обслуживание мне очень понравилось. У них есть собственная, более умная система DNS, которая знает, что конкретный узел / хост либо находится под большой нагрузкой, либо не работает, и может соответствующим образом маршрутизировать трафик.

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

Хотя это и не 100% время безотказной работы, вы можете рассмотреть такие варианты распространения контента по всему миру. Насколько я понял, Akamai также имел возможность локализовать трафик: если я был в Мичигане, я получал контент с сервера в Мичигане / Чикаго, а если я был в Калифорнии, я предположительно получал контент с сервера в Калифорнии.

Я не думаю, что заказчик на самом деле требует 100% времени безотказной работы или даже 99,999% времени безотказной работы. Если вы посмотрите на то, что они описывают, они говорят о возобновлении с того места, на котором остановились, если метеорит уничтожит их локальный центр обработки данных.

Если требование состоит в том, чтобы посторонние люди даже не замечали, насколько это должно быть решительно? Будет ли приемлемо повторение запроса Ajax и отображение счетчика в течение 30 секунд для конечного пользователя?

Это те вещи, которые волнуют клиентов. Если бы заказчик действительно думал о точных SLA, он бы знал достаточно, чтобы выразить это как 99,99 или 99,999.

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

Для сайтов, размещенных на внешнем хостинге, максимальное время безотказной работы, которое вы получите, - это размещение вашего сайта на Google App Engine и его использование. хранилище данных с высокой репликацией (HRD), который автоматически реплицирует ваши данные как минимум в трех центрах обработки данных в реальном времени. Точно так же интерфейсные серверы App Engine автоматически масштабируются / реплицируются для вас.

Однако даже при наличии всех ресурсов Google и самой сложной платформы в мире Соглашение об уровне обслуживания для App Engine Гарантия бесперебойной работы составляет всего «99,95% времени в любом календарном месяце».

Просто и прямо: Anycast

http://en.wikipedia.org/wiki/Anycast

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

Но также имейте в виду, что невозможно обеспечить 100% безотказную работу, и что затраты на переход с 99,999% до 99,9999% - это НАМНОГО больше.