Здравствуйте, chaotic-kotik, Вы писали:

CK>В нашем случае используется black-box мониторинг, который работает отдельно от основной инфраструктуры, в нескольких георграфически удаленных регионах, он делает запросы в API и измеряет время отклика.
Ну вот, то что я предлагаю, вид сбоку.
CK>Если заданное количество агентов не получили ответ от сервиса, или получили, но с превышением таймаута, заданного в SLA, поднимается alert, регистрируется начал инцедента. Когда все агенты снова получили ответ, генерируется новый alert и регистрируется окончание инцидента.
Ну, то есть пока падает меньше выбранного вами процента запросов, вы считаете, что система available.
CK>Есть метрика в графане, которая по этим данным рисует доступность.
CK>Это довольно распространенное решение, datadog и alertra считают availability похожим образом.
То, что вы рассказываете — это попытка получить приближение к "настоящей" формуле availability при отсутствии возможности её прямого измерения.
Когда мы проектируем систему, мы оперируем не black box availability, а предсказываем реальное поведение.
S>>Мне кажется смешным такая вот бескомпромиссная трактовка Availability. Реальные системы запросто жертвуют доступом к части данных, продолжая работать с тем, что есть.
CK>Еще раз, мне интересны распределенные системы в общем и распредленные БД в частности. Мне не очень интересны системы, где можно пожертвовать частью данных, такие как сайты с котиками и онлайн агрегаторы, торгующие авиабилетами. В контектсе баз данных, потеря 1/N данных, при отказе одного из N датацентров — неприемлема.
Нет никакой потери.
CK>Aviasales это агрегатор, поставщик — сторонний вендор, а не часть системы. Хорошим примером ялвяется приложение такси. Представь, что у яндекса накрылся один ДЦ и 1/(количество Дц) клиентов не может использовать сервис, и такая же доля водителей не может принимать и завершать заказы.
Во-первых, не 1/N. А 1/(N в большой степени), потому что тут не "DC накрылся", а произошёл network partition. В итоге клиенты из Новосибирска не могут вызвать такси в Москве. К счастью, таких запросов — 1 на миллион, поэтому почти никто не заметит потери. Нам важно дать возможность клиентам в Нске заказывать машину в Нске, а Москвичам — в Москве. Причины очевидны или надо разжёвывать?
Ну, и конечно же система, которая продолжает принимать заказы из Нска в Москву без гарантии их выполнения (нарушение консистентности) гораздо хуже системы, которая честно говорит "сервис заказа в данном городе временно недоступен, попробуйте позже".
CK>То, о чем ты говоришь, называется graceful service degradation. Хорошая вещь, но в качестве дополнения, а не как единственное поведение в случае проблем.
Речь не о единственности, а о том, какой показатель показывает хорошесть этой вещи. Опять таки, с точки зрения бескомпромиссной availability все эти изобретения бесполезны — они не улучшают измеряемый показатель.
Расскажите, какую именно метрику вы улучшаете при graceful degradation?

CK>Я не могу сделать эти шаги за тебя.
Попробуйте сделать их за себя. Пока что продемонстрировано не больше пользы от CAP, чем от иконы на приборной доске автомобиля.
CK>Попробуй DDIA прочитать более внимательно что-ли.
Я уже почитал. Особенно вдохновляет раздел The Unhelpful CAP Theorem.