Войти в систему
Войти с помощью соц. сетей:
Автор — Марк Алвидрес
Под редакцией Кавиты Джулиани
Вы можете подумать, что компания Google старается выпускать на 100 % надежные сервисы, которые никогда не дают сбоев. Однако в определенный момент увеличение надежности приносит сервису (и его пользователям) больше вреда, чем пользы! Предельная надежность имеет свою цену: увеличение стабильности ограничивает скорость разработки новой функциональности и создания новых продуктов, а также повышает их стоимость. В свою очередь, это уменьшает объем функциональности, который команда может позволить себе предложить пользователям. Далее, пользователи, как правило, не замечают разницы между сервисами с высокой и крайне высокой надежностью, поскольку во время их взаимодействия с сервисом значительное влияние оказывают менее надежные компоненты вроде мобильной сети или того устройства, с которым они работают. Проще говоря, пользователь смартфона, надежного на 99 %, не заметит разницы между сервисами с 99,99 % и 99,999 % надежности! Учитывая это, SR-инженеры стараются не просто увеличивать время работы без сбоев, а добиваться баланса вероятности того, что сервис окажется недоступен, и возможности его быстрого развития и эффективного функционирования. Тогда пользователи останутся в целом удовлетворены как функциональностью сервиса, так и его доступностью и производительностью.
Ненадежные системы быстро утрачивают доверие пользователя, поэтому мы хотим снизить вероятность отказов. Однако опыт показывает, что стоимость системы при повышении надежности растет нелинейно — следующий шаг повышения надежности может стоить в 100 раз больше предыдущего. Можно выделить две составляющие этой стоимости.
• Стоимость избыточных (резервных) машинных/вычислительных ресурсов — стоимость, связанная с дополнительным оборудованием, которое, например, позволяет нам отключить систему для запланированных или непредвиденных работ или предоставляет место для контрольных кодов, дающих хотя бы минимальные гарантии сохранности данных.
• Стоимость упущенных возможностей — затраты, которые несет организация, когда она выделяет разработчиков для создания служебных систем или отдельных функций, необходимых для снижения рисков, вместо прикладных функций, востребованных конечными пользователями. Эти инженеры больше не работают над новой функциональностью и продуктами для конечных пользователей.
В SRE мы контролируем надежность сервиса в основном через управление рисками. Мы рассматриваем риск как непрерывную функцию (континуум), а также считаем одинаково важным повышать надежность систем Google и устанавливать адекватный уровень устойчивости наших сервисов. Это позволяет нам анализировать стоимость и прибыль, чтобы определить, например, в каких точках кривой зависимости (нелинейной!) рисков поместить сервисы Search, Ads, Gmail или Photos. Наша цель — явно соотнести риски, которые несет конкретный сервис, с рисками, которые готов понести бизнес в целом. Мы стремимся сделать уровень доступности сервиса достаточным, но не более необходимого. То есть, когда мы задаемся целью создать сервис, надежный на 99,99 %, мы хотим превзойти этот целевой показатель, но не намного, иначе это не позволяло бы нам добавлять новую функциональность, исправлять технические недоработки или снижать операционные расходы. В некотором роде, мы рассматриваем целевой уровень доступности как минимум и как максимум одновременно. Ключевое преимущество такого подхода — возможность явно и вдумчиво оценивать риски.
Стандартная практика Google — определить объективный показатель, позволяющий представить свойства системы, которые мы хотим оптимизировать. Имея цель, мы можем оценить текущий уровень и отслеживать его изменения с течением времени. Для оценки рисков, связанных с сервисом, не совсем понятно, как можно свести все потенциальные факторы в единый показатель. Отказы сервисов могут потенциально иметь множество различных последствий: недовольство пользователя, причинение ему вреда или потерю его доверия; прямое или непрямое снижение выручки; ущерб для бренда или репутации; нежелательное освещение в средствах массовой информации. Очевидно, некоторые из этих последствий трудно измерить. Чтобы упростить эту задачу и иметь возможность распространить ее решение на все типы запускаемых нами систем, мы сосредоточимся на незапланированных отключениях.
Для большинства сервисов проще всего представить рискоустойчивость в терминах допустимого уровня незапланированных отключений сервиса. Незапланированные отключения связаны с желаемым уровнем доступности сервиса, значение которого обычно выражается количеством девяток: 99,9, 99,99 или 99,999 %. Каждая дополнительная девятка на один порядок приближает нас к 100%-ной доступности. Для работающих систем этот показатель, как правило, вычисляется на основе времени безотказной работы (формула (3.1)). Доступность вычисляется на основе времени безотказной работы и отключений:
|
| Доступность = | Время безотказной работы | . | (3.1) |
| Время безотказной работы + Время отключений |
Используя эту формулу и взяв в качестве рассматриваемого промежутка времени один год, мы можем рассчитать допустимое время в минутах, когда система может быть неработоспособна, сохраняя при этом заданный уровень доступности. Например, система, для которой задана доступность 99,99 %, допустимо будет оставаться неработоспособной до 52,56 минуты за год. В приложении А вы можете увидеть соответствующую таблицу.
Однако для компании Google такой показатель доступности, основанный на времени, обычно не очень полезен, поскольку мы имеем дело с глобальными распределенными системами. Наш метод локализации и изоляции неисправностей позволяет в большинстве случаев сохранять возможность обработки хотя бы части трафика любого из сервисов за счет глобального перенаправления (то есть мы все время как минимум «частично включены»). Поэтому вместо показателей, связанных с временем безотказной работы, мы определяем доступность на основании количества успешных запросов. В формуле (3.2) показано, как определяется такой показатель с использованием «скользящего окна» (то есть доля успешных запросов в рамках одного дня):
|
| Доступность = | Успешные запросы | . | (3.2) |
| Все запросы |
Например, если система обслуживает в день 2,5 миллиона запросов и имеет заданный уровень доступности 99,99 %, для нее допустимо терять из-за сбоев до 250 запросов в день.
В обычном приложении не все запросы равноценны: ошибка при регистрации нового пользователя отличается от ошибки при фоновой загрузке новых электронных писем. Однако во многих случаях доступность, вычисленная как отношение количества успешных запросов к общему количеству запросов, с точки зрения конечного пользователя служит допустимым приближением к показателю доступности, связанному с незапланированными отключениями.
Определение времени незапланированного отключения через соотношение количества успешных запросов к общему количеству запросов позволяет также использовать этот показатель в системах, которые обычно не обслуживают непосредственно конечных пользователей. Большинство таких «технологических» систем (например, системы пакетной обработки, конвейеры, хранилища и транзакционные системы) имеют строго определенные критерии успешных и неуспешных «единиц работы» (запросов, операций и т.д.). Более того, хотя в этой главе рассматриваются в первую очередь системы, обслуживающие либо пользователей, либо инфраструктуру, многие из описанных подходов и определений можно применить также к «технологическим» системам, лишь слегка их модифицировав.
Например, пакетная обработка, в процессе которой содержимое одной из пользовательских баз данных извлекается, трансформируется и внедряется в общее хранилище для дальнейшего анализа, может запускаться периодически. Используя уровень успешных запросов, определенный через количество записей, обработанных успешно или с ошибкой, мы можем рассчитать и применять показатель доступности, хотя системы пакетной обработки обычно не работают в непрерывном режиме.
Чаще всего мы задаем уровень доступности для квартала, а производительность наших сервисов отслеживаем еженедельно или даже ежедневно. Это позволяет нам управлять сервисом так, чтобы обеспечить высокий уровень его доступности, имея возможность выявлять и исправлять причины значительных изменений состояния сервиса, появление которых со временем неизбежно. Более подробно об этом вы прочитаете в главе 4.
Что означает «определить рискоустойчивость сервиса»? В формализованном окружении или для систем, безопасность которых критически важна, понятие рискоустойчивости сервиса обычно включено в характеристики продукта или сервиса. Рискоустойчивость сервисов Google определяется не столь четко.
Для определения рискоустойчивости сервиса SR-инженер должен поработать с владельцами продукта, чтобы преобразовать набор бизнес-целей в четкие требования, которые можно реализовать. В этом случае нас интересуют бизнес-цели, которые непосредственно влияют на производительность и надежность предлагаемого сервиса. На практике такое преобразование удается с трудом. В то время как у потребительских сервисов зачастую есть владельцы, инфраструктурные сервисы (например, системы хранения или уровень кэширования для протокола HTTP), как правило, определенного владельца не имеют. Рассмотрим оба случая.
Зачастую над нашими пользовательскими сервисами работают команды, которые выступают бизнес-владельцами приложения. Например, сервисы Веб-поиск (Search), Карты (Google Maps) и Документы (Google Docs) имеют собственных менеджеров продукта. Эти менеджеры отвечают за взаимопонимание с пользователями и бизнесом, а также за то, чтобы продукт был успешным на рынке. Когда существует такая «команда продукта», требования к доступности сервиса можно обсудить с ней. При отсутствии такой команды эту роль зачастую играют создающие систему инженеры, знают они об этом или нет.
Существует множество факторов, которые следует принимать во внимание при оценке рискоустойчивости сервисов.
• Какого уровня доступности нужно достичь?
• Как различные типы сбоев влияют на сервис?
• Как мы можем манипулировать стоимостью сервиса, чтобы позиционировать его на кривой зависимости рисков?
• Какие другие показатели сервиса важно иметь в виду?
Целевой уровень доступности заданного сервиса Google обычно зависит от выполняемых им функций и от его позиционирования на рынке. В следующем списке приведены вопросы, которые необходимо принять во внимание.
• Какого уровня доступности будут ожидать пользователи?
• Связан ли сервис непосредственно с прибылью (как нашей, так и наших пользователей)?
• Сервис платный или бесплатный?
• Если на рынке есть конкуренты, какого уровня сервисы они предоставляют?
• Сервис предназначен для конечных пользователей или для предприятий?
Рассмотрим требования, предъявляемые к Google Apps for Work. В основном этот сервис используют предприятия, как крупные, так и небольшие. Эти предприятия зависят от сервисов Google Apps for Work (например, Почта (Gmail), Календарь (Calendar), Диск (Drive), Документы (Docs)), которые предоставляют им инструменты для повседневной работы сотрудников. Другими словами, сбой в сервисе Google Apps for Work становится сбоем не только для Google, но и для всех предприятий, которые от нас зависят. Для типичного сервиса Google Apps for Work нам следует установить целевой уровень доступности равным 99,9 % (в течение квартала), подкрепив эту цель более высоким целевым уровнем внутренней доступности и контрактом, который допускает штрафы на случай невыполнения внешних показателей.
Для сервиса YouTube, однако, во внимание принимается совершенно другой набор факторов. Когда компания Google приобрела YouTube, нам нужно было определить подходящий для этого сайта уровень доступности. В 2006 году сервис YouTube был ориентирован на пользователей и находился в совершенно другой фазе своего бизнес-цикла, чем Google. Несмотря на то что YouTube уже считался отличным продуктом, он все еще быстро менялся и рос. Мы установили для YouTube более низкие требования к уровню доступности, чем для наших продуктов, используемых на предприятиях, поскольку быстрое развитие функциональности было важнее.
Важно также иметь в виду характер сбоев, ожидаемых для каждого сервиса. Насколько устойчивым к отключениям сервиса будет наш бизнес? Что будет хуже для сервиса: постоянные небольшие сбои или периодическое полное отключение сайта? Оба типа сбоев могут при одинаковом абсолютном количестве ошибок иметь совершенно разные последствия для бизнеса.
Разницу между полным и частичным отключением можно естественным образом наглядно продемонстрировать на примере систем, обрабатывающих личные данные. Возьмем приложение по управлению контактами и рассмотрим разницу между сбоем, который не позволяет отрисовать изображения профиля, и ошибкой, приводящей к тому, что контакты одного пользователя показываются другому. В первом случае налицо небольшая ошибка, которую SR-инженеры довольно быстро исправят. Однако во втором случае вероятность выдачи личных данных может легко подорвать доверие пользователей. Поэтому во втором случае приемлемым будет полное отключение сервиса для отладки и (потенциально) очистки.
На другом конце шкалы будут находиться те сервисы Google, для которых допустимо иметь регулярные отключения в запланированное время. Когда-то одним из таких сервисов был Ads Frontend. Он использовался рекламодателями и публикующими рекламу сайтами для создания, конфигурирования, запуска рекламных кампаний и наблюдения за ними. Поскольку большая часть этой работы выполняется в обычное рабочее время, мы решили, что допустимо будет отключать сервис для его обслуживания в заранее запланированные промежутки времени.
Стоимость зачастую является ключевым фактором при определении подходящего целевого уровня доступности сервиса. Сервис Ads особенно удобен в качестве примера, поскольку доля успешных запросов может непосредственно отражаться на прибыли. При определении целевого уровня доступности для каждого сервиса мы задаем следующие вопросы.
• Если нам нужно построить и эксплуатировать подобную систему с доступностью на одну девятку выше заданной, насколько в таком случае вырастет наша прибыль?
• Покрывает ли дополнительная прибыль затраты на достижение такого уровня надежности?
Для того чтобы сделать это компромиссное равенство более конкретным, рассмотрим следующий анализ рентабельности для типового сервиса, где все запросы одинаково важны.
• Предлагаемое улучшение целевого уровня доступности: 99,9 % → 99,99 %.
• Предполагаемое увеличение уровня доступности: 0,09 %.
• Прибыль, получаемая от сервиса: $1M.
• Прибыль, которую можно будет дополнительно получить от улучшения доступности: $1M × 0,0009 = $900.
В этом случае, если стоимость улучшения доступности на одну девятку меньше $900, такое улучшение будет стоить своих денег. Если же эта стоимость больше $900, она будет превышать потенциальное увеличение прибыли.
Задача по определению целевой доступности может стать сложнее, если у нас нет простой функции, которая бы отражала зависимость между надежностью и прибылью. В таком случае может быть полезной модель фоновых ошибок, которой пользуются интернет-провайдеры. Если взять за основу количество сбоев на стороне конечного пользователя и снизить уровень ошибок настолько, чтобы он стал ниже уровня ошибок пользовательской среды, то эти ошибки можно будет считать непланируемыми помехами в рамках заданного качества соединения с Интернетом. Несмотря на значительные различия между провайдерами и протоколами (например, TCP и UDP, IPv4 и IPv6), измеренные нами типичные уровни фоновых ошибок для различных интернет-провайдеров заключены в пределах от 0,01 до 1 %.
Часто бывает полезным выразить рискоустойчивость и через другие показатели. Понимание того, какие показатели важны, а какие — нет, дает нам некоторую свободу при принятии решений, связанных с оправданным риском.
Наглядным примером может служить время задержки сервиса Ads. Когда компания Google только запустила поисковый сервис, одной из определяющих его особенностей была скорость. Когда мы создали сервис AdWords, отображающий рекламу рядом с результатами поиска, отсутствие задержки при использовании поиска было ключевым требованием к этой системе. Это требование распространяется на разработку каждого поколения систем AdWords и считается неизменным.
Система AdSense выводит на экран контекстную рекламу в соответствии с запросами, получаемыми из скриптов JavaScript, который издатели внедряют в свои сайты. Для нее установлен совершенно другой требуемый показатель величины задержки. Сервис AdSense не должен замедлять отображение сторонней страницы при внедрении в него контекстной рекламы. Конкретный показатель величины задержки будет зависеть от скорости отображения заданной веб-страницы. Это означает, что сервис AdSense может выполнять свою работу на сотни миллисекунд медленнее, чем AdWords.
Более мягкое требование к величине задержки позволило нам пойти на несколько компромиссов при планировании организационно-технического обеспечения (определении количества ресурсов и их местоположения). Это сэкономило нам немало средств. Другими словами, учитывая относительную нечувствительность сервиса AdSense к умеренным изменениям задержек, мы смогли ограничить количество площадок для размещения сервиса и тем самым снизить наши эксплуатационные издержки.
Требования к разработке и функционированию инфраструктурных компонентов значительно отличаются от требований к потребительским продуктам. Фундаментальное отличие состоит в том, что инфраструктурные компоненты имеют несколько клиентов, чьи потребности часто не совпадают.
Рассмотрим Bigtable [Chang, 2006] — крупную распределенную систему хранилищ структурированных данных. Некоторые пользовательские сервисы работают с данными непосредственно в Bigtable по путям, указанным в запросах пользователя. Время задержки у таких сервисов должно быть небольшим, а надежность — высокой. Другие команды используют Bigtable как репозиторий для данных, которые затем подвергаются анализу в режиме офлайн (например, MapReduce). Для них пропускная способность важнее надежности. Требования к рискоустойчивости для этих двух случаев будут значительно различаться.
Один из подходов к удовлетворению потребностей обоих типов состоит в том, чтобы сделать инфраструктурные сервисы ультранадежными. Учитывая, что эти инфраструктурные сервисы, как правило, потребляют значительные объемы ресурсов, такой подход на практике оказывается слишком затратным. Для того чтобы понять различие в потребностях разных типов пользователей, вы можете взглянуть на то, какое состояние очереди запросов было бы желательно для пользователей каждого типа.
Пользователи, которым нужно малое время задержки, хотели бы видеть очереди запросов Bigtable пустыми (практически всегда). Это позволит системе обрабатывать каждый особый запрос сразу же после его поступления. (Более того, неэффективное размещение запросов в очередях зачастую является причиной увеличения времени задержки.) Пользователей, заинтересованных в офлайн-анализе, больше интересует пропускная способность системы — они не хотят, чтобы очереди запросов пустовали. Оптимизация пропускной способности требует, чтобы система Bigtable никогда не простаивала в ожидании следующего запроса.
Как мы можете видеть, понятия успешного функционирования и отказа для этих групп пользователей противоположны друг другу. Ситуация, которая оказывается успехом для пользователей, ожидающих получить малое время задержки, становится дефектом для пользователей, связанных с офлайн-анализом.
С точки зрения стоимости это противоречие можно эффективно обойти, разделив инфраструктуру и создав несколько независимых уровней обслуживания. В случае с Bigtable мы можем создать два типа кластеров: кластеры с низкой задержкой и кластеры с высокой пропускной способностью. Первые разрабатываются так, чтобы их могли использовать сервисы, которым нужны малое время задержки и высокая надежность. Чтобы гарантировать, что очереди запросов будут короткими, и обеспечить выполнение более строгих требований по изоляции клиента, системе Bigtable может быть выделено дополнительное количество ресурсов для ослабления конкуренции между их потребителями за счет большей избыточности. С другой стороны, кластеры с повышенной пропускной способностью могут содержать меньшее количество устройств, чтобы оптимизировать пропускную способность ценой задержек. На практике мы можем гораздо дешевле обеспечивать выполнение таких ослабленных требований и стоимость подобных кластеров составляет 10–50 % от стоимости кластеров с низкой задержкой отклика. Учитывая масштаб системы Bigtable, такая экономия очень быстро становится весомой.
Ключевая стратегия при работе с инфраструктурными сервисами — создание сервисов с явно разграниченным уровнем параметров обслуживания. Это позволяет клиентам находить оптимальные компромиссы рисков и стоимости при построении своих систем. Имея явно разграниченные уровни обслуживания, провайдеры инфраструктуры могут эффективно подчеркнуть разницу между ними, отразив ее в стоимости. Такое разграничение стоимости побуждает клиентов выбирать наиболее дешевый уровень обслуживания, который соответствует их требованиям. Например, Google+ может разместить данные, критически важные для безопасности пользователей, в хранилище данных с высокой доступностью (например, глобально реплицированную SQL-подобную систему вроде Spaner [Corbett et al., 2012]). При этом опциональные данные (которые не являются критически важными и нужны для повышения потребительских качеств) будут храниться в более дешевом, менее надежном, более старом и, соответственно, менее устойчивом хранилище данных (например, хранилище NoSQL с оптимизированной по затратам репликацией вроде Bigtable).
Обратите внимание на то, что мы можем запускать сервисы различного класса, используя одно и то же программное и аппаратное обеспечение. Мы можем обеспечить совершенно разные характеристики сервисов, изменив их параметры: количество выделяемых ресурсов, уровень избыточности, географические особенности размещения и, что принципиально, конфигурацию инфраструктурного софта.
Эти принципы оценки рискоустойчивости могут быть применимы не только для хранилищ, и, чтобы продемонстрировать это, рассмотрим еще один крупный класс сервисов: фронтенд-инфраструктуру Google. В нее входят обратные прокси-серверы и балансировщики нагрузки. Эти системы, помимо всего прочего, поддерживают соединения конечных пользователей (например, TCP-сессии их браузеров). Учитывая критическую роль этих систем, мы проектируем их максимально надежными. В то время как определенный уровень ненадежности пользовательских сервисов может остаться незамеченным, инфраструктурным системам повезло меньше. Если запрос не попадает на фронтенд-сервер прикладного сервиса, он будет полностью потерян.
Мы рассмотрели способы определения рискоустойчивости для пользовательских и инфраструктурных сервисов. Теперь рассмотрим понятие допустимого уровня дефектов в разрезе управления ненадежностью посредством суммарного уровня ошибок.
Автор — Марк Рот
Под редакцией Кармелы Куинито
В других главах этой книги рассматривается ситуация, когда между командами разработки и SRE могут возникнуть трения из-за того, что их работа оценивается разными показателями. Производительность труда команды разработчиков оценивается в основном скоростью выпуска продуктов, что побуждает как можно быстрее писать новый код. В то же время производительность работы SR-инженеров оценивается (что неудивительно) с точки зрения того, насколько надежен сервис, и это побуждает сопротивляться появлению большого количества изменений. Информационная асимметрия между двумя командами еще больше усиливает эти трения. Разработчики продукта имеют более четкое представление о том, сколько времени и сил они потратили на написание и выпуск своего кода, а SR-инженеры лучше ориентируются в надежности сервиса (и в общем состоянии продукта).
Эти трения часто отражаются в разных мнениях о том, насколько старательно нужно разрабатывать продукты. Далее перечислены наиболее типичные спорные моменты.
• Устойчивость к сбоям. Насколько хорошо нужно защитить софт от неожиданных ситуаций? Если защита будет слабой, у нас получится уязвимое и нестабильное приложение. Если защита будет сильной, у нас получится приложение, которое никто не захочет использовать (зато оно будет очень надежным).
• Тестирование. Опять же, если мало тестировать приложение, это может привести к нежелательным простоям, утечкам личных данных или к другим явлениям, вредящим имиджу. Если тестировать долго, можно потерять свою долю рынка.
• Частота выпуска новых версий. Каждое обновление рискованно. Как найти наиболее удачное соотношение затрат времени на снижение этого риска и на выполнение другой работы?
• Продолжительность тестирования и размер выборки. Лучше всего тестировать новую версию на небольшом фрагменте данных. Как долго нам следует ждать и насколько большой должна быть выборка?
Существующие команды, как правило, выработали некий неформальный баланс между риском и затрачиваемыми усилиями. К сожалению, вряд ли кто-то из них может с уверенностью сказать, что выработанный ими баланс является идеалом, а не результатом дипломатических талантов инженеров. Принятие таких решений не должно быть продиктовано политикой, страхом или надеждой. (Более того, неофициальный девиз Google SRE гласит: «Надежда — плохая стратегия».) Вместо этого наша цель — определить объективный показатель, с которым будут согласны обе стороны и с помощью которого можно будет направить переговоры в продуктивное русло. Чем больше решение будет основываться на данных и количественных показателях, тем лучше.
Чтобы строить свои решения на основе объективных данных, обе команды совместно определяют квартальный допустимый суммарный уровень ошибок (бюджет ошибок), основываясь на целевом уровне качества обслуживания (SLO, см. главу 4). Суммарный уровень ошибок — прозрачный и объективный показатель, который определяет, как часто сервис может проявлять ненадежность в пределах одного квартала. Этот показатель позволяет исключить влияние «политических» и эмоциональных факторов на договоренности между SR-инженерами и разработчиками.
Мы пользуемся следующим алгоритмом.
1. Менеджер продукта определяет SLO, задавая тем самым ожидаемую долю времени бесперебойной работы сервера в течение квартала.
2. Реальное текущее время бесперебойной работы измеряется нейтральной третьей стороной — нашей системой мониторинга.
3. Разница между этими двумя числами является запасом (бюджетом) того, насколько ненадежной может быть система в оставшуюся часть квартала.
4. Пока доля времени бесперебойной работы больше времени, заданного SLO (другими словами, пока имеется запас времени недоступности), можно продолжать выпуск новых версий и обновлений продукта.
Например, пусть согласно SLO сервиса он должен успешно обслуживать 99,999 % всех запросов за квартал. Это означает, что лимит времени недоступности сервиса в данном квартале равен 0,001 %. Если из-за какой-либо проблемы ошибки будут возникать при обработке 0,0002 % ожидаемых запросов, будет считаться, что эта проблема поглощает 20 % квартального бюджета ошибок.
Основное преимущество описанного подхода в том, что он дает хороший стимул командам разработчиков и SR-инженеров сконцентрироваться на поиске баланса между инновациями и надежностью.
Во многих продуктах приведенный алгоритм применяется для управления скоростью выпуска новых версий: до тех пор пока заданные целевые показатели обеспечиваются и задачи выполняются, можно продолжать выпускать обновления. Если нарушения требований SLO происходят довольно часто и превышают заданные лимиты, выпуск новых версий временно приостанавливается. При этом дополнительные ресурсы направляются в тестирование и разработку, что служит повышению устойчивости системы, ее производительности и т.д. Существуют и более гибкие и эффективные подходы, чем просто «включение/выключение»: например, релизы можно задерживать или откатывать, если лимит времени недоступности почти исчерпан.
Например, если команда разработки хочет сэкономить время на тестировании или ускорить выпуск новых версий, а команда SRE этому сопротивляется, решение основывается на текущем суммарном уровне ошибок. Если запас велик, разработчики могут позволить себе больше рисковать. Если же лимит практически исчерпан, разработчики сами будут переориентироваться на тестирование или задерживать выпуск, поскольку они не заинтересованы «выйти за бюджет», полностью затормозив выпуски. В результате команда разработчиков начинает больше следить за своей работой. Они знают величину лимита и могут управлять собственными рисками. (Конечно, это возможно при условии, что команда SRE имеет право остановить выпуск новых продуктов, если требования SLO нарушены.)
Что происходит, если снижение измеренного SLO вызвано отключением сети или сбоем в дата-центре? Такие события также расходуют бюджет ошибок. В результате количество выпущенных новых версий до конца квартала может уменьшиться. Вся команда поддержит подобное снижение, поскольку за работу системы отвечает каждый сотрудник.
Использование суммарного уровня ошибок также позволяет наглядно отобразить цену слишком высоких показателей надежности: снижение гибкости и замедление инноваций. Если у команды возникают проблемы при выпуске новой функциональности, они могут пойти на ослабление требований SLO (тем самым увеличивая доступный бюджет ошибок), чтобы ускорить обновления.
| Основные итоги Управление надежностью сервиса в основном заключается в управлении рисками, и это может быть связано с издержками. Практически никогда не стоит планировать 100%-ный уровень надежности: во-первых, его невозможно достигнуть, а во-вторых, пользователь может не нуждаться в таком показателе или не заметить его. Необходимо соотнести назначение и особенности сервиса с теми рисками, которые бизнес готов на себя взять. Введение допустимого суммарного уровня ошибок (бюджета ошибок) стимулирует команды SRE и разработчиков и подчеркивает их общую ответственность за систему. Он позволяет проще принимать решения о скорости выпуска новых версий и эффективно сглаживать конфликт между участниками проекта в случае сбоев, а также дает возможность нескольким командам без лишних эмоций приходить к одинаковым выводам о рисках при выпуске продукта. |
Первая версия этого раздела появилась в журнале ;login: (август 2015 года, выпуск 40, № 4).
Этот прием также известен как bang/bang control — более подробную информацию вы найдете по ссылке .
Войти с помощью соц. сетей: