Мой товарищ спросил меня как-то: "Зачем я пишу о книжке, если в конце говорю что её не надо читать?" - очевидный ответ, чтобы её не читали, по причинам про которые я написал :) . Если читали, чтобы сравнить собственные впечатления после прочитанного, с не парадными впечатлениями ещё одного читателя. И в конце-концов отнестись критически и прочитать, чтобы согласится или не согласится с озвученным мнением. Книга в любом случае оставила впечатление достаточное чтобы про него сказать, книги без такого впечатления пылятся дальше без всякого упоминания.

В общем, я с трудом осилил "Site Reliability Engineering" от Google, с трудом, потому что попытки читать перед сном приводили к этому самому сну раньше чем я планировал, а в другое время - к активной скуке, потому что всё в духе Капитана Очевидность. Вроде как опять негативный отзыв, но почитать скорее стоит, чтобы оценить взгляд Google на DevOps и даже не столько на него, тем более есть несколько историй изнутри, не сказать чтобы детально описанных, но они есть, да и актуальность всё ещё присутствует, может быть поэтому и скучно, потому что такого очень много вокруг. Кстати, я почему-то думал что SRE не про DevOps, но книга в общем и не про него.

Структурно это набор статей, в нескольких разделах, где-то есть перекрёстные ссылки, но в целом каждый раздел самостоятелен, часто и каждая глава-статья самостоятельны. Во второй половине третьего раздела практически не упоминается про SRE/DevOps там про балансировку, консистентность, отказы, мониторинг, тесты, развёртывание в распределённых системах, не сказать что технически глубоко, но они больше всего технические. Вся книга по задумке, как мне показалась - про надёжность, в конце делается даже попытка сравнить как дела обстоят в разных отраслях, по отзывам сотрудников Google ранее в этих отраслях работавших. Но это не учебник, да и приведённого небольшого набора практик хватит на то чтобы только оценить свои подходы через ещё одну призму. Про надёжность как предмет изучения, к своему ужасу, я не могу вспомнить ни одной конкретной инженерной лекции в университете, всё больше про абстракции и вероятности, а вот в более приземлённом колледже что-то было, как минимум ориентироваться в терминах учили.

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