danikin Apr 1 2019 at 14:24

Citymobil — пособие для стартапов по увеличению стабильности на фоне роста. Часть 2. Какие бывают виды аварий?

20 min

7.6K

VK corporate blog High performance *System Analysis and Design *Start-up development Product Management *

+35

Comments 14

Anton238 Apr 1 2019 at 14:35

Эх, а я то думал вам зачем то реальные аварии потребовалось разбирать…

danikin Apr 3 2019 at 16:55

Чтобы получить опыт и улучшить сервис

Anton238 Apr 3 2019 at 20:40

Вы не поняли, изначально я подумал что вы разбирали авто-аварии.

danikin Apr 4 2019 at 09:40

Ааа, понял. Нет, тут речь только про IT-инфраструктуру

pilot911 Apr 1 2019 at 15:20

Столько описанных вопросов решает Java со Spring в связке, все эти альтеры вне бранчей, отсутствие типизации

После перехода на микросервисы + Marathon всегда есть возможность безболезненно в течение секунд переключиться на предыдущую рабочую версию согласованных сервисов или баз

danikin Apr 1 2019 at 15:28

«Столько описанных вопросов решает Java со Spring в связке, все эти альтеры вне бранчей, отсутствие типизации» а что такое альтеры вне бранчей?

«После перехода на микросервисы + Marathon всегда есть возможность безболезненно в течение секунд переключиться на предыдущую рабочую версию согласованных сервисов или баз»

А как понять, какая версия рабочая?

Matvey-Kuk Apr 1 2019 at 16:36

Уже традиционно оставлю комментарий, что эффективность реакции на инцидент сильно зависит от конкретного инцидент менеджера — тулы, которая рассылает алерты по дежурным, шлет СМСки, звонит, эскалирует если кто-то проспал. Для тех, у кого нет «Котана», есть целый набор готовых штук:
PagerDuty
OpsGeany
VictorOps
И мой любимый, работающий прямо в Slack https://amixr.io (Предвзятое мнение)

danikin Apr 1 2019 at 16:41

Интересно было бы послушать истории внедрения этих менеджеров, как внедряли, какие конкретно бизнес показатели улучшились, как уменьшалась средняя продолжительность аварий и за счет чего

Matvey-Kuk Apr 1 2019 at 17:10

Поддерживал PagerDuty, потом мигрировал на VictorOps. Отдельно интегрировал в тестовом режиме OpsGeany. В среднем, функционал одинаковый. У всех трех проблема — интерфейс.

Когда начали вводить разработчиков в On-Call ротацию, это стало реальной болью. Я каждые несколько дней заново объяснял дежурным простейшие операции в VictorOps.

Сейчас веду интеграцию amixr.io в несколько компаний уже со стороны вендора. Он простой как пробка, так что пока таких проблем не наблюдаем :)

По цифрам хорошая идея. Быстрым набегом на базу, видно улучшение времени реакции после введения эскалаций и расписаний. Нужно обстоятельно сесть и выгрузить в отчетик…

danikin Apr 1 2019 at 17:37

Круто было бы, если вы статью написали. Очень интересен чужой опыт.

iKBAHT Apr 3 2019 at 14:29

Не рассматривали вариант переписать на строго типизированный язык? Я конечно понимаю, что на это совершенно нет времени, но может хотябы новые сервисы/модули начать писать на строгой типизации?

danikin Apr 3 2019 at 16:54

Конечно. Новые сервисы/модули пишем на Go.

gnuman Apr 4 2019 at 14:55

Денис, спасибо за статью! Было интересно.
Не приходилось сталкиваться с ошибками в старом коде, когда сломали что-то незначительное, но связанное с деньгами/поездками, но очень давно?
Пример из другой предметной области, но тем не менее — в каком-то определенном хитром случае подписки перестали продляться или комиссия перестала списываться. То есть где-то течет, но чуть-чуть и на графиках этого после релиза не заметно и мониторинг не замечает.
Находишь такое через год, умножаешь на 365 вроде бы небольшую сумму потерь за день, и волосы начинают шевелиться на самых нескромных местах от масштабов потерь. Самые неприятные, на мой взгляд, аварии.

danikin Apr 4 2019 at 14:56

«Не приходилось сталкиваться с ошибками в старом коде, когда сломали что-то незначительное, но связанное с деньгами/поездками, но очень давно? „

Постоянно. Это то, что я в статье как раз называю “пасхалки».

Only those users with full accounts are able to leave comments. Log in, please.