Портал №1 по управлению цифровыми
и информационными технологиями

Вопрос из зала: доступность и её команда

Алексей Тюрин спрашивает на нашей страничке в Фейсбуке:


Добрый день!

Помогите пожалуйста разобраться в чем разница между reliability и dependability (нет в глоссарии). И то и другое согласно ГОСТУ – надежность – т.е. свойство объекта сохранять во времени в установленных пределах значения всех параметров…

Тем не менее в другом контексте говорится, что depentability – это reliability и availability. В этом случае, если reliability – надежность, то что такое dependability? Безотказность?

Т.е. безотказность это надежность и доступность (способность объекта выполнять согласованную функцию, когда это требуется).

Правильным ли будет такой вывод? Спасибо!


Давайте распутаем эту терминологическую красоту в комментариях.

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

Комментариев: 2

  • Игорь

    В Словаре (см. ред. 2011) availability определяется совокупностью (см. словарь). В совокупности есть и надежность (см. там же), как мера того, как услуга функционирует без перерыва, т.е., понимай, как можно дольше. Очень не конкретно. Надежность для РЭА определяется по коэффициентам отказов (лямбда), надежность рассчитывается для определенного временного периода (часов, дней, месяцев, лет). Расчет готовят от элемента до узлов и системы в целом, т.е. снизу вверх. Для ПО и ИТ услуг нет понятия коэффициента отказов, Более 8 лет мне довелось принимать расчеты по надежности для многих ИУС в ВМФ СССР и РФ. Их делали только для РЭА и никогда для ПО. Не слышал, чтобы появились способы расчета надежности для софта (кто-то может поделиться?). Доступность Услуги и Приложения (бизнес-услуга) мне все-таки представляется некоторым соглашением между бизнесом и ИТ, которое поставщик берет на свою ответственность. Формулу расчета легко применили из области расчета для РЭА. Расчет сразу и наверху, т.е. низ отсутствует. Достижение метрики по доступности осуществляется комплексом мер (Программа обеспечения надежности, иногда качества). Отсылки можно найти в ГОСТ Р ИСО/МЭК 12207-99 (п.5.3.4.1) Процессы ЖЦ программных средств. Мы редко конкретизируем ограничения к понятиям и терминам, а еще проще переносим их с одной среды на другую. Надежную систему можно разработать на ненадежных элементах (компонентах:кластеры, блейды, диски, адаптеры и т.д., блоки питания), получим таким образом катастрофоустойчивое решение, сохраняющее данные и позволяющее восстановить их. Привлечение всех терминов из области надежности для РЭА в область ITSM мне представляется избыточным и не корректным. Допускаю, что поэтому, вероятно, число терминов из этой области в СЛОВАРЕ все-таки сознательно ограничено. Напомню также, что корни ITIL в британском ВМФ, а мы с ними “дружили”, лучшие практики интересны были всем, но они у каждого свои. Поэтому лучше следовать принципу “не множить сущности без необходимости” (английский философ У.Оккама XiV в.) и не вносить дополнительные термины, пусть правильные, но строго для других целей. Надеюсь, что смог убедить.

    • Pavel Solopov

      “и не вносить дополнительные термины, пусть правильные, но строго для других целей”

      Во, во, я примерно тоже самое говорил про Функцию, предлагая не наделять этот термин в русском языке ещё одним значением. Но поддержки моя позиция не нашла. 🙂


Добавить комментарий для ИгорьОтменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM