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

Ключевые практики управления доступностью и непрерывностью

Последнее время меня занимает вопрос оценки процесса управления доступностью и непрерывностью ИТ-услуг. И если с измерением результативности процесса, на мой взгляд, все более или менее понятно – она определяется степенью достижения согласованных показателей доступности и непрерывности услуг[1], то с измерением ключевых практик не все однозначно. Собственно, вопросы есть уже к списку ключевых практик, которые необходимы для реализации назначения процесса. Здесь необходимо сделать оговорку, что я рассматриваю вариант ISO/IEC 20000, согласно которому управление доступностью и непрерывностью совмещены. Однако суть упражнения не поменяется и при разделении процессов. С оглядкой на ITIL и COBIT5 Enabling Processes получается следующий список ключевых практик: Планирование доступности и непрерывности…

Павел Дёмин, 8 августа 2016, последний комментарий 12 августа 2016

Критерий доступности

Уровень доступности является одним из важнейших параметров качества услуги, требования к которому должны быть зафиксированы в SLA. За определение измеримых обязательств по предоставлению ИТ-услуг отвечает процесс управления уровнем услуг, однако решающее значение в том, насколько адекватно отчетность будет отражать реальную ситуацию, а, следовательно, и удовлетворенность заказчиков доступностью услуг, имеет то, насколько четко определены границы доступности и недоступности. Вне зависимости от услуги и способа измерения, расчет уровня доступности основан на учете периодов недоступности. Чтобы избежать споров как внутри ИТ-организации, так и с заказчиком, о том, считать тот или иной сбой инцидентом недоступности или нет, требуется документировать критерий доступности. Для этого, как…

Павел Дёмин, 20 июля 2016, последний комментарий 26 июля 2016

Антихрупкость: частые падения, своевременное обнаружение, быстрое восстановление

Определённо, в последнее время требования к высоким уровням доступности становятся всё более распространёнными. Сервисы, что ранее предоставлялись лишь "внутри" компании, становятся внешними, будучи предоставляемыми непосредственно клиентам. Соответственно, как отмечает Стюарт Рэнс в своей заметке, и простои сервисов, когда они возникают, становятся сразу видны многим: от клиентов до прессы и конкурентов. Довольно часто можно прочитать в заголовках новостей, что в такой-то компании произошёл серъёзный сбой в ИТ. В свою очередь, это выливается в потерю огромных сумм денег, потерю репутации на рынке. Что предпринять, чтобы не оказаться в подобной ситуации? Крепость Данный подход "старой школы" предполагал титанические усилия, направленные на проектирование сервисов,…

Нужен ли процесс управления доступностью?

Управление доступностью – уникальный процесс. Уникальный в первую очередь тем, что является изобретением авторов ITIL и не замечен как отдельный процесс (если я не отстал от жизни) ни в одном известном мне своде знаний по управлению ИТ, кроме ITIL, или процессной модели известной мне реальной компании. Почему – вопрос, который я хочу поднять в этой заметке, и поделиться своими размышлениями на этот счет. Причина 1: Доступность уже обеспечивается другими процессами Взглянем на задачи процесса: Создавать и вести план доступности, отражающий текущие и будущие потребности заказчиков. По услуге такой план может быть частью SIP. Кроме того, задача сильно пересекается с аналогичной в управлении…

Павел Дёмин, 14 мая 2016, последний комментарий 15 апреля 2022

Доступность. Держать аптайм или быстро восстанавливать?

Ньюсмейкер этой недели, Стюарт Рэнс, продолжает делиться своим богатым ИТ-опытом. В этот раз по части такой важной характеристики, как доступность. Недавно Сюарт поучаствовал в дискуссии об ИТ-услугах и о том, как обеспечивать приемлемый уровень их доступности. Хотя поводом и послужил сбой системы авиационно-диспетчерской службы Лондона 12 декабря 2014 г., идеи, вынесенные из обсуждения, применимы для любых систем, а не только для таких критичных, как контроль и управление воздушными перевозками. Несмотря на то, что сбой продолжался недолго, последствия были огромными. Множество рейсов было отклонено, их невозможно было принять, и самолёты вынужденно садились в других аэропортах. Пассажиры, соответственно, оказывались совсем не там,…

Новостной поток, 10 июля 2015, последний комментарий 14 июля 2015

Checklist: А вы готовы к неожиданностям?

Независимо от уровня надежности и отказоустойчивости ИТ-систем, приходит день, который испытывает их, а заодно и вас, на прочность. Пожары, затопления, отключения электричества, перебои у ключевых подрядчиков, нарушение целостности каналов связи, крупномасштабные отказы вследствие реализации угроз ИБ – вот лишь короткий список обстоятельств, которые могут поставить вас и ваших заказчиков в затруднительное положение. На случай, если у вас на это есть бюджет, мы предлагаем короткий чеклист, благодаря которому вы можете проверить свою способность держать удар. Разработан и актуален план реагирования на НШС, который включает: События и сценарии, являющиеся триггерами для активации плана Порядок действий по реагированию и минимизации негативного…

Граница между доступностью и непрерывностью

Граница между двумя процессами – управление доступностью и управление непрерывностью ИТ-услуг – неочевидна, и часто вызывает сложности, особенно у тех, кто только знакомится с ITIL. Действительно, процессы используют схожие техники. В основе обоих процессов лежит понятие риска: мы должны идентифицировать нежелательные события, угрожающие вывести из строя услуги, затем думать, как с этим справляться. И в том, и в другом случае требуется понимание критических бизнес-функций (VBF) и анализ влияния отказов услуг/систем на бизнес-процессы (BIA). Оба процесса, в конечном счете, решают задачу обеспечения устойчивости организации к отказам. Так ли важно разделять эти процессы? На прошедшем недавно курсе PPO мы с группой составили небольшую табличку, иллюстрирующую различия, которую я…

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

Система определения приоритетов одной известной компании

В одной компании уже много лет действует такая система определения приоритетов неприятных событий (мы бы называли их инцидентами, наверное): Код Sev-5, самый низший, используется для относительно незначительных проблем, как правило технических. Такие проблемы можно и нужно решать в обычном рабочем порядке. То есть — не очень срочно, но сделать нужно. Код Sev-1, самый высший, присваивается срочным событиям, реакция на которые должна быть безотлагательной: запускаются все возможные системы оповещения ответственных сотрудников, приступить к устранению беды следует немедленно, о проблеме, её последствиях и героическом устранении будет доложено одному из топ-менеджеров компании, который не только выслушает, но и сделает орг.выводы и примет административные…

Олег Скрынник, 11 февраля 2015, последний комментарий 30 марта 2015

CMDB как инструмент учёта прав доступа

Ярослав спрашивает авторов и читателей портала: Просьба посоветовать хорошие практики по учету прав доступа к информационным системам (бизнес-сервисам). Цель: учесть возможные права доступа к каждой системе и выданные права доступа каждого пользователя к каждой системе. Использовать это в заявках на запрос, изменение, отключение прав, для отчетности и аудита прав. Сейчас это представляется мне так: для каждого права доступа к системе создается отдельный класс CI в CMDB. К CI "Информационная система" привязываются все CI "Право доступа…", имеющие к ней отношение. Пользователи привязываются к CI "Право доступа…", в соответствии с выданными им в реальности правами. Есть ли какой-то другой подход к решению такой задачи? Заранее благодарю!

Вопрос из зала, 9 февраля 2015, последний комментарий 11 февраля 2015

Новая серия вебинаров CleverTALK. С Днем знаний!

Лето закончилось, за окном пасмурно, но это не повод для грусти, потому что у нас есть отличная новость! В День знаний мы объявляем начало новой серии бесплатных вебинаров CleverTALK! В этом сезоне вас ждет 7 интересных вебинаров от наших тренеров и консультантов: Универсальный протокол интеграции ITSM-систем Управление рисками проекта как привычка Экспресс-оценка: больше, чем обучение, меньше, чем консалтинг Постоянное улучшение как привычка Организационные изменения как привычка Что такое доступность услуг и как ее считать Внешняя и внутренняя оценка процессов Программа опубликована на нашем сайте, регистрация уже открыта. Первый вебинар "Универсальный протокол интеграции ITSM-систем" Дмитрий Исайченко проведёт 25 сентября. С 2011…

О пользе FTA

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

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

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

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

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