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

Доступность, готовность?

Опубликовано 2 апреля 2011
Рубрики: ITSM, Аналитика: точка зрения, Вопрос из зала, Управление доступностью, Эксплуатация ИТ
Комментарии

Вопрос прислан посетителем портала.

Возник он (вопрос) при подготовке документа, который описывает ПО, позволяющее:

  • собирать информацию об отказах в сети,
  • вычислять значения коэффициента готовности отдельных компонент сети
  • вычислять интегральный коэффициент готовности сети 
  • вычислять некоторые финансовые показатели (потери от простоев…).

Как видно из второго пункта в списке, речь в документе первоначально велась о "готовности". И не просто потому что слово понравилось, а потому, что автор давно и привычно основывает свою работу в этой области на ГОСТ 27.002-89 «Надежность в технике» (ныне действующий ГОСТ Р 53480-2009 «Надёжность в технике. Термины и определения»).

С другой стороны расчет метрик велся в целях повышения степени управляемости телекоммуникационной инфраструктуры и в целом для повышения качества предоставляемых ИТ-услуг. Методическим руководством в этой работе служили ITIL и ISO/IEC 20000, а в них используется термин "доступность".

Оба термина обычно являются переводом английского "availability". Что же такое эта Availability – готовность или доступность? И что же такое этот вопрос – очередной беспочвенный спор о терминах или важное уточнение, необходимое для корректного управления ИТ?

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление поддержкой ИТ-услуг
Строим эффективную ИТ-поддержку, оптимизируем существующую

Также по теме:

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

  • Олег Скрынник

    Мне вот интересно, слово “доступность” появилось в русских айтилах, случайно, не из “белой книжки”?

    До её публикации никаких глоссариев не было. Использовалось ли тогда слово “доступность” как перевод слова “availability”?

  • Константин Нарыжный

    Самое существенное отличие определений availability из ISO20k и из ГОСТ, в том, что ISO указывает на “услугу”, а ГОСТ на “изделие” (Изделие – любая функциональная единица, которую можно рассматривать в отдельности), то есть на Configuration Item.

    Математический аппарат в ГОСТе довольно строгий.

    Пусть “доступность” – это “для пользователей”, для SLA, и по идее измеряется в точке потребления, а “готовность” – для “технарей”, измеряется покомпонентно, механизмы расчета закладываются в техническое задание компонентов.

    Короче говоря, разделение этих терминов в русском языке мне видится семантически дальновидным =)

    Кстати, “услуга” в ГОСТ определяется как “набор функций, предлагаемых пользователю”.

    • Вадим Курчаев

      «Брюки превращаются…»

      Определение из ISO 20k: availability – ability of a component or service to perform its required function at a stated instant or over a stated period of Time.

      ГОСТ же трактует понятие «изделие» очень широко.
      Похоже, что суть не в этом…

      • Константин Нарыжный

        …А жаль, красивая была версия =)

        Я имел в виду следующее за определением примечание:
        NOTE Availability is usually expressed as a ratio of the time that the service is actually available for use by the business to the agreed service hours.

        Тут уже компонентов нет, а есть прямое указание на согласование с бизнесом времени предоставления услуги. Из этого я исхожу, предлагая посетителю портала для иллюстративности использовать оба термина в своей документации.

  • Георгий

    ну насколько я помню из института есть еще “оперативная готовность” 🙂 как раз прямо как в ITIL – если удалить периоды плановой недоступности услуги 🙂
    Разницы по сути я не вижу
    Теоретически, я не вижу и никогда не видел причин, не использовать устоявшиеся технические термины в описании доступности.

    С практикой дело обстоит довольно тухло. так как для того чтобы использовать замечательный матаппарат для расчета комплексных показателей надежности, который мы знаем со времен вуза нужны очень подробные данные на все элементы инфраструктуры, срок службы, вероятность отказа итд итп. Такой инфы нет почти никогда (и это даже если мы говорим про внутреннюю инфраструктуру), а если подумать, что даже простейший сервис Электронная почта, завязан обязательно на провайдера интернет, то становится ясно, что точный математический расчет показателей надежности существует лишь в наших снах 🙂

    • Руслан

      Ну и сны у вас, Георгий! 😉 С мнением согласен. Более того, ITSM – гуманитарная наука, ничего сюда тащить ваши гиковские штучки. Так мы, чего доброго, гипотетического начальника управления эксплуатации какого-нить филиала международного мега банка интегралы брать заставим для расчёта фактического уровня сервиса. Будут ли после этого его дети здороваться с нашими?

      • Дмитрий Исайченко

        Спокойно! Наши тоже будут брать. Интегралы я имею ввиду 🙂

      • Георгий

        Стоп-стоп-стоп, я не хочу чтобы мои дети здоровались с гипотетическими детьми, гипотетического начальника. Пусть с реальными детьми дружат лучше 🙂

        а сны разные бывают 🙂 бывают и просто сны

    • Вадим Курчаев

      Георгий, добрый день.

      Прошу Вас дать ссылку на термин “оперативная готовность” из ITIL,
      в глоссарии ITIL v.3 такого не нашел.

      По Вашему последнему абзацу замечание: в заданном вопросе значение метрики уже определено статистически (экспериментально) и рассчитывать метрику теоретически (вероятностно) не нужно.

      • Георгий

        Термина “оперативная готовность” в ИТИЛ нет. Я собственно и не говорил что есть. я говорил, то нас нас когда то учили что есть комплексные показатели надежности систем, в том числе готовность и оперативная готовность. Отличаются они, насколько я помню, тем, что в показателе оперативная готовность учитываются плановая недоступность системы из за профилактики и регламентных работ.
        Я намеренно пишу все по памяти, как раз потому, что не вижу никакого смысла практического использования этих терминов, как и всего аппарата расчета надежности систем, ввиду тех причин которые уже описал

        По поводу замечаний по статистическим выборкам, я бы рад с вами согласиться, но не могу. нет их как правило. Максимум что доступно это экспертная оценка

    • ZW

      Можно посчитать, если бы провайдер давал информацию о своём показателе готовности, который он нам гарантирует.

      • Георгий

        угу, а еще если бы на софт сразу давали паспорт с показателями надежности именно в той конфигурации, которую мы используем, а еще, чтобы электричество, которое нам подает мосэнергосбыт тоже имело данные по готовности, а еще….
        и так далее.
        Собственно о чем я и писал. тухло

        • ZW

          С софтом сложнне. А с остальным вполне посчитать можно. У всех железок указана наработка на отказ(выход из строя железа). Немного усложняет подсчет учет особеностей реализованных схем резервирования. Но при этом на софт, который крутиться на этих железках, ничего нет.

          Про энергопитание: проблемы поставщика нивелируются системой гарантированного электропитания с ДГА.
          PS. Но многие показатели наработки на отказ выполняются только при надлежащем обслуживании. Особенно это касается ДГА.

          • Георгий

            Я правильно понял, что вы считаете, что все данные есть и посчитать можно и на практике делалось?

            • ZW

              На железки данные есть. Посчитать можно. На практике не делалось(для себя пару раз развлекались, обсчитывая некоторые схемы подключения для сетей).
              В практических целях сложность вызывает подсчет с учетом сложных схем резервирования.

              • Георгий

                То есть нет. Тогда о чем мы дискутируем?:)

                • ZW

                  Точно можно посчитать готовность коробок. Это делается для расчета ЗИПа. Там приходится просчитывать схемы резервирования с учетом возможности техподдержки по доставке запчастей.
                  С остальным сложнее. На готовность системы влияет не только ПО(которое меняется с каждым обновлением, что влияет на наработку на отказ), но и настройки системы.
                  К сожалению никто из вендоров не гарантирует, что если вы поставите такой набор коробок, соединненых между собой определенным образом, с определенным набором ПО(и определенным набором версий) это в совокупности даст вам оперделенную наработку на критический отказ.
                  Но посчитать, как часто вам понадобятся запчасти для коробок вы можете.

            • Вадим Курчаев

              Да сделано. Данные берутся из оборудования, складываются в БД и обсчитываются.
              Вопрос в том, как в назвать то, что поститано: “доступность” или “готовность”.

              • Георгий

                Если берется из систем мониторинга, помимо компонетного еще и пробниками услугу меряет, то это в терминах ITIL доступность. Если очень хочется назвать готовностью – то велком, я лично не против, как и писал уже. Если система позволяет отдельно отрезки времени по доступности в сутках мерять то вообще хорошо, мы когда в 2005 запускали у себя процесс упр-я досутпностью, то сделали 3 отрезка, “дневное время”, “ночное время” и “сумерки” – собственно сумерки были для плановых и регламентных работ.
                Выкидываете сумерки – вот оперативная готовность

  • Дмитрий Исайченко

    Раз спич пошел серьезный, я пошел читать и разбираться. Благо все доступно:

    ГОСТ Р 53480-2009: http://www.complexdoc.ru/pdf/%D0%93%D0%9E%D0%A1%D0%A2%20%D0%A0%2053480-2009/gost_r_53480-2009.pdf
    IEC 60050, раздел “Dependability and quality of service”: http://www.electropedia.org/iev/iev.nsf/index?openform&part=191

    Текст ГОСТа является очень близким переводом IEC 60050 (по крайней мере в рамках обсуждаемой темы). Чтобы не было путаницы, соответствие терминов (справа – ГОСТ, слева = IEC 60050):

    – Изделие = Item (про которое сказано, что это может быть как целая система, так и отдельный функциональный узел, т.е. перевод на мой взгляд крайне неудачный)
    – Готовность = Availability
    – Возможность = Capability

    Термина “Доступность” в ГОСТе нет, зато в IEC 60050 есть термин “Accessibility” (191-19-03). В IEC 60050 также есть наглядная картинка, демонстрирующая взаимосвязь терминов. Из нее можно сделать следующие выводы (для простоты я не буду цитировать, а своими словами):

    1. Availability – состояние системы или компонента (item), в котором они могут выполнять свою функцию. Например, серверное приложение работает (available).

    2. Capability – возможность (извините за тавтологию) системы или компонента соответствовать заданным количественным критериям. Например, серверная часть формирует отчет за приемлемое время 10 секунд.

    3. Accessibility = (упрощенно) Capability + Availability + доступность потребителю. Например, отчет не только формируется за заданное время, но и доступен клиенту.

    В этом смысле ITIL-овский термин Availability, рассматриваемый прежде всего с точки зрения потребителя конечной услуги, мне кажется ближе к IEC-овскому Accessibility. И перевод “Доступность” кажется вполне адекватным.

    Вообще, разница значима именно с точки зрения анализа технической инфраструктуры, а не с точки зрения предоставления услуг. В ГОСТе в разделе “Область применения” сказано: “Настоящий стандарт устанавливает термины и определения понятий в области надежности _в_технике_”. Так что если автору вопроса интересно мониторить техническую инфраструктуру, то в зависимости от охвата и объекта мониторинга термины Доступность и Готовность можно различать. Если же речь идет о диалоге с потребителем услуг, термин “Готовность” мне кажется избыточным. И к тому же непонятным для большинства этих самых потребителей.

    P.S. Вот в чем соглашусь, так это с тем, что система терминов в IEC 60050 гораздо более целостная и последовательная, чем в ITIL.

    • Дмитрий Исайченко

      Уточнение к тексту выше:

      Чтобы не было путаницы, соответствие терминов (слева – ГОСТ, справа – IEC 60050).

    • Георгий

      А вот Дима подошел как всегда основательно и ознакомился со всеми первоисточниками 🙂

    • Вадим Курчаев

      «Раз спич пошел серьезный … » )) Спич пойдет серьезный, когда ответят на вопрос Олега (см. первый пост). ))

      Соглашусь с Дмитрием в части перевода термина «Accessibility» из IEC 60050 на русский как «доступность». Не соглашусь тем, как им интерпретирована доступность:
      «Accessibility = (упрощенно) Capability + Availability + доступность потребителю».

      Если исходить из идеологии IEC 60050, и конкретно, если обратиться к Figure 191-2-Performance concepts, то можно сделать такой вывод: изделие работоспособно или услуга предоставляется, если соблюдены следующие условия:

      – обеспечена техническая возможность (Capability)
      – услуга предоставляется с согласованными показателями надежности (Dependability)
      – услуга предоставляется с заявленными качественными характеристиками (Quality of service)

      При этом «готовность» комплексно (включает в себя несколько свойств) и количественно отражает достигнутый уровень надежности изделия (предоставляемой услуги). «Доступность» же характеризует одно из пяти качественных свойств услуги – свойство услуги быть доступной, в смысле досягаемой, услуга может быть получена при определенных условиях… Например, автоматизированная система доступна, если подключении пользователя к АС, выдает приглашение аутентифицировать пользователя.
      И т.о. «доступность» системы, еще не гарантирует работоспособность пользователя в системе (и не только в связи проблемами аутентификации).
      И тогда, по-видимому, SLA нужно заключать не в терминах «доступности» системы/услуги, а в терминах работоспособности, т.е. готовности системы выполнять требуемую функцию, т.е. это и есть «готовность» системы/услуги…

      По тезису: «Так что если автору вопроса интересно мониторить техническую инфраструктуру, то в зависимости от охвата и объекта мониторинга термины Доступность и Готовность можно различать».
      То есть, если это АС работает на 7 уровне модели ОСИ, то это Услуга, и она должна характеризоваться «доступностью», а всё что ниже 7-го уровня – «готовностью» ? )) Т.о. связисты и телекоммуникационщики должны использовать одни стандарты и термины, а прикладники и системщики другие? Не смотря на то, что и они (связисты) тоже хотят предоставлять качественные услуги? ))

      По поводу того, что термин «готовность» не понятен потребителю, думаю, что и термин «доступность» без адекватного «правильного» объяснения тоже мало о чём говорит потребителю.
      Применение термина «доступность дело привычки, сложившейся практики, а по сути, оно, по-моему, не совсем верно.

      • Дмитрий Исайченко

        “Спич пойдет серьезный, когда ответят на вопрос Олега (см. первый пост).”

        Шансов никаких. Сворачиваем тему 😉

        • Вадим Курчаев

          А жаль, хотелось бы узнать атора перевода 14 главы “белой книги” .
          Может он объяснил бы – почему при расчете показателей надежности было принято решение отойти от закрепленного в ГОСТ 27.002-89 термина “коэффициент готовности” и заменить его “доступностью”…

      • Дмитрий Исайченко

        “То есть, если это АС работает на 7 уровне модели ОСИ, то это Услуга, и она должна характеризоваться «доступностью», а всё что ниже 7-го уровня — «готовностью» ? )) Т.о. связисты и телекоммуникационщики должны использовать одни стандарты и термины, а прикладники и системщики другие?”

        Вадим, корень непонимания я вижу в том, что Вы отождествляете услугу с системой автоматизации. Я – нет. ITIL – тоже нет. Если Вы апеллируете к практики телекома, велкам – посмотрите как определяется услуга в eTOM. Это совсем не то же самое, что определение услуги в IEC 60050/ГОСТ 53480.

        Вот и все. Еще раз, область применения ГОСТа “термины и определения понятий в области надежности _в_технике_”. Есть разница.

        • Вадим Курчаев

          Дмитрий, поясните подробнее, пожалуйста, как различные формулировки термина «Услуга», могут повлиять на _определение_ ее качественных и количественных характеристик. В частности, если мы говорим о такой характеристике как «доступность/готовность»?
          Термины услуга и система я не отождествляю. Вообще, термин «система» – это «наше все», святое, и его путать с чем-либо грех… ))

          «область применения ГОСТа «термины и определения понятий в области надежности _в_технике_». Есть разница.»

          Хорошо. В результате работы техники возникают услуги, которые и предоставляются потребителю. «Требования к поставщику услуг … должного качества» с 01.07.2011. будет регулировать ГОСТ ИСО/МЭК 20000-1/2. В результате 20К будет оценивать «доступность» услуги, а количественной характеристикой качества услуги, предоставляемой техникой, будет «готовность»?

      • Дмитрий Исайченко

        Вообще конечно тема с 7-ым уровнем модели OSI улыбнула 🙂 Мы-то спорим про то что есть сервисный подход. А ответ, оказывается, прост. 7-ой уровень – услуга, 1-6 – система. Блеск!

        • Вадим Курчаев

          Да это шутка была, но сделана она как вывод из Вашей, Дмитрий фразы: “Так что если автору вопроса интересно мониторить техническую инфраструктуру, то в зависимости от охвата и объекта мониторинга термины Доступность и Готовность можно различать”. Потому, что мне не понятно – в каком месте и, главное как, Готовность превращается в Доступность. Ведь, предлагаемая разными источниками (т.н. «белая книга», глоссарий ITIL v3, ISO 20k и ГОСТ 53480 и 2 7.000-89) методика расчета данной метрики едина…

          • Дмитрий Исайченко

            “Да это шутка была”

            Ну разумеется. Я так же и ответил 🙂

            P.S. По большому вопросу Выше обязательно отвечу, но видимо только ночером.

  • Лялеко Владимир

    Перечитал, всю дискуссию… Это что-то совсем космическое для меня 🙂

    В ИТИЛе термин Availability применяется к услугам. Услуга по умолчанию “доступна” не всем. Готова ли эта услуга к появлению новых пользователей?

    В итоге вводится термин “readiness” – готовность, чтобы посчитать сколько новых пользоваелей сможет ещё подключиться к услуге, пока показатель Availability не просядет.

    Резюме:
    Availability – доступность услуги для текущих пользователей.
    readiness – готовоность услуги обеспечить подключение новых пользователей, без провала показателя доступности.

    Право на жизнь подобное разделение терминов имеет ?:)

    • Вадим Курчаев

      readiness – это другая готовность.
      Что бы не путать ее с темином готовность из теории надежности технических систем (а раньше по ГОСТ 27.002-89 были “коэффициент готовности” и “коэффициент оперативной готовности”), нужно, трактовать это свойство системы/услуги, например, как “готовность к приращению”.
      Одним словом заменить не получилось…))

  • Игорь Бессонов

    Коллеги! У меня был уникальный учитель, преподававший в советсвкое время надежность в технических ВУЗах Москвы. Он же был моим начальником в ВП МО. По вопросам надежности для МО есть свой комплекс ГОСТов (от задания, расчетов, проектирования, до подтверждающих испытаний, включая разрушительные).

    Для нас это быти ИУС для подводных лодок.

    Что конкретго. Доступность и готовность связаны между собой, но физическая суть отличается. Надежность вообще определяется по люмбда-характеристикам элементов аппаратного комплекса. Никогда не считали и не было математики для расчета надежности ПО. Может кто-то поправить, но пока не удалось с таким встретиться.

    Доступность определялась для каждого режима работы, установленного для системы (теперь услуги, которая предоставляестя удаленно и пр.). Режим работы имеет длительность (делта t ►0), в течение которой к системе (услуге) должна быть обеспечена доступность пользователя.

    Готовность сейчас это проще, т.к. режим работы имеет временные рамки, отраженные в SLA.

    А для более жестких условий неизвестно, когда будут востребованы критичные режимы работы, например, стрельбы чем-то с "головой".Готовность это метрика того, что для выбранного режим работы на определенный момент (дельта t = 0) времени система будет готова к использованию.

    Мнение специфичное, но очень понятное и логичное.

Добавить комментарий

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.