Как строить надежные, стабильные и отказоустойчивые IT-системы: главное об SRE и SLO / Comments / Habr

gecube Jun 3 2022 at 17:08

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

Многие системы к которым применяют требования 24/7 или даже 14/6 на самом деле являются такими всего несколько дней в месяц, а в остальное время вполне себе 20/6 или 10/5 (часов в день/дней в неделю

полностью согласен, но в этом случае история с SLA прекрасно масштабируется и делается дифференцированный SLA по различным дням календаря, например. С другой стороны - многие сервисы являются глобальными или являются круглосуточными. Например, сервис такси в Москве (Moscow never sleeps!). Или google mail - у него пользователи по всему миру в разных часовых зонах. И поэтому в этом случае проще говорить именно об унифицированном SLA.

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

это не так. Во-первых, методология SRE вводит понятие бюджета ошибок. То есть того самого времени за некий интервал (скажем, год, месяц...) в течение которого наш сервис может быть недоступен. И мы можем тратить этот бюджет, например, на плановое обслуживание. Как только он закончился - все, привет. Кукуем и ждем пока он восстановится. Таким образом мы с нашими заказчиками поддерживаем тот самый SLA, на который мы договорились. Вторая история заключается в том, что разработка (и клиенты сервиса) хотят по возможности те же бесшовные деплои, когда изменение версии ПО происходит без останова. Да, это инженерно сложнее, чем просто выключить сервер из балансировки, обновить, и ввести заново. Но это как раз и позволяет обеспечивать беспрерывность работы, отсутствие нарушений SLA и дает компании конкурентные преимущества по сравнению с соперниками на рынке (кто умеет быстро и стабильно, бесшовно катить релизы - тот выигрывает в конкурентной гонке и может предоставить клиенту более широкий, более качественный сервис).

Что в конечном итоге и стоимость системы увеличивает и гибкость снижает.

BCP/DR ни чуть не идут в противоречение ни с SRE, ни с SLA/SLO/SLI, а дополняют. И очень здорово, когда отказоустойчивость сервисов уже изначально в них прошита. Потому что потом, когда уже разработка завершена, реализовать эти качества может быть очень дорого (так как потребуется, например, полный пересмотр архитектуры или очень сильно закостылевания изначального кода)

@Anna_sokol22

что-то я подустал от слермовской методики публиковать статьи под чужими именами. Вот как мне включить в дискуссию Ивана и задать ему вопрос? Не понимаю.

В своей практике я встречают с тремя, либо с тремя с половиной девятками. То есть надежностью на 99,9% или 99,95%

Вот вопрос - что такое надежность 99.9% Почему мы ее вообще меряем в процентах. А не в каких других единицах. Что мы будем делать, если у нас отказ “параметрический” (нормальным языком - частичный) ? То есть сервис как бы работает, задачу свою выполняет, но пользователи уже страдают. Или мы хотим определить некий бейзлайн - скажем, 99% от всех запросов должны выполняться в пределах 10 ms и процент ошибок должен быть не больше 5%? И тогда смотреть общее время, по которому уже ЭТА метрика (по сути как раз SLI) и была в указанных интервалах? А что делать с теми сервисами, которые не HTTP? Например, обработка очередей? При чем это еще более менее понятный сценарий (есть методология выявления золотых сигналов для очередей - количество сообщений, лаг времени в обработке и пр) Еще разговор будет абсолютно неполным без рассказа о методиках RED/USE, потому что невозможно измерить то, что мы не определили, а объект и параметры наблюдения еще нужно правильно определить. В этом аспекте мне нравится подходы, описанные у https://www.brendangregg.com

Для SRE очень важно SLO — конкретные измеримые характеристики доступности системы.

неточность в статье. Характеристики, простым языком - это SLI. То есть метрики и индикаторы. SLO - это то целевое значение, которое мы хотим получить. А SLA - это уже договоренность между поставщиками и потребителями сервиса, которое включает это самый SLO и действия и санкции в случае его нарушения.