Что такое управление непрерывностью услуг и как готовиться к катастрофе

Зачем управление непрерывностью сервисов

ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 готовит организацию к катастрофе: к событиюСобытиеИзменение состояния, замеченное мониторингом.ITIL 4, которое не просто ломает услугуУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation, а угрожает работе целиком. ITIL определяет катастрофу так: внезапное незапланированное событие, которое наносит большой ущерб или серьёзные потери. К этому ITIL добавляет условие: событие должно попадать под признаки, которые организация задала заранее, — по тому, как сильно оно бьёт по бизнесу 1.

Отсюда первое, что стоит понять о практике: её предмет задаётся заранее. Мелкие отказы в неё не входят: мелкое от крупного отделяют по тому, как сильно оно бьёт по бизнесу 1. Стратегические, политические и рыночные события — тоже вне её 1.

Практика обычно снижает риски высокого влияния и низкой вероятности, которые нельзя полностью предотвратить: часть причин вне власти организации, например стихийные бедствия 1.

ГОСТ Р ИСО/МЭК 20000-1 требует того же в виде обязанностей: в заранее назначенные сроки оценивать риски непрерывности, определять требования, а планы писать, вводить в дело и держать в рабочем состоянии 2.

Когда практика работает

Три вопроса, ответы на которые лежат в планах, а не в намерениях.

Известно, что восстанавливаем первым. Как проверить: определены жизненно важные функции и их зависимости — это делает разбор влияния на бизнес 1.

Цифры названы. Как проверить: по значимым услугам заданы допустимое время восстановления, допустимая потеря данных и минимальный уровень работы 1.

Планы проверялись. Как проверить: за последний год проводились учения, и по их итогам планы менялись — готовность и осведомлённость выделены в отдельный фактор успеха 1.

Что входит и что рядом

Три цифры, о которых договариваются заранее

Требований непрерывности три, и без них план остаётся сочинением 1.

Допустимое время восстановления — максимальный срок после перерыва, за который услуга должна быть возобновлена, пока нехватка работы не ударила по организации всерьёз. Оценивается по потерям от простоя, штрафам по соглашениям и решениям регуляторов, ущербу конкурентоспособности и репутации 1.

Допустимая потеря данных — момент, к которому должны быть восстановлены сведения. Если он равен тридцати минутам, то копия должна существовать не старше тридцати минут до события 1. Счёт на пальцах такой: интернет-магазин принимает сто заказов в час; руководство говорит, что потеря двухсот заказов неприемлема; значит, допустимая потеря — два часа 1.

Минимальный уровень работы — что именно должно работать во время восстановления: перечень действий и возможностей, ограниченный круг пользователей, ограниченное число операций за период 1.

Отдельно стоит развести две похожие величины 1. Предельно допустимый простой приходит из непрерывности бизнеса: это момент, когда последствия становятся невыносимыми. Допустимое время восстановления должно быть меньше — настолько, насколько организация готова рисковать.

Что на входе и что на выходе

Практика получает от бизнеса понимание, что критично, а от техники — знание, что и как быстро восстанавливается. Отдаёт планы и требования, которые становятся частью проектирования, закупок и договоров.

Осложнение то же, что и в безопасности: облачные решения и связки с системами партнёров создают новые критичные зависимости, которые труднее контролировать, а там, где организации не договорились между собой, появляются новые слабые места 1.

Разбор влияния на бизнес

Ключевая работа практики. ITIL описывает её так: найти жизненно важные функции и то, от чего они зависят, — поставщиков, людей, другие процессы, ИТ-услуги. Этот же разбор задаёт требования к восстановлению для каждой услуги 1.

Практический порядок разбора:

1. назвать функции, без которых организация не работает;
2. определить, через сколько времени их отсутствие становится неприемлемым;
3. проследить, от чего эти функции зависят — включая людей и поставщиков;
4. перевести это в требования к услугам: время, потери, минимальный уровень;
5. проверить, что требования выполнимы имеющимися средствами.

Пятый шаг — тот, где обычно выясняется, что обещания расходятся с возможностями. Это и есть польза разбора: он показывает разрыв до катастрофы, а не после.

Как это работает

Цвет шага: приём, учёт, работа с обращением техническая работа решение и полномочия проверка, разбор, улучшение

Две строки этой таблицы стоит развернуть.

Пятый шаг требует конкретики до имён. ГОСТ Р ИСО/МЭК 20000-1 задаёт состав плана 2:

• по каким признакам объявляют непрерывность и кто за что отвечает;
• что делать при крупной беде;
• какой уровень доступности держим, пока работаем по плану;
• требования к восстановлению и порядок возврата к обычной работе.

Отдельно оговорено: сами планы и списки контактных лиц должны быть под рукой.

Шестой шаг отличает практику от папки. Осведомлённость и готовность выделены отдельным фактором успеха 1: план, который не разыгрывали, в день события работает примерно как непроверенный откат.

Что с чем путают

Непрерывность и доступность. Доступность — про обычную работу и обычные сбои; непрерывность — про события, после которых обычные меры не помогают 1.

Непрерывность сервисов и непрерывность бизнеса. Вторая шире: она включает людей, помещения, поставки, деньги. ИТ-часть — вклад в неё, а требования приходят оттуда.

План непрерывности и резервное копирование. Копии — средство. План отвечает на вопросы, кто объявляет катастрофу, кого извещают, что восстанавливаем первым и как возвращаемся обратно 2.

Катастрофа и крупный инцидент. Разницу задают заранее выбранные признаки — по тому, как сильно событие бьёт по бизнесу 1, — а не ощущение в момент события.

Кто участвует

Как измерять

Самая честная пара — время восстановления в учениях против допустимого времени. Она превращает разговор о непрерывности из декларации в измеримую разницу.

Готовность Брукс проверяет внезапно, а не по расписанию. Запаздывание резервных мощностей он меряет так. Площадке звонят в случайную минуту и считают разницу: за сколько она обещала быть готовой и за сколько готова на самом деле. Цель — ноль, тревога — любое запаздывание 5. Учения, назначенные на третий вторник, проверяют готовность к учениям. Внезапная проверка проверяет готовность.

Справочник кризисной группы он выделяет в отдельную метрику — число неверных записей: цель 0, тревога 1 5. Одна ошибка уже тревога, и проверяется список случайной выборкой, которую делает независимая сторона, а не сама команда непрерывности. Обоснование у него шире, чем кажется: неверные контакты означают, что у плана не работают CHNКонтроль изменений и CFGУправление конфигурациями, — а значит, устарел, скорее всего, не только справочник.

Испытание не считается пройденным, пока его находки открыты. Число вопросов последнего испытания, оставшихся нерешёнными: цель 5, тревога 10 5. Пока они висят, план неработоспособен — и в этом смысле отчёт «учения проведены» без второго числа рядом ничего не сообщает. Отдельно считается задержка самого испытания: цель 1 день, тревога 5. Причина переносов, по Бруксу, почти всегда одна — участники заняты на другой работе.

Услуга без плана — это решение, а не пробел. Целевое значение у числа услуг вне плана 5 при тревоге в 10 5, но интереснее требование рядом: связь с непрерывностью должна быть оговорена у каждой услуги, даже если записано, что восстанавливать её не будут. Разница между «решили не восстанавливать» и «не дошли руки» в отчёте не видна, а в аварии видна сразу. Числа Брукса — образцы для настройки под свои услуги, не отраслевая норма.

Зрелость управления непрерывностью

✕

Где ломается чаще всего

Шесть мест, в порядке частоты.

Катастрофа не определена. Признаков нет, и в момент события спорят, объявлять ли режим 1.

Разбор влияния не проводился. Восстанавливать начинают то, что ближе, а не то, без чего организация не работает 1.

Цифры не согласованы с бизнесом. Допустимое время восстановления назначено ИТ-службой исходя из возможностей, а не из потерь 1.

Планы не проверялись. Готовность выделена отдельным фактором успеха именно поэтому 1.

Копии есть, восстановление не проверялось. Допустимая потеря данных задана, а способность уложиться в неё — нет 1.

Поставщики вне планов. Критичные зависимости от облака и подрядчиков не покрыты обязательствами 1.

Что говорят своды

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

ITIL держит непрерывность отдельной практикой, задаёт три требования восстановления и три фактора успехаФактор успеха практикиТо, что должно быть верно, чтобы практика выполняла своё назначение.ITIL Service Operation, раздел 4.2.8: планы, снижение рисков, осведомлённость и готовность 1.

ГОСТ Р ИСО/МЭК 20000-1 требует оценивать риски непрерывности через интервалы, определять требования, разрабатывать и поддерживать планы с заданным составом, обеспечивать доступность планов и контактов и проверять их 2.

FitSM объединяет непрерывность с доступностью в один процесс из четырёх требований 3.

COBIT выделяет управление непрерывностью отдельной целью управленияЦель управленияЕдиница описания COBIT: цель с проверяемым содержанием, у которой есть процесс того же имени.COBIT 2019, книга Governance and Management Objectives 4.

Расхождение здесь одно и практическое: объединять непрерывность с доступностью разумно для небольшой организации, но так легко потерять разбор влияния на бизнес — работу, которую обычная практика доступности не делает.

Где описано

Что почитать дальше

Три соседние практики, с которыми непрерывность живёт в связке: AVLУправление доступностью — где заканчивается обычная работа, RSKУправление рисками — откуда берутся оценки, SECУправление информационной безопасностью — что защищаем в первую очередь.