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

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

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

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

Управление доступностью – уникальный процесс. Уникальный в первую очередь тем, что является изобретением авторов 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

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

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

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

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

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

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

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

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

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