«Вокруг царила паника. В двух милях от разрушенных башен Всемирного торгового центра находился один из наших резервных центров обработки данных. Я прибежал туда весь в пыли и грязи. „Все нормально, я с вами, слушай мою команду”,-- говорю собравшимся там сотрудникам. Вдруг кто-то хлопает меня по плечу. Я оборачиваюсь и вижу президента компании, этого небожителя. „Это хорошо, что ты пришел, но главный тут я”,-- говорит он. Уже во второй половине дня мы начали использовать дополнительные ресурсы по восстановлению работоспособности компании. Мы должны были разместить людей так, чтобы все были задействованы на своих местах, но сначала нужно было найти подходящие помещения. На следующее утро мы переместились в наше резервное здание, которое было рассчитано на 50 человек -- топ-менеджеров. Но вскоре под угрозой взрыва нас эвакуировали и оттуда. Это надо было видеть, как 50 самых главных в компании людей полчаса управляли империей Merrill Lynch, стоя на улице под открытым небом».
Так вспоминает о трагических событиях 11 сентября 2001 года в Нью-Йорке Пол Хони, занимавший тогда пост первого вице-президента международной финансовой корпорации Merrill Lynch. Хони отвечал в компании за программы по обеспечению бесперебойности бизнеса, и именно ему довелось руководить восстановлением жизнедеятельности Merrill Lynch после терактов. На Западе он считается самым авторитетным «ликвидатором» последствий самолетной атаки террористов, после которой понятия бесперебойности бизнеса (business continuity) и его восстановления после катастроф (disaster recovery) получили совершенно иное звучание. Многие компании всерьез задумались о том, что нужно сделать, чтобы обезопасить свой бизнес от последствий техногенных и природных катастроф, терактов, сбоев в инфраструктуре, недружественных действий властей, конкурентов, партнеров, своих сотрудников и посторонних мошенников. Конечно, все операционные риски можно застраховать. Но чтобы не разориться на выплатах страховщикам, необходимо эти риски, а вместе с ними и страховые платежи, снизить.
Теперь business continuity в США -- это хорошо проработанная концепция, и каждая компания обязана иметь план по обеспечению непрерывности бизнеса. Пол Хони сейчас возглавляет консалтинговую фирму, помогая клиентам разрабатывать и внедрять у себя программы business continuity, и делится опытом и уроками, вынесенными из той ситуации, которая заставила его стать «ликвидатором».
Советы ликвидатора
«В 13.30 у нас прошел конференц-холл, и мы узнали, что в Нью-Йорке произошел теракт, что башен-„близнецов” больше нет, наши офисные здания сохранились, но сильно пострадали. Как только пришло осознание масштабов беды, мы организовали антикризисный веб-сайт. Это был источник информации и канал коммуникаций. Интернет -- вообще штука очень живучая, и сайт был единственным инструментом коммуникаций, который продолжал работать в компании. На Манхэттене почти не осталось телефонной связи, вещал только один телеканал, испаноязычный, единственное что работало -- интернет и беспроводная электронная почта BlackBerry. К вечеру мы начали рассылать по домашним электронным адресам сотрудников (карточки с их персональными данными были заготовлены в рамках антикризисного плана) инструкции о том, как действовать. Ведь многие люди получили физические и психологические травмы. Их нужно было как-то вернуть к работе. Некоторые департаменты искали своих сотрудников по шесть-восемь недель, вычисляли их по мобильным звонкам, транзакциям через банкоматы и торговые терминалы. Испугавшись, люди не выходили на связь с внешним миром, некоторые сбежали подальше из Нью-Йорка. Поэтому могу утверждать, что коммуникации -- это ключевой фактор восстановления компании после катастрофы. Без этого возобновить работу было бы абсолютно невозможно. И ключевым инструментом для обеспечения коммуникаций в нашем случае был сайт, на котором все заинтересованные лица могли получить подробную информацию о том, кому и что нужно делать.
Работу всех информационных систем мы восстановили за неделю. У нас была огромная информационная среда, полностью зарезервированная: 20 тыс. серверов в распределенных центрах обработки данных, единое хранилище данных. Мы не потеряли ни одного байта, но для восстановления требовалось использовать 20 тыс. магнитных лент, многие из которых оказались в зоне разрушений. Все эти ленты нужно было проверить, а это очень трудоемкая работа. Я бы не советовал делать резервирование полностью на ленточных носителях. Если бюджет позволяет, нужно от них избавляться. С физическими носителями вообще много сюрпризов. Когда я вернулся в наше разрушающееся здание, чтобы найти счета по оплате топ-менеджеров компании, то обнаружил, что бумаги разлетелись по всем окрестным улицам. Еще одна проблема -- взаимодействие с органами, участвующими в устранении последствий катастрофы, Мы столкнулись с 70 различными структурами, включая армию. А с человеком с автоматом ведь не поспоришь. Помню, я пытался пройти в наше здание, а меня не пускали, чуть не пристрелили. Доступ к нашим резервным зданиям в Нью-Йорке оказался в зоне отчуждения, и мы не могли туда попасть. Поэтому резервные центры нужно располагать как можно дальше друг от друга. Не давали о себе забыть и СМИ. Несколько десятков бригад работали в прямом эфире. И когда говоришь на весь мир, приходится думать над каждым словом, чтобы не напугать клиентов.
Меня потом здорово критиковали за то, что 70% сотрудников компании не были вовлечены в работу по восстановлению. Желающих поработать волонтерами было много. И люди хотели общаться друг с другом, а не с электронными сообщениями. Да, мы сделали 30-секундные видеоролики, голосовые сообщения, но возможности широкополосного доступа к рабочим местам все же явно недооценили. Нагрузка на каналы была предельной. Резервные системы нужно строить с таким расчетом, чтобы они обеспечивали доступ большого числа людей к информации.
Но прежде чем заниматься ИТ, нужно обеспечить транспорт, логистику, инженерные коммуникации в зданиях. Я, например, записывал все сведения о людях, отданных им распоряжениях, движении информации внутри компании и наружу в двух журналах. Можно сказать, что с помощью этих книжек мы пережили кризис. Но главное -- это внедренные в корпоративную культуру элементы антикризисного управления. Без серьезных структур и опробованных процедур люди начинают действовать хаотично, на свой страх и риск. Они заботятся лишь о своей зоне ответственности, группе, департаменте, пытаясь получить как можно больше ресурсов. В большой же компании нужно искать компромиссы.
За полгода до 11 сентября в соответствии с планом антикризисного управления мы провели в штаб-квартире учебную тревогу. По этому поводу было много шуток и недовольства. Когда я заявил, что нужно провести учения среди топ-менеджеров, меня чуть не уволили. Многие ворчали, что это пустая трата времени. Но меня поддержал один весьма влиятельный член совета директоров, и я все-таки вытащил из офиса 50 начальников. Мы отрабатывали с ними сценарий урагана на Манхэттене. И какие-то наши наработки оказались жизненно важными 11 сентября, когда мы смогли вывести из горящих зданий 9 тыс. человек. А в других компаниях люди гибли просто потому, что не знали куда бежать и что делать.
В чем-то наш план сработал хорошо, в чем-то -- не очень. Ведь катастрофы такого масштаба никто предвидеть не мог. Но главный итог в том, что через неделю компания смогла вернуться к нормальной работе. Хотя пять наших офисных зданий были сильно повреждены, и нам пришлось срочно закупить и доставить 5,5 тыс. новых компьютеров, организовать транспорт для сотрудников -- около 80 тыс. рейсов: автобусы, паромы, даже вертолеты. Обычно ведь все происходит не совсем так, как ты планировал. Поэтому нужно обеспечить больше гибкости. Дайте людям возможность коммуникаций, и они проявят себя с самой неожиданной стороны. А без этого вы просто ничего не сможете сделать. И это основной аргумент для инвестиций в ИТ.
На восстановление бизнеса мы потратили $17 млн, получили страховки. В целом все обошлось вполне приемлемо. Бизнес не пострадал, ИТ оправдали вложенные в них деньги. И радикально изменилось отношение руководства к планам по обеспечению бесперебойности бизнеса. Помнится, за пять месяцев до катастрофы я проводил совещание руководителей по этой теме, и особого интереса никто не проявил. А после 11 сентября энтузиазм по этому поводу приходилось уже сдерживать. И никого не требовалось убеждать в необходимости затрат на процедуры и технологии, которые бы гарантировали защиту бизнеса в любых обстоятельствах».
План на всякий случай
Опыт Пола Хони, конечно, не дай бог никому повторить. Но понятие business continuity связано не только с катастрофами, которые приводят в ужас весь мир.
В одном среднем российском банке из-за короткого замыкания возник пожар в серверной комнате. В огне погиб мощный сервер с основной информационной системой. Работа всех корпоративных бизнес-приложений была парализована: клиентские запросы не обрабатывались, ежедневный отчет в ЦБ отправить не удалось. Огонь распространился на соседние помещения с серверами, на которых хранились резервные копии информационной системы с данными за последний месяц. Восстановить часть этих данных удалось только через неделю. Пожарные, справившиеся в конце концов с огнем, оставили после себя офис в таком состоянии, что руководство банка вынуждено было объявить сотрудникам двухдневный выходной.
В один крупный издательский дом нагрянули представители СЭС и пожарной части и под надуманными предлогами закрыли и опечатали офис. Компания на некоторое время лишилась возможности готовить и выпускать номера своих изданий.
Работа одного крупного российского банка оказалась парализованной в течение дня из-за того, что его базы данных были поражены интернет-червем, использующим бреши в защите программного обеспечения Microsoft SQL Server. В другом крупном российском банке обиженный на руководство системный администратор перед увольнением уничтожил все данные в операционной среде, в результате чего банк не работал несколько суток, не имея возможности закрыть операционный день.
Во всех этих случаях можно было сохранить непрерывность бизнес-процессов, если бы компании заранее обеспечили возможность резервного копирования важной информации, позаботившись при этом, чтобы сервер с back up находился как можно дальше от основного, предусмотрели вариант с резервным офисом или возможностью работы сотрудников из дома, проверили защиту своей информационной системы на предмет вирусных и хакерских атак. Еще очень полезно иметь два независимых подвода электроэнергии и запасной дизель-генератор, поскольку длительные сбои в подаче электричества -- явление в России отнюдь не редкое. Вообще, как говорит вице-президент «Вымпелкома» Владимир Филиппов (см. интервью с ним на стр. ??), обеспечение непрерывности бизнеса -- задача комплексная, включающая в себя и организационные, и методические, и технические мероприятия. Элементы концепции business continuity, настаивает Пол Хони, необходимо внедрять в корпоративную культуру, в сознание сотрудников, особенно руководящих. Но поскольку речь идет об избыточности, призванной компенсировать риски для бизнеса, управление его непрерывностью превращается в искусство балансировки, причем баланс приходится искать на длительной перспективе. Ведь плата за страховку не может быть сравнимой со стоимостью самого бизнеса. Конечно, бизнес сам по себе предприятие рискованное, и каждый игрок на рынке самостоятельно определяет степень допустимого риска. Нужно только делать это на основе полной информации о потенциальных проблемах и тех возможностях, которые предоставляют современные технологии не только для снижения рисков, но и для снижения затрат на обеспечение разумной избыточности.
«Сначала говорят деньги»
Задача по обеспечению непрерывности бизнеса -- это поиск баланса множества факторов. О том, из чего слагается это искусство в отношении корпоративных центров обработки данных, рассказывает директор департамента управления проектами APC-MGE в России и СНГ Олег Письменский.
Центр обработки данных как инструмент обеспечения непрерывности бизнеса. Какими характеристиками он должен обладать?
Прежде всего отмечу, что APC-MGE специализируется на инженерной инфраструктуре для центров обработки данных, то есть мы действуем в самом основании пирамиды business continuity, там, где находятся базовые элементы жизнеобеспечения бизнеса. Существует множество разных определений этой концепции, я бы дал такое: возможность предоставления необходимых сервисов в четко обозначенный момент времени. Если такая возможность обеспечивается, значит, непрерывность бизнеса присутствует, если нет -- надо искать причины в основании пирамиды. Ничто не может функционировать безупречно и вечно, поэтому непрерывность бизнеса должна быть спланирована. Планируется допустимое время простоя, в течение которого сервисы отсутствуют по вине инфраструктуры. То есть нужно говорить об определенном уровне эксплуатационной готовности оборудования. Он определяется коэффициентом готовности или доступности оборудования (сервиса), который можно выразить в процентах, а еще лучше во времени. Если мы говорим об уровне доступности, допустим, 99,94 («три девятки»), это значит, что в течение года оборудование не работает примерно полдня. Уровень можно наращивать -- четыре, пять девяток, но вместе с эксплуатационными показателями будут расти инвестиционные. За все надо платить -- чудес не бывает. Физическая инфраструктура data-центра -- это своего рода страховка, которую бизнес выплачивает инженерам, чтобы не потерять свою информацию.
Но на страховке можно и разориться. Как определить уровень разумной избыточности?
Четких критериев разумной избыточности нет. Но центры обработки данных появились не вчера. APC-MGE входит в различные ассоциации проектировщиков и эксплуатантов ЦОД. В частности, мы сотрудничаем с Uptime Institute, который ведет наблюдения за работой data-центров с 1965 года. Там накоплена статистика по отказам, их причинам, инвестициям, и сейчас мы можем эмпирически подходить к оценке стоимости эксплуатации одного квадратного метра или одной аппаратурной стойки на протяжении всего жизненного цикла ЦОД. Совокупность эксплуатационных, финансовых, временных показателей, в зависимости от уровня доступности ИТ-сервиса может дать бизнесу понимание того, что ему нужно. Если я плачу $150 тыс. за «пять девяток» доступности серверной стойки, когда ИТ-сервис будет отсутствовать в год не более нескольких минут, я должен понимать, стоит ли игра свеч и так ли это критично для меня. Каждая компания сама определяет, исходя из критериев своего бизнеса, уровень разумной избыточности.
Строить собственный ЦОД или аутсорсить. Кому что показано?
Опять же однозначных рекомендаций в этом вопросе нет. Строительство собственного ЦОД -- это серьезные инвестиции, которые необходимо защитить перед руководством, плюс эксплуатационные расходы. Сегодня стоимость владения одной серверной стойкой в центре обработки данных находится в пределах $80–150 тыс. на протяжении всего жизненного цикла, причем на долю электроэнергии приходится около 20% затрат. Расходы на инженерную инфраструктуру составляют 3–5% от стоимости ИТ-оборудования. К примеру, увеличение нагрузки источника бесперебойного питания в два-три раза означает такое же -- в два-три раза -- увеличение инфраструктурных расходов в пределах того же пространства. Расходы на электроэнергию и кондиционирование для серверной стойки мощностью 15 кВт десятикратно превышают аналогичные показатели для стойки в 1,5 кВт. В перспективе инфраструктурные расходы могут составить 30–50% от всех затрат на ИТ. Если ЦОД аутсорсить, то снимается головная боль по многим вопросам: по сути, деньги платятся за SLA -- оговоренное качество услуг и уровень их доступности. Но при этом повышаются риски.
Я бы разделил все компании на две категории: те, для которых ИТ служат основным средством производства, и те, где они выполняют поддерживающую функцию. Если стоимость информации и риски ее потери соизмеримы с позицией компании на рынке, тогда да, нужен свой ЦОД. Да, это серьезные инвестиционно-эксплуатационные расходы, но риски потери бизнеса перевешивают. Если ИТ не столь критичны для бизнеса, нужно искать баланс. Ведь даже эксплуатационные расходы по ЦОД могут оказаться намного выше теоретической выгоды от владения собственным центром. Не говоря уже об инвестициях в его создание. Нужно построить помещение, отвечающее определенным требованиям, набрать и обучить команду, найти и привлечь тех, кто разработает правильную архитектуру центра и будет грамотно управлять проектом. Получается, что компания тратит ресурсы не на стратегию развития своего бизнеса, а на строительство некой комнаты. Но это еще не все. Если ЦОД отвечает текущим потребностям бизнеса, сколько будет стоить его модернизация под потребности завтрашние? Можно ли спланировать весь жизненный цикл ЦОД? А защищать на совете директоров нужно именно такое предложение, поскольку не факт, что когда-нибудь еще на это выделят деньги. И на все эти вопросы CIO обязан дать своим директорам ответ.
В варианте с аутсорсингом data-центра возникают свои вопросы. Какой уровень доступности гарантируют провайдеры, и сопоставимы ли прописанные в договоре штрафы с теми потерями, которые компания все-таки может понести по вине поставщика услуг. По моему опыту, на бумаге в аутсорсинговых data-центрах все выглядит гораздо лучше, нежели оказывается на деле. Это касается общемировой практики, Россия в этом отношении не лучше и не хуже. Рынок у нас, конечно, еще не столь зрелый, как в Европе, не хватает культуры предоставления подобных услуг, но подходы, люди и законы физики -- те же. В некоторых странах, например, операторам связи и финансовым организациям аутсорсить ЦОД не разрешается законодательно. Неприемлем аутсорсинг и для предприятий с непрерывным производством, например металлургических, хотя ИТ для них отнюдь не главная функция. Поэтому критерии выбора -- аутсорсить или нет -- весьма разноплановые. Сначала говорят деньги, потом появляются нюансы, связанные с конфиденциальностью, безопасностью и прочими моментами.
Как сэкономить на владении
Для оценки полной стоимости владения (ПСВ) в отношении инженерной инфраструктуры data-центров компания APC использует собственную методику. Знание природы источников затрат, образующих ПСВ, дает компаниям возможность анализировать ROI и управлять расходами.
APC предлагает считать удельную ПСВ не на квадратный метр площади или киловатт мощности компьютерного центра, а в более универсальных «стоечных единицах» -- в расчете на одну серверную стойку. Разработанный компанией программный калькулятор, настроенный на усредненные значения затрат на приобретение, установку, наладку и эксплуатацию оборудования, дает следующие результаты. При этом учитывается, что инфраструктура типичного компьютерного центра используется не более чем на 30%, но работа ЦОД обычно начинается с коэффициента использования 10%. Для типичного центра с максимальной мощностью 100 кВт, сроком службы 10 лет, средней мощностью стойки 1500 Вт и двойным резервированием ПСВ в расчете на стойку в течение всего срока службы составляет около $120 тыс. Зачастую эта сумма сравнима со стоимостью всего ИТ-оборудования, побывавшего в стойке за время ее эксплуатации. Соотношение капитальных и эксплуатационных затрат -- примерно 50 на 50.
Расчеты показывают, что ПСВ сокращается на 60%, если строить безызбыточную инфраструктуру ЦОД. Но CIO, защищая перед руководством проект по построению ЦОД, закладывает многократный запас по отношению к текущим потребностям, чтобы хватило на ближайшие годы. Если бы технологии позволяли масштабировать инженерную инфраструктуру data-центра по мере появления новых потребностей в вычислительной мощности, он бы умерил свои первоначальные запросы. Однако идеально масштабируемая архитектура ЦОД, обеспечивающая 60% экономии ПСВ на безызбыточности, пока недостижима. А вот реальная масштабируемость за счет использования некоторых модульных элементов (ИБП, блоков распределения питания, кондиционеров) может обеспечить до 30% экономии в ПСВ. При этом большая часть экономится в первый год эксплуатации. В традиционной же архитектуре ЦОД в первый год обычно вкладывается более 90% капитала, хотя коэффициент использования инфраструктуры в этот период минимален. С точки зрения ROI оправдание такому вложению средств найти трудно.