Software Processes
advertisement
Tarkvara kvaliteed ja standardid Качество и стандарты программного обеспечения Отладка программ Что такое отладка? • Отладка – это процесс обнаружения причин возникновения ошибки и ее последующего исправления (в отличие от тестирования, являющегося процессом обнаружения самого факта существования ошибки) • Отладка включает в себя элементы тестирования и разработки • На некоторых проектах отладка может занимать до 50% всего времени разработки • Для многих программистов отладка – это самая трудная часть программирования • При соответствующем подходе количество ошибок, требующих отладки, должно сократиться, и отладка должна стать самой легкой частью; при таком подходе все ошибки сводятся к небольшим недосмотрам или опечаткам Роль отладки в качестве ПО • Как и тестирование, отладка не является способом улучшения качества ПО. Отладка – это всего лишь способ исправления дефектов в программе • Качество программ должно обеспечиваться аккуратным анализом требований или прототипированием, грамотным проектированием и использованием лучших практик кодирования • Отладка – это последняя надежда программиста Вариации в качестве отладки • • Исследования работы опытных программистов показали, что отличие лучших и худших результатов при отладке Среднее составляет ~20:1. Кроме время того, некоторые отладки (мин) программисты находят больше ошибок и Среднее колисправляют их более во не найденных аккуратно ошибок Пример: исследование Среднее колработы опытных во ошибок, программистов (как допущенных минимум 4 года опыта при исправлении работы) при отладке других программы с 12 ошибками: ошибок 3 самых быстрых программ иста 3 самых медленных программи ста 5.0 14.1 0.7 1.7 3.0 7.7 Выводы о различиях в качестве отладки • Три лучших программиста смогли найти ошибки примерно за треть времени по сравнению с худшими • Кроме того, они допустили всего 2/5 ошибок по сравнению с худшими • Самый лучший программист нашел все ошибки и не допустил ни одной ошибки при исправлении • Худший не нашел 4 из 12 ошибок и сделал 11 ошибок при исправлении тех 8, что он нашел • Схожие результаты получались и в других исследованиях (Gilb, 1977; Curtis, 1981) • Эти результаты подтверждают общий принцип качества: «улучшение качества снижает стоимость разработки». Не нужно выбирать между качеством, стоимостью и временем – они все могут оптимизированы одновременно Ошибки как возможности • Что означает наличие ошибки в программе? Видимо, то, что мы не полностью понимаем программу. Это неприятная мысль, но если мы программируем методом проб и ошибок, то ошибки неизбежны • По большому счету надо улучшать свои навыки программирования, а не навыки отладки • Но даже лучшие программисты допускают ошибки • «На ошибках учатся». Что может узнать программист при изучении своих ошибок в программах? – – – – Понять программу, над которой работает Осознать свои типичные виды ошибок Оценить удачность своего подхода к решению проблем Оценить удачность своего подхода к исправлению ошибок «Вредные советы» по отладке • «Проще всего найти ошибку методом угадывания» – Разбросайте случайным образом множество отладочных печатей. – Смотрите только на результат работы. – Исправляйте программу где попало – вдруг повезет и она заработает? – Не сохраняйте исходную версию программы. • «Не надо тратить времени на понимание проблемы» – Ошибка-то, скорее всего, тривиальная! • «Исправляйте ошибку самым очевидным способом» – Не нужно тратить времени на сложные исправления, затрагивающие всю программу. Отладка и суеверия • Не доводилось ли вам говорить следующие фразы? – Компьютер глючит – Это ошибка в компиляторе – Кривые входные данные – Редактор неправильно сохраняет программы и потому компилируется неправильная версия – Кто его знает, когда происходит эта ошибка. Может быть, это зависит от фазы луны? • Чаще всего, ошибки в программах – ваши собственные; нечего сваливать свои ошибки на других • Даже если это не ваша ошибка, полезно предполагать обратное. Ошибки и так трудно находить, а если вы еще и не будете их искать... Нахождение ошибок • Отладка состоит из нахождения ошибок и их исправления. Первая часть обычно занимает до 90% времени и усилий. • Наиболее эффективный метод отладки – "научный". Обобщенный научный подход может быть сформулирован так: – – – – – Сбор данных через повторяемые эксперименты Создание гипотезы, отражающей максимум доступных данных Разработка эксперимента для проверки гипотезы Подтверждение или опровержение гипотезы При необходимости - итерация предыдущих шагов • Этот подход находит следующее отражение в отладке: – – – – – Стабилизация ошибки (1-ый шаг общего метода) Обнаружение точного места ошибки (2-4 шаги общего метода) Исправление ошибки Тестирование исправления Поиск похожих ошибок Сквозной пример • Мы будем рассматривать методику отладки на следующем примере. Предположим, что у нас есть программа, работающая с базой данных сотрудников. Эта программа должна печатать список сотрудников и их налоговые отчисления в алфавитном порядке. Ниже приведен результат работы: Formatting, Fred Freeform $5,877 Goto, Gary $1,666 Modula, Mildred $10,788 Many-Loop, Mavis $8,889 Statement, Sue Switch $4,000 Whileloop, Wendy $7,860 • Проблема заключается в том, что Many-Loop, Mavis и Modula,Mildred напечатаны в неправильном порядке Стабилизация ошибки • Если проблема возникает нестабильно, то ее практически невозможно диагностировать. • Нестабильные ошибки обычно связаны с проблемами инициализации или висячими указателями • При стабилизации ошибки требуется также свести тест к минимально возможному (иногда это задача группы тестирования, но чаще всего это задача программиста) • Сведение теста к минимальному – это тоже задача, требующая научного подхода (хоть и в миниатюре) Пример стабилизации • В нашем примере мы обнаруживаем, что после второго запуска программы все в порядке: Formatting, Fred Freeform $5,877 Goto, Gary $1,666 Many-Loop, Mavis $8,889 Modula, Mildred $10,788 Statement, Sue Switch $4,000 Whileloop, Wendy $7,860 • Однако при вводе новой записи, Fruit-Loop, Frita, проблема сортировки возникает снова • В обоих случаях мы вводили одну запись, а не группу записей • Отсюда гипотеза: проблема заключена в процедуре ввода новой записи (сортировка группы записей работает правильно) • Повторный запуск подтверждает нашу гипотезу Обнаружение точного места возникновения ошибки • После сведения теста к минимальному изменение любого аспекта этого теста изменяет и внешнее проявление ошибки. Естественно, мы будем использовать это для диагностики ошибки • Например, в нашем примере, мы можем подозревать наличие ошибки смещения на единицу (ошибка, которая возникает при вводе одной, но не двух записей). Тогда мы можем попробовать граничные случаи (+1, 0, -1) • Однако при просмотре программы мы не можем найти ни одной такой очевидной ошибки • Поэтому мы должны вернуться к этапу варьирования теста. Мы добавляем сотрудника Hardcase, Henry ... и он появляется на правильном месте! Таким образом, наша первая гипотеза провалилась – это или более сложная проблема, или что-то совершенно иное Новые гипотезы • При изучении нашего теста, мы замечаем, что FruitLoop, Frita и Many-Loop, Mary – это единственные фамилии, содержащие дефисы. Оба имени появлялись на неправильном месте при вводе. Может быть, в первом случае проблема была не в Modula, Mildred, а в Many-Loop, Frita? • Новая гипотеза: проблема связана с именами, содержащими дефис, а не с вводом одного имени • Однако это не согласовывается с правильностью повторной сортировки Новые гипотезы • Мы смотрим в код и обнаруживаем, что программа использует две различных процедуры сортировки: при вводе сотрудника и при сохранении данных. Более того, первая процедура и не должна полностью сортировать записи – она подготавливает данные для ускорения процедуры сохранения программы. При этом всяческие особенности (типа дефисов) не поддерживаются • Итак, проблема заключается в том, что данные печатаются до сохранения в файле, в не полностью отсортированном виде • Новая гипотеза: имена с символами пунктуации неправильно сортируются вплоть до сохранения в файле Методы поиска ошибок • После стабилизации ошибки и минимизации теста необходимо перейти к нахождению причины ошибки • В зависимости от качества кода, это может быть тривиальным или сложным (если при поиске причины ошибки у вас возникают трудности, то, скорее всего, вся программа написана плоховато) • Рекомендации по поиску ошибок: – – – – – – Используйте все доступные данные при выдвижении гипотез Минимизируйте тесты, показывающие ошибки Воспроизведите ошибку различными способами Соберите больше данных для генерации новых гипотез Используйте результаты негативных тестов Проведите мозговой штурм в поисках новых гипотез (не хватайтесь за первую гипотезу; ищите другие причины; думайте!) Методы поиска ошибок (2) • Рекомендации по поиску ошибок: – Сужайте подозрительные фрагменты кода (попробуйте убрать фрагмент кода и проверьте наличие ошибки; метод "разделяй и властвуй"; ставьте точки останова в отладчике) – Относитесь внимательнее к тем процедурам, в которых уже встречались ошибки – Проверяйте недавние исправления – Расширяйте подозрительные фрагменты кода – Проводите интеграцию постепенно – Поставьте временное ограничение на "quick&dirty debugging" – Ищите типичные ошибки (см. inspection checklists) – "Исповедальная отладка" (расскажите проблему кому-то еще) – Отдохните от проблемы Синтаксические ошибки • В принципе, синтаксические ошибки постепенно вымирают. Как помочь им в этом процессе: – Не доверяйте номеру строки с ошибкой, на которую указывает компилятор (см. как минимум на ±1 строку) – Не доверяйте сообщениям компилятора – Еще меньше доверяйте всем сообщениями компилятора после самого первого ("наведенные ошибки") – "Разделяй и властвуй" (особенно хорошо работает для синтаксических ошибок) – Ищите лишние комментарии, апострофы и кавычки. Исправление ошибок • Относительно простая задача, но именно это делает ее столь опасной (50% исправлений неправильны!) • Рекомендации по исправлению ошибок: – Разберитесь в проблеме прежде, чем ее исправлять – Разберитесь в программе, а не в проблеме (исследование в 1986 г. показало, что с исправлением лучше справляются те программисты, которые понимают контекст программы; под контекстом понимается несколько сот строк, а не 1-2) – Убедитесь в правильности диагноза до исправления – Не торопитесь! Не срезайте углы. Методы исправления ошибок • Рекомендации по исправлению ошибок: – Сохраняйте исходную версию кода – Исправляйте проблему, а не симптомы: • Исправления, ориентированные на симптомы, почти никогда не будут работать • "Заплатки" на коде невозможно сопровождать • Компьютеры предназначены для систематических вычислений – оставим "творческий подход" для людей – – – – Вносите исправления только тогда, когда вы уверены Вносите изменения по одной штуке за раз Проверяйте свои исправления Ищите похожие ошибки Психологические соображения при отладке • Отладка – это психологически сложный процесс: – Приходится искать ошибку в собственном коде – Приходится думать последовательно и логично – Приходится переключаться между разработкой и тестированием – Приходится бороться со знакомством с кодом • "Психологические установки" Психологические установки • Студенты, обучавшиеся структурному программированию, ожидают, что все конструкции похожи на три базовые операции (но код с goto ведет себя по-иному) • Студенты, изучающие цикл while, зачастую подразумевают, что условие проверяется постоянно (а не в конце или начале цикла) • Ошибки в присваиваниях примерно в три раза сложнее для обнаружения, чем "ошибки взаимодействия" • Анекдот: программист случайно использовал переменные SYSTSTS и SYSSTSTS как одну и ту же переменную. Ошибку нашли только после сотен запусков и издания книги с кодом • Типичная ошибка – "подразумеваемые скобки": Психологическое расстояние • Психологическое расстояние определяет легкость различия различных слов людьми: Первая переменная Вторая переменная Психологич. Расстояние STOPPT ST0PPT Почти ноль SHIFTRF SHIFTRT Мало заметно CLAIMS1 CLAIMS2 Небольшое GCOUNT CCOUNT Небольшое PRODUCT SUM Большое Средства отладки • Существует целый вагон средств, которые могут помочь при отладке: – Компараторы исходных текстов – Предупреждения компилятора • Поставьте максимальный уровень предупреждений в компиляторе и исправляйте код соответствующим образом • Считайте предупреждения ошибками • Создавайте проектные соглашения по установкам компилятора – Дополнительные средства проверки синтаксиса (lint верификатор C-программ) – Профайлеры Использование отладчика • Современные отладчики умеют очень много: – – – – – – – – – – – Точки останова на конкретных строчках кода Остановка на n-ой итерации цикла Остановка при изменении переменных Остановка при присваивании конкретного значения Прохождение кода строчка за строчкой Откат по программе Исследование всех данных в программе, включая типы, определенные пользователем Присваивание новых значений переменным Продолжение исполнения программы Многоязыковая отладка (язык1, язык2, ассемблер...) Запоминание установок Критика отладчиков • "An interactive debugger is an outstanding example of what is NOT needed – it encourages trial-and-error hacking rather than systematic design, and also hides marginal people barely qualified for precision programming" » Harlan Mills • Отладчик действительно не заменяет мозгов, но и обратное не полностью верно • Отладчик – это мощный инструмент. При правильном использовании, он дает большие преимущества; при неправильном – можно повредиться Системы с повышенными требованиями к надежности: основные понятия, спецификации Функциональная надежность Величина, на которую пользователи критической системы доверяют ей Концепция надежности Для критическх систем характерно то, что надежность является самым важным свойством системы Надежность системы отражает степень доверия пользователя к системе. Она отражает область доверия пользователя к тому, что система будет работать, как ожидается, и что при нормальном использовании она не выйдет из строя. Применимость системы и ее надежность – не одно и то же. Система не обязана быть удобной и практичной. Параметры надежности Надежность Работоспособность безотказность Защищенность Безопасность Удобство сопровождения Атрибут системы, соответствующий простоте восстановления системы после отказа или изменения системы для добавления новых свойств Очень важно для критических систем, так как отказы системы случаются часто из-за проблем сопровождения Удобство сопровождения отличается от других параметров надежности тем, что это статический атрибут системы, а не динамический, потому не будет нами рассматриваться Способность к выживанию Способность системы к продолжению предоставления своих услуг пользователям при случайных или намеренных атаках на систему Этот атрибут становится все более и более важным для распределенных систем, чья безопасность постоянно подвергается риску Способность к выживанию включает в себя понятие – способность к восстановлению системой своих функций – возможность продолжать работать и в том случае сбоя компонентов системы Стоимость и надежность Cost Dependability Low Medium High Very high Ultrahigh Стоимость надежности Стоимость обеспечения надежности имеет тенденцию к возрастанию экспоненциально по отношению к уровню надежности, который необходимо достичь Этому есть две причины: Использование более дорогих средств разработки и оборудования, которые необходимы для достижения более высокого уровня надежности Увеличивающийся объем тестирования и валидации системы, которые необходимы для убеждения клиента в том, что нужный уровень надежности ссистемы достигнут Надежность vs производительность Не заслуживающие доверия системы могут быть отвергнуты пользователем (Не заслуживает доверия => Непригодна) Стоимость отказа системы может быть очень высока Очень трудно отладить систему так, чтобы она стала более надежной («модификация надежности», к сожалению, невозможна) Плохую производительность можно компенсировать (надежность - нельзя) Ненадежные системы могут привести к потере важной информации Экономика надежности Из-за очень высокой стоимости достижения определенного уровня надежности может быть более экономически эффективно принять к использованию ненадежную систему и оплачивать стоимость отказов Это, однако, зависит также от социальных и политических факторов. Репутация продукта, которому не доверяют, может подорвать будущий бизнес. Зависит от типа системы, особенно для бизнессистем, в которых уровень системы должен быть адекватен представлениям Работоспособность и безотказность Безотказность Способность безотказной работы системы в течение определенного времени в данной среде для достижения данных задач Работоспособность Способность системы в определенной точке времени быть работоспособной и предоставляющей запрошенные услуги Оба этих атрибута могут быть рассчитаны численно Работоспособность и безотказность (2) Иногда возможно соотнести работоспособность системы и безотказность системы Обычно если система не работоспособна, то она не предоставляет запрашиваемые специфические сервисы Однако, возможно создать систему с низкой безотказностью, которая будет работоспособной. Системные сбои могут быть исправлены очень быстро и не повреждать данные, поэтому низкая безотказность может не быть проблемой Работоспособность учитывает время ремонта Терминология безотказности Отказы и сбои Отказы обычно являются результатом системных ошибок, которые являются следствием сбоя в системе Тем не менее, сбои необязательно ведут к системным ошибкам Сбойное состояние системы может измениться и «выровняться» до появления ошибки Ошибки необязательно приводят к отказам системы Ошибки могут быть исправлены встроенным определителем ошибок Повторное возникновение сбоев может быть предотвращено встроенными средствами защиты Представление об отказоустойчивости Формальное оределение отказоустойчивости не всегда отражает пользовательские представления об отказоустойчивости системы Представления о среде, в которой может использоваться система, могут быть неверными Использование системы в офисной обстановке может быть совершенно иным, чем использование той же системы в полевых условиях Последствия системных отказов влияют на понимание отказоустойчивости Отказывающие увлажнители ветровых стекол могут оказаться бесполезными в сухом климате Отказы, которые имеют серьезные последствия (такие, как поломка двигателя в машине), значат для пользователя больше, чем отказы, просто причиняющие неудобства Достижение надежности Предотвращение сбоев Средства разработки, которе снижают возможность ошибок или выявляют ошибки до того, как они приведут к отказу системы Определение отказов и устранение их Verification & validation увеличивают возможность обнаружения и исправления ошибок до ввода системы в эксплуатацию Обеспечение отказоустойчивости Технологии, которые позволяют убедиться в том, что сбои системы не приводят к ошибкам и/или ошибки системы не приводят к сбоям системы Моделирование отказоустойчивости Вы можете смоделировать систему как карту ввода-вывода, для которой отдельные входные данные служат результатом ошибочных выходных данных Отказоустойчивость системы основывается на возможности того, что отдельные входные данные являются частью набора других входных данных, ведущих к ошибочным выходным данным Разные люди используют систему различными способами, так что эта возможность не является статическим атрибутом системы, но зависит от окружения системы Карта ввода-вывода Представление отказоустойчивости Совершенствование отказоустойчивости Исправление X% отказов в системе не обязательно исправляет отказоустойчивость системы на X%. Исследования IBM показали, что 60% исправленных дефектов системы приводят лишь к 3% увеличения отказоустойчивости Дефекты программы могут быть в редко используемых разделах кода так, что они никогда не будут получены при обычной работе. Исправление таких дефектов никак не отразится на отказоустойчвости системы Программа с известными заранее отказами может рассматриваться, как достаточно надежная для ее пользователей. Защищенность Защищенность – это такое свойство системы, которое отражает способность системы работать, нормально или ненормально, без возможности причинить вред или смерть людям и без повреждений окружающей среды Особенно важно учитывать безопасность системы при том, что все больше и больше устройств включаются в системы контроля, основанные на ПО Требования безопасности – это эксклюзивные требования, так как они исключают нежелательные ситуации чаще, чем специфические сервисы системы Критическая защищенность Первичные критически-защищенные системы Встроенные системы ПО, отказ которых может вызывать отказ связанного с ним оборудования и непосредственно воздействовать на людей. Вторичные критически-защищенные системы Системы, чьи отказы приводят к отказам других систем, что может привести к воздествию на людей (база данных лекарств) Здесь мы будем рассматривать только первичные критически-защищенные системы Защищенность и отказоустойчивость Защищенность и отказоустойчивость связаны, но отличны друг от друга В общих чертах, защищенность и отказоустойчивость – необходимое, но не достаточное условие для защиты системы Отказоустойчивость связана с соответствием имеющейся спецификации и предоставление услуг Защищенность связана с возможностью системы не причинять вреда не зависимо от того, соответствует она спецификации или нет. Незащищенные отказоустойчивые системы Ошибки спецификации Если спецификация неверна, то система может вести себя, как предполагалось, но все равно привести к инцидентам Отказы оборудования могут генерировать ложные входные данные Это сложно отразить в спецификации Контекстно-зависимые команды могут быть неправильно поняты в определенное время Часто результат операторской ошибки Терминология защищенности Достижение защищенности Предотвращение несчастного случая Система создана так, что некоторые категории несчастных случаев просто не могут произойти. Обнаружение и исправление повреждения Система сконструирована так, что сбои обнаруживаются и исправляются до того, как они могли бы повлечь за собой несчастный случай Ограничение повреждений Система включает в себя такие свойства безопасности, которые уменьшают повреждения, которые могут быть получены в результате несчастных случаев Accidents Выход из строя в коплексных системах редко имеют единичную причину возникновения, так как эти системы спроектированы быть надежными до первой точки отказа Конструирование системы так, чтобы первая точка отказа не приводила к выходу из строя – это фундаментальный принцип построения безопасных систем. Как правило, выход из строя является результатом комбинации случаев неправильного функционирования Безопасность Безопасность системы – это такое системное свойство, которое отражает способность системы защитить себя от от случайных или плановых внешних атак Безопасность становится особенно важной для систем, работающих в сети, так как к ним возможен удаленный доступ Безопасность – это обязательное свойство для достижения отказоустойчивости, работоспособности и защищенности системы Фундаментальные положения безопасности Если система является сетевой и не является безопасной, то положения о ее отказоустойчивости и ее защищенности недостоверны Эти положения зависят от выполняющейся системы и разработанной системы, которая является той же самой системой. Однако, вторжение может изменить и систему и/или данные системы Терминология безопасности Повреждения при отсутствии безопасности Отказ служб Система приводится в состояние, когда обычные сервисы недоступны или когда результат выполнения значительно деградировал Повреждение программ или данных Программы или данные могут быть изменены неавторизованным путем Потеря конфиденциальной информации Информация, используемая в системе, становится доступной людям, не имеющим права ее читать или использовать Гарантия безопасности Предотвращение отказов Система создана так, что отсутствует возможность отказа. Например, отсутствие соединения со внешней сетью исключает атаки извне Выявление атак и устранение опасности Система разработана так, что атаки обнаруживаются и нейтрализуются до того, как они привели к потере работоспособности системы. Например, антивирусная программа находит и удаляет вирусы до того, как они заразят систему Ограничяение воздействия Система сконструирована так, что последствия успешной атаки минимальны. Например, политика резервного копирования сохраняет данные от повреждения Спецификация надежной системы Процессы и средства создания спецификации для безопасности, защищенности, работоспособности и безотказности системы Функциональные и нефункциональные требования Функциональные требования могут быть сформулированы для определения проверки ошибок и возможностей восстановления, которые обеспечивают защиту от отказов системы. Нефункциональные требования могут быть сформулированы для определения необходимых отказоустойчивости и работоспособности системы. Спецификация отказоустойчивости системы Отказоустойчивость оборудования Отказоустойчивость ПО Какова возможность отказа компонентов аппаратуры, и как долго будет производиться ремонт компонентов? Какова возможность того, что ПО будет причиной неверных выходных результатов? Отказы ПО отличаются от отказов оборудования, программа прдолжает работать даже после выдачи неверных результатов. Отказоустойчивость оператора Какова вероятность того, что оператор системы сделает ошибку? Построение отказоустойчивой системы Существует дисциплина в системной инженерии, которая связана с оценкой отказоустойчивости системы Она принимает во внимание возможности отказов различных компонентов системы и их кобинаций Для системы с 2 –мя компонентами A и B где возможности отказа А - P (A) и возможности отказа B - P (B). Возможности отказов Так как компонентов 2 и работа системы зависит от обоих из них, то возможность отказа всей системы составляет P (S) = P (A) * P (B) Если число компонентов растет, то растет и вероятность отказа системы Если компоненты дублируются, то возможность отказа составит n P (S) = P (A) (могут отказать все компоненты) Требования функциональной отказоустойчивости Предварительно определенная область всех значений, которые вводятся оператором, должна быть описана, и система должна проверять соответствие вводимых оператором данных. Система должна проверять все диски на сбойные участки перед инициализацией. Система должна быть статического анализа проверена методами Спецификация нефункциональной отказоустойчивости Необходимый уровень отказоустойчивости должен быть описан численно Отказоустойчивость – динамический атрибут системы – связь спецификации отказоустойчивости и исходного кода бессмысленна. Подходящие метрики отказоустойчивости должны быть выбраны в соответствии с обеспечением отказоустойчивости всей системы Метрики отказоустойчивости Метрики отказоустойчивости есть единицы для измерения отказоустойчивости системы Отказоустойчивость системы определяется подсчетом числа оперативных отказов и, при необходимости, соотнесения их с требованиями, предъявленными к системе и ко времени, в течение которой система должна быть в рабочем состоянии Для обеспечения отказоустойчивости критических систем необходимы программы протяженных по времени измерений Метрики отказоустойчивости (2) Metric POFOD Probability of failure on demand Explanation The likelihood that the system will fail when a service request is made. For example, a POFOD of 0.001 means that 1 out of a thousand service requests may result in failure. ROCOF The frequency of occurrence with which unexpected Rate of failure behaviour is likely to occur. For example, a ROCOF of occurrence 2/100 means that 2 failures are likely to occur in each 100 operational time units. This metric is sometimes called the failure intensity. MTTF The average time between observed system failures. Mean time to failure For example, an MTTF of 500 means that 1 failure can be expected every 500 time units. MTTR The average time between a system failure and the Mean time to repair return of that system to service. AVAIL The probability that the system is available for use at a Availability given time. For example, an availability of 0.998 means that in every 1000 time units, the system is likely to be available for 998 of these. Работоспособность Измерение интервала времени, в течение которого система остается в рабочем состоянии Учитывает время на восстановление и рестарт системы Работоспособность на 0.998 означает, что ПО находится в рабочем состоянии в течение 998 из 1000 временных интервалов Подходит для систем, работающих без останова Телефонные станции, станции слежения на транспорте Возможность отказа по требованию (POFOD) Существует возможность отказа системы при запросе сервиса. Используется, если запросы сервиса не частые и нерегулярные Подходит для систем защиты, где сервисы запрашиваются от случая к случаю и где нет отчетливой последовательности вызовов сервиса Используется для многих критических систем с компонентами, управляющими исключениями Аварийная система отключения на химической фабрике Частота возникновения отказа (ROCOF) Отражает частоту возникновения отказов системы ROCOF 0.002 означает 2 отказа на протяжении 1000 временных единиц работы, т.е. 2 отказа на 1000 часов работы Используется для операционных систем и систем, использующих транзакции, в которых должнл производить большое число похожих запросов с достаточно большой частотой. Система обработки кредитных карт, система заказов билетов Время до отказа (MTTF) Время между замеченными сбоями системы. Это значение, обратное ROCOF для стабиотных систем MTTF 500 означает, что время между отказами – 500 временных единиц Используется для систем с длительными транзакциями, т.е. Там, где действие системы продолжительны по времени. MTTF должна быть больше, чем время транзакции Последствия отказа Измерения отказоустойчивости не принимают во внимание последствий отказа Отказы могут не иметь реальных последствий, но часть из них приводит к потере или повреждению данных или потерю системных сервисов. Может понадобиться определить несколько классов отказов и использовать разные типы метрик для каждого из них. Спецификация отказоустойчивости в этом случае должна быть структурирована. Последствия отказа (2) При определении отказоустойчивости мы должны учитывать не только сами отказы, их частоту и количество, но и последствия этих отказов Отказы, которые имеют серьезные последствия, являются более опасными, чем те, ремонт и восстановление после которых несложно. В некоторых случаях должны быть определены спецификации отказоустойчивости для различных типов отказов. Классификация отказов Failure class Transient Permanent Recoverable Unrecoverable Non-corrupting Corrupting Description Occurs only with certain inputs Occurs with all inputs System can recover without operator intervention Operator intervention needed to recover from failure Failure does not corrupt system state or data Failure corrupts system state or data Создание спецификации отказоустойчивости Для каждой подсистемы проанализируйте последствия возможных отказов. В результате анализа разделите отказы на классы. Для каждого класса отказов определите отказоустойчивость на основе подходящих метрик. Разные метрики должны быть использованы в случае различных требований отказоустойчивости Определите требования функциональной отказоустойчивости для уменьшения шансов критических отказов. Банковская система Каждая машина в сети используется 300 раз в день У банка всего 1000 машин Время жизни ПО 2 года Каждая машина производит около 200 000 транзакций Всего 300 000 транзакций в день Пример спецификации отказоустойчивости Failure class Example Permanent, The system fails to operate with non-corrupting. any card which is input. Software must be restarted to correct failure. Transient, non- The magnetic stripe data cannot be corrupting read on an undamaged card which is input. Transient, A pattern of transactions acrossthe corrupting network causes database corruption. Reliability metric ROCOF 1 occurrence/1000 days POFOD 1 in 1000 transactions Unquantifiable! Should never happen in the lifetime of the system Валидация спецификации Невозможна эмпирическая валидация спецификаций с высокой отказоустойчивостью Отсутствие повреждений в базе данных означает POFOD менее, чем 1 на 200 миллионов Если транзакция занимает 1 секунду, то симуляция трансакций 300 000 машин в течении дня займет 3.5 дня
