Site Reliability Engineering. Надежность и безотказность как в Google

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

В какой-то момент, казалось, об SRE заговорили из каждого утюга (по крайней мере, в моем информационном пузыре). Так что пройти мимо этой книги у меня не было практически никаких шансов. Сразу оговорюсь, что её имеет смысл читать исключительно "специалистам", ну либо очень любопытным людям.

Я же, поработав "с компьютерами" некоторое время, могу с уверенностью сказать, что компьютеры ненадёжны (впрочем, в каких-то отношениях точно надёжнее людей). Поэтому лично меня построение (и принципы построения) надёжных технических систем, которые способны функционировать достаточно автономно, стало интересовать само по себе.

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

Так уж получилось, что то, что ПО разрабатывалось одними одними людьми, а запускались системы и эксплуатировались - другими, стало доброй традицией. Вероятно, это наследие обычных производств. Наверное, с точки зрения чистого менеджмента, в этой книге всё достаточно банально. Есть организационные проблемы, есть принцип Конвея, есть риски, есть сроки, стоимость и качество. И всё это надо учитывать, чему и посвящены некоторые разделы.

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

Книгой свободно можно пользоваться как справочником, потому что материал хорошо структурирован и, как уже говорилось, является скорее сборником статей. Хотя один раз я бы рекомендовал её прочитать целиком, чтобы составить комплексное представление о проблеме в целом.

Конкретные практики и подходы (бюджеты ошибок, SLO, SLA, управление инцидентами) в рамках небольшой рецензии описывать смысла нет. Серьёзно, для этого и есть эта книга. Думаю, основная её ценность - это то, что она позволяет посмотреть на проблемы отказов в сервисах в нескольких измерениях, рассматривая технические, организационные и человеческие факторы в целом. Шаг за шагом в этой книге описывается практически полная производственная цепочка ПО (очевидно, на примере Google, но это не так важно).

Главные общие идеи, которые красной нитью проходят через все повествование:

• нужно стремиться не к абсолютной надёжности, а к достаточной. При ужесточений требований по надёжности, затраты на такое решение будут расти по экспоненте;
• люди ошибаются, и делают это часто. Поэтому, когда они ошибаются, система должна продолжать работать корректно. Улучшить систему проще, чем изменить людей;
• всегда есть компромисс, но очень важно думать не о сиюминутных приоритетах, а о более долгосрочных;
• нужно понимать, что и почему вы делаете. Это определяет и эффективность процессов и успех команд.

  Звучит более, чем банально, не правда ли?

  Большая часть подходов, которые описаны в данной книге иначе как банальным "здравым смыслом" не назовёшь, но отчасти секрет в том, что люди как вид не очень-то заточены под создание по-настоящему сложных систем. Это факт, это ни хорошо, ни плохо. Среднестатистически это - норма. И, как это часто бывает, то, что очевидно на бумаге, не всегда проявляется в деле. И вот у нас есть стереотипы о программистах-перфекционистах и "эффективных" менеджерах.

  Именно признание объективной действительности и понимание того, как именно всё (и компьютеры, и люди) работает позволяет двигаться вперёд и строить не просто сложные системы, а очень сложные ("Google runs on 5000 times more code than the original space shuttle").

  Забегая вперёд, скажу, что в этой книге SRE не то, чтобы противопоставляется DevOps, но у меня сложилось впечатление, что SRE - это всё-таки про надёжность, в то время как из "руководства по DevOps" я бы сделал вывод, что DevOps - это про скорость внесения изменений. Понятно, что оба подхода стремятся в общем-то снизить издержки на внедрение нового функционала, чтобы позволить себе меняться настолько быстро, насколько это необходимо, а не упираться в потолок того, насколько это доступно.

  Но например, в плане отношения к ошибкам: в DevOps мы считаем, что ошибки - это нормально, то, что мы их исправляем делает нас и продукт лучше. В SRE же принято бюджетирование ошибок, хотя, конечно же, на ошибках тоже учатся.

  Когда я пишу эту рецензию, уже вышла и вторая книга (и, судя по всему, не последняя) - SRE Workbook. И в ней уже на нескольких страницах нам объясняют, что SRE - это и есть реализация DevOps. Впрочем, какая разница, как это называть, если это работает?

  В заключение добавлю лишь, что слышал, что обе SRE-книги являются "настольными" в SRE-командах Google, хотя знать их как "отче наш", вроде бы не требуется. Но обе книги замечательны тем, что предлагают не просто набор инструментов, а даже определенную, не побоюсь этого слова, философию. Хотя, прежде всего, кажется, они просто призывают включить голову.

Общее впечатления от книги какое-то среднее! Из минусов:

• Очень много воды! Ну очень много.
• Во многих главах слишком сильная заточка конкретно под Google. Я понимаю, что эту книгу дают в обязательном порядке читать всем, кто устраивается на работу в Google. Но вот практическая польза для сотрудников других организаций - под вопросом.

  Но всё же нельзя не выделить и плюсы. Это, во-первых, теоретическая база по SRE, тех поддержке, работе с SLA и SLO, жизненному циклу продукта, тех дизайну и т.д.

  Есть главы, в которых практически одна вода, либо сильно специфичная информация, которая могла бы быть интересной только для инженеров Google.

В главе про cron автор рассуждает про аргументы в пользу выбора распределенных файловых систем. Такие рассуждения, основанные на реальном опыте, на мой взгляд представляют собой наибольшую ценность.

Небольшие операции записи для распределенных файловых систем выполнять очень дорого.

В целом я бы, наверное, не стал рекомендовать эту книгу к прочтению. Такой объем, 550 страниц! Представить только, сколько можно прочитать статей по highload, к примеру, вместо этой водянистой муры. Советую читать, только если реально собеситесь в гугл.