IT AS IS
RTO и RPO. часть 4
Доступность в свою очередь является частью обеспечения непрерывности бизнеса. Вы наверняка слышали такое понятие.
Но что это за непрерывность?
Давайте начнем с определения. Что такое бизнес?
Вот хорошее определение:
Бизнес – способ получения прибыли для его владельцев.
Сервисы могут быть как внутренними (почта, CRM и т.п.), так и внешними (web-сайты, мобильные клиенты т.п.). Но у всех информационных систем (ИС), предоставляющих эти сервисы, есть свои владельцы внутри компании. Сбои, возникающие в работе ИС, ведут к сбоям в работе отдельных подразделений, и влияют на чистый денежный поток.
Давайте рассмотрим варианты.
1. Сбой (отказ в работе системы) не ведет к прямым негативным финансовым последствиям для компании.
Например, в небольшой организации целый день не работал web-сайт. Компания продолжала работать. На доходах/расходах сбой никак не сказался.
2. Сбой повлечет за собой снижение чистого денежного потока.
Пример.
Веб-сервер компании не работает, клиенты не могут разместить заказы. Доходы за текущий период снижаются.
Или.
Ваша компания хостит веб-сайты. Сбой в работе веб-серверов привел к простою по времени больше, чем прописано в контракте с вашими клиентами. Ваша компания выплачивает штрафы за нарушение уровня обслуживания.
3. Сбой в ИС ведет к остановке бизнеса.
Например. Сломался биллинг сервис-провайдера. Считать деньги невозможно.
Всё вполне логично, вы и так это прекрасно понимаете. Что из этих вариантов последствий от сбоев вытекает?
Существует деление на три категории инфосистем, согласно их влиянию на бизнес.
Вот еще один пример.
Почтовая система относится к категории general. Несмотря на то, что сбой в её работе не влияет напрямую на бизнес, тем не менее приводит к финансовым потерям. Как минимум это оплата работы сотрудника ИТ, который занимается восстановлением работы системы.
Потери доступности данных и сервиса тем больше влияют на финансовый результат, чем больше происходит простой сервиса, или потеря данных. О чем я и писал во второй части этой серии.
Как вы думаете, на сбоях каких систем компании больше теряют? Бизнес-критикал или обычных?
Экономия в ИТ
Прекратите экономить чужие деньги!
когда по факту система, собранная из говна и палок «бесплатно» из подручных средств, обходится компании дороже.
Потому нам, технарям, в первую очередь нужно искать технологии, которые помогут развивать информационные системы. А в расчеты привлекайте финансовые структуры своей компании.
Во-первых, просто приятно работать с хорошими системами 😉. Во-вторых, на таких системах вы вырастите в профессиональном плане.
Что такое mission critical
Общие обсуждения
. Просьба не выкладывать ссылки на англ википедию 🙂 и, если это Ваше мнение, то укажите это в скобках.
Влияние на систему (ПО) с точки зрения безопасности, угрозы и прочие не рассматриваем
1. Непрерывность бизнеса (бизнес процессов)
2. SLA к ИТ-услугам (бизнес услугам) в терминалогии ITIL/ITSM
В сети интернет на русском языке по этой теме мне встречалась информация от Альфа банка
Все ответы
В англ. книге по циско от 2004 года нашел информацию по описанию BC и требованиям к ИС (расчет доступности ИС в год и т.д.)
Более точно опишите задачу и требования. (например: готовимся к аудиту и нужно bla
bla; хотим привести инфраструктуру в соответствие к станадрту ISO XXXX и т.п)
По тому что я понял, вам надо курить методологию итиля и т.п. и дальше работать, работать и еще раз работать
Более точно описываю задачу и требования 🙂
1. Требуется информация по определениям Mission Critical (MC) и т.д. с примерами.
2. Привязка Степеней критичности к времени восстановления штатной работы ИС
Делюсь с обществом тем, что нашел в интернете.
1. Нашел и потерял, к сожалению, требования к ИС в книге по циско 2004г. требования к восстановлению ИС для различных режимов работы 7x24x365 и определением mission-critical
2. С сайта республики Коми
Классификация по уровню требуемой непрерывности обслуживания и важности для бизнеса
Многие критические управленческие и технологические процессы опираются на компьютерные системы обработки и хранения данных и не могут функционировать без их использования. Поэтому, обеспечение непрерывности обслуживания и доступности ИТ-решений является важнейшим показателем непрерывности государственного управления в целом, и важным классифицирующим фактором для элементов ИТ-инфраструктуры. Исходя из предъявляемых требований к надежности отдельных элементов и конфигураций ИТ-систем в целом и их восстановлению после сбоев и отказа оборудования, ПО или инфраструктурных элементов, современные ИТ-технологии предоставляют различные архитектурные и конфигурационные решения, обеспечивающие данные требования. С точки зрения обеспечения непрерывности обслуживания управленческих и технологических пользователей и процессов, а также требований к отказоустойчивости, можно предложить следующую классификацию ИТ-решений:
Необходимо учитывать, что общая непрерывность и отказоустойчивость ИТ- конфигураций определяется соответствующей непрерывностью и отказоустойчивостью ее отдельных элементов: аппаратных, программных средств и инфраструктуры, необходимой для ее успешного функционирования – каналов связи, системы электропитания и т.д. и, в конечном итоге, зависит от уровня непрерывности и отказоустойчивости его слабейшего компонента (принцип «слабого звена»). Классификация систем с точки зрения обеспечения непрерывности и отказоустойчивости должна быть одним из решающих факторов при выборе уровня инфраструктуры (ЦОД) для размещения ИТ-систем. В разделе «6.4. Требования к инфраструктуре центров обработки данных (системы хранения и резервирования, серверы)» содержатся общие требования к таким конфигурациям в разрезе ЦОД различного уровня.
Классификация критичности информационных систем
«Альфа-банк надежен, как танк,
А Гамма-банк надежен как банк!»
Когда в разговорах возникает фраза «банковская система», воображение рисует сверхнадёжную систему, построенную на самом дорогом оборудовании, кластеризованную на всех возможных уровнях и ограждённую от окружающего мира доступными и недоступными средствами защиты. Действительно, такие системы существуют. Но…
Если посмотреть вакансии разработчиков в банке, то вполне можно увидеть там среди требований знания Cassandra, MongoDB и других платформ, которые никак не внушают мыслей о 100% доступности. Да и такие СУБД как Oracle или Microsoft SQL Server где-то устанавливают на кластер из дорогих серверов, подключённых к самым надёжным и высокопроизводительным массивам, а где-то – на обычную виртуальную машину в ферме из самого что ни на есть commodity.
Причины очевидны – избыточные решения дороги. Но как найти компромисс между стоимостью платформы и её надёжностью?
Давным-давно, когда информационных систем на предприятии было немного, инфраструктура для каждой системы была произведением искусства. Со временем систем стало больше, поддерживать несколько сотен разных конфигураций оборудования и программного обеспечения стало накладно, и инфраструктурные подразделения пришли к стандартизации. Например, набор инфраструктурных решений для реляционной СУБД, которые могут использовать приложения, может выглядеть так:
Можно составить список «самых важных приложений, которые должны работать во что бы то ни стало». При этом возникает две проблемы:
Конфигурация оборудования для оставшихся приложений зависит от «веса» владельца системы. В результате какой-нибудь сервис электронных больничных листов работает на самом дорогом оборудовании, потому что это любимое детище главного бухгалтера, с которым никому не хочется ссориться. Налицо неразумная трата денег.
Некоторые приложения могут не войти в список «самых важных» потому, что про них не подумали. Например, все помнят про процессиниг банковских карт, но никто не помнит про проверку клиентов по «чёрным спискам», которая должна работать при каждой операции. В результате отказ такой системы становится неприятной неожиданностью и приводит к серьёзным проблемам.
Существует формальная методика, позволяющая сделать правильный выбор и защитить то, что нуждается в защите, не переплатив за то, за что можно не переплачивать.
Для начала вводится классификация приложений по уровню критичности. Как правило, этих уровней четыре. Называться они могут, например, так:
При оценке важно соблюдать два правила:
Систему оценивает бизнес, а не обслуживающее её подразделение IT. Критичность не должна определяться тем, насколько долго или трудоёмко обслуживание системы. Единственный критерий – убытки, которые понесёт бизнес от простоя системы.
Формулировки вопросов, формирующих оценку, должны предусматривать возможность верификации ответов. Разумеется, критерии всё равно основаны на экспертной оценке, но эксперт, по крайней мере, может объяснить, почему он поставил именно такую оценку.
Что определяет уровень критичности?
Это не значит, что на вашем предприятии распределение систем по классам должно быть именно таким. Но в любом случае – если в класс Mission critical попало больше 15% эксплуатируемых систем, это повод серьёзно задуматься.
На вопрос «насколько нужна та или иная система», любой владелец ответит «очень». Следовательно, нужно задавать другой вопрос: а что случится, если система остановится? Класс критичности системы зависит от тяжести последствий остановки системы и скорости их наступления.
Давайте рассмотрим несколько банковских систем.
Расчётная система обеспечивает (сюрприз!) расчёты между клиентами – юридическими лицами. Если вдруг крупный корпоративный клиент не сможет сделать платёж контрагенту, то банк потеряет весьма существенную сумму, поэтому расчётная система, без сомнения, попадёт в высший класс критичности.
Возьмём карточный процессинг. Если сотня-другая клиентов не смогут расплатиться картой, потери банка будут невелики, но такой массовый отказ в обслуживании недопустим сам по себе.
Теперь возьмём систему, которая ведёт вклады. Если остановится эта система, то убытки банка вновь будут невелики, а отказ в обслуживании не будет столь массовым, как в случае процессинга. Но нужна ли нам передовица в газете с заголовком «Банк отказывается выдавать вклады»? Вопрос риторический.
Наконец, возьмём главную бухгалтерскую книгу. Если вдруг с ней что-то случится, то клиенты ничего не заметят, т. к. эта система в обслуживании клиентов вообще не участвует. Но стоит задержать сдачу баланса, как санкции Центробанка не заставят себя ждать.
Итак, негативные последствия от простоя системы можно разделить на 4 класса:
| 0 | 1 | 2 | 3 | 4 | |
|---|---|---|---|---|---|
| Экономические | нет | 1% плановой прибыли | |||
| Клиентские | нет | 1 клиент | >1% клиентов | >5% клиентов | >10% клиентов |
| Репутационные | нет | огласка маловероятна | огласка в локальных СМИ | огласка в региональных СМИ | огласка в федеральных СМИ |
| Юридические | нет | предупреждения регуляторов | штрафы регуляторов | гражданские иски | риск отзыва лицензии |
Разумеется, все цифры условны, все методики подсчёта основываются исключительно на экспертной оценке, а простор для споров, что считать «региональными СМИ» и как относиться к негативным статьям в популярных блогах, поистине безграничен. Но в крупной корпорации наверняка найдётся и юридический отдел, и PR-служба, которые с готовностью выскажут компетентное мнение.
Следующим шагом нужно выбрать временные интервалы, на которых мы будем оценивать убытки. Например, час, 4 часа, 8 часов, 24 часа. Эти интервалы произвольны и не имеют никакого отношения к SLA, заключённым на оцениваемые системы. Хотя в дальнейшем было бы правильно привязать типовые SLA именно к этим интервалам.
Теперь владелец каждой системы заполняет матрицу из 16 клеток. В таблице ниже числа даны для примера. Единственное, что принципиально важно, – оценка последствий для более длинного интервала не может быть меньше, чем оценка для более короткого интервала.
| до 1 часа | 1..4 часа | 4..8 часов | 8..24 часа | |
|---|---|---|---|---|
| Экономические | 1 | 1 | 3 | 3 |
| Клиентские | 1 | 2 | 2 | 3 |
| Репутационные | 0 | 0 | 1 | 2 |
| Юридические | 1 | 2 | 3 | 4 |
Чтобы из этой матрицы получить окончательную оценку, осталось выполнить три шага.
Шаг первый – для каждого временного интервала выбираем максимальную оценку:
Шаг второй: по матрице транслируем полученные оценки в классы критичности:
| Баллы | до 1 часа | 1..4 часа | 4..8 часов | 8..24 часа |
|---|---|---|---|---|
| 4 | MC | MC | BC | BC |
| 3 | MC | BC | BC | BO |
| 2 | BO | BO | BO | OP |
| 1 | BO | BO | OP | OP |
Для данной системы получаем следующие оценки:
И, наконец, из всех полученных оценок выбираем максимальную – в данном случае оцениваемая система должна быть отнесена к классу Business critical.
Получив эти оценки, мы вполне можем обоснованно выбирать для каждой системы то или иное инфраструктурное решение.
Осталось несколько нюансов, без которых описанная методология была бы неполной.
Если система обеспечивает работоспособность другой системы, то её класс критичности не может быть ниже, чем класс зависимой системы. Например, Active Directory вообще никак не относится к бизнесу. Но если вдруг она встанет, то последствия для многих бизнес-приложений будут самые печальные, и поэтому AD однозначно относится к классу Mission critical.
Убытки, понесённые в результате простоя системы, не могут быть ниже, чем убытки, нанесённые прерыванием бизнес-процесса, который эта система обеспечивает. В свете этого правила очень интересно бывает оценить корпоративную систему электронной почты, ибо внезапно оказывается, что на неё завязан обмен критичной информацией.
Если в компании одну систему используют несколько блоков, и оценки этих блоков для системы отличаются, то следует использовать максимальную оценку. Мало того, даже критерии оценки могут быть разными. Так, например, оценка невозможности обслужить одного клиента может сильно отличаться в зависимости от того, что это за клиент – обычный «физик», VIP или крупный корпоративный клиент.
Снабдите свои системы ярлыками – и да будет ваша инфраструктура не менее надёжна, чем нужно, но и не дороже, чем можно!
Mission critical communication и при чем тут NFV?
Ищут пожарные,
Ищет милиция.
Примеры проектов, где используется ПМР
Смайлик во введении был неспроста – все, разумеется, не так легко. Начинаем погружаться в стандарты… Основная функциональность ПМР – это надежная голосовая связь, поэтому прежде всего смотрим, что предлагает LTE. С удивлением обнаруживаем, что голос в LTE изначально не был предусмотрен и технологии, используемые для VoLTE прошли нелегкий путь от Circuit-Switched Fallback (CSFB) до использования IMS (IP Multimedia Subsystem). На текущий момент использование IMS или SIP core в LTE признано целевой архитектурой для мобильных сетей. Что такое IMS? Стандарты IMS появились задолго до LTE и используются для организации передачи голоса и видео в пакетных сетях передачи данных. Очень упрощенная схема выглядит так:
Cложную схему даже не буду пытаться рисовать, т.к. IMS — это отдельный мир с сотнями стандартов, если интересно, немного подробнее тут: «Предоставление голосовых услуг в сетях связи следующего поколения». Кратко по схеме. Основная идея IMS – это разделение архитектуры на слои: транспортный, управление и уровень приложений. На транспортном уровне находится MRF (Media Resource Function), она обеспечивает реализацию таких услуг, как: конференц-связь, оповещение, перекодирование передаваемого сигнала и MGW (Media Gateway) – медиа-шлюзы. Для упрощения схемы тут же нарисовал MGCF (Media Gateway Control Function) – функцию управления транспортными шлюзами, хотя на самом деле она находится на уровне управления. Коммутацию и управление вызовами осуществляет CSCF (Call Session Control Function), которая взаимодействует с серверами приложений и медиа шлюзами по SIP протоколу. Профили абонентов хранятся в HSS, взаимодействие HSS c миром происходит по Diameter-протоколу.
VoLTE
Как же стыкуется IMS c LTE? Для этого есть специальный стандарт c требованиями: GSMA PRD IR.92 v9.0: «IMS Profile for Voice and SMS». Т.е. если у оператора уже есть система IMS, то он интегрирует ее в соответствии со стандартом. Если нет, то для VoLTE можно ограничиться функциональными элементами, реализующими только необходимые интерфейсы, тогда это будет называться SIP core. Внесем в схему LTE сеть:
Реальная архитектура будет зависеть от того, какие системы уже существуют у оператора связи. Для наглядности не делил PGW (Packet Data Network Gateway) для IMS и Internet. Опять же для наглядности нарисовал HSS общим для LTE, IMS и PCRF, хотя HSS для LTE и IMS в общем случае разные, а для PCRF надо рисовать отдельный UDR или SPR. PCRF (Policy and Charging Rules Function) в LTE управляет скоростью трафика, который проходит через PGW. Соответственно, когда CSCF понимает, что начинается голосовой вызов, то дает команду PCRF установить для трафика определенный приоритет QCI (QoS Class Identifier), подробнее про PCRF можно посмотреть тут: «Тарификация современных услуг передачи данных в мобильных сетях связи и управление политиками обслуживания абонентов».
Для установки и контроля голосового вызова в VoLTE необходимо, чтобы SIP шел от абонентского устройства, т.е. устройство должно поддерживать SIP нативно или через приложение. На схеме показаны потоки SIP сигнализации (красные стрелки мелким пунктиром) и данных (синие стрелки крупным пунктиром). Application сервера используются для реализации услуг поверх чистого VoLTE, например для организации переадресации вызовов, реализации черных/белых списков и т.п.
MCPTT
Так, с VoLTE немного разобрались, для MCPTT требования к сети ужесточаются:
Добавляется новая функциональность – широковещательная связь: один ко многим, многие ко многим.
Необходима приоритизация звонков и трафика, для этого вводятся специальные QCI 65,66, которые должны обеспечивать задержку голоса не более чем 75 ms и 100 ms соответственно.
Сами устройства также должны поддерживать MCPTT нативно и иметь возможность взаимодействовать друг с другом напрямую, без наличия сети связи.
Давайте обратимся к стандартам и посмотрим, что же нужно сделать оператору связи, чтобы запустить MCPTT поверх LTE. В соответствии со стандартом в MCPTT появляются элементы для поддержки широковещательных сообщений MBMS GW (Multimedia Broadcast Multicast Services) и BM-SC (Broadcast Multicast Services Centre), а также MCPTT Application Service и для реализации логики услуги и MCPTT User DB для настройки и хранения групп абонентов:
Чуть более подробно. MCPTT Application Service состоит из MCPTT server, «Common service core», MCPTT User Database и MCPTT клиента, работающего на пользовательском терминале. От схемы из стандарта становится грустно:
Поэтому нарисовал более наглядно:
MCPTT server
MCPTT server – функциональный элемент (реализующий GCS AS (Group Communication Service Application Server), как описано в 3GPP TS 23.468) для контроля широковещательных (multicast) и одиночных вызовов. MCPTT server включает в себя SIP AS (Application Server), HTTP клиент и сервер. Взаимодействует с IMS и MTTP client по SIP протоколу для:
Common service core
Взаимодействует с функциональным элементом «Common service core» по HTTP и SIP протоколам. Common service core обеспечивает:
При чем тут NFV?
Про то, что такое NFV я уже писал. Как же связаны Network Functions Virtualization и MCPTT? Для операторов связи запуск VoLTE – это второй шаг после построения самой сети LTE. Но у большинства операторов отсутствует IMS. Возникает естественное желание минимизировать денежные и трудовые затраты. Разворот виртуальной среды и запуск на ней необходимых элементов IMS в виде виртуальных сетевых функций (VNF) позволяет быстро достичь желаемого. Также хорошо виртуализируются и другие сетевые функции, например, HSS или PCRF. И если у оператора они отсутствуют, их виртуализация вполне логична. К тому же к элементам самой системы MCPTT предъявляются требования работы в виртуальных средах. Что, наверное, стоит делать железным, так это функцию «Media distribution», которая осуществляет кодирование потоков данных.
Так что для NFV нашлось еще одно достойное применение – MCPTT service!
