ВИЗИТКА 


Айрат Мустафин,
генеральный директор Liberum Navitas

Перенос данных в облака: 
как сделать и как защититься

Вопрос о том, нужно ли хранить данные в облаках, уже давно обсуждается не на теоретическом, а на прикладном уровне: доверие к облаку у российских предприятий значительно повысилось, необходимость этой работы не вызывает сомнений, а на вопрос «как?» пытаются ответить лучшие российские компании этой сферы – пусть и с разными подходами. Другое дело, что на этом фоне давно назрел вопрос о том, стоит ли переносить в облако не просто голые данные, а бизнес-процессы. Притом, что именно они сегодня определяют, как живет и развивается компания и насколько ее деятельность интегрирована в отечественную экономику.

Для того чтобы понять, что именно движет типичной российской организацией при принятии решения о переводе данных в облака, стоит договориться о терминах. По моему опыту, у клиентов бывает два подхода: спонтанный («взрывной») и сдержанно-взвешенный. Эти термины мы здесь и будем использовать.

В первом случае (спонтанность) на первое место выходят два вопроса: сколько «это» будет стоить и почему поставщики соответствующих решений так редко отвечают на запрос, хотя потенциальный клиент обращался ко многим из них. О цене поговорим позже, а вот такая реакция провайдеров не удивительна, ведь начинать надо не с цены, а с задачи, и решать ее нужно не «абы как», а на уровне сервисов и гарантий, которые поставщик может предоставить бизнесу. Причем не на уровне деклараций и базовой дешевой автоматизации, не учитывающей специфику конкретного бизнеса, а на действительно высоком уровне.

Да, бывает, что с помощью «начального» набора услуг можно решить тактическую задачу клиента, – но всегда на короткий срок и, естественно, лишь частично. На деле такой подход, а, стало быть, и взаимодействие клиента и поставщика, не интересен ни тем, ни другим, а в среднесрочной перспективе даже вреден: решение потребуется переделать, а средств придется потратить значительно больше. Отрадно, тем не менее, что таких «постановщиков» задачи и подобных исполнителей с каждым годом становится всё меньше.

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

• Уровень готовности бизнес-процессов к переводу в облако. Здесь важна формализация: простой перенос всей информации в новую среду не просто невозможен, но и непродуктивен. Необходимо оценить, какие бизнес-процессы на самом деле критичны, как они взаимодействуют с другими процессами, что здесь прописано и задокументировано, а что пока находится лишь в «головах умных людей». Только те процедуры, которые действительно отлажены и автоматизированы, могут и должны размещаться в облаках, и только для них будет полезно большое число специализированных сервисов, которые может предложить провайдер.
• Умение и способность перенести в облако результат, а не процесс как таковой. Дело в том, что ожидание от провайдера чуда, когда на базе предоставленных ему сырых данных он построит бизнес-процесс за клиента – опасное (и типичное) заблуждение. Хороший провайдер обеспечивает надежное, безопасное хранение информации, ее резервирование и контроль доступа к ней. За сам бизнес-процесс отвечает клиент, это поэтому – разные зоны ответственности.
• Готовность «отчуждать» и «доверять» – как внутри компании, так и снаружи. Под словом «отчуждать» я имею в виду «отдавать» информацию партнерам, делегировать принятие решений и ответственность. Под «доверять» – полагаться на своих сотрудников, поставщиков решений, совместную работу с ними и, наконец, прислушиваться к своей интуиции. Это важно, поскольку страх что-то потерять всегда опасен – он ведет к неизбежной попытке контролировать всё и вся, а это тупик. Ведь делая это, компания связывает по рукам и ногам инициативу и своих сотрудников, и партнера/поставщика, а на выходе – и собственный бизнес.

Теперь посмотрим на то, чем руководствуется поставщик профессиональных решений.

• Первое. Любая комплексная услуга, любой вытекающий из нее сервис – это не «мертвая ворона» и не «железная палка», а гибкий инструмент, который необходим для реализации конкретной цели заказчика. Когда речь идет о такой «сенситивной» субстанции, как данные, это особенно важно. Значит, предлагаемое решение должно быть адаптивным.
• Второе. Поставщик услуг должен правильно реагировать на обоснованное «нет», полученное от клиента, и уметь говорить «нет» самому клиенту, если его желание – это лишь амбиция, а не реальная задача, подкрепленная пониманием бизнеса на уровне ИТ. Только такие самоуважение и смелость исполнителя, на самом деле, ведут к реальному результату. А вот компании с так называемым «человеческим лицом», подстраивающиеся под любые желания клиента, просто не способны помочь ему решить ни тактические, ни стратегические задачи. Все профессиональные игроки ИТ-рынка знают: говоря необоснованное «да» на старте, они получают море проблем в ходе реализации проекта. Поэтому лучше сразу, не сглаживая, обсудить все острые углы, прийти к единому знаменателю и работать вместе как слаженная команда: будет эффективнее и дешевле.
• Третье. «Синхронизация». Генри Форд, заключая первые крупные контракты, говорил о так называемой «вселенской волне», когда на уровне абсолютного профессионализма заказчика и исполнителя возникает так называемый бизнес-слух, означающий умение структур, занятых абсолютно разным бизнесом, разговаривать на одном языке и мгновенно понимать друг друга, в том числе, на уровне «чужих» специализаций. Сегодня понятно, что в этом нет никакой мистики: это всего лишь одинаковое отношение к делу как к глобальной задаче и общая парадигма понимания методов и способов ее решения (прежде всего, на уровне руководства). Вот такой «вселенский голос» действительно необходим сегодня российскому бизнесу. И эту миссию – во-многом, просвещения и обучения – должны брать на себя профессиональные ИТ-компании. Мы, например, используем для этого собственную модель Know You Customer, подразумевающую полное погружение в бизнес заказчика, начиная с мельчайших задач и заканчивая реализацией комплексной долгосрочной стратегии.

Казалось бы, всё хорошо. Критерии заданы и даже появляется фундамент, на базе которого будут взаимодействовать заказчик и исполнитель. И всё же, как не ошибиться с партнером – провайдером услуг? И как не потратить лишние деньги, притом что, делая такие проекты, они должны быть эффективными и приносить отдачу уже завтра.

Выше мы говорили, что постановка задачи и единый «знаменатель» для этого – необходимое условие успеха. Далее начинается декомпозиция на конкретные подзадачи, инструменты, сроки, этапы и предоставляемые гарантии. Это – первое must have для успешного сотрудничества.

Далее речь пойдет о приземленном (правильной реализации). У клиента, конечно, всегда возникает законный вопрос – сколько будет стоить? Какой тариф предложат? Где тут гибкость? К сожалению, как правило, как только заказчик и исполнитель скатываются в это обсуждение на старте проекта (а чаще всего бывает именно так), и те и другие попадают в мир иллюзий и конструктива не получается. Почему? Как известно, крупные провайдеры работают по утвержденным тарифам, где цена услуги банально складывается из стоимости компонентов, которые необходимы для технического решения, плюс – увы – жадность. При таком положении дел обычный пользователь просто не выбирает тариф: сверху назначается избыточная просчитанная цена с заложенным в нее люфтом на скидку.

На деле же заказчик должен биться за прозрачность и вариативность предлагаемого решения. Комплектующие его интересовать не должны. Здесь «дьявол в деталях»: отношения со многими поставщиками позволяют профессиональному провайдеру подобрать необходимую технику под финансовые возможности клиента. Именно вариативность и дальнейшая гибкость предлагаемого решения, а не цена железки – второй must have.

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

Более того, здесь необходимо, чтобы и каждое приложение, и весь их комплекс тестировали представители заказчика на всех уровнях. Затем собранные данные обрабатываются в многомерной модели (например, учитываются метрики на различных этапах работы приложений, ввод – вывод, отклик сети, время исполнения операций и т. д.), и только после такого совместного анализа производится корректировка конкретного модуля или решения.

Еще один важный момент. При выборе облачного провайдера необходимо обращать особое внимание на число локаций – мест, где провайдер будет размещать оборудование, данные и предоставлять другие свои услуги. Лучше, если у него есть возможность осуществлять это не в одном регионе, а в масштабах всей страны. Может быть, и за рубежом. Кстати, это актуально и для обеспечения катастрофоустойчивости, и для локализации данных. Мы в Liberum Navitas, например, уже оперируем 12 точками присутствия в регионах РФ и шестью точками в мире (Европа, Северная Америка).

Кстати, заказчикам, готовым переносить данные и отлаженные бизнес-процессы в облака, стоит сосредоточить усилия и на комплексной безопасности: информационной и физической. Под физической я имею в виду, конечно, не защиту конкретного здания ЦОД, а контроль носителей, которыми могут распоряжаться лица, имеющие доступ к облачному хранилищу и уполномоченные вносить какие-либо изменения. Очевидно, что такой контроль должна брать на себя служба безопасности заказчика. А вот защиту данных в облачном ЦОД от внешнего воздействия – осуществлять заказчику нужно вместе с исполнителем проекта. И даже если клиент пытается решить этот вопрос собственными (зачастую не самыми современными средствами), то и в этом случае у поставщика должен быть пул партнеров, способных защитить данные клиента, причем на соответствующем уровне и в рамках имеющегося финансирования.

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

Еще один аспект безопасности: порой приходится слышать, что основной ущерб на уровне утечки данных происходит по вине существующих, а чаще – бывших сотрудников (кто-то забыл внести соответствующую информацию в систему, и доступ оказался открыт). Это не всегда так. Да, бывает, что заказчик, у которого весь комплекс защиты данных еще не создан, ищет злоумышленника везде, где только может; даже сочиняет теории заговора, хотя на деле этого почти не бывает.

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

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

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

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

Ключевые слова: Liberum Navitas, облачные технологии, заказчик, провайдер, данные, резервное копирование, облачный ЦОД

Подпишитесь на журнал
Купите в Интернет-магазине

Комментарии могут оставлять только зарегистрированные пользователи