Size: a a a

SPb Reliability Meetup

2019 October 28

MK

Max Krylov in SPb Reliability Meetup
мб за пол-года разгребусь
источник

SM

Serg Martynov in SPb Reliability Meetup
Давайте вернемся ко времени реакции на инцидент - "Шеф, у нас все упало!!!", время действия вечер субботы, круглосуточной поддержки на проекте нет ))
источник

AS

Aleksey Shirokikh in SPb Reliability Meetup
Etki
тут хвастаются захламленностью зоны собственной ответственности?
тоже удивился
источник

MK

Max Krylov in SPb Reliability Meetup
Serg Martynov
Давайте вернемся ко времени реакции на инцидент - "Шеф, у нас все упало!!!", время действия вечер субботы, круглосуточной поддержки на проекте нет ))
быстро поднятое не считается упавшим
источник

MK

Max Krylov in SPb Reliability Meetup
утром в субботу такое было - у парней auth юзерского кабинета отвалился, через пол часа передеплоили - заработало. хз чо эт было
источник

AS

Aleksey Shirokikh in SPb Reliability Meetup
Serg Martynov
Давайте вернемся ко времени реакции на инцидент - "Шеф, у нас все упало!!!", время действия вечер субботы, круглосуточной поддержки на проекте нет ))
по приоритетам. на высокий приоритет реакция инженера должна последоватеть немедленно.
сколько до починки зависит от умелости инженера
источник

MK

Max Krylov in SPb Reliability Meetup
Aleksey Shirokikh
по приоритетам. на высокий приоритет реакция инженера должна последоватеть немедленно.
сколько до починки зависит от умелости инженера
плюсую
источник

AS

Aleksey Shirokikh in SPb Reliability Meetup
sla на починку глупость несуственая.
источник

AS

Aleksey Shirokikh in SPb Reliability Meetup
однако это время можно и нужно измерять и стремится к его уменьшению
источник

AS

Aleksey Shirokikh in SPb Reliability Meetup
для достижения менее чем 5 минут нужно что бы код отрабатывал сбои сам.
источник

MK

Max Krylov in SPb Reliability Meetup
если заметной деградации для пользователя не наступает и потерь бизнесс критикал данных нет, то и пару часов можно повозиться)
источник

MK

Max Krylov in SPb Reliability Meetup
*чтоб исключить/минимизировать вероятность повтора
источник

SM

Serg Martynov in SPb Reliability Meetup
Aleksey Shirokikh
по приоритетам. на высокий приоритет реакция инженера должна последоватеть немедленно.
сколько до починки зависит от умелости инженера
Не, я не про время починки, соглашусь с тобой, что это глупо измерять.
источник

AS

Aleksey Shirokikh in SPb Reliability Meetup
Serg Martynov
Не, я не про время починки, соглашусь с тобой, что это глупо измерять.
время починки измерять не глупо. глупо его нормировать
источник

SM

Serg Martynov in SPb Reliability Meetup
А вот как раз, сколько должно пройти времени, когда есть триггер и инженер приступил к решению вопроса. Понятно, что самый выгодный вариант - незамедлительно, но у нас нет круглосуточной поддержки, и человек может быть в это время в дороге.
источник

SM

Serg Martynov in SPb Reliability Meetup
Aleksey Shirokikh
время починки измерять не глупо. глупо его нормировать
Я это и хотел сказать, спасибо ))
источник

AS

Aleksey Shirokikh in SPb Reliability Meetup
Serg Martynov
А вот как раз, сколько должно пройти времени, когда есть триггер и инженер приступил к решению вопроса. Понятно, что самый выгодный вариант - незамедлительно, но у нас нет круглосуточной поддержки, и человек может быть в это время в дороге.
мы меряем время до ack. если ack на приоритетный issue за 5 минут не прилетел значит роутим на следующего
источник

AS

Aleksey Shirokikh in SPb Reliability Meetup
дежурство предполагает что человек должен иметь ноутбук с собой.
источник

AS

Aleksey Shirokikh in SPb Reliability Meetup
первый приоритет означает что надо остановить автомобить или выйти на станцию метро и приступить к решению
источник

SM

Serg Martynov in SPb Reliability Meetup
Aleksey Shirokikh
дежурство предполагает что человек должен иметь ноутбук с собой.
Да, но вот не всегда мы можем оперативно реагировать, даже если ноут с собой. Ты можешь выйти в магазин, поехать за продуктами итд.
источник