Комментарии 12
НЛО прилетело и опубликовало эту надпись здесь
Так простои не считаются, если проект будет недоступен сутки, то думаю, что большая часть клиентов уйдёт навсегда, год никто ждать не будет :) Убыток вполне может быть таким, а может быть и не таким. Возможен вариант, когда проект будет недоступен час и после этого потеря — половина оборота компании, так как уйдут клиенты. Хотя в большинстве случаев таких потерь не будет, если речь о банковских транзакциях — ну заплатит клиент позже, когда шлюз возобновит работу. Однако, если шлюз будет лежать весьма часто, вряд ли кто будет им пользоваться.
Стоимость (убытки от) минуты даунтайма ≠ прибыль от минуты работы системы.
Минута $100K — в год это больше $50 миллиардов. Сдаётся что вы чуть-чуть себе льстите.
В платежной системе — деньги не их, а клиентские. Они всего лишь посредники.
И них собствено выручка платежной системы — какой-нибудь 0,5%
Знался с мелкой местячковой локальной платежной системой — даже у них миллиард оборота запросто набегало.
что делать, когда минута простоя стоит $100000
Не брать горе-айтишников на зп штука баксов/мес?
НЛО прилетело и опубликовало эту надпись здесь
Ох, раскопали выступление полуторогодовой давности…
1. Потом, кровью и опытом:)
Дело в том, что по опыту сбой всегда вызывает резкий взлет показателей, и никогда плавный. При этом потолок взлета не меньше 3х от нормальных показателей. Так что у нас алерты настроены в среднем по больнице на 2 — 2.5х от нормальных показателей.
2. Это проблема тогда, когда мы обращаем внимание на систему в целом. В нашем же случае мы мониторим еще и время работы отдельных компонент — сервисов системы. И если какой-то компонент начал работать медленнее обычного мы это заметим сильно раньше чем это критично скажется на производительности всей системы целиком. При этом отдельный компонент может конечно в теории стать узким местом всей системы, но маленькую часть быстрее масштабировать, быстрее исправлять и дорабатывать, тем более не откатывая коммиты полугодовой давности.
1. Потом, кровью и опытом:)
Дело в том, что по опыту сбой всегда вызывает резкий взлет показателей, и никогда плавный. При этом потолок взлета не меньше 3х от нормальных показателей. Так что у нас алерты настроены в среднем по больнице на 2 — 2.5х от нормальных показателей.
2. Это проблема тогда, когда мы обращаем внимание на систему в целом. В нашем же случае мы мониторим еще и время работы отдельных компонент — сервисов системы. И если какой-то компонент начал работать медленнее обычного мы это заметим сильно раньше чем это критично скажется на производительности всей системы целиком. При этом отдельный компонент может конечно в теории стать узким местом всей системы, но маленькую часть быстрее масштабировать, быстрее исправлять и дорабатывать, тем более не откатывая коммиты полугодовой давности.
НЛО прилетело и опубликовало эту надпись здесь
Извиняюсь за запоздалый ответ.
Измерение настолько гранулярных данных и триггеры на них на наш взгляд неэффективны. У нас используются метрики либо кумулятивные, либо апроксимированные.
Например, мы не смотрим время ответа на каждый запрос пользователя на наших серверах. мы смотрим на сумму времен ответа на все запросы пользователя в каждую секунду. То есть дискретность данной метрики крайне высокая, но за счет того, что она кумулятивна, в ней отсутствует влияние естественных всплесков. Понятно, что представленную в примере метрику бесполезно делать, если у вас условно 1-2 rps на сервера.
Также широко используется стандартная общепринятая практика по мониторингу 95 / 99 персентили, в зависимости от стабильности показателей. Например мониторинг времен проведения одной транзакции (в автоматическом режиме) ведется по 95 персентили. А мониторинг некоторых сервисов, стоящих «за нами» — по 99. В этом случае конечно сложно достичь дискретности в 1 секунду, но на достаточном потоке данных получить дискретность в 15-30 секунд вполне можно
Измерение настолько гранулярных данных и триггеры на них на наш взгляд неэффективны. У нас используются метрики либо кумулятивные, либо апроксимированные.
Например, мы не смотрим время ответа на каждый запрос пользователя на наших серверах. мы смотрим на сумму времен ответа на все запросы пользователя в каждую секунду. То есть дискретность данной метрики крайне высокая, но за счет того, что она кумулятивна, в ней отсутствует влияние естественных всплесков. Понятно, что представленную в примере метрику бесполезно делать, если у вас условно 1-2 rps на сервера.
Также широко используется стандартная общепринятая практика по мониторингу 95 / 99 персентили, в зависимости от стабильности показателей. Например мониторинг времен проведения одной транзакции (в автоматическом режиме) ведется по 95 персентили. А мониторинг некоторых сервисов, стоящих «за нами» — по 99. В этом случае конечно сложно достичь дискретности в 1 секунду, но на достаточном потоке данных получить дискретность в 15-30 секунд вполне можно
что делать, нанимать адвока, он дешевле минуты простоя.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
HighLoad++, Евгений Кузовлев (EcommPay IT): что делать, когда минута простоя стоит $100000