Переносим операционные процессы компании в облако


Оглавление (нажмите, чтобы открыть):

Экспертиза: на чем можно сэкономить при миграции в облака?

Облака ассоциируются с серьезной экономией, однако безоглядно переносить всю инфраструктуру эксперты не советуют. Здесь тоже есть подводные камни, многие из которых ведут к дополнительным затратам. В том, как потратить на миграцию оптимальную сумму и выстроить взаимовыгодные отношения с провайдером облачных услуг, CNews помогал разбираться продакт-менеджер КРОК Облачные сервисы Сергей Зинкевич.

Из чего складываются затраты на облака?

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

«Если заказчик готов к тому, что его инфраструктура будет недоступна для сотрудников и клиентов хотя бы на одну ночь (обычно выбирается ночь с субботы на воскресенье, но конкретный день и время суток зависят от сервисов и пользователей), – стоимость работ для него автоматически уменьшится вполовину, – объясняет продакт-менеджер КРОК Облачные сервисы Сергей Зинкевич. – И, напротив, если заказчик переносит критичный для бизнеса сервис и хочет бесшовно интегрировать его в облачную инфраструктуру с сохранением постоянной доступности, – цена проекта будет выше».

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

«Совсем недавно мы провели вебинар о том, как провести миграцию данных и сервисов в облаке без проблем и лишних затрат. В нем мы рассказали о типовых ошибках, технических средствах, упрощающих процесс переноса, и очередности работ. А на следующем вебинаре, который состоится 25 апреля, мы поделимся советами, которые помогут правильно выбрать провайдера и составить для него ТЗ», – говорит Сергей Зинкевич.

Как избежать лишних трат?

Главное, на что нужно обратить внимание – выбор поставщика услуги. Важно детально ознакомиться с компетенциями облачного провайдера и не ориентироваться только на цену, потому что как раз низкая стоимость может обернуться большими проблемами при эксплуатации. Конечно, в первую очередь стоит рассматривать лидеров рынка с большой историей внедрений, желательно – в том сегменте, который представляет ваша компания. Можно почитать отзывы других клиентов или даже собрать их в индивидуальном порядке. Саму облачную платформу лучше сначала протестировать, воспользовавшись демо-доступом. И очень важно максимально ответственно подойти к созданию SLA: документ должен быть детальным, строгим и включать абсолютно все параметры, касающиеся как работы облачной платформы, так и команды специалистов, поддерживающих и развивающих ее.

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

«Похожая ситуация была у нашего клиента Туту.ру, – вспоминает Сергей Зинкевич. – И решилась она как раз путем перехода в облако. Мы переписали систему биллинга, чтобы заказчик мог четко отслеживать затраты в привязке к конкретным проектным командам и процессам. В результате ИТ-директор видит детальную картину затрат, а разработчики Туту.ру, получая индивидуальные счета за услуги, научились четко планировать нужный объем ресурсов».

Какие приложения лучше не переносить в облака?

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

Как оптимизировать расходы в зависимости от модели потребления?

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

«Так делает, например, автодилер Swed-Mobil, экономя до 50% бюджета, распланированного на облачные услуги, – приводит пример Сергей Зинкевич. – Похожий опыт есть и у другого нашего клиента – медицинской организации, которая выключает на ночь электронную регистратуру, работающую на базе облака КРОК. Когда утром в клинику приходят пациенты, она запускается снова».

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

Какие решения помогают управлять затратами на облака?

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

«В облаке КРОК используются самые популярные на данный момент утилиты, в том числе – Terraform и Ansible. Их основное преимущество – возможность вместо условно десяти «ручных» операций развернуть вычислительные среды, хранилища данных и сетевые устройства одним кликом, после чего также быстро удалить, не тратя время администраторов и ресурсы облака», – добавляет Сергей Зинкевич.

Каковы потенциальные бизнес-преимущества от экономии в облаках?

Ключевая выгода – сокращение капитальных затрат. Многие компании, вставшие на «облачный» путь, отчитываются о 30-40-процентном уменьшении CAPEX.

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

«Подготавливаясь к пику активности, такие заказчики обращаются к облаку вместо того, чтобы вкладываться в собственные ИТ, которые квартал или дольше стоят «холодными», – детализирует Сергей Зинкевич. – А если активность бизнеса в целом сбалансирована в течение года, нагрузки стабильны, то в перспективе пяти лет затраты на собственную инфраструктуру и облачные услуги могут сравняться. Но наши клиенты, которые пользуются облаком на протяжении многих лет, говорят, что считать только лишь прямые затраты не корректно. Помимо издержек на оборудование, в бюджет нужно закладывать также затраты на администрирование, то есть поиск на рынке специалистов с нужной инфраструктурой, оплату ФОТ, повышение постоянной квалификации персонала и его удержание. Для многих крупных компаний проще и выгоднее переложить эти задачи на провайдера, пользуясь его экспертизой и инфраструктурой enterprise-уровня».

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

Миграция в облако: основные этапы, стоимость и вопросы безопасности

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

Основные этапы миграции в облако

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

1. Проверка и выбор облачной модели

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

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

2. Тестовая миграция и проверка облака

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

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

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

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

3. Дорожная карта миграции

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

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

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

Безопасность в облаках

Залогом безопасности является проверка всего, что происходит в облаке, включая управление самой системой. Аудит, с одной стороны, подразумевает определенные технические и финансовые затраты, с другой — позволяет избежать многих проблем в будущем.

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

Всегда проверяйте поставщика облачного сервиса. Для этого задайте себе следующие вопросы:

  • Доверяют ли крупные клиенты этому поставщику?
  • Был ли поставщик замешан в каком-либо заметном скандале?
  • Достаточно ли у него опыта, чтобы обслуживать мой проект?

Доверяйте действиям, а не словам.

Основные моменты для любой стратегии миграции в облако

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

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

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

Производительность приложений в облаке

Чтобы не растерять производительность, выбирайте поставщиков с надежными резервными каналами, трезво оценив, какого плана услуги они предоставляют, в какое время, и в каком объеме.

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

Заключите соглашение об уровне услуг. «Service Level Agreement» (SLA)— термин методологии ITIL, обозначающий формальный договор между заказчиком услуги и её поставщиком. Профессиональные поставщики облачных услуг предоставляют условия, включающие круглосуточную поддержку. Таким образом, например, аппаратный сбой на стороне подрядчика перестает быть проблемой заказчика. Но могут существовать расхождения между тем, что поставщик услуг готов сделать, чтобы решить вашу проблему, и тем, что поставщик может делать в рамках выбранного вами плана подписки. Конфликт интересов становится явным в тот момент, когда вы хотите получить «подписочный» платеж, а поставщик выставляет счет за ресурсы по факту их использования. Выбирая поставщика, стоит учесть данную особенность, и, повторюсь, тщательно изучить SLA. Разработайте план Б на случай, если потребуется расширить инфраструктуру.

Планируйте периоды пиковой нагрузки. Часы пик бывают не только у вас, но и у провайдеров, и «веселье» начинается, когда такие времена наступают у вас обоих. Важно иметь план Б и на этот случай.

Затраты при переходе на облачные технологии: что входит в уравнение?

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

Электричество. Для стран, где электричество стоит дорого (т. е. для большинства стран), это очень важная часть уравнения. В этом случае переход на облачные технологии является чрезвычайно эффективным, потому что за деньги, которые вы тратите на 10 реальных серверов, можно получить

Резервные копии. Создание резервных копий в облаке — дорогое удовольствие. Когда инфраструктура находится в офисе, осуществить резервное копирование проще. Вы просто добавляете репозиторий/библиотеку и копируете данные туда. В облаке все организовано несколько сложнее, но экономия в данном вопросе может оказаться губительной для бизнеса. Подумайте, резервные копии чего и как часто вам нужно создавать, сколько для этого понадобится ресурсов. Обсудите с вашим провайдером возможность сделать для вас отдельный план для резервного копирования.

Интеграция. Если облако является публичным, продумайте для себя ответы на следующие вопросы:

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

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

  • Каким образом удастся совместить локальное и публичное облако?
  • Будут ли все приложения работать так, как задумано?
  • Какой будет реакция пользователей на фактически двойную инфраструктуру?

При грамотном налаживании работы пользователи не заметят двойственности архитектуры. Случаются моменты, когда тайное становится явным (например, когда одна из частей дает сбой), и к таким моментам стоит быть готовым заранее.

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

Даже в свете последних скандалов в СМИ по поводу взлома облачных инфраструктур, миграция в облако — это верное решение. Это будущее ИТ. Опять же, существуют гибридные облака, которые позволяют хранить конфиденциальные данные локально, разместив все остальное в облаке. Выход всегда есть, что бы ни произошло.

Автор статьи — ведущий системный инженер компании Itransition.

Этапы переноса инфраструктуры в облако

Каждый из этапов имеет свои нюансы, знание которых позволит не допустить ошибок.

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

Разберем основные этапы переноса инфраструктуры в облако. Каждый из них имеет свои нюансы, знание которых позволит не допустить ошибок.


Этап подготовки

Подготовка начинается с оценки имеющейся инфраструктуры и составления плана переноса. Необходимо рассчитать точную мощность тех ресурсов, которые вы планируете перенести в облако. Зачастую они могут оказаться меньше, чем используемые в настоящий момент. Работая с собственной физической или виртуальной инфраструктурой, мы закладываем запас по мощности, чтобы предвидеть будущий рост запросов бизнеса, а также нивелировать огрехи оптимизации, которые исключены в среде облачного провайдера. Аренда виртуальной инфраструктуры позволяет добавлять дополнительные ресурсы только тогда, когда в них возникает необходимость, поэтому, если вы просчитали, что для работы определенного сервиса необходимо 2 ядра, 16 Гб ОЗУ и 500 Гб дискового пространства, значит, столько необходимо арендовать, а когда потребуется увеличить производительность — скорректируете спецификацию.

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

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

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

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

Выбор способа переноса

В основном способ переноса зависит от исходной платформы (тип виртуализации в случае миграции частного облака или железный сервер) и активности данных (будет это офлайн-переезд или необходимо переносить горячие данные). Также играет роль скорость интернет-канала между исходной инфраструктурой и центром обработки данных облачного провайдера. При низкой скорости или невысоком качестве линии связи имеет смысл рассмотреть вариант миграции с использованием внешнего NAS.

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

Этап переезда

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

Если осуществляется перенос железных серверов, то используется специальное программное обеспечение для клонирования образов серверов от Acronis, Clonezilla, Partition magic или VMware vCenter Converter, которое подходит для миграции в среду VMware. Они подходят для офлайн-преезда, когда можно выключить сервер, сделать его полную копию и развернуть в виртуальной среде. В данном случае необходимо учитывать совместимость операционной системы: старая ОС Windows может хорошо работать на устаревшем железе, а для современной аппаратной платформы провайдера у нее может не оказаться драйверов.

Если заказчик переносит в облако собственную виртуальную инфраструктуру VMware, можно использовать функцию экспорта/импорта через файл формата OVF/OVA (унифицированный формат распространения готовых виртуальных машин) как для отдельных виртуальных машин, так и для целых vApp.

Еще один способ удобной миграции — использование инструмента VMware vCloud Connector, он объединяет частное облако заказчика и публичное облако провайдера. Администратор получает доступ к понятному графическому интерфейсу, в котором можно запускать задачи копирования одной или нескольких виртуальных машин.

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

Заключение

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

Миграция в облака: в чем могут разойтись ИТ-отдел и финансисты

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

Менее 40% компаний достигают показателей, ради которых затевалась миграция в облако, говорится в исследовании Forrester. Расскажем, что эксперты предлагают, чтобы снизить шанс такого исхода.

Учтите скрытые расходы

Соучредитель компании Cloudability Джонатан Стормен (J.R.Storment) рассказывает, как происходит перерасход облачных бюджетов:

  • списание средств может вырасти при масштабировании, если затем компания в отсутствие потребностей оставит по подписке избыточные ресурсы на несколько дней или даже недель;
  • дополнительные затраты могут появиться в том случае, если компания подписана на слишком большое количество услуг. К примеру, по мнению Стормена, на некоторых предприятиях одновременное применение облачных технологий и методологии разработки DevOps (концепция Development and Operations, предполагает активное взаимодействие и интеграцию специалистов по разработке и специалистов по информационно-технологическому обслуживанию) дало “айтишникам” иллюзию того, что они могут подписываться на сервисы по своему усмотрению, с минимальным обоснованием.

Степень избыточности расходов на облака может быть привязана к расходам на ИТ в целом. Согласно отчету компании Pendo, около 80% функций в программных бизнес-приложениях и приложениях для частных пользователей используются редко или вообще не используются. Во всем мире при внедрении систем впустую тратятся миллиарды долларов. Директор по маркетингу Pendo Джейк Сорофман (Jake Sorofman) отмечает, что многие функции не используются, так как бесполезны для пользователей. Иногда ИТ-специалисты подбирают функциональность без четкого понимания того, что на самом деле нужно конечным пользователям, поясняет Сорофман.

Базовая схема сервисов облачной миграции

Источник: Connectria, 2020

Рассчитайте тщательно

Снижение расходов является основной движущей силой внедрения корпоративного облака. Но дьявол кроется в деталях, и если их учесть, можно снизить расходы на инфраструктуру в разы. Облачная миграция подразумевает высокие разовые затраты на настройку. После того, как данные переведены в облако, операционные расходы складываются из стоимости задействованных облачных сервисов: виртуальных ресурсов, хранения данных, трафика и так далее. «Облачный провайдер берет на себя привычные для компании операционные затраты – на поддержку инфраструктуры, управление рисками и т.д. Поэтому некорректно сравнивать стоимость облака с капитальной стоимостью оборудования on premises, нужно включить в сравнение и операционные расходы. Тогда все оказывается по-другому. Важная часть работы провайдеров — разъяснить клиенту комплексный характер расчётов: почему это стоит именно столько и так работает. Важно, чтобы клиенты могли принять информированное и взвешенное решение», – комментирует Илья Летунов, руководитель Mail.ru Cloud Solutions.

Для компании «Газпромбанк Автолизинг» одним из ключевых факторов выбора в пользу облака стало то, что оно позволяет в разы быстрее масштабировать бизнес, сокращая время и затраты на организацию ИТ-инфраструктуры в новых филиалах. На основе облака в компании функционируют клиентские сервисы и мобильные приложения по выбору и заказу автомобилей, а также информационные системы филиалов по всей стране. «Мы выбрали облачную модель развития с самого старта бизнеса: у нас нет ни одной серверной, все критически важные для бизнеса системы работают в облаке провайдера. Это позволяет нам быстро развивать бизнес, открывая в считанные дни новые филиалы и запуская востребованные рынком сервисы», – пояснила главный исполнительный директор компании «Газпромбанк Автолизинг» Лилия Маркова.

Другой пример – из истории фриланс-биржи FL.ru. По мере развития сервисов ИТ-инфраструктура компании усложнялась, и объем рутинных задач, связанных с ее обслуживанием, нарастал как ком. Приходилось часто менять накопители, мониторить состояние оборудования, администрировать систему. Чтобы добавить новые мощности, требовалось до двух недель. Бизнесу требовались оперативность и сокращение расходов и трудозатрат на развитие парка оборудования. Компания попробовала арендовать физические мощности, но осталась проблема администрирования. Тогда инфраструктура компании переехала в облака.

Секрет успеха – в качественном планировании

Многие специалисты советуют принимать взвешенный, постепенный план миграции на облака. Необдуманное стремление форсировать переезд может дорого обойтись бизнесу. На ранних этапах проекта компания должна разработать обучающие мероприятия и предусмотреть достаточно времени на адаптацию приложений. К примеру, оператор мобильной связи Tele2 перевел во внешнее облако одного провайдера хостинг бизнес-приложений SAP и SAP HANA, а также среды тестирования и разработки. Миграция прошла в 10 этапов. Для каждого приложения был разработан специальный алгоритм, который сделал время простоя минимальным.

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

Сервис торговли б/у автомобилями CarPrice оперирует большим количеством фото и видеоконтента (изображения автомобилей, примерно 40 ТБ данных), который изначально хранился на Amazon S3. Постепенно выкристаллизовались три проблемы:

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

Поэтому компания решила перенести данные в объектное хранилище на территории России, задача решалась поэтапно.

  1. Сначала подключили отечественных CDN-операторов, это помогло оптимизировать затраты на трафик и увеличить скорость. В результате весь трафик раздавался с серверов на территории России.
  2. Далее компания занялась переносом непосредственно данных. За один вечер перенесли горячие данные по текущим аукционам (10 ТБ). Потребовался один разработчик.
  3. В течение следующей недели переносился архив (30 ТБ). Поскольку Amazon уже частично попал под блокировку, разработчик компании подготовил специальный скрипт – данные переносились через промежуточные незаблокированные сервера.

Перенос всей ИТ-инфраструктуры

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

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

Частичная миграция

Другая тенденция – с запросами к облачным провайдерам обращаются бизнес-подразделения, например маркетинг или продуктовые офисы компаний. Они проявляют активность, потому что у руководителей ИТ-департаментов не всегда есть время детально разбираться с потребностями в вычислительных мощностях под небольшие задачи. В результате провайдеры все чаще предлагают доступ к облачным услугам по модели Managed Services. «Этот подход дает возможность не только предоставлять ресурсы облака, но и передать провайдеру сопровождение облачной инфраструктуры до уровня приложений», – поясняет Сергей Зинкевич.

«Барышский мясокомбинат» перенес в облако хранение и обработку данных поставщиков и контрагентов, как того требует федеральный закон «О персональных данных». Так компания сняла с себя капитальные затраты на создание и владение защищенной ИТ-инфраструктурой. Расходы на сертификацию средств защиты, разрешения от ФСТЭК и ФСБ нес только провайдер.

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

Специалисты рекомендуют выстраивать общение с командами на стороне клиента, погружаться в бизнес в ходе аудита ИТ-систем и консалтинга. Провайдер может детально изучить потребности заказчика в ходе Customer Development и по итогам сформировать план по использованию облачных сервисов внутри компании. В плане соотносятся потребности в облачных ресурсах с бизнес-ожиданиями.

Миграция в облака – глобальный тренд

Согласно прогнозу TechNavio, глобальный рынок услуг облачной миграции в ближайшее время будет расти в среднем на 23% в год и в 2022 году составит около $4,4 млрд.

Прогноз роста рынка услуг облачной миграции до 2022 года

Источник: TechNavio, 2020

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

Переход в облако как способ оптимизации ИТ

На секции «ИТ-инфраструктура и облачные сервисы», проведенной в рамках форума «МИР ЦОД – 2015», обсуждались две ключевые темы: повышение эффективности ИТ-инфраструктуры, а также спрос и предложение облачных сервисов.

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

На российском рынке по-прежнему сохраняется диспропорция между спросом и предложением облачных услуг. С одной стороны, несмотря на обилие провайдеров, заказчики жалуются, что они не могут найти услуги, удовлетворяющие всем их требованиям. С другой стороны, недостаточный спрос не оправдывает развития провайдерами технологически сложных сервисов. Ситуацию на российском рынке мог бы поменять приход крупных мировых игроков. Именно такую цель и ставит перед собой компания Microsoft, которая на форуме «МИР ЦОД – 2015» впервые представила свою новую инициативу Cloud OS Network Russia, предусматривающую предоставление облачных услуг совместно с российскими провайдерами. «Мы хотим, чтобы облака в России преодолели уровень ясель и детского сада и доросли до нормального крупного бизнеса», — заявил в своем выступлении, открывавшем пленарное заседание, Олег Коверзнев, руководитель программы развития партнерских облачных решений в Microsoft.

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

Вместе с тем зачастую именно экономическая целесообразность оказывается главным аргументом в пользу перехода в облако. В управляющей компании Inventive Retail Group подсчитали, что в таком случае за три года им удастся сэкономить более 20%. «При прочих равных условиях этот довод оказался для нас самым убедительным», — рассказывает Василий Аникушин, руководитель отдела облачной ИТ-инфраструктуры. Под прочими равными условиями понималось соответствие инфраструктуры, сервисов и ответственности провайдера жестким требованиям со стороны заказчика. Убедившись в надежности провайдера, компания не побоялась перенести в облако такой критичный сервис, как корпоративная система управления ресурсами, и не ошиблась в своем решении — за три года не было ни одного критичного сбоя.

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

СЕРВИСЫ MICROSOFT ОТ РОССИ ЙСКИХ ПРОВАЙДЕРОВ

Несмотря на все усилия по пропаганде облачных сервисов и несомненную выгоду их использования, многие потенциальные потребители таких услуг относятся к ним с недоверием, сомневаясь в их надежности и безопасности. В частности, как отметил в своем выступлении, Кирилл Котляренко, специалист по технологической стратегии Microsoft, если о направлении развития таких крупнейших поставщиков услуг, как Amazon, Google и Microsoft, у них имеется хотя бы общее представление, то стратегия российских сервис-провайдеров остается для них неясной. Укреплению доверия и изменению положения дел в лучшую сторону должна способствовать инициатива Microsoft Cloud OS Network Russia.

COSN Russia является ответом Microsoft на текущую экономическую и политическую ситуацию. Сегодня заказчики опасаются хранить данные в ЦОДах иностранных компаний (как за пределами РФ, так и на территории России). Так что предложение о предоставлении облачных сервисов на платформе Microsoft из центров обработки данных российских провайдеров оказалось как нельзя более своевременным. Стратегически компания нацелена на продвижение собственных облачных услуг, однако на каждом рынке имеются свои препятствия. Поэтому, чтобы дать заказчикам возможность выбора, на общемировом уровне была принята программа Cloud OS Network (COSN): корпоративные клиенты могут воспользоваться публичными облачными сервисами от Microsoft, услугами местных провайдеров на базе тех же технологий или установить Azure Pack в своем ЦОДе.

Microsoft не просто вкладывает средства и предоставляет технологии, а фактически выступает в роли партнера для российских компаний. «Мы проходим вместе весь путь: от разработки архитектуры решения, детального продумывания и составления сервисного каталога до создания четкой дорожной карты развития сервисов, проработки всех аспектов, связанных с продажей, эксплуатацией, правильным маркетингом услуг — все делаем в тесной связке», — уверяет Олег Коверзнев.

В результате такие сервисы для бизнеса, как Azure, Office 365, Dynamics CRM Online (точнее, их функциональные аналоги), станут доступны из ЦОДов российских сервис-провайдеров. На данный момент в программе участвуют семь российских партнеров: «Крок», «Облакотека», «Ростелеком», «Электронная Москва», DataLine, Infobox, Softline.

Подход к реализация COSN Russia отличается от принятого в других странах более полным учетом особенностей местного — российского — рынка. Так, если в рамках глобального COSN предполагается предоставление только сервиса IaaS (аналог Azure), то в COSN Russia к нему добавлены Business Productivity (аналог Office 365) и Hosted Dynamics CRM (Dynamics CRM Online). «Это уникальное для Microsoft решение по созданию отдельной организационной структуры, работающей по принципу проектного офиса, принято именно исходя из особенностей сложившейся в России ситуации, — поясняет Олег Коверзнев. — В системном и плотном графике мы работаем с партнерами по модернизации имеющихся облачных сервисов и созданию новых, по выявлению слабых мест, когда выясняется, почему их сервис не пользуется тем спросом, которого заслуживает, как сотрудники компании взаимодействуют в процессе продажи этих услуг и т. д.».

Мастер Йода рекомендует:  Таймтрекинг стоит ли вести учёт рабочего времени программиста и если да, то как

Причины расширения программы для России связаны в том числе с тем, что продвижение двух последних сервисов сдерживается такими факторами, как запрет на хранение персональных данных за рубежом. Даже безотносительно к закону о персональных данных некоторые заказчики не готовы хранить электронные сообщения на американских серверах при использовании Office 365. Что уж говорить о системе взаимоотношений с клиентами, в которой накапливаются персональные данные о клиентах. Помимо расширения перечня сервисов, был устранен и ряд имевшихся в них недостатков. Так, в случае Office 365, поясняет Кирилл Котляренко, для использования коммуникационных средств на базе Lync фактически было необходимо установить у себя «свой маленький Lync», что никак не согласуется с облачным подходом, когда все необходимые сервисы предоставляются из облака. В случае COSN Russia сервис Business Productivity включает в себя телефонию из облака.

На момент презентации COSN Russia на форуме «МИР ЦОД – 2015» было доступно пять сервисов. Два из них предоставляются «Ростелекомом»: «Виртульный ЦОД» (IaaS) и «Виртуальный офис» (Business Productivity). Кроме того, услугу «Инфраструктура как сервис» предлагают Softline («Виртуальный дата-центр») и «Облакотека» (AzuRus), а Business Productivity — компания Infobox («Офис 24»). Еще 12 сервисов планируется запустить до 1 сентября 2015 года. Если услуги IaaS и Business Productivity будут предлагать все партнеры, то Dynamics CRM — лишь некоторые. Как можно видеть, названия услуг различаются. «Мы не хотим получить сеть одинаковых облачных платформ. С каждым партнером мы прорабатываем его позиционирование на рынке облачных услуг, чтобы было понятно, чем, например, облако «Крок» отличается от облака Dataline», — объясняет Олег Коверзнев. Во внимание принимаются такие особенности, как географическое расположение ЦОДа, имеющиеся каналы, вычислительные платформы, предоставляемые SLA, схемы ценообразования. Задача состоит в том, чтобы дать конечному заказчику возможность выбора оптимального сервиса под конкретную задачу, которую можно вынести в облако.

В Microsoft надеются, что своими усилиями они помогут партнерам развить бизнес до объемов, характерных для схожих по условиям рынков. В условиях, когда российские производители получают определенные преференции перед международными игроками, для отечественных провайдеров появляется уникальный шанс расширить свой облачный бизнес и достичь серьезных оборотов — в десятки миллионов долларов (против нынешних сотен тысяч, в лучшем случае, у крупнейших из игроков). «Потенциал развития облачных услуг достаточно большой, — уверен Олег Коверзнев. — В этом плане мы ничем не хуже Китая, Бразилии или ЮАР».

Сравнение функционала Azure и COSN Russia

ЧТО ПРЕДПОЧЕСТЬ: КОЛОКЕЙШН ИЛИ ОБЛАКО?

Выбор услуг сервис-провайдеров достаточно широк — как по разнообразию сервисов, так и по их надежности и стоимости. Однако до сих пор немало предприятий отказываются от них по экономическим причинам. Как показало исследование «Облачные сервисы в России: спрос и предложение», которое провели OSP Data и «Журнал сетевых решений/LAN», в малых и средних компаниях — а именно они являются целевой аудиторией для публичных облачных сервисов — число недовольных текущими тарифами составляет около 40% (это второй по популярности аргумент после опасений относительно безопасности и надежности использования сервисов).

«Когда начнется снижение цен?» — так звучал вопрос из зала во время заключительной дискуссии секции «ИТ-инфраструктура и облачные сервисы». В текущей экономической ситуации такое вряд ли возможно — лишь 4% из числа опрошенных провайдеров заявили о планах сократить стоимость услуг до конца 2015 года. В лучшем случае какое-то время цены будут оставаться на прежнем уровне — о подобном намерении заявили 56% провайдеров. Однако это не означает, что обращение к облачным услугам менее выгодно, чем, например, размещение оборудования в ЦОДе провайдера. К тому же качество и набор услуг на рынке различаются, чем объясняется разница в ценообразовании.

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

В соответствии с приведенными Игорем Дроздовым расчетами, стоимость собственного четырехъядерного сервера с массивом RA >по кредитам и за аренду обойдется в 260 евро в месяц (на трехлетний период), тогда как ежемесячный платеж за сопоставимый виртуальный сервер (процессор 8 ГГц, оперативная память 8 Гбайт, дисковая емкость SAS 100 Гбайт) окажется даже чуть ниже — 240 евро. При этом за названную цену заказчик получает резервирование ресурсов, средства мониторинга и диагностики, добавление ресурсов без простоя и т. д.


Облако LinxСloud, на базе которого предоставляются виртуальные серверы, построено на платформе FlexРod, что позволяет реализовать очень гибкое решение. Услуги по модели IaaS пользователь получает в виде виртуального ЦОДа, в котором он может производить настройку новых ВМ, развертывать из имеющихся образов старые ВМ, задавать жизненные циклы ВМ, создавать сети, МСЭ, VPN — все с помощью единого интерфейса VMware. Облачная платформа работает в режиме высокой доступности: на каждые 7 блейдов Cisco UCS приходится один резервный. В случае выхода вычислительного модуля из строя, VMware автоматически перераспределяет нагрузку на рабочий модуль. СХД имеет резервируемые контроллеры, внутренние каналы резервируются так же, как и подключения к Интернету. ЦОД, где размещается облачная платформа, соответствует требованиям Tier III.

Благодаря переносу ERP-системы в облако, Inventive Retail Group, управляющей компании сети монотрендовых магазинов Apple, Samsung, Sony и др., удалось сократить расходы на ИТ на 20%

ERP-СИСТЕМА В ОБЛАКЕ

Выбор облачного провайдера — дело весьма непростое и ответственное, особенно в случае переноса в облако критически важных для бизнеса приложений. Многие называют себя облачными провайдерами, но требованиям заказчика отвечают не все. При выборе провайдера облачных услуг управляющая компании сети брендовых магазинов Inventive Retail Group для размещения системы ERP тщательно исследовала все аспекты деятельности провайдера: обеспечение информационной безопасности, качество процессов оказания услуг, надежность и финансовую ответственность, а также обязательное наличие сертификации от SAP, поскольку ИТ-инфраструктура должна была соответствовать многочисленным требованиям SAP. Как нетрудно догадаться, подходящих предложений нашлось немного.

Inventive Retail Group специализируется на управлении сетями монобрендовых магазинов. Компания сотрудничает с такими известными производителями, как Apple (re:Store), Nike, Lego, Samsung, Sony. Прирост бизнеса составлял 40% в год. В результате в 2012 году ERP-система перестала соответствовать его масштабам — точнее, имеющаяся инфраструктура оказалась не в состоянии обеспечить ее надлежащее функционирование. Нужны были технологические изменения. Как отметил Евгений Бахин, директор по информационным технологиям Inventive Retail Group, прежде чем обратиться к облачному провайдеру, специалисты просчитали различные варианты решения, в том числе и организацию собственного ЦОДа — даже разработали модель расходов. Процедура эта непростая, поскольку не всё поддается учету.

Как оказалось, обращение к услугам облачного провайдера на 20% дешевле, чем содержание собственной инфраструктуры (за трехлетний период). «Если учесть энергоснабжение, стоимость специалистов, аренду площади, которую оборудование занимает, то пользоваться услугами коммерческого дата-центра выгоднее, — поясняет Евгений Бахин. — Кроме того, мы избавляем себя от рисков, связанных с содержанием собственных специалистов: ими нужно управлять, кормить их, поить, они увольняются, меняются и т. д. Это те риски, которые не хотелось бы брать на себя». При этом он отмечает, что у облачного решения немало других преимуществ: оперативное развертывание и масштабирование вычислительной среды, оплата по фактическому потреблению вычислительных мощностей, снижение рисков ошибок в планировании инфраструктуры, доступность из всех регионов, отказоустойчивость, обслуживание и поддержка.

Одно из важных требований — масштабируемость решения. Поскольку бизнес интенсивно развивался, надо было убедиться в том, что провайдер всегда сможет предоставить необходимые мощности и на короткий срок (в пиковые периоды нагрузки), и на длительный период (при расширении масштабов деятельности компании). «Мы должны были быть уверены в том, что в какой-то момент провайдер не скажет, что закончились стойки и серверы либо производительность дисковых подсистем достигла своего предела, и что нам не придется снова куда-то переносить ERP-систему», — рассказывает Василий Аникушин.

Как отмечалось, при выборе КЦОДа ключевым требованием стали опыт и экспертиза в поддержке SAP, а также системы управления базами данных (вся информация хранилась в СУБД Oracle). Провайдер должен был предоставить общий контракт на аренду виртуальных мощностей и поддержку самой системы, чтобы ответственность возлагалась только на одного исполнителя. Иначе, как опасался Евгений Бахин, в случае сбоя найти виновного окажется очень трудно. В качестве провайдера был выбран OnCloud.ru, поскольку он обеспечивал соответствие архитектуры потребностям бизнеса, имел сертификацию SAP, обладал статусом Certified Provider of Cloud Services, предоставлял SLA, обеспечивающее нужный уровень доступности инфраструктурных сервисов.

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

Быстрее, сильнее, экономичнее

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

Такие актуальные ИТ-задачи, как внедрение частного облака, повышение загруженности ресурсов и снижение операционных расходов, решаются только комплексно. Например, достигнутое в последние полвека повышение производительности вычислительных систем было бы невозможно без улучшения их энергоэффективности. По данным компании Intel, с момента появления в 1971 году первого Intel 4004 энергоэффективность выпускаемых ею микропроцессоров улучшилась на пять порядков — в 90 тыс. раз! Если бы она вдруг осталась на прежнем уровне, земной энергетике оказалось бы не под силу обеспечить питание ЦОДов. «Intel всегда пропагандировала комплексный подход к решению проблем, — подчеркивает Сергей Жуковский, инженер по продажам и применению продукции Intel в России. — В частности, управляемое выделение ресурсов в зависимости от требований приложений».

В первую очередь это касается, конечно, вычислительных ресурсов. Утверждается, что до 75% всего инсталлированного серверного оборудования как в мире, так и в России оснащается процессорами из семейства Xeon e5. На базе недавно выпущенного ЦПУ Intel Xeon E5-2600v3 не только созданы двухпроцессорные серверы, которым принадлежит множество рекордов по производительности, но и самый энергоэффективный на данный момент сервер. Улучшение энергоэффективности достигается за счет применения технологии Per Core P-States (PCPS), благодаря которой при изменении нагрузки процессора не приходится одновременно повышать или понижать частоту всех ядер — это можно делать для любого из них. В результате, по сравнению с предыдущим поколением, энергопотребление удается снизить на 24%.

Помимо процессоров, Intel предлагает и другие необходимые компоненты для построения эффективного ЦОДа, в частности твердотельные накопители и контроллеры Ethernet. SSD выпускаются в различных форм-факторах: в корпусе 2,5″ и 1,8″, а также в виде плат PCI Express, mSATA и M.2/NGFF. С переходом на шину PCI Express применение последних моделей накопителей SSD позволяет увеличить пропускную способность процессора в 6 раз. 10- и 40-гигабитные адаптеры Ethernet тоже поставляются в разных форм-факторах. Применяемая в них технология Intel Ethernet Flow Director позволяет связать обработку пакетов с приложениями, для которых эти пакеты предназначены. При ее использовании не происходит переключение контекста между разными ядрами, благодаря чему сокращаются задержки.

Разгрузить процессоры от выполнения других ресурсоемких задач, таких как сжатие данных, шифрование и прямая коррекция ошибок, позволяет применение решений американской компании AHA Products Group, которая специализируется на выпуске соответствующих аппаратных ускорителей. Компания была основана в 1988 году и занималась задачами ускорения спутниковой связи (по заказу NASA). В ее послужном списке — первая в мире микросхема для реализации кода Рида — Соломона (1989), первая контентно-адресуемая память CAM в сжатии данных (1992), первая микросхема для сжатия данных GZIP (2006). Ускорители AHA в своих продуктах используют EMC, NEC, Riverbed, Radware и другие компании.

AHA Group выпускает аппаратные решения (платы сжатия) с производительностью 10, 20, 40 и 80 Гбит/с (в ее линейке есть и менее производительные платы сжатия на 2,5 и 5 Гбит/с, но они доступны только по заказу). Как заявляет Сергей Вдовин, бренд-менеджер компании «Созвездие», российского партнера AHA Group, одна плата на 10 Гбит/с способна заменить 20 ядер процессоров Intel, если сжатие осуществляется в соответствии с открытым стандартным алгоритмом GZIP. Согласно приведенным им данным, одно ядро такого процессора, как Intel Core Xeon E5-2680 с частотой 2,7 ГГц, может выполнять сжатие со скоростью 0,49 Гбит/с, то есть для сжатия на уровне 10 Гбит/с потребуется 20 ядер. Для достижения требуемой быстроты обработки в платах используются микросхемы AHA 3610 IC с производительностью 2,5 Гбит/с.

При использовании ускорителей AHA с увеличением размеров сжимаемых блоков данных загрузка центральных процессоров падает практически до нуля. Применение ускорителей сжатия позволяет не только разгрузить процессор, но и уменьшить число необходимых серверов. Так, в центре обработки данных Bloomberg, где было установлено около 80 стоек с серверами для хранилищ данных, за счет установки аппаратных ускорителей AHA количество стоек удалось сократить вчетверо.

Помимо плат для ускорения сжатия данных AHA Group выпускает акселераторы шифрования и микросхемы прямой коррекции ошибок (Forward Error Correction, FEC). Один криптоускоритель AHA602 с номинальной производительностью 12 Гбит/с способен заменить 90 процессорных ядер при выполнении шифрования с 2048-разрядным ключом. Применение микросхем FEC позволяет снизить мощность передатчиков и увеличить пропускную способность.

Быстрее и мощнее, но за меньшие деньги — вот требование к современным вычислительным средствам. И, как показали выступления в секции «ИТ-инфраструктура и облачные сервисы», производители стремятся им соответствовать.

ОБЛАЧНЫЕ ПЕРСПЕКТИВЫ

В том, что российский рынок облачных услуг отстает от американского и европейского, нет ничего удивительного. Основными целевыми потребителями облачных сервисов являются компании малого и среднего бизнеса — сегмент, который в России не столь развит, как в западных странах, да и переживает сейчас не лучшие времена. Помимо объективных факторов, мешают и субъективные — например, предубеждение относительно надежности и безопасности облачных сервисов. Вместе с тем в таком отношении нет ничего специфического. Как пояснил во время завершающей дискуссии Кирилл Котляренко, такое же опасение имелось и у представителей американского бизнеса, когда Microsoft вышла со своим сервисом Azure на рынок США. На тот момент предложение значительно опережало потребности: облачных технологий остерегались, и никто не хотел на них переходить. Однако спустя три года ситуация кардинально поменялась: на развитых рынках люди все реже предпочитают покупать серверы и прибегать к услугам колокейшн, а все чаще пользуются облачными сервисами (не только Azure).

Российский рынок, несмотря на кажущееся обилие услуг, перенасыщен предложениями низкоуровневых сервисов по размещению оборудования клиента в ЦОДе провайдера, поскольку именно они пользуются до сих наибольшим спросом. «На рынке очень много предложений по аренде серверов, и они опережают спрос, поэтому мы не собираемся этим заниматься», — объясняет Василий Белов из «Электронной Москвы». Соответственно, провайдеры ищут наиболее выгодное применение для имеющихся площадей и ресурсов. «Почему акцент делается на облачных сервисах? Потому что это перспективная технология не только для клиентов, но и для нас как сервис-провайдеров, — объясняет Игорь Дроздов. — Это позволяет использовать мощности наших ЦОДов наиболее эффективно. Перераспределяя нагрузку между модулями в своем облачном кластере, мы можем оптимизировать энергопотребление, место, которое в нашем ЦОДе занимают клиенты и их ИТ-инфраструктура, и т. д.».

Выгоды использования виртуального сервера, предоставленного облачным провайдером, по сравнению с размещением физического сервера (на примере услуг Linxdatacenter)

Провайдеры отмечают растущий спрос на облачные сервисы, причем самые разнообразные — от базовых IaaS до PaaS и SaaS. Игорь Дроздов выразил уверенность в том, что акцент будет смещаться на облачную инфраструктуру ввиду ее многочисленных преимуществ. «Электронная Москва», основным заказчиком которой является московское правительство, пытается найти свою нишу на рынке SMB. «Мы стали партнерами Microsoft (по COSN. — Прим. ред.), развернули инфраструктуру в собственном ЦОДе и ищем нишу, чтобы предлагать услуги малым и средним предприятиям (о крупных говорить еще рано), — делится планами Василий Белов. — Тестовый пилотный проект направлен на взаимодействие со столичными школами: фактически мы переводим рабочие места в наше облако. Думается, этот процесс будет масштабироваться и спрос на него появится, ведь это решение обеспечивает определенные финансовые преимущества и гибкость».

Облачные сервисы постепенно становятся все более востребованными во многих отраслях — легче сказать, где они не используются. Прежде всего это касается областей, на которые распространяется жесткое законодательное регулирование, — здравоохранение и финансы. В «Электронной Москве» отмечают даже снижение спроса со стороны банков, объясняя это тем, что ИТ-службы банков как наиболее продвинутые были среди первых потребителей и тестировщиков облачных сервисов — кто хотел и мог, уже воспользовался ими. Теперь пришла пора тех, кто следует в кильватере технологических новшеств, и с их стороны спрос увеличивается.

Дмитрий Ганьжа — главный редактор «Журнала сетевых решений/LAN». С ним можно связаться по адресу: diga@lanmag.ru.

Поделитесь материалом с коллегами и друзьями

Перенос ИТ-инфраструктуры в облако

Перенос ИТ-инфраструктуры в облако

Любая компания, государственная она или частная, ориентируется на оптимизацию затрат, в том числе на ИТ. Одним из способов оптимизации является переход в облако.

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

Журнал «Системный администратор» провел заочный круглый стол. В ходе дискуссии ИТ-специалисты рассказали о том, как их компании осуществляли перевод ИТ-сервисов в облака.

В комментариях экспертов «СА» даны анализ ситуации на российском рынке облачных услуг, а также практические советы по наиболее важным типовым вопросам

На вопросы «Системного администратора» отвечали:

  • Александр Максимов, начальник отдела ИТ, ООО СК СЕРВИСРЕЗЕРВ, г. Ковров
  • Константин Феоктистов, главный архитектор проектов ЗАО НИП «Информзащита», г. Москва
  • Тамерлан Набиев, системный администратор, ООО «СТАЛФОРМ Инжиниринг», г. Москва
  • Денис Романов, ИТ-специалист, KM, г. Казань

Подготовка к переходу

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

АЛЕКСАНДР МАКСИМОВ, начальник отдела ИТ, ООО СК СЕРВИСРЕЗЕРВ, г. Ковров

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

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

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

КОНСТАНТИН ФЕОКТИСТОВ, главный архитектор проектов ЗАО НИП «Информзащита», г. Москва

Критерии для перехода различны и, как правило, зависят от целей, преследуемых компанией. На заре появления облачных технологий считалось, что основным критерием, побуждающим компании переходить в облака, является отсутствие капитальных затрат при создании и поддержании ИС организации. Многолетняя практика эксплуатации облаков показала иные результаты. В настоящее время преобладает тезис, определяющий «быстроту изменений», которой позволяет достичь использования облачной модели услуг. Чтобы запустить новый сервис компании, не обязательно покупать новые серверы и заботиться об их размещении в ЦОД – достаточно на период пилотирования решения и подтверждения концепции арендовать необходимые мощности в облаке за существенно меньшие деньги, чем покупка новых компонентов инфраструктуры.

Поэтому, с моей точки зрения, сегодня основными критериями перехода в публичное облако для компании являются:

  • взрывной рост, напрямую связанный с необходимостью быстрого ввода в эксплуатацию новых сервисов;
  • активное развитие информационных систем компании, требующее пилотирования, тестирования и разработки с использованием новых технологий (например, сервисов машинного обучения);
  • наличие стратегии обновления архитектуры ИС и состава предоставляемых пользователям сервисов, требующих пересмотра вопросов динамического масштабирования производительности;
  • желание компании снизить затраты на ИТ, побуждающее заменять отдельные корпоративные сервисы на их «условно-бесплатные» аналоги на основе облачных решений.

Если касаться вопроса перехода компании от классической модели инфраструктуры к модели использования частного облака на основе собственной инфраструктуры, то к указанным выше критериям (кроме сокращения затрат) добавляются еще:

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

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

  • механизм быстрой оценки стоимости использования ИТ-сервисов каждым потребителем;
  • возможность оперативно перестраивать состав доступных для эксплуатации ресурсов;
  • быстрая подготовка (провижининг) ресурсов под требования клиентов;
  • анализ статистики использования и прогнозирование потребности ресурсов облака в перспективе.

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

ТАМЕРЛАН НАБИЕВ, системный администратор, ООО «СТАЛФОРМ Инжиниринг», г. Москва

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

ДЕНИС РОМАНОВ, ИТ-специалист, KM, г. Казань

Основные критерии для перехода в облако: удобство управления + безопасность.

Рубрика: Заочный круглый стол

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

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

Капитальные затраты на ИТ стремятся к нулю, а значит, можно финансы пустить на более важные вещи, чем серверы и программы. А ежемесячный или квартальный платеж оказывается подъемным расходом. Готовый набор стандартных услуг в виде офиса, почты и других мелочей покрывает большинство потребностей. Ну и самый большой плюс – платить ровно за то, что используешь, и, когда какой-либо из проектов закрылся, смело удалить набор ВМ и начать платить меньше.

С точки зрения опытного потребителя облачных решений хочется говорить о том, что реально болит, – о недостатках. Интерфейс и скорость решения обращений.

Большинство знакомых мне интерфейсов взаимодействия пользователя с облачным решением производят двоякое впечатление. Урезанные и кастомизированные облачными провайдерами «донельзя» системы управления пулом ресурсов Cisco UCS Director и VMware vCloud Director – главная претензия. Процессы создания и прямого вмешательства в работу развернутых ВМ по архитектуре IaaS вызывают замедление исполнения и субъективный набор неприятных эмоций у специалиста, привыкшего в два клика выполнять такую же операцию в своей виртуальной среде.

Риск неадекватной скорости выполнения инцидентов, даже в рамках прописанных SLA, является вторым весомым недостатком. Намертво зависшая ВМ, будучи размещенной в облаке, может быть перезапущена только специалистом провайдера, а заявка на такой перезапуск может обрабатываться дольше, чем «бизнес ожидания». Еще хуже, если повисла совсем чужая ВМ, которая потребовала срочного перезапуска всего хоста, и пострадала часть вашей инфраструктуры.

Для большинства потребителей еще долгие годы останется актуальным самое гибкое решение – гибридный вариант, симбиоз собственной инфраструктуры и облачной, где для создания высокоэффективной среды открываются отличные возможности. Например, для архитектуры почтовых серверов Exchange можно использовать встроенную связку с Office365 для размещения, как вариант, архивов почтовых ящиков или небольших ящиков разъездных работников. А в схеме IaaS можно создать кластер DAG и разместить один сервер у себя, а второй – в облаке и диверсифицировать риски отказа за счет геораспределения.

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

Как правильно выбрать провайдера услуг? Какие критерии выбора облачного провайдера вы считаете важными? Как правильно выбрать тариф? Какие инструменты использовать для оценки производительности ресурсов провайдера?

АЛЕКСАНДР МАКСИМОВ

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

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

Производительность ресурсов провайдера правильно оценивать только субъективно: «достаточная» или «недостаточная». Любая попытка оценивать количественно с помощью синтетического показателя приведет к тому, что умные люди в организации провайдера с помощью инструментов оптимизации докажут, что синтетические показатели в норме, но для вашего бизнеса от этого ничего не улучшится. Нужно быть в нормальном человеческом контакте со службой поддержки и добиваться, чтобы «сервис отвечал», а не «пинг был менее. ».

КОНСТАНТИН ФЕОКТИСТОВ

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


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

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

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

Например, публикация самооценки выполнения, а еще лучше сертификация на соответствие требованиям Security, Trust & Assurance Registry (STAR) международной организации Cloud Security Alliance (CSA), является хорошей практикой для западных и международных компаний.

ТАМЕРЛАН НАБИЕВ

Основные критерии выбора облачного провайдера: известность, стабильность, надежность, безопасность.

Тариф и производительность необходимо выбирать с некоторым запасом. Оценка будет зависеть от отзывов пользователей.

ДЕНИС РОМАНОВ

Основные критерии выбора провайдера: цена\качество + управляемость.

«С точки зрения опытного потребителя облачных решений хочется говорить о том, что реально болит, – о недостатках» Экспертное мнение
СЕРГЕЙ БАРАМБА,
заместитель ИТ-директора ООО «БФТ»

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

  • сокращение расходов на ИТ;
  • повышение надежности и безопасности;
  • расширенные возможности доступа, возможности поддержки сложных систем без привлечения собственных специалистов;
  • оптимизация деятельности ИТ-службы и т.п.

Облачные решения подходят практически для любых предприятий, для огромного, если не сказать, полного спектра их задач.

Выбор – внедрять или не внедрять – лежит в большей степени в коммерческой составляющей, нежели в какой-либо иной. (Здесь априори я не рассматриваю ограничения регуляторов для компаний госсектора.)

Принимая решение о переходе в облако, в первую очередь следует оценить TCO и сравнить его с TCO классической среды. Делая подобный расчет, не стоит забывать об оценке стоимости миграции. Если цифры окажутся в пользу облачного решения, то переход в облако, очевидно, оправдан. Следует понимать, что облачные технологии предлагают несколько подходов к решению, наиболее популярные: SaaS, IaaS, PaaS. Разумеется, может быть использован гибридный вариант, сочетающий в себе несколько технологий. Соответственно, процесс расчета TCO получается не таким простым, как может показаться на первый взгляд, и будет состоять из нескольких итераций.

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

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

Серьезное внимание следует уделить вопросам безопасности и доступности облачной среды. Насколько она защищена от внешних воздействий, например от DDoS-атак? Предлагается ли такой сервис со стороны поставщика решения или это становится проблемой самой компании?

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

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

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

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

Публичное или частное облако?

Что безопасней – публичное или приватное облако с вашей точки зрения? Готовы ли вы довериться публичному облаку? Что именно вы готовы передать в облачную инфраструктуру?

АЛЕКСАНДР МАКСИМОВ

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

А что всегда предлагают отдать в облако? Самые примитивные задачи типа электронной почты. Электронная почта – самый старинный, хорошо изученный и примитивно простой инструмент. Создание и содержание почтового сервера – задача, доступная каждому школьнику, который только-только научился читать и писать (потому что настолько хорошо написаны и за долгие годы доведены до совершенства почтовые программы, например sendmail – настолько примитивная в настройке и обслуживании программа, что сейчас ее перестали считать модной).

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

Поэтому я лично не готов в бизнесе никому «довериться» (о каком доверии в бизнесе вообще может идти речь? – я обанкрочусь, а маркетологи облака будут точно так же продвигать решения) и, поскольку пока хватает собственного интеллекта для решения задач, не могу придумать задачи, которые не жалко отдать в облако.

КОНСТАНТИН ФЕОКТИСТОВ

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

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

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

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

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

ТАМЕРЛАН НАБИЕВ

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

«Принимая решение о переходе в облако, в первую очередь следует оценить TCO и сравнить его с TCO классической среды» Экспертное мнение
ЛЕОНИД ШАПИРО,
архитектор ИТ-систем, MVP, MCT, MCSE, MCITP:EA, MCSE:S, MCSE:M

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

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

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

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

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

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

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

Что безопасней – публичное или приватное облако? Готовы ли вы довериться публичному облаку? Что именно вы готовы передать в облачную инфраструктуру?

АЛЕКСАНДР МАКСИМОВ

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

Оценка компетентности сотрудников облачных провайдеров

Как защититься от недобросовестного персонала облачного провайдера? Какие технологии и приемы лучше использовать? Как я могу оценить профессионализм персонала облачного провайдера?

АЛЕКСАНДР МАКСИМОВ

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

Сервисы и миграция

SaaS, PaaS и IaaS. Какие сервисы лучше вынести в облако в первую очередь и какую модель использовать? Рассматриваете ли вы гибридные решения для постепенного перехода в облачную среду, если планируете подобную миграцию?

АЛЕКСАНДР МАКСИМОВ

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

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

Это естественный процесс укрупнения и монополизации при капитализме. В ИТ все процессы развиваются гораздо быстрее, чем в обычной жизни. Перенос производства из США в Китай привел к полной деиндустриализации США за двадцать лет, а перенос бизнес-процессов компаний в облака приведет к монополизации видов бизнеса существенно быстрее. Уже сейчас на рынке онлайн-продаж мы видим «лидеров», а спустя несколько лет «останется только один», причем потребителям услуг от этого хуже не станет.

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

КОНСТАНТИН ФЕОКТИСТОВ

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

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

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

Если говорить о моделях использования, то имеет смысл различать модель разворачивания (deployment model), о которой мы уже говорили много раз ранее, и модель обслуживания (service model), представленную базовыми IaaS, PaaS иSaaS. В последнем случае, если компания не собирается самостоятельно разрабатывать и поддерживать облачное приложение, а лишь использовать его функции, используется аренда по модели SaaS.

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

Если компания планирует разрабатывать приложение или систему на базе сервисов, предоставляемых поставщиками публичных облаков (AWS, MS Azure, IBM Bluemix), или запускать код приложения в некоторой среде исполнения (Herocu, Jelastic, Google App Engine и т.п.), то этот путь лежит через модель PaaS.

Существует еще преогромное множество всевозможнейших моделей оказания облачных услуг, помещающихся под акронимом АaaS (Аnything as a Service): БД, резервное копирование, аппаратные средства, сети и т.д., «как сервис». В том числе я хотел бы выделить оказание услуг по защите информации, «как сервис», получившее в профессиональной среде «загадочное» название SECaaS – Security as a Service. В это понятие входит большой объем услуг, связанных с обеспечением безопасности информационных систем, которые могут предоставляться поставщиками или брокерами облачных услуг самостоятельно или совместно с базовыми услугами, например в составе публичного IaaS.

ТАМЕРЛАН НАБИЕВ

В первую очередь в облако лучше перенести средства коммуникации (IP-телефония, корпоративный портал) и офисные приложения. Во вторую очередь системы коллективной работы над проектами, CRM, 1С.

ДЕНИС РОМАНОВ

Частное облако для среднего, публичные для малого бизнесов.

«Облачные сервисы позволяют начинающим компаниям получить необходимые инструменты и возможности» Экспертное мнение
АНДРЕЙ ТАМБОВСКИЙ,
директор по технологиям «ФОРС Дистрибуция»

Если говорить о бизнесе в целом, то проблема переноса ИТ в облако согласно тенденциям развития отрасли заключается не в «стоит ли?», а в вопросе «когда?». Нарастающая мобилизация, BYOD и другие технологии, связанные с облачными сервисами, обеспечивают своим пользователям конкурентные преимущества. Поэтому уже сейчас, не используя облако, бизнес несет потери.


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

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

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

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

Характерным для облака можно назвать лишь взлом платформы провайдера облачных услуг. Поэтому нередко при переходе в облако основными проблемами, обсуждаемыми провайдером и бизнесом, становятся интеграция своей инфраструктуры в облако, независимость в плане миграции и переноса данных, обеспечение требований регуляторов, защита информации и т.п. Надо сказать, что многие поставщики облачных услуг успешно справились с реализацией обеспечения требований №152-ФЗ «О персональных данных».

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

Резервное копирование данных в облаке. Как правильно его реализовать и обезопасить свою информацию?

АЛЕКСАНДР МАКСИМОВ

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

ТАМЕРЛАН НАБИЕВ

Облачный провайдер должен предоставлять возможность делать свою резервную копию. И иметь механизм аварийного восстановления данных на локальный сервер.

ДЕНИС РОМАНОВ

Полное копирование виртуальных машин + копирование изменяемых данных приложений.

Как переход в облако меняет роль внутренней ИТ-службы и службы безопасности? Риски для ИТ-специалистов при миграции корпоративных инфраструктур в облако, есть ли они? Если да, то как им противостоять?

АЛЕКСАНДР МАКСИМОВ

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

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

КОНСТАНТИН ФЕОКТИСТОВ

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

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

ТАМЕРЛАН НАБИЕВ

Работа ИТ-нацелена больше на поддержку бизнес-процессов. Нет необходимости в большом штате ИТ-специалистов. Требования к уровню подготовленности ИТ-специалистов уменьшаются.

Переезд в облако: так что в итоге переносить, а что оставлять?

Переезд в облако: так что в итоге переносить, а что оставлять?

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

Согласно исследованию The Modern Infrastructure Insight Report , 57 % организаций прогнозируют увеличение расходов на облачные сервисы в течение следующих двух лет. Практически каждое предприятие считает ту или иную форму облачных услуг неотъемлемой частью своей IT-стратегии. Ожидается, что к 2020 году расходы на облака превысят $270 млрд. К этому времени облачные вычисления должны значительно сократить затраты, связанные со строительством или арендой мощностей центров обработки данных.

Зачем переносить бизнес-процессы в облака

Когда вы только начинали свой бизнес, все процессы укладывались в рамки возможностей Excel. Но со временем, когда предприятие начало генерировать много данных, пришло время задуматься об их безопасном хранении, резервном копировании и оптимизации затрат. Возникли вопросы: устанавливать ли сервер в офисе? Арендовать ли стойку в ЦОДе? Или мигрировать в облака? Еще раз по пунктам.

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

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

Остается вариант номер три: арендовать облачные мощности.

Преимущества переноса бизнеса в облака

Облачное хранение данных позволяет значительно сократить расходы. К примеру, корпорация General Electric, которая в данный момент занимается перемещением в облака своих IT-систем, уже более чем в десять раз сократила расходы на обслуживание своих нефтегазовых приложений и теперь тратит на это $6000 в год вместо прежних $65 000.

Еще одно преимущество миграции в облака — сокращение капитальных затрат, вследствие чего повышается эффективность работы организации. Компании, вставшие на «облачный» путь, заявляют о 30-40-процентном уменьшении CAPEX. При этом выгода в сравнении с установкой собственного сервера очевидна: облако окупает себя в среднем за период от 12 до 18 месяцев.

Сравнение облачной модели доставки услуг с традиционной. Источник: данные IBM

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

IDC выделяет следующие виды облачных услуг:

  • Public Cloud — публичное облако — вид услуг, при котором IT-сервисы предоставляются через интернет для свободного использования широкой публикой. Основной плюс: простота настройки и низкая стоимость;
  • Private Cloud — частное облако, инфраструктура, расположенная внутри компании для ее собственных нужд. Создается, например, для обеспечения какого-либо дочернего предприятия сервисом корпоративной почты;
  • Virtual Private Cloud — частная виртуальная сетевая среда, которая располагается внутри публичного облака;
  • Hybrid Cloud — гибридное облако — комбинация нескольких облаков: частных, публичных и общественных. Очень часто в целях безопасности предприятия размещают особо важные приложения в приватном облаке, а остальные в целях экономии работают в публичном.

На что обратить внимание при миграции в облака

Бизнес-задачи

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

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

Право

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

Если вы работаете в банке, некоторые регламенты ЦБ запрещают вообще любую возможность размещения в облаках. Например, все, что содержит банковскую тайну, должно размещаться на оборудовании банка, что часто составляет 90 % от всего объема данных.

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

Безопасность

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

Даже у больших компаний-провайдеров облачных услуг случаются сбои, причиной которых является человеческий фактор . К примеру, 16 мая 2020 года ошибка сотрудника «Яндекса» в сервисе «Яндекс.Облако» привела к удалению части виртуальных машин пользователей. Несмотря на то что «Яндекс» сразу заметил ошибку и остановили удаление, некоторые данные были безвозвратно утеряны.

Как выбрать поставщика?

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

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

Не забудьте заключить SLA (соглашение об уровне качество услуг) с поставщиком: оно должно быть подробным и включать все детальные характеристики, касающиеся работы облачной платформы.

Особенности использования облаков в разных сферах деятельности

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

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

Каким процессам лучше не переезжать в облака?

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

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

Переносим операционные процессы компании в облако

Если вы решили перенести свою базу в 1С облако, нужно выполнить несколько основных шагов.

Шаг 1 – зарегистрироваться в облаке

У вас конечно есть выбор, но лучше зарегистрироваться в нашем облаке. Почему?)

  1. Вы моментально получите бесплатный тестовый доступ на месяц к облачной 1С.
  2. Мы помогаем нашим тестовым клиентам перенести данные. Вы можете обратиться к нашему специалисту с просьбой помочь с выгрузкой загрузкой базы. Он подключится к вашему компьютеру через Teamiewer и сделает все за 15 минут.
  3. Уже и смысла нет читать статью дальше, просто свяжитесь с нами, это будет проще и быстрее)).

Шаг 2 – выгрузить архив базы

Для того, чтобы выгрузить базу, необходимо:

  1. Зайти 1C в Конфигуратор на компьютере, с которого хотите выгрузить базу.
  2. В конфигураторе выбрать в главном меню Администрирование – Выгрузить информационную базу.
  3. В списке слева выбрать папку, куда хотите сохранить базу. Рекомендуем сохранить базу в папку на диске C или D, а не на рабочем столе. Так ее будет проще найти при загрузке. Нажать «Сохранить».
  4. Дождаться окончания выгрузки базы. В окне завершения выгрузки нажать «Ок».

Шаг 3 – загрузить базу

Для того, чтобы загрузить базу, необходимо выполнить похожие шаги, но уже в базе
1С в облаке.

  1. Подключиться к 1С и зайти в нужную базу в режиме Конфигуратор.
  2. В конфигураторе выбрать в главном меню Администрирование – Загрузить информационную базу. Указать в окне диалога путь к базе на локальном компьютере. Например, если база расположена по пути D:\База\1cv8.dt, выберите мышкой справа “D на PC” (вместо PC будет название вашего компьютера). Найдите файл с архивом .dt и нажмите “Открыть”.
  3. В списке слева выбрать папку на компьютере, куда хотите сохранить базу. Рекомендуем сохранить базу в папку на диске C или D, а не на рабочем столе. Так ее будет проще найти при загрузке. Нажать «Сохранить».
  4. После загрузки базы появится информационной сообщение об успешной загрузке. Все, программа переноса 1С в облако выполнена, можно приступать к работе.

Новичкам, которые боятся запутаться в описанном выше процессе, но уверенным в необходимости осуществить перенос 1С в облаке, мы подскажем, как перенести базу. То есть будем руководить каждым шагом или просто возьмем весь процесс на себя. В том, как перенести базу 1С для работы в облаке, разобрались. Посмотрим, что дает аренда облачного пространства сразу и в перспективе.


Что дает перенос 1С в облако?

Программа 1С: Предприятие уже несколько десятилетий является самой популярной в РФ. В последние же годы развитие технологий привело к появлению облачного сервиса, который заметно расширил возможности пользователей данной программы, благодаря идее аутсорсинга ПО. В чем его польза, почему наблюдается обвальный рост желания перенести 1С в облако как у индивидуальных предпринимателей, так и крупных компаний?

  1. Отпадает необходимость приобретать дорогостоящее ПО под определенное количество пользователей. В облаке легко меняется как число пользователей, так и объем места под базу.
  2. Для внедрения программы на предприятии просто указываете число пользователей, тип доступа, получаете файл и приступаете к работе. Это особенно оценят те, кто уже прошел долгое внедрение и споры с приглашенными техническими специалистами.
  3. Обновления не требуют вашего участия, производятся автоматически в удаленном режиме. Плюсы 1С в облаке – специалисты объяснят, как перенести базу и обеспечат ее безотказную работу.
  4. Неважно насколько велика база вашей компании, сколько их у вас. Необходимости увеличивать мощность ПК и докупать сервера не возникнет – информация хранится в другом месте. Вы просто по мере необходимости увеличиваете количество пользователей и баз в личном кабинете.
  5. Любой сотрудник может подключаться к базе с любого устройства, что дает возможность работать удаленно с любой точки мира, где есть интернет. В одной базе круглосуточно могут работать несколько сотрудников.
  6. Исключается потеря информации. Благодаря автоматическому резервному копированию и хранению архива в облаке в любой момент можно вернуться к старым данным.

Отсюда делаем вывод – перенос 1С и работа в облаке с арендой любого количества облачного пространства, это возможность экономить на IT-специалистах, серверах и охране данных, одновременно имея доступ к самому современному ПО с круглосуточной профессиональной поддержкой.

Миграция в облако

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

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

Виды миграции в облако

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

«Большинство рисков безопасности облака присущи и традиционным ИТ-технологиям» Экспертное мнение
ИГОРЬ ШТОМПЕЛЬ,
инженер, системный администратор
Частичная (постепенная) миграция

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

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

Итак, подытожим: в зависимости от размера организации и сложности инфраструктуры определяется, какой вид миграции следует выбрать:

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

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

Примеры миграции в облако

Сегодня можно найти большое количество кейсов, демонстрирующих успешную миграцию ИТ-инфраструктуры в облако IaaS-провайдера. В своих статьях мы часто публикуем истории успеха компаний, клиентов «ИТ-ГРАД», использующих облачные технологии для решения актуальных и востребованных задач. Одни используют облако в качестве дополнительной площадки, где размещены некритичные сервисы, другие – наоборот, полностью переносят инфраструктуру в облако с размещением жизненно важных для компании решений.

Delivery Club, абсолютный лидер российского рынка по заказу доставки еды, является примером компании, осуществившей перенос всех сервисов в облако провайдера. Поскольку заказ еды через интернет является достаточно востребованной услугой, наблюдался постоянный рост нагрузок на сервисы Delivery Club, что требовало быстрой реакции. Миграция в облако решила проблему. Теперь все сервисы компании виртуализированы и полностью отсутствует связка используемых серверов с физическими.

Миграция инфраструктуры компании Delivery Club в облако IaaS-провайдера

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

Автомобильный холдинг «Терра-авто» тоже выполнил последовательную, постепенную миграцию в облако провайдера.

Миграция инфраструктуры компании «Терра-авто» в облако IaaS-провайдера

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

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

Миграция инфраструктуры NETFLIX в облако провайдера

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

Ошибки и подводные камни миграции

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

Ошибка 1. Отсутствие схемы зависимости приложений

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

Пример схемы зависимости приложений

Ошибка 2. Отсутствие плана миграции

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

Ошибка 3. Запуск миграции без предварительных тестов

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

Общепринятая схема миграции в облако

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

Шаг 1. На первом этапе требуется выполнить инвентаризацию существующего ИТ-окружения и определиться с моделью облака.

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

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

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

Шаг 3. План или дорожная карта миграции позволяют контролировать все выполняемые шаги на пути переезда в облако.

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

Шаг 4. После того как выполнены вышеуказанные шаги, можно приступать к процессу миграции, придерживаясь вышеупомянутой стратегии. Если переносимая инфраструктура сложная и разветвленная, следует двигаться поэтапно. Если перенос некоторых сервисов не удается разделить на части, полный переход является единственным вариантом переноса.

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

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

Способы миграции в облако

Существует несколько способов миграции в облако. Какой вариант подойдет именно вам, зависит от ситуации. Это может быть перенос физической ИТ-инфраструктуры в виртуальную среду, перенос локальной виртуальной инфраструктуры в облако, переезд из облака одного поставщика в облако другого провайдера. Ниже рассмотрим возможные варианты миграции более подробно.

Вариант 1: Импорт-экспорт vApp / VM

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

Пример экспорта vApp

Поскольку отдельно взятая ВМ представляет собой набор виртуальных дисков, характеристик и конфигураций, все это возможно экспортировать в файл формата OVF/ OVA (унифицированный формат распространения готовых виртуальных машин), который позже используется для экспорта/импорта на платформу виртуализации VMware vSphere и не только. Таким же способом можно импортировать/экспортировать содержимое vApp.

Вариант 2: vCloud Connector

С помощью инструмента VMware vCloud Connector вы можете объединять облака различного формата и переносить виртуальные машины, vApp в облако хостинг-провайдера и обратно. Для этого необходимо выполнить связку соответствующих инфраструктур друг с другом и, используя интуитивно понятный графический интерфейс, запустить задачу, к примеру, копирования одной или нескольких виртуальных машин в облако поставщика.

Пример копирования ВМ из одного облака в другое, используя vCloud Connector

После успешного выполнения операции следует убедиться в корректности функционирования перенесенной инфраструктуры. Более подробно о работе с VMware vCloud Connector читайте здесь.

Вариант 3: Миграция на уровне сервисов

Миграция на уровне сервисов – еще один из наиболее часто используемых вариантов. Суть метода заключается в создании дублирующего сервиса на стороне хостинг-провайдера и запуска синхронизации с имеющимся сервисом, установленным локально. После того как процедура закончилась успешно, локальный сервис выводится из эксплуатации. Примером выступает миграция Active Directory, где применяется следующий алгоритм:

  • Организуется сетевая связность между локальной инфраструктурой и облаком провайдера.
  • На облачной площадке поставщика разворачивается необходимое количество новых виртуальных машин, в которых настраиваются контроллеры домена AD с до­бавлением их в имеющийся лес.
  • Затем база данных Active Directory реплицируется с работающими контроллерами локальной инфраструктуры в облако.
  • После завершения репликации данных переназначаются мастера ролей операций на облачные контроллеры и убираются роли контроллеров домена с серверов в локальной инфраструктуре.
  • После проверки исправной работы сервисов отключаются учетные записи старых контроллеров, после чего они выводятся из локального использования.

Вариант 4: Конвертация, или «горячее» клонирование

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

При работе с VMware vCenter Converter необходимо выбрать, что будет конвертироваться. Основной метод работы подразумевает конвертирование работающего компьютера или сервера (Powered-on machine), который может быть физическим или виртуальным.


Пример работы с инструментом VMware vCenter Converter

При корректном подключении VMware vCenter Converter понимает, какую операционную систему предстоит мигрировать, определяя при этом диски и разделы, сетевые интерфейсы, оперативную память и процессоры. Эти параметры используются для создания новой виртуальной машины на ESXi-хосте.

Вариант 5: Конвертация, или «холодное» клонирование

Помимо «горячего» клонирования, с помощью VMware vCenter Converter можно выполнять «холодное» клонирование, или офлайн-миграцию с остановкой сервера на время переноса и переустановки сервисов физической машины в виртуальную. При таком варианте клонирования рабочая машина останавливается, создается образ жесткого диска и выполняется конвертация в ВМ. Для серверов Active Directory, баз данных, почтовых серверов рекомендуется использовать такой вид клонирования.

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

Вариант 6: Установка с нуля

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

При развертывании инфраструктуры в облаке на базе VMware предоставляется доступ к консоли vCloud Director, в которой формируется инфраструктура согласно требованиям проекта. Используя интуитивно понятный интерфейс, здесь создаются виртуальные машины, производится настройка сетевых параметров, конфигурация необходимых сервисов и другое.

Заключение

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

3 причины, почему бизнесу стоит переносить it-инфраструктуру в облако

3 причины, почему бизнесу стоит переносить IT-инфраструктуру в облако

Согласно исследованию Forrester, в 2020 году рынок облачных сервисов в России вырос на 24%. Российские провайдеры облачных услуг (Cloud Service Providers или CSP), с которыми нам удалось пообщаться, сходятся на еще более впечатляющих темпах роста рынка: 30-40% в год.

Растущий спрос отражает стремление бизнес- и технических лидеров в нашей стране оптимизировать IT-инфраструктуру управляемых ими компаний:

  • Снизить стоимость владения инфраструктурой
  • Упростить управление вычислительными ресурсами и доступами к ним
  • Увеличить скорость вывода продуктов и услуг на рынок
  • Сосредоточить ресурсы компании на ее собственных конкурентных преимуществах

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

Ключевые драйверы рынка

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

Данные помогают бизнесу быть более конкурентным и зачастую становятся его основой.

Как следствие, сегодня растет потребность к хранению и обработке данных и это происходит с катастрофической скоростью: за последние два года были сгенерированы 90% всех хранимых данных.[1]
Обратите внимание

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

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

Причина 1. Time-to-market (скорость вывода продуктов и услуг на рынок)

Подход компаний к построению IT-инфраструктуры сильно изменился как в мире, так и в России. Еще 20 лет назад цикл планирования, закупки и настройки собственного серверного, сетевого и инженерного оборудования занимал месяцы и годы. Инфраструктурный цикл также страдал от необходимости строительства собственных серверных помещений.

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

Проведенный Forbes опрос генеральных директоров по всему миру показал, что 72% из них полагают, что следующие 3 года станут более трансформационными для их индустрии, чем последние 50 лет.

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

Развитие облачных технологий и появление надежных CSP в России позволяют бизнесу доверить периферические инфраструктурные сервисы профессиональным игрокам.

Причина 2. Снижение стоимости владения инфраструктурой

Грамотная облачная или гибридная стратегия может драматически снизить стоимость владения IT-инфраструктурой практически любой компании за счет целого ряда факторов:

Точность планирования

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

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

Наглядный пример первого сценария: во время распродажи у Huawei перестал работать сайт. Китайский вендор не рассчитывал, что смартфоны за 1,000 рублей могут так заинтересовать россиян.

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

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

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

Уход от долгосрочных капитальных инвестиций

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

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

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

Экономия на персонале

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

Причина 3: Отказоустойчивость и катастрофоустойчивость

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

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

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

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

Они соединяются друг с другом непересекающимися и зарезервированными оптическими каналами.

Если авария парализует работу одного ЦОД, системы автоматически перезапускаются в другом, и инфраструктура заказчика продолжает работать в штатном режиме.

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

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

Эти практики ― залог надежного функционирования инфраструктуры, например, если сотрудник клиента случайно удалил часть кода или произошел системный сбой.

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

На что обратить внимание при выборе CSP

Лицензии. Существует ряд лицензий, наличие которых обязательно для большинства CSP:

  • Лицензия ФСТЭК — для оказания услуг, связанных с технической защитой конфиденциальной информации (коммерческой тайны, персональных данных)
  • Лицензия ФСБ — для предоставления услуг с использованием средств криптографической защиты информации (шифрование)
  • Лицензия на телематические услуги — для предоставления доступа к сети Интернет или оказания услуг хостинга
  • Лицензия на услуги связи по предоставлению каналов связи — для создания скоростной сети и предоставления в аренду каналов на территории одного либо нескольких субъектов РФ

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

  • Соответствует ли инфраструктура провайдера стандарту предприятий электронной коммерции PCI DSS? Если да, то он может хранить данные платежных карт
  • Соответствуют ли сервисы провайдера закону ФЗ-152 «О персональных данных», выполняя юридические, организационные и технические мероприятия?
  • Готов ли CSP выполнять специфические требования заказчика (например, по техническим характеристикам, уровню безопасности, поддержки или с точки зрения соответствия стандартам по защите информации?)

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

Уровень надежности дата-центра. От него зависит, дублируются ли внутренние системы в ЦОД. Например, повлияет ли на работу дата-центра отключение электричества.

Резервирование ЦОД. Предоставляет ли провайдер облачных услуг возможности для создания отказоустойчивой и катастрофоустойчивой инфраструктуры, доступно ли резервирование между несколькими географически-распределенными дата-центрами.

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

Система оплаты. Самая удобная — за фактическое потребление. Оплата только за те мощности, которыми вы воспользовались.

Отсутствие ограничений. Количество ресурсов: дисков, машин и сетей не лимитировано. Клиент должен иметь возможность создать инфраструктуру любой сложности.

Разграниченный доступ к проектам. Разные сотрудники могут иметь разный доступ к ресурсам компании.

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

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

Администрирование сервисов, в свою очередь, позволит делегировать обслуживание IT-инфраструктуры на специалистов облачного провайдера.

Задайте рассматриваемым CSP вопрос о возможности предоставления персонального customer care менеджера для вашей компании.

Уровень квалификации сотрудников, которые будут обслуживать IT-инфраструктуру. Стоит обратить внимание на менеджмент, размер команды, наличие сертификатов у сотрудников. А также на партнеров провайдера.


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

Интерфейс. Насколько удобно работать с созданием новых серверов и как просто управлять ресурсами и доступами.

Наличие API у облачного провайдера позволит автоматизировать работу с ним и интегрироваться с собственными и сторонними сервисами.

Заключение

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

По данным Cisco, к 2021 году 94% задач и вычислений будут выполняться в облачных дата-центрах, в традиционных — 6%. Российский рынок ожидает похожая трансформация, и конкурентноспособность практически любой средней или крупной компании будет зависеть от способности их лидеров адаптироваться к новым реалиям.

[2] Гибридная IT-инфраструктура — комбинация локальной инфраструктуры, нескольких частных и публичных облаков различных провайдеров.

Как компании перенести свою инфраструктуру в облако и избежать ошибок

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

Например, в течение трех последующих лет 50% индийских организаций планируют переместить инфраструктуру в облако.

Рынок «идет» вверх — по прогнозу аналитического агентства Gartner, в 2020 году IaaS-сегмент вырастет на 36,8% и достигнет планки в 34,6 млрд долларов.

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

Из-за объемов IT-инфраструктуры и миллиардов долларов, затрачиваемых каждый день на оборудование, программное обеспечение и поддерживание сервисов, переход от модели развертывания on-premise к облачной невозможно совершить за одну ночь.

При переносе IT-отделам компаний приходится решать, как поддерживать доступ к источникам данных — большинство сценариев миграции включают перенос информации с использованием бэкап-инструментов и систем восстановления в случае катастрофы (disaster recovery).

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

Подробнее об этих типах рисков и как их избежать, мы расскажем далее.
Переход в облако совершают крупные компании и небольшие стартапы — 52% сегмента малого бизнеса обратились к облачной инфраструктуре.

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

Существуют кейсы, демонстрирующие успешную миграцию IT-инфраструктуры в облако IaaS-провайдера. При этом часть компаний используют облако как вторичный плацдарм, где хранят «вторичные» сервисы, а другие — целиком отдают инфраструктуру на аутсорсинг и размещают там бизнес-критические системы.

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

В Netflix перенесли в облако платежную инфраструктуру и сервисы предоставления счетов, платформу Big Data, службы видеотрансляции, систему управления данными клиентов и др.

Российские компании также переходят в облачную среду. Delivery Club — сервис по доставке еды c полностью виртуализированной системой.

В случае Delivery Club, облако упростило управление, поддержку и обеспечило надежность.

Мигрировал в облако провайдера и автомобильный холдинг «Терра-авто». Компания разместила в виртуальной среде телекоммуникационный компонент, почтовые сервисы и инструменты фильтрации трафика.

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

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

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

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

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

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

  • Категоризация данных, требования к безопасности;
  • Сложность интерфейса, аутентификация, структура данных, требования к латентности;
  • Требования к работе (SLA), интеграция, мониторинг.

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

  • Память, число процессоров, занимаемое место на диске операционной системой;
  • Платы сетевого интерфейса;
  • IPv6;
  • Поддержка доменов;
  • Наличие сторонних компонентов и пакетов приложений.

Закончив эту оценку, IT-команда составляет список приоритетов, то есть определяет, какие приложения более других выиграют от миграции в облако. Эксперты рекомендуют начинать переход в облачную среду с простых проектов, постепенно увеличивая сложность.

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

Шаг 2. Это этап выбора облачного провайдера с тестированием возможностей облачной площадки. Оцените надежность площадки провайдера и проверьте её на соответствие требованиям компании.

Надежность облачной платформы зависит от используемого оборудования, поэтому стоит обратить внимание на актуальность «железа», его класс и проверить наличие резервирования (не должно быть единой точки отказа).

Также большинство коммерческих дата-центров заявляют, что их инфраструктура соответствует стандарту по категории надежности Tier III. Однако это не всегда так. Проверить сервис-провайдера просто: запросите сертификаты, подтвержденные Uptime Institute. UTI сертификаты для российских дата-центров находятся на сайте организации.

После того как вы определились с провайдером, в обязательном порядке проведите тестирование облачной площадки и тестовую миграцию. Например, мы в компании «IT-ГРАД» по запросу клиента предоставляем бесплатный доступ VMware vCloud на две недели. Это позволит вам убедиться, что все сервисы работают правильно.

Шаг 3. При переносе IT-инфраструктуры в облако следует выбрать миграционный путь: постепенный или полный переход.

Постепенная миграция подходит для крупных компаний с разветвлённой инфраструктурой. Такой переход выполняется на протяжении нескольких месяцев или даже лет (например, случай компании Netflix, о которой мы говорили выше).

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

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

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

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

Шаг 4. Далее, можно приступать к миграции, придерживаясь выбранной стратегии. После остается выполнить проверку и тестирование сервисов. Если ошибок нет — сервисы выводятся в продакшн.

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

Если у компании уже есть виртуальная инфраструктура на базе VMware, то её виртуальное окружение позволяет «перекинуть» сразу несколько ВМ.

Все параметры виртуальных машин «упаковываются» в файлы формата OVF/OVA.

Затем они используются экспорта на платформу виртуализации VMware vSphere и другие. Переносить приложения в облако также позволяет VMware vCloud Connector. Как работать с этим инструментом ми писали в нашем блоге.

Миграция на уровне сервисов

Провайдер создает у себя дублирующий сервис. Этот сервис синхронизируется с локальным сервисом клиента. Как пример можно привести миграцию Active Directory. Облачный провайдер разворачивает у себя необходимое количество ВМ, после чего база данных реплицируется в облако вместе с контроллерами.

«Горячее» и «холодное» клонирование

При «горячем» клонировании выполняется перенос работающего узла. Оригинальный сервер останавливается только в момент переключения. Утилита vCenter Converter автоматически определяет диски, разделы и сетевые интерфейсы, оперативную память и процессоры.

На основе этих данных создается новая виртуальная машина на ESXi-хосте.

VMware vCenter Converter также может выполнять «холодное» клонирование. Этот вид клонирования рекомендован для миграции Active Directory и почтовых серверов.

Машина останавливается, создается образ жесткого диска и выполняется конвертация в ВМ.

Провайдер создает ВМ, и на неё накатывается операционная система и необходимое программное обеспечение. Затем происходит переключение клиентов. При миграции в облако компании порой не уделяют внимания некоторым деталям. Давайте рассмотрим самые популярные ошибки, которые совершают организации при переходе к облачной инфраструктуре.

«Все провайдеры одинаковые»

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

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

Например, мы в «ИТ-ГРАД» предлагаем несколько площадок для размещения данных.

Клиент может создавать несколько виртуальных дата-центров и настраивать параметры производительности и безопасности для каждого. Мы также предлагаем разные модели оплаты, включая Pay-As-You-Go.

Другая ошибка, которая является своеобразным следствием, — это отказ от нативных облачных сервисов и использование собственных инстансов виртуальных машин.

Эту ошибку легко допустить, поскольку кажется, что это позволит избежать привязки к вендору.

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

Нет схемы зависимости приложений

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

Например, как говорят в «Хантердон Медикал Сентер», они совершили эту ошибку во время первой миграции систем в облако. Сотрудники не провели глубокий анализ приложений. Специалисты переносили почтовую систему в G Suite, однако не учли, что именно пользователям было нужно от старой системы, и не проанализировали, как она себя поведет в новом окружении.

До начала миграции ответьте для себя на вопросы: что вы будете переносить в облако, в каком порядке, когда и за сколько? Составьте план переноса.

Эксперты из технологической компании DoubleHorn также советуют для составления плана прибегнуть к помощи третьих лиц и консалтинговых фирм. Они помогут найти и применить лучшие практики и избежать дорогостоящих ошибок.

Забыли про политики безопасности

12 веских причин использовать в бизнесе облачный сервер за рубежом

Многие считают, что облака окутаны тайнами, которые дано постичь только избранным.


На самом деле всё не так страшно. Да, в отрасли есть свои термины. Часто их понимают только специалисты, которые работают с облаками постоянно. И само облако — сложная система. Но самые важные моменты можно легко объяснить простым языком.

Чтобы начать разбираться в облаках, нужно понять, какую пользу они дают бизнесу.

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

Итак, перечислим 12 причин, почему стоит использовать облачные сервисы в бизнесе.

Причина №1 — Когда данные за рубежом, бизнес в безопасности

Когда вы храните информацию на облачном сервере за границей, до неё сложно дотянуться без вашего разрешения.

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

Потеря данных нарушает процессы бизнеса или вовсе останавливает работу компании. А во время простоя бизнес теряет клиентов. Когда компания снова сможет восстановить работу — неизвестно.

Чтобы этого избежать, держите информацию в облаке за границей. На работу в облаке можно перевести всех сотрудников компании или отдельное подразделение (например, бухгалтерию).

Причина №2 — Вечная актуальность без затрат

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

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

При использовании облаков, этот вопрос отпадает. Вы не думаете над тем, как и когда обновлять оборудование, к кому обращаться и что делать, если что-то не работает.

Годный провайдер всегда следит за работой серверов и не допускает сбоев в работе. Вы платите только за использование мощностей в облаке — заказанное количество ресурсов и программы, если они вам нужны.

Причина №3 — Облако — универсальный инструмент

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

Например, вы можете заказать почтовый сервер, сервер для хостинга сайтов на 1С-Битрикс или машину для размещения программы 1С:Бухгалтерия, пакет офисных программ для работы сотрудников с удалёнными рабочими столами и так далее.

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

Причина №4 — Бизнес можно перенести в облако за день

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

В большинстве случаев это мнение ошибочно. Конечно, если надо перенести в облако несколько тысяч или сотен тысяч сотрудников, это займёт больше времени.

Но компания из 10-20 человек может переехать в облако за день, а то и за несколько часов. Так что всё напрямую зависит от размера бизнеса и задач.

Для ваших сотрудников в работе ничего не изменится. Просто теперь они будут работать через удалённый рабочий стол, а бизнес будет в облаке — в безопасности.

Причина №5 — С облаками бизнес экономит деньги

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

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

Простыми словами при переходе на работу в облаке бизнес прекращает тратить деньги на покупку оборудования. Всё оборудование предоставляет и обслуживает провайдер облака.

Кроме того, в облаке легче администрировать, обслуживать и настраивать системы, поэтому отпадает необходимость подключать дополнительные ресурсы и финансы.

Причина №6 — Есть возможность делать снимки системы и бекапы

В каждом бизнесе бывают неприятные ситуации с потерей данных.

Например, потерять базу клиентов очень обидно, а базу бухгалтерии и важные электронные документы — очень опасно.

Всё это грозит финансовыми убытками и крахом репутации, иногда банкротством.

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

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

То есть, если вдруг вы потеряете часть информации или всю информацию, то сможете восстановить её, потому что у вас будет снимок системы и/или резервная копия — бекап.

Причина № 7 — Облака делают бизнес мобильным

Если до этого момента ваш бизнес был привязан к офису и оборудованию, которое там установлено, с переходом на облака бизнес обретает мобильность.

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

Даже если вы решите слетать в путешествие на Луну, и там будет интернет, сможете продолжить решать задачи бизнеса удалённо. Никто и не заметит вашего отсутствия в офисе.

Облака позволяют работать на любом устройстве в любом месте, где есть интернет. При этом ваша информация остаётся под надёжной защитой.

Причина № 8 — Облака легко администрировать

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

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

А для клиентов, которые вообще ничего не хотят администрировать самостоятельно, у нас есть отдельная услуга администрирования серверов. Клиенты просто работают в облаке, а функции администрирования отдают нам и вообще не думают об этом. А мы следим за тем, чтобы всё работало исправно.

Облака должны помогать бизнесу, а не добавлять новые задачи, на которые нужно тратить время.

Причина № 9 — Надёжность и непрерывность работы

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

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

Всё работает надёжно и непрерывно.

Причина № 10 — Гибкость и масштабируемость

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

Вы платите провайдеру только за то, что вам реально нужно. От ресурсов, которые вам не нужны, всегда можно отказаться.

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

Причина № 11 — Возможность мониторинга

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

Причина № 12 — Высокая скорость работы

Технологии развиваются. Облака становятся быстрее и удобнее.

Сейчас скорость работы в облаке ничем не отличается от привычной работы на локальном компьютере. Только теперь ваша информация в безопасности.

В этой статье мы перечислили основные причины, по которым всё больше компаний переносят бизнес в облака.

На самом деле причин гораздо больше. Для каждого бизнеса они свои.

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

Если у вас остались вопросы, обращайтесь к нам в любое время. Мы всегда на связи. И рады вам 24х7.

Подпишитесь на нашу рассылку пользы, чтобы не упустить важного.

5 причин не переходить в «облако»

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

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

1. Готовы ли вы передать информацию, с которой работаете, в чужие руки?

Информационная безопасность является одной из основных причин, почему некоторые компании не спешат переносить свою работу в «облако».

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

Если ваша компания — представитель индустрии с особыми требованиями к информационной безопасности (например, вы работаете в финансовом секторе или сфере здравоохранения), вполне возможно, что вы просто не можете передавать данные в третьи руки.

2. Смогут ли облачные технологии сократить ваши расходы?

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

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

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

3. В случае прекращения сервиса, будет ли ущерб для вашей компании минимальным?


По мнению Николаса Карра (Nicholas Carr), автора книг о технологиях и культуре, прекращение выпуска продукта или предоставления сервиса — в целом вполне нормальное, всем знакомое явление.

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

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

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

4. Можете ли вы с уверенностью сказать, что облачное решение не превратится в Гордиев узел?

В интервью для Software Magazine Шуб Джавед (Shoeb Javed), CTO в компании Worksoft, отмечает, что «все рассуждают о том, насколько облачные технологии облегчают жизнь, однако «облако» с тем же успехом может все усложнить.

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

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

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

5. Можете ли вы сказать, что на 100 % уверены в качестве услуг своего интернет-провайдера?

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

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

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

Конечно, у любой медали есть две стороны. То, о чем говорилось выше, может быть «не вашим случаем», либо у вас может быть другое, не менее справедливое мнение. Эта статья — просто пища для размышлений, и мы надеемся, что вы нашли в ней что-то полезное для себя. Будем рады, если поделитесь своим мнением в комментариях!

Данный материал является частной записью члена сообщества Club.CNews.
Редакция CNews не несет ответственности за его содержание.

IT-инфраструктура: облачная vs локальная

Уход в «облака» — пожалуй, наиболее яркий тренд на рынке IT в последние годы, радикально меняющий структуру инвестиций в корпоративные информационные системы.

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

Предприниматель Денис Фокин провел сравнение облачной и локальной инфраструктуры на примере двух принадлежащих ему компаний.

У меня есть две компании — TI Systems и TeamBridge. Первая предлагает услуги по разработке крупных информационных систем на заказ, а вторая предоставляет онлайн-сервис для совместной работы и управления небольшой компанией.

Компании TI Systems скоро исполняется 8 лет, ее IT-инфраструктура складывалась постепенно и сейчас является мощной и современной.

Она включает 22 аппаратных сервера, на которых работают 92 виртуальных сервера и 30 виртуальных рабочих станций, предназначенных для тестирования разрабатываемого ПО.

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

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

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

Это электронная почта, средства онлайн-коммуникаций (такие как телефония, аудио- и видеоконференции), средства совместной работы, CRM. Сюда можно было бы добавить бухгалтерию на основе 1С, но в TeamBridge бухгалтерия полностью на аутсорсинге, поэтому у меня нет возможности провести адекватное сравнение.

Все данные приведены из расчета на 10 сотрудников, чтобы устранить разницу в масштабе.

Таблица 1. Анализ затрат: TI Systems

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

Я также перечисляю названия тех программных продуктов, которые реально используются в TI Systems. Стоимость приведена исходя из текущих цен поставщиков. Получилось, что первоначальные инвестиции в инфраструктуру составили 1,65 млн рублей, или 165 тыс. рублей на сотрудника.

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

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

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

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

Таблица 2. Анализ затрат: TeamBridge

В таблице 2 приведены цифры для TeamBridge. Главное отличие в том, что для начала пользования облачными сервисами не требуется первоначальных вложений в лицензии на ПО и на аппаратное обеспечение. Поэтому приводится стоимость использования сервиса в месяц (тоже на 10 сотрудников).

Также в таблице указаны конкретные сервисы, которые используются. Итого получаем 18 тыс. рублей в месяц, или 1800 рублей в месяц на сотрудника. В год набегает 216 тыс.

рублей, то есть TeamBridge может пользоваться теми же IT-системами более 7 лет, прежде чем потратит такую же сумму за их использование, какую пришлось вложить TI Systems в создание своей инфраструктуры.

Серверная инфраструктура TI Systems

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

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

В TeamBridge IT-специалист должен контролировать только локальную сеть и рабочие станции сотрудников. Сохранность данных и уровень доступности услуг финансово гарантируются соглашением об уровне обслуживания (SLA agreement) с каждым поставщиком облачного сервиса. Уровень доступности каждой услуги — не ме­нее 99,9% времени в год.

В TI Systems за сохранность данных и работоспособность сервисов отвечают штатные IT-специалисты, ответственность которых зафиксирована в трудовом договоре. TeamBridge доверяет свои данные известным на рынке, дорожащим своей репутацией компаниям — поставщикам облачных сервисов.

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

TeamBridge настолько уверена в безопасности облачных технологий, что хранит в облаке даже самый ценный актив — исходные коды своего программного продукта.

Разница инфраструктур двух компаний проявилась «в полный рост», когда мы затеяли переезд. Начала она проявляться еще на этапе поиска офиса. Для TI Systems обязательным условием была возможность оборудовать серверную. На практике это означает небольшое помещение площадью около 4 кв.

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

Для TI Systems необходимость наличия серверной комнаты в офисе не только сузила выбор, но и повлекла за собой дополнительные расходы.

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

А что же в TeamBridge? Все потери рабочего времени сотрудников свелись к упаковке и распаковке личных вещей. Корпоративные информационные системы не останавливались даже тогда, когда вся мебель и оборудование были в пути.

Сотрудники, которые не участвовали непосредственно в переезде, в это время работали из дома. Таким образом удалось избежать остановки рабочих процессов.

Полагаю, что ужасы переезда пережили многие компании, и их руководители помнят, как болезненна приостановка деятельности: можно упустить новых клиентов и подпортить отношения с кем-то из старых. У TeamBridge таких проблем просто не было.

Инвестиции в собственную серверную инфраструктуру сопоставимы с затратами на пользование облачными сервисами в течение 7 лет

Из приведенного сравнения и случая с переездом я для себя сделал однозначный вывод: очень выгодно строить новый бизнес сразу с использованием облачной IT-инфраструктуры. Если мне доведется запускать новые стартапы, я, безусловно, буду отдавать приоритет облачным решениям.

Получив такой положительный опыт с новой компанией, я серьезно задумался над переводом TI Systems в «облака». Но, к сожалению, миграция уже существующей IT-инфраструктуры — процесс гораздо более сложный, чем создание облачной инфраструктуры с нуля. Во-первых, требуется тщательное планирование.

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

Ведь очень важно не останавливать работу компании и не снижать ее производительность.

Проанализировав нашу инфраструктуру и наш опыт помощи другим компаниям в переводе IT-инфраструктур в «облака», мы решили в первую очередь переводить не самые критичные для нашего основного бизнес-процесса сервисы. Проще всего нам будет перевести в «облака» электронную почту. Это обособленный, но активно используемый нами сервис.

У нас сейчас используется MS Exchange Server, поэтому идеальной облачной альтернативой является сервис Exchange Online, входящий в состав MS Office365. Этот сервис нам хорошо известен, поскольку его использует TeamBridge, а TI Systems выполнила несколько проектов для своих клиентов по миграции электронной почты в Exchange Online.

Процесс миграции позволяет перенести почтовые ящики сотрудников, сохранив историю переписки, и его можно организовать таким образом, что пользователи даже не заметят сам процесс «переезда» их почтового ящика. При желании можно перевести в «облако» только часть сотрудников.

Например, некоторые крупные компании сначала переводят на «облачную» электронную почту только филиалы и региональные представительства.

Затем мы планируем перенести в «облако» корпоративный портал, который сейчас реализован на MS SharePoint Server.

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

Для портала мы пока рассматриваем две облачные альтернативы: SharePoint Online и наш собственный онлайн-сервис TeamBridge.

Далее хотелось бы вынести в «облако» вообще все сервисы корпоративных коммуникаций. Как я отмечал выше, для телефонии, аудио- и видеоконференций мы используем продукт MS Lync. Ему тоже есть облачная альтернатива в составе Office365, но имеется один недостаток — Lync Online пока не интегрируется с местными телефонными сетями в России, и это существенно ограничивает его применение.

На перевод всех упомянутых сервисов в «облако» мы выделили полгода. Если все пройдет успешно, то далее мы приступим к переводу и более критичных процессов.

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

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

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

например, Gmail. И если они рассматривают автоматизацию таких процессов, как управление задачами и поручениями, управление проектами, продажи и маркетинг, то целесообразно сразу выбирать SaaS-системы.

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

Первая группа — сервисы общего пользования или инфраструктурные сервисы (такие как электронная почта, телефония, онлайн-конференции, хранилища данных). Вторая категория — специализированные сервисы, автоматизирующие конкретные бизнес-процессы (CRM, совместная работа, управление задачами и проектами и т.п.

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

Хотя в последнее время ситуация выравнивается, и, например, почта от «Яндекса», по моему мнению, не уступает решениям от мировых лидеров.

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

Денис Фокин

Окончил Башкирский государственный университет, Военную инженерно-космическую академию им. Можайского. Информационными технологиями занимается 20 лет, пройдя путь от рядового программиста до руководителя компании.

В 2005 году вместе с партнерами основал компанию TI Systems, специализирующуюся на разработке ПО на заказ и на системной интеграции (в штате более 50 сотрудников).

В 2012 году основал компанию TeamBridge, которая предоставляет одноименный онлайн-сервис для совместной работы и управления небольшими компаниями.

Мастер Йода рекомендует:  Скрытые возможности Instagram, о которых должны знать все
Добавить комментарий