Комментарии 16
При этом важно понимать, что вы никогда не получаете доступ к инженерной команде, чаще всего вас останавливает первая линия поддержки, которая ведет с вами переписку, пока настоящие инженеры пытаются исправить ситуацию. Знакомый сценарий?

Именно потому в процессе миграции из дата-центра на AWS. Это дороже, но не будет траты время на общение с тупицами из поддержки.

Aws норм если прям в нем самому делать резервы дублируя мощности. А если там один сервер… У них поддержка не сахар, могут день отвечать.

SLA — это всегда очень забавно, особенно когда случается критический факап и нужно исполнение этого самого SLA.
У одной крупной компании стоит цифра в 2 часа по критическим инцидентам и мне было очень интересно, как они обеспечивают поддержку многослойного пирога из железа, ОС, прикладного софта и своих доработок, оказалось — нужно было читать мелкий шрифт, SLA этот распространяется на время ответа поддержки ( даже если это будет "ваш звонок очень важен для нас мы работаем над вашей проблемой"), а время решения проблемы никто не лимитирует, если копнуть глубже — решения проблемы тоже не гарантируется (если вы попадёте в десяток клиентов, у которых всплыл конкретный баг из сотен тысяч по всему миру, правило 80/20 никто не отменял)
PS как-то раз, в процессе общения с поддержкой по критичной проблеме (SLA 2 часа), инженер пропал на 5 суток — а здесь всё горит, все горят и уровень хаоса становится всё больше, а потом как ни в чём не бывало появился и сказал, что он на религиозный праздник уезжал и забыл предупредить. После истерики «что за… это было?», инженера того уволили и отправили дальше молиться святой корове, поправили внутренние регламенты и сейчас стало лучше, но в SLA я полностью перестал верить.
Ну Вы нашли, во что верить — в SLA!
Если уж так критичен простой, то нужно отдельный договор заключать с провайдером услуг, там все прописывать, а не надеяться на «авось».
Даже если детально прописать SLA и его согласуют юристы с 2 сторон ( та ещё задача) — всё равно нужно иметь план Б на случай факапа.
Или закладывать сутки недоступности системы/переключение на резерв, не смотря на наличие / отсутствие SLA и всего того, что там прописано.
План Б — это прям азы для любого архитектора инфраструктуры.
SLA согласованный юристами — это уже другое дело, совсем другое отношение у компании к его соблюдению.
Это база, про которую, наравне с хранением свежиих бэкапов на отдельной площадке, многие почему-то забывают, иначе не было бы столько паники по поводу потерь данных и диких убытков из-за проблем с облаками.
Единицы даже очень серьёзных учреждений проводили тренировки по переключению на резерв с таймингом действий.
И все, кто пробовал — совершали много чудных открытий.
Наиболее часто встречал хардкод адресов в ETL процессах — когда нужно быстро переключиться на резезрв, оказывается, что взять и поменять в 500+ потоках по 50 fqdn для каждой операции (и потом откатиться обратно после восстановления прода) или пересобрать несколько .jar со всеми параметрами и разлить его всем клиентам — задача на неделю минимум и проще поднять упавший прод, чем использовать резерв как резерв.
При показателях от 98% и выше, любое падение — событие на грани статистической погрешности.

Автор что-то путает. 98% uptime означает, что незапланированный простой за год работы может составить более 7(СЕМИ) дней!

Рабочее оборудование и коннект либо есть, либо их нет.

То есть вариант того, что оборудование или коннект работает не стабильно не рассматривается?

Вы можете годами пользоваться хостером с показателем «надежности» в 50% (согласно его же SLA) без единой проблемы или «падать» раз в месяц на пару дней у ребят, где заявлено 99,99%.

SLA регламентирует, что клиент получает в случае простоя, а не гарантирует, что-то. Обычно ожидаемый uptime рассчитывается по прошлому периоду, но не совсем честные организации могут писать недостоверные цифры, а по SLA компенсировать какую-то незначительную долю ежемесячного платежа.

Если ваша проблема возникла по причине третьей стороны (на магистрали), то вроде как «никто не виноват» и когда решится проблема — вопрос вашей удачливости.

SLA — это все же добровольные намерения компании, она может вполне прописать, что действия 3-х лиц не покрываются SLA. Но на этот счет есть суд, через него вполне можно взыскать уплаченное за период простоя, а иногда и убытки, если удастся их доказать.

Например, при необходимости распределенной инфраструктуры (часть серверов в РФ, вторая — в ЕС), проще и выгоднее будет воспользоваться услугами хостеров, имеющих партнерские отношения с европейскими ДЦ по модели White Label.

Какой-то странный совет, какая разница, связан ли хостер в РФ с хостером ЕС или нет? Партнерские отношения ни к чему не обязывают и ничего не гарантируют.
То есть вариант того, что оборудование или коннект работает не стабильно не рассматривается?

У большинства в так называемом SLA именно так и написано «работает/не работает», а деградации это что то абстрактное за гранью реальности.

SLA — это все же добровольные намерения компании, она может вполне прописать, что действия 3-х лиц не покрываются SLA. Но на этот счет есть суд, через него вполне можно взыскать уплаченное за период простоя, а иногда и убытки, если удастся их доказать.

Суд, взыскание и пр. — это не про РФ
Полностью поддерживаю все выше сказанное! Сам работал тем самым инженером до которого не добраться.
SLA — это не про технику.
SLA — это про бизнес.
Что вы и ваш поставщик услуг будете делать, если качество услуги упадет.
Очевидно, никто не может гарантировать что качество всегда будет нужного уровня. SLA регулирует, а сколько будет стоить для поставщика его факап.
Вот и белое превратили в чёрное. Рекомендация всем PM и CTO, никогда не подписывать договора без SLA, и при подписании смотреть что это за SLA, если 99.9%, то за какой период, так как возможный простой 8 часов в год или 15 минуты в сутки — как правило, большая разница для конечного пользователя. Да, SLA это про договор, а не про технологии, у хороших компаний фактический SLA сильно выше заявленного, но если SLA вообще нет или он слишком мягкий — значит провайдер сам не уверен в стабильности своих услуг и заранее пытается снять ответственность, сигнал насторожиться.
Помнится, когда у нас в организации вводили внутренний SLA — пытались описать время устранения сбоя вместо гарантированного времени доступности.
А начальник службы поддержки мне как согласующему выносил мозг, что «во всех организациях так» только ты от нас чего-то требуешь
скорее всего, за первые четыре часа простоя вы вообще ничего предъявить не сможете, хотя некоторые хостеры начинают пересчет тарифа (выплату компенсации) с момента падения.
При этом крупным клиентам, по факту, вообще плевать на компенсации в рамках SLA. «Компенсация по SLA» — это возврат денег в рамках тарифа пропорционально простою оборудования, которая никогда не покроет даже 1% потенциальных денежных и репутационных потерь. В этом случае клиенту намного важнее, чтобы неполадки были устранены в кратчайшие сроки, нежели какой-то там «пересчет тарифа».
На хостера надейся, а сам не плошай.

Если аптайм сайта критичен, а сайт высоконагруженный, то размещаем два-три (или больше, сколько фантазия и бюджет позволяют) физических или виртуальных сервера в разных ЦОДах (разные владельцы ЦОДов, разные аплинки, разные юрисдикции). На каждом сервере ставим Linux, Nginx и BIND, а при необходимости что-то ещё (например, почтовый сервер; в этом случае в MX-записях указываем разный приоритет); настраиваем nftables, открываем необходимые порты (53, 80, 443, при необходимости другие). Все сервера имён делаем authoritative для доменного имени, при внесении изменений они вносятся на всех серверах имён сразу; для A и AAAA-записей указываем очень низкий TTL (скажем, одна минута). Если один сервер становится недоступен, удаляем указывающие на него A и AAAA-записи (NS-записи и указывающие на сервера имён A и AAAA-записи не трогаем); когда он вновь становится доступен, возвращаем A и AAAA-записи на место.

Если аптайм важен, но смысла в зеркалах нет (или бюджет не позволяет), то находим VPS-хостера, позволяющего держать снимок (snapshot) виртуального сервера без самого́ виртуального сервера и платить только за занимаемое снимком место (знаю одного такого хостера), создаём там VPS, ставим Linux и Nginx (BIND не надо), размещаем временное зеркало, останавливаем VPS, делаем снимок, удаляем VPS. Берём в двух-трёх местах дешёвые VPS, ставим Linux и BIND, настраиваем сервера имён для доменного имени (обязательно с низким TTL), открываем 53 порт, делаем эти сервера имён authoritative. Если основной сервер уходит в даун, разворачиваем из снимка временное зеркало и меняем A и AAAA-записи; когда основной сервер снова доступен, меняем обратно A и AAAA-записи и через некоторое время удаляем временное зеркало.

Да, ещё можно использовать CDN (например, Cloudflare или Imperva). В этом случае не надо будет указывать низкий TTL и администрировать свои сервера имён, но сама CDN может стать точкой отказа.
Верх идиотии — это не саммонить юриста для вписки миллионных штрафов в SLA за простой критической для вашего бизнеса инфраструктуры после определённого срока.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
miran.ru
Численность
51–100 человек
Дата регистрации

Блог на Хабре