Надёжность ПО (All in one) (2014), страница 10

Целевая интенсивность отказов17Отражает ожидаемое число «багов»,оставшихся в продукте послезавершения его разработкиАльтернативный способ измерениянадёжности17Целевая интенсивностьотказовИнтенсивность отказов обычноопределяется как число случившихсяотказов системы за заданное время(или аналогичными метриками):183 сигнала тревоги за 100 часов работы.5 отказов за время печати 1000документов.Интенсивность отказов системы –сумма интенсивностей отказов всех18компонентов системыКак установить целевуюинтенсивность отказов?19Оценка основывается на опыте исубъективно зависит от проектаЗависит от компромисса между качествомпродукта (временем и стоимостьюразработки) и его функциональностьюПравило большого пальца: Устанавливайцелевую интенсивность отказов исходя израсчётной итоговой стоимости проекта19Как установить целевуюинтенсивность отказов?Типичные целевые интенсивностиотказов для разных проектов:Стоимость отказаЦелевая интенсивностьотказов ()Время междуотказами> 1,000,000,000 $1 в 1,000,000,000 часов114,000 лет> 1,000,000 $1 в 1,000,000 часов114 лет> 1,000 $1 в 1,000 часов6 недель> 100 $1 в 100 часов100 часов> 10 $1 в 10 часов10 часов>1$1 в час1 час2020Целевая интенсивностьотказов и надёжностьЗависимость между целевойинтенсивностью и надёжностью1  R  ln Rλ=илиtλдля R  0.95t - интенсивность отказовR - надёжностьt - единица измерения (время, …)21При R = 0.992 за 8 часов,  = 0.00121Надёжность &Интенсивность отказовНадёжность для 1 часаработы22Интенсивность отказов0.368001 отказ в час0.90000105 отказов в 1000 часов0.959001 отказ в день0.9900010 отказов в 1000 часов0.994001 отказ в неделю0.998601 отказ в месяц0.999001 отказ в 1000 часов0.999891 отказ в год22Целевая интенсивностьотказов и доступность•Зависимость между целевойинтенсивностью отказов идоступностью:t m  - интенсивность отказов- время простоя на ошибкуЕсли система должна быть доступна 99%времени работы и время простоя 6 минут,тогда целевая интенсивность отказов равна2323 1 отказ в 10 часовЦелевая интенсивность отказов исреднее время безотказной работыЕщё одно определение доступности:24MTTRMTTFинтенсивность отказовсреднее время восстановления после отказасреднее время безотказной работы24Целевая интенсивность отказов ивероятность первого отказа25Вероятность первого отказа z(t) –вероятность сбоя в заданном временноминтервале при условии отсутствия сбоев доего наступленияВероятность первого отказа 0.05 означает,что первый отказ с вероятностью 5%произойдёт в заданном интервале и нераньше его наступленияДля экспоненциального распределенияz(t) = 25Целевая интенсивностьотказов и прибыль26Расчёт основывается на опытеаналогичных систем с помощьюсравнения их основных качественныххарактеристик и отношению к нимпользователяСравниваются тенденции измененияприоритетов развития компромиссамежду прибылью и интенсивностьюотказов26Пример27Совет: выбирайте диапазон на границевысоких прибылейИнтенсивность отказовПрибыль10000,65001,52505,810017,25021,42519,81016,327Надёжность vs.

Доступность28Зачем задавать надёжность, еслидоступность более интуитивна ипроще для понимания?Доступность субъективна для каждогопользователя и обычно существуютспособы изменения доступностисистемы без изменения её внутреннейнадёжностиПример: дублирование серверов DNSповышает доступность системы, но не28повышает надежность серверного ПОРазрабатываемое ПОСоздаваемыйпродукт –лишь частьсистемыИнтерфейсдля сторонних системПриобретённые РазработанныекомпонентыкомпонентыОС, системное ПОАппаратное обеспечение29293.

Выбор общего масштабаДля разных целевых интенсивностейотказов различных частей проекта могутиспользоваться разные масштабы:Целевая интенсивность отказов системы30 отказов на 1 миллион операцийСреднее время между отказами ОС•Среднее время между отказами оборудования•303,000 отказов на 10 миллионов операций1 на 30 часов работыНужно выбрать общий масштаб30Как найти целевую интенсивностьотказов разрабатываемого ПО?1.2.3.4.5.31Установить общесистемнуюцелевую интенсивность отказовПеревести системы измерения интенсивностейотказов компонентов в единую системуизмеренияВычесть из целевой интенсивности системырасчётную интенсивность отказовприобретённых компонентовВычесть расчётную интенсивность отказовокружения (ОС и интерфейсных систем), вкотором будет работать разработанное ПООстаток – целевая интенсивность дляразрабатываемого ПО31Вычисление целевой интенсивности отказовдля разрабатываемого ПО (1)•Пример 1:••32Общесистемная целевая интенсивность отказов100 отказов на 1 миллион операцийИнтенсивность отказов «железа»0.1 отказа в часЧисло отказов ОС на 100,000 операций0.4 отказа в часЦелевая интенсивность ПО95 отказов на 1 миллион операций32Вычисление целевой интенсивности отказовдля разрабатываемого ПО (2)•Пример 2: БД на Win 2K:Общая целевая интенсивность отказов•Среднее время между отказами для Win 2K•3,000 часов на 10 миллионов операцийСреднее интенсивность отказов «железа»•30 отказов на 1 миллион операций1 отказ в 30 часовИнтенсивность отказов других подсистем•9 отказов на 1 миллион операцийКакова целевая интенсивность отказовдля разрабатываемого ПО?•3333Вычисление целевой интенсивности отказовдля разрабатываемого ПО (3)34344.

Стратегии уменьшениячисла отказов программ4 основных стратегии:35НедопущениеУстранениеНевосприимчивостьПрогнозирование35Недопущение отказовИзбежание отказов по построению.Действия:Эффективность применения:36Перепроверка требованийПересмотр архитектуры и очистка кодаИспользование стандартов (ISO 9000-3, etc.)Использование CASE-средств со встроеннымимеханизмами контроляПропорция отказов после выполненияуказанных действий не меняется.36Устранение отказовОшибки в коде устраняются с помощьюверификации и валидации.Действия:Эффективность применения:37Семантическая проверка кодаТестированиеУменьшение числа ошибок в коде.Уменьшение числа отказов ПО.37Тестирование vs.ИнспектированиеИнспеция – детальное изучениеспецификаций, архитектуры проекта, егокода, … Инспектирование эффективнеетестирования более чем в 20 раз Пересмотр кода позволяет найти в 2 разабольше ошибок, чем его тестирование 80% ошибок находятся во времяинспектирования Инспектирование уменьшает стоимость3838 разработки в 10 разМожно ли заменить тестированиеинспектированием?НЕТ.

Иногда инспектирование непозволяет получить информацию,доступную с помощью тестирования:39Реальное поведения системыПоказатели производительности,удобства использования, …Показатель надёжности системы39Невосприимчивость котказамОбеспечение сервиса несмотря наотказы ПО с помощью избыточностиДействия:Эффективность применения:40Проектирование и обеспечениеизбыточностиУменьшение числа отказовсистемы из-за её избыточности40Прогнозирование отказовПостроение оценки вероятностивозникновения отказовДействия:Эффективность применения:41Построение модели надёжностиСбор информации об отказахАнализ результатовУменьшение интенсивностивозникновения ошибок за счётуправления надёжностью41SRE: процесс• 5 шагов в SREпроцессе:– Определить необходимыйуровень надежности– Построитьфункциональный срез– Подготовиться ктестированию– Выполнить тестирование– Проанализировать данныеоб ошибках ииспользовать их дляпринятия решенийDefine NecessaryReliabilityDevelopOperational ProfilePrepare for TestExecute TestApply Failure Datato Guide Decisions42ПрофильПрофиль - набор альтернативных сценариеввместе с вероятностями их выполненияПример:Если сценарий A выполняется в 30% случаев,сценарий B – в 20%, а С – в 50%, то профиль имеетследующий вид:A0.3B0.2C0.543Функциональный срезФункциональный срез – полный набор сценариев выполнениявместе с их вероятностями (во время работы заданного ПО)Функциональный срез описывает распределение событий,которые происходят во время работы программыФункциональный срез программы отражает то, как она будетиспользоваться на практикеВероятностьФункциональный среззависит от пользователя,времени, используемойфункциональности т.д.Работа44Функциональный срезФункциональныйсрез – полныйнабор операций(имя и частота)и вероятностей ихиспользованияПример:45Почему это полезно?Профиль функционирования программы даётинформацию о том, как её будут использовать, ипозволяет разработчикам сфокусироваться на решениидействительно актуальных задачС помощью профиля разработчики могут:Увеличить эффективность разработки и тестирования.Сделать тесты более реалистичными.С точки зрения эффективного управления разработкувсегда нужно начинать с изучения приложенийпрограммы и составления соответствующего профиляфункционирования46Операция (1)Неформальное определение:Операция представляет собой задачу,выполняемую программой в заданномокружении.

Причём результат выполнениязадания должен быть обозримым дляпользователяБолее формальное определение:Операция – крупное логическоекраткосрочное задание, выполнение которогозначительно отличается от других заданий47Операция (2)Крупное означает, что операция должнаотноситься к функциональным требованиям,предъявляемым к разрабатываемой программе, ане к подзадаче, решаемой в её реализацииОперация – логическая концепция в том смысле,что она может включать набор программных,аппаратных и пользовательских действий48Операция (3)Кратковременность означает, что принормальном функционировании программы, онаможет выполнять тысячи операций в часЗначительно отличающееся выполнениеозначает, что с высокой долей вероятности отказвнутри операции не произойдёт при выполнениидругих операций49Прогон и его типы (1)Прогон - наименьшая часть работы,которая может быть вызвана внешнимвоздействиемПримеры:Звонок в телекоммуникационной системеКоманда в интерактивном приложенииТранзакция в интернет-магазинеetc.50Прогон и его типы (2)Прогоны связаны со входным состоянием,включающим полный набор входныхпеременных (любых данных, полученных извне)Входные переменные могут быть:Частично неизвестными на стадии проектированияпрограммыСкорее логическими, чем физическими[например адрес в памяти]Прогоны с одинаковым входным состояниемпринадлежат к прогона одного типа51Операции vs.

Функции (1)Функция, заданная требованиями к программе,потенциально может стать операцией илинабором операций на стадии её разработкиФункция – группа типов прогона, заданныхтребованием к программе и наблюдаемыхпользователемОперация – группа типов прогона заданных вовремя разработки программы ирассматриваемых с точки зрения еёпроектирования52Операции vs. Функции (2)АнализКонцентрацияна пониманиипроблемыИдеальныйслучайПоведениеПример:ПроектированиеПеремещениеКонцентрация наобъекта в памятипонимании(функция) на стадиирешенияопределенияБлизко к реальномутребований можеткодупревратиться вОперации иоперации создания,атрибутыкопирования иЖизненный циклудаления на стадииобъектовразработки53Как искать операции?Реализация случаевиспользованияДополнительныеспецификации ГлоссарийОперацииСпецификацияархитектурыМодельиспользованияРазработкаархитектурыКлассыПодсистемыИнтерфейсыСигналыСобытияРеализация случаевиспользования(разработка)УправлениеСущностьГраницыАналитическиеКлассы54ПредставлениеОписывает функциональныйпрофиль:Табличное представление Графическое представление55Representation: TabularТабличное представление включает списокимён операций и вероятностям ихвозникновенияТаблица из Reliability Engineering Handbook56Графическое представлениеГрафическоепредставлениесостоит из:Узлов – атрибутовоперацийВетвей – значенияатрибутовГрафическое представлениеВероятностьможет быть получено изиспользования:табличного и наоборот.ассоциируется с ветвями57Режим функционированияРежим функционирования – шаблониспользования системы и/или условийокружения которые нужно различать во времятестирования, так как они могут приводить котказамПример: пиковые и свободные режимы работытелекоммуникационной системыОдна и та же операция может использоваться вразных режимах функционирования с разнымивероятностямиПрофиль функционирования системы долженвключать все важные режимыфункционирования58Сколько это стоит?Средняя стоимость построения профиляфункционирования для проекта среднегоразмера (10 разработчиков, 100 тыс.