Игорь Мызгин (Servers.ru)
Буду рассказывать про провайдеров дата-центров и как выбрать оптимального. Почему оптимального, расскажу чуть позже.
Я расскажу о том, что такое дата-центр как бизнес (это мое определение, которое предлагаю обсудить); какие услуги оказывают дата-центры; что нужно потребителю услуг от дата-центра; как правильно сравнить несравнимое. Также я предложу алгоритм, который, я считаю, помогает выбрать провайдера дата-центров лучше, чем алгоритм, который обычно используется большинством людей, которые пытаются купить услуги дата-центра.
Два переезда — один пожар. Берем какой-то проект — несколько десятков серверов, IP-адреса, есть DNS’ы. Мы хотим это куда-то резко перенести. Перенос среднего и крупного проекта без down-time — это тяжело, не всегда это получается быстро. У каждого, наверное, есть опыт, как он это успешно перенес или перенес успешно, но не до конца. Соответственно, ходят разные легенды, когда люди перевозили физику, когда люди что-то не так делали в DNS’ах, но два переезда — один пожар — есть такая проблема.
Вторая проблема — невозможность проверить качество услуги дата-центра до того, как ты некоторое время дата-центром попользуешься. Поэтому вариант такой, что «мы сначала пойдем в дата-центр 1, попробуем с ними поработать, нам чего-то не понравится, мы переедем в дата-центр 2, там попробуем, поработаем, нам тоже не понравится, мы идем в дата-центр 3, и там все нам понравится» — такой вариант очень болен, потому что два переезда — один пожар.
Зачем мы говорим о том, как правильно выбрать дата-центр? Потому что это не самая простая задача, это не самая простая тема.
Почему я рассказываю про это? Потому что уже 15 лет я занимаюсь дата-центрами — я их эксплуатировал, я их строил, я их покупал, я продавал их услуги в России, я продавал их услуги не в России. Соответственно, у меня накопился некий опыт, который я попробовал отструктурировать в формате HighLoad Junior. Т.е. эта презентация довольно базовая, она вводная, условно говоря, и большую часть времени, наверное, я буду говорить очевидные вещи, но я просто их попробовал отструктурировать. Просто как некий опыт в формате обучающего трека HighLoad’a.
На рынке дата-центров есть три проблемы.
Первая проблема — все лгут. Что это значит? Это значит, что в любом дата-центре есть отдел продаж, есть отдел маркетинга, есть некие технические люди, которые этот бизнес создали. Они считают, что они в чем-то сильны. И они говорят: «Мы очень сильны в чем-то. И поэтому всем это очень важно, все остальное не важно». Любой маркетинг, рекламируя услуги своего дата-центра, будет гнуть на то, что у него получается лучше всего, по их мнению, все остальное они будут замалчивать. Т.е. не сказанная правда — можем считать, что они чуть-чуть лгут, поэтому я сказал так провокационно — все лгут. Т.е. на самом деле все приукрашивают хорошее, замалчивают плохое, и везде самопиарятся на чем-то таком. Все находят какую-то тему — «О, мы в этой теме должны быть сильны», — и ее пиарят.
Из этого есть логическое следствие — когда у вас в руках молоток, все превращается в гвозди. Любой дата-центр, как провайдер услуг имеет некую свою специализацию, некую наработанную практику, что-то любит, что-то знает, с чем-то умеет работать. И когда к ним приходит клиент и говорит: «Я хочу решить какую-то свою задачу», люди из дата-центров вспоминают, что они умеют, и пытаются то, что они умеют, натянуть на ту задачу, которая есть у потенциального клиента. Иногда это получается, иногда это не получается.
И третья проблема рынка услуг дата-центров — идеального провайдера и идеального клиента не существует.
Если сейчас вы спросите: «Вот этот дата-центр лучший?». Неизвестно. «А если сравнить вот этот дата-центр и вот этот дата-центр, то какой из них двоих лучший?». Неизвестно. Потому что не существует, условно говоря, критерия, по которому можно сказать, что вот этот дата-центр лучше, чем тот. Т.е. этот дата-центр, условно говоря, может быть, стоит 1000, а этот — 2000, один другого лучше? Один другого физически больше. В этом дата-центре может быть 10 провайдеров, а в этом — 12. 12 больше, чем 10, но кто сказал, что эти 12 лучше, чем эти 10 по уровню связанности? Из-за того, что дата-центр оказывает пул различных сервисов, и ни один дата-центр не оказывает сервисы одинаково хорошо, невозможно два дата-центра сравнить линейно, в матрицу как-то.
И точно так же двух одинаковых клиентов не бывает, все клиенты хотят что-то разное. Т.к. я последние лет 6-7 продаю услуги дата-центров, я задаю вопросы: «Что вы хотите сделать?» и «Зачем вы хотите это сделать?». Я получаю два ответа и периодически я не вижу логической связи между тем, что люди хотят и зачем это люди хотят. Но люди связь видят, они ее понимают, они ее объясняют — у людей есть логика.
Все мыслят по-разному, поэтому двух одинаковых клиентов не бывает, не бывает двух идеальных провайдеров, все друг с другом несравнимы. Даже если мы скажем, что дата-центр 1 лучше, чем дата-центр 2 и обоснуем это, и скажем, что дата-центр 2 лучше, чем дата-центр 3, и тоже это как-то обоснуем, то обосновать, что дата-центр 1 лучше, чем дата-центр, мы не сможем.
Таким образом, есть три проблемы рынка услуг дата-центров. Мне кажется, что они есть.
А как вы думаете, что такое дата-центр как бизнес? Из чего он состоит?
Я предлагаю следующее определение — дата-центр как бизнес состоит из двух элементов: первый элемент — это предоставление инфраструктуры в аренду; второй элемент — это отлаженные, стандартизированные процедуры оказания услуг сервиса и эксплуатации.
Зачастую люди помнят о первом пункте — предоставлении инфраструктуры в аренду. Т.е. условно говоря, какие-то люди взяли 100 млн. денег, купили большое здание, купили большие-большие ДГУ, большие-большие тяжелые БП, 20 тонн аккумуляторов, 30 тонн хладагентов, купили 1000 стоек, очень много денег проинвестировали, два года строили, получилось большое красивое помещение, где есть куча colocation — это инфраструктура в аренду. Поставили туда много-много серверов, тоже сдали их в арену — это тоже инфраструктура в аренду.
Но ключевая часть — вторая — чтобы люди с этим всем умели и корректно стандартизировано работали, чтобы это все эксплуатировалось корректно, чтобы на этом всем оказывался корректный сервис.
Поэтому я предлагаю определение дата-центра как бизнеса — это, во-первых, предоставление инфраструктуры в аренду, во-вторых, процедура оказания на этой инфраструктуре сервисов и услуг клиентам этого дата-центра как бизнеса.
Из этого определения я предлагаю некое количество следствий.
Следствие №1: размер имеет значение. Это следствие из того, что инфраструктура предоставляется в аренду, т.е. это финансово емкий инструмент. Люди взяли, условно, 100 млн. денег, проинвестировали в инфраструктуру, и эту инфраструктуру на модели помесячно или как-то иначе предоставляют некоему пулу своих клиентов в аренду. Действует закон экономики — чем компания больше, тем больше у нее доступа к рынкам капитала, тем легче им заимствовать, тем ей проще на эффектах масштаба жить и строить бизнес.
Следствие №2: у хорошего провайдера дата-центр — это основной вид бизнеса, у очень хорошего провайдера — это единственный вид бизнеса. Это следствие из второй части определения, из сервисов и из процедур эксплуатации. Потому что, если компания занимается доставкой пиццы, такси, call-центром, сетью салонов красоты, и попутно они в одном из салонов красоты открывают еще небольшой дата-центр, то я сомневаюсь, что процедуры сервиса дата-центра в такой компании будут как-то хорошо отлажены. Потому что и у акционеров там 33 дела, и выручка от этих дата-центров — 5% в отчетности… Нет смысла убиваться и делать идеальный сервис, если он не основной. Зачем, если он приносит там, 10% выручки?
Следствие №3: на длинной дистанции международные игроки всегда имеют преимущество перед локальными игроками. Мотивация очень простая, которая понятна всем. Мы все знаем, что кредит в Москве стоит, условно говоря, 20%. Мы помним, что недавно был большой скандал, что чешский сбербанк предлагал ипотеку под 2% годовых, а в России российский «Сбербанк» россиянам предлагал ипотеку под 20% с лишним. Потому что Россия, потому что в Европе и в мире деньги стоят дешевле, чем они стоят в России. Когда мы говорим о том, что дата-центр — это много инвестиций в инфраструктуру, а потом эта инфраструктура дается потребителям через механизмы оказания услуг, то часть, связанная с «много денег проинвестировать, а потом много лет возвращать», — это стоимость денег, она играет роль. Условно говоря, 4% там и 18% здесь — это большая разница. На пятилетнем отрезке накопленных процентов будет в 2 раза разницы.
4-ое следствие: персонал более чем важен. Потому что по статистике 60% отказов дата-центров — это человеческий фактор, т.е. как любой сложный механизм, пока человек что-то не специально, по ошибке, случайно не сделает, а оно — «ой». И все эти «ой» происходят из-за человека, из-за персонала.
Недавно у нас была проблема на амстердамском AIX’e, когда инженер случайно сделал кольцо 100 Гбитное, что-то куда-то не туда воткнул. В плане мира на два часа с Интернетом были проблемы, в России тоже были проблемы с Интернетом, и все думали, что опять проблемы у Ростелекома, потому что фейсбук не открывался, еще что-то не открывалось два часа. Разобрались, Ростелеком ни при чем, это в Амстердаме один инженер, один пигтейл не туда воткнул в один свитч. Поняли это сразу, но начался расколбас Интернета и, пока он устаканился, еще два часа прошло. Хотя вроде бы площадка там одна из крупнейших в мире, и персонал там — не кто попало.
5-ое следствие из этого определения: чем длительнее контракт на услуги, тем, скорее всего, вы, как потребитель, сможете выторговать себе более хорошие условия сотрудничества с дата-центром. Потому что дата-центру как бизнесу, предоставляющему инфраструктуру в аренду, выгоднее иметь наиболее длительный контракт на аренду.
Вот такие следствия из определения, которое я предлагаю.
Какие услуги дата-центров бывают? Здесь я нарисовал некий слоеный пирог — от самых базовых сервисов до сервисов, которые базируются на базовых. Сейчас я про каждый из этих сервисов что-то расскажу. Буду говорить базовые вещи, но их неплохо проговорить, потому что нас к этому обязывает формат мероприятия.
Colocation. На картинке, как раз, стойка, которую любят в рекламах показывать. Ряды стоек, фальшпол, все красиво моргает. Здесь все просто. Есть стойки, есть юниты в стойках. Они даются вам в аренду, вы арендуете фактически там одну стотысячную, одну миллионную часть дата-центра. В рамках этого юнита или этой стойки у вас предоставляется электроснабжение вашего оборудования, сколько-то ватт стоек, остальные ватты за доплату, соответственно, охлаждение — у вас все это работает. У дата-центра есть некий уровень отказоустойчивости, который определен его архитектурой, его дизайном, и вы знаете, что можете на это рассчитывать. Существует куча опций — видеокамеры, электронные замки, физическое ограждение стоек и прочее. Это такие услуги colocation, они более-менее стандартизированы, они всем понятны. Это базовая услуга — самая инфраструктура инфраструктур — с чего все дата-центры и начинаются.
Аренда оборудования. Мы вспоминаем определение дата-центра как бизнеса — дата-центр покупает много-много разных серверов, покупает к ним много дисков, памяти, прочих комплектующих и готов дать их вам в аренду, чтобы вы их арендовали для решения своих задач на месяц, год, два, три года. Собственником оборудования остается дата-центр, вы его некоторое время арендуете. Дата-центр обычно несет ответственность перед теми, кто арендует оборудование, за работоспособность оборудования, и обычно дата-центр обеспечивает замену блоков питания, жестких дисков, чего-то еще, что может отказать в сервере. А в сервере может отказать все, что угодно, включая даже рельсы, на самом деле. Соответственно, такая услуга тоже более-менее понятна, она существует.
Порты в Интернет. Здесь уже начинается более интересное. Сам по себе дата-центр без connectivity во внешний мир мало кому нужен, соответственно, начинаются вопросы про доступ в Интернет. Есть варианты — shared порт, dedicated порт, т.е. когда вся емкость ваша или вы, условно говоря, в коммунальном порту живете. Есть варианты, когда вам дают фиксированный порт в 100 Мбит или Гбит, или вариант, когда вы берете порт с каммитом, но вас тарифицируют по факту утилизации этого порта по burst’у.
Есть еще варианты, которые особенно популярны в облачных сервисах, когда вас тарифицируют не по полосе, а по количеству либо туда-сюда переданных байтов, либо только отданных байтов. Здесь начинаются разные нюансы, запомните их на будущее, когда будете общаться с любым облачным провайдером. Вы задаете вопрос: «Что вам продает облачный провайдер?». Вы думаете, что он продает вам МГц’ы процессоров, Гбайты памяти и Гбайты хранилища, но если посмотреть в их итоговые счета, на чем они зарабатывают, вы удивитесь, что обычно они продают вам байты Интернета, байты данных, ходящих между вашими виртуальными машинами, стораджами и прочее.
Соответственно, помимо портов Интернет, в рамках связанности есть услуги, связанные с прокидыванием вашей автономной системы, с предоставлением пулов подсетей IP-адресов в аренду и др. В Телекоме, если захотеть, можно только об этом говорить час, что дата-центр может вам продать, или что вы можете в Телекоме купить. У нас же обзорно, поэтому коротко.
Также есть такая услуга как аренда лицензий. Помимо аренды физической инфраструктуры дата-центры любят давать в аренду программное обеспечение (ПО), потому что в любой стандартной лицензии на ПО, скажем, от Microsoft, Oracle и др., написано, что лицензия не подразумевает передачу третьим лицам в аренду, и для такой задачи у всех вендоров существует отдельная модель лицензирования — модель лицензирования аренды софта. Вы, когда приходите в дата-центр, вы берете железку в аренду, вы можете или свои лицензии накатить, или сказать: «Ребята, дайте мне в аренду лицензии такие-то», если вы используете коммерческий продукт, а не тот, что не подлежит коммерческому лицензированию. Еще, помимо лицензии, многие провайдеры умеют и любят (потому что они на этом зарабатывают) давать в аренду более высокоуровневые вещи — бизнес-приложения, CMS, CRM, все, что существует. Они это предоставляют в аренду, и пользователи это арендуют.
Облачные сервисы. В облачных сервисах существуют вычислительные сервисы и сервисы облачного хранения данных. Самый популярный, на слуху, это Amazon. Вариантов много. Здесь мысль в том, что эффект масштаба — эффект технологий. Люди берут тысячи, десятки тысяч железок, на них разворачивают некую среду управления виртуальностью, с помощью своих специалистов все это дело настраивают и обеспечивают то, что вы можете купить маленький кусочек эффективно используемого железа. Итак, железа куплено очень много, оно куплено за единицу очень дешево; людей, которые обслуживают эту систему, на самом деле немного; софт работает эффективно. Когда вы сравниваете варианты — купить в аренду небольшой виртуальный сервер или физический сервер с такими же характеристиками, условно говоря, 2-4 ядра, 8-16 Гбайт памяти и немножко жесткого диска, то вы понимаете, что виртуальная машина намного выгоднее по деньгам, чем физический сервер, только потому что таких виртуальных машинок живет на сервере десяток-сотня, и colocation возникает на одном сервере, а не просто сервер colocation. Т.о. облачный сервис — это то, что продают многие провайдеры. Есть ряд провайдеров, которые занимаются только облачными сервисами и не продают все, что под ними лежит. Например, DigitalOcean продают только облачные сервисы и им не выгодно, не интересно продавать colocation.
Поднимаемся выше. DDoS — это больно. DDoS приходит к каждому, кто делает то, что имеет конкуренцию на рынке, и интересно людям. Условно говоря, если у вас есть некий веб-ресурс, например, интернет-магазин, и если вас никогда не дедосят, вас это должно печалить, потому что вы никому не нужны — это больно. Любой ресурс — онлайн СМИ, развлекательный портал, онлайн-игру, интернет-магазин, все что угодно — рано или поздно будут дедосить, потому что есть конкуренты, которые не хотят, чтобы этот портал, этот ресурс развивался.
От DDoS защищают специализированные провайдеры, соответственно, ряд дата-центров договаривается с кем-то, и они вместе оказывают эти услуги. Кто-то не оказывает эти услуги, т.е. DDoS — это не такая вещь, не такой commodity, как стойки или аренда оборудования, это уже кто-то делает, кто-то не делает. Я знаю случаи, когда люди плакались, что их начинают дедосить, а им просто говорят: «У нас написано так в соглашении: если вас дедосят, мы имеем право вас отключить и расторгнуть с вами контракт». Это реальная жизнь, в одном крупном европейском дата-центре это просто написано в SLA: «Сорри, парни, вас дедосят, мы имеем право вас отключить, если вас дедосят долго, мы имеем право вас выгнать за дверь, так получилось».
Коллеги из «Куратора» любят по часу рассказывать только про DDoS — структуры атак, типы атак, аналитика статистики, как это развивается, что происходит, почему, как бороться, какие причины… Это долгая тема, но в рамках обзорного доклада, я хотел сказать три вещи:
- Запомните: механизм защиты капча — это не защита от DDoS. Это механизм, как бы потроллить ваших пользователей.
- Есть еще очень популярная мысль, что CloudFlare — это хороший бесплатный DDoS- protection. Нет, запомните: CloudFlare — это провайдер CDN, а CDN и DDoS- protection — это разные вещи.
- Если вы берете услуги какого-то дата-центра, вы явно спросите: «Ребята, а есть ли у вас защита от DDoS, как она реализована, и что будет со мной, если на мой ресурс на вашем дата-центре будет DDoS?». Потому что далеко не у каждого оператора дата-центров есть защита от DDoS, и далеко не каждый оператор дата-центров, провайдер, будет терпеть вас, если вас будут дедосить. Как показывает опыт, иногда это откровение для людей и откровение болезненное. Т.е. мало того, что дедосят, еще и выгоняет, ссылаясь на свой же пункт 6.8.13 приложения 4 к договору.
Managed services. Т.к. мы говорим, что дата-центр — это предоставление инфраструктуры в аренду и отлаженная процедура оказания услуг, то логично эти отлаженные процедуры продавать потребителям. И очень много дата-центров оказывают услуги Managed services — это услуги по администрированию или инфраструктурных приложений, или бизнес-приложений заказчика. Так, например, коллеги из «ITSumma» зарабатывают на жизнь только этим. Они приходят к клиенту, говорят: «Рребят, у вас сервер где-то стоит, давайте мы его вам будем администрировать?». Хорошая бизнес-модель.
Администрировать можно все, что угодно, но более стандартные вещи, такие как почтовые системы, какие-то CMS берут на администрирование чаще, что-то более сложное берут на администрирование реже. Оплачивается это обычно $X за почтовый ящик в месяц, или просто люди говорят: «Час работы нашего инженера стоит столько-то денег», потом говорят: «Мы работали в этом месяце по вашим заявкам 12 часов, дайте нам Х*12 денег за этот месяц». Или, как коллеги рекламируют, Flat fee за единицу оборудования: «За каждый сервер дайте 100 единиц», или Flat fee за приложение: «Мы будем администрировать вашу CMS за $49 в месяц». Такие услуги есть, они тоже не у всех есть, все в разном объеме, но они существуют.
Услуги CDN и геораспределенные сервисы. Зачастую у провайдера бывает больше, чем одна площадка, и тогда мы начинаем говорить о геораспределенных услугах. Первая услуга, которая всем приходит на ум, — это CDN (Content Delivery Network). Это отдельный класс услуг. Т.е. есть класс провайдеров, которые занимаются DDoS, — это отдельные люди, со своей математикой и со своим софтом, а есть люди, которые занимаются CDN. CDN — это тоже отдельная математика внутри отдельной инфраструктуры, отдельной технологии. Бывает так, что некоторые дата-центры партнерятся с каким-нибудь провайдером CDN, или бывают случаи, например, когда в холдинг входит и дата-центр как бизнес, и провайдер CDN как бизнес. Бывает, что дата-центр просто не занимается CDN, потому что он там один, а CDN из одной точки выглядит как-то странно. Это первый класс услуг, который бывает геораспределенным и который можно встретить в дата-центрах. Если сеть дата-центров занимается CDN, это хорошо тем, что хотя бы у них на уровне сети, на уровне технологии коммуникаций есть интеграция между CDN и их сервисом, и в случае возникновения какой-то проблемы не начинается игра, как у нашего сатирика: «К пуговицам претензии есть? К пуговицам претензий нет, ищите с той стороны проблему». Помимо CDN, как геораспределенного сервиса, есть ряд других сервисов — private backbone, распределенный DNS, отказоустойчивый распределенных DNS-зон. Вариантов много, они существуют, с ними тоже можно говорить.
На всех услугах есть три волшебные буквы — SLA, которые люди иногда считают некоторой парадигмой. Что такое SLA? SLA — это соглашение об уровне сервиса, в котором провайдер декларирует (ключевое слово — декларирует):
- насколько стабильно будет оказываться услуга;
- как быстро сервисная служба будет реагировать на ваши обращения, и как быстро она будет эскалировать ваши обращения, если она будет реагировать на них некорректно;
- что будет делать провайдер, если он не сделает то, что он обещал;
- и для каждого сервиса обычно бывает так, что существуют некие граничные параметры признаков — «работает/не работает». Сервисы разные, измеряются в разных параметрах, у них бывают разные параметры — признак того работает или не работает, потому что может сложиться ситуация, когда работает, но медленно. В хорошем SLA написаны критерии медленности;
И опять же по опыту, очень важная вещь (на слайде красным написано) — время отклика сервисной службы дата-центра, сервис-провайдера и время решения вашей проблемы — это две разные вещи, друг с другом никак не коррелирующие. Т.е. response time — это время, в течение которого на вашу заявку будет ответ от инженера, адекватный, не от робота типа «Спасибо, мы получили вашу заявку», а ответ от инженера по сути. Это обычно час, два часа, четыре часа, 24 часа — это все прописано в SLA, а вот время решения вашего инцидента, т.е. когда будет не ответ «OK, мы услышали, что у вас проблема», а «OK, мы вашу проблему решили так-то и так-то и больше этого не повторится». Вот время до этого ответа, т.е. время разрешения инцидента почти никогда не регламентируется в SLA и в договорах. И это надо помнить, что время ответа и время решения проблемы — это разные вещи, и сильно разные.
Что такое Uptime. Доступность любого сервиса определяется через тот процент времени, когда он работает. Соответственно, есть несколько аксиом. Чем более высокоуровневый сервис, тем ниже у него uptime, потому что он зависит от uptime нижележащих сервисов. Очень просто — если у нас в дата-центре кончилось электричество, наша почтовая система перестанет работать — это физика. Т.е. почтовая система сама по себе может сломаться. Т.е. может сложится ситуация, что в софте произойдет глюк, софт не работает, но сервер работает, colocation под ними работает, и uptime почтовой системы будет ниже. Но в случае, если нижележащий инфраструктурный сервис умирает, вышестоящие сервисы умирают по определению. Просчитать мат.модель невозможно, можно оценить «пол, палец, потолок». Соответственно, «в среднем по больнице» хороший уровень — три девятки, 99,9% uptime. Больше четырех девяток на одном дата-центре — это критерий удачливости. Т.е. если ваш сервис живет в дата-центре и за год показал uptime выше четырех девяток, то супер, вам повезло, все хорошо. Но гарантировать, что еще в следующий год вы опять достигнете этого uptime, никто не может. Когда вам говорят uptime пять девяток, шесть, семь и больше девяток — это как в старом армянском анекдоте, что Сочах изобрели коньяк 7 звездочек, хотя во Франции только 5.
Что нужно нам? Перед тем, как искать провайдера дата-центров, ответьте себе на максимальное количество вопросов — что вы и зачем хотите сделать?
Т.е. какие у вашего проекта будут временные категории? Кто будет потребителем вашего проекта? Это будет внутренний или внешний проект, краткосрочный или нет, будет связан с разработкой и написанием некоего софта, или вы просто поставите почтовый сервер, чтобы он просто работал?
Ответьте себе на вопросы про ресурсы.
- Все почему-то думают, что деньги рулят миром, и ключевой вопрос — это деньги. В жизни все немножко сложнее, ключевой вопрос — это люди. Т.е. какие люди есть у вас, что вы готовы сделать сами, а какие услуги вам придется купить на стороне, у аутсорсера или у дата-центра?
- Второй больной вопрос — это сроки. Когда вам что нужно получить, когда вам что нужно сделать?
- Третий вопрос — это технические ограничения. Т.е. условно говоря, если вся ваша команда умеет программировать, но не умеет администрировать, то вам, наверное, нужны услуги администратора. Или наоборот, если у вас в команде люди занимаются внедрением Microsoft project’а, то чтобы что-то программировать вам нужно будет искать программиста.
- И только четвертый по важности вопрос — это вопрос бюджетных ограничений, т.е. сколько денег у вас есть на все то, что вы задумали?
Понимая эти вопросы, вы должны понимать еще один вопрос, который возникает, который вам могут задать уже потом, поэтому лучше его себе задать заранее. Inhouse или нет? Т.е. надо понимать, что да, у нас сейчас существует куча провайдеров, да у нас есть Google, есть Amazon, у нас есть Microsoft Azure, у нас есть десятки дата-центров. Все супер. Надо помнить, что вариант с собственной серверной или, условно говоря, вариант с двумя серверами под столом не отменяется, он всегда существует как альтернатива, и его тоже нужно просчитать. Он будет, скорее всего, грустнее по срокам, он, скорее всего, будет грустнее по техническим ограничениям, потому что если у нас чего-то нет, то у нас этого нет. Но он может оказаться лучше по бюджетным ограничениям — если у нас железо уже есть, то ничего покупать не надо. Такие кейсы тоже бывают.
Соответственно, надо определиться с ресурсами и четко определить себе задачу.
Сначала нужно понять, что мы хотим сделать, потом вспоминаем, что мы говорим про бизнес дата-центров и, исходя из этого, мы смотрим, нужны ли нам услуги по администрированию, по управлению, нуждаемся ли мы в помощи дата-центров, закупке инфраструктуры, чтобы мы ее могли арендовать? Потому что мы можем прийти в дата-центр и, условно говоря, арендовать стойку, потратить миллион денег и купить железки, чтобы поставить в эту стойку. Или же мы можем прийти и сказать: «Дата-центр, мы хотим арендовать у тебя стойку, набитую таким-то железом», и фактически в этом случае дата-центр оказывает финансовый сервис — покупает эти железки и дает их вам в аренду. Это нормальная практика.
Мы доходим до самой интересной части — как выбрать провайдера?
Есть две проблемы:
- Все провайдеры оказывают разный спектр услуг, и зачастую одно и то же название соответствует каким-то разным вещам.
- Между вами и любым дата-центром будет стоять еще два участника, на которых вы слабо влияете и дата-центр тоже слабо влияет — это телеком и государство.
Про телекомы. Дата-центр без связанности, без присутствия провайдеров — это какой-то неправильный дата-центр, потому что или пользователи вашего сервиса не будут видеть или будут плохо видеть ваш сайт, лежащий у этого провайдера, или вы банально не сможете получить доступ к этому провайдеру. На слайде есть ссылки, по которым можно посмотреть на автономную систему любого дата-центра. Соответственно, Hurricane Electric и qrator.
Справа нарисован вариант, который не очень хороший, когда есть некий провайдер, который говорит, что он хороший и крутой, но мы видим, что он на самом деле является ресейлером другого дата-центра, а уже другой дата-центр имеет у себя некую не очень большую связанность, ну, он ее имеет, но не офигенно. И хороший вариант слева (на самом деле это Google Aps), когда сам провайдер имеет связанность с большим списком очень уважаемых провайдеров. Соответственно, чем лучше связанность (это можно посмотреть на сервисах), тем лучше. Тем больше шансов, что из различных точек Интернета пользователи вашего сайта или сервиса до него получат адекватный доступ. Т.е. гарантий нет, но шансы повышаются.
Государство. Мы говорим про Россию. В России возможны два расклада — вы пользуетесь российским дата-центром или не российским. Если вы пользуетесь не российским дата-центром, то государство может вам «делать голову» по документообороту и по отношениям. Если вы занимаетесь даже с российским дата-центром, то нельзя думать, что государство от вас отстанет, потому что в России сейчас принимается все больше и больше законов, связанных с персональными данными, данными россиян. Вот у нас есть закон о блоггерах, под который попадает любой сайт с посещаемостью больше 3 тыс. человек в день. Также у нас есть закон о противодействии отмыванию, терроризму, т.е. очень много законов, написанных в нашем государстве, которые влияют на Интернет, влияют на хостеров, влияют на владельцев Интернет-ресурсов. Об этом надо помнить, об этом надо знать.
Предположим, мы сделали вот такую табличку. Выписали кучу дата-центров, их услуги и расписали их так, как нам хочется. Чуть ниже я объясню, зачем нам такая табличка.
Как обычно происходит поиск дата-центров любым, кто хочет купить услуги дата-центра? Это я рассказываю, какие вижу случаи в 80% кейсов за последние 6 лет, как я продаю дата-центры. Это алгоритм 80% коммуникаций с клиентами. Приходят клиенты и говорят: «Ребята, у нас сейчас есть некий пул железа, мы хотим точно такой же, но в дата-центре. Мы подумали и решили, что нам нужны три сервера таких, два сервера таких, пять серверов таких. Мы хотим вот это в дата-центре». Соответственно, любой потенциальный покупатель рассылает какому-то пулу провайдеров этот запрос. Всем, кого знает, всем рассылает. Потому что глупо прийти к одному и купить у него дорого, надо же купить дешево. Все провайдеры в ответ присылают некие цены, просто в табличке заполняют цифры — сервер конфигурации №1 — 100 денег, сервер конфигурации №2 — 150 денег в месяц и т.д. Клиент получает эти таблички, сравнивает, говорит: «Видите, а ваш сосед предложил на два рубля дешевле». Т.е. ведется торговля, получается некое снижение цены — все супер. И еще раз снижение цены, подписание договора, мир, дружба, жвачка. Процедура тендерных торгов — был выбор оптимальный по цене-предложению.
Есть такой хороший демотиватор:
Проблема в том, что эта описанной процедурой идет 80% потребителей услуг дата-центров, а задача дата-центров все-таки не продать самую дешевую цену, задача дата-центров — заработать прибыль своим акционерам. И все это понимают, и все знают, что эту процедуру пройдет 80% клиентов. Соответственно, собака где-то порылась. Не думайте, что вы изобрели механизм отжимания по цене и показывания офферов друг другу дата-центров как некий механизм нового слова в тендерных торгах.
Поэтому нужно делать по-другому. Сначала нужно написать технические требования. Технические требования — это рамки, ограничения и формализация того, что мы хотим сделать примерно, крупными мазками, без прописывания количества ядер, МГц, ИОПСов и прочего. Технические требования к тому, что мы хотим реализовать. И имея технические требования, мы определяем классы услуг, которые мы хотим.
Предположим, мы хотим сделать очень крупный сайт, на котором будет миллион пользователей, и они будут по всему миру. Если пользователи по всему миру, но, наверное, нам нужен CDN. 1 млн. пользователей — наверное, нам нужно много железа. Мы хотим еще, чтобы там была отказоустойчивость выше, чем три девятки — наверное, нам нужны две площадки. Т.е. условно говоря, определяете, что вы хотите. Вот, нам нужно, чтоб из Интернета было видно так-то, и мы хотим свою АС-ку поместить, и мы хотим, чтобы еще наш сайт с 1 млн. пользователей не дедосили.
Т.е. у вас есть некий класс услуг, который вы хотите. Вы потом смотрите: а что из этих классов услуг для вас самое важное. Сетевая связанность, крутые железки, офигенные облачные технологии, потому что вы живете в докере, вы научились деплоить в докере красиво, и вы хотите, чтобы этот докер работал? Или для вас важно, чтобы был самый офигенный CDN, потому что у вас пользователи на всех пяти континентах. После этого вы определяетесь, что вы хотите иметь по uptime, насколько адекватным, насколько быстрым, вменяемым должен быть тот провайдер, с которым вы хотите договориться.
Опять же, смотрите на географию и понимаете, где этому провайдеру лучше находиться. Потому что, если вы хотите сделать сервис для пользователей, технологически логично поставить свою площадку как-то не далеко от пользователей. Потому что если вы делаете сайт для русских и на русском языке, логично его поставить в России, в крайнем случае, в Европе. А если вы делаете сайт для Южной Америки, то надо искать площадку или в Южной Америке или в Северной Америке, но, например, из России делать сайт для Южной Америки — очень плохо.
Соответственно, у вас есть такие структурные понимания.
Дальше вам нужно понять про SLA. Любой дата-центр декларирует свои SLA, исходя из своих знаний о том, как он оказывает сервис, и вы понимаете, что если вы даже заплатите дата-центру чуть больше денег, но он этот SLA не делает, то он его не сделает. Он его пообещает, но не сделает. Ваш собственный проект, любой сайт, любое то, что вы размещаете в дата-центре, в итоге должно окупить затраченные деньги и принести прибыль. Вряд ли вы будете делать какой-то highload проект просто ради фана, тратить на это деньги и время. Скорее всего, вы это будете делать для того, чтобы эти деньги как-то вернулись — через рекламу, через подписки, через что-то. Т.е. в итоге это будет бизнес, за который кто-то заплатит. Соттветственно, у этого бизнеса будет человек, который потратит деньги, а потом их вернет. Этот человек должен знать требования по уровню доступности, масштабированию, по надежности того сервиса, который он хочет построить. Но не абстрактно, чтобы «типа работало всегда, никогда не падало», а более предметно. Это с одной стороны.
С другой стороны, у вас есть некие технологические ограничения внутри. Т.е. если у вас нет системы мониторинга, и вы не узнаете в течение суток, что у вас что-то сломалось, то требовать от вашего хостера downtime не больше пяти минут в год как-то глупо. Вы должны требовать от своего провайдера тот уровень доступности, который вы можете проконтролировать сами. Если вы не видите сами, что ваша площадка в течение десяти минут не очень видна из сети дойч-телекома, то требовать какие-то супер SLA по телекому глупо.
У вас еще есть внутренние ограничения по зрелости команды, когда вы не имеете мониторинга или не имеете отлаженных процедур у себя внутри. Т.е. вы понимаете, насколько вы хотите быть по SLA, и вы понимаете, насколько вы можете по SLA. И такой SLA вам стоит потребовать у своего будущего провайдера, потому что требовать мега крутой SLA глупо, т.к. это будет очень дорого, а требовать SLA, который вам не подходит — зачем вам искать провайдера, который вам сразу не подходит?
Т.о., вы определяете те SLA, которые вы ждете от провайдера, после того, как вы определите то, что вы хотите.
Есть еще такой интересный слайд, о котором забывает 80% людей:
Предположим, если вы решили контрактоваться не с российским провайдером, а с европейским или американским, то у вас в вашей компании есть такие люди, которые называются юристы, и есть люди, которые называются бухгалтеры.
Не каждый юрист примет публичную оферту на сервис, размещенную на сайте провайдера на английском языке, далеко не каждый. Это боль. Не каждый бухгалтер согласиться оплачивать сервис Paypal’ом или корпоративной кредитной картой — в России этого нельзя сделать. Далеко не каждый провайдер согласиться обсуждать свой договор, потому что результаты работы юриста видны, когда он правит договора с контрагентами, а есть много провайдеров услуг дата-центров, которые просто говорят: «Нет, ребят, у нас есть шаблон — тут вы вписываете, чего хотите, вот тут фамилию, тут место для печати, вот тут дата подписания договора. Все остальное не исправляется». И далеко не каждый юрист на такую структуру взаимоотношений согласится.
Государство. Если вы захотите заплатить абстрактному Amazon’у денег… Ну, сейчас они уже научились это делать, но два года назад заплатить Amazon’у денег — это был периодический квиз, тот еще, потому что внешнеэкономическая деятельность, потому что «принесите, пожалуйста, контракт, распечатанный с оригиналами печатей». Или не Amazon, а более мелкий иностранный провайдер вставал в позу «ээээ», которая не проходит.
Вот, из жизненного опыта. Приходят люди и говорят: «Нам очень срочно нужен проект, мы взлетаем, у нас дедлайн. За неделю договариваемся —тонна железа за кг денег в месяц, по рукам?» — «По рукам. Присылайте договор — подписываем». После этого три месяца юрист — бухгалтер, юрист — бухгалтер с их стороны… Это нормально. Причем, такой цирк не зависит от суммы договора, т.е. это может быть на рубль и на млн. рублей в месяц. Объем юристов и бухгалтеров от этого не зависит. И если вы хотите работать, например, с не российским дата-центром, вы об этом риске должны помнить не в момент, когда у вас дедлайны прошли, и надо завтра в продакшн, а на моменте выбора провайдера.
Алгоритм. Если у вас уже есть понимание, какие услуги дата-центров, в принципе, вы хотите, и есть некие описания технических требований, то алгоритм очень простой:
- Сначала выписываем все названия дата-центров, которые мы знаем, слышали, в Яндексе или в Google, опыт имеем, уже работали, общались, коммуницировали как-то.
- Составляем табличку, что они умеют, и сравниваем с тем, что мы хотим купить. Если для нас критично, например, DDoS-protection, a половина из участников DDoS не делает никак, то их лучше из списка на сравнение вычеркнуть сразу, потому что они потом все равно вычеркнутся.
- Потом лезем к ним на сайт, лезем к ним в публичные оферты и читаем их SLA внимательно. Находим у них раздел legal и в этом legal читаем SLA, и сравниваем то, что они пишут, с тем, что хотим мы. Например, мы хотим response time 24/7 20 минут на русском языке. Открываем какой-нибудь итальянский дата-центр и читаем, что они делают поддержку на итальянском круглосуточно, на английском — круглосуточно, а на немецком — только в рабочие дни. И время отклика — минимум четыре часа. И мы понимаем, что такой SLA нам не подходит, и вычеркиваем его. Соответственно, смотрим, у кого какие критерии. У многих провайдеров есть критерии SLA: «Бесплатно мы отвечаем в течение суток, платите нам Х денег, мы ответим в течение четырех часов, платите нам три раза по Х денег, мы ответим в течение часа». Хотите SLA, платите — это нормальная практика. Вы смотрите, какой SLA вы хотите, и на какой SLA они согласны. Те, кто не согласен на тот SLA, который вы хотите, вычеркните их. Если ваш SLA вменяемый, кто-то останется.
- После этого отсейте тех, кто может вам не подойти по деньгам. Потому что у вас все равно есть бюджет проекта, и если у вас есть деньги на «Эквиникс» и «Рекспейс», я рад за вас, и вы понимаете, почему вы должны их купить, их сервисы — это супер. У вас очень критичные, у вас очень хорошие и высокобюджетные проекты. Но, скорее всего, «Эквиникс» и «Рекспейс» вам тоже придется вычеркнуть.
- После чего вы показываете документы, которые хранятся на сайте или на шаблонах договора у этих провайдеров, бухгалтерам и юристам, и говорите: «Ребята, а у нас есть шансы подписать такой договор?». Дальше отматываем на тот слайд, чего не любят юристы/бухгалтеры, и вы еще тоже кого-то вычеркнете.
Т.о. вы отфильтруете некое количество дата-центров, но что-то останется. И уже этим дата-центрам вы рассылаете запрос на предложение.
RFP. Что входит в RFP. Вы пишете некое описание проекта: мы хотим реализовать сайт, на котором будут пользователи выкладывать котиков, пользователей будет 1 млн., они будут жить везде, общаться на разных языках, у них будет чатик, условно говоря. Вы пишете, что вы хотите от провайдера, от проекта, для того, чтобы этот сайт с 1 млн. котиков заработал, и вы пишете, как вы видите развитие своего проекта в течение года, двух, трех, в случае, если вы будете работать с провайдером дата-центра. А после этого пишете тот SLA, который вы хотите видеть. И ту начальную конфигурацию, с помощью которой вы хотите начать реализовывать свой будущий проект с 1 млн. котиков.
Этот RFP содержит время, в течение которого вы хотите сотрудничать, ваш горизонт планирования — один-два-три года; он содержит технологии, которые вы хотите; он содержит ваши ожидания про SLA, и он содержит отправную точку того, что квотировать.
Этот путь в отличие от пути, по которому обычно идут все, он уже не про то, что типа «ребят, сначала давайте мы договоримся про самые минимальные деньги, а потом получим upsell в виде SLA, upsell в виде всего остального». Здесь вы сразу уходите от этих неприятных подводных камней, когда люди говорят, что «ой, а вы хотели еще, чтобы вас там и на русском поддерживали? Не вопрос. Ценник умножается на два». Или вы там говорите: «Мы хотим что-то», а вам: «Умножайте тоже на два или мы это, вообще, не можем».
Такой RFP помогает вам после того, как вы отсеяли тех, кому вы этот RFP отправили, найти провайдера, который вас потом не разочарует ни по классу услуг, который вы хотите получить, ни по тем коммуникационным процедурам SLA, которые вы от них ожидаете. Потому что я знаю кейсы, когда люди раз в 72 часа просто получают роботом автомат, типа, «OK, мы получили ваш запрос, мы над ним работаем». Потому что базовый SLA — трое суток на ответ «ОК», а escalation time нет. Я такие SLA тоже видел у дата-центров.
Помните, что любой дата-центр — это не только цена на тот сервис, который написан на сайте. На сайте всегда (мы вспоминаем, что все лгут) пишутся или промо, или какие-то спец. предложения, или то, что по каким-то причинам дата-центр может продать дешево. Но продавая что-то дешево, дата-центр понимает, что он вернет свою прибыль на тех вещах, которые будут связаны с этим, с тем, что он продаст дешево, т.к. это вам все равно будет нужно в комплексе.
Т.е. сервис — это не только цена, но это еще и персонал, который оказывает услуги. И вы смотрите на то, что дата-центр оказывает, и при желании старайтесь избегать явных ресейлеров и явных агентов по продажам, которые сами не добавляют какого-то дополнительного сервиса. Т.е. условно говоря, есть дата-центр, а есть сайт ресейлер, который перепродает какие-то ресурсы с него. Там фактически два человека — студенты, которые принимают платеж с карточки, свои 10% забирают, и мутят, чтобы это в дата-центре заработало. Такой вариант вам не нужен. А если, например, есть дата-центр, который сдает в аренду только железки, а ребята берут железки в аренду, разворачивают на нем виртуалки и продают виртуалки вам, то такой ресейлер вам может быть нужен, потому что вам нужны виртуалки, но в этом дата-центре.
Внимательно смотрите, если вы покупаете не напрямую у дата-центра, а у его ресейлера, какую ценность дает ресейлер? Я знаю кейсы, когда берется английский дата-центр и русские ребята его ресейлят. Единственная ценность ребят в том, что они работают переводчиками с русского на английский и обратно. Т.е. русский клиент пишет на русском ресейлеру, ресейлер переводит это быстренько на английский и пишет на английском индусам в саппорт дата-центра. Вот она ценность — коммуникации на русском языке, потому что индусы на английском плохо говорят, по-русски они, вообще, не говорят. В таком смысле вам ресейлер может быть полезен.
Если вы не видите явной ценности ресейлера, когда составляете список, вычеркните его, потому что ресейлер — это дополнительная задержка в response time и это отсутствие ответственности по SLA, потому что ресейлер вам может пообещать что угодно, но в контракте с дата-центром вы этого ничего не увидите.
Еще помните, что длительность сотрудничества имеет значение. Реально оцените, если у вас проект планируется при хорошем стечении обстоятельств на вечно или на много лет, напишите об этом в RFP, что «Ребята, в случае, если у нас будет все хорошо, то мы с вами планируем трехлетнее сотрудничество». Если дата-центр вменяемый, то ценник на услуги упадет на 10-20%, а это хорошо. А если вы напишите «мы на месяц-другой хотим Superdome», то, скорее всего, вас пошлют. Хотя реально я регулярно получаю запросы на не Intel’овскую архитектуру: «А можете ли нам дать 16-процессорный pSeries на месяц?». pSeries 16-процессорный — это фигня в полмиллиона долларов, весьма специфическая. Мы говорим: «А откуда мы ее найдем на месяц? И что мы с ней потом будем делать?».
Помните, что быстро, дешево, качественно — выберите любые два. Это работает в любом бизнесе, в дата-центрах это тоже работает. Т.е. быстро, дешево, качественно одновременно — оно, к сожалению, не бывает. Надо выбирать два из трех. Помните, что провайдеры дата-центров делают бизнес, зарабатывают деньги на вас, благодаря тому, что они проинвестировали много денег в инфраструктуру и отладили процедуры предоставления этой инфраструктуры своим клиентам в аренду. На этом дата-центры делают свои деньги — на эффекте масштаба, на привлечении инвестиций, на экспертизе по эксплуатации, на этом всем они зарабатывают деньги в рыночных условиях.
Контакты
Этот доклад — расшифровка одного из лучших выступлений на обучающей конференции разработчиков высоконагруженных систем HighLoad++ Junior.
В тот год (это 2015) концепция конференции состояла из ряда обучающих докладов от профи (которые очень даже в теме). Игорь сейчас работает в команде, запустившей Servers.ru, а это сейчас, наверное, самый агрессивно развивающийся .
Также некоторые из этих материалов используются нами в обучающем онлайн-курсе по разработке высоконагруженных систем HighLoad.Guide — это цепочка специально подобранных писем, статей, материалов, видео. Уже сейчас в нашем учебнике более 30 уникальных материалов. Подключайтесь!
Ну и главная новость — мы начали подготовку весеннего фестиваля "Российские интернет-технологии", в который входит восемь конференций, включая HighLoad++ Junior.
Автор:
