Жаль вас расстраивать, коллеги, но мой ответ: никак. Или, как говорилось в одной отечественной рекламе, «сынок, это фантастика». Нет, в природе существуют Tier IV ДЦ и ЦОДы, заключающие и выполняющие SLA, но в этой статье речь пойдет не о них (так как их услуги стоят, простите за каламбур, заоблачных денег), а о провайдерах выделенных физических и виртуальных серверов и сервисов, которыми в настоящее время пользуется большинство простых смертных, в том числе и мы в Pixonic.

Я намеренно не буду приводить названия конкретных компаний, с которыми мне приходилось работать как в Pixonic, так и до него, чтобы донести уже озвученную идею: так или иначе, серьезные «нюансы» обнаруживаются у всех. Возможно, кто-то захочет поспорить, но мое заключение основывается на более чем 8-летнем опыте общения с техподдержкой и менеджментом дата-центров разного уровня по всему миру.

Ёж — птица гордая: пока не пнешь, не полетит

Полагаю, не ошибусь, обобщив проблему следующим образом: до тех пор, пока каждый непосредственный исполнитель во всех дата-центрах, услугами которых вы пользуетесь, не будет лично заинтересован в закручивании своей конкретной условной гайки — все будет плохо для вашего бизнеса. Но улучшить положение и облегчить себе жизнь можно, и довольно просто.

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

Начну с простого вопроса: ваш провайдер присылает вам ссылку на опрос о качестве их услуг с просьбой потратить 5 минут на его прохождение — ваши мысли? Как правило, «утомили» — самая невинная из них, после которой просьба просто игнорируется.

Так получается, потому что вы заплатили денег, у вас свой бизнес, свои задачи, и вам нужно, чтобы оплаченное просто работало. У вас нет времени заниматься их ерундой, в конце концов! Знакомо?

Открою секрет: они не идеальные, но они стараются. Именно для этого они делают эти опросы, различные интерфейсы и API разной степени удобства, мониторинги, нотификации и прочее. Почему бы не постараться и вам на благо своего бизнеса, если они предоставляют для этого какие-то инструменты? Начните с изучения документации и базы знаний по работе с пользовательским веб-интерфейсом и API. Укажите в настройках своего профиля контакты таким образом, чтобы важная информация (вроде предупреждений о запланированных работах или abuse с угрозой блокировки) не валилась на нечитаемый никем общий ящик, а доходила до конкретных людей, которые на нее смогут адекватно и своевременно среагировать. Например, технические, сетевые и абузные вещи — админам, а все вопросы взаиморасчетов — в бухгалтерию и финансовый контроль.

Пишите письма

Далее, не ленитесь разбираться в каждой проблеме и писать в саппорт. На первых порах, если проблема не горит, нужно именно писать, чтобы все было запротоколировано. Это пригодится не только для того, чтобы в случае чего было куда «ткнуть носом» очередного дежурного на стороне провайдера, но и при необходимости показать тикет вашему коллеге. Если пишущие с вашей стороны не знают английского на достаточном уровне, сделайте с этим что-то: привлеките коллег, обучите, наймите переводчика (Google Translate не поможет!), займитесь сами, в конце концов.

При письменном общении с представителем провайдера заострите внимание на следующих моментах:

• как правило, в каждый момент времени над проблемой работают инженеры разного уровня квалификации, при этом они ограничены внутренними регламентами их компании. Часто сменщик не обменивается информацией по проблеме со сменяемым — будьте готовы повторять по многу раз одно и то же и досконально разжевывать проблему;
• если в общении упоминается время, всегда уточняйте и вашу временную зону, и время по UTC;
• если корень проблемы вам очевиден, напишите пошаговую инструкцию вплоть до запятой и в общении с менеджером (о нем чуть ниже) постарайтесь настоять на том, чтобы она была выполнена беспрекословно без лишних вопросов — как правило, из-за упомянутых выше регламентов инженер обязан у вас спросить всякое странное, вроде собрать и предоставить статистику MTR за 1000+ итераций с разных хостов в одной подсети;
• часто техподдержка провайдера увлекается расследованием инцидента, которое может длиться неделями; в таком случае не стесняйтесь просить радикальных мер: физической замены сервера или его переноса в другую стойку/PDU/коммутатор;
• если при составлении тикета есть возможность выставить степень важности проблемы, указывайте честно, чтобы не оказаться в ситуации из известной притчи про мальчика и волков;
• если «разбором полетов» с провайдерами у вас занимается отдельный человек, не являющийся лицом, принимающим решения, ему не стоит употреблять корпоративную подпись с указанием его должности — пусть ограничивается чем-то вроде: «Regards, Имярек» — они будут воспринимать его как ЛПР и активнее работать по проблеме;
• вообще, в некоторых ситуациях, если для вас это приемлемо, может быть полезно выстроить некоторую модель общения по электронной почте, где среди формальных, оформленных в HTML сообщениях в треде будет появляться персонаж, пишущий рубленые фразы в plain text без подписи — цель та же;
• во всех случаях, когда считаете нужным, употребляйте аббревиатуру ASAP и фразу «business critical» в разных вариациях — они это «любят», особенно менеджеры, которых обязательно нужно либо ставить в копию, либо, если нет такой возможности, упоминать по ФИО прямо в тикете, чтобы показать техподдержке, что их начальство уже в курсе проблемы;
• если на третий раз эти волшебные фразы не подействовали, грозите съехать от них вот прямо завтра без разговоров и оплат — их это еще сильнее «бодрит».

А если не помогает?



На самом деле, на практике лишь часть инфраструктуры флагманского продукта Pixonic единственный раз действительно съехала от провайдера Х (чтоб их черти мучили).

Как правило, если у вас, конечно, не 5-10 серверов на весь проект, провайдер очень заинтересован, чтобы вы остались у него. И тут с них нужно просить, нет, не неустойки (к слову, из всех провайдеров, с кем мы общались на повышенных тонах по критичному для бизнеса инциденту, был только один, кто сразу спросил, как и сколько денег вернуть) — ведь, положа руку на сердце, у вас не заложен механизм расчета финансовых потерь из-за факапа облачного провайдера, временной неработоспособности DNS, временной несходимости интернета из-за проблем на магистральных каналах? Вот тут нужно требовать по максимуму! Самое простое — скидки на новые сервера/инстансы, бесплатную аренду или расширение уже существующих, повышение уровня качества техподдержки и тому подобное. Но правильнее всего требовать отдельного менеджера, который — да-да — как раз будет лично мотивировать свою команду на повышенный интерес к вашему бизнесу.

В общении с таким менеджером тоже есть свои нюансы, а именно:

• иногда ситуация обостряется настолько, что хочется написать в тикет отборным русским матом; для начала пишите, но по-английски, зло, но сдержанно и развернуто по существу, упоминая уже не только саму проблему, а косяки коммуникаций внутри техподдержки провайдера и откровенную глупость инженеров — такую проблему непременно эскалируют на вашего менеджера, который либо попытается позвонить вам сам, либо письменно предложит созвониться, пообещав решить все проблемы; трезво оценивайте ситуацию и не тратьте свое время на менеджера, если можно напрямую связаться с техническим человеком, принимающим решения — условно, руководителем третьей линии техподдержки;
• в критической ситуации созвон голосом хорош только тогда, когда он реально поможет что-то решить; плохой пример из жизни: как-то собрали конф-колл из 3-х менеджеров с разных сторон и одного инженера-индуса, лишь для того, чтобы он мне продиктовал пароль — не надо тратить время на такое;
• тем не менее звонить и общаться голосом и встречаться лично, если получится, полезно всегда: личный контакт увеличит ваши шансы на повышенный интерес к вашему бизнесу и, как следствие, на разного рода «приятности» в виде эксклюзивных скидок, особых условий компенсаций факапов, обхождения неудобных регламентов и тому подобное.

30 часов боли. Разом

Где-то в параллельной вселенной после жалоб клиентов

Чтобы не быть голословным, приведу некоторые примеры из практики за время работы в Pixonic. Чтобы приблизительно был понятен масштаб проблемы, стоит уточнить: мы имеем точки присутствия в шести регионах планеты, которые с разным успехом нам обеспечивают пять провайдеров, и подобные приведенным проблемам возникают регулярно и везде. Итак, поехали!

---

Однажды нам выключили целый зал! После выяснений оказалось, что ранее провайдер предоставил нам скидки на сервера в этом зале, но менеджер забыл внести эту информацию в определенную базу. Сервера так работали несколько месяцев до тех пор, пока кто-то из разработчиков провайдера не обнаружил неработающий скрипт, который на основе информации из базы регулярно проходится по оборудованию и отключает «должников», и не починил его.

---

С такой автоматикой мы сталкивались неоднократно у разных провайдеров. Однажды нам поставили два сервера, которые периодически самопроизвольно отключались. Первое подозрение — автоматика — оказалось верным, ее отключили. Но один сервер продолжал периодически падать. Инженеры расстарались и проверили все, что только можно. Даже перенесли его в другую стойку, забыв, правда, включить, но ничего не помогало. В итоге пришлось просто поменять сервер.

---

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

С кабелями были случаи, когда жесткие диски вели себя странно из-за плохо подключенных шлейфов. Техподдержка на голубом глазу отвечала: «Подоткнули получше — заработало».

---

Бывает, что инженеры провайдера банально путают сервера, на которых нужно проводить работы. Также часто бывает, что исполнители и их менеджеры путаются в задаче и делают совсем неожиданное. Прямо как в том анекдоте про ампутацию: «Я сказал левую. Я сказал руку».

---

Как-то возникла необходимость обновить «железо» 50+ «боевых» серверов в одном регионе. Чтобы эта активность минимально сказалась на продакшене, обновляли по 5 штук. Так вот, в каждой партии обязательно попадался один неисправный сервер! Либо проблемный БП, либо битые диски, либо сгоревшая материнка. В итоге заложенное на обновление время увеличилось вдвое.

---

Тоже про обновление, но операционных систем. Провайдер предоставляет веб-интерфейс и API для манипуляций с серверами, в том числе для переустановки ОС. В нашем случае оказалось, что для 80% серверов, которые нужно было обновить, эти инструменты просто не работали! Разработчики провайдера пообещали разобраться, а техподдержка в это время предложила переустановку ОС вручную. Первая переустановка Windows заняла у инженера двое суток!

---

Еще про интерфейс — иногда бывает такое, что «накликанное» там на самом деле не работает, хотя техподдержка уверяет в обратном. Смешанные чувства вызывает ситуация, когда инженеры именитого провайдера ковыряют что-то вручную.

---

Как-то раз инженеры того же крутого провайдера попросили даунгрейдить наши «боевые» виртуальные машины, чтобы понять, почему у них некорректно работает мониторинг нескольких метрик. Случилось это потому, что мы сами случайно заметили проблемы с их мониторингом и то, что они ушли, когда мы планово уменьшили ресурсы для одной из виртуалок.

---

И напоследок, пожалуй, самая «веселая» история. Длительное время у нас была «плавающая» сетевая проблема с частью виртуальных машин в регионе: в разное время суток в течение разных периодов времени происходили обрывы клиентских TCP-сессий. Провайдер очень настойчиво заявлял, что такого не может быть потому, что не может быть, а мы не могли предоставить доказательства из-за непредсказуемости проблемы и из-за того, что на самих машинах все было нормально, проблемы были видны только на мониторинге. В итоге мы пришли к предположению, что эти виртуалки, скорее всего, находятся на одном физическом гипервизоре. Передали предположение провайдеру с предложением проверить сам хост, после чего случилось фееричное. Сначала нам сказали, что машины находятся на разных хостах, потом сказали, что да, все-таки на одном, и инженеры видят проблему, далее бодро отчитались о том, что проблема решена, после чего все наши виртуалки тут же ушли в даун. Как выяснилось, хост просто не справлялся с нагрузкой, так как наши машины «генерировали слишком много трафика», и эти простые ребята решили их тупо выключить, «чтобы не аффектили других клиентов»!

Если приведенных примеров недостаточно, задавайте вопросы в комментариях — я постараюсь вспомнить еще охпоучительных историй. А лучше делитесь своими.

Заключение

Я повторюсь, озвученным в статье советам достаточно просто следовать, чтобы минимизировать проблемы, возникающие из-за расхождения ожиданий в отношении дата-центров с реальностью, и сосредоточиться на бизнес-задачах. Но эти проблемы так или иначе будут присутствовать. Чтобы защититься от них по максимуму, закладывайте отказоустойчивость и гибкую инфраструктуру на уровне архитектуры приложений, как это делаем мы в Pixonic. И обязательно правильно настройте свой мониторинг, чтобы было к чему апеллировать в общении с представителями провайдера вместо сбора 1000+ MTRов.

https://habrahabr.ru/post/331490/