Продолжаем тему нефункциональных требований и атрибутов качества.
Слово Dependability, как "система, на которую можно положиться, ей можно доверять" придумал в 1981 году французский учёный Жан-Клод Лапри. К этому времени слово Reliability было уже заезжено, и обозначало всё подряд. Впрочем, по его определению, Dependability включает в себя Reliability, но в узком смысле, скорее как отказоустойчивость.
Полный список атрибутов Dependability:
➕ доступность (aviability): готовность предоставлять работающий сервис (вероятность, что система будет работать, когда мы к ней обратимся);
➕ надежность (reliability): неизменность параметров сервиса во времени;
➕ безопасность (safety): из-за сбоя не будет катастрофических последствий для пользователей и окружения;
➕ целостность (integrity): система не развалится при сбое и данные не будут искажены;
➕ ремонтопригодность (maintainability): систему можно будет починить после сбоя: обнаружить дефект, перезапустить, восстановить данные.
Иногда добавляют security, и наконец-то я нашел определение разницы: security — это про умышленные действия по нанесению вреда, тогда как safety — про отсутствие вреда в любом случае, были умышленные действия или нет. В свою очередь, вредоносные действия могут быть направлены на нарушение целостности, доступности или на раскрытие конфиденциальной информации. Эти понятия ортогональны, а не из одного ряда.
Вся модель выглядит так: атрибуты➡️ угрозы ➡️ меры.
Угрозы делятся на дефекты (fault), ошибки (error) и отказы (failure).
Дефект — это недостаток в конструкции системы; он не обязательно приводит к ошибке и сбою — возможно, система никогда не придёт в состояние, когда дефект проявится. Статическая вещь, имеется в системе уже в момент разработки.
Ошибка — несоответствие реального поведения системы указанному в спецификации. Это означает, что система приходит в непредусмотренное состояние в результате активации дефекта (возможно, связанного с нестандартными параметрами окружения или входов системы). Обнаруживается только во время работы.
Сбой — момент или интервал времени, когда система демонстрирует некорректное поведение или недоступна. То есть, это проявленная и не обработанная ошибка. Не все ошибки ведут к сбою — они могут быть, например, перехвачены обработчиком исключений.
Сбои проявляются на границах системы: в API, в интерфейсах, в выводе. Пока ошибка не превратилась в сбой, то есть не вышла за границу системы, про неё может никто и не догадываться.
В итоге, образуется цепочка: дефект➡️ ошибка ➡️ отказ, который, в свою очередь, приводит к ошибке в смежной системе и т.д.
Поэтому, с одной стороны, хорошо бы обнаруживать ошибки внутри системы, пока они ещё не привели к сбою, и хорошо бы прерывать распространение сбоя на смежные компоненты при взаимодействии. Поэтому мы особое внимание уделяем обработке ошибок при проектировании интеграций, чтобы ошибочное состояние не расползлось на всю распределенную систему. Поэтому же за корректную работу вне зависимости от степени испорченности входных данных отвечает каждый компонент самостоятельно.
Сбой в системе может привести к нарушению одного или нескольких атрибутов:
доступности, надежности, целостности, безопасности.
Слово Dependability, как "система, на которую можно положиться, ей можно доверять" придумал в 1981 году французский учёный Жан-Клод Лапри. К этому времени слово Reliability было уже заезжено, и обозначало всё подряд. Впрочем, по его определению, Dependability включает в себя Reliability, но в узком смысле, скорее как отказоустойчивость.
Полный список атрибутов Dependability:
Иногда добавляют security, и наконец-то я нашел определение разницы: security — это про умышленные действия по нанесению вреда, тогда как safety — про отсутствие вреда в любом случае, были умышленные действия или нет. В свою очередь, вредоносные действия могут быть направлены на нарушение целостности, доступности или на раскрытие конфиденциальной информации. Эти понятия ортогональны, а не из одного ряда.
Вся модель выглядит так: атрибуты
Угрозы делятся на дефекты (fault), ошибки (error) и отказы (failure).
Дефект — это недостаток в конструкции системы; он не обязательно приводит к ошибке и сбою — возможно, система никогда не придёт в состояние, когда дефект проявится. Статическая вещь, имеется в системе уже в момент разработки.
Ошибка — несоответствие реального поведения системы указанному в спецификации. Это означает, что система приходит в непредусмотренное состояние в результате активации дефекта (возможно, связанного с нестандартными параметрами окружения или входов системы). Обнаруживается только во время работы.
Сбой — момент или интервал времени, когда система демонстрирует некорректное поведение или недоступна. То есть, это проявленная и не обработанная ошибка. Не все ошибки ведут к сбою — они могут быть, например, перехвачены обработчиком исключений.
Сбои проявляются на границах системы: в API, в интерфейсах, в выводе. Пока ошибка не превратилась в сбой, то есть не вышла за границу системы, про неё может никто и не догадываться.
В итоге, образуется цепочка: дефект
Поэтому, с одной стороны, хорошо бы обнаруживать ошибки внутри системы, пока они ещё не привели к сбою, и хорошо бы прерывать распространение сбоя на смежные компоненты при взаимодействии. Поэтому мы особое внимание уделяем обработке ошибок при проектировании интеграций, чтобы ошибочное состояние не расползлось на всю распределенную систему. Поэтому же за корректную работу вне зависимости от степени испорченности входных данных отвечает каждый компонент самостоятельно.
Сбой в системе может привести к нарушению одного или нескольких атрибутов:
доступности, надежности, целостности, безопасности.