наличие второго уровня системы надежности что это
УРОВНИ И РАСЧЕТ НАДЕЖНОСТИ ОБЪЕКТОВ СЭЖТ
Надежность объектов СЭЖТ условно делится на 3 уровня.
Первый уровень надежности. Объект рассматривается как «черный ящик». О процессах, протекающих внутри него ничего не известно. Считается, что объект может иметь только два состояния – работоспособное состояние и отказ. Конкретное состояние объекта устанавливается путем сравнения параметров на его выходе с параметрами, заданными технической документации. Такими объектами являются сложные комплексные объекты, например – тяговые подстанции.
Второй уровень надежности. Объект рассматривается как система, состоящая из отдельных структурных элементов. Каждый из элементов может находится в двух состояниях – работоспособное состояние или отказ. Надежность объекта определяется как результат расчета совокупной надежности всех входящих в него элементов. Надежность такого объекта может быть оценена при наличии достаточных статистических данных по надежности всех его элементов.
Третий уровень надежности. Объект рассматривается как совокупность отдельных структурных элементов. Для каждого элемента известны закономерности изменения его параметров. В этом случае результаты расчета надежности будут наиболее точными и достоверными при условии наличия достаточного объема априорной информации о надежности всех элементов.
Первый и третий уровень надежности подразумевают наличие большого объема данных либо по измерениям параметров объекта в целом, либо по всем его структурным элементам. Использование этих уровней на практике затруднено ввиду больших затрат по их реализации. Второй уровень надежности применяется достаточно широко.
На практике применяются 2 вида расчетов надежности объектов СЭЖТ:
— расчеты структурной надежности;
— расчеты функциональной надежности.
Структурная надежность. При расчете структурной надежности не учитывается влияние отказа отдельного элемента на степень работоспособности всего объекта. При этом считается, что отказ любого не резервированного элемента сразу ведет к отказу всей системы.
Пример: Система состоит из трех последовательно соединенных элементов (рисунок 1). Отказ любого элемента ведет к отказу всей системы.
В случае параллельного соединения (резервирования) отдельных элементов отказ одного отдельного элемента не ведет к отказу всей системы (рисунок 2).
В случае если структурная схема сложна, то для расчета надежности системы необходимо выполнить ее преобразование к виду последовательного соединения элементов.
Функциональная надежность.При расчете функциональной надежности определяется возможность полноты выполнения ее функций. Считается что возможен не только отказ объекта, но и частичная потеря его работоспособности. В этом случае объект продолжает выполнять часть своих функций. Данный вид расчета является более сложным, более глубоким и боле дифференцированным.
Пример. Система электроснабжения постоянного тока должна обеспечивать подвижной состав напряжением, изменяющимся под нагрузкой в пределах 2700 … 3850 В. В результате неисправности системы регулирования под действием внешней нагрузки напряжение изменяется в пределах 2500 … 3850 В. Система электроснабжения будет выполнять свои функции с пониженными показателями качества работы, но это не приведет к прекращении движения ПС.
Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет
Электронная библиотека
С 1983 по 1988 годы Министерство обороны США и Национальный комитет компьютерной безопасности разработали систему стандартов в области компьютерной безопасности, которая включает более десяти документов. Этот список возглавляют «Критерии оценки безопасности компьютерных систем», которые по цвету обложки чаще называют «Оранжевой книгой». В 1995 году Национальный центр компьютерной безопасности США опубликовал «Пояснения к критериям безопасности компьютерных систем», объединившие все имеющиеся на тот момент дополнения и разъяснения к «Оранжевой книге».
«Критерии оценки безопасности компьютерных систем» Министерства обороны США открыли путь к ранжированию информационных систем по степени надежности.
В «Оранжевой книге» определяется четыре уровня надежности (безопасности):
· D – минимальная защита. Уровень предназначен для систем, признанных неудовлетворительными. В настоящее время он пуст, и ситуация едва ли когда-нибудь изменится;
· B – обязательная защита. Система должна иметь математическое описание своей защиты, т.е. иметь описание формальной модели политики безопасности и наличие спецификаций на функции системы. Система должна поддерживать защиту даже в отключенном состоянии;
· A – верифицированная защита. Для проверки спецификаций такой системы применяются методы формальной верификации.
По мере перехода от уровня C к A к надежности систем предъявляются все более жесткие требования. Уровни подразделяются на классы C1, C2, B1, B2, B3, А1 с постепенным возрастанием надежности.
Таким образом, всего имеется шесть классов безопасности:
· C2 – управляемый доступ. Большинство широко используемых операционных систем претендуют на соответствие защите по этому классу;
· B1 – защита с применением меток безопасности;
· B2 – структурированная защита;
· A1 – верифицированная разработка.
Большинство коммерческих операционных систем соответствуют классам С1 и С2. Подклассы класса В менее удобны для реализации в обычных бизнес-системах. Системы классов В и А чаще всего встречаются там, где все время требуется поддерживать максимально возможную защиту, например, в некоторых правительственных учреждениях. Windows NT и Windows 2000 относятся к классу С2. Одно из требований этого класса гласит, что сервер должен все время находиться за запертой дверью.
Чтобы система в результате процедуры сертификации могла быть отнесена к некоторому классу, ее политика безопасности и гарантированность должны удовлетворять приводимым ниже требованиям. Поскольку при переходе к каждому следующему классу требования только добавляются, будем говорить лишь о том новом, что присуще данному классу, группируя требования в согласии с предшествующим изложением.
Срочно?
Закажи у профессионала, через форму заявки
8 (800) 100-77-13 с 7.00 до 22.00
Наличие второго уровня системы надежности что это
KConsult C.I.S. оказывает услуги по расчёту и анализу надёжности и функциональной безопасности устройств, оборудования и систем различных назначения и степени сложности.
Расчёты и анализ надёжности проводят российские и зарубежные сертифицированные специалисты по надёжности и функциональной безопасности с многолетним опытом работы для предприятий машиностроительной, аэрокосмической, энергетической, электронной, железнодорожной и других отраслей промышленности России, стран СНГ и Европейского Союза.
Цели расчёта и анализа надёжности
Выбор методов для проведения расчёта и анализа надёжности системы определяется следующими факторами:
В большинстве случаев целями расчёта и анализа надёжности систем являются:
Базовые методы и инструменты расчёта и анализа надёжности
Множественность целей расчёта и анализа надёжности определяет значительное многообразие методов и техник проведения таких расчётов.
Стандарты определяют расчет надежности как процедуру последовательного уточнения оценок, показателей надежности по мере отработки решений по построению (проектированию, производству) и эксплуатации системы.
При этом в качестве основного показателя надежности часто называют вероятность безотказной работы системы, т.е. вероятность того, что в пределах заданной наработки (заданного интервала времени) отказа системы не произойдёт.
Сертифицированные специалисты KConsult C.I.S. обладают экспертизой и многолетним успешным опытом проведения расчётов таких показателей надёжности систем, как:
Взаимосвязи различных методов и более сложные стратегии анализа надёжности и функциональной безопасности
Для таких отраслей промышленности, как авиастроение, космическая, оборонная, энергетическая, железнодорожная, медицинская, а в ряде случаев, и для некоторых других, базовые методы анализа надёжности являются отправной точкой, основой для выполнения более сложных видов анализа надёжности и функциональной безопасности.
Примеры стратегий анализа:
1. Расчёт наработки на отказ (MTBF) > Анализ видов, последствий и критичности отказов (FMEA/FMECA) > Анализ дерева отказов (FTA)
Целью выполнения указанной выше последовательности типов анализа является демонстрация того, что вероятность наступления наиболее критичных отказов системы останется ниже заранее определенной величины в течение заданного периода времени.
2. Расчёт наработки на отказ (MTBF) > Блок-схемы надежности (RBD)
Целью выполнения указанной выше последовательности типов анализа является демонстрация того, что доступность системы останется выше заранее определенного уровня в течение заданного периода времени.
Приведенные выше примеры стратегий анализа являются довольно широко используемыми типовыми вариантами. В реальности же применяется гораздо больше разнообразных подходов. Возможны ситуации (которые часто встречаются на практике), когда оценка надежности системы выполняется только одним из методов, например, только методом анализа видов и последствий отказов (FMEA) или только методом анализа дерева отказов (FTA). Функциональность наиболее широко используемых методик оценки надёжности описана в соответствующих разделах нашего сайта:
По Вашему запросу наши эксперты могут выполнить необходимые расчёты, анализ надёжности для Вашего устройства, оборудования, системы или провести обучение с целью подготовки собственных специалистов в области надёжности и функциональной безопасности в Вашей организации.
Наличие второго уровня системы надежности что это
НАДЕЖНОСТЬ В ТЕХНИКЕ
Dependability in technics.
Dependability prediction. Basic principles
МКС 21.020
ОКСТУ 0027
Дата введения 1997-01-01
1 РАЗРАБОТАН МТК 119 «Надежность в технике»
ВНЕСЕН Госстандартом России
2 ПРИНЯТ Межгосударственным Советом по стандартизации, метрологии и сертификации (протокол N 7 от 26 апреля 1995 г.)
За принятие проголосовали:
Наименование национального органа по стандартизации
Госстандарт Республики Беларусь
Госстандарт Республики Казахстан
3 Стандарт разработан с учетом положений и требований международных стандартов МЭК 300-3-1 (1991), МЭК 863 (1986) и МЭК 706-2 (1990)
4 Постановлением Комитета Российской Федерации по стандартизации, метрологии и сертификации от 26 июня 1996 г. N 430 межгосударственный стандарт ГОСТ 27.301-95 введен в действие непосредственно в качестве государственного стандарта Российской Федерации 1 января 1997 г.
5 ВЗАМЕН ГОСТ 27.410-87 (в части п.2)
1 Область применения
Настоящий стандарт устанавливает общие правила расчета надежности технических объектов, требования к методикам и порядок представления результатов расчета надежности.
2 Нормативные ссылки
В настоящем стандарте использованы ссылки на следующие стандарты:
ГОСТ 2.102-68 Единая система конструкторской документации. Виды и комплектность конструкторских документов
ГОСТ 27.002-89 Надежность в технике. Основные понятия. Термины и определения
ГОСТ 27.003-90 Надежность в технике. Состав и общие правила задания требований по надежности
ГОСТ 27.310-95 Надежность в технике. Анализ видов, последствий и критичности отказов. Основные положения
3 Определения
В настоящем стандарте применены общие термины в области надежности, определения которых установлены ГОСТ 27.002. Дополнительно в стандарте применены следующие термины, относящиеся к расчету надежности.
3.1. расчет надежности: Процедура определения значений показателей надежности объекта с использованием методов, основанных на их вычислении по справочным данным о надежности элементов объекта, по данным о надежности объектов-аналогов, данным о свойствах материалов и другой информации, имеющейся к моменту расчета.
3.2 прогнозирование надежности: Частный случай расчета надежности объекта на основе статистических моделей, отражающих тенденции изменения надежности объектов-аналогов и/или экспертных оценок.
3.3 элемент: Составная часть объекта, рассматриваемая при расчете надежности как единое целое, не подлежащее дальнейшему разукрупнению.
4 Основные положения
4.1 Порядок расчета надежности
Надежность объекта рассчитывают на стадиях жизненного цикла и соответствующих этим стадиям этапах видов работ, установленных программой обеспечения надежности (ПОН) объекта или документами, ее заменяющими.
ПОН должна устанавливать цели расчета на каждом этапе видов работ, применяемые при расчете нормативные документы и методики, сроки выполнения расчета и исполнителей, порядок оформления, представления и контроля результатов расчета.
4.2 Цели расчета надежности
Расчет надежности объекта на определенном этапе видов работ, соответствующем некоторой стадии его жизненного цикла, может иметь своими целями:
обоснование количественных требований по надежности к объекту или его составным частям;
проверку выполнимости установленных требований и/или оценка вероятности достижения требуемого уровня надежности объекта в установленные сроки и при выделенных ресурсах, обоснование необходимых корректировок установленных требований;
сравнительный анализ надежности вариантов схемно-конструктивного построения объекта и обоснование выбора рационального варианта;
определение достигнутого (ожидаемого) уровня надежности объекта и/или его составных частей, в том числе расчетное определение показателей надежности или параметров распределения характеристик надежности составных частей объекта в качестве исходных данных для расчета надежности объекта в целом;
обоснование и проверку эффективности предлагаемых (реализованных) мер по доработкам конструкции, технологии изготовления, системы технического обслуживания и ремонта объекта, направленных на повышение его надежности;
решение различных оптимизационных задач, в которых показатели надежности выступают в роли целевых функций, управляемых параметров или граничных условий, в том числе таких, как оптимизация структуры объекта, распределение требований по надежности между показателями отдельных составляющих надежности (например безотказности и ремонтопригодности), расчет комплектов ЗИП, оптимизация систем технического обслуживания и ремонта, обоснование гарантийных сроков и назначенных сроков службы (ресурса) объекта и др.;
проверку соответствия ожидаемого (достигнутого) уровня надежности объекта установленным требованиям (контроль надежности), если прямое экспериментальное подтверждение их уровня надежности невозможно технически или нецелесообразно экономически.
4.3 Общая схема расчета
4.3.1 Расчет надежности объектов в общем случае представляет собой процедуру последовательного поэтапного уточнения оценок показателей надежности по мере отработки конструкции и технологии изготовления объекта, алгоритмов его функционирования, правил эксплуатации, системы технического обслуживания и ремонта, критериев отказов и предельных состояний, накопления более полной и достоверной информации о всех факторах, определяющих надежность, и применения более адекватных и точных методов расчета и расчетных моделей.
4.3.2 Расчет надежности на любом этапе видов работ, предусмотренном планом ПОН, включает:
идентификацию объекта, подлежащего расчету;
определение целей и задач расчета на данном этапе, номенклатуры и требуемых значений рассчитываемых показателей надежности;
выбор метода(ов) расчета, адекватного(ых) особенностям объекта, целям расчета, наличию необходимой информации об объекте и исходных данных для расчета;
составление расчетных моделей для каждого показателя надежности;
получение и предварительную обработку исходных данных для расчета, вычисление значений показателей надежности объекта и, при необходимости, их сопоставление с требуемыми;
оформление, представление и защиту результатов расчета.
4.4 Идентификация объекта
4.4.1 Идентификация объекта для расчета его надежности включает получение и анализ следующей информации об объекте, условиях его эксплуатации и других факторах, определяющих его надежность:
назначение, области применения и функции объекта;
критерии качества функционирования, отказов и предельных состояний, возможные последствия отказов (достижения объектом предельного состояния) объекта;
структура объекта, состав, взаимодействие и уровни нагруженноcти входящих в него элементов, возможность перестройки структуры и/или алгоритмов функционирования объекта при отказах отдельных его элементов;
наличие, виды и способы резервирования, используемые в объекте;
типовая модель эксплуатации объекта, устанавливающая перечень возможных режимов эксплуатации и выполняемых при этом функций, правила и частоту чередования режимов, продолжительность пребывания объекта в каждом режиме и соответствующие наработки, номенклатуру и параметры нагрузок и внешних воздействий на объект в каждом режиме;
планируемая система технического обслуживания (ТО) и ремонта объекта, характеризуемая видами, периодичностью, организационными уровнями, способами выполнения, техническим оснащением и материально-техническим обеспечением работ по его ТО и ремонту;
распределение функций между операторами и средствами автоматического диагностирования (контроля) и управления объектом, виды и характеристики человеко-машинных интерфейсов, определяющих параметры работоспособности и надежности работы операторов;
уровень квалификации персонала;
качество программных средств, применяемых в объекте;
планируемые технология и организация производства при изготовлении объекта.
4.4.2 Полнота идентификации объекта на рассматриваемом этапе расчета его надежности определяет выбор соответствующего метода расчета, обеспечивающего приемлемую на данном этапе точность при отсутствии или невозможности получения части информации, предусмотренной 4.4.1.
4.4.3 Источниками информации для идентификации объекта служит конструкторская, технологическая, эксплуатационная и ремонтная документация на объект в целом, его составные части и комплектующие изделия в составе и комплектах, соответствующих данному этапу расчета надежности.
4.5.1 Методы расчета надежности подразделяют:
по составу рассчитываемых показателей надежности (ПН);
по основным принципам расчета.
4.5.2 По составу рассчитываемых показателей различают методы расчета:
комплексных показателей надежности (методы расчета коэффициентов готовности, технического использования, сохранения эффективности и др.).
4.5.3 По основным принципам расчета свойств, составляющих надежность, или комплексных показателей надежности объектов различают:
структурные методы расчета,
физические методы расчета.
Структурные методы расчета основаны на представлении объекта в виде логической (структурно-функциональной) схемы, описывающей зависимость состояний и переходов объекта от состояний и переходов его элементов с учетом их взаимодействия и выполняемых ими функций в объекте с последующими описаниями построенной структурной модели адекватной математической моделью и вычислением ПН объекта по известным характеристикам надежности его элементов.
Физические методы расчета основаны на применении математических моделей, описывающих физические, химические и иные процессы, приводящие к отказам объектов (к достижению объектами предельного состояния), и вычислении ПН по известным параметрам нагруженности объекта, характеристикам примененных в объекте веществ и материалов с учетом особенностей его конструкции и технологии изготовления.
«Надежность и безотказность как в Google» — и не только: перевод статьи «Расчёт надёжности сервиса»
Главная задача коммерческих (да и некоммерческих тоже) сервисов — быть всегда доступными для пользователя. Хотя сбои случаются у всех, вопрос в том, что делает IT-команда для их минимизации. Мы перевели статью Бена Трейнора, Майка Далина, Вивек Рау и Бетси Бейер «Расчёт надёжности сервиса», в которой рассказывается, в том числе, на примере Google, почему 100% — неверный ориентир для показателя надежности, что такое «правило четырёх девяток» и как на практике математически прогнозировать допустимость крупных и мелких отключений сервиса и\или его критических компонентов — ожидаемое количество простоя, время обнаружения сбоя и время восстановления сервиса.
Расчет надежности сервиса
Ваша система надежна настолько, насколько надежны её компоненты
Как описано в книге «Site Reliability Engineering: Надежность и безотказность как в Google» (далее — книга SRE), разработка продуктов и сервисов Google может достигать высокой скорости выпуска новых функций, сохраняя при этом агрессивные SLO (service-level objectives, цели уровня обслуживания) для обеспечения высокой надежности и быстрого реагирования. SLO требуют, чтобы сервис почти всегда был в исправном состоянии и почти всегда был быстрым. При этом SLO также указывают точные значения этого «почти всегда» для конкретного сервиса. SLO основаны на следующих наблюдениях:
В общем случае для любого программного сервиса или системы 100% — неверный ориентир для показателя надежности, поскольку ни один пользователь не сможет заметить разницу между 100%-ной и 99,999%-ной доступностью. Между пользователем и сервисом находится множество других систем (его ноутбук, домашний Wi-Fi, провайдер, электросеть. ), и все эти системы в совокупности доступны не в 99,999% случаев, а гораздо реже. Поэтому разница между 99,999% и 100% теряется на фоне случайных факторов, обусловленных недоступностью других систем, и пользователь не получает никакой пользы от того, что мы потратили кучу сил, добиваясь этой последней доли процента доступности системы. Серьёзными исключениями из этого правила являются антиблокировочные системы управления тормозами и кардиостимуляторы!
Подробное обсуждение того, как SLO соотносятся со SLI (service-level indicators, индикаторы уровня обслуживания) и SLA (service-level agreements, соглашения об уровне обслуживания), смотрите в главе «Целевой уровень качества обслуживания» книги SRE. В этой главе также подробно описывается, как выбрать метрики, имеющие значение для конкретного сервиса или системы, что, в свою очередь, определяет выбор соответствующего SLO для этого сервиса или системы.
Эта статья расширяет тему SLO, чтобы сосредоточиться на составных частях сервисов. В частности, мы рассмотрим, как надежность критических компонентов влияет на надежность сервиса, а также как проектировать системы так, чтобы смягчить влияние или сократить количество критически важных компонентов.
Большинство сервисов, предлагаемых Google, направлены на обеспечение 99,99-процентной (иногда называемой «четыре девятки») доступности для пользователей. Для некоторых сервисов в пользовательском соглашении указывается более низкое число, однако внутри компании сохраняются целевые 99.99%. Эта более высокая планка дает преимущество в ситуациях, когда пользователи высказывают недовольство производительностью сервиса задолго до случая нарушения условий соглашения, поскольку цель № 1 команды SRE состоит в том, чтобы пользователи были довольны сервисами. Для многих сервисов внутренняя цель 99,99% представляет собой «золотую середину», которая уравновешивает стоимость, сложность и надежность. Для некоторых других, в частности глобальных облачных сервисов, внутренняя цель составляет 99,999%.
Надежность 99.99%: наблюдения и выводы
Давайте рассмотрим несколько ключевых наблюдений и выводов о проектировании и эксплуатации сервиса с надежностью 99,99%, а затем перейдем к практике.
Наблюдение № 1: Причины сбоев
Сбои происходят по двум основным причинам: проблемы с самим сервисом и проблемы с критическими компонентами сервиса. Критический компонент — это компонент, который в случае сбоя вызывает соответствующий сбой в работе всего сервиса.
Наблюдение № 2: Математика надежности
Надежность зависит от частоты и продолжительности простоев. Она измеряется через:
Вывод № 1: Правило дополнительных девяток
Сервис не может быть надежнее всех его критических компонентов вместе взятых. Если ваш сервис стремится обеспечить доступность на уровне 99,99%, то все критические составные части должны быть доступны значительно больше, чем 99,99% времени.
Внутри Google мы используем следующее эмпирическое правило: критические компоненты должны обеспечивать дополнительные девятки по сравнению с заявленной надёжностью вашего сервиса — в примере выше 99,999-процентную доступность — потому что любой сервис будет иметь несколько критических компонентов, а также свои собственные специфические проблемы. Это называется «правилом дополнительных девяток».
Если у вас есть критический компонент, который не обеспечивает достаточно девяток (относительно распространенная проблема!), вы должны минимизировать отрицательные последствия.
Вывод № 2: Математика частоты, времени обнаружения и времени восстановления
Сервис не может быть надежнее, чем произведение частоты инцидентов на время обнаружения и восстановления. Например, три полных отключения в год по 20 минут приводят в общей сложности к 60 минутам простоя. Даже если бы сервис работал отлично в остальное время года, 99,99-процентная надежность (не более 53 минут простоя в год) стала бы невозможной.
Это простое математическое наблюдение, но его часто упускают из виду.
Заключение из выводов № 1 и № 2
Если уровень надежности, на который полагается ваш сервис, не может быть достигнут, необходимо предпринять усилия для исправления ситуации — либо путем повышения уровня доступности службы, либо путем минимизации отрицательных последствий, как описано выше. Снижение ожиданий (т. е., объявленной надежности) тоже вариант, и зачастую — самый верный: дайте понять зависимому от вас сервису, что он должен либо перестроить свою систему, чтобы компенсировать погрешность в надежности вашей службы, либо сократить свои собственные цели уровня обслуживания. Если вы сами не устраните несоответствие, достаточно длительный выход системы из строя неизбежно потребует корректировок.
Практическое применение
Давайте рассмотрим пример сервиса с целевой надежностью в 99,99% и проработаем требования как к его компонентам, так и к работе с его сбоями.
Цифры
Предположим, что ваш 99,99-процентно доступный сервис имеет следующие характеристики:
Математический расчет надежности будет выглядеть следующим образом:
Требования к компонентам
Требования к реагированию на отключения
Вывод: рычаги для увеличения надежности сервиса
Стоит внимательно посмотреть на представленные цифры, потому что они подчеркивают фундаментальный момент: есть три основных рычага, для увеличения надежности сервиса.
Уточнение «Правила дополнительных девяток» для вложенных компонентов
Случайный читатель может сделать вывод, что каждое дополнительное звено в цепочке зависимостей требует дополнительных девяток, так что для зависимостей второго порядка требуется две дополнительные девятки, для зависимостей третьего порядка — три дополнительные девятки и т. д.
Это неверный вывод. Он основан на наивной модели иерархии компонентов в виде дерева с постоянным разветвлением на каждом уровне. В такой модели, как показано на рис. 1, имеется 10 уникальных компонентов первого порядка, 100 уникальных компонентов второго порядка, 1 000 уникальных компонентов третьего порядка и т. д., что приводит к созданию в общей сложности 1 111 уникальных сервисов, даже если архитектура ограничена четырьмя слоями. Экосистема высоконадежных сервисов с таким количеством независимых критических компонентов явно нереалистична.
Рис. 1 — Иерархия компонентов: Неверная модель
Критический компонент сам по себе может вызвать сбой всего сервиса (или сегмента сервиса) независимо от того, где он находится в дереве зависимостей. Поэтому, если данный компонент X отображается как зависимость нескольких компонентов первого порядка, X следует считать только один раз, так как его сбой в конечном итоге приведет к сбою службы независимо от того, сколько промежуточных сервисов будут также затронуты.
Корректное прочтение правила выглядит следующим образом:
Рис. 2 — Компоненты в иерархии
Например, рассмотрим гипотетический сервис A с лимитом ошибок 0,01 процента. Владельцы сервиса готовы потратить половину этого лимита на собственные ошибки и потери, а половину — на критические компоненты. Если сервис имеет N таких компонентов, то каждый из них получает 1/N оставшегося лимита ошибок. Типичные сервисы часто имеют от 5 до 10 критических компонентов, и поэтому каждый из них может отказать только в одной десятой или одной двадцатой степени от лимита ошибок Сервиса A. Следовательно, как правило, критические части сервиса должны иметь одну дополнительную девятку надежности.
Лимиты ошибок
Концепция лимитов ошибок довольно подробно освещена в книге SRE, но и здесь следует ее упомянуть. SR-инженеры Google используют лимиты ошибок, чтобы сбалансировать надежность и темпы внедрения обновлений. Этот лимит определяет допустимый уровень отказа для сервиса в течение некоторого периода времени (обычно — месяц). Лимит ошибок — это просто 1 минус SLO сервиса, поэтому ранее обсуждавшаяся 99,99-процентно доступная служба имеет 0,01% «лимита» на ненадежность. До тех пор, пока сервис не израсходовал свой лимит ошибок в течение месяца, команда разработчиков свободна (в пределах разумного) запускать новые функции, обновления и т. д.
Если лимит ошибок израсходован, внесение изменений в сервис приостанавливается (за исключением срочных исправлений безопасности и изменений, направленных на то, что вызвало нарушение в первую очередь), пока служба не восполнит запас в лимите ошибок или пока не сменится месяц. Многие сервисы в Google используют метод скользящего окна для SLO, чтобы лимит ошибок восстанавливался постепенно. Для серьёзных сервисов с SLO более 99,99%, целесообразно применять ежеквартальное, а не ежемесячное обнуление лимита, поскольку количество допустимых простоев у них невелико.
Лимиты ошибок устраняют напряженность в отношениях между отделами, которая в противном случае могла бы возникнуть между SR-инженерами и разработчиками продукта, предоставляя им общий, основанный на данных механизм оценки риска запуска продукта. Они также дают и SR-инженерам, и командам разработки общую цель развития методов и технологий, которые позволят внедрять нововведения быстрее и запускать продукты без «раздувания бюджета».
Стратегии сокращения и смягчения влияния критических компонентов
К данному моменту, в этой статье мы установили, что можно назвать «Золотым правилом надежности компонентов». Это значит, что надежность любого критического компонента должна в 10 раз превышать целевой уровень надежности всей системы, чтобы его вклад в ненадежность системы оставался на уровне погрешности. Отсюда следует, что в идеальном варианте задача состоит в том, чтобы сделать как можно больше компонентов некритическими. Это означает, что компоненты могут придерживаться более низкого уровня надежности, давая разработчикам возможность вводить новшества и идти на риск.
Наиболее простой и очевидной стратегией уменьшения критических зависимостей является устранение единых точек отказа (SPOF, single points of failure) всегда, когда это возможно. Более крупная система должна быть в состоянии работать приемлемо без какого-либо заданного компонента, который не является критической зависимостью или SPOF.
На самом деле, вы, скорее всего, не можете избавиться от всех критических зависимостей; но вы можете следовать некоторым рекомендациям по проектированию системы для оптимизации надежности. Хотя это не всегда возможно, проще и эффективнее достичь высокой надежности системы, если вы закладываете надежность на этапах проектирования и планирования, а не после того, как система работает и влияет на фактических пользователей.
Оценка структуры проекта
При планировании новой системы или сервиса, а также при перепроектировании или улучшении существующей системы или сервиса, обзор архитектуры или проекта может выявить общую инфраструктуру, а также внутренние и внешние зависимости.
Разделяемая инфраструктура
Если ваш сервис использует разделяемую инфраструктуру (например, сервис основной базы данных, используемый несколькими продуктами доступными пользователям), подумайте, правильно ли используется эта инфраструктура. Четко определите владельцев разделяемой инфраструктуры в качестве дополнительных участников проекта. Кроме того, остерегайтесь перегрузки компонентов — для этого тщательно координируйте процесс запуска с владельцами этих компонентов.
Внутренние и внешние зависимости
Иногда продукт или сервис зависит от факторов вне контроля вашей компании — например, от программных библиотек или услуг и данных третьих сторон. Выявление этих факторов позволит минимизировать непредсказуемые последствия их использования.
Планируйте и проектируйте системы внимательно
При проектировании вашей системы обращайте внимание на следующие принципы:
Резервирование и изоляция
Можно попытаться сократить влияние критического компонента, создав несколько его независимых экземпляров. Например, если хранение данных в одном экземпляре обеспечивает 99,9-процентную доступность этих данных, то хранение трех копий в трех широко рассредоточенных экземплярах обеспечит, в теории, уровень доступности равный 1 — 0,013 или девять девяток, если сбои экземпляра независимы при нулевой корреляции.
В реальном мире корреляция никогда не равна нулю (рассмотрите сбои магистральной сети, которые влияют на многие ячейки одновременно), таким образом, фактическая надежность никогда не приблизится к девяти девяткам, но намного превысит три девятки.
Аналогично, отправка RPC (remote procedure call, удаленный вызов процедур) в один пул серверов в одном кластере может обеспечить 99-процентную доступность результатов, в то время как отправка трех одновременных RPC в три разных пула серверов и принятие первого поступившего ответа помогает достигнуть уровня доступности выше чем три девятки (см. выше). Эта стратегия также может сократить «хвост» задержки времени ответа, если пулы серверов равноудалены от отправителя RPC. (Поскольку стоимость отправки трех RPC одновременно высока, Google часто стратегически распределяет время этих вызовов: большинство наших систем ожидают часть выделенного времени перед отправкой второго RPC и немного больше времени перед отправкой третьего RPC.)
Резерв и его применение
Настройте запуск и перенос программного обеспечения так, чтобы системы продолжали работать при отказе отдельных частей (fail safe) и изолировались при возникновении проблем автоматически. Основной принцип здесь в том, что к тому времени, когда вы подключите человека для включения резерва, вы, вероятно, уже превысите свой лимит ошибок.
Асинхронность
Чтобы компоненты не становились критическими, проектируйте их асинхронными везде, где это возможно. Если сервис ожидает ответного RPC от одной из своих некритических частей, которая демонстрирует резкое замедление времени ответа, это замедление без нужды ухудшит показатели родительского сервиса. Установка RPC для некритического компонента в режим асинхронности освободит показатели времени ответа родительской службы от привязки к показателям этого компонента. И хотя асинхронность может усложнить код и инфраструктуру сервиса, все же этот компромисс стоит того.
Планирование ресурсов
Убедитесь, что все компоненты обеспечены всем необходимым. Если сомневаетесь, лучше обеспечить избыточный резерв — но без увеличения расходов.
Конфигурация
По возможности стандартизируйте конфигурацию компонентов, чтобы минимизировать расхождения между подсистемами и избежать одноразовых режимов отказа \ обработки ошибок.
Обнаружение и устранение неполадок
Сделайте обнаружение ошибок, устранение неполадок и диагностику проблем максимально простыми. Эффективный мониторинг является важнейшим фактором своевременного выявления проблем. Диагностировать систему с глубоко встроенными компонентами крайне сложно. Всегда держите наготове такой способ нивелировать ошибки, который не требует детального вмешательства дежурного.
Быстрый и надежный откат в предыдущее состояние
Включение ручной работы дежурных в план по устранению последствий сбоев существенно снижает возможность выполнить жесткие цели SLO. Выстраивайте системы, которые смогут легко, быстро и бесперебойно вернуться к предыдущему состоянию. По мере того, как ваша система совершенствуется, и уверенность в вашем способе мониторинга растет, вы можете снизить MTTR разработав систему автоматического запуска безопасных откатов.
Систематически проверяйте все возможные режимы отказа
Изучите каждый компонент и определите, как сбой в его работе может повлиять на всю систему. Задайте себе следующие вопросы:
Проведите тщательное тестирование
Разработайте и внедрите развитую среду тестирования, которая будет гарантировать, что каждый компонент покрыт тестами, включающими в себя основные сценарии использования этого компонента другими составляющими среды. Вот несколько рекомендуемых стратегий для такого тестирования:
План на будущее
Ожидайте изменений, связанных с масштабированием: сервис, начинавшийся как относительно простой двоичный файл на одном компьютере, может обрасти множеством очевидных и неочевидных зависимостей при развертывании в большем масштабе. Каждый порядок масштаба выявит новые сдерживающие факторы — не только для вашего сервиса, но и для ваших зависимостей. Подумайте, что произойдет, если ваши зависимости не смогут масштабироваться так быстро, как вам нужно.
Также имейте в виду, что системные зависимости со временем развиваются и список зависимостей может со временем увеличиваться. Когда дело доходит до инфраструктуры, типичная рекомендация Google заключается в создании системы, которая будет масштабироваться до 10 раз от начальной целевой нагрузки без значительных изменений в архитектуре.
Заключение
В то время как читатели, вероятно, знакомы с некоторыми или многими понятиями, описанными в этой статье, конкретные примеры их использования помогут лучше разобраться в их сущности и передать это знание другим. Наши рекомендации непросты, но не недостижимы. Ряд сервисов Google неоднократно демонстрировали надежность выше четырех девяток не за счет сверхчеловеческих усилий или интеллекта, но благодаря продуманному применению принципов и передовых практик, выработанных в течение многих лет (см. книга SRE, Приложение B: Практические рекомендации для сервисов в промышленной эксплуатации).