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

Необходимое предисловие: перед тем пытаться обеспечить максимальный uptime проекта, следует соотнести затраты и стоимость даунтайма. Обычно, это очень важно для компаний, от работы которых зависит работа других компаний — B2B решения, API-сервисы, службы доставки. Недоступность в течение даже нескольких минут приведет, как минимум к нагрузке на call-центр от недовольных клиентов. Для компаний другого типа, например, небольшого интернет-магазина, или компании, клиенты которой работают с 9 до 18 недоступность даже в течение нескольких часов может стоить дешевле полноценной резервной площадки.

1. Локализация всего проекта в одном датацентре/одной зоне облачного хостинга

Маркетинг облачных хостингов прочно закрепил в голове людей ошибочную концепцию: облачный хостинг не привязан к железу и это означает, что облачная инфраструктура не упадет. Три 24-х часовые аварии Amazon Web Services, недавняя авария cloud4y, потеря данных cloudmouse показали, что локализация данных и самого проекта в одном датацентре — гарантированный способ получить многочасовой даунтайм без возможности легко поднять проект на другой площадке. Закон о персональных данных, в этом плане, создает дополнительные проблемы. Мы считаем, что любой облачный хостинг должен пройти через несколько крупных аварий, чтобы научиться их не допускать (молния, ударившая в Amazon, проблемы с сетевой конфигурацией, связанные с человеческим фактором итп.), и если западные облачные хостинги прошли через эту череду катастроф, то многим российским площадкам это еще предстоит, и это надо учитывать.

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

Рекомендуемая AWS схема работы проекта подразумевает использование нескольких availability zones по умолчанию для достижения максимального аптайма проекта.

2. Отсутствие адекватного дублирования на резервной площадке

Итак, мы пришли к банальному выводу о необходимости иметь резервную площадку для достижения максимального uptime’а проекта, однако, для того чтобы на нее переключиться — данные должны быть адекватными продакшен-площадке. Важно здесь не первичное создание резерва — это довольно простая и понятная процедура, гораздо важнее синхронизация и мониторинг синхронизации дальнейших изменений. Прежде всего, мы говорим о:

• Синхронизации конфигурации кластера/данных в кластере, когда мы говорим о сложной площадке
• Синхронизация файловой структуры и мониторинг отставания синхронизации
• Отслеживание изменений в серверной конфигурации
• Отлаженные процессы контроля и добавления в синхронизацию новых проектов/сервисов на площадке.
• Отслеживание добавления новых вторичных сервисов (новые очереди, механизмы обработки и взаимодействия итп).
• Адекватный постоянный мониторинг всех этих процессов.

3. Отсутствие плана переключения и регулярных переключений на резервную площадку

Любой, даже самый хороший мониторинг не может гарантировать что резервная площадка будет готова к переключению, когда это действительно потребуется. По нашему опыту, на первом переключении на резерв обязательно произойдет авария, и так будет происходить еще несколько раз. В своих докладах Stack Overflow рассказывают, что у них ушло около пяти переключений на резерв, до того, как они убедились что теперь он полностью готов принять трафик после аварии. Поэтому в план работ по увеличению uptime’а проекта обязательно надо включить тестовые переключения на резерв, и учесть, что подобные переключения приведут к аварии. После отработки и фиксации в документации механизма переключения — надо и дальше регулярно переключать на резерв, для того, чтобы убедиться что все по-прежнему работает.

4. Локализация резервной площадки на одном и том же канале/в одном и том же регионе облака

Если продакшен и резервная площадки находятся в пределах одной хостинг-компании, то вполне возможно, что в случае аварии перестанут работать сразу обе ваши площадки. Несколько крупных аварий в AWS затрагивало сразу все availability zones одного региона, Selectel падал одновременно датацентрами в Санкт-Петербурге и Москве, компании могут говорить о полной изоляции, но авария cloud4y, которая привела к полной недоступности Битрикс24 говорит о том, что даже в таких случаях существуют большие риски. Идеальной, с нашей точки зрения является конфигурация где одна резервная конфигурация располагается в той же хостинг компании (для использования штатных средств переключения на резерв, таких как VRRP), а вторичная резервная площадка в другой хостинг-компании.

5. Размещение одинаковых версий на основной и резервной площадке.

Даже использование проверяемой резервной площадки и использование вторичной площадки в другом датацентре не гарантирует готовность резерва быстро взять на себя продакшен нагрузку. Связано это с сутью резервирования: новая версия кода, которая создала фатальную нагрузку на продакшен окружение создаст точно такую же нагрузку и на резервной площадке, и проект станет полностью недоступен. В качестве простого решения должен существовать механизм отката на предыдущую версию, однако в гонке бизнеса за релизами это не всегда возможно, и тогда мы начинаем думать об еще одной резервной площадке с предыдущей версией. Отдельно стоит поговорить о резервном копировании: случайное удаление данных на основной площадке отразится и на резервной площадке, поэтому стоит подумать о об отложенной (на 15 минут, на час) репликации, для того чтобы иметь возможность переключиться на базу данных, на которой еще не произошла фатальная операция.

6. Зависимость от внешних сервисов к которым обращается проект.

Но и этого недостаточно. Огромное количество проектов сейчас используют внешние службы для оказания собственных услуг. Большинство использует SMS для двойной аутентификации, интернет-магазины рассчитывают время доставки с помощью сервисов служб доставки, оплата принимается через сторонние payment-gateway-и и если эти сервисы падают, то неважно, есть резервирование или нет, проект все равно будет недоступен. Резервирование внешних сервисов мы встречаем очень редко, а, между тем, это точно такие же проекты, у которых могут быть проблемы с резервной площадкой, или может быть вообще нет резерва. И в случае недоступности внешнего сервиса обслуживание ваших клиентов тоже будет невозможно. Мы рекомендуем дублировать все критичные внешние системы, мониторить их доступность и иметь план на их переключение в случае аварии.

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