Как выбрать правильного облачного провайдера: 12 ключевых советов

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

Критично, чтобы идеальный сервис соответствовал и превосходил ожидания бизнеса.

Но что бизнесу искать при поиске облачного сервиса?

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

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

Насколько удобен пользовательский интерфейс облачного сервера?

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

Раньше эти казалось тривиальные действия требовали полного ИТ-департамента.

Amazon Direct Connect (AWS), например, использует довольно громоздкий UI. Это может затруднить бизнес в выполнении рутинных задач без выделенной ИТ-команды. Суть простого и эффективного UI: вам как компании нужен доступ к данным всегда.

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

Как работает Service Level Agreement (SLA)?

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

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

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

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

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

Регулярно вызывайте на диалог провайдеров, готовых предлагать гибкие термы. Просите детали: как они планируют поддерживать запрошенную кастомизацию, кто ответственен за модификацию, какие шаги для администрирования вариации. Всегда помните главные компоненты SLA: service level objectives, политики ремедиации и пенальти/инцентивы по этим объективам, исключения и оговорки.

Документация, провижининг и настройка аккаунта

Лучшие практики SLA и другие контракты часто разбиты на четыре пункта интереса (с доп. под-секциями для кастомизации): правовые защиты, доставка сервиса, бизнес-термы, assurance данных.

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

Доставка сервиса варьируется в зависимости от размера провайдера. Правило: всегда ищите точное определение всех сервисов и deliverables. Будьте абсолютно ясны во всех ответственностях сервисной компании по их предложениям (service management, провижининг, доставка, мониторинг, поддержка, эскалации и т.д.).

Бизнес-термы включают: паблисити, страховые полисы, специфические бизнес-полисы, операционные ревью, фи, коммерческие термы.

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

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

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

Метрики надежности и производительности для оценки

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

Сначала — валидируйте производительность провайдера к их SLA за последние 6–12 месяцев. Часто провайдер публикует это публично, другие дадут по запросу.

Но: не ждите идеальности. Даунтайм серверов ожидаем, никакое решение не имеет идеальной записи.

Для допустимых уровней даунтайма — изучите дифференциацию Data Center Tiers 1, 2, 3, 4. Ценность отчетов — в том, как компания реагировала на даунтайм. Также верифицируйте, что все инструменты мониторинга и репортинга работают с вашими существующими системами управления и репортинга.

Точный и детальный репортинг надежности сети дает ценное окно в ожидания от работы с провайдером.

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

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

Важно ли аварийное восстановление?

Помимо надежности сети, клиент должен учитывать протоколы disaster recovery у отдельных вендоров.

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

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

Доп. страхование рисков — всегда умная идея для покрытия потенциальных затрат на восстановление данных (когда аспекты восстановления под юрисдикцией клиента).

Что нужно знать о безопасности данных?

Защита данных сохраняет бизнес и клиентов от кражи данных. Безопасность в облаке влияет и на прямого клиента, и на тех, с кем клиент ведет бизнес.

Валидируйте разные уровни систем и мер безопасности данных вендора. Также изучите возможности security operations и security governance процессов. Контролы безопасности провайдера должны поддерживать ваши политики и процедуры безопасности.

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

Сетевая инфраструктура и локация дата-центра

Локация дата-центра провайдера критична — драматически влияет на многие факторы.

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

Локация влияет на сетевую латентность. Чем ближе бизнес к дата-центру, тем ниже латентность и быстрее данные доходят. Компания в Лос-Анджелесе получит данные из Финикса быстрее, чем из Амстердама.

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

А если мне нужна техподдержка?

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

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

Некоторые дата-центры и провайдеры предлагают tailored ресурсы для технических проблем, до 24/7 on-call сервиса.

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

Бизнес-здоровье провайдера сервисов

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

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

Исследуйте прошлое/текущие правовые проблемы провайдера через ресерч и запрос данных. Спросите о потенциальных изменениях в корпоративной структуре (поглощения/слияния) — полезная инфа. Не обязательно doom and gloom: поглощение может улучшить сервисы и поддержку в будущем.

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

Сертификации и стандарты

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

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

Много разных стандартов и сертификаций может получить провайдер. Зависит от организации, уровней безопасности, другого клиентура, множества условий. Стандарты для ознакомления: DMTF, ETSI, ISO, Open Grid Forum, GICTV, SNIA, Open Cloud Consortium, Cloud Standards Customer Council, NLST, OASIS, IEEE, IETF.

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

Стандарты облачной безопасности на отдельной фацетте, сертификации выдают разные организации. Первичные критерии безопасности: CSA (CS-A, SSAE, PCI, IEC, ICO, COBIT, HIPAA, Cyber Essentials, ISAE 3402, COBIT, GDPR.

Операционные стандарты — третья категория для рассмотрения и поиска сертификации. Включают ISO, ITIL, IFPUG, CIF, DMTV, COBIT, TOGAF 9, MOF, TM Forum, FitSM.

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

Зависимости сервисов и партнерства

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

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

Подумайте, вписываются ли сервисы этих вендоров в более широкую экосистему других сервисов, которые могут дополнять или поддерживать. Некоторые вендоры легче коннектятся с IaaS, SaaS или PaaS. Может быть перекрытие или pre-configured сервисы, из которых бизнес может извлечь выгоду.

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

Поддержка миграции ИТ облачных сервисов и планирование выхода

Ища идеального партнера, заботьтесь о долгосрочной стратегии.

Если решите перенести сервисы или вырастете за возможности провайдера. Последнее, чего хотите — сценарий Vendor Lock-In. Ситуация, где вы как клиент, используя продукт/сервис, не можете легко транзишн к конкуренту. Часто возникает, когда провайдер использует проприетарные технологии, становящиеся несовместимыми с другими.

Специфические термы для наблюдения при сравнении build apps и дата-центров. Примеры CSP с vendor lock-in технологиями:

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

Выбор провайдера со стандартными сервисами без реляции на tailor-crafted системы снизит долгосрочные боли и поможет избежать vendor lock-in.

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

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

Ключевые выводы по облачным вычислительным вендорам

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

С правильной стратегией и talking points бизнес может найти правильное решение за провайдером в кратчайшие сроки.

Помните думать долгосрочно чтобы избежать потенциального data center lock-in. Избегайте проприетарных технологий и стройте определенную exit стратегию для предотвращения головной боли в будущем.

Уделите время для построения рабочих и исполнимых SLA с контрактными термами. Детальный SLA — первичная форма assurance, что сервисы будут доставлены и поддержаны как согласовано.

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