В июне 2012 года в компании «М.Видео» был завершен проект по обеспечению непрерывности бизнеса. Очень важным его этапом стало размещение резервных мощностей во внешнем центре обработки данных одного из подрядчиков проекта — компании КРОК. О том, почему было выбрано именно такое решение, мы и беседовали с операционным директором по ИТ Игорем Веселовым.

Intelligent Enterprise: Известно, что у вас в компании установлена ERP-система разработки SAP, и это одно из крупнейших внедрений в России. Какие еще информационные системы используются в компании? Есть ли среди них высококритичные, когда время простоя меньше рабочего дня неприемлемо?

Игорь Веселов: Несмотря на то что SAP является основной информационной системой нашей компании и часть её модулей действительно бизнес-критичны, у нас используются и иные бизнес-критичные системы. Например, система лояльности Siebel и торговая ИС собственной разработки, которую мы долго уже развиваем.

В настоящее время идет процесс ее замены, но пока мы продолжаем активно эксплуатировать её. Система обслуживает наши торговые процессы в магазинах и в главном офисе.

Система SAP обеспечивает управление цепочками поставок и логистикой. Сюда входит работа со складскими комплексами и центрами дистрибуции — одним словом, всё, что относится к движению товаров от складов в магазины. Другие модули SAP используются для подготовки финансовой, управленческой и прочей отчетности, а также для решения задач бизнес-аналитики. Используем мы и HR-модуль для кадрового учета. Однако данные задачи хоть и важны, но не являются в полном смысле этого слова бизнес-критичными.

У этих модулей показатели RPO/RTO, которые используются для расчета SLA в проектах, связанных с обеспечением непре­рывности бизнеса, измеряются часами. И именно они использовались при создании резервного ЦОДа. Максимальное время простоя для таких систем было определено в четыре часа, время переноса сервисов на резервные мощности не должно его превышать. Однако для всех высококритичных систем, а их около десятка, учитывая процессы, связанные с изменениями ИТ-ландшафта в компании, процесс миграции будет проходить в реальном времени без заметных задержек. С таковой целью пришлось организовать репликацию на резервные мощности не только данных бизнес-приложений, но и конфигурационной информации.

Какие средства обеспечения непрерывности бизнеса применялись у вас до начала проекта? Чем они вас не устраивали? Было ли что-то такое, что стало последней каплей, после чего и начались работы?

Задача обеспечения непрерывности бизнеса у нас стояла всегда. Но на разных этапах развития мы решали ее по-разному, различными способами. Скажем, несмотря на гетерогенность на­шего ИТ-ландшафта, наши системы являются как поставщиками, так и потребителями данных друг друга. В итоге данные в различных системах дублируются. И мы этим пользовались.

Так, система SAP у нас была вынесена на внешнюю площадку. Этот ЦОД был соединен канала­­ми связи с нашим основным ЦОДом и с прочими системами и взаимодействовал с ними. И такое решение, хотя процесс восстановления данных не был гарантирован, а время, затрачиваемое на него, являлось непредсказуемым, позволяло восстановить работоспособность систем голов­ного офиса из резервных копий или данных, которые хранились в системе SAP. Или наоборот, если стояла обратная задача. Кроме того, у нас уже давно работает централизованная система резервного копирования, поэтому процесс получения резервных копий отлажен и производится с заданной регулярностью. А лен­ты с резервными копиями, как того требуют стандарты, переносятся в резервное хранилище.

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

Так что какие-то меры мы принимали. Однако нельзя было сказать, чтобы существовала полноценная система обеспечения непрерывности бизнеса. Да, оно обеспечивалось, но с большими трудозатратами со стороны администраторов и за длительное время, которое, несмотря на всю критичность систем, могло измеряться в лучшем случае сутками, а то и неделями.

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

Как вы пришли к тому, чтобы использовать аутсорсинговый ЦОД? Это временное решение или оно всерьез и надолго?

Мы располагаемся в арендованном здании, что создает из­вестные трудности для размещения собственного оборудования. Так что аутсорсинг у нас используется давно, о чём вскользь я уже говорил. Могу сказать, что тем не менее свой собственный ЦОД мы имеем. Однако и это не мешает нам применять аутсорсинг: мы отдали партнерам обслуживание инженерных и климатических систем. За историю моей работы в компании было несколько переездов. Поводы к тому могли быть самые разные. В данном случае основной причиной было развитие компании, выразившееся среди прочего в росте количества торговых точек и персонала. В такой ситуации собственный ЦОД является препятствием, в то время как использование аутсорсинговой площадки позволяет начать полноценную работу практически сразу после переезда сотрудников в новое помещение. Причем неважно, о каком ЦОДе идет речь — основном или резервном. Просто при переезде нагрузка переносится на резервный ЦОД, и это продолжается до того момента, пока не закончатся работы по переносу основных мощностей на новое место.

Когда зашла речь о создании резервного ЦОДа, мы рассматривали возможность строительства собственной площадки, учитывая, что у нас есть свои площади. Однако расчеты с использованием различных моделей, в том числе и аутсорсинговых, включая обычный хостинг в России и за рубежом, показали, что модель полноценного частного облака для нас наиболее оптимальна. При этом мы считали далеко и глубоко как по модели совокупной стоимости владения, так и по скорости возврата инвестиций. И эти расчеты также показали преимущество аутсорсинга. Хотя бы потому, что отсутствовали затраты на строительство и на выделение энергетических мощностей. Особенно в Москве, где остро ощущается дефицит и площадей под строительство, и мощностей, где высока стоимость самих работ и недвижимости. Строительство большого ЦОДа в Москве просто нереально. Выносить же его в область или в другие регионы также по многим причинам нецелесообразно.

Всего в нашем конкурсе участ­вовало шесть компаний — пять российских и одна иностранная. В их числе были Tieto, «АйТеко», «Инлайн Груп». В итоге нам удалось не только добиться значительных скидок, но и понять, как различные решения работают на развитых рынках, где давно предлагаются те же облачные услуги, к которым мы давно присматривались. Остановились же мы на предложении КРОК.

Выбранная нами модель подразумевает работу необходимых ресурсов с заданными характеристиками производительности и отказоустойчивости. Я даже какое-то время заблуждался, что эта масштабируемость будет безграничной и простой в использовании, где всё, что я хочу, будет получено по хлопку в ладоши. Но, к сожалению, реальность оказалась куда прозаичней. Хотя бы потому, что любая более-менее масштабная модернизация в основном ЦОДе означает проведение работ и на резервной площадке. Ведь никто, по крайней мере в России, не держит мощности в состоянии простоя или сна. Следовательно, потребуется время на то, чтобы масштабировать оборудование на той стороне, у провайдера. Другое дело, что эти инвестиции будут уже не нашими, но тем не менее нам приходится синхронизировать всю свою проектную деятельность с поставщиком услуги.

Как разрабатывался план Disaster Recovery? Насколько сложной и трудоемкой была эта задача?

Наиболее сложным и важным моментом в выработке DRP-плана стал выбор критичных бизнес-систем и инфраструктурных комплексов, которые обеспечивают их функционирование, определение показателей RPO/RTO и согласование полученных показателей с бизнес-заказчиками. Именно в решении этих вопросов нам и помогли внешние консультанты. Здесь мы привлекли компанию, которая не участвовала в дальнейших работах по проекту.

Для этого были проведены аудит нашей инфраструктуры и определенная работа с бизнес-заказчиками. «На выходе» мы получили практически готовое техническое задание для данного проекта. То есть мы получили оценку критичности тех или иных систем, величину ущерба, который возникнет в случае их простоя, и некие ориентиры по возможному времени восстановления. А вот дальнейшее создание DRP-плана — это уже, как мне кажется, не слишком сложная процедура. Хотя у нас все осложнялось тем, что в работы по развитию ряда систем включены другие партнеры. Например, компания «Инфосистемы Джет», которая взяла на аутсорсинг поддержку ряда наших бизнес-приложений, включая Siebel и SAP. И без их участия вести работы по созданию резервной площадки невозможно.

Но эта сложность обернулась позитивными факторами. Партнеры были заинтересованы в том, чтобы работы были проведены правильно, чтобы заранее была определена зона ответственности, контроль качества. Поэтому они активно участвовали в общей работе по выработке DRP-плана, что сделало его не мертвым документом, который никто никогда не будет смотреть, а реально работающим. В итоге документ, который разработали инженеры из КРОКа, прошел дополнительную экспертизу, причем фактически со стороны их конкурентов. Таким образом, не прошли не то что неправильные или плохо понятые термины, но буквально лишние запятые. И как результат приемосдаточные испытания, в ходе которых был полностью отключен основной ЦОД и вся нагрузка перемещена на резервный, прошли успешно.

Подготовка персонала, тренинги… Насколько широко будут проводиться подобного рода мероприятия?

Все проходит по тому самому DRP-плану. Он реально действует, а не положен под сукно, как это нередко бывает. Каждый месяц у нас проводятся семинары, посвященные работам по перемещению нагрузки в резерв­ный ЦОД. В них участвуют все специалисты, вовлеченные в проект, в том числе сотрудники наших партнеров. Тут и теоретические учения по действиям персонала дежурных смен при выходе из строя тех или иных систем. И работы в рамках процессов, связанных с управлением изменениями. Это важно, потому что обе площадки так тесно между собой увязаны, что любые неосторожные или плохо обдуманные действия на внешней стороне могут привести к проблемам у нас. Ну а полноценные учения в обстановке, приближенной к реальной, мы планируем проводить раз в год. Чаще в этом нет необходимости.

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

Тренинги проводятся и для корректировки самого DRP-плана. Этот процесс является естественным для рабочего документа. Он касается только нас и не зависит от Business Continuity Plan, работа над которым пока только ведется. Так что бизнес-пользователи пока не задействованы. Это дело будущего, надеюсь, скорого.