Intelligent Enterprise: Какие параметры ИТ-инфраструктуры планировалось улучшить в ходе проекта?
Алексей Ежков: Главной целью было уменьшение рисков потерь вследствие остановки ключевых бизнес-процессов компании, причиной которой могли бы стать отказы ИТ-инфраструктуры. До начала проекта весь её комплекс был размещен на одной площадке. Таким образом этот ЦОД потенциально становился единой точкой отказа, когда любой сбой или авария приводят к остановке бизнеса. А если простой будет длительным, то последствия окажутся фатальными.
В итоге был разработан план по обеспечению непрерывности бизнес-процессов. В числе многих других мер он предусматривал также создание резервного центра обработки данных, куда могли бы мигрировать приложения и данные в случае аварии в основном ЦОДе.
Надо отметить, что мы арендуем стойкоместа для размещения нашего ЦОДа у внешнего оператора. И резервы по расширению мощностей там со временем все более и более сужались. Принято говорить, что дурной пример заразителен, но положительный опыт также перенимается, и услуга по аренде мощностей или стойкомест набирает популярность. В таких условиях наличие второй площадки давало бы нам резервы для масштабирования нашей ИТ-инфраструктуры, тем самым поддерживая рост компании.
Как был организован процесс репликации данных?
Синхронизация данных у нас проводится в «теплом» режиме. Строить полноценный распределенный кластер мы не стали, так как затраты в этом случае не оправдывают достигаемого эффекта. Мы сознательно пошли на то, что данные переместятся с неким опозданием и, возможно, какие-то операции не будут завершены. Кроме того, расстояние между Москвой и Санкт-Петербургом, где расположены наши центры обработки данных, слишком велико для того, чтобы организовать кластерное решение. Рекомендуемое расстояние не должно превышать пятидесяти километров, а в нашем случае оно на порядок больше. Законы физики, увы, вещь объективная, сетевые задержки неизбежны и составляют 8–12 мс. Но мы думаем над тем, чтобы в ближайшей перспективе начать строительство еще одной площадки и добиться еще более высоких показателей по скорости восстановления системы.
Естественно, на новую площадку переносились все наши продуктивные системы. Весь этот процесс шел без остановки работы, в режиме active stand-by.
Менялись ли соглашения об уровне сервиса (SLA)?
Принципиальным образом нет. Мы добавили только параметры восстановления работы после катастрофы, которое занимает разное время для разных сервисов, от нескольких минут для самых критичных до нескольких часов для менее значимых для бизнеса. Раньше процесс восстановления мог бы длиться многие сутки, а то и недели. Но на операционную деятельность построение резервной площадки никакого влияния не оказало. А для многих вообще ничего не изменилось.
Наиболее сложной задачей было определение приоритетности процессов, подлежащих восстановлению. В любой компании есть процессы, простой которых в течение каких-то минут приводит к огромным убыткам, а есть и такие, которые могут остановиться даже на несколько дней и это не приведет к серьезным потерям. Всю эту работу мы проводили совместно с бизнес-заказчиками. Так, например, процессы, обслуживающие продажи, нужно восстанавливать с максимальным приоритетом в течение считанных часов. Восстановление же других бизнес-процессов в полном объеме может занимать до нескольких дней, а то и недель, особенно в тех случаях, когда необходимо приобретать дополнительное оборудование, что в нынешних условиях требует довольно длительного времени.
Был ли у вас до начала работ по этому проекту план восстановления после аварии (DRP)? Как он формируется?
Нет, не было. Создание DRP-плана — довольно сложный и длительный процесс. Пока у нас идёт его формирование, хотя мы уже продвинулись здесь довольно далеко.
Для этой цели необходимо собрать пожелания бизнеса и определить, какие бизнес-процессы следует восстанавливать в первую очередь и в какие сроки. Естественно, бизнес-процессы, связанные с продажами, будут иметь наивысший приоритет, а, например, бэк-офис окажется не самым первым в очереди.
На следующем этапе нужно разработать комплекс мер, необходимых для того, чтобы восстановить работоспособность каждого ИТ-сервиса в заданные бизнес-заказчиками сроки. Для этого необходимо выделить соответствующие ИТ-ресурсы: дисковое пространство, серверные мощности и т. д.
Кроме того, следует определить вероятность аварий и катастроф, чреватых потерей расположенных в ЦОДе сервисов. Имеются методические материалы, которые позволяют оценивать влияние таких факторов, как сезонные эпидемии (например, гриппа и ОРВИ в холодное время года), всяческого рода опасные природные явления (землетрясения, наводнения, ураганы, снегопады и пр.), массовые уличные акции, перебои с электропитанием, пожары и многое другое. Естественно, какими-то рисками мы пренебрегли. Так, в Москве и Санкт-Петербурге в принципе невозможны разрушительное землетрясение, тайфун или тропический шторм. Однако есть вполне вероятные события, к которым нужно быть готовым. Все мы помним отключение энергии 2005 года, когда в половине Москвы отсутствовало электричество, или последствия ледяного дождя в 2011-м в Москве и Московской области. Довольно часто имеют место проблемы со связью.
Исходя из сценария аварии и разрабатывается DRP-план. Это меры, которые необходимо принимать в каждом конкретном случае для тех или иных групп ресурсов — Windows- и Linux-серверов, СХД, сетевого оборудования. Сейчас мы находимся в стадии разработки этих мер. Они скорее организационные, нежели технические. Грубо говоря, надо распределить обязанности, кто куда бежит и кто что берет. Все эти инструкции и регламенты также требуют тестирования и совершенствования.
Но разработать DRP-план мало. Нужны постоянные тренировки, чтобы в случае аварии минимизировать ущерб для бизнеса. Причем сценарии этих тренировок должны быть максимально близкими к тем инцидентам, которые могут возникнуть в реальности.
За последние полгода у нас уже возникали аварийные ситуации. Проблемы с каналами связи бывают регулярно, и мы уже на практике успели оценить, как у нас улучшились параметры отказоустойчивости. Так что мероприятия по выработке DRP уже показали свою необходимость, хотя есть еще вещи, над которыми нужно работать.
Можете поделиться опытом в обеспечении сохранности данных в условиях аутсорсинга?
Тут, пожалуй, главное — правильный выбор партнера. Мы для себя выбрали крупных операторов, которые имеют собственные коммуникации как внутри Москвы и Санкт-Петербурга, так и между этими городами. Они полностью обеспечивают связь наших магазинов и складов с ЦОДом. Хотя следить за тем, чтобы каналы связи были действительно зарезервированы, все равно надо. Увы, «эффект пьяного экскаваторщика» действительно есть, и неприятности, связанные с халатностью при ведении земляных работ, возникают довольно часто. Необходимо также шифровать сетевой трафик, тем более что это можно сделать на уровне оператора.
Таких операторов совсем немного, и они имеют хорошую репутацию. Скажем, наша московская площадка считается одной из лучших в Москве. LinxDatacenter, у которого мы арендуем ЦОД в Санкт-Петербурге, тоже солидный игрок. Его ЦОД полностью соответствует уровню TIER III, а такие наперечет. Кроме того, данный оператор ЦОДов имеет сертификат ISO 27001, а этот стандарт регламентирует в том числе и процессы, связанные с поддержанием непрерывности работы.
Насколько сложно «продать» руководству идею создания резервного ЦОДа? Что для этого нужно?
Да, создание резервной площадки — дело весьма недешевое. Но нам повезло. Наше руководство находится на очень высоком уровне зрелости и хорошо понимает, на чем держится бизнес. Наши покупатели знают, что у нас нет традиционных розничных магазинов с витриной, где выставлены товары. Вся продажа производится через онлайн-платформу. И если она не работает, то ничего продать невозможно. И, естественно, в голове сразу возникает вопрос, как сделать так, чтобы всё функционировало надежно. Чтобы сбои возникали как можно реже, а если бы и происходили, то работоспособность сервисов, по крайней мере наиболее критичных, восстанавливалась в кратчайшие сроки. Кроме того, резервная площадка — залог нашего развития. А планы по развитию бизнеса у «Юлмарта» есть, и они весьма амбициозны. У нас расширяется как ассортимент, так и география присутствия. Терять темпы развития в общем-то из-за досадных мелочей не хочется. И бизнес это понял сам, практически без нашей помощи.
В дальнейшем динамика развития бизнеса естественным образом будет увеличивать стоимость минуты простоя и требовать еще более эффективной реакции на нарушения непрерывности и влиять на параметры восстановления.
А можно ли в какой-то понятной форме рассчитать необходимость такого проекта?
Да, и это не так сложно. Любой, кто работает в области розничной торговли, знаком с таким понятием, как высокий сезон. В разных сегментах он наступает в разное время, таких сезонов может быть и несколько в году. Например, у нас их как минимум два: в конце года (ноябрь — декабрь) и, в меньшей степени, перед началом нового учебного года. В это время стоимость простоя наиболее высока, и на данные периоды стараются свести к минимуму всякого рода технологические окна. В итоге наш проект окупался бы в течение буквально нескольких часов, «спасенных» благодаря наличию резервной площадки.
Более того, мы рассматривали несколько сценариев. Те параметры восстановления после сбоев, на которые мы вышли, были оптимальными по соотношению эффекта и затрат, так что они возникли далеко не случайным образом. Более жесткие параметры обошлись бы дороже, а более щадящие для нас дали бы меньшую экономическую отдачу. При этом ситуация меняется, обороты растут, как и цена возможного ущерба. Мы делали свои расчеты год назад, и сейчас всё уже по-другому. Так что перспективы для создания третьей площадки становятся все более близкими.
С Алексеем Ежковым беседовал обозреватель Intelligent Enterprise Яков Шпунт
