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

Дважды два — четыре. Учимся считать доступность

Опубликовано 6 сентября 2010
Рубрики: ITSM, Управление доступностью
Комментарии

В своей первой заметке из серии "Про доступность — легко и доступно" Джеф Хармер (Geoff Harmer) рассказывает о математических правилах расчёта плановой доступности для части ИТ-инфраструктуры.

Полезно для тех 54% российских ИТ-директоров, которые не имеют высшего образования и, соответственно, не изучали теорию вероятности.

Читать заметку Джефа

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

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

  • «Полезно для тех 54% российских»

    А также для тех 45%, которые изучали и успешно её забыли после того, как ручка экзаменатора оторвалась от их зачётной книжки. 🙂

    • Тут не теория вертоятности, а комбинаторика:)

      У меня кстати дипломная работа магистрская была на схожую тему (признают — подгонял научную базу под навозну кучу).

      Ради «пустить пыль в глаза» не поленился заскриншотить итоговую формулу

      s48.radikal.ru/i120/1009/38/6c90c1a08e3f.gif

      Суть в двух словах — связи бизнес-серсивов между собой, возможными неблагоприятными событиями, ИТ-инфрастурктурой, набором средств и мероприятий по невилированию рисков и вероятностей событий с кучей параметров на каждую связь. Формула — как бы "индекс защ

      • ищенности бизнеса от рисков, связанных с ИТ.

        • Кирилл, должен признать формула не самая устрашающая. Операторами суммы и произведения никого не испугаешь, вы бы туда интегралов, дифференциалов да логорифмов подкинули бы. Вот это уже было бы серьёзнее.

          А почему «под навозную кучу»? Теория надёжности технических систем уже не в почёте? После появления ITSM она стала не нужна?

          • про интеграл/дифференциал и какой нить хитрый оператор не подумал — нужно было побольше такой лабуды добавить. Солиднее бы выглядело:)

            Теория надежности тех. систем более чем развита как в теории, так и в практике. И всяким лучшим практикам тут далеко (с точки зрения "показать циферку).

            Имел ввиду, что НИР делал по большей части ради «сдать», чем «применить в жизни».

          • Если уж интеграл — то только по замкнутому контуру

            🙂

  • Да уж статья в целом совсем уж примитивная, что-то вроде «теория надёжности технических систем для чайников».

    Попытка эмпирически доказать теорему умножения вероятностей. Кстати не очень удачный пример, по моему мнению.

    Хотелось бы сказать о другом, о том откуда брать исходные данные об отдельных компонентах сервисов. Мы как-то озадачились этим вопросом, и... практически ничего не нашли. Производители (по крайней мере в открытом доступе и документации) ни словом не упоминают про надёжность своей продукции. Мы конечно не исследовали весь рынок, покопались в доркументации на оборудование только крупнейших производителей. Удалось найти только данные по наработке на отказ для некоторых можедей Cisco, а вот HP (правда не официально устами своих сотрудников в форуме поддержки) заявляет, что принтеры их очень надёжные, и они не стали даже заморачиваться, расчётом таких показателей.

    Остаётся только собственная статистика, а значит какие-то более-менее качественные оценки доступности сревиса, мы сможем получить года через 3 эксплуатации его компанент. И хорошо если через 3 года эти компаненты не будут заменены на другие модели...

    • В этом-то и проблема.

      По заметкам типа таких, «как посчитать доступность», очень легко отличить теоретиков, прочитавших несколько страниц ITIL, от практиков, которые реально пытались посчитать доступность хотя бы части инфраструктуры.

      Это, кстати, одна из хороших дискуссий, которую мы затевали на курсе IT Service Manager. Начиная с вопроса «что такое доступность», т.к. это совсем не очевидно.

      • Да уж, вот вопрос: а стоит ли вообще манипулировать вещами (а тем более управлять), которые не очевидны. Может сначала надо привести их к очевидному состоянию? Кстати, вот такие вещи было бы правильно ожидать от стандарта 20К. Хотя куда уж там, в нём даже само понятие Service не определено.


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

Ваш адрес email не будет опубликован.

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM