Поделиться
Владимир Свиридов, IBS Datafort: SLA должен быть комплексным!
Если договор на оказание облачных услуг — документ, которым интересуется не только ИТ-департамент компании, но и экономисты, юристы и другие специалисты, то прилагаемое к договору соглашение об уровне обслуживания SLA — вотчина исключительно ИТ-подразделения. Оно насыщено различными терминами и оговорками, и именно от них зависит, какого качества услугу получит заказчик. О тонкостях и хитростях SLA рассказывает директор по развитию инфраструктуры IBS Datafort Владимир Свиридов.
Понятие комплексного или «сквозного» SLA
Инфраструктура как сервис (IaaS) — это многогранный продукт, который включает в себя не только вычислительные мощности, но и каналы связи, панель управления, защиту от DDoS-атак и другие компоненты. Соответственно, SLA должен описывать доступность каждого из них.
Именно такой подход реализован в SLA на облачные сервисы IBS Datafort. Мы называем его комплексным или сквозным. В нем последовательно изложены параметры доступности облачных вычислительных сервисов, услуги передачи данных, обслуживания виртуальных машин, восстановления виртуальных машин и других услуг. Иными словами, сквозной SLA распространяется не только на IaaS, но и на все дополнительные сервисы, включая доступ к облаку — L2/L3 VPN каналы, скорость интернет-соединения и другие параметры.
Сквозной SLA позволяет оценить сразу все нюансы работы с тем или иным провайдером. Многие компании заявляют хороший SLA на IaaS. На его основе можно сделать вывод о надежности провайдера. Но если проблема возникнет на уровне доступа к инфраструктуре, то это равносильно тому, что облако не работает: виртуальные машины без внешнего доступа никому не нужны, поскольку ценится именно круглосуточная доступность систем заказчика.
О важности метрик
В ходе изучения SLA следует обратить внимание на то, чтобы в SLA был прописан не только уровень доступности, но и гарантированные технические характеристики платформы. В случае IaaS это параметры CPU Ready, RAM Swapped, latency для каждого типа Storage и другие.
Условно говоря, процессоры могут быть доступны, но Ready Time (время ожидания процессора) будет зашкаливать. На практике это выльется в медленную работу приложений заказчика. Или другой пример — дисковое хранилище доступно, но время отклика выше заявленных значений. Опять-таки сервисы заказчика будут «подвисать».
Для описания таких ситуаций используется термин «деградации сервиса». В случае деградации IaaS, фактически, остается доступной, но характеристики инфраструктуры ниже заявленных (деградировали). Так как конечный заказчик покупает не просто облако, а облако с конкретными характеристиками, то деградация суть некачественное оказание облачных услуг, и она также должна компенсироваться провайдером.
В SLA Datafort деградация — это вторая по значимости категория проблем с облачной инфраструктурой после ее полной недоступности. Для каждого типа сервиса у нас определен свой граничный уровень деградации, по достижении которого клиент имеет право рассчитывать на компенсации.
Что касается базовой метрики — заявленного уровня доступности, то на практике он всегда выше анонсированного значения (99,95%). Такой результат достигается за счет того, что мы самоотверженно следим за качеством работы инфраструктуры, постоянно обновляем и совершенствуем ИТ-оборудование и программное обеспечение.
Тонкости определения времени простоя
Любые компенсации, на которые может рассчитывать клиент, рассчитываются исходя из времени простоя. И тут возникает вопрос — с какого момента начинается простой? Хорошо, если недоступность сервисов фиксирует автоматика. Хуже, если для этого нужно открыть тикет в техподдержке.
Разница в том, что система мониторинга зафиксирует недоступность практически мгновенно. А на ручную идентификацию сбоя и ручное написание тикета требуется определенное время. Более того, некоторое время потребуется и на регистрацию данного тикета провайдером.
Причем в том же SLA может быть указан срок регистрации сообщений и 10, и 20, и даже 30 минут. Таким образом, по причине элементарной бюрократии почти часовой простой IaaS не будет засчитан просто потому, что не был оформлен надлежащим образом.
Обращаясь к практике Datafort, отмечу, что простой отсчитывается с момента обращения, но в случае проблем с инфраструктурой все аварии фиксируются системой мониторинга, автоматически открываются трабл-тикеты (trouble – тревога), и расчет недоступности ведется именно с этого момента.
Кроме того, в нашем SLA есть пункт, который говорит о том, что разногласия о времени недоступности решаются переговорами сторон. Таким образом, представив свои логи, клиент может оспорить данные нашей системы мониторинга.
Впрочем, на практике подобных ситуаций не возникало: мы никогда не отрицаем проблемы, которые были вызваны некорректной работой платформы, и идем на уступки клиенту в части компенсаций, так как наша главная задача — удовлетворить потребности клиента и сохранить партнерские отношения.
А будет ли профилактика
Один из ключевых моментов — прописана ли в SLA длительность профилактики и порядок уведомления о ней. Многие провайдеры скрывают эти сведения, анонсируя полное отсутствие профилактических работ. Возможно ли это?
В качестве примера можно привести любой современный смартфон. Каждое приложение на нем требует регулярных обновлений, или оно перестанет работать. Обновление занимает несколько секунд, но все-таки это недоступность. Прошивка телефона также обновляется чуть ли не ежемесячно, а для этого он должен корректно завершить все процессы, обновиться и включиться вновь, что также является простоем.
В SLA IBS Datafort честно указана максимальная длительность профилактики, причем она одна из самых коротких на рынке: всего 4 часа в квартал (1 час 20 минут в месяц). Фактические работы длятся на порядок меньше, и мы в обязательном порядке предупреждаем о них не менее чем за 72 часа.
Другие важные моменты
Помимо вышесказанного, конечно, в SLA должны быть прописаны сроки решения зарегистрированных обращений, их типы и четкое описание, какой тип обращений при каких проблемах назначается.
Также следует настоять на фиксации контактов эскалационных менеджеров. У клиента всегда должен быть личный телефон менеджера, который его ведет. А на случай отсутствия менеджера, например, в период отпуска, указываются телефоны замещающих его специалистов. Кроме того, передается контакт руководителя клиентской службы.
И не лишним будет наличие ежемесячных сервисных отчетов, в которых будут зафиксированы фактические технические показатели по итогам месяца.
Не SLA единым
Каким бы щедрым ни был SLA, ответственность провайдера ограничена стоимостью облачных сервисов, выкупленных у него. При этом потери бизнеса ввиду простоя инфраструктуры, как правило, значительно (на порядки) выше стоимости облачных услуг. Таким образом, задача заказчика — не столько надеяться на компенсации по SLA, сколько самостоятельно предпринять разумные шаги по увеличению надежности ИТ-инфраструктуры.
В первую очередь это достигается использованием кластеризации на уровне конечных приложений и сетевых аплаенсов (appliance — образ виртуальной машины) клиента, которые стоят на «границе» облака.
Также имеет смысл резервировать и само облако — использовать два сегмента облака в разных ЦОД. Мы арендуем площади в трех дата-центрах уровня надежности Tier III. Это позволяет нашим клиентам, с одной стороны, работать с одним облачным провайдером и получать услугу из одних рук (в буквальном смысле, пользоваться службой одного окна), а, с другой стороны, разворачивать по-настоящему надежную ИТ-инфраструктуру для своего бизнеса.
Резервирование на уровне облака в совокупности с первой рекомендацией — кластеризацией — обеспечивает максимальную надежность за счет географического резервирования всей инфраструктуры. При этом каждый наш ЦОД является полностью независимым и даже в случае аварии на магистрали или в одном из них облако продолжит работу за счет инфраструктуры другого центра обработки данных.
Еще один вариант — это заказ услуг резервного копирования и репликации или полноценного Disaster Recovery (DRaaS). И здесь также важно физически разнести боевой сервис и его резервные копии по разным дата-центрам.
Качество поддержки и уровень ИТ-специалистов провайдера
Наконец, обратим внимание ещё на один момент. В большинстве случаев переход или развертывание новых сервисов в облаке выполняется клиентом не в одиночку, а командой, состоящей из сотрудников клиента и провайдера. Успех проекта во многом зависит от взаимопонимания всех членов команды.
Отсюда можно вывести еще две рекомендации: формулировать задачу будущего облака максимально открыто и емко (при необходимости, можно подписать соглашение о неразглашении), чтобы провайдер зарезервировал нужную инфраструктуру, а также оценить уровень компетентности ИТ-специалистов провайдера, прогрессивность и оптимальность предлагаемых решений на этапе пресейла.
В конечном итоге, данные пожелания также будут способствовать повышению надежности и минимизации рисков сбоев ИТ-сервисов клиента, работающих в облаке провайдера.
Короткая ссылка
