Мы - небольшой стартап, пытающийся угодить нашему первому покупателю. На данный момент вся настройка ч / б находится в облаке Amazon (в ближайшее время будет перемещена в VPC). Я должен дать клиенту оценку того, какую гарантию безотказной работы может предложить моя компания. Хотя Amazon предлагает меньше «99,95%, но равно или больше 99,0%», я думаю, что имеет смысл учесть обновления моих приложений, установку исправлений и другие действия по техническому обслуживанию с моей стороны и пойти с гораздо меньшей оценкой, скажем, 95%. .
Я думаю, что мой вопрос в более общем смысле касается того, что является более безопасным обязательством для стартапа, работающего со своим первым клиентом, с точки зрения SLA. Будет ли что-то вроде 90-95% приемлемо для моего клиента (который является компанией с миллиардным доходом, и они платят нам за транзакцию), считая, что мы не являемся зрелой компанией в этой сфере?
90% -95% SLA бесполезно, лучше не говорить об этом (даже старый виртуальный хостинг гарантирует лучшее SLA для вашего веб-приложения), вам нужно как минимум 99,5% для серьезного бизнеса. Если вам нужно лучшее SLA (а ваши клиенты будут!), Вам необходимо иметь зеркальные ресурсы (2 сервера приложений, 2 сервера баз данных и т. Д.), Настроить балансировку нагрузки и аварийное переключение (например, keepalived, haproxy, squid и т. Д.), Настроить хорошие внутренние и внешние решение для мониторинга и оповещения (что-то вроде Zabbix или Nagios, newrelic и Logstash / Kibana для управления журналами), и вам понадобятся системные администраторы, которые будут управлять им, отслеживать и реагировать на проблемы.
Вы должны посмотреть таблица SLA в Википедии и там вы можете узнать, как долго ваше приложение может находиться в автономном режиме для вашего уровня SLA. Не забывайте, что отключение может произойти и произойдет, когда вы не можете немедленно отреагировать (например, в 3 часа ночи), поэтому вам нужно иметь достаточно большую команду администраторов, чтобы обеспечить круглосуточную поддержку. Вы должны найти и идентифицировать все SPOF и устранить их. Не забывайте, что не только ваши разработчики являются источником потенциальных проблем, но и ваши серверы будут подвергаться различным типам автоматических атак с первой минуты (ssh-боты, DDoS и т. Д.)
Иметь хорошую и стабильную среду действительно сложно, очень, очень дорого, а когда вы работаете в облаке, это еще дороже (из-за влияния других пользователей облака).
Вы можете найти примеры того, как ваша среда должна искать простую веб-страницу для обеспечения высокой доступности на aws, предоставленную самой Amazon здесь (pdf) или более в Центр архитектуры AWS.
И последнее, но не менее важное: никогда не стоит забывать об удвоении ресурсов! Если у вас есть только одна виртуальная машина одного типа, вы не можете ничего гарантировать. И вторая часть - вам (или вашим администраторам) необходимо подготовить планы аварийного восстановления и проводить регулярные «пожарные учения», чтобы убедиться, что планы актуальны и работают хорошо.
Этот вопрос, вероятно, скоро закроется как «слишком расплывчатый».
С помощью AWS вы можете создать решение с высокой доступностью или предоставить решение с низкой надежностью. Любой отдельный виртуальный сервер, вероятно, достаточно надежен, 99,9% или лучше, но программное обеспечение, которое вы запускаете на нем, и выполняемый вами мониторинг, вероятно, будут ограничивающим фактором. Однако отдельную машину нельзя назвать «высокой доступностью».
Вы можете использовать ELB, географическую балансировку нагрузки, зеркальные базы данных и серверы, а также множество других методов для повышения надежности. Человеческая ошибка или недосмотр, вероятно, снова станут ограничивающим фактором.
AWS имеет архитектурный центр это поможет вам создать решение с высокой доступностью. Использование программного обеспечения, разделенного на несколько зоны доступности является ключевым - зона доступности фактически является центром обработки данных с очень высокоскоростными связями с другими центрами обработки данных AWS в регионе. Например, Amazon RDS (служба реляционной базы данных) может сделать одну и ту же базу данных доступной в нескольких зонах доступности, и вы можете запустить несколько вычислительных экземпляров за балансировщиком нагрузки, поэтому, если что-то пойдет не так, у вас все равно должно быть рабочее приложение. В архитектурном центре есть для вас образцы шаблонов приложений. Я сертифицированный архитектор решений AWS (младший уровень), я изучал AWS, используя бесплатные онлайн-ресурсы - там есть масса доступной информации.
Расщепление в разных регионах сложнее, поскольку регионы фактически независимы, но, вероятно, потребуется, если вам нужна сверхвысокая доступность. Обычно это делается с помощью возможностей DNS маршрута 53, используя маршрутизация на основе задержки. Разделение по зонам доступности подходит для большинства приложений.
Но, если вам нужно число, я предлагаю вам сказать 98%. Это действительно низкая доступность, но если вы даже не знаете, как подойти к решению этой проблемы, это может быть все, что вы можете достичь.