В последнее время про облака говорят не просто много, а очень много, но крайне редко трактуют их как вызов компетенциям всего профессионального сообщества. О таких вызовах и о ближайших перспективах в данной сфере рассказал директор по технологиям Hitachi Data Systems в регионе Европа, Ближний Восток и Африка Боб Пламридж (Bob Plumridge), который также входит в состав группы маркетинга решений и развития бизнеса.
Intelligent Enterprise: Как, на ваш взгляд, будет выглядеть концепция развития облачного хранения данных?
Боб Пламридж: Ответ на этот вопрос зависит от того, о каком типе облака идет речь, о частном или публичном или же о комбинации того и другого, что, мы считаем, будет доминирующей моделью. Уже сегодня заметна такая тенденция: крупные предприятия, перенося свои данные в облако, делят их в первую очередь на те, которые нужны им для повседневной работы, и на внешние ресурсы, принадлежащие сторонним организациям. В силу этого внутренние ИТ-департаменты фокусируют свое внимание на поддержке ежедневных потребностей своих компаний в ИТ и в обработке данных. А вот архивы и массивы данных, подлежащие длительному хранению, переносятся в инфраструктуру внешних поставщиков.
В результате меняется структура спроса внутренних ИТ-подразделений на специалистов. Сейчас уже в меньшей степени требуются системные администраторы и администраторы баз данных, а всё большее значение приобретают менеджеры по работе с клиентами и сотрудники, контролирующие выполнение SLA-соглашений, так как отношения между внутренним ИТ-подразделением и внешним поставщиком услуг оцениваются не в терабайтах, а именно в способности выполнять соглашение. При этом можно заметить, что вакансии технического характера перемещаются в компании поставщиков облачных услуг, которые имеют возможность сократить удельные затраты за счет масштаба, так как они развертывают свою ИТ-инфраструктуру не под одну конкретную компанию, а под десять, двадцать, а то и пятьдесят заказчиков. Вот тогда эффект масштабности дает свои результаты.
Пожалуй, все должны бы уже привыкнуть к тому, что в новых средах уходят старые риски и приходят новые...
Безусловно, существуют новые риски, которыми надо уметь управлять. Уже есть примеры двух американских провайдеров, ушедших из бизнеса. Одна из компаний при ликвидации дала своим клиентам две недели на то, чтобы забрать свои данные, а это практически невозможно. В результате у клиентов осталось два варианта — переносить данные обратно на собственные внутренние ресурсы, но за две недели надо где-то найти достаточно мощностей для хранения таких объёмов, что зачатую является непосильной задачей, либо же перенести эти данные к другому провайдеру, а перенос — это отдельный процесс, очень дорогостоящий и во многом зависимый от коммуникационных каналов. В любом случае это занимает время и сопряжено с рисками.
Возникает вопрос: если вы обращаетесь к подобным услугам, то как можете защитить себя от таких рисков? Найти ответ на него нелегко. Может быть, стоит работать с двумя поставщиками услуг, ведь если один обанкротится, то останется другой. Или не связываться с мелкими партнерами, а работать только с крупными и надежными, но это будут уже другие затраты.
Очевидно, что любой центр обработки данных (ЦОД) имеет свои ограничения. Бесконечно больших ЦОД не бывает. Рано или поздно их придется наращивать путем построения новых. Но не бывает и двух одинаковых ЦОД. Пока эту проблему удается решать за счет увеличения вычислительных мощностей. Но о системах хранения данных такого сказать нельзя. Как быть?
Это верно. Мощности технических средств хранения данных растут не так быстро, как мощности средств, которые эти данные порождают. Это огромная проблема. Эти вопросы пытаются решить с помощью технологии, когда некий базовый файл сохраняется один раз, а его модификации существуют только в виде инкрементальных изменений. Такой подход помогает решить проблему, но, мне кажется, наилучший путь состоит в том, чтобы вначале оценить, что нужно хранить и для чего. Мы, да и все другие участники индустрии, согласны, что большая часть данных, которые сегодня хранятся в системах хранения данных (СХД), в общем-то храниться там не должна.
Практически во все отраслях по-прежнему жива тенденция к тому, чтобы сохранить всё и навсегда. В каком-то смысле наша отрасль стала жертвой своего успеха, мы значительно облегчили задачу сохранения информации на максимально большой срок. Но сейчас ситуация близка к тому, как полтора десятилетия мы все двигались в этом направлении, но потом сказали сами же притормозили. Сейчас, как мне кажется, актуальный вопрос должен звучать иначе: каким образом обеспечить хранение того, что нам действительно необходимо, и как избавиться от всего остального?
Следует найти эффективные способы определения нужной информации, данных, имеющих юридическую значимость и соответственно требующих определенных норм хранения. Например, в Великобритании финансовая информация должна храниться семь лет. Как сделать так, чтобы данные по истечении этого срока автоматически удалялись? На самом деле обязательный период хранения и автоматизация его соблюдения — это очень важный момент. Во многих компаниях эти нормы не установлены и данные, несмотря на то что должны храниться в течение ограниченного времени, остаются навсегда.
Следует ли из этого, что хранение данных на стороне облачного провайдера неразрывно связано с некими сервисами, предоставляемыми с его стороны?
Мне кажется, пока это еще не так. Но в ближайшие пару лет всё будет развиваться именно в эту сторону, потому что поставщик услуг хранения не просто хранит данные, но на основе этих данных может предоставлять и дополнительные услуги.
Но у различных данных есть общая проблема — засорённость. И её не решить в рамках SLA.
Совершенно согласен. Я не пытаюсь убедить вас в том, что проблема эта простая, но я знаю, как ее решить. То, что вы считаете мусором, для других может оказаться жизненно важной информацией. Вопрос надо ставить иначе — каким образом бизнес или компания принимает решение, какая информация важна, а какая нет? Всё это осложняется еще одним аспектом: мы можем легко найти примеры того, что данные, которые сегодня воспринимаются как ненужные, через какое-то время перестают быть таковым. Подобными примерами могут служить здравоохранение и фармацевтика. Думаю, что единственным путем решения этой проблемы является анализ данных в момент их формирования. Скажем, у кого-то сохранилось десять петабайт данных, но он же не будет организовывать их анализ просто для того, чтобы разобраться, что из этого можно удалить. Вопрос нужно ставить в плоскости воспроизводства этой проблемы, а для этого необходимо проводить отбраковку данных сразу при их появлении. Речь идет о потоковом анализе в реальном времени, в тот момент, когда данные поступают из бизнес-систем. Для этого необходимо разработать сценарные модели, которые будут определять, какие данные стоит сохранять, а какие нужно удалять, сразу назначая срок и автоматически устанавливая атрибуты времени хранения. На мой взгляд только таким способом эту проблему и можно решить.
Пять лет назад у программистов еще не было опыта написания ПО специально под облачные сервисы. Сейчас он появился. Но не везде... Это опять-таки новые компетенции, не всегда совершенные, однако уже появляются новые требования к практикам работы с данными. Как вы видите развитие управления данными?
К настоящему времени уже сформировался специальный термин Data Scientist — «ученый по данным». Фактически это человек, который понимает предметную область в достаточной степени для того, чтобы определить, какие данные являются ценными, а какие нет. Сейчас это определение расширилось и подразумевает умение анализировать, какие данные должны сохраняться и почему. Ожидать таких знаний и навыков от сотрудников ИТ-департамента означает предъявлять к ним очень жесткие требования. Скорее всего это функция представителей бизнеса.
Если управление данными становится бизнес-задачей, то бизнес хорошо понимает только одну мотивацию — деньги. Как эту характерную особенность бизнеса можно использовать при категорировании данных? Было бы логично придерживаться такого постулата: та информация, что хранится дольше и надежнее, соответственно и стоит дороже.
Да, и мы имеем тому реальные примеры. Практика категоризации услуг при работе с данными активно используется (золотой, платиновый и прочие уровни) в зависимости от того, в какую категорию попадает сервис или услуга; соответственно назначается и цена. Например, платиновый уровень гарантирует мгновенный доступ, две, а то и три копии данных на территориально разнесенных ресурсах и моментальное восстановление в случае сбоя, а в противоположность ему можно привести бронзовый уровень — хранение вне ЦОД на съемном носителе и гарантированный доступ в течение двенадцати часов. Соответственно и цена этих уровней будет существенно различаться.
Обычно в жизни происходит так, что вначале данные оплачиваются по платиновому тарифу, а по мере устаревания переводятся на более дешевый уровень. Однако мне представляется, что и с самого начала не все данные достойны того, чтобы попадать на платиновый уровень, а значит, их анализ уже в момент формирования позволяет существенно сократить затраты.
