Site Reliability Engineering — Betsy Beyer and others

Книга о том, как гугл обеспечивает надежную работу своих систем, а также эволюции подходов к надежности.

В целом — очень полезно и хорошо, но надо понимать, что это не цельная книга, а скорее сборник эссе разных авторов. Из-за чего в ней намешано сразу всё:

  • как устроены датацентры гугла
  • общие принципы работы SRE в гугле
  • процессы инцидент-менеджмента
  • процессы найма и онбординга SRE-инженеров
  • технические вопросы — типа как гугл обеспечивает шардирование данных или борется с повышенной нагрузкой и др.

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

Особенно полезными показались главы

Про инцидент менеджмент как процесс. Работа над инцидентом не должна быть авралом. В Гугле есть отлаженный процесс работы над инцидентом, в которых участвует несколько человек, каждый из которых играет свою роль. В частности отдельные люди занимаются коммуникациями с внешними командами и если необходимо пользователями. Построен процесс передачи данных между сменами инженеров, если инцидент длится долго. В процесс вплетен сбор данных для последующего постмортема.

Про написание постмортемов — полезная практика, но сразу надо понимать, что занимает значительное время. Желательно чтобы заранее было определено какие ситуации требуют их написания и было явно выделено время на их написание — без этого ничего не полетит.

Про главный принцип работы SRE — что SRE должны не менее 50% времени тратить на разработку — автоматизацию, улучшение инфраструктуры и т.п, а не на повторяюшиеся ручные операции и тушение пожаров. Если этого не делать — всё скатывается к тому, что рост системы требует постоянного увеличение числа инженеров — а их найм и обучение очень сложны.

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

Ну и общий главный принцип подхода к работе:

Unlike almost everything in life «boring» is actually a positive attribute when it comes to software. We don’t want our programs to be spontaneous and interesting. We want them to predictably accomplish business goals

В целом 20+ часов на прослушивание были потрачены не зря 🙂

Добавить комментарий