Выбор облачного провайдера — это не про цены и список функций, а про способность выдерживать реальную нагрузку. Именно в пиковые моменты становится видно, где заканчиваются обещания и начинается устойчивость инфраструктуры. Какие советы даст бизнес и чем поделится провайдер — далее в статье.
- 1. Введение
- 2. Требования бизнеса к облаку
- 3. Типичные ошибки при переходе в облако
- 4. Предохранители в облачных моделях
- 5. О гибридных облаках
- 6. Типовые вопросы бизнеса к облачной инфраструктуре
- 7. Соответствие масштабов бизнеса и провайдера
- 8. Рынок облаков сегодня, и что ожидает его в будущем
- 9. Выводы
Введение
В прошлом выпуске вместе с Иваном Гузевым, руководителем центра развития безопасности облачной инфраструктуры и сервисов МегаФона ПроБизнес, и Дмитрием Шестерниным, техническим директором Flowwow, мы поговорили о границах ответственности между облачным провайдером и бизнесом во время инцидентов. Разобрали, что происходит, когда сервис выходит из строя, как распределяются зоны ответственности. Обсудили, что должно быть зафиксировано в договорах и какую роль играют не только формальные обязательства, но и отношения между сторонами.
Рисунок 1. Участники подкаста
В ходе обсуждения мы пришли к выводу, что многих проблем можно избежать ещё до запуска сервисов: на этапе выбора инфраструктуры. Поэтому сегодня мы продолжим эту тему и поговорим о том, как выбрать облачного провайдера, на какие критерии стоит обращать внимание и какие решения действительно влияют на надёжность сервисов.
Участники подкаста:
Михаил Воронков, руководитель направления по развитию облачных продуктов МегаФона ПроБизнес.
Виталий Акулов, руководитель инфраструктуры Skyeng.
Ведущая и модератор эфира — Олеся Афанасьева, генеральный продюсер, специальный корреспондент «АМ Медиа».
Требования бизнеса к облаку
Для небольших компаний выбор облачного провайдера обычно не превращается в сложный проект. На старте бизнеса используются типовые решения и стандартные сценарии работы, поэтому достаточно ориентироваться на крупных российских провайдеров, которые обеспечивают соответствие требованиям законодательства, поддержку на русском языке и понятные условия взаимодействия.
Если речь идёт о критически важных информационных системах, например 1C, подход меняется. В этом случае имеет смысл протестировать нескольких провайдеров и сравнить не только стоимость услуг, но и производительность инфраструктуры на реальных задачах. Иначе экономия на этапе выбора может обернуться проблемами при закрытии отчётного периода или выполнении других важных операций.
Изменение требований по мере масштабирования бизнеса
Переход от малого бизнеса к среднему сопровождается изменением требований к инфраструктуре. Если на ранних этапах её основная задача заключается в обеспечении текущей работы сервисов, то по мере роста компании на первый план выходят вопросы масштабирования, надёжности. Возрастают требования и к обработке персональных данных, информационной безопасности (ИБ), выполнению требований регуляторов.
Инфраструктура должна поддерживать развитие бизнеса, а не становиться ограничением для дальнейшего роста. Любой простой в этот период означает не только техническую проблему, но и прямые потери выручки, репутационные риски и влияние на клиентский опыт.
Признаки необходимости перехода в облако
Развитие инфраструктуры успешного бизнеса редко начинается с заранее подготовленного плана. Обычно всё происходит следующим образом:
- быстрый рост компании;
- появление новых продуктов;
- увеличение числа клиентов;
- рост нагрузки на сервисы.
В какой-то момент инфраструктура начинает работать на пределе возможностей, и её развитие из долгосрочной задачи превращается в необходимость. Основная цель в такой ситуации — обеспечить дальнейший рост без потери производительности и надёжности сервисов. Требования к инфраструктуре должны быть сформированы исходя из планов бизнеса и его продуктовой стратегии.
Решения о развитии инфраструктуры, как правило, принимаются совместно, рассказал Виталий Акулов. Бизнес определяет направление развития и ставит задачи, а специалисты по инфраструктуре, сетевые инженеры и команды разработки, оценивают, какие изменения необходимы для поддержки будущих нагрузок. Такой подход позволяет связать технические решения с реальными потребностями компании.
По словам Михаила Воронкова, организации обращаются к ним по вопросу модернизации инфраструктуры в разные моменты. Иногда изменения планируются заранее, когда понятны перспективы роста и ожидаемые нагрузки. Иногда необходимость возникает уже после возникновения проблемы:
- нехватки ресурсов;
- отказа собственной инфраструктуры;
- резкого роста нагрузки.
Подобные ситуации нередко становятся следствием успешных маркетинговых кампаний или быстрого увеличения клиентской базы. Для компаний, находящихся в фазе активного роста, решения по инфраструктуре могут приниматься практически непрерывно. В более зрелом бизнесе горизонт планирования увеличивается с 1 квартала до 1–3 лет, что позволяет заранее готовить инфраструктуру к будущим изменениям.
Требования к отказоустойчивости определяются не размером компании, а значимостью конкретной информационной системы для бизнеса. Для одних систем даже кратковременный простой означает потерю выручки, клиентов и репутационные риски. Для других допустимо восстановление в течение нескольких часов без серьёзных последствий для деятельности компании. Поэтому подходы к резервированию и восстановлению должны выбираться с учётом допустимого времени простоя, времени восстановления и возможной потери данных для каждой конкретной системы.
Типичные ошибки при переходе в облако
Когда компания приходит к выводу, что текущая инфраструктура перестаёт соответствовать требованиям бизнеса, ключевой вопрос смещается к выбору новой модели размещения сервисов. По опыту участников подкаста, это редко выглядит как заранее спланированное решение.
Ошибка №1: отсутствие расчётов
Основная причина ошибок при переходе — отсутствие предварительных расчётов. Перед выбором инфраструктуры важно определить:
- перечень размещаемых систем;
- требования к их производительности и надёжности;
- бюджет на миграцию;
- допустимые риски.
Чем точнее эти параметры зафиксированы, тем ниже вероятность некорректного выбора архитектуры.
Ошибка №2: сравнение затрат
Распространённая ошибка — сравнение затрат на собственную инфраструктуру и облачные сервисы только по стоимости оборудования или аренды ресурсов. Такой подход не отражает реальную ситуацию. В расчёт необходимо включать расходы на специалистов, лицензирование программного обеспечения, эксплуатацию инфраструктуры и обеспечение отказоустойчивости. Только полная стоимость владения позволяет получить корректную картину.
Ошибка №3: отсутствие проверок инфраструктуры на соответствие реальным задачам
Инфраструктуру необходимо регулярно пересчитывать и проверять на соответствие текущим задачам бизнеса. Для этого используются различные метрики, включая соотношение инфраструктурных расходов и бизнес-показателей компании, что позволяет понять, остаётся ли текущая модель экономически оправданной или требует пересмотра.
Виталий Акулов: «Разные информационные системы требуют разного подхода. Нагрузка редко бывает однородной. Системы аналитики, внутренней отчётности, веб-сервисы, базы данных и инструменты разработки могут предъявлять совершенно разные требования к производительности, надёжности и стоимости эксплуатации. Поэтому выбор инфраструктуры должен выполняться не для компании в целом, а для конкретных сервисов и сценариев их использования. Такой подход со временем приводит многие организации к гибридным моделям, где для каждой категории задач используется наиболее подходящий вариант размещения».
Виталий Акулов, руководитель инфраструктуры Skyeng
Предохранители в облачных моделях
Облачные провайдеры, например «МегаФон ПроБизнес», предлагают своим клиентам так называемые предохранители — механизмы, которые позволяют ограничивать объём потребляемых ресурсов. Лимиты задаются для того, чтобы клиент не вышел за заранее определённую планку потребления. Их смысл в том, чтобы сгладить ошибки в расчётах, проектировании или прогнозировании нагрузки и не доводить их до критических последствий для бизнеса.
Это практикуется как стандартный механизм управления потреблением в облачной среде. По смыслу это можно сравнить с лимитами в банковских продуктах, например с ограничениями по снятию средств или суточными и месячными лимитами по банковской карте.
О гибридных облаках
Всё реже встречаются чистые модели использования инфраструктуры, чаще речь идёт о гибридных, где разные подходы к размещению сервисов сочетаются в рамках одной компании. Облачные модели особенно хорошо работают в сценариях быстрого старта. Это небольшие компании и стартапы, которым важно оперативно развернуть инфраструктуру, проверить продуктовые гипотезы и выдержать рост без длительной подготовки. В таких случаях облако закрывает задачу скорости запуска и масштабирования при условии, что архитектура приложений это поддерживает.
По мере роста бизнеса нагрузки становятся более предсказуемыми и типизированными. В образовательных проектах, например Skyeng, есть выраженная сезонность: пики приходятся на осень и весну, летом активность снижается. Дополнительно внутри дня формируются повторяющиеся пиковые часы. Когда такие закономерности уже видны и подтверждены метриками, появляется возможность иначе подходить к размещению систем и распределению нагрузок между различными средами.
Переход на гибридную инфраструктуру
Гибридный формат не обязательно означает смену провайдера. Во многих случаях компания продолжает работать с тем же поставщиком, который предоставляет разные варианты размещения: публичное облако, физические серверы в аренде и решения для частных облаков. У одного провайдера могут одновременно использоваться разные технологические платформы, включая облака на международных стеках виртуализации и решения на отечественных технологиях. Это позволяет выстраивать совместимые конфигурации и снижать затраты на интеграцию при переходе к гибридной модели.
Отдельный вариант — аренда физических серверов для построения частного облака (private cloud). Здесь возможны два подхода: самостоятельное управление или модель с участием провайдера, когда часть задач по сопровождению инфраструктуры берёт на себя сервисная команда. Гибридная модель в итоге складывается из сочетания публичного облака, частных облачных решений и выделенных физических ресурсов. Пики нагрузки при этом могут выноситься в облако, а более стабильные системы оставаться в предсказуемой инфраструктуре.
Безопасность в гибридном облаке
Безопасность — базовое условие любого проекта. При переносе части нагрузки в облако или обратно в инфраструктуру на железо вопросы ИБ прорабатываются на этапе проектирования, а не после запуска.
Михаил Воронков: «На сегодняшний день облако без информационной безопасности представить сложно. Это одна из обязательных составляющих. Например, наши облачные платформы имеют аттестаты по ИБ. Самые простые — это хранение персональных данных и государственные информационные системы. Из более свежих направлений — размещение объектов критической информационной инфраструктуры. Для разных категорий клиентов мы можем предложить тот объём мер по защите информации, который необходим в их случае».
Михаил Воронков, руководитель направления по развитию облачных продуктов МегаФона ПроБизнес
Типовые вопросы бизнеса к облачной инфраструктуре
С точки зрения бизнеса ключевые сложности при работе с облачной инфраструктурой чаще всего связаны с надёжностью. Это не один параметр, а совокупность факторов, которые в итоге определяют стабильность работы сервисов и предсказуемость поведения системы под нагрузкой: стабильность центров обработки данных, сети, вычислительных ресурсов, а также отсутствие просадок производительности в пиковые моменты.
Отдельно выделяется эффект шумных соседей. В облаке ресурсы одного физического сервера могут использоваться несколькими клиентами одновременно. Если один из них создаёт высокую нагрузку на процессор, память или дисковую подсистему, это может отражаться на других виртуальных машинах.
Со стороны провайдера эти вопросы решаются через разные тарифные планы. В зависимости от выбора и сценария использования клиент получает различный уровень выделения вычислительных мощностей.
Если система размещена в неподходящем по нагрузке сегменте, провайдер формирует рекомендации по изменению конфигурации. Основанием для этого выступают как обращения клиентов, так и данные мониторинга производительности, где отслеживаются загрузка процессоров, использование памяти и дисковой подсистемы в рамках соглашений об уровне обслуживания.
У МегаФона ПроБизнес выстроен непрерывный цикл обратной связи, основанный на круглосуточной технической поддержке и системе эскалаций. Техническая поддержка закрывает текущие инциденты и операционные вопросы, при усложнении ситуации подключаются службы клиентского сервиса в рамках заранее определённой эскалационной матрицы, закреплённой в договоре.
Соответствие масштабов бизнеса и провайдера
Идея о том, что небольшим компаниям подходит небольшой провайдер, а крупным — крупный, не является универсальным правилом. Формально такой подход выглядит логичным с точки зрения сопоставления масштабов, однако в реальной работе он не является определяющим.
Ключевым фактором становится не размер компании, а совпадение модели работы. У разных организаций отличается зрелость процессов, подход к планированию бюджета, уровень формализации требований и ожидания по взаимодействию с провайдером. Крупный бизнес чаще опирается на фиксированные SLA (соглашение об уровне качества услуги), долгосрочные контракты и формализованные процедуры. Малый бизнес, напротив, работает в более динамичном режиме, где важнее скорость реакции и решение задач по мере их появления.
Получается, что решающий фактор — не размер участников, а совпадение ожиданий по скорости, формальности процессов и способу взаимодействия.
Рынок облаков сегодня, и что ожидает его в будущем
Облако сегодня. Компании, особенно крупные, начинают более осознанно подходить к тому, какие нагрузки размещать в облаке, а какие оставлять на собственной инфраструктуре, включая железо, либо размещать у того же поставщика, но под своим управлением. Такой подход выглядит более взвешенным и практичным.
Но в отрасли сохраняется разный уровень проникновения облачных моделей. В сегменте малого бизнеса он остаётся относительно низким, порядка 30 %, тогда как в среднем и крупном бизнесе существенно выше — 60 %. На зрелых западных рынках этот показатель достигает порядка 70 %. Малому бизнесу надо фокусироваться на доходах, а не на поддержании собственной сложной инфраструктуры. В этом контексте передача части задач партнёрам выглядит рациональным решением.
Как будет развиваться облако в будущем. Развитие искусственного интеллекта (ИИ) будет всё заметнее влиять на управление инфраструктурой. Появятся агентные системы, способные самостоятельно принимать решения по размещению, масштабированию и оптимизации ресурсов. В результате для бизнеса инфраструктура станет более абстрактным сервисом: на первый план выйдут требования к стоимости, надёжности и доступности, а особенности архитектуры — гибридной, облачной или иной — будут играть всё меньшую роль.
Со стороны провайдеров эта трансформация будет сопровождаться дальнейшей автоматизацией управления инфраструктурой. Агентные системы смогут непрерывно собирать и анализировать данные, прогнозировать нагрузку, оптимизировать использование ресурсов и контролировать расходы. Поэтому особое значение получат инструменты мониторинга, автоматизации и практики FinOps (Financial Operations), обеспечивающие выполнение бизнес-требований при оптимальной стоимости инфраструктуры.
Рост уровня автоматизации и качества управления ресурсами, по мнению участников подкаста, будет способствовать дальнейшему повышению эффективности облачных моделей. По мере того как принятие решений всё больше будет передаваться ИИ, преимущества крупных облачных платформ и масштабируемой инфраструктуры станут ещё заметнее. Это может привести к дальнейшей консолидации вычислительных мощностей и укрупнению центров обработки данных. По оценке участников дискуссии, первые признаки такого перехода могут стать заметны уже в ближайшие 2–3 года.
Выводы
Поскольку универсального сценария перехода в облако не существует, выбор провайдера стоит строить не вокруг абстрактных рейтингов или набора услуг, а вокруг собственных требований бизнеса. Важно оценивать, насколько платформа соответствует характеристикам текущих и будущих нагрузок, требованиям ИБ, доступности сервисов, интеграции с существующей инфраструктурой и уровню технической поддержки.
Опыт провайдера при этом остаётся одним из ключевых критериев. Компании, которые регулярно сопровождают проекты миграции, обычно могут предложить проверенные архитектурные решения, помочь избежать распространённых ошибок и снизить риски на этапе внедрения. Поэтому при выборе облачного провайдера имеет смысл учитывать не только технические характеристики и стоимость услуг, но и практическую экспертизу партнёра в решении задач, схожих с вашими.
