Вот эта штука примерно в 10 раз снижает затраты электричества на охлаждение
Мы строим последнее коммерческое облако в России. Мы маленькие, просто микроскопические. Но при этом, пока мы маленькие, есть время подумать про архитектуру и подходы, а также разобрать оверхеды прошлых компаний. Ну, знаете, у каждого был бизнес (или пара), после которого хотелось всё сделать заново правильно.
При определённом уровне масштаба думать становится дорого, и проще залить всё типовыми решениями и деньгами. Нам это пока позволительно.
Вот хочется верить, что мы делаем с нуля правильно. По крайней мере, как нам сейчас кажется.
Поэтому мы сели и подумали, какие затраты вообще можно оптимизировать, а какие сильно не поменяются никогда:
- Например, в копеечной экономии на комфорте сотрудников нет никакого смысла.
- Фонд зарплат явно должен использоваться на маленькую команду профессионалов, а не на большую толпу середнячков.
- Аренда стоек: каждая сотая доля процента цены скажется на нашей марже, тут надо очень чётко всё продумывать.
- Железо: жёстко торговаться много раз.
- Электричество — ключ к марже. Оно определяет место ЦОДа.
- Поставщики: строго взаимовыгодные открытые отношения, иначе — никак.
- Сразу нужен хороший юрист для договоров (там потенциально самые большие потери).
- Минимум совещаний внутри команды, там самые большие потери — то есть усиление архитекторов и сеньоров LLM-инструментами сразу.
Теперь давайте попробуем угадать, что получится, а что — нет )
Офис: не экономим
Мы не стали арендовать помещение в бизнес-центре класса B где-то за МКАДом, а нашли вместо этого офис рядом с метро Цветной бульвар. Долго искали, выбирали и в итоге нашли вариант с более-менее приемлемой арендой, который перекрывает кучу удобств: расположение, метро рядом, много интересных мест поблизости. Сели в приличном бизнес-центре, и по факту это не стоит нам огромных денег, а в общей массе издержек это вообще какие-то маленькие проценты.
Сотрудники: лучше дорогие профессионалы, чем много середнячков
У отечественных облаков обычно перераздутый штат и очень много затрат, которые характерны для корпораций.
Самая большая статья операционных расходов, как ни странно для облачного хостинга, — это зарплата сотрудников. И вот тут — самое интересное. Если раздувать штат середнячками, то получается очень дорого. И сейчас всё идёт к тому, что с маленькими командами может быть очень интересно и эффективно.
У обычного облака наших размеров — около 300 человек в штате. У нас — 30. Перебаланс — на разработчиков вместо инженерной службы, чтобы максимум вещей решать автоматизацией.
Эффективность у двух условных middle или senior при одинаковой зарплате может отличаться в 10, а то и более раз. Мы всячески стремимся, чтобы каждый, кто к нам приходит, был настоящим монстром в своей области, знал про соседние и при необходимости умел закрывать разные компетенции. Чтобы не было историй типа «Ой, а это за соседним шажочком, это меня не касается».
Благодаря тому, что команда у нас очень маленькая, мы не тратим времени на всякую фигню типа долгих внутренних согласований и излишнего проектирования. Нам проще быстро сделать proof of concept, посмотреть, как это работает, и если ОК — двинуться дальше, а если нет — выкинуть и сделать новый подход. Мы можем быстро договориться между собой, что будем делать, и бюрократия у нас отсутствует как класс.
Вероятно, за пару лет мы сначала подрастём по саппорту и немного — по инженерной службе, а потом точка зрения может и поменяться, если вдруг вырастем. Но посмотрим.
Аренда стоек: экономим, но без снижения качества
Сумма там некислая. Этот пункт очень важный в проработке, мы очень долго искали, куда встать. У нас есть свой ЦОД в дальнем Подмосковье, и были нужны площадки в Москве (желательно — две) плюс несколько ЦОДов по стране. В Москве IXcellerate сделали нам очень выгодное предложение по цене киловатта на стойку и, что важно, полностью закрыли нам периметр. То есть фактически сделали кейдж, не требовавший никаких расходов. У них прямо закрываемые коридоры, всё классно, и мы получаем изоляцию — невозможность постороннего физического доступа без дополнительных затрат. Это очень ценно, потому что в других ЦОДах создание такого периметра — просто огородить кусок машинного зала решёткой — начиналось от восьми миллионов единоразовых затрат плюс сразу вырастала арендная часть.
Интернет в офисе: бросили свою оптику
Мы сами — облачный провайдер и пользуемся услугами провайдеров, подключённых в ЦОДе. Подключать с такими вводными отдельную точку доступа в офисе и платить 30–50 тысяч за гигабит не очень интересно.
Вместо этого мы один раз потратились на достройку трассы, понесли разовые операционные издержки и сейчас за достаточно скромные деньги арендуем тёмное волокно, сидя в офисе на 40-гигабитном аплинке, который напрямую соединён с нашей внутренней облачной сетью. Как вы, возможно, помните, у нас был злобный управдом, который на три месяца задержал нам эту историю, но потом оказалось, что он вообще не нужен в согласованиях.
Электричество: жёстко экономим
Место для своего ЦОДа и политика энергопотребления стоек в аренде — это прямо основа оперкостов, сравнимая с зарплатами. Именно поэтому мы сначала нашли электростанцию и подстанцию, затем купили землю под возможность бросить ещё одну трассу (поставить промежуточный узел) и там развернули ЦОД, а уже только потом охренели от стоимости подключения оптики. Но, какой бы она ни была, если есть дешёвое электричество — это не очень важно.
В арендованных ЦОДах важна автоматизация выключения неиспользуемого железа.
Ещё одна наша волшебная особенность — экспертиза в иммерсивке, то есть жидкостном охлаждении. Один из машзалов своего ЦОДа мы строим именно таким, потому что раньше там были ванны для асиков криптанов. Мы перезалили диэлектрик и погружаем туда обычные сервера. Это внезапно позволяет разгонять процессоры без перерасхода денег на вентиляцию. Охлаждение — это основной потребитель питания ЦОДов, если это не ЦОДы на Крайнем Севере.
Так вот, по нашим прикидкам, машзал на иммерсивке потребляет примерно в 10 раз (!!!) меньше электричества при полной загрузке (PUE = 1,03 вместо 1,30). Но это мы проверим на практике чуть позже.
Амортизация железа
Обычно железо служит четыре года, а дальше его становится невыгодно держать в стойке, потому что на единицу вычислений становится слишком много расходов. Новые линейки железа делают больше расчётов на киловатт-час питания плюс не надо платить за дико дорогую расширенную поддержку. А пара лет расширенной поддержки обычно равна стоимости нового железа среднего класса в энтерпрайзе.
Мы нашли способ уводить железо умирать примерно как это делает Hetzner, но через контейнеры и serverless. Там, где нужны массовые stateless-расчёты (или statefull-расчёты, где надёжная хранилка и ненадёжные расчётные модули) — ну, условно, например, это инференс нейросетей или обработка звука, видео и т. п., когда один любой расчётный модуль может в любой момент вылететь и никто ничего даже не заметит, — они идеальны для старого железа. Остаётся вопрос аренды стойки и электричества, а мы их решили жидкостным охлаждением и дешёвым ЦОДом в Подмосковье, напоминаю. Расширенная поддержка нам тоже не нужна: если процессор умрёт — ну умер и умер, мы его отключим от матрицы и погрузим в жидкость новый. Точнее, старый. По нашим расчётам, это позволит железу служить семь лет. Из которых последние три — в задачах матрицы, где нужны роевые вычисления, а не ответственные транзакции, как в задачах IaaS облака.
Своё железо
Железо у нас полностью своё, мы принципиально не берём сервера в аренду. Поэтому все технические потребности закрываем буквально по клику: надо — взяли и использовали. У нас нет историй с долгой арендой, хотя на старте б/у серверов у нас было много (они достались нам по наследству вместе с ЦОДом), и мы могли позволить себе разные эксперименты.
Покупаем сервера последнего поколения
HP заявили, что один сервер 12-го поколения (на котором стоит шестой Xeon) по производительности заменяет семь серверов 10-го поколения (на которых стоял второй-третий Xeon). Если смотреть по процессорам: в 10-е поколение ставили второй-третий Xeon, в 11-е — четвёртый-пятый плюс переход на DDR5-память, а в 12-е — шестой, и тоже DDR5, но ещё более быстрый. Его энергоэффективность как минимум вдвое выше, чем у 11-го поколения, и всё это легко переводится в понятные деньги и финансовые модели окупаемости.
Эксплуатационная служба
По классике для облака нам нужны круглосуточно работающие NOC, SOC и SRE. То есть всё это выглядело так, будто нам нужны целые три круглосуточные службы. Вдобавок к этому на каждом ЦОДе неплохо иметь инженеров, которые быстро реагируют на все изменения. Мы решили пойти не по классике и строим сейчас одну службу мониторинга, которая будет реагировать на все инциденты и стараться решить их по стандартным автоматизированным сценариям. А в случае неудачи передавать информацию либо сетевым инженерам, либо безопасникам, либо SRE’шникам, у которых вводятся дополнительные дежурства по инцидентам. Они не будут сидеть на месте круглосуточно, их задача — при необходимости реагировать на нестандартные ситуации.
Возможно, мы на этом наколемся, и через некоторое время я расскажу, как мы завели все три службы, но пока наш опыт показывает, что до 15 площадок так будет можно. А у нас пока их планируется восемь в этом году.
Работники на удалёнке
Серваки за последние годы стали более-менее надёжными. Заботу о них и необходимость инженеров непосредственно в ЦОДе мы прекрасно закрываем работниками на удалёнке. Аутсорсить такое дёшево. Но надо иметь в штате как минимум несколько админов, способных устроить «секс по телефону», если удалёнщик не понимает, что делать.
Аутсорсим неключевые задачи
Мы не строим in-house-службы. Нам проще разово обратиться в крутое агентство, решить задачу и успокоиться, чем нанимать специалистов, которые будут нужны очень редко. Например, когда нам понадобился брендинг, мы решили, что обратиться в профессиональное агентство будет эффективнее, и заказали его у агентства Signal (это часть ONY), они нам всю эту историю и проработали.
Агрессивно торгуемся
С капитальными издержками мы заморачиваемся намного сильнее, потому что тут есть за что биться. Во-первых, мы агрессивно торгуемся. Прямо по классике. Собираем несколько предложений и начинаем беседовать с поставщиками в стиле: «Смотрите, какую интересную цену предлагают нам ваши конкуренты, может, вы предложите что-нибудь ещё, чтобы мы согласовали с партнёрами именно вас?» Эта история может иметь развитие, где подключаются и другие с ещё более интересными ценами. Используя этот нехитрый метод, мы сэкономили на последней закупке на приличную двушку в московской новостройке, причём не где-то за МКАДом.
А если взять весь объём закупок, который запланирован на текущий год, то разница между начальными и конечными ценами может подрасти уже до стоимости пентхауса на Патриках. Правда, это означает, что закупками можем заниматься только мы с партнёрами, иначе эта условная «недвижимость» может достаться удачно подобранному сотруднику. Отследить это, кроме как занимаясь самостоятельно, я даже не представляю как.
Во-вторых, если не разобраться в комплектациях, лицензиях, совместимости оборудования и прочих нюансах, то есть большая вероятность купить дрянь по завышенным ценам. Когда я договаривался о нашей текущей закупке с российским поставщиком, то дал ему спецификацию и подробно рассказал, что мне нужно. Единственное, чего не написал, — конкретные партномера сетевого оборудования. Мне прислали коммерческое предложение на 690 тысяч долларов. Вроде всё норм. Но потом я попросил прописать точные названия каждой позиции с лицензиями. И понеслось! Во-первых, поставщик со своим проектным отделом вписал туда несколько лицензий, несовместимых с оборудованием, а во-вторых, закупка в момент внезапно подорожала до 740 тысяч долларов, «потому что Трамп ввёл новые пошлины». Увеличенные пошлины, правда, касаются поставок в Штаты, но поставщиков это в тот момент не волновало.
На следующий день мы созвонились, и я потратил минут сорок на то, чтобы объяснить продукт-менеджерам поставщика, какие лицензии подходят, а какие — нет. От всей этой истории я знатно офигел, но ребята подумали и вернулись ко мне с ценником, который был ниже, чем изначальный, прописанными номерами и нормальными лицензиями. Это было приятно. Поставщик был московский, но, судя по всему, в целом он транслировал взгляд на продажи китайских производителей.
Потому что с китайцами всё вообще очень интересно. Однажды нашим коллегам нужно было купить много асиков, и мы помогали им закупиться. Через хороших знакомых вышли на человека, который, скажем так, возглавлял китайский Главстрой и был отнюдь не последним человеком в партии. Если бы всё получилось, то мы купили бы через него весь годовой объём нескольких заводов, консолидированный в один заказ. То есть асиков было нужно очень много. Всё было здорово, пока нам не выставили цены выше, чем у российских перекупщиков с их наценкой. Мы тихонько поинтересовались, в чём тут бизнес. В ответ нам родили небольшую скидку, но модель не менялась. Я запросил те же железки напрямую на заводе — ценник получился ощутимо ниже, но все равно не проходной. То есть это в принципе общая странная тенденция — китайцы заряжают цены «на дурачка». Нужно проверять буквально каждый заказ, который формируется в Китае. В любой момент цена может оказаться завышенной вдвое просто потому, что им так захотелось. Даже у проверенных поставщиков.
Буквально на днях мне понадобилась новая линейная карта в наш холодильник (Juniper MX960). Я пошёл туда, где в прошлом году покупал такую за 1,8 миллиона, и ровно за то же самое у меня попросили уже три миллиона, ссылаясь на китайцев. Я начал искать альтернативу и нашёл в наличии за 1,4 миллиона. И так — каждый раз. С ними нужно долго торговаться, бодаться, но как только договорился по одной поставке, следующая может стать снова невыгодной, потому что однажды вы расслабитесь. Это как на рынке: даже если вы покупаете в Китае овощи у одного продавца, то он каждый раз будет говорить вам, что цена выросла. Прямо каждый день у него будет обстоятельство, почему сегодня дороже, и каждый день нужно будет торговаться обратно до старой цены.
Анализируем каждое технико-коммерческое решение со всех сторон
При закупке оборудования я всегда моделирую в Apple Numbers (не Excel: у меня Numbers на Mac) технико-коммерческое решение. Собираю и техническую, и коммерческую стороны, вывожу итоговую цифру. Бьюсь при этом буквально за каждую десятую долю процента в периоде окупаемости. Высчитываю стоимость владения и все операции, связанные с обслуживанием железа и сетей, расход электроэнергии для каждой конфигурации, объём ресурса, который можно продать из построенной инфраструктуры, стоимость закупки и содержания. У одного и того же вендора разные конфигурации из одной и той же линейки могут за счёт производительности отличаться по времени окупаемости в два раза. Всю экономику может поменять какой-нибудь очень мелкий фактор, поэтому проверять всё нужно гипервнимательно. Например, если говорить об оверхеде, то любая виртуализация — это оверхед. У нашего любимого OpenStack он настолько высокий, что на одном и том же железе наша платформа и OpenStack при прочих равных будут отличаться по времени окупаемости примерно в два раза. Для конечного клиента это выражается как минимум в ценообразовании.
Налаживаем отношения с поставщиками
Одно из важных наших правил — всегда выстраивать честные, прозрачные и взаимовыгодные отношения с партнёрами, поставщиками, арендодателями — да со всеми. И этот прямой подход без попыток схитрить и пожадничать многократно оправдан.
А ещё для хороших торгов важно, чтобы и поставщик, и заказчик были грамотными.
Самые лучшие решения строятся на взаимодействии их компетенций. Грамотные и заинтересованные поставщики вносят свою экспертизу, например, могут предложить другую модель, чтобы компенсировать какую-то характеристику количественным фактором или любопытной опцией.
В частности, мы договорились с MasterTel и ЮЛ-Ком о том, что каждый аплинк Интернета в каждой нашей локации будет по 100 гигабит. От каждого провайдера таких два, идут независимыми маршрутами через разное оборудование (это важно!). Суммарно выходит 800 гигабит! Вроде перебор: у того же СберКлауда весь внешний трафик на облако в среднем — 40 гигабит, и кажется, что больше и не надо. Но наш аплинк — это задел на будущее, в том числе — на эффективную защиту от дидоса. И это становится возможным только благодаря взаимовыгодным партнёрским отношениям.
Хороших поставщиков нужно любить, уважать, выращивать под себя и быть с ними предельно честными и аккуратными в расчётах. Если они будут периодически поставлять товары в долг, а потом годами через суды выбивать оплату, то им станет неинтересно работать.
Моя жена — закупщик в строительной компании. Когда она только начинала свой путь, опытные коллеги говорили ей: «Твои поставщики — твой актив». Она прислушалась к совету и начала их холить и лелеять. В итоге её поставщики уже несколько раз переходили за ней из одной компании в другую. При этом у неё обычно и цены раза в полтора ниже, чем у коллег по цеху, и поставки почти никогда не срываются. Она приходит на новое место и сразу даёт цены лучше.
Внимательно читаем договоры
Договор может состоять из 70 страниц, но, если не прочитать их очень внимательно, можно влететь в неприятную историю. У нас этим занимаются два юриста: первый проверяет все пункты на предмет странных приколов, а второй проводит очень тщательную due diligence поставщика: как он ведёт бизнес, какие у него обороты, как долго он находится на рынке, сколько у него судебных исков и каких. Мы получаем рекомендации даже из налоговой, работать с этими людьми или нет. Ну, потому, что, например, делать закупку на 150 миллионов рублей у поставщика с годовым оборотом в 10 миллионов — как минимум странно. То есть посмотреть мельком руководителей через rusprofile или focus.kontur явно недостаточно. И СБ у нас работает не столько по формальным признакам, сколько готова решить любую непонятную ситуацию. Была история с собственником подвала, который не хотел подписывать бумагу на прокладку трассы: он ждал «денежных предложений». После одного звонка с упоминанием «общих знакомых», через 15 минут пришла SMS, что курьер с документами отправлен.
И такой подход выручает.
Вот недавний пример: поставщик прислал договор, где в приложении вместо спецификации была лишь «форма спецификации», а сама спецификация в случае отсутствия берётся из счёта. В счёте же очень кратко были прописаны характеристики сервера, не было указано, новое на нём оборудование или б/у, и даже не были вписаны конкретные модели. А разброс цен у разных производителей комплектующих, например, оперативной памяти, может отличаться на десятки тысяч рублей. Если не вчитываться, то легко можно получить совсем не то.
А с нашими коллегами однажды произошла и вовсе дикая история. Крупный и проверенный поставщик привёз им новые сервера, а когда они начали ставить на них операционную систему, выяснилось, что она там уже стоит. То есть жёсткие диски, которые были заявлены как новые, на самом деле оказались бэушными.
В общем, главный минус такого подхода в том, что нужно постоянно быть в тонусе, изучать новинки и мониторить цены. Ещё нужно всё внимательно вычитывать — от спецификаций производителя до многостраничных договоров и лицензионных соглашений. Делать это нужно в режиме реального времени, потому что цены могут меняться по велению левой пятки. Необходимо постоянно мониторить каждую мелочь. Иначе даже поставщик, который давно знаком, может привезти совсем не то, что нужно, и доказать, что договаривались о другом, будет непросто.
Софт
Для экономии времени на старте мы брали некоторые хорошие open source’ные штучки, в том числе — для аутентификации. Например, аналитикой пытались затащить PostHog, но с ним ничего не получилось. Сейчас мы потихоньку пришли к своим компонентам там, где это целесообразно.
Из архитектуры мы выкинули всё лишнее. Библиотеки, компоненты и технологии не могут появиться у нас только потому, что они крутые. Они должны решать определённые задачи лучше всего остального. Наш стек предельно простой.
У нас нет каких-то строго стандартных рабочих систем. Кто-то работает на Apple, кто-то — на Linux, каждый использует те инструменты, которые ему удобны. Но в плане IDE у нас все используют либо JetBrains, либо VS Code (который, кстати, интегрирует нейронку прямо в IDE). Некоторые ребята используют Cursor, и это тоже помогает ускориться. Уже на старте у нас была поднята вся своя CI/CD-система, в которую входили Git-репозитории и Docker registry. Дальше мы её подружили с Argo CD и начали по десять раз на дню деплоить всё это в Kubernetes. Процесс разработки отстроен очень хорошо.
Если говорить про архитектурные устройства, то практически вся платформа сделана на Go, кроме одного микросервиса на Scala (критичного к нагрузке, распределённости, но требующего строгой консистентности данных, там самый хайлоад). Прямые вызовы — это gRPC, асинхронные — Kafka, и больше ничего лишнего. Если нужно хранение данных, то в большинстве случаев это Postgres. При этом каждый микросервис для своей же простоты может использовать те вспомогательные инструменты, которые нужны конкретно ему (например, «Баланс» работает с Cassandra и т. д). Деплоится всё это отдельно и независимо, все компоненты очень хорошо изолированы. Между бэком и фронтом есть слой middleware с GraphQL. Когда мы поменяли весь бэкенд с OpenStack на свою платформу, то с точки зрения фронтенда у нас не изменилось ничего.
Вайб-кодинг
Мы очень любим использовать нейронки и всячески поощряем команду их использовать, но правильно — об этом мы постоянно говорим. Они хорошо помогают грамотно формировать задачу, техзадание и детальное описание, прежде чем ребята начнут что-то кодить или отдавать кодить нейронке. И главный кайф: у нас нет необходимости писать ТЗ, долго обсуждать его всем коллективом и согласовывать между отделами. Вот тут я писал подробнее. У многих такой подход до сих пор вызывает удивление, хотя это как раз и есть новый мир. И он уже работает.
Промежуточные результаты
OPEX стабильно держался в районе 5 млн руб./месяц, а сейчас при запуске целых восьми локаций, расширении команды вдвое и подключении восьми 100-гигабитных аплинков не выходит за пределы 10 млн. И мы научились очень хорошо экономить на CAPEX. Благодаря такому подходу мы очень быстро окупаемся. И, значит, можем давать на наш ресурс хорошую цену.
Автор: km1337
