Конспект книжки “Site Reliability Engineering: How Google Runs Production Systems”: http://danluu.com/google-sre-book/

Гугл написал книжку про своих Site Reliability Engineers и их подходы. Это те же DevOps, продвинутые админы и тд. Интересно для тех, кто какое-то отношение имеет к поддержке работы production систем. Саму книжку можно бесплатно почитать тут: https://landing.google.com/sre/book.html Если выдержки заинтересовали, то книжка точно понравится.

Там мне запомнились несколько вещей.

Действия, когда случился инцидент

Your first response in a major outage may be to start troubleshooting and try to find a root cause as quickly as possible. Ignore that instinct! Instead, your course of action should be to make the system work as well as it can under the circumstances. This may entail emergency options, such as diverting traffic from a broken cluster to others that are still working, dropping traffic wholesale to prevent a cascading failure, or disabling subsystems to lighten the load. Stopping the bleeding should be your first priority; you aren’t helping your users if the system dies while you’re root-causing. Of course, an emphasis on rapid triage doesn’t preclude taking steps to preserve evidence of what’s going wrong, such as logs, to help with subsequent root-cause analysis.

То есть если случился пиздец, то естественной реакцией будет разобраться в его корневых причинах и сделать сразу ПРАВИЛЬНЫЙ фикс. Ребята говорят. что эта реакция ошибочна. Вместо этого надо сфокусироваться на немедленном устранении последствий (откат изменений, обходные пути и тд)

Из: https://landing.google.com/sre/book/chapters/effective-troubleshooting.html

Error budget Нет смысла стремится к 100% доступности. Переход к 100% (от 99.99% например) незаметен пользователям, но требует несоизмеримо бОльших усилий и создает мотивацию не делать ничего рискованного и нового. Поэтому надо задавать error budget и если мы его не выбрали, то возможно мы слишком консервативны и надо быть чуть более рисковее.

Про мониторинг Три типа результата: требует внимания человека немедленно (алерты, смс), требует внимания человека когда-нибудь (тикеты) и не требующие внимания человека (логи). Это сильно пересекается с моделью коммуникации: мессенжеры, email, остальное.

Про автоматизацию Carla Geisser: “If a human operator needs to touch your system during normal operations, you have a bug. The definition of normal changes as your systems grow.”

Планируемые фейлы

Google found that Chubby was consistently over its SLO, and that global Chubby outages would cause unusually bad outages at Google. Chubby was so reliable that teams were incorrectly assuming that it would never be down and failing to design systems that account for failures in Chubby

…

Solution: take Chubby down globally when it’s too far above its SLO for a quarter to “show” teams that Chubby can go down