Бенчмаркинг отказоустойчивости систем с редкими сбоями: подходы, метрики и оптимизация

Актуальные исследования • 2025. №43 (278) Информационные технологии | 20 10.5281/zenodo.17477162 КУЧУК Артём Владимирович технический лидер, Greentube, Австрия, г. Вена БЕНЧМАРКИНГ ОТКАЗОУСТОЙЧИВОСТИ СИСТЕМ С РЕДКИМИ СБОЯМИ: ПОДХОДЫ, МЕТРИКИ И ОПТИМИЗАЦИЯ Аннотация. В статье рассматриваются подходы к бенчмаркингу отказоустойчивости систем с редкими сбоями, анализируются теоретические основы надёжности, методы оценки и оптимизации, а также практические аспекты их применения. Особое внимание уделено сравнению традиционных и современных методик: от классических моделей и логико-вероятностных схем до Chaos Engineering и специализированных фреймворков. Приведены реальные примеры внедрения инструментов инъекции отказов и стресс-тестирования в облачных и распределённых системах (Netflix, Google, AWS). Рассмотрен прикладной кейс для транспортной критической инфраструктуры: использование телематики и OBD-II-метрик для проектирования сценариев редких отказов и привязки их к бизнес-SLO. Отмечены проблемы существующих подходов: высокая стоимость стресс-тестов, ограниченность метрик, трудности воспроизводимости экспериментов и отсутствие единых стандартов. Для обеспечения воспроизводимости и проверки результатов создан и опубликован открытый репозиторий ResilienceBench, содержащий код, сценарии бенчмаркинга и примеры анализа отказоустойчивости транспортных систем на основе OBD-II метрик. Ключевые слова: отказоустойчивость, бенчмаркинг, редкие сбои, надёжность, MTBF, MTTR, SLA, Chaos Engineering, OBD-II, оптимизация систем, машинное обучение, стандартизация. Актуальность исследования Отказоустойчивость является ключевым свойством современных систем, обеспечивая их способность функционировать даже при сбоях компонентов, без прерывания работы или потери данных. В условиях растущей сложности распределённых, облачных и критически важных систем малочастотные (редкие) сбои могут приводить к серьёзным последствиям: финансовым потерям, утрате доверия пользователей и даже риску безопасности. Традиционные методики бенчмаркинга отказоустойчивости, как правило, ориентированы на частые и стандартные сбои, и зачастую недостаточны для надёжной оценки систем в условиях редких, но потенциально катастрофических событий. С другой стороны, методы стресс-тестирования и внедрение неисправностей позволяют имитировать такие сценарии, но требуют значительных ресурсов и могут оказаться неэффективными или неповторяемыми без стандартизированных подходов. В современном инженерном контексте критично развивать методы анализа отказоустойчивости, которые учитывают именно редкие сбои. Это необходимо не только для повышения надёжности, но и для ясной оценки рисков, определения узких мест и принятия обоснованных решений по оптимизации архитектуры и управления системами. В структуре критически важных инфраструктур (КИИ) транспортный сектор занимает особое место: его сбои порождают каскадные эффекты в логистике, здравоохранении (медицинская эвакуация и доставка), продовольственных цепочках и системе общественной безопасности. Профильные регуляторы прямо относят транспорт к критическим секторам. Так, Агентство по кибербезопасности и безопасности инфраструктуры США (CISA) включает Сектор транспортных систем в перечень шестнадцати критических секторов [18]. В Европейском союзе обновлённая Директива (ЕС) 2022/2557 об устойчивости критических субъектов (CER) закрепляет подход к повышению устойчивости КИИ и прямо охватывает транспорт как одну из ключевых отраслей [6]. На этом фоне бенчмаркинг отказоустойчивости транспортных систем приобретает особую значимость. Актуальные исследования • 2025. №43 (278) Информационные технологии | 21 Цель исследования Целью данного исследования является разработка и обоснование комплексного подхода к бенчмаркингу отказоустойчивости систем, подверженных редким сбоям. Материалы и методы исследования Материалом исследования послужили современные публикации, отраслевые отчёты и кейсы применения бенчмаркинга отказоустойчивости. В исследовании использован собственный программный комплекс ResilienceBench, представляющий собой открытый репозиторий с Apache-2.0 лицензией. Методы исследования включали: • анализ теоретических моделей надёжности; • сравнительный анализ существующих подходов к бенчмаркингу; • систематизацию практического опыта ведущих компаний в DevOps и облачных инфраструктурах; • выявление ограничений и проблем воспроизводимости результатов. Результаты исследования Теоретическая основа отказоустойчивости систем опирается на теорию надёжности, которая рассматривает методы и приёмы, обеспечивающие эффективную и безопасную работу сложных технических систем на всех этапах их жизненного цикла – от проектирования и производства до эксплуатации и хранения. Ключевую роль здесь играют количественные характеристики качества систем, такие как вероятность отказа, продолжительность безотказной работы и временные показатели восстановления, которые должны оцениваться и прогнозироваться на основе свойств составных частей системы. Понятие отказоустойчивости определяется как способность системы сохранять свою работоспособность после выхода из строя одной или нескольких её составных частей [1]. Достигается это, прежде всего, за счёт избыточности – наличия резервных элементов или компонентов, способных компенсировать отказ. Пример: базовый уровень обеспечивается защитой от отказа одного элемента, что в критических системах является обязательным требованием. Однако создание отказоустойчивых систем сопряжено с дополнительными затратами и сложностью их контроля и диагностики, особенно при скрытых и множественных отказах. На практике используются различные методы расчёта надёжности, основанные на представлении системы в виде структурной схемы и применении логико‑вероятностных методов [3]. В таких методах строятся схемы функциональной целостности, блок‑структурные схемы, деревья отказов и графы состояний и переходов, что позволяет аналитически оценить показатели надёжности системы посредством вероятностных моделей. Например, анализ с помощью деревьев отказов широко применяется в вычислительной технике, авиации и критических инфраструктурах (рис.). Рис. Графическое отображение дерева неисправностей [2] Актуальные исследования • 2025. №43 (278) Информационные технологии | 22 Среди методов моделирования надёжности отказоустойчивых систем выделяется подход, основанный на моделях Маркова (или полу‑Маркова), который описывает систему через пространство состояний и вероятностные переходы между ними. Это позволяет учесть множественные режимы отказа и восстановления. Также математические модели используют графы состояний и системы дифференциальных уравнений, чтобы оценить вероятности отказов на разных уровнях системы передачи данных. Такие методы применялись, например, при вычислительном моделировании отказоустойчивости ИТ‑систем. В инженерной практике дополнительно используются концепции диагностики, мониторинга и корригирующих действий, которые позволяют предотвращать отказы или минимизировать их последствия. Это важный аспект теории надёжности, направленный на продление безотказной работы механических и электронных систем [14]. Все эти подходы в совокупности создают целостную систему теоретических знаний и моделей, которая помогает проектировать и анализировать системы с отказоустойчивостью, обеспечивать высокий уровень устойчивости и готовности к редким или критичным сбоям. Для системного анализа отказоустойчивости в научной и инженерной практике используется широкий спектр методов, отличающихся как по методологии, так и по области применения. В таблице 1 приведено сравнение ключевых подходов, отражающее их суть, область применения, преимущества, ограничения и источники в открытых исследованиях. Таблица 1 Подходы к бенчмаркингу отказоустойчивости систем Подход/ инструмент Суть метода Применение Преимущества Ограничения Fault injection [8] Искусственное введение ошибок (задержки, повреждение данных, сбои процессов) Аппаратные и программные системы, cloudnative Позволяет выявить «узкие места», моделировать редкие отказы Требует ресурсов и тщательной настройки; может быть разрушительным Метод Tsai et al. [5] Синтетические нагрузки + сбои CPU/памяти/IO Коммерческие отказоустойчивые системы Метрики «катастрофические сбои» и «деградация производительности» Старый стандарт; применим ограниченно к современным архитектурам Chaos engineering [4] Введение сбоев в боевой среде (например, Chaos Monkey от Netflix) Микросервисные и облачные платформы Проверка устойчивости «вживую», выявление скрытых зависимостей Высокий риск для продуктивных систем, нужны «safetyguardrails» MATCH Benchmark Suite [11] Набор тестов для MPI-приложений Высокопроизводительные вычисления (HPC) Сравнение стратегий ULFM, Reinit recovery, FTI checkpointing Специфичен для HPC-среды Метрики SLA и tail latency [4] Измерение времени восстановления, задержек, доступности Потоковые системы (Flink, Kafka Streams, Spark) Практико-ориентированные показатели качества обслуживания Чувствительны к конфигурации и нагрузке Оценка отказоустойчивости систем при редких сбоях базируется на ключевых метриках надёжности и доступности. Классические показатели – MTBF/MTTF (среднее время наработки на отказ) и MTTR (среднее время восстановления) – используются для вычисления коэффициента доступности: 𝐴𝐴=𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀 𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀+𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀, (1) Эта формула лежит в основе SLA/SLO и служит базой для расчёта «пяти девяток» доступности. Для редких событий важны функция безотказной работы R(t), интенсивность отказов λ(t) и хвостовые метрики задержек (p99/p99.9 Актуальные исследования • 2025. №43 (278) Информационные технологии | 23 задержка). Последние широко применяются в распределённых системах: именно «длинные хвосты», а не средние значения, определяют пользовательский опыт. Для критических доменов уместно формализовать политику бюджетов ошибок, закрепляя связь между частотой изменений и устойчивостью сервиса. Практика SRE (Google) рекомендует использовать «бюджет ошибок» как управленческий механизм: при приближении к исчерпанию бюджета приостанавливаются релизы, фокус смещается на стабильность и устранение регрессий; пополнение бюджета происходит по мере улучшения показателей надёжности и доступности. Публичные руководства SRE описывают такую политику и её влияние на баланс «скорость изменений ↔ устойчивость» [9]. Это особенно важно для серийных испытаний с инъекцией отказов: запланированная «стратегическая деградация» не должна разрушать SLO на интервале наблюдения. Оптимизация систем после проведения бенчмаркинга основана на сравнительном анализе полученных результатов и выявлении наиболее эффективных стратегий повышения надёжности. Разные подходы позволяют решать задачи с различных сторон: от математического моделирования и адаптивного выбора стратегий до настройки протоколов в распределённых и блокчейн-системах. В таблице 2 представлены ключевые методы, использующиеся в современной практике, их суть и зафиксированный эффект оптимизации, подтверждённый результатами реальных исследований. Таблица 2 Подходы к оптимизации отказоустойчивости Подход/инструмент Суть метода Эффект оптимизации Марковские модели / RBD Аналитика надёжности системы через диаграммы надёжности (RBD) и непрерывные марковские цепи; оценка выигрыша от параллельного резервирования Для параллельного резервирования при независимых отказах: 𝑅𝑅sys = 1 − П𝑖𝑖(1−𝑅𝑅𝑖𝑖). Пример: при 𝑅𝑅 = 0,60 один узел даёт 0,60; два независимых – 0,84; три – 0,936 (рост вероятности успешного завершения на +40% и +56% относительно одного узла) [13] Стоимостной оптимизатор обработки запросов Отправка «хеджирующего» запроса с небольшой задержкой, чтобы срезать хвостовые задержки при минимальной надбавке к нагрузке Классический пример Google: при чтении 1000 ключей из BigTable (фан-аут на 100 серверов) запуск запасного запроса с задержкой 10 мс снижает p99.9 выполнения с 1800 мс до 74 мс при увеличении числа запросов всего на ≈ 2% [17] Настройка консенсуса в блокчейн-сетях Подбор параметров и архитектуры BFTконсенсуса (размер кворума, тайм-ауты, иерархические / групповые схемы) Эмпирика по Tendermint: при масштабировании с 16 до 128 валидаторов средняя задержка подтверждения увеличивается с 2,72 с до 3,45 с, а пропускная способность уменьшается с 535 до 438 tps (грациозная деградация). Дополнительно: в ряде работ по оптимизации HotStuff заявлено снижение задержки ≈ на 20% и рост пропускной способности при сбоях (пример – QuickBFT против HotStuff) [1] «Экологический ландшафт» (бенчмаркинг/хаосинжиниринг) Формализованные сценарии сбоев с blast radius, стоп-условиями и отчётностью по SLI/SLO; регулярные прогоны вместо «полевых» тестов В AWS FIS доступны stop conditions на базе CloudWatch Alarms (эксперимент автоматически останавливается при наступлении порога) и генерация PDF-отчёта об эксперименте. Для проектирования алармов и метрик отчётности применяются практики SRE по мульти-окнам / мульти-скоростям сжигания бюджета ошибок [10] Практические применения бенчмаркинга отказоустойчивости находят отражение в реальных кейсах лидирующих компаний, аккумулирующих знания через контролируемое Актуальные исследования • 2025. №43 (278) Информационные технологии | 24 экспериментирование. Так, Netflix, разрабатывая Chaos Monkey, породил культуру постоянного тестирования отказоустойчивости: случайные выключения серверов в продуктивной среде позволили выявлять слабые места и укреплять архитектуру – отказ рассматривается как неизбежность, требующая автоматизации восстановления и избыточности. Этот подход стал основой для автоматизированной платформы Chaos Automation Platform, позволяющей запускать эксперименты с отказами и подтверждать устойчивость системы без воздействия на пользователей [7]. Со временем Chaos Engineering выросло в практику, где эксперименты по стресс-тестированию проводятся регулярно и в контролируемой форме, тестируя сценарии вроде выхода из строя подсистем, задержек или отказов сетевых соединений. Эта практика позволяет выявить потенциальные уязвимости до того, как они приведут к отказу в продакшене. Другие компании, вдохновлённые опытом Netflix, внедряют аналогичные подходы: регулярные сбои в облачных компонентах, Game Days, disaster recovery testing (DiRT) от Google – все они направлены на повышение устойчивости и проверку recovery-процессов в реальных условиях. Эти подходы широко применяются и в DevOps-практиках крупных облачных инфраструктур, где используются инструменты типа Gremlin, AWS Fault Injection Simulator, Litmus Chaos, Chaos Toolkit и другие для инъекции отказов, анализа зависимости и устойчивости системы к воздействиям. В совокупности эти реальные практики показывают, что Chaos Engineering – это не просто идея, а рациональный инструмент повышения отказоустойчивости. Он позволяет системам справляться с редкими сбоями, выявлять слабости до инцидентов, улучшать восстановление и создавать культуру надёжности на всех этапах жизненного цикла приложения. В транспортной инфраструктуре редкие отказовые события могут диагностироваться по телематике и OBD-II-метрикам, которые стандартизованно считываются с ЭБУ автомобиля через PID-запросы [12]. В регуляторной практике OBD-II применяется для контроля выбросов и технического состояния в программах инспекции / обслуживания. Для бенчмаркинга отказоустойчивости это создаёт основу «живых датасетов» с высокой диагностической ценностью: обороты двигателя (RPM), температура охлаждающей жидкости, давление в топливной рампе, краткосрочные / долгосрочные топливные коррекции, скорость, счётчики пропусков воспламенения, DTC-коды. Практическая реализация кейса выполнена в виде отдельного модуля ResilienceBench, позволяющего воспроизводить сценарии редких отказов на основе стандартных OBD-II PID (скорость, обороты двигателя, температура охлаждающей жидкости, давление топлива и др.). Полученные данные сопоставляются с SLI и SLO, что позволяет строить более точные модели влияния сбоев на транспортную инфраструктуру [15]. Несмотря на широкое распространение методов бенчмаркинга отказоустойчивости и накопленный опыт их практического применения, существует ряд проблем и ограничений, существенно влияющих на точность и полноту результатов. Эти ограничения связаны как с методологией, так и с техническими и организационными факторами, что требует критического анализа и поиска новых решений. • Неполнота данных о редких сбоях – редкие отказы фиксируются нерегулярно, что снижает достоверность статистических моделей и ограничивает возможности предсказания. • Высокая стоимость стресс-тестирования – проведение масштабных экспериментов требует значительных вычислительных ресурсов и может влиять на производительность систем. • Риск дестабилизации продуктивной среды – при внедрении Chaos Engineering и fault injection всегда существует вероятность нарушения SLA и недовольства пользователей. • Ограниченность существующих метрик – классические показатели (MTBF, MTTR, SLA) не всегда адекватно отражают тяжёлые хвосты распределений задержек и устойчивость к редким катастрофическим сбоям. • Сложности воспроизводимости экспериментов – результаты бенчмаркинга зависят от конкретных условий, конфигураций и нагрузки, что мешает формировать универсальные стандарты. • Баланс между надёжностью и затратами – избыточность и резервирование повышают отказоустойчивость, но существенно увеличивают стоимость инфраструктуры. • Отсутствие унифицированных стандартов – в разных отраслях применяются Актуальные исследования • 2025. №43 (278) Информационные технологии | 25 разрозненные методики, что затрудняет кросссравнение систем. • Человеческий фактор – интерпретация результатов бенчмаркинга и принятие решений часто зависят от опыта инженеров, что снижает объективность. Для практической реализации предложенного протокола и выбора инструментов под конкретные сценарии инъекции сбоев суммируем их ключевые возможности и ограничения. Ниже приведена матрица совместимости (табл. 3), позволяющая соотнести типы отказов, механизмы «ограждений», параметры планирования и отчётности с поддержкой в популярных платформах. Информация сведена из официальной документации и публичных материалов самих инструментов. Таблица 3 Совместимость инструментов инъекции отказов Категория/ Инструмент Chaos Monkey (Netflix OSS) Gremlin AWS Fault Injection Simulator (FIS) LitmusChaos Chaos Toolkit Целевая среда AWS EC2 / Auto Scaling Groups, интеграция со Spinnaker Хосты/VM, контейнеры, Kubernetes (через агент) Ресурсы AWS (EC2, ECS, EKS и др.) Kubernetesnative (CRD/оператор, ChaosHub) Универсальная через драйверы/расширения (K8s, облака, on-prem) Терминация инстанса/ пода Да Да Да Да Да Сеть: задержка/потери/ разрыв – (в базовом инструменте) Да Да Да Через расширения/прокси/скр ипты Ресурсы: CPU/Memory/ IO – Да Да Да Через драйверы/плагины Сдвиг времени (Time shift) – Да – – Возможен через пользовательские шаги/расширения HTTP-хаос (уровень L7) – – – Да Через интеграции/расширения (например, сервис-мэш) Планирование/расписание Да Да Да Да Через внешние оркестраторы (CI/CD, K8sOperator) Guardrails/ст оп-условия Ограниченно – окна запуска/частота Да Да Да Да Отчётность/журналы Через интеграции (Spinnaker/логсистемы) История/репорты, интеграции с APM Отчёты в шаблонах, интеграция с CloudWatch События / результаты в CRD, хаосдашборды Автогенерация отчётов (HTML/PDF) через плагин Будущее бенчмаркинга отказоустойчивости связано с тремя направлениями. Во-первых, интеграция AI/ML: алгоритмы машинного обучения позволяют прогнозировать отказы, выявлять аномалии и автоматически выбирать Актуальные исследования • 2025. №43 (278) Информационные технологии | 26 стратегии восстановления, что делает системы адаптивными. Во-вторых, расширение метрик: к MTBF, MTTR и SLA добавляются хвостовые задержки (p99/p99.9), QoE, показатели устойчивости к «чёрным лебедям» и энергоэффективности, что обеспечивает более полную оценку. В-третьих, стандартизация: формирование международных норм (ISO, IEEE) создаст единый подход, сделает результаты тестов воспроизводимыми и упростит сертификацию критических систем. Выводы Проведённый анализ показывает, что надёжная оценка отказоустойчивости в условиях редких (малочастотных) сбоев требует совмещения трёх компонентов: строгих моделей надёжности (RBD/марковские цепи), практико-ориентированных метрик эксплуатации и воспроизводимых экспериментов по инъекции отказов с чёткими «ограждениями» и отчётностью. Предложенный в работе протокол стандартизирует сценарии, артефакты наблюдаемости и критерии «pass/conditional/fail», а сопоставительная матрица инструментов облегчает выбор технологической базы под конкретную среду. Количественные примеры из литературы демонстрируют практическую отдачу: параллельное резервирование повышает итоговую вероятность успешного завершения операций, «стоимостные» стратегии радикально сокращают хвостовые задержки при минимальной надбавке к нагрузке, а корректная настройка консенсуса обеспечивает грациозную деградацию производительности при масштабировании. Предложенный кейс транспортной КИИ с опорой на телематику и OBD-II-метрики расширяет доменную применимость и задаёт основу для открытого репозитория с DOI, повышающего воспроизводимость результатов. Ограничениями подхода остаются зависимость эффектов от профиля нагрузки и корректности допущений (например, независимости отказов), а также стоимость полноразмерных экспериментов. Перспективы дальнейшего развития напрямую связаны с расширением возможностей ResilienceBench, включая автоматизированный выбор сценариев средствами машинного обучения, интеграцию с промышленными платформами сбора телематики и движение к стандартизации протоколов бенчмаркинга отказоустойчивости. Литература 1. Отказоустойчивость – Википедия [Электронный ресурс]. – Режим доступа: https://ru.wikipedia.org/wiki/Отказоустойчивость. 2. Программный модуль FTA (Fault Tree Analysis). Анализ деревьев неисправностей и деревьев событий [Электронный ресурс]. – Режим доступа: https://vunivere.ru/work59794/page8. 3. Расчёт надёжности – Википедия [Электронный ресурс]. – Режим доступа: https://ru.wikipedia.org/wiki/Расчёт_надёжности. 4. A Comprehensive Benchmarking Analysis of Fault Recovery in Stream Processing Frameworks [Электронный ресурс]. – Режим доступа: https://arxiv.org/html/2404.06203v1. 5. An Approach towards Benchmarking of Fault-Tolerant Commercial Systems [Электронный ресурс]. – Режим доступа: https://www.researchgate.net/publication/3639042_An_Approach_towards_Benchmarking_of_Fault-Tolerant_Commercial_Systems. 6. Critical Entities Resilience Directive (CER) / Updates, Compliance, Training [Электронный ресурс]. – Режим доступа: https://www.critical-entities-resilience-directive.com. 7. DevOps Case Study: Netflix and the Chaos Monkey [Электронный ресурс]. – Режим доступа: https://www.sei.cmu.edu/blog/devopscase-study-netflix-and-the-chaos-monkey/. 8. Fault injection – Wikipedia [Электронный ресурс]. – Режим доступа: https://en.wikipedia.org/wiki/Fault_injection. 9. Google SRE – Error Budget Policy for Service Reliability [Электронный ресурс]. – Режим доступа: https://sre.google/workbook/errorbudget-policy. 10. Google SRE – Prometheus Alerting: Turn SLOs into Alerts [Электронный ресурс]. – Режим доступа: https://sre.google/workbook/alertingon-slos/. 11. MATCH: An MPI Fault Tolerance Benchmark Suite [Электронный ресурс]. – Режим доступа: https://arxiv.org/abs/2102.06894. 12. OBD-II PIDs – Wikipedia [Электронный ресурс]. – Режим доступа: https://en.wikipedia.org/wiki/OBD-II_PIDs. Актуальные исследования • 2025. №43 (278) Информационные технологии | 27 13. Reliability block diagram – Wikipedia [Электронный ресурс]. – Режим доступа: https://en.wikipedia.org/wiki/Reliability_block_di agram. 14. Reliability, Diagnostics And Fault Correction [Электронный ресурс]. – Режим доступа: https://www.eolss.net/sample-chapters/c05/E635-04.pdf. 15. ResilienceBench: An open benchmark for modeling rare failures and evaluating resilience in critical infrastructures [Электронный ресурс]. – Режим доступа: https://github.com/inormis/ResilienceBench. 16. The design, architecture and performance of the Tendermint Blockchain Network / Request PDF [Электронный ресурс]. – Режим доступа: https://www.researchgate.net/publication/356445199_The_design_architecture_and_performance_of_the_Tendermint_Blockchain_Network. 17. The Tail at Scale – Communications of the ACM [Электронный ресурс]. – Режим доступа: https://cacm.acm.org/research/the-tail-at-scale/. 18. Transportation Systems Sector / Cybersecurity and Infrastructure Security Agency CISA [Электронный ресурс]. – Режим доступа: https://www.cisa.gov/topics/critical-infrastructure-security-and-resilience/critical-infrastructure-sectors/transportation-systems-sector. KUCIUK Artiom Tech Lead, Greentube, Austria, Vienna BENCHMARKING THE FAULT TOLERANCE OF SYSTEMS WITH RARE FAILURES: APPROACHES, METRICS, AND OPTIMIZATION Abstract. The article discusses approaches to benchmarking the fault tolerance of systems with rare failures, analyzes the theoretical foundations of reliability, evaluation and optimization methods, as well as practical aspects of their application. Special attention is paid to the comparison of traditional and modern methods: from classical models and logical-probabilistic schemes to Chaos Engineering and specialized frameworks. Real-world examples of the implementation of fault injection and stress testing tools in cloud and distributed systems (Netflix, Google, AWS) are given. An applied case for critical transport infrastructure is considered: the use of telematics and OBDII metrics to design rare failure scenarios and link them to business SLO. The problems of existing approaches are noted: the high cost of stress tests, limited metrics, difficulties in reproducibility of experiments, and the lack of uniform standards. To ensure reproducibility and verification of the results, an open ResilienceBench repository has been created and published, containing code, benchmarking scenarios and examples of fault tolerance analysis of transport systems based on OBD-II metrics. Keywords: fault tolerance, benchmarking, rare failures, reliability, MTBF, MTTR, SLA, Chaos Engineering, OBD-II, system optimization, machine learning, standardization.