Классификация критичности информационных систем

«Альфа-банк надежен, как танк,
А Гамма-банк надежен как банк!»

Виктор Пелевин, «Числа»

Когда в разговорах возникает фраза «банковская система», воображение рисует сверхнадёжную систему, построенную на самом дорогом оборудовании, кластеризованную на всех возможных уровнях и ограждённую от окружающего мира доступными и недоступными средствами защиты. Действительно, такие системы существуют. Но…



Если посмотреть вакансии разработчиков в банке, то вполне можно увидеть там среди требований знания Cassandra, MongoDB и других платформ, которые никак не внушают мыслей о 100% доступности. Да и такие СУБД как Oracle или Microsoft SQL Server где-то устанавливают на кластер из дорогих серверов, подключённых к самым надёжным и высокопроизводительным массивам, а где-то – на обычную виртуальную машину в ферме из самого что ни на есть commodity.

Причины очевидны – избыточные решения дороги. Но как найти компромисс между стоимостью платформы и её надёжностью?

Давным-давно, когда информационных систем на предприятии было немного, инфраструктура для каждой системы была произведением искусства. Со временем систем стало больше, поддерживать несколько сотен разных конфигураций оборудования и программного обеспечения стало накладно, и инфраструктурные подразделения пришли к стандартизации. Например, набор инфраструктурных решений для реляционной СУБД, которые могут использовать приложения, может выглядеть так:

• серверы класса hi-end с дисковыми массивами класса hi-end плюс синхронная репликация;
• серверы класса midrange с дисковыми массивами класса midrange плюс синхронная репликация;
• серверы класса midrange с дисковыми массивами класса midrange плюс асинхронная репликация;
• commodity-серверы с дисковыми массивами класса midrange без репликации.

Как же теперь выбрать конфигурацию для конкретной базы данных, принадлежащей конкретному приложению?

Можно составить список «самых важных приложений, которые должны работать во что бы то ни стало». При этом возникает две проблемы:

Конфигурация оборудования для оставшихся приложений зависит от «веса» владельца системы. В результате какой-нибудь сервис электронных больничных листов работает на самом дорогом оборудовании, потому что это любимое детище главного бухгалтера, с которым никому не хочется ссориться. Налицо неразумная трата денег.

Некоторые приложения могут не войти в список «самых важных» потому, что про них не подумали. Например, все помнят про процессиниг банковских карт, но никто не помнит про проверку клиентов по «чёрным спискам», которая должна работать при каждой операции. В результате отказ такой системы становится неприятной неожиданностью и приводит к серьёзным проблемам.

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

Для начала вводится классификация приложений по уровню критичности. Как правило, этих уровней четыре. Называться они могут, например, так:

• Platinum;
• Gold;
• Silver;
• Bronze.

Или так:

• Mission critical;
• Business critical;
• Business operational;
• Office productivity.

Эти четыре уровня прекрасно ложатся на 4 разных конфигурации инфраструктуры. Осталось только отнести каждое приложение к нужному классу.

При оценке важно соблюдать два правила:

Систему оценивает бизнес, а не обслуживающее её подразделение IT. Критичность не должна определяться тем, насколько долго или трудоёмко обслуживание системы. Единственный критерий – убытки, которые понесёт бизнес от простоя системы.

Формулировки вопросов, формирующих оценку, должны предусматривать возможность верификации ответов. Разумеется, критерии всё равно основаны на экспертной оценке, но эксперт, по крайней мере, может объяснить, почему он поставил именно такую оценку.

Что определяет уровень критичности?

• Приоритет обслуживания при массовых инцидентах. Безусловно, любую систему нужно восстанавливать после аварии, но если авария задела несколько систем, то сначала нужно восстановить наиболее критичные.
• Типовые значения SLA (service level agreement). Если простой системы приносит убытки, то правильный путь – не жаловаться на администраторов, а повышать её уровень критичности.
• Стандартные инфраструктурные решения. Каждое из перечисленных выше решений обладает определёнными характеристиками надёжности, обеспечивающими скорость восстановления при сбоях, а также определённой стоимостью.

В мировой практике сложилось примерно такое распределение:



Это не значит, что на вашем предприятии распределение систем по классам должно быть именно таким. Но в любом случае – если в класс Mission critical попало больше 15% эксплуатируемых систем, это повод серьёзно задуматься.

На вопрос «насколько нужна та или иная система», любой владелец ответит «очень». Следовательно, нужно задавать другой вопрос: а что случится, если система остановится? Класс критичности системы зависит от тяжести последствий остановки системы и скорости их наступления.

Давайте рассмотрим несколько банковских систем.

Расчётная система обеспечивает (сюрприз!) расчёты между клиентами – юридическими лицами. Если вдруг крупный корпоративный клиент не сможет сделать платёж контрагенту, то банк потеряет весьма существенную сумму, поэтому расчётная система, без сомнения, попадёт в высший класс критичности.

Возьмём карточный процессинг. Если сотня-другая клиентов не смогут расплатиться картой, потери банка будут невелики, но такой массовый отказ в обслуживании недопустим сам по себе.

Теперь возьмём систему, которая ведёт вклады. Если остановится эта система, то убытки банка вновь будут невелики, а отказ в обслуживании не будет столь массовым, как в случае процессинга. Но нужна ли нам передовица в газете с заголовком «Банк отказывается выдавать вклады»? Вопрос риторический.

Наконец, возьмём главную бухгалтерскую книгу. Если вдруг с ней что-то случится, то клиенты ничего не заметят, т. к. эта система в обслуживании клиентов вообще не участвует. Но стоит задержать сдачу баланса, как санкции Центробанка не заставят себя ждать.

Итак, негативные последствия от простоя системы можно разделить на 4 класса:

• Экономические (непосредственные убытки);
• Клиентские (отказ в обслуживании);
• Репутационные (негативные реакции в средствах массовой информации);
• Юридические (от предупреждений и штрафов до судебных исков и отзыва лицензии).

Для каждого класса последствий следует сформулировать критерии тяжести и присвоить им оценки от 0 до 4. Например, таблица может выглядеть так:


Разумеется, все цифры условны, все методики подсчёта основываются исключительно на экспертной оценке, а простор для споров, что считать «региональными СМИ» и как относиться к негативным статьям в популярных блогах, поистине безграничен. Но в крупной корпорации наверняка найдётся и юридический отдел, и PR-служба, которые с готовностью выскажут компетентное мнение.

Следующим шагом нужно выбрать временные интервалы, на которых мы будем оценивать убытки. Например, час, 4 часа, 8 часов, 24 часа. Эти интервалы произвольны и не имеют никакого отношения к SLA, заключённым на оцениваемые системы. Хотя в дальнейшем было бы правильно привязать типовые SLA именно к этим интервалам.

Теперь владелец каждой системы заполняет матрицу из 16 клеток. В таблице ниже числа даны для примера. Единственное, что принципиально важно, – оценка последствий для более длинного интервала не может быть меньше, чем оценка для более короткого интервала.


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


Шаг второй: по матрице транслируем полученные оценки в классы критичности:


Для данной системы получаем следующие оценки:


И, наконец, из всех полученных оценок выбираем максимальную – в данном случае оцениваемая система должна быть отнесена к классу Business critical.

Получив эти оценки, мы вполне можем обоснованно выбирать для каждой системы то или иное инфраструктурное решение.

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

Если система обеспечивает работоспособность другой системы, то её класс критичности не может быть ниже, чем класс зависимой системы. Например, Active Directory вообще никак не относится к бизнесу. Но если вдруг она встанет, то последствия для многих бизнес-приложений будут самые печальные, и поэтому AD однозначно относится к классу Mission critical.

Убытки, понесённые в результате простоя системы, не могут быть ниже, чем убытки, нанесённые прерыванием бизнес-процесса, который эта система обеспечивает. В свете этого правила очень интересно бывает оценить корпоративную систему электронной почты, ибо внезапно оказывается, что на неё завязан обмен критичной информацией.

Если в компании одну систему используют несколько блоков, и оценки этих блоков для системы отличаются, то следует использовать максимальную оценку. Мало того, даже критерии оценки могут быть разными. Так, например, оценка невозможности обслужить одного клиента может сильно отличаться в зависимости от того, что это за клиент – обычный «физик», VIP или крупный корпоративный клиент.

Снабдите свои системы ярлыками – и да будет ваша инфраструктура не менее надёжна, чем нужно, но и не дороже, чем можно!