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