Да, облачные технологии и услуги позволяют получать вычислительные и коммуникационные сервисы «в любом месте и в любой конфигурации», но тем не менее, для того чтобы вы могли получить эти услуги, где-то должны находиться и функционировать и серверы, и системы хранения, и телеком-оборудование.
Здесь стоит отметить, что построение ЦОДа даже в соответствии с рекомендациями и стандартами Uptime Institute и аналогичных огранизаций не обеспечивает его полной отказоустойчивости, отсутствия единых точек отказа и, как результат, непрерывности его функционирования в ходе эксплуатации. А последнее – непрерывность предоставления услуг – ни много ни мало требование современного мира. Так или иначе, но решать эту проблему нужно, и на наш субъективный взгляд, это можно сделать как минимум двумя способами, не исключая при этом ни один из них.
Первый – модный, но дорогой. Это строительство и/или аренда ЦОДов (обеспечивает катастрофоустойчивость), аренда стойкомест в коммерческих дата-центрах, непосредственно вычислительных мощностей на разных площадках и агрегация этого «хозяйства» в единое вычислительное и информационное пространство.
Второй – простой, как старые растоптанные кроссовки. Для того чтобы автомобиль надежно ездил, не обязательно каждые 100 км ставить на обочине подменный авто. Достаточно вовремя выполнять плановые сервисные работы и смотреть немного вперед: сделать профилактику потенциально слабых узлов, возможно, некоторые из них заменив заранее, до того как они вышли из строя.
При этом, хотя старые кроссовки нам и знакомы, они могут таить сюрпризы, особенно в период экономии, тщательного бюджетирования расходов, сокращения непрофильных на первый взгляд трат. Никоим образом не отрицая пользу современных, в том числе облачных, решений, повышающих надежность и доступность приложений, нам хотелось бы обратить внимание на некоторые подводные камни именно наших «кроссовок». Это три, на наш взгляд, наиболее распространенные ошибки в подходах компаний к сервису. Их можно свести к следующим тезисам:
- Резервирование ИБП/кондиционеров/дизелем есть? Есть. Тогда экономим на обслуживании – пусть работает. Когда сломается, починим.
- Сервисный контракт на обслуживание заключается с минимально разумной периодичностью в обслуживании, а то и с неразумно длительными перерывами между сервисными работами. При этом закладывается крайне жесткий SLA на время реакции и/или прибытия инженеров, а также устранения неисправности.
- Говоря о плановом сервисном обслуживании – контракте, компания пытается заложить в него гарантии работоспособности ЦОДа, с одной стороны, регламентируя время простоя (как планового технологического, так и внепланового аварийного), с другой – выставляя неприемлемые санкции даже за частичную деградацию в работе инженерных систем. Естественно, в этой ситуации обе стороны в первую очередь озадачены расчетом и калькуляцией рисков, а не вопросами качественного обслуживания как процесса.
Думаем, опытные автовладельцы смогут провести аналогии с автомобилем. Если упростить, наши тезисы выглядят следующим образом:
- Катаемся, пока не встанет. После поломки – как повезет.
- Катаемся строго по сервисной книжке (но тогда через 3–4 года машину лучше продать).
- «Каско + подменный автомобиль в комплекте». Сколько на рынке стоит эта услуга?
Возвращаясь к инженерным системам, стоит отметить, что все три подхода в определенной своей части имеют право на жизнь. Более того, комплексный подход к сервисному обслуживанию инженерных систем и заключается в создании наиболее пропорционального, сбалансированного предложения. Какими особенностями оно может и должно отличаться?
Во-первых, по всем системам компания должна получать одну точку входа для взаимодействия и единый, соразмерный SLA. Во-вторых, и заказчик, и исполнитель должны исходить из того соображения, что крайности невыгодны ни тому, ни другому. Редкое обслуживание – это поломки и простои, гарантии работоспособности – это высокая стоимость. Истинное понимание и формирование предложения по требуемому уровню сервиса может родиться только в процессе диалога равных сторон. В-третьих, квалифицированный исполнитель может и должен при необходимости предлагать структуру взаимодействия. Типовое слабое место – так называемая «точка принятия решения».
И наконец общее место. В процессе разработки и согласования сложных сервисных контрактов возникают две стороны проблемы: техническая фактология и юридические формулировки. Специалистов, в равной степени разбирающихся в обеих предметных областях и способных сопоставить и одновременно оценить риски и технические, и юридические, не очень много. У компании-заказчика – тем более.
Не стоит излишне усложнять технические документы и соглашения, прописывая все мыслимые и немыслимые условия, предположения и варианты. Жизнь обычно богаче на форс-мажоры, чем наша фантазия, и ничего, кроме пустой головной боли, эти усложнения не приносят. Хотя, да, они выглядят красиво и предусмотрительно. Многочисленные примеры из практики, часть из которых проходит на грани между здравым смыслом и возможными серьезными проблемами как для непосредственных участников процесса (сотрудников), так и для организаций (юридических лиц), только подтверждают это.
О сервисе можно писать книгу, с примерами того, как надо и не надо делать, разбирая конкретные случаи и неисправности, описывая предпосылки или скрытые злонамеренные действия персонала. Но для того, чтобы двигаться в правильном направлении, достаточно спокойного, адекватного взгляда: впереди поездка, и к ней надо подготовиться. Вам сделать ТО и профилактику или поставить подменные автомобили по дороге?