В последнее время проектами, связанными с внедрением различных облачных решений, удивить трудно. Их довольно много, и они, что называется, на слуху. Это касается предприятий разного уровня бизнеса — от малого до крупного. Однако такой широко распространенный за рубежом сервис, как резервное копирование на облачных ресурсах, у нас распространен не слишком широко. Преимущества, а также возможные слабые места этого подхода к резервному копированию и стали предметом нашего разговора с начальником ИТ-управления страховой компании «Гефест» Георгием Власкиным.
Intelligent Enterprise: Как обстояло дело, пока вы не начали использовать внешние ресурсы для резервного копирования данных? Что способствовало тому, что вы решились на это?
Георгий Власкин: Использование внешних ресурсов не означает, что мы отказались от резервного копирования на локальных ресурсах. Оно как производилось, так и производится. Никаких принципиальных изменений в сам процесс при этом не вносилось: мы продолжаем ежедневно резервировать информацию с файловых серверов и из баз данных, сообщения электронной почты, данные наших порталов, приложений для групповой работы. Одним словом, мы резервируем всю информацию в полном объеме. Исключение составляют лишь данные с рабочих станций пользователей, но по нашим стандартам хранение рабочей информации на локальных дисках ПК не допускается.
Использование внешних ресурсов стало лишь дополнением. Это обусловлено стандартами в области обеспечения непрерывности бизнеса и восстановления после катастроф, или, по-другому, disaster recovery. А требование их таково, что данные должны резервироваться и на удаленной площадке, причем удаление от основного офиса должно быть значительным: 12—15 километров.
Для обеспечения этого процесса надо было или искать какой-то центр обработки данных и поднимать там всю инфраструктуру, арендовать каналы связи, или воспользоваться готовой услугой «из коробки». Мы сочли второй вариант более удобным и выбрали решение компании КРОК. Для этого было арендовано дисковое пространство и предоставлен набор необходимого ПО. Потребовалась некоторая настройка и отладка процесса. Довольно значительное время ушло на самое первое резервное копирование. Но затем, благодаря технологии дедупликации, резервировались только те данные, которые изменились, и последующие процедуры стали занимать совсем небольшое время. Использовать каналы связи повышенной пропускной способности нам не пришлось. Так что все пошло именно так, как мы и планировали.
Какими количественными параметрами (надежность, скорость резервного копирования, оперативность последующего доступа, характеристики масштабируемости сервисов, возможность гибкого изменения расписания и т. д.) описывается процедура Buckup as a Sercice? Выдерживаются ли эти параметры на практике? Удовлетворяет ли качество сервиса сегодня в целом?
У нас нет каких-либо особенных количественных требований. Благодаря использованию технологий дедупликации, как я уже говорил, объем данных относительно невелик. К тому же наша компания относится к среднему бизнесу: штат сотрудников около четырёхсот человек. Да, первое копирование было длительным. Тут даже пришлось проводить процедуру поэтапно, система за системой. Но сейчас речь идет лишь о нескольких десятках минут в течение суток для того, чтобы сохранить на удаленном ЦОДе результаты суточной работы. Резервное копирование занимает примерно столько же. Оно, правда, производится несколько чаще, но и времени на него уходит меньше. При этом мы используем обычный канал связи 100 Мбит/с с использованием технологии виртуальной частной сети. Заказывать канал с гарантированной пропускной способностью мы не стали. Того, что уже есть, оказалось достаточно.
А какие параметры использовались для выработки соглашений об уровне сервиса (SLA)?
Никаких серьезных требований к SLA мы не выдвигали. Этот проект рассматривался как пилотный. В договоре прописаны лишь ключевые параметры, связанные с критическими ошибками, недоступностью системы и т. п.
Как обстоит дело с обеспечением сохранности и конфиденциальности данных?
Соглашение о конфиденциальности, которое было подписано до передачи данных в компанию КРОК, регламентирует эти вопросы. К его выработке мы подошли основательно, поскольку в нашем бизнесе вопрос доверия стоит очень серьезно. Причем только соглашением мы не ограничились. Нам была предоставлена возможность посетить ЦОД КРОКа, то самое его место, где должны были храниться наши данные. И то, что КРОК на это пошел, мы сочли как его конкурентное преимущество. Услуга внешнего ЦОДа сейчас очень популярна, ее оказывают многие компании, но далеко не все из них готовы пустить заказчиков на свою территорию. Особенно когда речь идет о месте хранения данных. Ведь только таким образом можно убедиться, насколько надежно работают системы безопасности — от пропускной до противопожарной.
Стоит ли рассматривать услугу резервного копирования как пилотный проект для более масштабного использования облачных решений и аутсорсинга?
Пока все ограничивается экспериментами. И среди моих коллег из других компаний тоже никто ещё не бросился с головой в облачные технологии. Но иногда это бывает целесообразным, хорошим примером чему является наш опыт резервного копирования. Организация собственной инфраструктуры заняла бы намного больше времени и обошлась бы существенно дороже. А тут получаешь высококачественную услугу с хорошим уровнем поддержки и не заботишься ни о каналах связи, ни о физической безопасности, включая защиту от взрывов, пожаров и прочие форс-мажорные ситуации. Все это — головная боль для подрядчика. Кроме того, переход в облако для нас, да и для других страховых компаний, существенно осложняет то обстоятельство, что ПО, используемое для автоматизации бизнес-процессов, очень плохо приспособлено для работы в облаках. Нет и готовых SaaS-решений для страхового учета. Что касается других систем, то мы будем смотреть, что предлагает рынок. Ну и оценивать целесообразность такого перехода.
С другой стороны, поддерживать работоспособность систем автоматизации для небольших страховых компаний становится довольно сложной задачей. Это связано с тем, что требования к таким системам год за годом серьезно возрастают. Равно как и требования к отчетности, которую собирают регуляторы. Меняются и требования к процедуре передачи данных в надзорные органы. При этом все больше отчетности необходимо представлять в режиме онлайн. Это, в частности, относится к отчетности по страхованию опасных объектов, которую необходимо передавать в автоматизированную информационную систему Национального союза страховщиков ответственности. А с нынешнего года нужно производить онлайн-обмен информацией по КБМ ОСАГО и учету документов о техническом осмотре транспортных средств с автоматизированной учетной системой Российского союза автостраховщиков. Все это требует большого объема разработок. Так что если будет предложен облачный сервис, который оперативно подстраивается под изменения в законодательстве и требования регуляторов, то он вполне может оказаться востребованным. Тогда переход на подход «всё как сервис» может быть для нас оправданным.
К чему должны быть готовы те, кто решит пойти по вашему пути?
Прежде всего нужно все тщательно просчитать. Нужно знать, каков у вас прирост данных. А дальше исходить из желаемой частоты резервного копирования и самой потребности к восстановлению. Стоит отметить, что резервное копирование на удаленной площадке не является единственно возможным вариантом. Хотя для построения катастрофоустойчивого решения или когда остро стоит проблема копирования данных с рабочих станций, оно очень удобно. Особенно если речь идет о мобильном персонале, который работает без постоянного подключения к корпоративной сети, даже удаленного. Это могут быть, например, страховые агенты, торговые представители. Для таких сотрудников важно сохранить данные с их мобильных ПК и других устройств.
Но в любом случае нельзя необдуманно бросаться в омут с головой. Нужно осторожно смотреть, пробовать и обязательно считать.
Сейчас все больше разработчиков ПО интегрирует свои продукты с различными облачными сервисами. Насколько это перспективно? Снимается ли при этом необходимость использования различного рода решений для резервного копирования?
Использование таких сервисов не решает задачу сохранения информации. Если речь идет о работе с комплектом офисных приложений, например Microsoft Office 2013, то таким образом решается лишь задача сохранения документов, причем только тех, в которые вносились изменения. Но это не относится к сохранению, например, фотографий. А есть еще и база почтовых сообщений, и многие настройки операционной системы и используемого ПО, в том числе критичные. Их потеря тоже может принести ущерб, причем не меньший, чем утрата документов. Тем более, что публичные ресурсы предоставляют относительно небольшой объем. Насколько мне известно, не большее 30 Гбайт, если речь идет о Microsoft SkyDrive, а обычно даже меньше. Кроме того, публичными сервисами не поддерживается та же технология дедупликации. А ее использование реально минимизирует объемы передаваемых данных.
Если речь идет об офисных документах, то это десятки килобайт в день, в итоге данная процедура займет секунды, даже если в распоряжении оказался низкоскоростной канал доступа в Интернет. В случае с фотографиями все несколько сложнее, но и тут трудность может возникнуть лишь при очень большом отдалении от цивилизации. В итоге восстановление информации в случае утери ноутбука или иного устройства займет считанные часы с учетом времени, необходимого на установку операционной системы и базового набора ПО. При использовании публичных сервисов на такое рассчитывать будет сложно. Это и менее быстро, и менее удобно, да и восстановление в полном объеме вряд ли возможно.
