Comments 28
Если в системе есть параллельная фолбэк‑логика для дублирования элементов (быстро поставить задачу в очередь не получилось — сходи напрямую в сервис; в кеше нет данных — выбери их из БД), формула другая:
Rсистемы = 1 − (1 − R1) × (1 − R2) × … × (1 − Rn)
Это верно, если надежность этой "фолбэк‑логики" равна единице. В противном случае, все сложнее.
Тут вы абсолютно правы, я раскрываю эту мысль в детальном примере с фолбеками:
У такого переключателя тоже будет своя надёжность. А формула надёжности станет произведением надёжности механизма фолбэков на надёжность параллельно соединённых элементов.
И в примере до этого с кэшем тоже описана проблема того, что, кроме надёжности самого внешнего кэша, есть ещё и логика, которая его наливает и инвалидирует.
Но глобально даже заглушку нельзя считать на 100% надёжной потому что это код, который подвержен ошибкам.
Вообще надёжность и доступность(готовность) - это две разные метрики.
Если хочется углубиться в математику надёжности, то можно начать, например, со стандарта.
Всё верно, тут речь скорее про индикаторы availability, которые тоже можно определить по-разному в зависти от того, что мы вообще хотим называть доступностью, я про это даже сделал продолжение в виде доклада “Математика SLO” — потому что доступность как раз с ним сильно связана. Думаю, что скоро получу запись.
Но стоит признать, что в литературе по теме определение надежности из статьи (и похожие определения вокруг вероятности безотказной работы) часто встречаются в количественных показателях надёжности, или вовсе отождествляются ей.
Тут хотелось именно показать из чего складывается эта цифра доли отказов, что на неё влияет и как это можно оценить.
Тут ещё нюанс в том, что вы рассматриваете только надёжность программной компоненты, а она лишена ряда компонентов, характерных для железа, как-то характеристик ремонтопригодности, логистической доступности и т.п.
Хотя если считать в целом аппаратно-программный комплекс, то часто всё упирается именно в логистику ремонтов.
С инфрой вообще всё интересно и многогранно, там можно и компоненты копать, и конфигурацию внутри ДЦ, а потом оказывается, что нам важна связность между ДЦ, каналы, а там могут быть спецэффекты в виде шумных соседей, которые заливают канал. И это только небольшой кусок, виртуализация тоже влияет.
И тут, с одной стороны, важно разделить уровни и зоны ответственности, я поэтому явно и говорю, что формулы на самом деле работают для независимых компонент, которыми сервисы не являются (а сам доклад сделан в backend секции). А с другой (и про это отчасти пункт о изменениях в платформе) — что мы можем или учитывать или влиять на эти «не наши» уровни. Делать load shedding, local-dc и прочие политики маршрутизации, делать системы, которые не боятся вылета шарда и все эти стандартные уже продуманные вещи для устойчивости.
Вообще надёжность и доступность(готовность) - это две разные метрики.
Если хочется углубиться в математику надёжности, то можно начать, например, со стандарта.
Кстати, страница по ссылке у меня не открывается. Могу предложить, что сайт предельно надёжен, но у них есть региональные ограничения. Так что да, надёжность и доступность это разные вещи.
Привет. Рассказывал про доклад про метрики доступности, вышла запись, поэтому доношу сюда в комменты.
Про аппаратную часть, сетевую инфраструктуру и комплексность замечания всё ещё в ней не рассмотрены, но про это я уже ниже писал ответ про уровни абстракции и зоны ответственности :)
Есть ещё вариант разделить функции сервиса на критичные и не очень, и резерв (переход на него не вручную, а по событию) строить не как 100% копию, а 75%-ю например.
А без микросервисов проблем было бы гораздо меньше
Всё что выходит в сеть умрёт много раз. Я разрабатывал и сопровождал геораспределенную инфо систему, так в логах было 10.000 сетевых сбоев за год типа отказ сети при SQL запросе или web api. Ошибок бизнес логики было гораздо меньше. Очень трудно достичь надёжности в такой системе. А требования к надёжности были высокие.
Интересно, а Яндекс своим клиентам платит штрафы за отказы и сбои при их обслуживания? Имеется ли такой показатель, как чёрн? Иначе все эти разговоры про надёжность - чисто пиар)
есть вопрос. Вот вы тут пишете
Так считаются SLI/SLO, и именно на основе этих цифр нужно принимать решения. Если сервис не соблюдает SLO из‑за ненадёжных зависимостей, то это хороший индикатор того, что стоит сходить к коллегам и поработать над решением вместе.
Что в этом контексте "сервис"? Равно микросервис?
В концепции SLO "service" имеет более широкое определение и перевод на русский будет "услуга". Услуга – это то как ее видит пользователь, например, услуга "подбор товара" для пользователя интернет-магазина будет комбинацией из: на сайте работает поиск + открываются страницы товара + можно добавить в корзину. Поиск, страница товара, корзина - под капотом это могут быть 3 или больше микросервисов.
Это крутой вопрос, я постараюсь ответить компактно.
Когда я писал этот текст, то представлял себе именно сервис в понимании разработчика — потому что это обычно тот уровень абстракции, с которыми чаще всего взаимодействуют команды разработки.
Здесь же вся статья про модель, то есть упрощение. И мне кажется, что будет хорошо применять это упрощение так, как удобно для наилучшего результата. Мне модель с "услугой" кажется удобной с точки зрения клиентского SLA, но избыточно высокоуровневой для применения при взаимодействии команд разработки. Но "сервис" это тоже не совсем удобная единица работы — потому что чаще всего недоступность сервиса != недоступности какого-то сценария. И в этом плане я бы скорее говорил не в терминах услуг, а в отдельных "функциональностях" — поиск, страница товара, корзина. Так будет достаточно детализированно чтобы локализовать проблему и определить действия. Такие подсчёты требуют дополнительной разметки или дополнительных индикаторов, и разметка по функциональности (связь между функциональностью и метриками + их связь на домены и сервисы) требует дополнительных усилий. То есть, это хорошо, но довольно дорого. Поэтому в базовом варианте можно смотреть именно на сервис. но стремиться к функциональностям.
Такую разметку функциональности может хорошо помочь сделать DOMA — в ней как раз деление по доменам проходит часто по функциональности и у каждого домена есть свои специфичные метрики, которые и будут доступностью этой функциональности.
У меня на практике так и выходит, часть удается покрывать по сценарию, а часть по сервису. Прикол в том, что иногда тебе от сервиса важна работа одной из 3 ручек, а остальные могут криво работать из-за багованого релиза, но клиентам и бизнесу это будет мало важно.
Но в части сервисов это не всегда возможно технически. Типа Single Page App, в котором есть graceful degradation и потому у тебя на одну страницу приходит 3-5 запросов и даже если 4 из них умрут, основной контент доедет. Тут тяжело даже просто вот это самое ядро отделить.
Про "функциональности" что ты называешь хорошо перекликается с Operation-based SLO от Zalando - они так смотрят https://engineering.zalando.com/posts/2022/04/operation-based-slos.html. Но кажется в их подходе все равно недосказано про сценарии, где-то же должно быть записано, что если сломался поиск - это знчать покупать в магазине не смогут. Хотя это все можно и в голове подержать в головах команды отвечающей за этот этап сценария.
Про DOMA надо посмотреть.
плюсанул бы да кармы нет. Микросервисный и cloud-based подход лепят везде и всюду усложняя инфраструктуру и добавляя себе гемора.
Вместо обычного подхода, накидали сервисы с разумной детализацией, закинули на сервак(виртуалку), подняли несколько инстансов в разных ДЦ и погнали.
Но нет же для простых сервисов, возьмут куберы, контейнеры, прокси, балансеры, облачные базы, и вроде все должно работать но все равно летят ошибки из-за инфраструктуры, в 70% проектов вообще нафиг не нужен этот cloud-based подход.
Да и потом для масштабирования в реальном времени из-за нагрузки, такого куска можно применить cloud-based подход.
Более того есть бизнес процессы, которые в принципе масштабируются сложнее из-за длинных цепочек и мест синхронизаций
...пока мы уменьшаем MTTR/MTTRC, продуктовые команды занимаются надёжностью сервисов.
Есть мнение и исследование, что Mean метрики в том числе MTTR для сложных систем не подходят и пытаются упростить, то что является сложным по природе https://www.verica.io/blog/mttr-is-a-misleading-metric-now-what/
Также есть исследование, показывающее, что даже не внося изменений для улучшения MTT* метрик вы можете увидеть их улучшение https://static.googleusercontent.com/media/sre.google/en//static/pdf/IncidentMeticsInSre.pdf
Да, это довольно обсуждаемые в последнее время статьи, про них стоит говорить отдельно. Идея того, что ЦПТ не всегда хорошо — хорошая. Среднее нам действительно не важно. И фактически в примере с устойчивостью и временем восстановления вы чаще всего будете видеть большую дисперсию и скопление большинства точек "слева". Правильнее тут говорить про процентили (то есть, избавление от длинного хвоста). И качественные исследования хорошо делать как раз на выбросах. А ещё про waste при координации у меня есть вот такой доклад, который как раз про "Hidden Costs of Coordination" из статьи.
Вообще, этот и предыдущий ваш комментарий хорошо ложатся в близкую тему про то, как быть с SLO, и про эти статьи, и про посервисность, и про работу с зависимостями, которые влияют на доступность, я встречал хорошие обсуждения в телеге в ALLSLO - все про SLO (из SRE) — там довольно концентрированно именно об SLO обычно.
Немного теории. Есть много определений, но в самом близком к IT‑миру надёжность, или , — это вероятность того, что система на протяжении заданного интервала времени будет выполнять свои функции без отказов. Проще думать и считать её так: надёжность — доля безотказной работы за весь период времени. И переводят её в термины девяток:
Не нашел тут ключевого слова «коэффициент готовности». Эта статья точно про классическую теорию надежности?
Повышаем надёжность
Придумано всего два метода повышения надежности системы: использование более надежных элементов и резервирование элементов. По секрету скажу третий метод: надежность любой системы можно резко повысить – лишь скорректировав критерий ее отказа (тег: юмор).
Надёжность системы считается по формуле для параллельно соединённых элементов и складывается из надёжности исходного сервиса, который может отказать, и надёжности кеша:
Реальные системы так не считают. Это уровень школы.
Реальные системы описываются марковскими цепями (графами, ссылка на ГОСТ уже была в коментах) и далее решение системы уравнений.
Более того, отказоустойчивые конфигурации (резервирование) – сложная штука и нормальный расчет (коэффициент готовности) реального отказоустойчивого сервера (например, кластера) еще не встречал (у кого есть – покажите). Там должен быть как минимум параметр «вероятность отказа, не обнаруженного внутренней системой контроля», т.к. идеальных систем нет.
Надежность ПО. Вообще не понял, как Вы оцениваете (считаете) надежность ПО. Это отдельная сложная тема, т.е. к надежности железа нужно добавить еще надежность ПО (всего, включая ОС).
Не нашел тут ключевого слова «коэффициент готовности».
Постарался показать пример с коэффициентом готовности как раз на примере с теневой репликой, но в остальном, конечно, эта часть тут довольно сильно обрезана. У меня есть немного расширенная версия в виде задачи, где можно как раз это пощупать руками и обжечься. С вот таким примером, где сервис A зависит от данных из двух других сервисов, поэтому может работать, но не быть в работоспособном состоянии :)
Реальные системы описываются марковскими цепями (графами, ссылка на ГОСТ уже была в коментах) и далее решение системы уравнений.
Вообще да, но когда дело доходит до систем, где есть хотя бы несколько сотен сервисов и столько же БД, всё это над несколькими уровнями инфраструктуры и с зависимыми элементами, то все переходы между состояниями обычно становится нереалистично описать, а считать это целиком может быть избыточно.
Я именно поэтому постарался сделать дисклеймер о том, что эта модель не точно отражает реальность. Но она может подсвечивать критичные места в достаточной степени для принятия решений.
Да даже на малой модели граф переходов замучаешься описывать. И не стоит забывать, что любое изменение зависимостей влечет его перестройку.
На самом деле во многих ит системах не нужна прям точная оценка, так как собственно и не вся система по факту для нас критически важна. Важно уловить тренд - становится ли хуже, а способы этого могут быть разные, хоть количество жалоб от бабушек у подъезда (наблюдал такой SLI на почтальонов кто пенсию разносит :) )
Важно уловить тренд - становится ли хуже, а способы этого могут быть разные, хоть количество жалоб от бабушек у подъезда (наблюдал такой SLI на почтальонов кто пенсию разносит :) )
Как раз без точной модели этот тренд иногда обманчив. Например, в высоконадежных системах (пять девяток, только не "дутых", а реальных) часто добавление нового резервного узла снижает общий показатель готовности системы, как бы это не казалось странным.
... точно ли важно знать цвет машины и показывать пользователю ошибку, если сервис, извлекающий цвет из хранилища данных об авто, недоступен?
Пожалуйста, скажите мне кто-нибудь, что отдельный микросервис ради цвета машины — это лишь художественное преувеличение.
Не лучше ли показать машину без цвета?
Думаю, что в реальности, всё же, этот сервис отвечает не только за цвет, но и за остальные данные о машине. Имеет ли смысл показывать пользователю машину без цвета, модели и регистрационного номера? Имхо, далеко не всегда.
О, правильные и действительно безопасные деградации — это отдельная весёлая тема. Они чаще всего опираются на конкретный домен, так что мне сложно будет привести хорошие примеры. Если с цветом машины решение несложное, то есть ситуации, когда действительно сложно подобрать правильный способ замены. Как пользователь я бы скорее хотел чтобы марка-номер не отображались, но машина приехала, мы там в чате или по телефону договоримся. Но у меня есть ещё пару любимых из личного опыта.
Доставки-агрегаторы из магазинов часто не могут хорошо синхронизироваться по наличию товара с магазинами, а если и могут, то это очень ненадёжная синхронизация. И решили проблему довольно просто — заказывай, что хочешь, сборщик тебе позвонит и уточнит детали, или по галочке выберет аналог.
Не совсем деградация, но некоторый компромисс в ситуации, когда на складе у тебя 100 товаров, а пользователи за 1 секунду заказывают 500. Ситуация выглядит нереалистично, но вот рассказ про что-то подобное.
Цвет машины — не обязательно сервис. Это может метод внутри крупного сервиса, который умеет фейлится, и вопрос выбора фоллбека — это то, как обрабатывать ошибку вызова этого метода. Тут уровень абстракции у каждого свой.
Математика надёжности. Доклад Яндекса