Мы были такими зажравшимися, что 2019-й казался нам почти кризисным

в 7:02, , рубрики: ruvds_статьи, аварии, итоги, продукт, управление, цод
image

Уже в 2020-м началась дичь, которая не кончается до сих пор. Казалось, надо чуть потерпеть, долго моргнуть — и всё пройдёт.

Не прошло.

Поскольку это продолжается уже 4 года, пора учиться жить в этом мире и строить в нём уютный домик из того, что есть. Мы выжили (по крайней мере, пока), хорошо расширились с 9 до 15 ЦОДов, запустили свой спутник (сразу сломанный) и сделали много других странных вещей, даже успели развернуть свой сервер на Северном полюсе (на 4 часа).

Если трезво задуматься, это были в целом удачные годы. Ладно, нормальные. Ладно, странные.

Мы узнали, что нельзя доверять крупным брендам, что вершина ИБ — чтобы про вас хотя бы не рассказывали в телевизоре, что наши же крупные аварии приводят клиентов. Узнали, что поддержка — лучшие разработчики, потому что они не любят повторяющиеся инциденты. И много другого нового, например, что SLA на бесперебойную работу просто конски сложно обеспечивать — это если считать честно. Как выяснилось, честно считают немногие и обычно в этот SLA не входит сеть. То есть если ЦОД включён, но без связи, это считается за нормальную работу.

В общем, сейчас расскажу несколько недокументированных фич бизнеса в России за эти 4 странных года.

▍ Нестабильность

В начале 2020-го мы думали, что главная проблема мира — нестабильность, и поэтому расширяли бизнес многократным дублированием площадок. В целом, наверное, наши представления о нестабильности с января 2020-го расширились достаточно сильно.

Математика бизнеса такая: у нас есть ЦОДы, когда они падают, клиентам это не нравится. До определённого предела имеет смысл улучшать стабильность ЦОДа, но после какого-то предела выясняется, что вы строите второй точно такой же, только inactive/idle рядом, и поэтому лучше дублироваться многократной репликацией. Так у нас стало 15 площадок вместо 9 в 2020-м.

Стратегически важной была Москва — в Москве надёжность должна быть выше, чем в других местах. В Москве наша первая площадка, и она единственная собственная — подземное сервероубежище. В дополнение к ней мы нашли сверхукреплённый ЦОД Останкино, который настолько не заморачивался на резервирование электропитания, что не поставил ни одной батареи. Зато подключил 2 дополнительных полноценных крупных электростанции в дополнение к 2 уже имеющимся. Вот про него подробнее. Москва — наша база, и нестабильность на уровне ЦОДов в Москве убрана уровнем этих ЦОДов, а в мире — количеством и качеством площадок.

Это мы делали и до всех кризисов, но за эти 4 года появилась прямо стратегия, экономические пороги и модель того, что и как нужно делать на площадке, как гомогенезировать оборудование и так далее.

▍ Авария в Москве

Потом случилась феерическая авария в Москве. Вот пост про то, как это развивалось в моменте, а вот разбор уже после. Обратите внимание, что мы чётко идентифицировали причины, но сделали относительно мало такого, что защитило бы нас от подобных аварий в дальнейшем — потому что не надо работать с ошибкой выжившего.

Самое главное, что я тогда с удивлением узнал, что авария — это отличный способ привлечь клиентов. Просто в России принято ныкать свои косяки глубоко под ковёр и никому и никогда о них не рассказывать. А если делать так, как мы тогда сделали, с подробным разбором чуть ли не в реалтайме (ладно, с задержкой на сутки, чтобы выдохнуть и отоспаться), — то внезапно выясняется, что клиенты понимают, какой у нас уровень мышления, инфраструктуры и так далее. И это их устраивает, потому что лучше посмотреть вот на такие натурные испытания, чем слушать сладкоголосых продаванов, у которых всё всегда хорошо.

Мы получили новых клиентов на той ситуации, а не потеряли!

Сейчас в Москве мы постепенно приходим к исчерпанию возможной ёмкости ЦОДов — почти на год раньше плана. Ладно, там сыграла не только эта авария, но и то, что мы повысили цены превентивно при виде кризиса 2022-го, а многие другие повысили цены несколько раз по ситуации, и ещё была история с законами про то, как заниматься хостинговой деятельностью… Но авария дала достаточно много.

Мы начали распределять управляющие контуры, чтобы в случае других аварий «размазать» по всему гриду эффекты. Сейчас мы пришли к тому, что любой сбой — это не более 1/15 от общего парка, а не качественная деградация.

▍ Железо

С железом случилась беда, его не стало. Но мы за это время в полтора раза нарастили парк (это замены сошедшего с поддержки и плюс к этому расширение).

До 2022-го мы постоянно кичились тем, какие мы крутые, что у нас корпоративное брендовое железо, что это всё работает как часы, что мы посчитали экономику, что всё это надёжнее, чем самосборный ноунейм.

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

А нам нужно было получить гомогенное железо, потому что часть нашей модели — корпоративные серверы на поддержке, причём одинаковые по всему миру, чтобы получать объёмную скидку на закупки и поддержку и держать меньший ЗИП, писать меньше инфраструктурного кода и так далее. Зоопарк нам никак не подходил.

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

В Европах и других странах с железом чуть полегче, но всё равно Хуавей-то под санкциями, поэтому тоже пришлось подумать.

▍ Собственная разработка

Поскольку нас заодно прокинули вендоры разного софта, пришла пора возвращаться к собственной разработке. Не, мы честно пытались интегрироваться с разными крупными отраслевыми решениями. Часть с нами просто не работает ни в какой стране, потому что моя фамилия заканчивается на «ов», а это сейчас западло. Вторая часть такая, что вроде бы вы им доверяете, а там дальше оказывается, что сложно понять, то ли их софт создаёт уязвимость в системе, то ли сам ею является. Потому что не надо аутосорсить на Восток свой продакшон сарвар. Привет, Гитлаб, привет, Рег.ру.

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

В целом про информационную безопасность сейчас большим достижением считается просто не накосячить. Ситуация страшная: доверять крупным брендам уже нельзя, ответственности ни у кого нет, предъявлять, если что, некому. Плюс беспрецедентный разгул киберпреступности. Проприетарное ПО сейчас — это способ огородиться.

Что нужно — делать свою панель управления хостингом. У всех, у кого есть KVM, стоят те или иные вендорские панели. Собственно, хостинги ломают через эти панели. С другой стороны, сделать своё управление — это задача класса скорее инфраструктуры Яндекса или ещё кого такого же крупного, мы для неё ещё не доросли чисто по масштабу. Итог — мы продублируем вендора и будем иметь план Б.

Снова понадобилось научно разбираться с трафиком. Если что, нашей сильной стороной всегда была сетевая безопасность — это потому что мы написали собственные сетевые драйверы и ещё когда был MS, успели получить все нужные сертификации. В целом, погружаясь в тему, могу сказать, что практически каждая компания говорит, что у неё всё самое безопасное — но это по бумагам. Реальные краш-тесты проводят единицы, и результаты их обычно лучше никому не показывать. В общем, мы провели ещё несколько десятков испытаний и поняли, что в IPv6-модели много чего нужно будет доделать. Пока на проде у нас IPv4, но готовиться надо.

Ещё одна особенность — если бы мы внедрили активдиректори, то мы потеряли бы сейчас контроль над инфраструктурой. Тот же VMWare перестал работать в России, и то, что делает три буквы-клауд на нём, — это, наверное, подходит под категорию муток. Для нашего уровня — в основном софт либо не объединён в общий ресурс, либо дорого. Получается не единое облако, а совокупность железок. Чтобы это стало одним облаком со сквозными автоматизациями, это сложно. Ну после 2022-го.

▍ Куда идём в целом

Что я понял — надо делать очень качественный монопродукт. Первые несколько лет хотелось всем сказать да и сделать как нужно клиенту. Это, кстати, путь, как суши, кальяны и детские игровые площадки появляются в пельменных. В общем, первые несколько лет хотелось сделать больше продуктов. Теперь идём не в сторону ярмарки «купи домен», «купи сертификат» и так далее, а в улучшение основного продукта — виртуалок. Это требует убираться около подъезда. Мы сосредотачиваемся так: запустили бесплатные сервисы типа DNS как у Амазона (не настолько крутой, но бесплатный, вот пост), API по стандарту OpenAPI и так далее. Могли бы сосредоточиться на продаже IP или ещё чём-то, но делаем то, что нужно админам виртуалок. В целом мы строим то, что можем сделать качественного с гарантией. Реселлить софт или какие-то другие услуги — это непонятная история с точки зрения того, что мы выступаем посредником, а VDS — это уже наш продукт, и мы научились его готовить очень хорошо.

Развиваем сообщество, без этого сейчас, кажется, никак. Причём наш путь — не обязательно клиенты. Это среда людей, которым может быть не пофиг на вообще вопросы хостинга в целом. Мы говорим на одном языке, у нас общие интересы. Многие вещи просто легче даются, если делать вместе. Тот же спутник или экспедиция на Северный полюс — это задумывалось как реклама, а стало чем-то вроде отдельных проектов по фану. Да и многие наши внутрикорпоративные штуки стали отраслевыми вроде всяких хакквестов. В общем, от такого маркетинга мы сами получаем удовольствие. И да, со спутником из рекламы и фана всё это постепенно превращается в серьёзный проект благодаря сообществу. Мы накопили экспертизу, нашли отличных людей, и моя шутка про ретранслятор до марсианской колонии оказалась внезапно чуть менее шуткой, чем я думал, когда это писал. Но про это позже, если будет что-то получаться.

Поменяли парадигму с клиентским негативом. Раньше за это отвечал маркетинг. Любой негатив находили маркетологи и должны были пытаться потушить. Но мы поняли, что можно сделать круче. С негативом должны работать те, с кем общение и создаёт у клиента негатив. В нашем случае тимлиды саппорта. Наша точка зрения — вы сами за собой убирайте. Если клиент начал бузить — тебе разбираться. Это эффективно. Во-первых, поддержка заинтересована сама в хороших отзывах. Во-вторых, мы используем природную лень — лучше один раз закодить, чем повторять три раза. Это несколько поменяло структуру компании, но мы сейчас ещё разбираемся. Возможно, через полгода я приду и скажу, что наш гениальный план оказался отстоем. Но, по крайней мере, мы попробовали.

У нас текучка в маркетинге, пока не знаем, что делать. Многие пришли, положили нас в портфолио («вёл корпоративный блог на Хабре № 1»), получили отраслевые награды и ушли дальше. С другой стороны, у нас небольшая очередь (я сейчас представляю, как это звучит, да) — и кадровый резерв. Последний раз замену в маркетинге закрывали 5 минут ровно. С людьми надо работать тоже иначе, не так, как мы делали до этого. Из прям совсем негативного — мы снова вывели всех в офис. Возможно, я как-то не так руковожу, но мы провели замеры и теперь против удалёнки и гибридности. Удалёнка в целом плоха для компании. Главный эффект — люди не разделяют работу и неработу, и дальше это ведёт и к выгоранию, и к снижению эффективности во время работы. Если хотите подискутировать — понимаю, позиция холиварная, но конкретно у нас есть результаты наших экспериментов.

Очень большим шагом для меня лично стал SLA. Сбоев избежать нельзя — это факт. Но можно быстро подниматься и можно адекватно себя вести. Мы готовы возвращать деньги, но не с барского плеча, а по стандарту. Мне бы как клиенту было бы приятно видеть простые и понятные правила игры. В общем, мы возвращаем деньги за простой с повышенным коэффициентом. Это, конечно, не миллион за час, когда у пользователя всё пропало, — но мы и знаем, что пользователи, у которых может всё пропасть, обычно делают как минимум два геораспределённых инстанса. И дальше вопрос честности нас с клиентом.

Когда мы считали SLA, внезапно выяснилось, что большая часть проблем — это не электричество или что-то ещё. Это сетевые атаки. Многие, кто считают SLA, считают его по состоянию включённого сервера без учёта возможности пропустить реальный трафик. То есть если есть электричество — это не простой. Это к провайдеру. ЦОД говорит: «У нас пакеты вылетели, ничего не знаем, возьмите другого провайдера или ещё пару». Мы в такие игры не играем, у нас SLA с сетью.

Автор: Никита Цаплин

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js