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