«В обеспечении непрерывности бизнеса главное слово – «бизнес»!»

В компании «ВымпелКом» начинался большой проект IT Disaster Recovery, лидировала в проекте служба информационной безопасности (ИБ). Внутри проектной команды ИБ были созданы специальные группы: Planning Stream (вели работу по созданию планов реагирования и кризисного управления) и Technical Stream (отвечали за внедрение технических решений). Собственно, меня позвали возглавить Planning Stream… Далее все это переросло в большой процесс IT Service Continuity Management (ITSCM) и со временем превратилось в программу Business Continuity Management (BCM). В какой-то момент мы поняли, что с точки зрения ITIL процесс ITSCM «бегает» правильно и хорошо, взаимодействует с классическими ИТ-процессами: Availability, Capacity, Problem, Change, но с точки зрения бизнеса у него не было верхней подпорки, не было сформированной бизнес-картинки, включающей управление рисками, восстановление end-to-end бизнес-процессов и верхнеуровневого кризисного управления. Мы получились «чистым» ИТ-процессом. Опыт больших аварий показал, что в таком несколько однобоком мире жить нельзя, особенно телекому, где и раньше разрыв между ИТ и сетью был небольшим, а скоро его совсем не будет.

Вариантов несколько. Вариант первый, самый неприятный: тон задает тяжелая авария. Второй вариант: сам бизнес, люди, которые видят риски и управляют ими, которые понимают, что, если у соседа загорелось сегодня, завтра может загореться и у меня. Если человек приходит к какому-то пониманию рисков, дальше он хочет их оценить, а после оценки он начинает ими управлять. Вообще говоря, можно ничего не делать – это тоже возможный вариант стратегии, и она имеет право на жизнь, но это спорная бизнес-модель. И третий вариант – это уровень технических руководителей… CTOCIO, которые понимают, что нарушение процесса предоставления бизнес-услуги, вне зависимости от масштаба причины, – это их зона ответственности, и они точно не имеют права просто сидеть и не обращать внимания на риски, тогда они «продают» бизнесу эту идею. Приходят и говорят: «Вот моя боль, вот оцифрованный риск и меры по его снижению до приемлемого уровня, бюджет и сроки. Берем или не берем?» Ведь так или иначе вся непрерывность бизнеса, все кризисное управление крутится вокруг простых вещей: в компании не должно быть «серых зон». Если ты обнаружил такую зону, оцифровал ее, показал бизнесу, дальше вы решаете вместе: «Бежим или не бежим?» Если «не бежим», отлично – вот протокол принятия риска. Мы все взрослые люди, сели, посовещались, решили – это нормально. Не должно быть такого, что у нас есть пул тревожных недомолвок, который иногда генерирует нам аварии, но мы им не занимаемся, потому что там все запутано и непонятно. Как говорится, сколько мусорное ведро не утрамбовывай, все равно выносить придется – все такие проблемы рано или поздно дают о себе знать и всегда с отрицательной стороны.

Это не синонимы. Это связанные процессы одного клубка, но ни один из них не первичен! С одной стороны, нельзя управлять непрерывностью бизнеса, не просчитав риски и не приняв меры по некоторым из них. С другой стороны, управлять рисками бизнес-операций без непрерывности бизнеса можно, но это из разряда «теоретически я умею колоть дрова». Ну и что, что ты управляешь рисками, если при этом ничего не предпринимаешь? Нужно понимать, почему в России так сложно заниматься непрерывностью бизнеса. Россия – очень практичная страна. Когда я был в Англии, посетив пару компаний, я просто рыдал над их построенной непрерывностью. У них нет ничего! Есть только кипа регламентирующих взаимосвязанных бумажек, и они считают, что подстраховались, снизили риск до приемлемого уровня и твердо понимают, куда побегут, когда бизнес начнет по чуть-чуть исчезать после аварии. В России с такой непрерывностью тебя на смех поднимут, скажут: «Это не серьезно… А что вы сделали в технической части? Где то, что можно потрогать? Где резервный центр? Где «Зарница» с переездами из ЦОДа в ЦОД?»

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

Нужно понимать, что 15 лет назад для рынка телекоммуникаций, как для любого «быстрого» бизнеса, был актуален такой подход: строили неважно на чем, главное – побыстрее запуститься и побыстрее побежать, я имею в виду начать расти вширь и вдаль. Например, если мы говорим о ЦОДе, уже и в то время все было построено надежно, но не все риски принимались во внимание, всегда оставалась какая-то мелочевка просто потому, что фокус при таком темпе был на других вопросах. Никто особенно не просчитывал и не смотрел на те риски, которые существовали за периметром ЦОДа, но при этом могли драматически повлиять на его работоспособность. В какой-то момент пришло осознание, что дикорастущий забавный бизнес, приносивший 1 млн долларов, стал 2-миллиардным монстром. А это уже риски совсем другого порядка, и так просто обойтись с ними нельзя.

Международные регуляторы постоянно спрашивают про непрерывность у большого бизнеса. Правда, если драйвером BCM для компании становится внешнее требование, а не внутренний запрос, то непрерывность «растет» из очень странных мест: либо из финансов, либо из рисков, либо из аудита. Хотя, с другой стороны, если непрерывность идет от ИТ, всегда есть риск остаться слишком технологичными.

Очень важно построить диалог на одном языке. С одной стороны, картинка риск-ландшафта, которую видит бизнес, и то ее восприятие, которые хочет передать руководству CIO, в начале пути всегда разные. А с другой стороны, ИТ-руководитель должен уметь на бизнес-языке объяснить, что он хочет, а бизнес должен понимать, во что он вкладывает определенный бюджет и почему он вкладывает его не в развитие бизнеса, а в его непрерывность.

Хорошая мысль: «BIA сближает…» Сделать BIA, прийти в первый раз на правление, показать все риски и пути их снижения, обосновать бюджет – это все отлично, и, как правило, в первый раз поход удается. Проблемы возникают, когда ты приходишь за деньгами во второй раз. Глубокое непонимание начинается с третьего раза…

К сожалению, это нормально, но в процессе построения непрерывности бизнеса всегда появляются неожиданные проблемы: не заложили Сapacity Growth, думали, что лицензии на Oracle будут стоить столько-то, а по факту они дороже, или что лицензии на резервную часть не нужны, а они нужны, построили резервный ЦОД, все прекрасно летает, но… только один ввод электропитания или оптики – и нам что-то случайно отрубили, а мы туда не смотрели и т. д. Конечно, лучше все просчитать и договариваться на берегу… Но так не бывает! Каждый процесс управления непрерывности бизнеса, каждый проект Disaster Recovery абсолютно уникален и обладает своим набором достоинств и сопровождающих их совершенно неожиданных проблем.

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

Во-первых, я по-прежнему за централизацию. Просто сейчас технологии, в принципе, шагнули вперед: вместо разнофункциональных ЦОДов или схемы active-passive можно спокойно сделать распределенный единый виртуальный вычислительный центр. Если инфраструктура «живет» на 3–4 географически распределенных нодах, то в случае аварии сервис спокойно продолжает предоставляться без прерывания с легкой деградацией на любых выживших после аварии нодах… Разумеется, все должно быть централизовано, но при этом бизнес сам себе должен ответить на вопрос: «Централизовано как именно?..» Сейчас я могу сказать точно, что два ЦОДа – это мало. Должен быть приемлемый уровень деградации ИТ-сервиса, при этом должно работать все! Не должно быть пассивной ноды. Все активы должны работать всегда и на всем. Пусть это будут тесты для Production на случай чрезвычайной ситуации, пусть это будут расчеты моделей для Big Data – неважно. Единственное, что имеет право не работать, это вывезенные на грузовиках ленты из ленточных библиотек, и то, если мы так решили реализовать требования регуляторов по offsite-хранению, по-хорошему их раз в полгода надо тестировать на восстановление. Чем больше я занимаюсь этой темой, тем я отчетливее понимаю, что других принципов контроля разумной избыточности, кроме того, что эта разумная избыточность постоянно работает, нет!

В этот процесс должен быть вовлечен человек из финансов, который, собственно, деньги считает и нехотя дает; человек, который в компании управляет рисками, так как вы будете для него одним из блоков, скажем, в разделе «операционные риски», «реагирование на ЧС» и который будет со стороны оценивать вашу деятельность, и человек, который отвечает за выручку в компании, например, коммерческий директор. Эти три управленца и, разумеется, весь технический состав руководства компании… Когда мы смотрим на внедренный и работающий процесс BCM, то мы должны все вместе заниматься целеполаганием, которое заключается в том, что бизнес озвучивает свои планы по развитию на ближайшую перспективу. Владелец BCM в свою очередь обозначает те болевые точки, где потребуются дополнительные вложения, чтобы и выстроенная кривая Risk Reduction не росла, то есть любой новый критичный продукт должен сразу идти с DR-решением, и мы все продолжали жить в Risk Maintenance, то есть все внедренные системы, расширяя Сapacity, учли необходимый прирост в части резервных или балансовых нод.

Приведу пример. Компания решила внедрить CRM. Когда внедрение закончится и CRM заработает, она будет относиться к Business Critical-системам, второго класса восстановления. Это значит, что на этапе планирования те люди, которые отвечают за непрерывность, должны были быть включены в рамках процесса Project Management в экспертную команду проекта CRM, чтобы просчитать с командой внедрения, какая необходима архитектура, железо, СХД и т. д., чтобы в случае ЧС система была восстановлена в соответствии с определенными для нее бизнесом параметрами непрерывности. Соответственно, все эти расходы тоже закладываются в бюджет. В этом случае ты становишься для бизнеса гигиенической нормой базовой оценки и бюджетирования для любого проекта. Иными словами, когда процесс работает, ты, с одной стороны, встроен в организационную культуру операций – все администраторы ведут и Production, и резерв (хотя, как я говорил, лучше, когда все активное), а с другой стороны, ты – часть культуры проектного офиса, все новое сразу делается с анализом влияния на бизнес и внедряется в виде оптимального для бизнеса решения по избыточности.

Непрерывность бизнеса начинается с бизнес-анализа и оценки рисков и должна заканчиваться корпоративной культурой. Если вы стремитесь к действительно работающей модели непрерывности бизнеса, каждый администратор в вашей компании должен понимать: «Если я что-либо изменил в ГВЦ, то же самое должен изменить и в РВЦ». И его начальник должен чувствовать этот подход на своем уровне абстракции. Необходима полная симметричность. В «ВымпелКоме» около двух лет ушло на привитие этой культуры. Администраторы перестали говорить: «Это не наши проблемы… Я отвечаю только за Production», когда поняли, что резервная нода – это для них же самих страховка, когда они оценили, какие бенефиты дает по-настоящему продуманная с их помощью резервная структура.

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

Я считаю, что начинать без консультантов нельзя, жить потом в выстроенном процессе можно, хотя и в этом случае для сертификации или Quality Assurance все равно будут нужны консультанты. Это вопрос о том, как ты хочешь заниматься самонастройкой. Если ты понимаешь, что каждые два года тебе нужно делать health check, точно придется привлекать внешних людей.

Отдельно отмечу нюанс по замене консультантов, так как в любом бизнесе есть своя специфика. Менять консультантов каждый год – не самый оптимальный путь. Лучше, конечно, выбрать кого-нибудь одного, потому что каждый раз будет непростой процесс адаптации, а как я говорил ранее, любой процесс и программа BCM совершенно уникальны, потому не совсем логично каждый год платить за адаптацию нового победителя конкурсных процедур.

Практика показывает, что зачастую консультанты, особенно иностранные, могут прийти и построить очень правильный классический верх: BIA, Risk Assessment, Crisis management и т. д. Но вот именно «бытовые» процессные связки, которые характерны для телекома или банковского сектора, весь «внутренний цинизм» и нюансы могут знать либо специалисты, которые живут внутри, либо интеграторы, которые помогали все это строить.

В «ВымпелКоме» мы ориентировались на британские стандарты PAS56 и BS 25999, позже — на выпущенный на их основе международный стандарт ISO 22301. Мы всегда шли за ним, но делали больше, чем он рекомендует, потому что стандартам свойственна академичность. Когда ты пытаешься выстроить внутри ИТ-процесс по ITIL и при этом сертифицируешься по ISO, который не видит этой связи, у тебя всегда присутствует некоторый разрыв адаптации стандарта на землю.

Если отвечать на вопрос, достаточно ли следовать имеющимся стандартам, я отвечу: «Конечно, недостаточно». Стандарт – это хороший, но общий Practice Guide; так или иначе у него есть три уровня реализации, из них хорошо прописаны первые два. А третий – это и есть то сокровенное знание, что живет в консультанте-практике, который приходит, смотрит и через некоторое время говорит: «Нет, ребята, здесь что-то не так, здесь нужно сделать по-другому».

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

Стандарт – это очень хороший ориентир, на начальном этапе нам он дал процентов 60, а остальные 40 мы нарабатывали сами, практическим путем.

Политику – раз в 3 года, стратегию – каждый год, в зависимости от бизнеса. В непрерывности бизнеса главное слово «бизнес». Это постоянный живой процесс, включающий все, начиная с Business Impact Analysis и заканчивая организационной культурой.

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

Главное в непрерывности – это разумный баланс. С одной стороной, здесь не бывает мелочей, а с другой – нельзя на них зацикливаться. Так можно легко скатиться к техническим проблемам и перестать видеть бизнес-картину целиком.

Как я не раз говорил, важно научиться говорить с бизнесом на языке бизнеса. Сложный момент в непрерывности, особенно в первый раз – это распаковка Business View в бизнес-сервисы, потом бизнес-сервисов в ИТ-сервисы, далее ИТ-сервисов на ИТ-системы, ИТ-системы на элементы инфраструктуры и т. д. Идя по этой дороге, нужно быть уверенным, что тебя на каждом этапе услышали и трактовали правильно. Причем описанный процесс иногда оказывается для ИТ и бизнеса в целом гораздо более полезным, чем для непрерывности…

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

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