AZ
если мы про опсовые вещи говорим
Size: a a a
2020 February 25
AZ
все же читали, я бы начал с того чтобы адресовать текущие проблемы используя эти знания
AS
SLA это это контракт между потребителем и сервисом. Ваш сервис должен гарантировать потребителю некие обещания. Например что 99.9 перцентиль ответов будет не выше 20 миллисекунд. Потребителем может быть как внешний клиент так и внутренний. Например если у вас веб сервер обращается к микросервису то он чтоб иметь возможность давать свой SLA должен учитывать SLA микросервиса. В контексте ETL SLA можно вводить между каждым шагом. Например БД дает ответ за столько то секунд. процессинг переваривает его с гарантией не менее XXX мегабайт в секунду, В итоге мы можем гарантировать что весь пайплайн отработает с гарантированной скоростью (для определенного перцентиля) для определенного количества данных.
AS
А вот как это для бизнеса выглядит
AS
SLA это это контракт между потребителем и сервисом. Ваш сервис должен гарантировать потребителю некие обещания. Например что 99.9 перцентиль ответов будет не выше 20 миллисекунд. Потребителем может быть как внешний клиент так и внутренний. Например если у вас веб сервер обращается к микросервису то он чтоб иметь возможность давать свой SLA должен учитывать SLA микросервиса. В контексте ETL SLA можно вводить между каждым шагом. Например БД дает ответ за столько то секунд. процессинг переваривает его с гарантией не менее XXX мегабайт в секунду, В итоге мы можем гарантировать что весь пайплайн отработает с гарантированной скоростью (для определенного перцентиля) для определенного количества данных.
В итоге для менеджмента появляется возможность завести матрицу рисков и т.п.
A
@anton_shelin да, но первоначально кто выставляет требования?
бизнес или разработчики
они то всегда могут сказать “в течении месяца данные скорее всего доедут”
у меня обычно было со стороны бизнеса “данные должны быть доступны не позднее ….”
и дальше в зависимости от этого иногда приходилось выторговывать чуть больше времени, иногда мы сами декларировали что можем предоставить заметно раньше и соблюдать данное обещание
бизнес или разработчики
они то всегда могут сказать “в течении месяца данные скорее всего доедут”
у меня обычно было со стороны бизнеса “данные должны быть доступны не позднее ….”
и дальше в зависимости от этого иногда приходилось выторговывать чуть больше времени, иногда мы сами декларировали что можем предоставить заметно раньше и соблюдать данное обещание
AS
@anton_shelin да, но первоначально кто выставляет требования?
бизнес или разработчики
они то всегда могут сказать “в течении месяца данные скорее всего доедут”
у меня обычно было со стороны бизнеса “данные должны быть доступны не позднее ….”
и дальше в зависимости от этого иногда приходилось выторговывать чуть больше времени, иногда мы сами декларировали что можем предоставить заметно раньше и соблюдать данное обещание
бизнес или разработчики
они то всегда могут сказать “в течении месяца данные скорее всего доедут”
у меня обычно было со стороны бизнеса “данные должны быть доступны не позднее ….”
и дальше в зависимости от этого иногда приходилось выторговывать чуть больше времени, иногда мы сами декларировали что можем предоставить заметно раньше и соблюдать данное обещание
надо разделять время разработки системы или пайплайна нового и собственно гарантии его работы
AS
SLA относятся скорее к управлению рисками работы пайплайна а вы говорите о времени разработки
AS
соответственно и методы нужны другие
UD
sla,sli,slo
UD
И выше было отличное предложение про специальных людей от бизнеса
AS
И выше было отличное предложение про специальных людей от бизнеса
Заказ всегда идет от клиента а не от бизнеса в вакууме
AS
Если надо уовлетворить клиента мы должны расчитать как определенный sla гарантировать
AS
Для этого менеджеры вместе с разрабами и де и опсами выясняют компоненты с sla на каждом шаге
UD
"Клиент" не хочет строить ядерную электростанцию, ему например достаточно ветряка
AS
Также идет учет затрат чтобы это было выгодно и рост нагрузки
A
чаще клиент хочет электричество или чтобы кофеварка работала =)
UD
Классика жанра, n кластеров, дц дорого
UD
Не роняйте один существующий
AS
Есть небольшая книжка в которой это поверхностно рассматривается. Architecting for Scale: High Availability for Your Growing Applications Там и про риски и про расчет вероятностей и выбор количества дублирующих компонент и т.п.