Как мы реализовали продукт, как он устроен
Многих российских предпринимателей материнские компании отключают от инфраструктуры. Они ищут альтернативу, чтобы продолжить бизнес. Поэтому на рынке увеличилась потребность в российской инфраструктуре и ресурсах. Компаниям, для которых ИТ – не профильное направление, выгоднее и проще получить инфраструктуру как сервис. Предложения по управляемому хостингу сейчас востребованы. В этой статье я хочу рассказать, как мы реализовали такой продукт, как он устроен изнутри.
Меня зовут Илья Попов, я генеральный директор и сооснователь компании «CommCloud». В проекте «Управляемый хостинг» мои задачи – стратегия, развитие, работа с клиентами и немного с технарями. Мой рассказ о проекте дополнили два наших архитектора – Кирилл Елизаров и Андрей Расстегаев. Именно они занимаются технической частью работы: подбором оборудования под проекты, развертыванием и поддержкой инфраструктуры, поиском новых решений. Они превращают желания и идеи клиентов в готовые проекты.
Как мы работаем над проектом
Над проектом «Управляемый хостинг» работает весь технический блок нашей компании: специалисты техподдержки из двух городов, поддерживающие постпродакшн системные администраторы, команда по запуску - архитекторы. Первое время все делается руками архитекторов, а потом передается команде поддержки.
Сначала происходит «сбор хотелок» – клиент общается с руководителем проекта в формате интервью. Нам важно получить все требования к системе со стороны клиента, чтобы на их основе архитекторы готовили проект.
Дальше эти требования поступают техническому блоку. Архитекторы критикуют собранную информацию, готовят дополнительные вопросы и уточнения по ней. Когда все вопросы заданы, ответы получены и проект подготовлен, начинается работа коммерческого блока.
Наши коммерческие специалисты дают оценку. На этом этапе происходит оптимизация проекта, если это нужно. Все зависит от требований и финансовых возможностей клиента. На старте у заказчика максимальные требования к безопасности, отказоустойчивости, регуляторным моментам, пропускным способностям, резервированию. Потом он видит цену и понимает, что хочет дешевле. Тогда мы вместе с заказчиком оптимизируем смету с точки зрения реальных потребностей бизнеса.
Когда оптимизация закончена, мы согласовываем финальный вариант проекта, подписываем документы, утверждаем сроки запуска. Отстраиваемся от даты запуска, нужной клиенту, если надо сделать заранее. Рассчитываем время на тесты.
Теперь можно переходить к реализации проекта. Департамент закупок получает коммерческие предложения от поставщиков железа и софта. Подключается департамент поддержки, им потом с этим проектом работать.
Между реализацией и запуском в продакшн мы проводим проверки: нагрузочное, инфраструктурное, аварийное тестирование, тесты по ИБ, тесты на проникновение. В итоге предоставляем комплексный отчет заказчику. В документах указаны уязвимости, сбои, время на аварийное восстановление. План аварийного восстановления у нас с учетом рисков, которые согласовали в начале обсуждения проекта. В процессе тестирования мы проверяем, сколько времени на самом деле нам понадобится, чтобы все это восстановить.
Устраняем пробелы, если они найдены. Проводим повторное тестирование, показываем результаты заказчику. Когда проблем больше нет, передаем проект в продакшн – и клиент может зарабатывать деньги.
За что мы отвечаем
Мы за прозрачность и объективность. Приветствуем контроль со стороны заказчика – технический специалист или ответственный менеджер из компании клиента обычно участвует в процессе тестирования. С нашей стороны процесс контролирует руководитель инфраструктуры, который несет ответственность за проект.
Ни у кого из наших сотрудников нет полного доступа к данным клиента, каждый знает только необходимое для выполнения своих задач. Все изменения фиксируются, согласовываются. Сисадмины и архитекторы не могут по своей воле внести изменения. Администратор баз данных отвечает за производительность, доступность, работу БД. Анализирует логи, указывает на ошибки, которые всплывают. В сами запросы не вникает. Действует соответственно своим правам доступа.
Что у нас с информационной безопасностью
План поддержания информационной безопасности мы разрабатываем на стадии проектирования. Спрашиваем про чувствительность данных - насколько их нужно защищать, чтобы не тратить деньги заказчика зря. Прислушиваемся к тому, что просит клиент. Нам важно найти компромиссное решение: обезопасить все критически уязвимые данные, при этом уложиться в бюджет заказчика. Обычно сначала заказчики хотят максимально защитить все данные, но узнав цену, начинают обсуждать, от чего можно отказаться.
Если клиенту действительно нужен полностью закрытый периметр и он готов оплатить это – мы сделаем. Но такая необходимость возникает редко. Для интернет-магазина, например, полностью закрытый периметр точно не нужен. Здесь можно сделать доступ в админку только из закрытого контура при двухфакторной аутентификации – и будет достаточно.
Тестирование на проникновение может проводить пентестер со стороны заказчика, мы это только приветствуем – для объективности. К тому же чем больше тестов, тем надежнее безопасность, за которую мы отвечаем. Тестирование происходит на полной копии продакшна, но без боевых данных. Нет необходимости делать это часто. Мы работаем с международными компаниями «Volkswagen», «AIG» - они проводят тестирование на проникновение раз в год. Этого достаточно.
Перед запуском системы в коммерческое использование мы можем провести тестирование контура клиента для аттестации в соответствии с требованиями любого законодательного органа или гражданской, международной организации. Так заказчик сможет получить лицензию и спокойно начать бизнес, в том числе финансовый.
У нас кастом под каждого заказчика. Потому что каждый бизнес уникален. В ИБ шаблонный подход – это хорошо, но есть и специфические риски у любой компании. Например, внутренняя уязвимость – кто-то из сотрудников может оказаться злоумышленником. Мы более гибкие, чем публичные облачные провайдеры, которые просто предоставляют инфраструктуру и не несут ответственности за данные заказчика. Мы заинтересованы в безопасности и развитии бизнеса клиента, потому что это наши деньги: у нас предусмотрены штрафы вплоть до возмещения убытков.
Не забываем про резервное копирование
Выясняем: что, куда и как хочет копировать заказчик. Есть краткосрочные бэкапы и долговременные на ленточных накопителях. Мы можем хранить информацию хоть вечно, но это влияет на стоимость. Поэтому ищем оптимальные решения: что-то храним ограниченное время, а что-то на долгосрочное хранение - в архив.
Инфраструктура работает в одном ЦОДе, а бэкапы хранятся в другом. Это важно для безопасности. Если что-то случится, мы точно сможем восстановить данные. Бэкапирование производим и в виде отдельных файлов, и целиком виртуальных машин для более быстрого их разворачивания при необходимости.
Как планируем аварийное восстановление
Любое железо, любой софт может отказать, мы его резервируем. План зависит от тех рисков, которые мы согласуем с заказчиком. Чем меньше время восстановления, тем сложнее архитектура и дороже решение. Важен адекватный подход.
Сработала система мониторинга, оповещение о сбое, реагируют ответственные люди – все вместе это занимает около 15 минут. Дальше – диагностика, самый долгий этап – до 95% времени. На нем можно сэкономить время, переведя бизнес клиента на резервную копию - он заработает, а мы на оставшемся стенде продолжим разбираться, в чем проблема.
Если нужно успеть меньше чем 30 минут, подойдет автоматическое восстановление, переключение на резерв. Это быстро, но дорого. Когда для клиента 30 минут – это долго, он хочет снизить время восстановления, стоимость и сложность проекта будут расти в геометрической прогрессии. Инструменты, нужные для быстрых решений, очень дорогие.
Часто система может простоять час – и мы её восстановим. Мы развернем реплику в нашем резервном ЦОДе, в случае необходимости переключим на нее боевой трафик и бизнес клиента продолжит работать без потерь.
Если клиент готов подождать 2-3 часа, но заплатить меньше, то ему не нужен резервный стенд. Мы можем диагностировать и запустить систему без дополнительных ресурсов.
По желанию заказчика можем сделать так, чтобы оба ЦОДа были под нагрузкой – это гарантирует моментальное восстановление, но стоит дорого. А если проблема в приложении, а не в инфраструктуре? На такой случай изменения в софте вносятся в два ЦОДа не одновременно, а последовательно.
Максимально безопасная схема - разместить инфраструктуру в одном облаке, резервное копирование делать в другое. Самостоятельно это организовать хлопотно: надо договариваться с двумя облачными провайдерами, которые конкурируют друг с другом. У нас два независимых коммерческих ЦОДа, мы договорились за заказчика. Да, здесь узкое место для клиента – это мы. Но у нас хорошая репутация в финансовой сфере, у наших инвесторов тоже. Мы одними из первых в России стали предоставлять облачный сервис банкам и страховым. Нам доверяют.
Как происходит учет изменений
Учет изменений происходит в Jira. Мониторинг конфигурации в автоматическом режиме. Автоматически создаются задачи, если срабатывает триггер. Триггеры мы самостоятельно настраиваем, допиливаем под каждую систему после тестирования до ввода в продакшн.
Клиент получает отчеты так, как ему удобно. Он может зайти на портал и посмотреть в Jira информацию только по его системе. Может получать ее по электронной почте. В отдельных случаях мы готовы сделать даже в письменном виде. Иногда даем доступ в нашу систему мониторинга и алертов, тогда клиент видит сообщения в наших чатах и может задать вопрос.
Взаимодействие с техподдержкой: мессенджеры, телефоны, электронная почта. Заказчик может оставить заявку в Jira, она автоматически маршрутизируется. Клиенты пишут простыми словами, что у них не работает и потом наблюдают за статусом своего запроса. Цепочка прозрачна для клиента.
Что еще мы можем делать
Комплекс мер, рассчитанных при разработке проекта, дает нам возможность гарантировать доступность приложения клиента. Мы рассчитываем возможности допустимых сбоев, скорость восстановления. Подбираем оптимальный вариант для каждого клиента.
На стадии проектирования спрашиваем, будут ли производиться доработки, будет ли изменение самой системы. Если да – а всегда да – то мы развертываем тестовый сервер, девелоперский клон, распределяем роли.
Были кейсы, когда мы предоставляли заказчику нашу команду для тестирования его приложения. Мы можем участвовать в жизненном цикле разработки ПО, выступать на стороне заказчика, контролируя и взаимодействуя с разработчиками.
Что в итоге
Мы реализуем ИТ-инфраструктуру в виде сервиса. Заказчик использует результат для оптимизации бизнеса.
Конечно, клиент мог бы реализовать все то же самое и сам. Для этого нужны большие вложения с самого начала, команда специалистов. Потом ему самому поддерживать это все. Часто компании, не специализирующиеся на ИТ, вкладывают много денег на старте, а потом недостаточно заботятся о поддержке инфраструктуры. Мы предлагаем сервис: так компания, для которой ИТ – не основная часть бизнеса, получает качественную инфраструктуру и стабильную поддержку.