Предисловие авторов

Программное обеспечение (ПО) во многом подобно ребенку: для его появления на свет необходимо пройти через трудности и боль, но после его рождения усилий потребуется еще больше. Сегодня в обсуждении разработки ПО первому периоду уделяется намного больше внимания, несмотря на то что от 40 до 90 % затрат приходится на второй — после его выпуска. Распространенное мнение о том, что развернутое и работающее ПО «стабильно» и, как результат, не требует пристального внимания разработчиков, неверно. Следовательно, если разработка программного обеспечения обычно сосредоточена на проектировании и построении программных систем, должна существовать и другая дисциплина, предметом которой будет весь жизненный цикл программных продуктов: их создание, развертывание, функцио­нирование, обновление и в свое время — безболезненный вывод из эксплуатации. Эта дисциплина обращается — и должна обращаться — к широкому спектру навыков, но цель их применения иная, чем у других технических дисциплин. Такую дисциплину в Google называют обеспечением надежности информационных систем (Site Reliability Engineering, SRE).

Что же включает в себя понятие «обеспечение надежности информационных систем» (SRE)? Мы признаем, что название недостаточно хорошо отражает суть работы, — практически у каждого инженера, обеспечивающего надежность в Google, периодически спрашивают, что это такое и чем он занимается.

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

Далее, мы заботимся об обеспечении надежности системы. Бен Трейнор Слосс, вице-президент Google и автор термина SRE, утверждает, что надежность — это наиболее важная характеристика любого продукта: система не будет успешной, если с ней невозможно работать! И поскольку надежность настолько важна, специалисты SRE трудятся над тем, чтобы найти способы улучшить дизайн и функционирование систем в попытке сделать их более масштабируемыми, надежными и эффективными. Однако мы работаем в этом направлении только до определенного момента: когда система считается «достаточно надежной», мы переносим свое внимание на добавление новых функций или создание новых продуктов.

Наконец, SR-инженеры занимаются поддержанием работы сервисов, построенных на базе наших распределенных вычислительных систем, независимо от того, являются они хранилищами планетарных масштабов, сервисом электронной почты для сотен миллионов пользователей или поисковиком, с которого и началась история Google. Слово «сайт» в названии поначалу говорило, что мы поддерживали работу сайта google.com, однако сейчас у нас запущено гораздо больше сервисов, многие из которых не являются сайтами, — начиная с внутренней инфраструктуры вроде сервиса Bigtable и заканчивая продуктами для внешних разработчиков наподобие Google Cloud Platform.

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

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

Мы также предоставили вспомогательный материал — описание производственной среды Google и соответствия между нашим внутренним ПО и общедоступным, что должно помочь вам воспринимать весь изложенный материал в понятном вам контексте и применять свои знания на практике.

Наконец, нужно сказать, что создание ПО и разработка систем с учетом повышенной надежности — однозначное благо. Однако мы понимаем, что в небольших организациях могут задаваться непростым вопросом: как им лучше применить знания, полученные из этой книги? Это похоже на вопрос безопасности — чем раньше вы им займетесь, тем лучше. Даже если ваша небольшая организация имеет множество насущных проблем и ваше ПО отличается от выбранного в Google, вам все равно стоит заранее позаботиться о команде SRE, поскольку в этом случае последующее расширение структуры обойдется дешевле, чем построение ее с нуля. В части IV приведены практические рекомендации для обучения, коммуникации и проведения совещаний, опробованные у нас. Многие из них вы могли бы применить и для своей компании.

В компаниях среднего размера, скорее всего, уже имеется сотрудник, выполняющий функции SR-инженера (хотя, возможно, его должность называется как-то иначе). Поэтому путь к улучшению надежности ПО в такой организации — официально обозначить эту работу или найти людей, уже выполняющих ее, и побу­ждать их к ее дальнейшему выполнению, вознаграждая соответствующим образом. Эти люди стоят на границе разных взглядов на мир, подобно Ньютону, которого иногда называют не первым в мире физиком, а последним алхимиком.

И раз уж мы заговорили об истории, давайте подумаем, кто мог бы быть первым SR-инженером.

Мы думаем, что Маргарет Гамильтон, работавшая над программой «Аполлон» во время учебы в MIT, первой продемонстрировала все основные черты SR-инженера. По ее словам, «частью технической культуры является обучение всему и отовсюду, включая вещи, от которых меньше всего ждешь возможности чему-то научиться».

Однажды она взяла на работу свою маленькую дочь Лорен. В то время ее коллеги моделировали сценарии миссии на гибридном компьютере. Как и другие маленькие дети, Лорен принялась исследовать новое место и спровоцировала крах миссии, введя в DSKY (интерфейс компьютера «Аполлона», сокращение от display and keyboard) команды, не предусмотренные в текущем режиме. Таким образом, разработчики узнали, что произойдет, если реальный астронавт во время реальной миссии выполнит программу предстартовой подготовки P01. (Случайный запуск программы P01 во время реальной миссии стал бы серьезной проблемой, поскольку это привело бы к удалению навигационных данных и компьютер без них не смог бы управлять кораблем.)

Прислушавшись к своему чутью SR-инженера, Маргарет отправила запрос на изменение программы — добавление специального проверяющего кода на случай, если астронавт во время полета нечаянно выберет программу P01. Но эту инициа­тиву верхушка NASA посчитала ненужной — ведь такого, конечно же, просто не может быть! Поэтому вместо того, чтобы добавить код, Маргарет обновила документацию для миссии, поместив там предупреждение вида «Не запускайте программу Р01 во время полета». (Судя по всему, это позабавило многих участников проекта, поскольку им много раз говорили, что астронавты имеют безукоризненную подготовку и поэтому не ошибаются.)

Эти меры безопасности казались ненужными только до следующей миссии — на «Аполлоне-8», — которая стартовала спустя всего несколько дней после обновления спецификации. Экипаж состоял из трех человек: Джима Ловелла, Уильяма Андерса и Фрэнка Бормана. Во время прохождения среднего участка траектории, на четвертый день полета, Джим Ловелл нечаянно выбрал программу Р01 — по случайному совпадению это произошло на Рождество, — что создало кучу проблем всем участникам. Проблемы были более чем серьезными, ведь если бы решение не нашлось, то астронавты не смогли бы вернуться домой. К счастью, в обновленной документации такая ситуация была описана, и это помогло разобраться, как достаточно быстро загрузить необходимые данные и восстановить управление миссией.

По словам Маргарет, «даже досконального понимания того, как работают системы, бывает недостаточно для предотвращения человеческих ошибок», и вскоре запрос на добавление механизма обнаружения ошибки и восстановления работоспособности на случай запуска программы предстартовой подготовки P01 был одобрен.

Хотя инцидент с «Аполлоном-8» произошел полвека назад, этот опыт весьма поучителен для современных инженеров и продолжит оставаться таковым в будущем. Следите ли вы за системами, работаете в группе или создаете свою компанию, пожалуйста, держите в голове принципы SRE: доскональность и самоотдача, убежденность в важности подготовки и документирования, предусмотрительность в том, что может пойти не так, вкупе со стремлением это предотвратить. Добро пожаловать в нашу развивающуюся профессию!

Как читать эту книгу Эта книга представляет собой сборник очерков, написанных сотрудниками службы по обеспечению надежности Google. Она больше похожа на сборник докладов конференции, чем на обычную книгу, написанную одним автором или группой авторов. Каждая глава должна рассматриваться как часть целого, но пользу принесет также и чтение отдельных интересующих вас глав. (Если существуют какие-то другие статьи, которые дополняют текст, мы оставим на них ссылку, чтобы вы могли с ними ознакомиться.) Вам не обязательно читать книгу в определенном порядке, однако мы советуем начать с глав 2 и 3 (часть I «Введение»), где описывается производственная среда Google и подчеркиваются подходы SRE к рискам. (Риск во многом является ключевой особенностью нашей профессии.) Вы можете прочесть книгу от корки до корки, это тоже будет полезно; главы в ней сгруппированы по темам: «Принципы» (часть II), «Практики» (часть III) и «Управление» (часть IV). Каждая из них начинается небольшим вступлением: из него вы узнаете, о чем рассказывается в этой части, а также найдете ссылки на другие статьи, опубликованные SR-инженерами Google (там некоторые темы рассматриваются более подробно). Помимо этого, сопутствующий книге сайт, , содержит немало полезных ресурсов. Мы надеемся, что эта книга будет для вас интересной и полезной настолько, насколько ее создание было интересным и полезным для нас. Редакторы

Условные обозначения

В книге используются следующие условные обозначения.

Курсив

Применяется для обозначения новых понятий и терминов, которые авторы хотят особо выделить.

Шрифт без засечек

Используется для обозначения адресов электронной почты и URL-адресов.

Моноширинный шрифт

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

Курсивный моноширинный шрифт

Показывает в тексте те элементы, которые должны быть заменены значениями, подставляемыми пользователем или определяемыми контекстом.

Этот знак отмечает совет или предложение.

Этот знак указывает на примечание общего характера.

Этот знак отмечает предупреждение.

Использование примеров кода

Сопутствующий материал вы можете найти по адресу .

Эта книга призвана помочь вам в работе. Примеры кода из нее вы можете использовать в своих программах и документации. Если объем кода несущественный, связываться с нами для получения разрешения не нужно. Например, для написания программы, использующей несколько фрагментов кода из этой книги, разрешения не требуется. А вот для продажи или распространения компакт-диска с примерами из книг издательства O’Reilly нужно получить разрешение. Ответы на вопросы с использованием цитат из этой книги и примеров кода разрешения не требуют. Но для включения объемных примеров кода из этой книги в документацию по вашему программному продукту разрешение понадобится.

Мы приветствуем указание ссылки на источник, но не делаем это обязательным требованием. Такая ссылка обычно включает название книги, имя автора, название издательства и ISBN. Например: Site Reliability Engineering, edited by Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (O’Reilly). Copyright 2016 Google, Inc., 978-1-491-92912-4.

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