Здравствуйте, уважаемые читатели!
Полагаем, не только нас заинтересовала книга "Site Reliability Engineering", написанная большим коллективом авторов из Google. Мало того, что она продолжает занимать первые строчки всевозможных рейтингов Amazon; самое интересное, что в ней дается действительно доступная и исчерпывающая информация о безупречной эксплуатации систем любой сложности.
Более того, нас в перспективе интересует и более общая обзорная книга по методологии DevOps, выхода которой мы с нетерпением дожидаемся:
Поскольку мы практически убеждены, что варан с овцебыком составят идеальную пару, остается надеяться на не меньший читательский интерес к SRE и DevOps. Предлагаем изучить немного сокращенный обзор книги «Site Reliability Engineering». Автор статьи Майк Догерти — один из соавторов книги, частично ее вычитывавший.
Около 2 лет компания Google работала над книгой «Site Reliability Engineering». Это особая дисциплина и организация рабочих процессов, при помощи которой Google обеспечивает гладкую и бесперебойную работу всех своих колоссальных систем. Эта книга только что вышла в оригинале. Ее объем составляет более 500 страниц, а на ее страницах подробно рассказано, как именно работает Google. Авторы пишут на редкость открыто, не скрывают названий проектов и систем, объясняют, как функционируют эти системы. Да, вы не найдете на страницах исходного кода, зато сможете взять на вооружение массу приемов, которые пригодятся отнюдь не только в Google. Книга будет очень интересна сотрудникам стартапов, мечтающим вырастить большую компанию, а также работникам средних и небольших технологических компаний, желающих повысить надежность своих сервисов.
Сразу признаюсь, что работал SRE-инженером в Google и участвовал в написании небольшого фрагмента главы 33, где рассказывается, как принципы SRE можно применять в нетехнической области.
Разумеется, мне эта книга Америку не открыла, ведь я работал в той самой организации, в недрах которой она родилась. Но я интересуюсь тем, что Google пытается донести до остальной части технического сообщества. Google уже давно старается четко описать, что же такое SRE. Именно такая неопределенность озадачила меня, когда я устраивался на работу в Google по этой специальности. Но Google исключительно хорошо справляется с эксплуатацией гигантских систем, а SRE – набор практик и методов, позволивших сформировать такую технологическую культуру, которая обеспечивает подобную эффективность.
Спешу вас порадовать: даже если у вас нет систем вроде Borg или Chubby, вы все равно можете делать многие вещи, которыми занимаются SRE-инженеры в Google. Книга содержит массу практических советов о том, как правильно построить такую работу, что делать и чего не делать (кстати, книга приятно удивляет тем, как здраво в ней рассматриваются допускавшиеся ошибки).
Насколько мне известно, все технологии, упоминаемые в книге, уже засветились в открытых источниках. В последние годы появились статьи и лекции по Piper, Borg, Maglev и т.п., поэтому авторы также свободно рассуждают о них. Конкретные технологии интересны как материал для кейсовых ситуаций, но наиболее интересны не отдельные продукты или системы как таковые, а информация о том, как Google реализовал эти проекты в соответствии с принципами SRE. Итак, это книга о SRE, а не о конкретных системах. Большая часть материала в книге посвящена не готовым системам, а принципам и практикам, которыми может воспользоваться читатель. Правда, эти принципы и практики лучше работают не по отдельности, а как единое согласованное целое. К счастью, в книге найдутся дельные советы для самых разных читателей, целевую аудиторию я подробнее опишу в заключительной части этого обзора.
ОБЗОР
Книга делится на пять частей: Введение, Принципы, Практики (самый объемный раздел, на него приходится около 60% объема книги), Менеджмент и Заключение. Я хотел вкратце рассказать об отдельных главах, которые считаю особенно интересными или ценными для читателя. Если эта часть вас не интересует, можете ее пропустить и сразу перейти к разделу «Немного размышлений», где я рассуждаю, чем книга о SRE может быть полезна конкретному читателю.
«Введение» важно прочитать, так как в нем задается контекст для обсуждения всех дальнейших тем, поэтому настоятельно рекомендую его не пропускать. В первой главе рассказывается, что такое SRE, а также указываются различия между SRE, системным администрированием и DevOps. Во второй главе в общих чертах описано, как построена рабочая среда Google – от Borg до хранилищ данных, сетей и сред разработки.
Раздел «Принципы» базируется на материале главы 1 и начинается с темы управления рисками. Этот материал крайне важен, чтобы понять прочность и упругость систем SRE. Если бы мы хотели 100% стабильности, то просто не позволили бы разработчикам что-либо менять. Но это убивает бизнес. В действительности же мы учимся управлять уровнем риска, который на себя принимаем, и работать максимально быстро. При этом, поломки не исключены, главное, чтобы они укладывались в наш ремонтный бюджет.
Далее упомяну о главах 6 и 10, где подробно объясняется, как Google отслеживает работу своих колоссальных систем, и как мы получаем оповещения о возникающих проблемах (здесь также объясняется смысл понятия «неправильно», что очень важно). Вероятно, проблема мониторинга не менее сложна, чем монтаж тех самых систем, которые придется отслеживать, и решение этой задачи – искусство (системных) программистов.
В главе 7 рассмотрено, как велика роль автоматизации при SRE. В столь масштабных системах как наши ценность автоматизации невозможно переоценить, но, поскольку Google продолжает расти, мы стремимся создавать новые системы, чьи возможности выходят далеко за рамки автоматизации. Только так мы можем надеяться, что справимся с эксплуатацией наших крупнейших нынешних систем, а также тех систем, что появятся в будущем.
Один из важнейших аспектов SRE – соответствующая культура. Эта тема эпизодически затрагивается во всей книге, но наиболее важна в данном контексте «культура анатомирования». В главе 15 объясняется, что это такое, и почему анатомирование должно быть безупречным.
В главе 17 обсуждается тестирование надежности. Это одна из немногих глав, обманувших мои ожидания. Хотя в ней и рассматриваются такие важные темы, как нагрузочное тестирование и «звоночки», эти темы не обсуждаются в деталях. Может быть, авторы просто не хотели вдаваться в подробности, либо материал пришлось сократить (если так, то я лучше сократил бы какой-нибудь другой фрагмент), но, так или иначе, осадок остался.
Далее следуют четыре главы, в которых объясняется, как в Google организуют балансировку нагрузки на различных уровнях (главы 19 и 20), как справляются с перегрузками и избегают каскадирующих отказов (главы 21 и 22). Все эти темы сильно взаимосвязаны, они, безусловно, заслуживают уделенных им 60 страниц. У нас есть стандартные серверные и клиентские реализации обратного воздействия (backpressure), взвешенная балансировка нагрузки по принципу карусели, частичный бэкап баз данных (subsetting), приоритет и критичность запросов, а также сегментация нагрузки, стоимость запросов и многое другое. Все эти механизмы важны для избегания перегрузки и каскадирующих отказов, поэтому лучше разобрать их по такой книге, чем учиться на собственных ошибках.
В следующих двух главах, 23 и 24, рассмотрены распределенно-согласуемые системы и Borgcron – распределенная cron-служба Google, работающая по принципу такого согласования. Работать с распределенным cron сложнее чем кажется, поэтому читателю предстоит поучительная экскурсия по многоуровневой структуре, при выстраивании которой cron с единственной машины превращается в Borgcron.
Часть 4 посвящена управлению SRE-командами. Поскольку этот материал был мне не так интересен как техническая часть книги, сразу перейду к главе 32 «Разработка развивающихся сервисов: фреймворки и платформа SRE». МЫ считаем, что подобная работа по стандартизации платформы критически важна для масштабирования SRE, а, следовательно, и систем Google.
В части 5 излагаются истории о том, как достигается высокая надежность в других отраслях промышленности. Именно эту главу меня попросили просмотреть перед публикацией. Не уверен, насколько она обогащает книгу, но все-таки важно проследить общие черты в обеспечении надежности самых разных систем – тем самым авторы доказывают, что Google SRE развивается в верном направлении.
РАЗМЫШЛЕНИЯ
Итак, после достаточно беглого обзора важнейших частей книги я хотел бы поговорить о том, чем она особенно ценна. Может быть, Google просто бахвалится, либо читатель все-таки что-то вынесет из этой книги? Будут ли описанные в книге приемы полезны для сотрудников небольших компаний? Полагаю, да. Здесь вы найдете массу дельных советов для ведения open source-проектов, для работы в маленьких и больших технологических компаниях, где еще нет такой зрелой системы SRE, как в Google.
Многие приемы разработки и тестирования, описанные в книге, легко реализуемы в свободных проектах. Системы нужно проектировать с учетом обратного воздействия и изящной деградации, прозрачного мониторинга, обширного тестирования, не ограниченного модульными тестами и т.д.
Чем может быть полезна такая книга в небольших компаниях, где за эксплуатацию систем отвечают всего несколько инженеров, типичные сисадмины? Во-первых, она может показать иной путь. Речь не о том, чтобы реализовывать все эти возможности, мне такая задача кажется неподъемной. Но важно усвоить сами принципы. Наем и обучение сисадминов следует модифицировать, чтобы эти сотрудники стали дописывать те элементы программ, которых может недоставать. Сисадмин должен безупречно анатомировать ошибки, а также исправлять все действующие элементы, которые могли не сработать при отказе системы. Когда бюджет на исправление ошибок начинает исчерпываться, последовательность релизов нужно замедлить. В частности, обратите внимание на главу 30 «Берем на вооружение SRE для сглаживания эксплуатационной перегрузки». Также посмотрите главы 1 и 28.
В более крупных компаниях, где хватает талантливых инженеров, но процесс SRE как следует не организован, книга может быть полезна в разных отношениях; все зависит от того, в чем, н ваш взгляд, организация не дотягивает с инженерной точки зрения. Может быть, у вас по-прежнему существует специальный эксплуатационный отдел, может быть, вы уже занимаетесь DevOps, но всегда может наступить время, когда назреет необходимость изменить инженерную структуру организации. Допустим, у вас нет стандартов по борьбе с перегрузками и каскадирующими отказами — тогда вложите средства в создание таких циклов разработки, которые позволят создать такую инфраструктуру. Если возникают проблемы с балансировкой нагрузки — почитайте, как это делается в Google.
Наконец, должен упомянуть, что книга читается очень легко.
Настоятельно рекомендую эту книгу всем специалистам по DevOps, поддержке, обеспечению надежности и разработке масштабных программных проектов. Книга помогает не только взглянуть за кулисы Google, что само по себе бесценно, но и содержит дельные советы от специалистов Google, буквально из первых рук. Поверьте, все изложенные в ней идеи абсолютно реализуемы.
Автор: Издательский дом «Питер»
