Книга с ящеркой? Не подведёт!
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, хотя знать их как "отче наш", вроде бы не требуется. Но обе книги замечательны тем, что предлагают не просто набор инструментов, а даже определенную, не побоюсь этого слова, философию. Хотя, прежде всего, кажется, они просто призывают включить голову.
47 понравилось
