Меня зовут Александр, и я, среди прочего, занимаюсь тем, что общаюсь с теми, кто только-только узнал про облака. И хочет перевести туда часть своей инфраструктуры. Чаще всего это производства не из Москвы, которые совсем недавно узнали про виртуализацию как таковую.
В половине случаев это не самые развитые в ИТ ребята. Некоторые живут в прошлом веке. К ним приходят знакомые, рассказывают, что есть облачные провайдеры. Потом начинается общение с нами.
Мой любимый эпизод — это просчёт цен на новое оборудование в офисе (стойка из серверов дешёвого сегмента или переделанных ПК) и облака:
— Так. Лицензия на гипервизор. Зачем за неё платить? Мы никогда лицензию не покупали… Россия же, хе-хе! Поддержка на железо в стойке? К чёрту, без поддержки обойдёмся, у нас админ шарит. Что там ещё, бекап? У нас уже есть палёный...Еще есть популярный миф, что если сервер в офисе, то, когда придёт проверка, можно взять и залить его кипятком из чайника, и тогда данные никто не заберёт. Он настолько распространён, что иногда мне кажется, что на нём прямо держится отечественный рынок low-end серверов.
Как компания понимает, что к облаку надо присмотреться
Речь о двух вещах: деньгах или ответственности.
С деньгами все очевидно: перенос инфраструктуры на облачного провайдера позволяет экономить. Это понимает почти каждый. Правда, обычно про это думают в тот момент, когда что-то ломается. Финдиректор вспоминает слова «финансовая ответственность» и проводит свой подсчёт. Видит, что услуга стоит 7 миллионов, а то же самое внутри компании — 10 миллионов в год. Плюс есть финответственность на уровне SLA.
Ещё ответственность — это вопрос того, что кто-то будет отвечать за инфраструктуру, кроме админа или CIO/CTO. Очень часто, если бизнес встаёт из-за ИТ-поломок, это проблема именно ИТ-руководителя. То, что он два года назад говорил, что хорошо бы докупить пару жёстких дисков в сервер на место изношенных в RAID, или то, что он настаивал на включении поддержки по железу в бюджет, а денег ему не дали, это частые истории.
Получается, что инструментов контроля рисков его лишили, а ответственность за эти риски оставили.
Поэтому запрос чаще всего приходит либо от финдиректора, либо от главы ИТ-подразделения. Оба примерно представляют, что хотят, но на встрече нужны уточнения. Дальше происходит следующее: они рассказывают, что за потребности есть, а мы пытаемся перевести это в некое подобие технических требований и примерно обсчитать. На этой стадии обсуждения, что и кому нужно, обязательно участвует человек, который может разговаривать с людьми, понимает потребности бизнеса и при этом разбирается в технике. Как правило, это бывший инженер, который развивался по ветке организационных навыков. Его функционал — аналитика: поговорил и выяснил потребности. Подумал, как эти потребности закрыть нашими решениями. Сформулировал предложение по закрытию и уже презентовал, представил, обосновал, доказал, почему оно правильное.
Потом начинается стадия «а почему вы хорошая компания?». На самом деле, этот вопрос тоже про ответственность, вернее, про ее перенос на крупную компанию Это такой дополнительный неформальный, но очень важный аргумент. Потому что, если что-то сломается! и подрядчик маленький, это одно. А если что-то сломается и подрядчик большой, это уже не косяк руководителя, а практически форс-мажор. Выглядит это так: «Я нашёл большую компанию, она услугу оказывает. Если она лажает, это их надо дрючить, а не меня. Их выбирала конкурсная комиссия на основании факторов...». Понятно, что всё равно руководителя, в случае простоев, дрюканят, но корпоративный мир так устроен, что крупного подрядчика наказывают куда меньше. Потому что вина как бы на внешних обстоятельствах. Это как когда магистральный провайдер в очередной раз каналы роняет, это не айтишник виноват, это непреодолимые силы природы.
А дальше в процессе согласования предложения неминуемо начинаем разбирать мифы.
Мифы
- Берём Мерседес «Гелентваген» и ставим на него половину запчастей от УАЗика. Включая тормозные колодки. В целях экономии на отдельных компонентах. Получается отличная машина модели «Гелентуазен». Мы примерно так называем конфигурации, где по вычислительным ресурсам всё хорошо, а вот для СУБД берутся диски впритык по скорости: те, которые обычно предназначены для архивного хранения или хранения «холодных» данных. Я не знаю, какая именно алхимия действует в голове у ряда людей, но снижение конфигурации именно на СУБД в последний момент для уменьшения общей сметы — это частый случай. «Гелентуазен» снаружи выглядит как крутая тачка, только тормозить не может. С СУБД история обратная. Тормозить она может.
- Часто заказчик приходит и говорит, что у него важные данные. И ему нужна аттестация по определённому классу. Например, по 1К. И выкатывает требования для такой инфраструктуры. Во-первых, 1К не используется много лет. Во-вторых, вполне может оказаться, что у него данные третьей категории, и просто он об этом не знает, потому что кто-то либо некомпетентен, либо не умеет правильно оформлять документы, либо решил перестраховаться. Бывает, что юрист вооружается набором мифов и их уверенно отстаивает.
- Скорость масштабирования. Есть ещё два типа заказчиков, которые не всегда умеют считать затраты на железо. Это научно-исследовательские институты и розница. У розницы бывают крупные сезонные пики, к которым она не всегда готова даже на уровне работы сайта. А у НИИ бывают проекты с большим просчётом. Например, они могут считать геологоразведку месяц, а ещё три месяца их железо в стойке будет простаивать. Поэтому тоже финдиректор начинает смотреть на утилизацию и хватается за голову. Пики есть ещё много у кого: на платежных агрегаторах, у транспортников в сезон. И, если они есть, всегда надо думать о том, что вместо покупки нового железа, возможно, стоит посчитать частичную миграцию. У этих же компаний очень долгий шаг планирования. Железо покупается 3 месяца, а иногда оно нужно прямо вчера. Но нет: 2 недели — анализ, 2 месяца — тендер, месяц — контрактования. Потом доставка. Если повезёт, пусконалаженное — через 3 месяца. Но не все такие опытные. В облаке же многие вещи делаются на уровне «сегодня гарантийное письмо – завтра развернули в два раза больше виртуальных машин». Естественно, так не везде. Если нужно нарастить мощности вдвое, не все готовы работать по гарантийке. Лучше выяснять этот вопрос заранее.
- Средний и малый бизнес предполагает, что, когда придут проверяющие органы, самое безопасное — это кладовка, где стоит стойка, а рядом кипит чайник или лежит пожарный молоток. Дальше сервер заливается водой, или жёсткий диск разбивается в клочья. Мы в таких случаях просто показываем 30 машзалов, в каждом — 100 стоек. Угадаете, где облако, и какие конкретно стойки относятся именно к вашим данным? И как их так вынести, чтобы не уронить чей-нибудь банкинг или ИТ госпредприятия? Отделить, где именно чье, физически невозможно. А изъять все и сразу — инцидент национального масштаба. А ещё, даже если вдруг кто-то всё изымет, из оборудования, которое ты вытащил, ещё надо собрать что-то работающее. И это, скорее всего, не получится.
- «Вы не отдадите мои данные». Если один любой заказчик, даже мелкая булочная с чеком 5 тысяч рублей в месяц, вдруг когда-нибудь не сможет забрать данные, или мы их украдем, или потеряем, или выложим в открытый доступ, или кому-то сольём, или как-то иначе дискредитируем, нам, как облачному провайдеру, хана. Невозможно скрыть факап, если ты публичный сервисный провайдер. Поэтому ты прикладываешь усилия, чтобы его не было. Ну и сразу про уровень вмешательства: мы не ходим дальше гипервизора в принципе, то есть, даже не знаем, лицензионные ОС у заказчика или нет. И не должны знать. И не спрашиваем.
Тестирование, грабли и выводы
Перед тем, как подтвердить старт проекта, заказчик обычно начинает активно интересоваться другими предприятиями из смежных сфер: они созваниваются, меняются впечатлениями, ударяют друг другу по печени дорогим алкоголем, обмениваются уже искренними впечатлениями и берут минимальный набор на тесты. Некоторые сразу берут всё, потому что справедливо предполагают, что чем больше наш охват по услугам, тем более комплексная ответственность, и тем проще с нас спросить по обязательствам.
Вот, вроде, все согласовали, все вопросы задали, ответы получили — пора начинать тестовое внедрение. Тут на сцену выходят исполнители среднего уровня, у которых совсем другая, отличная от топов мотивация и образ действий.
Самая крупная «подстава» на этой стадии: бывает, что ИТ-директор хочет, а его подчиненные — нет. Потому что было 50 ИТ-специалистов, а после переезда останется 30. Облако в некоторой степени подменяет их работу, и они боятся её потерять. И дальше начинаются традиционные палки в колёса. Увы, но то, что после перехода на облачную инфраструктуру начинаются сокращения, это факт.
Тут я не смогу удержаться от лирического отступления. На мой взгляд, продвинутый подход, свойственный обычно западным компаниям, когда ИТ-отдел — это не просто что-то вроде уборщиц, а полноценное бизнес-подразделение, это большой рывок на рынке провайдеров виртуализации. Почему? Потому что два фактора:
- ИТ-отдел выставляет внутренние счета департаментам, и в облаке может точно сказать, кто и сколько потребил ресурсов (за исключением ресурсов маршрутизации типа оплаты ВМ роутеров, но это несколько процентов).
- У ИТ-директоров появились задачи — увеличить эффективность бизнеса. Или повысить контроль. У них даже цели в деньгах от бизнеса: снижение рисков, переход в опекс, повышение производительности труда. Поэтому сразу все сэкономленные деньги и несработавшие риски повышают премию, а она может быть 2-3 годовых оклада, если всё хорошо. Поэтому сразу начинается максимально эффективное использование мощностей.
Ну, и последний миф в том, что в облако обязательно надо. Нет, не всегда: есть задачи, когда всё решается именно стойкой в офисе. Или же есть компании, у которых бюджетирование такое, что проще заложить покупку железа раз в 3 года и поддержку сразу, нежели операционные расходы. Ну, и, конечно, есть люди, которые всегда жили на физическом железе и просто не хотят что-то выносить за периметр организации: для них тоже важны свои стойки. Где-то на границе этих задач проходит прослойка мифов, и эти мифы иногда довольно активно подпитываются продавцами серверов.
Текст подготовлен Александром Кузнецовым, руководителем направления управления стратегических продаж Техносерв Cloud.