В методологии ITIL управление непрерывностью предоставления ИТ‑услуг как составная часть управления непрерывностью бизнеса (Business Continuity Management — BCM) наравне с управлением изменениями или финансами в ИТ получило название «процесс». Руководитель службы непрерывности бизнеса ОАО «ВымпелКом» Виталий Задорожный считает, что так называть BCM не вполне корректно. В интервью нашему журналу он рассказал, каким образом в компании, чьи доходы за один только час можно грубо оценить в миллион долларов, анализируется воздействие чрезвычайных ситуаций (ЧС) на бизнес (Business Impact Analysis — BIA) и оцениваются возможные потери от ЧС.
Intelligent Enterprise: Управление непрерывностью предоставления ИТ-услуг — достаточно «высокоуровневый» и сложный процесс. Очевидно, он требует определенной управленческой зрелости. Каким предварительным условиям должна удовлетворять компания, желающая поставить управление непрерывностью бизнеса?
Виталий Задорожный: Прежде чем заняться управлением непрерывностью бизнеса, любое предприятие обязательно должно выйти на определенный уровень зрелости. К моменту начала таких работ нужно хорошо понимать, что такое риск, и говорить в компании на языке рисков. Если организация еще находится в стадии стремительного роста и ее руководители больше думают о выручке, чем о рисках, зачастую действуя без оглядки, то заниматься BCM здесь еще рано. Вы не сможете объяснить менеджерам такого бизнеса, зачем вкладывать средства в управление рисками и защиту инвестиций. Все ваши рассуждения о выявлении зависимостей и оценке рисков натолкнутся на то, что правление компании будет готово принять любой риск, лишь бы не инвестировать мер по его снижению, не приносящих компании прибыль. Нужно, чтобы руководители пришли к пониманию, что вести бизнес, игнорируя эти вопросы, непрофессионально. Решение о начале работ по BCM должно принимать именно высшее руководство, потому что управление непрерывностью касается любых бизнес-процессов, происходящих в организации.
Когда необходимость в BCM возникла в «ВымпелКоме» и как вы проводите анализ воздействия ЧС на бизнес?
В нашей компании к BCM пришли после принятия централизованной стратегии развития ИТ. Тут же возникла проблема с единой точкой отказа. Пока ИТ-инфраструктура распределена, выход из строя любого ее звена может стать серьезным ударом для бизнеса, но не будет смертельным. После централизации «ВымпелКома» потеря одного здания, работающего на всю Москву или каждый из регионов России, равносильна уходу из бизнеса. Очень понятный руководству пример. Хочу подчеркнуть, что BCM направлен только на операционные риски. Например, риском отзыва лицензии у оператора сотовой связи мы не занимаемся.
Что касается анализа воздействия ЧС на бизнес, то мы проводим его каждый год, и длится такой анализ два-три месяца. Уже по срокам понятно, что это очень сложный процесс. С методикой нам помогли консультанты, причем внедряла ее одна компания, а аудит проводила другая. Я считаю, что иначе не получится по‑настоящему непредвзятой проверки. Руководствовались мы в основном британским стандартом BSI 25999, который вырос из более старого BSI PAS 56, претерпев косметические изменения, но не поменяв своей сути.
Главная цель анализа для нас — составить актуальный бизнес-профайл, т. е. понять бизнес: что его волнует больше всего, какие потери для него приемлемы, а какие нет и где проходит критическая черта, как он изменился за прошедший год, какие новые сервисы появились и как изменилась критичность старых. Предположим, год назад стартовал масштабный проект и планируемый уровень прибыли смело позволял принять его критичность за высший уровень (mission critical). Но прошло время, появились новые технологии, и проект уже не приносит той финансовой отдачи, на которую изначально рассчитывали. А значит, пора пересмотреть отношение к нему и высший класс резервирования заменить на более дешевый с точки зрения поддержки. Подобные изменения выявляются в ходе BIA.
При проведении анализа мы руководствуемся подходом сверху вниз («top-down approach»), т. е. начинаем с высшего менеджмента, постепенно спускаясь по организационной лестнице всё ниже и детализируя вопросы. Руководству компании мы объясняем, что хотим очень четко понять, что в нашем бизнесе есть вообще и что из этого наиболее критично. На этом уровне мы должны, во‑первых, узнать, на каких зонах риска стоит акцентировать внимание, и во‑вторых, кто из подчиненных сотрудников за эти зоны отвечает. На следующем, более низком управленческом уровне опросов нам нужно прописать бизнес-процессы компании, понять, сколько каждый из них приносит выручки и на какие элементы ИТ и технологической инфраструктуры эти процессы опираются. Так постепенно экспертное интервью с высшим руководителем превращается в десяток интервью с его подчиненными, а потом в тридцать интервью с менеджерами и экспертами, которые уже могут объяснить, что такое конкретная ИТ-функция и как она влияет на указанную бизнес-функцию. Руководитель, с которого опрос начинался, занимается совершенно другими вещами.
На следующем уровне опросов мы разговариваем непосредственно с ИТ-подразделением, технической дирекцией и у администраторов выясняем внутренние взаимосвязи систем. Это тоже необходимо, так как бизнес-руководители могут сказать, например, не углубляясь в технические детали, что управление отношениями с клиентами (CRM) опирается на три ИТ‑системы. Но технические специалисты обязательно уточнят, что на самом деле есть еще две системы, без которых процесс работать не будет. Просто бизнес их не видит.
В результате такого многоуровневого анализа мы определяем воздействие на бизнес любой мало-мальски значимой ИТ‑системы. Важна связь с актуальной базой данных конфигурационных единиц (CMDB), в которой прописана критичность каждой такой единицы и, самое главное, взаимосвязи между ними. На выходе BIA мы получаем совокупность Excel-файлов и можем корректно просчитать финансовое воздействие чрезвычайных ситуаций. Мы должны определить стоимости рисков и насколько дорогим окажется их снижение на определенное число процентов. Без этого бизнес нас не поймет. Руководству надо сказать очень конкретно: под риском ходит пять миллиардов, можно вложить десять миллионов и снизить риск на 20%. При этом есть неснижаемый 8%-ный остаток, потому что цена дальнейшего снижения риска уже становится равной тем же пяти миллиардам.
Можно ли с помощью этих данных убедить руководство организации в необходимости управления непрерывностью бизнеса?
Да, пользуясь этими числами, мы объясняли свой анализ влияния ЧС на бизнес на заседании правления компании. Рассказывали о текущем статусе всех площадок — о проблемных зонах, оценках с точки зрения disaster recovery, о предлагаемой нами стратегии. По каждой такой области сформулировали задачи BCM на ближайшие пять лет. Назвали бюджет и возможные потери от остановки программы. Полученную картину можно отразить вот таким графиком (см. рис. 1).
Темно‑синяя линия показывает текущий запланированный рост прибыли компании. Красная линия отображает, как прибыль организации будет вести себя в случае ЧС. Надо пояснить, почему она опускается ниже нуля. Представим, что мы потеряли свое центральное здание, — в этот момент прибыль опускается до нуля. Но кроме того необходимо платить зарплату сотрудникам, есть у компании и другие обязательства, контракты, по которым нужно проводить выплаты. Отсюда и получаем отрицательное значение в первое время после катастрофы.
В следующие три месяца мы найдем помещение и подведем к нему нужную электроэнергию, отстроим серверные комнаты, закажем аппаратное обеспечение. И месяца через четыре снова запустим самые важные сервисы начиная с биллинга. Продолжим эти кривые до конца года, и площадь между графиками даст нам финансовое выражение воздействия ЧС на бизнес.
Светло‑синяя линяя — это следствие ЧС, аналогичное темно‑синей кривой, но с учетом уже внедренных BCM-решений. Если у нас уже есть резервная площадка, зарезервировано двадцать критичных систем и простроен процесс восстановления пяти бизнес-функций, то в случае ЧС мы их защитим, а потеряем лишь то, что осталось. Если бы мы хотели донести до высшего руководства только это, то было бы достаточно одного графика с тремя кривыми. Однако показательны два графика по разным годам. По ним видно, что бизнес продолжил свой рост. Соответственно и объем потенциальных потерь от ЧС за этот год стал выше. На мой взгляд, самое тяжелое в BCM — это держать руку на пульсе. Слишком просто почувствовать себя спокойно после очередного внедрения, когда кажется, что в проектной и процессной части все хорошо. На самом деле ты уже отстал. Бизнес успел за это время уйти вперед, купить себе еще одну организацию, принять решение об освоении еще одного сегмента рынка и так далее и так далее.
Как классифицируются ваши ИТ‑системы с точки зрения управления непрерывностью бизнеса?
По двум параметрам, хотя сейчас появляется и третий. Для того чтобы говорить о восстановлении конкретных процессов и поддерживающих их систем в случае ЧС, нужны параметры recovery time objective — RTO и recovery point objective — RPO. Первый из них определяет минимальное время восстановления в случае ЧС. Бизнес должен заявить, сколько времени можно работать без определенной функции, — скажем, четыре или двадцать четыре часа мы готовы без нее прожить. А RPO — это приемлемое время потери данных. Если мы готовы биться за сохранение информации о каждой транзакции, то должны использовать дорогостоящую технологию, которая гарантирует нулевую потерю данных при их передаче в резервный вычислительный центр. Если же допустимо потерять данные за сутки и более, то вместо синхронной или асинхронной репликации вы можете использовать удаленное резервное копирование, что обойдется компании на порядок дешевле. Совокупность RTO и RPO мы называем классом критичности.
Мы используем классификацию по четырем классам критичности. Заметьте, что для первого класса RPO составляет 4 часа, но даже просто восстановить с ленты 10 Тбайт данных за четыре часа невозможно, а для хранения информации из систем, отнесенных у нас к первому классу, требуются именно такие объемы. Причем восстановление с ленты — это еще далеко не запуск приложения. Отсюда появляется необходимость держать актуальные данные в резервном вычислительном центре, чтобы для возобновления работы оставалось только переключить кластер.
По новым стандартам существует еще один параметр — максимальное время разрушения. Его смысл — задать для каждого сервиса время, по истечении которого за него уже бесполезно бороться. Допустим, если не восстановили услугу за сутки, то можно забыть о ней и перераспределить ресурсы, сфокусировавшись на других вещах.
Как вы узнаете параметры RTO и RPO для конкретной ИТ‑системы?
Сначала каждое крыло «ВымпелКома» оценивает обычные операционные риски, начиная от отключения электроэнергии и заканчивая серьезными ИТ‑сбоями. В опросниках мы указываем основные сервисы и поддерживающие их приложения. Задача отвечающего — отметить критичность данного сервиса для компании именно с точки зрения его функции. И ключевые приложения, поддерживающие сервис, респондент указывает именно так, как видит их его крыло. Кроме того, мы задаем вопросы о финансовом воздействии ЧС: начиная с какого времени простоя начинаются небольшие потери, когда они возрастают до средних и когда становятся значительными? Все ответы мы сводим в единую таблицу и тщательно анализируем. Понятно, что для финансового отдела наивысшую критичность имеет их опорная финансовая система. Они всегда пишут, что без нее высокий уровень потерь наступает уже через четыре часа. Зато коллеги из call-центров эту систему считают совершенно некритичной. А, например, мнение коллег из отделов массовых продаж или маркетинга — это уже другая история. Так что вопрос в том, чтобы дать обоснованное сбалансированное решение по каждой системе, с понятной для всех аргументацией выбора класса восстановления.
Есть еще один интересный нюанс. ИТ‑система может быть крайне критична в обычной повседневной работе, а вот в случае ЧС без неё все спокойно проживут одну-две недели.
Это значит, что в её отношении больше внимания следует уделять процессу доступности — availability, а не непрерывности бизнеса.
Вы закончили анализ влияния ЧС на бизнес, потом классифицировали системы согласно RTO и RPO. Что дальше?
Дальше каждый домен, входящий в BCM, начинает жить своей жизнью. В технических подразделениях инициируются процессы разработки проектов решений disaster recovery для конкретных систем, которые позволят реализовать требования бизнеса по восстановлению в случае ЧС. Используя полученные данные, мы можем посчитать бюджет любой из возможных реализаций. Построив, допустим, три модели, с ними можно идти в бизнес, показывать и, используя свою экспертную оценку, пояснить, к какому варианту склоняемся мы с точки зрения бюджета, сложности внедрения, эксплуатации и поддержки. А дальше уже пусть бизнес принимает решение, по какому пути ему лучше идти и какие ресурсы для снижения риска в определенной области он готов выделить.
Очень важно с самого начала четко дать понять бизнесу, что BCM — это не проект, а процесс. Или, точнее, даже культура. То, что мы сейчас снизим какой‑то риск, еще не значит, что это останется таким навсегда. Риск-профайл компании постоянно меняется, так что процесс BCM должен жить и циклично совершенствоваться наравне с остальными процессами. Жизненный цикл процесса начинается с понимания бизнеса организации, после чего вырабатывается и принимается стратегия (см. рис. 2. — Прим. ред.). В соответствии с ней строятся планы внедрения, разделяются зоны ответственности за выполнение плана, выстраивается культура. Теперь люди знают, что делать в случае ЧС. Результаты всех этих шагов должны постоянно тестироваться, проверяться. Как минимум раз в год.
Отдельно хочу сказать о work recovery для бизнес-подразделений. Это довольно интересная и уникальная вещь, к сожалению, пока еще очень мало используемая, хотя по идее она является сутью BCM для технологичных компаний. Для ИТ мы поняли, какие системы нужно поднять в первые четыре часа, а какие — на вторые сутки. Точно так же и для каждой бизнес-функции необходимо понимать, в какой последовательности и в каком объеме после ЧС должны начинать работу сотрудники. Скажем, подразделения продавцов или поддержки пользователей. Если мы теряем свою штаб-квартиру, то через какое время следует найти и обеспечить определенное количество рабочих мест, чтобы восстановить ту или иную функцию? Может получиться так, что для какой‑либо функции развития в течение месяца после ЧС можно вообще ничего не делать. Потому что в форс-мажорных обстоятельствах главный фокус должен быть на удержании того, что есть, а не на развитии.
Были ли случаи, когда наработки BCM приходилось применять в реальных ситуациях?
Масштабных ЧС у нас не было, но серьезные были. Тогда за счет уже внедренных решений по резервированию нам удавалось очень существенно снизить влияние этих ситуаций на бизнес компании. В прошлом году во время сбоя в комплексе бесперебойного питания мы потеряли два серверных помещения, в которых находилось порядка сотни стоек оборудования. Наиболее критичные сервисы тогда сразу же удалось поднять в резервном центре, менее критичные были запущены позже с учётом их более длительного времени восстановления. Главное, что в резервном вычислительном центре уже было, во‑первых, аппаратное обеспечение и, во‑вторых, все нужные для возобновления работы данные.
Проводится ли у вас моделирование ЧС, обучение команды восстановления?
Вся инфраструктура, необходимая для обеспечения непрерывности, тестируется раз в полгода. На тестах проверяется всё аппаратное обеспечение, ведётся пошаговый анализ документации. Рассчитывается коэффициент готовности, хотя пока мы ведем его только для ИТ как наиболее развитого крыла. Эта интегральная оценка показывает отношение выполненных успешно тестов к запланированным. При этом каждому тесту присваивается свой удельный вес от одного до пяти, т. е. значимость разных тестов не одинакова. В последний раз коэффициент готовности у нас получился равным 85%, так как порядка пяти тестов дали плохой результат. Например, из‑за того, что в процессе жизненного цикла в главном вычислительном центре появилось несколько дополнительных терабайт для хранения данных, а в резервном — нет. Тестирование нужно проводить, чтобы внедренные решения не деградировали. В BCM вообще нужно жить по принципу из «Алисы в зазеркалье»: «Чтоб остаться на месте, надо бежать изо всех сил, а чтоб двигаться вперед, надо бежать в два раза быстрее».
