«99,5%». Можно ли доверять декларируемым показателям времени работоспособности системы?

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


12:08 23.10.2017   |   2441 |   CIO Magazine, США

Рубрика Предприятие



При оценке облачного решения самый распространенный вопрос звучит так: «Сколько времени система может находиться в нерабочем состоянии?»

У большинства ведущих провайдеров облачных сервисов ответ один: не более 0,5% общего времени. Другими словами, продолжительность рабочего состояния системы (uptime) составляет 99,5%. Звучит весьма впечатляюще, но означает ли это, что ваша система действительно находится в работоспособном состоянии на протяжении 99,5% общего времени ее использования? Ответим коротко: нет.

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

Для того чтобы оценить потенциальное время простоя (downtime) и сравнить друг с другом различные предложения, нужно получить правдивый ответ провайдера на следующие вопросы.

1. Что понимается под плановыми простоями?

В месяце, который состоит из 31 дня, насчитывается 744 часа. Не вдаваясь в тонкости расчета провайдером процента продолжительности рабочего состояния, естественно было бы выполнить простейшие вычисления, в соответствии с которыми простой на уровне 0,005 составляет четыре часа в месяц. На первый взгляд все выглядит вполне приемлемым, но помните, что в формулах имеются уловки, и провайдер ими пользуются. Некоторые рассчитывают процент безотказной работы как фактическое количество часов рабочего состояния системы, деленное на количество часов в месяце — количество часов планового простоя.

В этом случае ключевой вопрос должен звучать так: сколько часов в месяц приходится на плановые простои? И вот здесь цифры могут варьироваться уже в весьма широких пределах. Один из ведущих провайдеров, например, заявил, что запланированное время нахождения системы в неработоспособном состоянии в течение месяца вследствие установки обновлений, исправления ошибок и проведения процедур технической поддержки составляет 40 часов. Таким образом, вполне приемлемые четыре часа разрешенного простоя в маркетинговой формуле превращаются в 44 часа, или почти два дня в месяц. Ловко, что тут скажешь!

2. Что не относится к плановым простоям?

После того как мы узнали, по какой формуле поставщики получают прекрасную статистику, резонно задать еще один важный вопрос: имеются ли для формулы планового простоя исключения?

Можно, конечно, надеяться на то, что ответ на этот вопрос будет отрицательным, ведь существуют соглашения об уровне обслуживания, согласно которым провайдер обязан обеспечивать декларированное время безотказной работы (пусть даже со своими хитрыми формулами!). Но вот неожиданность: у многих провайдеров действительно имеются исключения. К примеру, один из них заявил, что при заблаговременном уведомлении о переводе системы в неработоспособное состояние соответствующие часы в плановых простоях не учитываются. Таким образом, 44 часа ежемесячного простоя в нашем сценарии на практике могут обернуться абсолютно любыми цифрами.

3. Как отражается на плановом времени простоя выпуск масштабных обновлений?

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

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

Провайдеры без особого труда могут добиться формального соблюдения показателей, с гордостью указанных на их рекламных проспектах, но вовсе не факт, что 99,5% действительно превратятся в 99,5%. Будучи информированным покупателем их решений, для определения реального времени простоев вы должны задать ключевые вопросы, обсуждавшиеся в этой заметке, и запросить объективную статистику продолжительности рабочего состояния и простоев, не имеющую отношения к плановым простоям и исключениям из них. Выполнив ряд несложных расчетов, вы легко сможете привести всех провайдеров к общему знаменателю.


Теги: Управление ИТ Облачные сервисы
На ту же тему: