Intelligent Enterprise: Какова цена простоя ИТ-систем? И какая величина абсолютно неприемлема для вас?
Александр Талалыкин: Самостоятельно ИТ-департамент не может и не должен определять приемлемость цены простоя систем, это задача исключительно бизнеса. Для «Евросети» цена простоя — упущенные продажи. Наши салоны работают автономно в том смысле, что их функционирование не критически зависит от доступа к центральному ИТ-оборудованию. Соответственно если по какой-то причине нет доступа к серверу, сотрудники торговых точек могут продавать товар, но не имеют возможности оказывать услуги (такие, как активация SIM-карт, платежи, которые принимаются в салонах нашей компании, оформление кредитов и т. д.). Поэтому, еще раз повторю, приемлемую цену простоя ИТ-систем в состоянии рассчитать только бизнес в зависимости от того, какую прибыль приносит та или иная услуга в конкретный сезон, в тот или иной день недели и в определённое время суток.
Что для вас выгоднее: создание собственных резервных мощностей или использование сторонних? Возможно ли сочетание обоих подходов? Что легче «продать» бизнес-заказчику?
Мы исторически идем по пути создания собственных резервных мощностей. Если говорить о том, что легче продать бизнес-заказчику, то в разных компаниях принципы эти работают по-разному и зависят, наверное, от их стратегии. Где-то изо всех сил нужно по максимуму постараться перевести затраты в OPEX-составляющую, поэтому там идут по пути использования сторонних услуг. А где-то, зачастую это розничные предприятия, борьба идет за EBITDA — соответственно в данном случае предпочтительно, чтобы OPEX был минимальным, значит, для такой компании дешевле CAPEX. Конечно, возможно и сочетание обоих подходов. В рамках «Евросети» мы все-таки используем свои мощности, сторонние компании не привлекаем. Мы рассматриваем коммерческие предложения, но если учесть риски, которые несет за собой полный аутсорсинг всего и вся, они для нас неприемлемы. Пока не появилось такое предложение, которое удовлетворило бы нас с точки зрения минимальных рисков и доступного по цене качества.
Что может нанести больший ущерб: деятельность злоумышленников или простой из-за выхода из строя систем ЦОДа?
Нет никакой разницы в том, по какой причине ИТ-сервисы становятся недоступными — будь то действия злоумышленника или лояльного, но неквалифицированного сотрудника, выход ли из строя каких-то систем, внезапный глобальный катаклизм или что-то ещё. Если человек просыпается утром и обнаруживает, что в кране нет воды, его не волнует причина случившегося, ему важен результат, а результат в том, что он не может умыться. Так же и здесь — причина не имеет значения. Тут вероятно всё что угодно — деятельность злоумышленников может заключаться в том, что гвоздем нацарапают на сервере нехорошее слово, и тогда действия собственных сотрудников положат всю компанию раз и навсегда.
Проектирование резервного ЦОДа — насколько это сложная задача в условиях ограниченного бюджета?
У нас резервный ЦОД есть, но о проблемах его проектирования рассуждать сложно: две площадки «Евросети» работают уже много лет, и дать какой-то актуальный ответ на этот вопрос я не могу.
С точки зрения сертификации что выгоднее: строить несколько площадок TIERII или одну TIERIII?
Наш ЦОД стоит на сертифицированных площадках, однако вопрос сертификации не столь важен для нас, поскольку свои серверы мы располагаем на сторонних площадках. Так как мы используем собственное оборудование, размещенное на профессиональной сторонней площадке, у нас нет актуального мнения по данному вопросу.
Пожалуйста, расскажите о формировании Disaster Recovery Plan. Можно ли здесь сразу предусмотреть всё?
Это длительная и трудоемкая задача. Предусмотреть всё, что написано в учебнике, конечно, можно, но на практике это нереально. Например, в далеком 2010 году в Москве выдалось аномально жаркое лето, что создало очередь на установку кондиционеров чуть ли не на пару лет вперед. При этом фреон, которым заправляют кондиционеры, закончился. И вот как-то вечером мне внезапно сообщают, что в нашем ЦОДе произошло ЧП — его затопило. Весь город изнывает от жары, но в одном конкретном районе прошел сильнейший ливень с ураганным ветром, который сорвал многотонную строительную металлическую балку и бросил ее на чиллеры, охлаждающие помещение ЦОДа. Фреон тут же испаряется, во всей Москве его нет, кондиционеры оперативно восстановить невозможно. В каком кошмарном сне могло привидеться, что с соседнего здания на наш ЦОД прилетит многотонная балка? Возможно такое предусмотреть? Это профессиональный ЦОД, претензий к нему нет даже после такого происшествия — случился форс-мажор, за который ответственности не несет никто. Потому-то и существует практика, когда компании строят два ЦОДа — по определенным правилам, на определенном расстоянии друг от друга. И если с одним что-то случится, то в работу автоматически вступает второй. Таким образом, у «Евросети» есть два взаимозаменяемых ЦОДа, данные в которых постоянно синхронизируются, и исчезновение одного не приведёт к приостановке деятельности компании. Это позволяет нам устранить 99,5% возможных рисков.
Как часто надо проводить тренировки персонала по реализации DRP?
Чтобы провести полноценное учение, нужно искусственно создавать риски. У нас такой практики нет. К тому же есть вероятность, что в ходе тренировки функционирующее много лет оборудование перестанет работать. Как правило, такие тренировки проходят на уровне профессиональных ЦОДов — там можно переключать электричество, менять системы охлаждения, проводить пожарные тревоги. Для профессиональных площадок в них есть смысл, для нас — нет. Что будет делать бухгалтерия, если перестанет работать SAP-система? Раскладывать пасьянсы? И в чем тогда смысл учения? Если говорить о тренировке ИТ-департамента, то тут постоянно что-то происходит. Как в фильме «Люди в черном»: на орбите всегда есть арквеллианский крейсер, и те, кто знает про его существование, просто с этим живут. То же самое можно сказать и о работе ИТ-отдела: где-то что-то постоянно будет выходить из строя, как бы хорошо мы ни работали.
с Александром Талалыкиным беседовал ведущий эксперт Intelligent Enterprise Сергей Костяков
