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

Необоснованные страхи

Облака — это совершенно новая технология

Многие читатели считают, что облачные технологии — это что-то принципиально новое, еще неизведанное и неопробованное. На самом деле, все далеко не так. Развитие облачных технологий началось еще в те времена, когда компьютеры не были персональными и занимали довольно большое пространство — несколько комнат или даже этажей, а также требовали промышленной системы электропитания и охлаждения. Вполне справедливо считать, что облачные технологии зародились в 60—70-е годы прошлого века.

В те времена взаимодействие пользователей с системой осуществлялось через разнообразные периферийные устройства, в том числе через терминалы — устройства, которые передавали компьютеру коды нажатых клавиш и отображали на экране генерируемое компьютером изображение. Примерно в это же время стала активно использоваться и виртуализация. Вашему покорному слуге в конце 80-х годов довелось на лабораторных работах в вузе столкнуться с СВМ (Система виртуальных машин) — операционной системой для ЕС ЭВМ, советским переосмыслением архитектуры IBM 360/370. Кстати, СВМ была написана советскими программистами в начале 70-х годов прошлого века, а сам термин “виртуальная машина” родился в лабораториях Кембриджа в конце 60-х.

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

В том, что облачные сервисы воспринимаются как нечто непривычно новое, отчасти виноваты и сами облачные вендоры, когда после нескольких лет предоставления онлайн-сервисов вдруг стали предлагать неведомые “облачные” услуги. Онлайн-сервисы годами использовались пользователями для общения, хранения фотографий и видео, заполнения налоговых деклараций. Бизнес также использовал онлайн-сервисы, например для того же хранения резервных копий данных. Это называлось удаленным бэкапом, интернет-бэкапом, онлайн-бэкапом, но никак не облачным бэкапом. Стремительное переименование онлайн-сервисов в облачные могло сбить с толку пользователей и породить недоверие к уже привычным услугам.

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

У пользователя нет контроля над облачными данными

Это целая группа страхов: мои данные хранятся неизвестно где, они могут пропасть, их могут украсть, их могут увидеть конкуренты. Попробуем разобраться и с этими опасениями.

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

Также можно поступить и с облачным провайдером — в контракте, регламенте или ином документе, определяющем объем оказываемых облачных услуг, обязательно должен быть определен уровень предоставляемого сервиса (SLA, Service Level Agreement), определены нормативы восстановления данных после сбоя (RTO, Recovery Time Objective), прописана ответственность оператора за нарушения порядка предоставления сервиса.

Скажу даже больше: очень часто облачные провайдеры обеспечивают гораздо меньшее время восстановления системы, чем их коллеги из “наземной” ИТ-службы. А что касается малого бизнеса, то он может получить неведомый им до сих пор уровень сервиса. Дело в том, что в небольших организациях и в среде индивидуальных предпринимателей зачастую вообще отсутствует культура резервного копирования данных: нет утвержденной процедуры и нет сотрудников, ответственных за сохранность и актуальность данных. В то же время облачная система может предложить гарантированное восстановление данных после сбоя, причем во вполне разумный срок. Кроме того, вы можете дополнительно сами организовать резервное копирование данных на локальные ресурсы или в иную облачную систему резервного копирования.

Приведу пример из своей практики: уже несколько лет я пользуюсь онлайн-почтой от одного российского провайдера. По старой привычке достаточно долгое время я скачивал почту в локальные папки e-mail-клиента (Outlook или Thunderbird), не надеясь на оператора. Так вот, локальные архивы в силу череды смен операционных систем, компьютеров, жестких дисков уже утрачены и, скорее всего, безвозвратно, а та почта, что осталась на сервере, доступна до сих пор. Получается, что в ряде случаев облачная система при должных мерах безопасности может быть более безопасна, чем on-premise, т. е. находящаяся на стороне пользователя.

У клиентов многопользовательских систем может возникнуть страх, что их данные могут быть доступны другим пользователям системы, вплоть до прямых конкурентов. Чтобы развеять страхи, стоит узнать у оператора, как реализовано совместное использование ресурсов (multi-tenancy). Вариантов реализации совместного multi-tenancy, баз данных и программного кода масса. Все данные, принадлежащие компании, могут быть поделены на группы или классы по степени приватности. Для каждой группы может быть определен свой режим, выделено свое место в облаке или связке облаков (обособленный или общий пул оборудования, обособленная или общая база данных, обособленное или общее приложение и т. п.). Гибридные облака (технология, объединяющая достоинства публичных и частных облаков) позволят распределить данные с разным уровнем приватности. Например, финансовые данные располагаются в частном облаке, а материалы рекламных кампаний — в публичном.

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

Недоверие оператору

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

Одним из перспективных способов решения этой задачи эксперты считают независимую сертификацию облачных решений. Сертификация может быть как добровольная, так и обязательная. До сего момента самым популярным в США независимым стандартом аудита оставался SAS 70 Type 2 — это руководство по проведению аудита сервисных организаций, разработанный Американским институтом сертифицированных общественных бухгалтеров (American Institute of Certified Public Accountants, AICPA). Дальнейшим развитием SAS 70 считается SSAE 16 — группа стандартов, включающая финансовые требования, требования к управлению организацией, к безопасности, доступности сервиса, целостности обработки данных и конфиденциальности. Есть и международная сертификация — ISAE 3402, разработанная International Auditing and Assurance Standards Board (IAASB), являющейся частью Международной федерации бухгалтеров (International Federation of Accountants, IFAC). Если говорить об обязательной сертификации, то в качестве примера приведу Федеральную программу управления рисками и авторизацией (Federal Risk and Authorization Management Program, FedRAMP), систему сертификации именно облачных провайдеров, собирающихся оказывать услуги государственным органам США. Попробую провести параллели с DoD 5015.2. Этот стандарт устанавливал требования для систем управления документами (Records Management Systems, RMS) в органах управления армии США, но скоро стал популярен и “на гражданке”, в американском бизнес-сообществе. Возможно, FedRAMP также станет стандартом де-факто и для облачных провайдеров, оказывающих услуги бизнес-организациям. Глобальная природа Интернета предполагает, что провайдер услуг физически и юридически может располагаться в любом месте земного шара, лишь бы его услуги удовлетворяли требованиям клиента. Если, конечно, клиенты, например государственные органы, вправе выбирать зарубежных операторов. Поэтому даже соответствие оператора строгому облачному стандарту другой страны может рассматриваться как конкурентное преимущество.

Впрочем, в гильдии облачных провайдеров есть и крупные и известные компании. Эти названия всегда на слуху, и, если вдруг сервис перестанет по какой-либо причине функционировать, средства массовой информации не преминут об этом поведать. В качестве примера можно вспомнить сбой в работе облачного сервиса Amazon Elastic Compute Cloud (EC2) в апреле 2011 г., продолжавшийся двое суток. Как пишет популярный сетевой ресурс habrahabr.ru, “причиной сбоя стала ошибка в сетевых настройках кластера Amazon Elastic Block Store (EBS) во время обычной работы по изменению масштабируемости… из-за ошибки изменение маршрутизации трафика произошло некорректно: вместо основной сети он пошёл в сеть низкой пропускной способности”. В течение двух суток работоспособность сервиса была восстановлена, а пострадавшие клиенты получили 10 дней бесплатного пользования сервисом. На мой взгляд, ценная для потенциального пользователя информация: как оператор ведет себя в нештатной ситуации и сколько такая ситуация может длиться. Поэтому перед заключением контракта полезно поискать открытую информацию об операторе, в том числе об имевших место сбоях и предпринятых оператором действиях.

Мои бизнес-процессы слишком уникальны

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

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

Есть и другой подход, и, как вы уже догадались, называется он “гора идет к Магомету”. Идея, что облачные системы слабо кастомизируемы, верна лишь отчасти. Как правило, это относится к multi-tenant SaaS системам, использующим общий код. Есть и другая концепция — инфраструктура как сервис (Infrastructure as a Service, IaaS). Специально для клиента создается свой виртуальный пул ресурсов, на который можно установить привычное, кастомизируемое программное обеспечение. В этом случае компания не вкладывается в инфраструктуру (что требует солидных единовременных затрат), а арендует ее у провайдера.

В качестве альтернативы можно рассмотреть и систему, построенную на базе PaaS-сервиса. PaaS (Platform as a Service — платформа как сервис) — еще одна парадигма предоставления облачных услуг, когда пользователю предлагается облачная программная платформа, он сам собирает на ней бизнес-приложение. Точнее, это могут сделать свои или приглашенные разработчики. Второй вариант предполагает большие затраты, так как заказной продукт, как правило, всегда дороже массового.

Обоснованные риски

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

Облачные решения не всегда дешевле

Облака всегда или почти всегда предлагаются как более выгодная альтернатива системам on-premise. По крайней мере так декларируется в рекламных материалах и статьях. На практике эта формула не всегда универсальна. Перед тем как выбрать, какое решение предпочесть: облачное или традиционное (а если облачное, то от какого провайдера, по какой технологии), крайне необходимо просчитать оба варианта. Расчет стоимости пользования облачным сервисом если не проще, то нагляднее. Есть ставка (за единицу объема хранимой информации, за машинное время, за одного пользователя, за транзакцию и т. п.). Кроме того, крупные облачные провайдеры предлагают онлайн-калькуляторы затрат, что облегчает процедуру расчета. Единственная сложность, что при превышении некоторого объема (данных, транзакций, пользователей) могут быть применены иные ставки.

Расчет стоимости владения системой on-premise сложнее. Вот как можно посчитать общую стоимость владения (TCO) на примере Alfresco. Все затраты можно разделить на капитальные (CapEx) и операционные (OpEx):

Статья затрат

1. CapEx

1.1. Серверы

1.2. Пользовательские устройства (ПК, смартфоны…)

1.3. Локальные вычислительные сети (ЛВС)

1.4. Инфраструктура для систем хранения данных (СХД)

1.5. Лицензирование серверного и клиентского ПО

2. OpEx

2.1. Внедрение

2.2. Площадь в ЦОДе для размещения оборудования

2.3. Администрирование серверов

2.4. Стоимость ввода в эксплуатацию новых серверов

2.5. Электричество (питание и охлаждение), ИБП

2.6. Администрирование клиентских устройств

2.7. Поддержка от поставщиков

2.8. Обучение администраторов

2.9. Обучение пользователей

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

Зная все цифры, можно построить уравнение с одним неизвестным (время). Как правило, в системах on-premise велики обычно первоначальные затраты, а операционные составляют доли первоначальных. Например, стоимость одного года поддержки решения вендором или интегратором оценивается в 20% от стоимости системы. Затраты на облачные системы растут линейно (если не меняются ставки), и в какой-то момент стоимость пользования облачной системой превысит стоимость владения системой on-premise. Весь вопрос, когда это произойдет. Если это больше того времени, в течение которого вы планируете работу компании или больше горизонта планирования, то облачная система будет выгоднее. Если нет, то, возможно, имеет смысл инвестировать в создание собственной системы. Если вы планируете привлекать заемные средства, то отнесите затраты на привлечение средств (затраты на оформление кредита, комиссию, проценты) в капитальные и операционные расходы и еще раз решите уравнение. Возможно, это вас приведет к принятию другого решения.

Не все информационные системы могут быть переведены в облако

Облачную концепцию не всегда можно рассматривать как полную альтернативу традиционной. Есть ряд информационных систем, которые не могут быть переведены в облака. К ним можно отнести:

  • системы, работающие с производственным и иным специфичным оборудованием, в том числе системы реального времени. В этом случае даже виртуализация и IaaS-подход может быть бессилен;
  • высокоинтегрированные системы. Как правило, раздел систем невозможен, равно как и интеграция выделенной и перенесенной в облако системы и оставшихся систем on-premise;
  • заказные системы, разработанные 15—30 лет назад. Данные системы могут использовать устаревшее оборудование, более неподдерживаемые операционные системы и платформы. Часто сам разработчик уже прекратил поддержку этих систем;
  • системы, обеспечивающие жизнедеятельность предприятия. Это системы, простой которых может привести к катастрофическим последствиям или потере бизнеса. Например, для банка такой системой является АБС.

Все вышесказанное относится к уже существующим системам и, разумеется, не относится к новым облачным предложениям.

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

Проблема последней мили

С переводом системы в облака или выбором облачной альтернативы во весь рост поднимается проблема последней мили — надежность соединения с провайдером Интернета. Организация становится критически зависимой от доступности, скорости, надежности интернет-соединения. Чтобы страх остаться в неподходящий момент без Интернета не перерос в фобию, имеет смысл относиться к нему, как к риску. А чтобы оценить риск, нужно определить его вероятность и ущерб. Для грубой оценки вероятности можно использовать статистику прошлых периодов по своему провайдеру. Вспомните, сколько было перерывов в обслуживании, их длительность. Были ли проблемы со скоростью? Приходилось ли вам обращаться в службу поддержки, какова была реакция? Используйте все эти данные, чтобы оценить непрерывность сервиса и вероятность возникновения риска.

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

Наверное, самая очевидная стратегия минимизации данного риска — организация резервного соединения. Если для небольшой организации или индивидуального предпринимателя в большинстве случае будет достаточно мобильного Интернета, то для крупной компании организация и поддержание резервного канала может оказаться дорогостоящим мероприятием. Тем не менее не таким дорогим, как потеря связи с облачным приложением.

Облачный пузырь еще не лопнул

Эту интересную мысльвысказал Дэн Элам (Dan Elam), главный операционный директор RSC Solutions. Сейчас многие стартапы переоценены. Так, Dropbox оценивается в 5 млрд. долл., при этом штат компании составляет менее 100 человек. А Lenovo (штат — более 26 тыс. сотрудников) оценивается в 7 млрд. долл., а OpenText (штат — 4.5 тыс. сотрудников) — в 3 млрд. долл. Можно со всей уверенностью говорить, что сформировался очередной пузырь — облачный. Все пузыри рано или поздно лопаются, в качестве примера можно вспомнить “дотком-бум”, имевший место в начале 2000-х или ипотечный пузырь на фондовом рынке США, с оглушительным треском лопнувший в 2008-м. Дэн Элам считает, что облачный пузырь лопнет уже в 2012 г. Понятно, что в первую очередь пострадают от этого инвесторы, вложившие средства в переоцененные стартапы. Но стоит ли этого бояться рядовым пользователям сервисов? Это будет зависеть от того, останется ли облачный оператор на плаву.

Для минимизации риска можно в качестве потенциального провайдера рассматривать крупные компании, для которых облачный бизнес не единственный вид деятельности. Думается, они будут более устойчивы к подобным рискам и не “сдуются” в мгновение.

Также эксперты отметили еще один интересный тренд: многие традиционные производители программных продуктов on-premise либо приобретают облачные стартапы (Oracle приобрел RightNow Technologies, SAP — SuccessFactors, IBM — DemandTec), либо сами развивают облачные направления (Adobe — Photoshop Online, Microsoft — Office 365). Думаю, что опыт вендора и его устойчивое финансовое положение только благотворно скажутся на солидности его облачного предложения.

Вместо эпилога

Можно было бы в заключение написать что-нибудь вроде: “переходить или не переходить в облака — этот ответ для каждой компании будет свой. Нужно просто оценить риски, взвесить все достоинства и недостатки каждого варианта”. При всей лаконичности ценность такой рекомендации стремится к нулю. Чтобы посчитать все “за” и “против”, требуются не только некоторые знания и навыки, но и просто время. Не всегда в компании найдется человек, у которого не будет недостатка в чем-то из вышеперечисленного. Поэтому свои выводы я попробую сформулировать в виде тезисов, с которыми вы можете соглашаться или не соглашаться:

  • Облачные технологии и облачные решения — это развитие уже зрелых, зарекомендовавших себя технологий — виртуализации, онлайн-сервисов. Новыми эти технологии называют все больше маркетологи с целью подогрева интереса к ним. Да еще высока доля гипноза и спекуляций, но тем не менее на рынке трудится большое число вендоров, причем со временем будет расти доля крупных вендоров и производителей традиционного программного обеспечения.
  • Есть целый ряд приложений, для которых неочевидна или даже негативна перспектива перевода их в облака, например приложения, обеспечивающие жизнедеятельность предприятия, высокоинтегрированные приложения, системы реального времени, заказная разработка 15—20-летней давности.
  • Для остальных приложений стоит сравнить стоимость традиционной и облачной модели. При традиционном подходе первоначальные затраты больше, чем стоимость последующего сопровождения системы. У облачных систем нет первоначальных инвестиций, а совокупные по времени затраты растут линейно. Поэтому в определенной точке графики, как правило, сходятся, и после этого момента облачная модель становится более затратной. Чем точнее расчет, тем больше шансов, что вы примете правильное управленческое решение.
  • Облачные технологии многогранны. Это не только ПО как сервис, но и инфраструктура как сервис и платформа как сервис. Вполне возможно, вам удастся найти приемлемый вариант облачной автоматизации ваших уникальных бизнес-процессов.

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

Автор статьи — ИТ-аналитик компании DIRECTUM.

СПЕЦПРОЕКТ