Принципы SRE

Какова на самом деле философия проектирования надежности сайта и чем она отличается.

Я инженер по надежности сайта в Google, пишу аннотации к Книге SRE в серии сообщений. Мнения, изложенные здесь, принадлежат мне, а не моей компании.

Продолжение: Подход Google к управлению услугами: разработка надежности сайта.

Хотя нюансы рабочих процессов, приоритетов и повседневных операций различаются от команды SRE к команде SRE, все они разделяют набор основных обязанностей в отношении услуг, которые они поддерживают, и придерживаются одних и тех же основных принципов. Как правило, группа SRE отвечает за доступность, задержку, производительность, эффективность, управление изменениями, мониторинг, реагирование на чрезвычайные ситуации и планирование ресурсов своих услуг. У нас есть кодифицированные правила взаимодействия и принципы взаимодействия команд SRE со своей средой - не только с производственной средой, но и с группами разработки продуктов, командами тестирования, пользователями и т. Д. Эти правила и методы работы помогают нам сосредоточиться на инженерной работе, а не на оперативной работе.

Вау, это список. Жемчужина здесь - «команда SRE отвечает за доступность, задержку, производительность, эффективность, управление изменениями, мониторинг, реагирование на чрезвычайные ситуации и планирование ресурсов »

Все эти предметы замысловато связаны. Как вы можете нести ответственность за задержку службы, если вы просто развертываете чужой код? Что ж: у вас есть возможности для планирования, мониторинга и управления изменениями, которые могут вам помочь.

Часто наша работа заключается в том, чтобы нести ответственность за то, что вещи работают медленнее или менее доступны, чем они должны быть, и взаимодействовать с нашими командами разработчиков, чтобы исправить проблемы в долгосрочной перспективе, одновременно применяя краткосрочные исправления: возможно, мы уменьшаем эффективность за счет простого добавления серверов? Или уменьшите нашу надежность, чтобы работать быстрее.

В следующем разделе обсуждается каждый из основных принципов Google SRE.

Обеспечение постоянного внимания к проектированию

Как уже говорилось, Google ограничивает оперативную работу SRE 50% их рабочего времени. Оставшееся время следует потратить на работу над проектом, используя свои навыки программирования. На практике это достигается путем мониторинга объема оперативной работы, выполняемой SRE, и перенаправления избыточной оперативной работы командам разработчиков продукта: переназначение ошибок и тикетов менеджерам по разработке, [ре] интеграция разработчиков в ротацию пейджеров по вызову и скоро. Перенаправление заканчивается, когда рабочая нагрузка падает до 50% или ниже. Это также обеспечивает эффективный механизм обратной связи, помогающий разработчикам создавать системы, не требующие ручного вмешательства. Этот подход хорошо работает, когда вся организация - как SRE, так и разработка - понимает, почему существует механизм предохранительного клапана, и поддерживает цель отсутствия событий переполнения, потому что продукт не создает достаточной рабочей нагрузки, чтобы требовать этого.

Я упоминал об этом в своей предыдущей статье: идея о том, что у нас есть поддержка руководства для «передачи» продуктов нашим разработчикам, - это отличный рычаг, который у нас есть.

Упомянутое здесь ограничение в 50% неточно измерено ни в одной команде, в которой я работал в Google. На практике, когда команде приходится выполнять слишком много оперативной работы, мы измеряем конкретные вещи, такие как количество инцидентов и количество поданных заявок.

В следующем абзаце мы начинаем рассказывать, как это работает.

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

В Google нет 8-часовых дежурств по вызову в SRE. Мы работаем по 12/12 или 24-часовой ротации. Показатель «2 происшествия в смену» применяется независимо от того, 12 или 24-часовой цикл смены. Это гарантирует, что инженеры, работающие в режиме 24-часовой ротации, также получат достаточно времени для управления инцидентами и последующей деятельности.

Мне не нравится рассматривать этот показатель как средний. Я здесь не отслеживаю среднее количество страниц за смену: если среднее количество страниц за смену составляет 0,4, но у вас есть 4–5 дней в месяц с 3+ инцидентами, я бы рассмотрел это как нездоровую загрузку пейджера и попытался бы решить эту проблему.

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

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

Аспекты подробно описаны в главе 15 книги SRE.

Коллега сказал мне на этой неделе: «После сегодняшнего инцидента я начал вскрытие с разработчиком, и они добавили к нему параграф, объясняющий, как они совершили изменение, которое нарушило производство, и мне пришлось поговорить с их об удалении. Потому что: если вы сосредоточены на том, чтобы найти кого-то или что-то виноватое, то вы ограничиваете себя только одной причиной. При вскрытии вы должны перечислить все, что пошло не так, что привело к сбою, не рассматривая это как место, где мы признаем свои поступки ».

Обеспечение максимальной скорости изменения без нарушения SLO службы

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

Мой бюджет: 21 минута.

Бюджет ошибок основан на наблюдении, что 100% - неправильная цель надежности практически для всего (за исключением кардиостимуляторов и антиблокировочной системы). В общем, для любой программной службы или системы 100% не является правильным целевым показателем надежности, потому что ни один пользователь не может отличить 100% доступность системы от доступности 99,999%. Есть много других систем на пути между пользователем и сервисом (их ноутбук, их домашний WiFi, их интернет-провайдер, электросеть…), и эти системы в совокупности доступны гораздо менее чем на 99,999%. Таким образом, предельная разница между 99,999% и 100% теряется в шуме другой недоступности, и пользователь не получает никакой выгоды от огромных усилий, необходимых для добавления последних 0,001% доступности.

Пока я был в Ads SRE, SRE смотрел на доходы от рекламы Google (на основе публично опубликованных данных о доходах, а не на какой-либо конфиденциальной информации) и подсчитывал, сколько денег в год стоит каждая дополнительная «9» доступности. Это продемонстрировало, что иногда вы действительно заботитесь о 0,001%!

Если 100% - это неправильная цель надежности для системы, что тогда является правильной целью надежности для системы? На самом деле это вовсе не технический вопрос - это вопрос о продукте, который должен учитывать следующие соображения:

Каким уровнем доступности будут довольны пользователи с учетом того, как они используют продукт?

Какие альтернативы доступны пользователям, недовольным доступностью продукта?

Что происходит с использованием продукта пользователями на разных уровнях доступности?

Проверить, что происходит с использованием пользователей, когда продукт немного менее надежен, довольно просто: if (user->in_experiment_set() && random()<0.0005), это не тот тест, который легко получить от своего менеджера.

Компания или продукт должны установить цель доступности системы. После того, как этот целевой показатель установлен, бюджет ошибок будет равен единице минус целевой показатель доступности. Услуга, доступная на 99,99%, недоступна на 0,01%. Допустимая недоступность 0,01% составляет бюджет ошибок службы. Мы можем потратить бюджет на все, что захотим, если только не перерасходуем его.

Старайтесь не тратить все это в одном месте.

Итак, как мы хотим потратить бюджет ошибки? Команда разработчиков хочет запустить функции и привлечь новых пользователей. В идеале мы бы потратили весь наш бюджет на ошибки, рискуя запускаемыми вещами, чтобы запускать их быстро. Эта основная посылка описывает всю модель бюджетов ошибок. Как только действия SRE будут концептуализированы в этой структуре, высвобождение бюджета ошибок с помощью таких тактик, как поэтапное развертывание и 1% экспериментов, можно оптимизировать для более быстрого запуска.

Это вводит идею поэтапного развертывания: если вы развертываете функции понемногу, а новая функция ненадежна на 20%, но доступна только для 5% ваших пользователей, это всего лишь 1% сбоя и только для время, необходимое для того, чтобы заметить.

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

Использование ошибочного бюджета разрешает структурный конфликт стимулов между разработкой и SRE. Целью SRE больше не является «нулевое отключение»; скорее, SRE и разработчики продуктов стремятся потратить бюджет ошибки на максимальную скорость работы функций. Это изменение имеет решающее значение. Отключение больше не является «плохим» - это ожидаемая часть процесса инноваций и событие, которым группы разработчиков и SRE управляют, а не опасаются.

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

Мониторинг

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

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

Различные вещи я считаю соответствующими действиями:

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

Ничего не делать никогда не нормально.

Существует три вида действительных выходных данных мониторинга:

Оповещения

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

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

У нашей команды есть правило под названием «Правило цветов»: если оно перейдет во вторичное, то это произойдет из-за того, что с первичным должно случиться что-то настолько трагическое, что вам нужно будет отправить им цветы и открытку.

Билеты

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

Когда я звоню, мне повезло, если я смотрю свою очередь билетов 4 раза в день. Они важны, но не критичны ко времени. Часто они отнимают очень много времени, потому что для понимания им нужен большой анализ.

«Какого черта мы сегодня делаем на 25% больше дисковых операций ввода-вывода, чем неделю назад, и достигаем пределов пропускной способности?»

логирование

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

Я собираюсь указать на это в следующий раз, когда кто-то попытается внедрить более серьезные оповещения по электронной почте. Все, что я получаю, - бесполезный шум.

Аварийного реагирования

Надежность - это функция средней наработки на отказ (MTTF) и среднего времени до ремонта (MTTR) [Sch15]. Наиболее важным показателем при оценке эффективности аварийного реагирования является то, насколько быстро группа реагирования может восстановить работоспособность системы, то есть MTTR.

Люди добавляют задержку. Даже если в данной системе больше фактических отказов, система, которая может избежать аварийных ситуаций, требующих вмешательства человека, будет иметь более высокую доступность, чем система, требующая непосредственного вмешательства. Когда люди необходимы, мы обнаружили, что предварительное обдумывание и запись лучших практик в «учебник» дает примерно трехкратное улучшение MTTR по сравнению со стратегией «крылатого». Дежурный инженер-герой на все руки действительно работает, но опытный дежурный инженер, вооруженный учебником, работает намного лучше. Несмотря на то, что ни одно руководство, каким бы всеобъемлющим оно ни было, не заменит умных инженеров, способных думать на лету, четкие и подробные шаги и советы по устранению неполадок ценны при ответе на высокоуровневые или срочные страницы. Таким образом, Google SRE полагается на инструкции по вызову в дополнение к упражнениям, таким как «Колесо неудач», чтобы подготовить инженеров к реагированию на события по вызову.

Различия в качестве в playbooks могут быть потрясающими. Где угодно, от «это настолько устарело, буквально все здесь не соответствует действительности», до «мне потребовалось бы 45 минут, чтобы прочитать эту книгу, а важная информация была скрыта в ссылке в конце абзаца ближе к концу», до « в этом учебнике в первом предложении мне рассказали, как именно диагностировать и устранить проблему ».

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

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

Напротив, мое личное мнение таково, что если playbook бесполезен, то и предупреждение не работает, и мы должны либо перестроить его, либо удалить и предупреждение, и playbook. Потому что иметь оповещения без достаточно полезной справочной информации очень опасно.

Управление изменениями

SRE обнаружил, что примерно 70% отключений происходят из-за изменений в действующей системе. Лучшие практики в этой области используют автоматизацию для достижения следующих целей:

Внедрение прогрессивных развертываний

Быстрое и точное обнаружение проблем

Безопасный откат изменений при возникновении проблем

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

Этот раздел очень маленький. Я уверен, что другие главы коснутся этого вопроса, но я собираюсь сделать здесь акцент:

Позвольте мне повторить это жирным шрифтом: 70% отключений вызваны изменениями в действующей системе. 70% сбоев можно избежать, если ничего не делать! Мы сами себе враги.

Таким образом, основной инструмент, позволяющий сократить расходы бюджета на ошибки до 70%, - это замечать плохие развертывания и быстро откатиться. Это такая простая вещь! Сколько времени нужно, чтобы заметить, что это плохой релиз? Сколько времени нужно, чтобы откатить? На скольких людях это повлияло до завершения отката?

Это вопросы, на которые вы обязательно должны знать ответы.

Прогнозирование спроса и планирование мощностей

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

При планировании мощности необходимо выполнить несколько шагов:

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

Иногда это так же просто, как нарисовать график роста, использовать линейку и прищуриться.

Не шутка. Иногда это бывает намного точнее, чем применявшиеся мне причудливые математические модели!

Точное включение источников спроса на неорганические продукты в прогноз спроса

Самое лучшее время года для рекламодателей - неделя перед Днем благодарения: каждая рекламная компания уделяет дополнительные часы, чтобы убедиться, что их рекламные кампании подходят для привлечения бизнеса в Черную пятницу.

Это отличный пример «неорганического спроса».

Регулярное нагрузочное тестирование системы для соотнесения необработанной емкости (серверов, дисков и т. Д.) С служебной емкостью

Нагрузочное тестирование не обязательно должно быть синтетическим, вы можете посмотреть на поведение работающей системы под нагрузкой, чтобы понять ее производительность, и вы часто получите более точные цифры.

Важно знать, что при достижении граничных условий (таких как нехватка ЦП или ограничения памяти) все может стать катастрофическим, поэтому иногда важно знать, где находятся эти ограничения.

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

Я принципиально не согласен со словами «ответственный» здесь. SRE в любой момент имеет полное право передать любую работу другой команде. Ключевым моментом является то, что мы несем ответственность за то, чтобы планирование мощностей было выполнено и соответствовало нашим требованиям, но это может сделать кто угодно.

В прошлом мне приходилось работать с продуктовыми группами, которые проделали вполне разумную работу по планированию своих услуг и предоставили это им. Однако мы проверили их работу.

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

Подготовка

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

В Google подготовка (или, как говорят в Google), может быть такой же простой, как изменение числа и нажатие кнопки, или это может быть дорогостоящий и рискованный многодневный процесс.

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

Это никогда не было безрисковым или безболезненным, лучшее, что я когда-либо делал, было «лишь немного рискованным» и «не невыносимо болезненным». Вот что происходит, когда у вас есть такая высокая степень риска и услуги, с которыми люди могут взаимодействовать, но не имеют хороших программных API-интерфейсов.

Один урок, который я усвоил здесь: никогда не пытайтесь заставить компьютер выполнять подготовку, как это сделал бы человек: копирование человеческих шагов, таких как «отредактируйте файл, отправьте его на проверку, запустите сценарий, проверьте консоль». безнадежно. Вместо этого следует делать это плавно и постоянно: «при использовании› x%, добавьте еще 1 сервер »,« когда серверы появятся в новом месте, добавьте их в набор серверной части балансировщика нагрузки ».

Эффективность и производительность

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

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

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

Прежде чем читать эту книгу и впоследствии анализировать ее для этого блога, я бы ответил «нет» на вопрос «Вы несете ответственность за производительность своих двоичных файлов». Но теперь я полностью передумал.

Точно так же, как надежность системы является обязанностью SRE, ожидая, что они предотвратят появление новой версии, вызывающей видимые для пользователя ошибки, группа SRE также несет ответственность за обнаружение, снижение и предотвращение производительности. регрессии.

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

Конец начала

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

Заключительные мысли: Это конец главы 1 книги SRE. Я изложил свою точку зрения, и мы лишь прикоснулись к сути SRE.

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