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

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Консалтинг
по управлению ИТ

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

Всё об управлении и измерении доступности

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О пользе FTA

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

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

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

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

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

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM