Облачный чек-лист, или как бизнес-консультанты оценивают ИТ23.01.2019 10:19

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

Переносили все системы: тестовые среды, тест + прод, препрод, все виртуальные машины, виртуальные сервера плюс все системы виртуальной инфраструктуры. Даже поддержка у них своя появилась в России. От нас — только аренда ресурсов.

Проверяли они нас знатно, по масштабам: почти полный аудит ЦОДа. Но они смотрели не железо и теххарактеристики в основном, а то, как выстроены процессы ИБ и как соблюдаются разные SLA. С их точки зрения, именно процессы по стабильности SLA указывают на качество работы компании. И мы им рассказывали про каждый из компонентов детально.

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

Общие параметры

Основных требований было порядка двух десятков. Среди них — такие базовые, как размещение платформы на двух дата-центрах, наличие консоли для управления ресурсами, возможность работать посредством API, оплата услуг по факту использования с гранулярностью не более одного часа, наличие средств автоматизации, например, Terraform. Другие требования не сказать чтобы нас сильно удивили, их просто поголовно все заказчики не предъявляют. Среди подобного требования — необходимость иметь в собственности здание, в котором работает облачный ЦОД.

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

Требования к персоналу

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

Вот на что нас проверяли:

• Наличие трёх уровней технической поддержки платформы: первая линия -— решение инцидентов на уровне платформы (HW, виртуализация), вторая линия — решение проблем в инфраструктуре заказчика, находящейся в облачной платформе (уровень ОС, СУБД и прочего прикладного ПО), третья линия — подключение разработчиков облачной платформы поставщика и/или вендоров для решения проблем.
• Режим работы 24×7х365 первой линии технической поддержки.
• Обязательное знание русского и английского языков у специалистов всех уровней поддержки.
• Возможность заведения заявок по появившемуся инциденту по электронной почте или по звонку в службу технической поддержки.
• Возможность заведения заявок по появившемуся инциденту по звонку в службу технической поддержки.
• Время реакции специалистов технической поддержки на инцидент — от 10 до 15 минут в зависимости от приоритета заявки (поставщик обязан зафиксировать детализированное описание приоритетов инцидентов в контракте на услуги).
• Время решения инцидента— от 90 до 240 минут в зависимости от приоритета заявки (поставщик обязан зафиксировать детализированное описание приоритетов инцидентов в контракте на услуги).
• Обязательное наличие выделенной проектной команды, в состав которой входят: аккаунт-менеджер, менеджер проекта, технический архитектор, инженеры.
• Возможность использования различных средств коммуникации между командой поставщика и командой заказчика для более оперативного решения вопросов (например, с помощью мессенджеров Telegram, WhatsApp и пр.).
• Фиксирование списка проектной команды в подписанном контракте на услуги предоставления облачной платформы. Список должен включать в себя Ф.И. О., контактные номера мобильных телефонов, e-mail-адреса всех причастных к активности лиц заказчика и поставщика.

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

Выделенная проектная команда — отдельный важный момент. У нормального провайдера облачных услуг это всё обычно входит в услуги в каком-то виде. Но опять ж, нет прямого явного требования на это, и нет никаких стандартов. В целом есть люди, которые занимаются непосредственно поддержанием клиента, есть человек, который управляет конкретным проектом, есть инженеры. Выделять время для этих людей заказчику дорого, но нужно, потому что в большинстве случаев за пределами «просто хостингов» нужно как раз решение довольно сложных задач. Или простых, но быстро и с первого раза. Поэтому эти люди команды будут активны 24×7, всегда на связи и готовы помочь. С любым видом связи, который удобен клиенту. Это та услуга, которая обычно предоставляется «любимым» клиентам, но у нас — всем. И она задокументирована.

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

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

Требования к сертификации

Здесь без сюрпризов: PCI DSS для финансовых данных и T-III по трём сертификатам. Это важно именно для бизнеса заказчика. Для своей компании надо составлять собственный список сертификации. А вот первый пункт заслуживает отдельного внимания. Как выяснилось, для заказчика было важно, чтобы мы предоставили документ, который свидетельствует о грамотной работе нашей системы биллинга. На наше счастье, мы как раз примерно за год до того сертифицировали её в Минкомсвязи.

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

Вычислительные ресурсы

Диски

Сети

Объектное хранилище

ИБ

Резервное копирование

Биллинг

Чем кончилось

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

Если вдруг остались вопросы не для комментариев — моя почта NiVasilev@croc.ru

© Habrahabr.ru