Управление доступностью Archives – Страница 3 из 4

О пользе FTA

Решая задачи управления рисками и непрерывностью ИТ-услуг, я искал инструмент, который в условиях ограниченных ресурсов аналитиков и сложностей с привлечением технических экспертов, позволял бы получить максимально точный ландшафт рисков и полную картину нарушений доступности. Да еще хотелось, чтобы с его помощью была возможна вероятностная оценка, и сразу можно было представить, как полученные и не очень устраивающие цифры исправлять. В книге Service Design любимого пятитомника говорится о методе анализа дерева отказов (Fault-Tree Analysis, далее – FTA), но уж слишком вскользь, чтобы обратить на него внимание. Стандарт ISO 31010 “Risk Management – Risk assessment techniques”, выступает более развернуто и, приводя следующий пример (см….

Павел Дёмин, 28 мая 2014, последний комментарий 5 июня 2014

Проектирование услуг как управление рисками — часть 3

Суммируя соображения в предыдущих двух частях (первая, вторая), я прихожу к матричному представлению четырех процессов проектирования услуг: В каждой ячейке таблицы – «модель» деятельности (ну как в ITIL модель изменений, например): Ответственный (это могут быть разные люди: ответственный за классификацию – аналитик, ответственный за разработку – инженер и т.д.) Шаги и методика выполнения (ясно, что они будут очень различаться для безопасности и доступности) Ресурсы (инструменты моделирования, расчетов, мониторинга и т.д.) Эскалация (то есть механизмы передачи решения «наверх» в случае конфликта ресурсов или отклонения от плановых значений) Ключевым здесь является лишь синхронное выполнение всех пяти видов деятельности управления рисками. Количество строчек может…

Константин Нарыжный, 22 октября 2013, последний комментарий 25 октября 2013

Проектирование услуг как управление рисками – часть 2

Итак, продолжая начатое в предыдущем посте рассмотрение процессов проектирования, отвечу на вопрос: Если они структурно похожи, многие своды знаний не видят разницы, почему ITIL разделяет управление доступностью, мощностями, безопасностью и непрерывностью? Мне кажется, причины две. Во-первых, четыре параметра качества независимы друг от друга, а, следовательно, их совмещение в одном процессе приведет к тому, что целей процесса будет две, и менеджер процесса будет постоянно балансировать между ними. К примеру, управление доступностью и мощностями объединяет COBIT 5, где говорится, что одновременно нужно обеспечить и доступность систем, т.е. минимальное количество и продолжительность прерываний, и достаточное быстродействие ИТ-систем. То есть в случае, если доступность достигается резервными…

Константин Нарыжный, 11 октября 2013, последний комментарий 25 октября 2013

Проектирование услуг как управление рисками

Вот еще одна модель с минимальной прикладной ценностью, зато для меня обеспечивающая полное понимание вопроса. В процессных моделях ITIL, COBIT 5, ISO 20000, MOF 4, CMMI for Services присутствуют одни и те же слова: доступность, мощность, непрерывность и, конечно, безопасность. Если брать за основу идеологию ITIL, то это – четыре равноправных и обязательных составляющих качества ИТ-услуг (есть еще функциональность, но я не о ней пока). И вот, в ITIL всё понятно: есть четыре процесса, которые оперируют ими: проектируют и контролируют. А вот в других источниках всё по-другому, по-разному. Во всех перечисленных моделях эти слова комбинируются в произвольном порядке. Стандарт – объединяет, и…

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

Алексей Тюрин спрашивает на нашей страничке в Фейсбуке: Добрый день! Помогите пожалуйста разобраться в чем разница между reliability и dependability (нет в глоссарии). И то и другое согласно ГОСТУ – надежность – т.е. свойство объекта сохранять во времени в установленных пределах значения всех параметров… Тем не менее в другом контексте говорится, что depentability – это reliability и availability. В этом случае, если reliability – надежность, то что такое dependability? Безотказность? Т.е. безотказность это надежность и доступность (способность объекта выполнять согласованную функцию, когда это требуется). Правильным ли будет такой вывод? Спасибо! Давайте распутаем эту терминологическую красоту в комментариях.

Вопрос из зала, 4 марта 2013, последний комментарий 11 марта 2013

Точно и адресно

Как и многие пользователи техники ASUS, сегодня я получил письмо с уведомлением о предстоящем перерыве в работе сервиса ASUS WEB storage. Этим сервисом я не пользуюсь (припоминаю, что когда впервые попробовал, был поражен неудобством интерфейса и низким качеством локализации и не стал продолжать), поэтому мне, в общем-то, все равно. Но само письмо показалось мне просто замечательным. Вот оно: Уважаемые пользователи! Чтобы улучшить качество предоставляемых услуг, мы планируем выполнить модернизацию наших систем. Продолжительность вынужденного отключения системы: система будет отключена для модернизации на 4 часов 17.12.2012 г. с 10:00 до 20:00 (GMT+8). Во время указанного периода доступ ко всем службам ASUS…

Роман Журавлёв, 12 декабря 2012, последний комментарий 15 декабря 2012

Недоступная доступность

На прошлой неделе, во время курса «Основы ITIL V3», мы разговорились со слушателями про доступность ИТ-услуг. Спор завязался вокруг тех сервисных инцидентов, в которых, в самом широком смысле, «виноват пользователь». Если конкретнее: считать ли ИТ-услугу недоступной, если пользователь просто не знает, как ею правильно воспользоваться? Ответ коллег был следующим. Услуга конечно же доступна, ведь у нас есть процессная модель управления, мы отлично взаимодействуем между собой, и все ИТ-компоненты работают слаженно. Нам за это платит заказчик. Он же платит своим сотрудникам, чтобы те делали свою работу используя компьютеры, а, следовательно, это он обязан их обучить всем аспектам рабочего процесса, и в…

Константин Нарыжный, 24 июня 2012, последний комментарий 5 июля 2012

Смотрим на инциденты расширенными глазами

Хочу написать про еще одну технику управления рисками, незаслуженно забытую в книгах ITIL V3 2007 года, но восстановленную ("по чертежам" ITIL V2) в прошлогоднем обновлении. Я говорю о расширенном жизненном цикле инцидента (the Expanded Incident Lifecycle). Это раздел в описании процесса управления доступностью (Availability Management), где предлагается разделять каждый инцидент (незапланированный перерыв в нормальном предоставлении ИТ-услуг) на обязательные последовательные этапы. Момент возникновения инцидента, то есть, момент, когда пользователь ощутил снижение качества ИТ-услуги Обнаружение, то есть промежуток времени от возникновения до момента получения поставщиком ИТ-услуг информации об инциденте Диагностика, то есть время на поиск причины инцидента Исправление, то есть время на…

Константин Нарыжный, 2 мая 2012, последний комментарий 3 мая 2012

Героизм в ITIL V3: борьба с инцидентами

На очередном курсе у крупного системного интегратора, слушатели смогли найти в ITIL V3 очередное противоречие. Их находкой хочу поделиться. Итак: два понятия.

Константин Нарыжный, 13 апреля 2012, последний комментарий 23 февраля 2016

Мониторинг инфраструктуры, что кроме автоматизации?

На днях закинули в CleverTEST очередной пробный экзамен по ITIL, пока кидали, на глаза попался вопрос: Что из перечисленного лучше всего описывает назначение управления событиями? Способность обнаруживать события, толковать их и определять подходящий способ реагирования Способность внедрять средства мониторинга Способность отслеживать и контролировать работу технического персонала Способность формировать отчетность об успешном предоставлении услуг на основе данных о времени бесперебойной работы устройств Вспомнился недавний разговор с одним знакомым, который жаловался на несовершенство используемой им системы мониторинга, "которая заваливает их спамом, а толку никакого". В моем понимании, идеальная схема работы с большими объемами информации заложена в процессе управления конфигурациями. А…

Евгений Шилов, 24 декабря 2011, последний комментарий 30 декабря 2011

Мониторинг ИТ-сервисов

Как обычно, тему навеяло не книгами, а внешними событиями, происходящими вокруг меня. В течение продолжительного времени я регулярно использовал единственный предсказуемо перемещающийся по нашему городу транспорт – метро. В связи с этим посещал одну из станций, где в ожидании поезда смотрел по сторонам. Как и любому человеку, имеющему отношение к ИТ, мне не чуждо чувство любопытства, которое начинаешь испытывать при виде окна с сообщением об ошибке. Особенно если это окно обнаруживается в неожиданном месте. Например, на мониторе рекламной стойки. Следует отметить, что рекламные ролики при этом продолжали крутиться, но на 60% они были перекрыты данным окном. Почитав надписи в окне,…

Евгений Шилов, 20 июля 2011, последний комментарий 22 июля 2011

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

Управление доступностью

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