Молоко по 790 мл? Вот вам пример интереснее. У этого хостера цены те же, только комиссия чуть выросла.

Сейчас идёт серьёзный передел рынка хостингов из-за тенденции ходить в Интернет по паспорту.

Это моё личное мнение, но очень похоже на то, что в следующем году всё станет дороже, и сейчас я расскажу про факторы, которые с очень высокой вероятностью приведут к этому.

Сразу скажу, что в большинстве сценариев конкретно поднимать цен мы не будем, но у нас горизонт планирования — до мартовских выборов, а дальше ситуация может меняться довольно быстро. Мы уже поднимали в прошлом году с пониманием, что случится, и этого пока достаточно.

Итак, первое: теперь всем нужно будет интегрироваться с СОРМ и хранить netflow трафика.

Если что, то это:

• От трёх до пяти миллионов рублей на покупку софта.
• Примерно один-два человекомесяца разработки на интеграцию.
• Железо для хранения трафика. У нас получается примерно от 60 терабайт на каждый 1 Гбит/с у пользователя, и это без DDoS-атак.

Всё это ляжет на пользователей, конечно, потому что больше не на кого. То есть на вас.

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

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

Законодательный пакет
По ФЗ № 406 от 31.07.2023 лицензия на ведение деятельности хостинга теперь точно не нужна, необходимо лишь войти в специальный реестр. А чтобы потом из него не вылететь — поставить СОРМ и хранить netflow.

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

Сейчас правоприменительной практики нет, и я думаю, что первую пару раз будут предупреждения и штрафы, а потом — уже исключения из реестра.

Что интересно, трафик хранится сразу на трёх уровнях. То есть если мы арендуем несколько стоек в чьём-то огромном ЦОДе, то трафик хранят:

• Мы как хостинг.
• ЦОД как ЦОД.
• Провайдер как провайдер.

Эти плюс-минус 60 Тб на 1 Гбит/с будут хранить сразу три компании. Так что сам-то трафик точно не потеряется, наверное.

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

Но сетевой драйвер делает это без эффектов для пользователя, а в юзерспейсе эти эффекты будут очень заметны. На дешёвых тарифах может оказаться так, что половина ресурсов будет занята логированием действий. Мы бы не хотели такого, и у нас есть решение: поскольку мы разрабатывали сетевые драйверы под себя самостоятельно (и даже получали официальную регистрацию в репозитории MS до 2022 года), то сейчас нам в целом будет довольно просто поменять что-то на этом уровне.

Но всё равно это дополнительная нагрузка на серверы, она будет у всех, и не факт, что у всех — так просто. Насколько я знаю, разработкой драйверов занимается далеко не каждый хостинг. То есть эти расходы + расходы на внедрение и поддержку придётся поделить между клиентами.

Аналогично поступят ЦОД и провайдер, то есть волна подорожаний скатится сверху вниз до конечного клиента.

Курс доллара
Мы заложились на коридор 100–120 в 2024 году, но это как раз то, что меньше всего прогнозируется.

Курс доллара прямо сказывается на покупке железа, а хостинг постоянно его покупает просто для обновления парка (даже если не растёт) и для роста. Это включая элементарные расходники вроде блоков питания и SSD. У нас в прошлом году обновление парка было 27 %, а его прирост — 48 % от осени 2022-го до осени 2023-го.

Покупка железа
Само железо тоже покупается достаточно интересным способом.

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

Проблема в том, что у него нет поддержки.

Раньше мы покупали свежий сервер у «Хуавея» за 1,2 миллиона рублей. Сейчас свежий сервер — 1,5 миллиона, но это не то же самое. Некуда писать тикет: «Привезите новый диск, старый вылетел», поэтому нужно покупать ремкомплект. Об этом мы думали сильно заранее и закладывали в экономику, когда вся эта история была ещё на старте, плюс у нас хороший опыт обслуживания, потому что при вылете диска мы берём его из горячего резерва, а уже потом ждём next business day, чтобы вендор поменял нам диск в резерве, а не в сервере. В частности, поэтому у нас гомогенное железо — по всему миру.

На российском рынке такой подход — скорее редкость. Я знаю, что сейчас многие закупили самосбора. К концу года он начнёт ломаться, и надо будет самим его ремонтировать. В этот момент многие узнают, сколько это действительно стоит. Так и до паяльников может дойти.

Покупка софта
Аналогично: тут сказывается курс доллара и начинает проявляться недоступность ПО.

Зарубежный софт теперь просто не купить. Нужно искать аналоги, а это тоже не приключение на 20 минут, и тоже не факт, что за те же деньги. Самое больное — повышение цен на системы виртуализации. MS с их Hyper-V подняли цены почти на 40 % ещё в прошлом году, мы вслед за этим пересчитали экономику и подняли свои цены — вот этот пост.

ISP подняли цены на свои лицензии. А у них, кроме панели, ещё есть KVM/Openstack-сборка, которая хорошо поддерживается. По сути, это такой кастомизированный Опенстек. С «ВМварой» — тоже беда. Дальше вопрос простой: либо у вас сейчас поднимется цена на ваш любимый проприетарный гипервизор, либо вам ковыряться с условно-бесплатными решениями.

Условно-бесплатные основаны на опенсорсном KVM. Его надо уметь очень хорошо готовить. Это такой конструктор типа «Лего», из которого можно собрать Тысячелетнего сокола, и он будет прекрасен! Но чаще получается деталька в ноге. Вокруг KVM есть много коммерческих обёрток вроде «Проксмокса» или условно-бесплатной «Фьюжнсферы» «Хуавея».

У нас был опыт с «Хуавеем»: рассматривали «Фьюжнсферу», пытались развернуть силами их инженеров в тестовом сегменте — даже они не смогли поднять полноценную версию. Это сложный продукт.

Без платной обёртки надо много людей, чтобы разобраться. Платные становятся дороже.

«Проксмокс» — внезапно австрийский. Чтобы им и подобным платить, надо искать компанию, которая сможет провести платёж.

Платежи
Платежи бывают к вам в хостинг и от вас какому-нибудь вендору.

Обе схемы могут быть полностью легальными, но при этом мутными и рисковыми.

Например:

• Если вы принимаете платёж на партнёра в Казахстане, который закупает ваши услуги как агент и затем продаёт их в Европу, например, то всё легально — обе пары могут работать между собой. Но! Банки боятся вторичных санкций и поэтому могут обнаружить систематику в платежах и просто отклонить их, чтобы не влететь самим. На практике это означает, что деньги приходят не сразу, а через две недели, а могут и просто не прийти. Потому что когда банк пугается и окукливается, он не может заплатить вам, ведь вы — в России, а это уже запрещено. Я сейчас достаточно сильно упрощаю, там куча нюансов, но работает это примерно так.
• Когда платят вам, например, физлицо из другой страны, то у вас возникает проблема с кросс-курсами (как и в предыдущем случае, но там ещё можно хеджировать риски, а в случае физика это не получится), то есть платёж становится дороже в среднем на 20 % плюс комиссии за перевод через партнёров добавляют ещё 10 %. Если вы умеете готовить другие валюты — 30 %, если не умеете — 40 % допиздержек.

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

Мы не готовы, например.

А, ну и вырастет комиссия за пополнение, как в примере на скриншоте в начале поста. Это вообще странный способ повысить цену, вводя в заблуждение. Показываете 300 рублей за ВМ, ставите комиссию 35 % за пополнение, и вот в прайсе — 300, а заплатить надо 405 рублей.

Вроде при сравнении цен так не казалось. Мы, если что, комиссию вводить не собираемся, она у нас всегда 0 %. Потому что в нашей модели она на нас.

Инфляция и айтишники
Есть бытовая инфляция: это когда вы приходите в магазин, а продукты стали дороже. То есть за те же деньги можно купить меньше. Это нормальный процесс: деньги всё время дешевеют.

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

Ну и санкции, конечно. Они не работают, но тут 10 %, там 20 % — и вот уже набирается ещё одна причина для повышения цен в быту, что потом отражается на повышении ожидаемых зарплат.

Реклама
«Гугл» покинул нас (хотя в 2022-м ещё можно было заказать у него контекст) и даже через иностранные юрлица не рекламирует никакого российского бизнеса. В этот момент «Яндекс» разыгрывает схему, достойную Ленни из фильма «Рок-н-рольщик»: приходит и говорит, что бизнесу тяжело, и даст всем кредит. Заливает рынок дешёвыми деньгами, и все рекламодатели начинают бешено накручивать ставки. Результат этой помощи — ставки существенно выше (два-три раза в некоторых областях), рынок поднялся, а предприниматели даже не чувствуют себя кинутыми и благодарят «Яндекс». Гениально, говорю же! Я без наезда: это реально так же гениально, как открыть кредитный отдел в казино. И, возможно, всё это даже этично.

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

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

Блогеры, которые раньше занимались нативными интеграциями, соответственно, теперь потеряют возможность рекламировать что-то втихаря, и уже их реклама дорожает.

Уход зарубежных игроков
Это вроде бы обратный вектор: поскольку теперь нужно быть в реестре и иметь СОРМ, иностранные хостинги перестанут заманивать доверчивых россиян низкими ценами и обещаниями всяческих фич и надёжности. Увы, но эти обещания они часто соблюдают, поэтому образуется нижний порог цены, чтобы россияне не сильно разбегались. «Хетцнером» без проблем можно было пугать практически любой хостинг в нижнем ценовом сегменте.

Теперь «Хетцнер» перестал работать с русскими, а OVH не войдёт в реестр, потому что им будет сложно интегрировать СОРМ. Их клиенты перейдут в Россию. Да, возможно, после истории с GoDaddy кто-то скажет, что достаточно перебить почту на Гмейл, но просто помните, что показаться латышом может и не прокатить. И тогда ваши активы (например, домен) просто заберут. Мы вот свои домены уже перенесли как раз из таких соображений.

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

Возможно, качество при этом снизится, а цена в каждом конкретном случае вырастет. Но логика простая: куда вы денетесь?

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

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

Проблема в том, что, когда эта цепочка раскроется, заставят вернуть деньги, и это будет концом проекта.

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

Следующая налоговая льгота — не платить этого самого налога. Тут всё просто: гроб-гроб, кладбище, инспектор.

Консолидация рынка
Вот Рег.ру много кого покупали, многие средние покупали мелких, мелкие покупали нанохостинги и так далее.

Мелким компаниям войти в реестр за внятный экономический эффект — почти без шансов, поэтому они продаются, если повезёт — не за копейки. Что покупают? Покупают клиентскую базу.

Хостеров меняют очень редко: это не вопрос цены, это вопрос, что не надо будет там звонить какому-то админу. Человек платит что 300 рублей, что 450 — по большому счёту, если всё работает, это его несильно трогает. Вот именно это сейчас и продаётся. Причём зуб даю, покупается только ради того, чтобы затем поднять цены, освободить часть оборудования и перепродать его аренду дороже. То есть никто не покупает хостинг, чтобы сохранять прежние условия у уже лояльных клиентов.

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

Вот примерно что будет
Так что я вангую повышение цен в следующем году.

Как я уже говорил, мы повышать, скорее всего, не будем: у нас было плановое повышение в прошлом году. Я бы это и без «скорее всего» сказал, потому что финмодель очень хорошо работала, и мы всё посчитали, но планировать до конца года сейчас никак не выйдет в принципе, потому что возможны любые сюрпризы. Поэтому давайте так: не собираюсь. Если что, то у нас можно оплатить хоть на 100 лет вперёд, и мы продолжим оказывать услуги по предыдущим ценам.

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

Так что хорошего вам года!

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

Из-за этого мы сейчас переживаем крупнейший передел рынка хостинга в России.

С 1 декабря новый федеральный закон запрещает заниматься хостингом тем, кто не в специальном реестре. В специальный реестр можно попасть, грубо говоря, если выполнить требования по хранению трафика клиентов и их авторизации по паспорту, «Госуслугам» или платёжной карте. Там куча нюансов, но примерно так.

Ещё в этом году в ЦОДы начало поступать полностью отечественное железо из отечественной компонентной базы и отечественных плат (на самом деле — нет), отвалилась страховка от киберрисков от AIG (вместе с AIG), и пришлось искать российский аналог. Были скандал и мир с Казахстаном при открытии двух новых площадок, мы взяли премию «Хостер года», запустили собственный бесплатный DNS (аналог Route53), перешли на OpenAPI в хостинге, открыли ещё две площадки: ЦОДы во Владивостоке и в Турции в Измире (это там, где было наводнение), запустили и сломали спутник (дважды), пережили крупную аварию и после неё ввели понятное SLA на доступность с денежной гарантией.

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

Юридический катаклизм и деанонимизация Рунета
В этом году началось регулирование хостингов в России.
Вообще-то и так с 2016 года для предоставления хостинг-услуг требуется получение лицензии у Федеральной службы по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзора).

Но по факту до 1 декабря 2023 года любой школьник мог арендовать сервер, назвать его «Мегахостинг2000» и заняться услугами хостинга. То есть для ведения деятельности хостинга в реальности не надо было получать никакой лицензии.

Теперь это регулируется ФЗ №14512 от 28.07.2023, и чтобы быть хостингом, нужно быть в реестре. Если вы не там и предоставляете услуги хостинга — вы нарушаете закон, но пока ответственность за это не установлена. Точнее, даже так: непонятна, потому что нет правоприменительной практики. Но будьте уверены: эцилопы будут приходить по ночам, чтобы бить вас в той или иной форме. Ответственность появится!

То есть, по сути, теперь лицензия на деятельность хостинга — нахождение в специальном реестре.

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

Теперь это касается и мелких хостингов тоже.

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

Соответственно, нужно хранить netflow трафика, чтобы представить её по запросу. Это аналог пакета Яровой, и всё равно эту копию так или иначе вы должны были иметь. Опять же крупные хостинги это делали и так, а маленькие были готовы рисковать штрафами на юрлицо с уставным капиталом 10 тысяч рублей.

Третья особенность — маркировка IP-адресов. Сразу говорю, что сейчас я буду объяснять не как юрист, а как обыватель, то есть неточно и поверхностно с точки зрения конкретных норм, но общее представление это даст.

Теперь каждый клиент хостинга должен иметь авторизованный IP. То есть ваш айпишник (точнее, вашего, например, VPN-сервера) должен быть однозначно связан с вашим паспортом.

Это можно сделать напрямую через контракт, через банковский ID с помощью карты (она связана с паспортом) или через авторизацию на «Госуслугах» (там ваш аккаунт тоже связан с паспортом).

Это передовой опыт Китая и ряда других стран.

Дальше будет маркировка на доверенные IP и не очень. Каждый элемент критичной инфраструктуры Рунета сможет определять, что делать с разными IP. Например, если у вас доверенный айпишник — вас можно пускать на сайты Почты России, «Госуслуг», РЖД и, утрируя, в комментарии к губернатору. Если нет — можно смело вас блекхолить. Уровни доверия могут быть на усмотрение объекта инфраструктуры, например, «смотреть можно, логиниться недоверенным нельзя» и так далее.

Эта классификация — самое сложное в законе: много суеты, надо менять маркировки. Мы, как и десятки других хостингов, вошли в рабочую группу Минцифры по законодательству. Могу сказать, что предложения от нас и других представителей индустрии точно были услышаны, и всё стало чуть более здравым. Однако всё равно всё это — очень крупное испытание. Одно слово в законе меняет всё. Была, например, некоторая вероятность, что прямо сейчас будет авторизация только по «Госуслугам», это, конечно, был бы обвал рынка! В итоге все хостеры вместе собрали нечто такое, что решает задачи государства, но при этом с этим очень даже можно работать. Я знаю, как сейчас буду выглядеть в ваших глазах, но мне даже понравилось взаимодействие с Минцифрой: там работают очень адекватные люди. А я знаю, о чём говорю, потому что это не первый и не второй мой опыт взаимодействия с госорганами.

На волне всех этих историй про закон особенно активизировались те, кто хотел бы скупить конкурентов. Я отлично видел, как были заказаны крупные пиар-кампании по «ужас-ужас, мы все умрём!» и как разгонялась паника на рынке. Мы сами в какой-то момент чуть было не решили, что пора завязывать и продавать бизнес, но потом трезво взглянули на вещи и разобрались, что происходит. Ничего принципиально нового в требованиях не было, но кто-то кого-то купил, и так получился самый серьёзный передел хостинг-рынка за всю его историю.

Кстати, процесс ещё не закончился: сейчас ждём вторую волну с применением санкций к тем, кто не осознал, что надо играть по новым правилам.

В мире история с лицензиями выглядит примерно вот так:

• США (в некоторых штатах).
• Китай — обязательная гослицензия.
• Германия — для предоставления хостинг-услуг требуется получение лицензии у Федерального агентства по сетевым технологиям (BNetzA).
• Франция — лицензия у Агентства по электронным коммуникациям и почтовым услугам (ARCEP).
• Япония — лицензия у Министерства внутренних дел и коммуникаций (MIC).

Аналогично — с ограничениями на внутренние доступы. Например, хорошо знакомая российским айтишникам Турция не пустит вас в критичную инфраструктуру без турецкого телефона.

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

ЦОДы
В этом году — плюс четыре площадки. Первые две вы, вероятно, знаете, если читаете нас: это Казахстан — Астана и Алма-Ата. Там журналисты замечательного издания «Коммерсантъ» и не менее замечательного «Форбс» вместо «встаём в сегмент партнёров в ЦОДы крупнейшего оператора» написали сразу «заключили партнёрство с крупнейшим оператором». К чему все вот эти мелочи и лишние слова, да? Топы «ТрансТелеКома» узнали об этом из газеты за завтраком, поперхнулись чаем и спросили, кто мы такие и не охренели ли мы в край. В общем, через некоторое время всё решилось. Детали — вот тут в посте. Закончилось всё тем, что мы таким образом вышли на их руководство и встали на прямом контракте, то есть для всех сторон история завершилась максимально хорошо, насколько это было возможно.

Потом — Владивосток. Там просто хороший ЦОД. Владивосток выгодно отличается от других городов своей географией: вряд ли вы найдёте что-то ещё более далёкое и такое населённое.

Там прямо через сопку — Китай и Корея, поэтому для многих сервер там очень нужен. Если что, и пользователи всяких облачных сервисов, и игроки в «Контр-Страйк» часто гоняют трафик через Москву или вообще через Европу, потому что Россия — в EMEA, а маршрутизация часто идёт странным образом. Локальные серверы очень даже нужны!

Дата-центр расположен на территории градообразующего предприятия с высочайшим уровнем безопасности, собственной службой безопасности и новейшими технологиями предотвращения чп

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

Учитывая последующие события — очень мудро! ЦОД во всех этих историях не пострадал.

Дата-центр Netdirekt — единственный центр обработки данных, который подключается к большинству операторской инфраструктуры в Турции

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

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

Какое-то время это работало, пока не прилетел очередной сервис-пак с апдейтом для блока санкций. Ключевой банк прекратил работу из-за возможных вторичных санкций.

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

Ещё одна забавная вещь про оплаты — для российского рынка мы внедрили рассрочки через Яндекс.Сплит. Изначально я не понимал, кому они в принципе нужны, потому что при оплате за год мы даём скидку 30 %, а при покупке за год в рассрочку по Сплиту скидка получается 10 %.

Можно платить помесячно. Тем не менее есть те, кто покупает хостинг в рассрочку на год. Кто эти люди — я не знаю, но, раз им так удобнее, то почему бы и нет?

Железо
Железо можно где-то купить и привезти в Россию, но тогда это будет грозить поставщику вторичными санкциями. Либо купить сразу в России. Как я уже говорил раньше, мы были уверены, что крупнейшие банки и операторы связи будут закупаться и надо делать это вместе с ними. Так и получилось.

За границей мы берём «Икс-Фьюжн». Это вот в точности как «Хуавей», только совсем-совсем не «Хуавей». Никакой связи!

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

Собственно, задачей было найти гомогенное хорошее железо, мы провели десятки тестов и нашли. За последние два года мы обновили 27 % оборудования. Прирост парка оборудования — 48 % по отношению к осени 2021-го.

Страховка
Во всех юрисдикциях у нас есть страховка на случай киберрисков. Это когда из-за действий хостинга что-то пошло конкретно не так в реальном мире. Это часть нашего контракта, когда вы получаете дополнительный запас уверенности в том, что всё будет хорошо. Точнее, как раз если что-то пойдёт не так, то за хостингом есть ещё кто-то, кто не пропадёт и не продаст юрлицо в Грозный.

В России это тоже была AIG, но сами понимаете, что они ушли из России.

Мы обошли российские компании и столкнулись с тем, что никто не понимает, как считать киберриски. В итоге нашли одного страховщика, который сделал тот же пакет, но при этом был категорически против того, чтобы мы рассказывали детали, потому что они живут в России и слишком хорошо знают отечественный менталитет. Если мы объясним, что и кто страхует, то точно появится умный замотивированный хакер, который попробует доказать им их неправоту.

Поэтому не называем их в рекламе )

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

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

Если что — лежат все. Простой и падение статистически будут всегда. Можно погуглить название любого хостинга со словом «упал» и получить подборку случаев. Кто-то просто заметает эти истории под ковёр, а кто-то рассказывает. У нас, например, в этом году был крупный простой в Королёве, который затронул около 0,5 % всех наших клиентов.

Про большую аварию
17 июня у нас была большая авария в Королёве. На три с лишним часа отключилось от 7 до 10 % виртуальных машин ЦОДа. Подробный разбор — вот тут, последствия — вот здесь. Как видите, мы рассказали, что там было (сейчас это читается уже со смехом, правда, немного истерическим), какие выводы мы сделали.

Из важного: вы тогда много говорили про финансовые гарантии на такие случаи. У нас в договоре их на тот момент не было, но мы считали хорошим тоном компенсировать клиентам простои.

Теперь мы апдейтнули договор и ввели первое внятное SLA на доступность. Сейчас компенсируем время простоя в пятикратном размере. На всякий случай: мировая практика на данный момент — «ну лежит и лежит», то есть, если вы опытный админ, то используйте две площадки. Дальше вам добавят время простоя или х 2 от времени простоя во время аренды сервера.

В России есть хостинги, которые платят при простоях ниже, например, 99,6 % и на премиум-тарифах (либо компенсацию до 35 % от стоимости услуг в месяц). Наше предложение работает на всех тарифах. У нас х 5 — с первой секунды. Да, это не совсем то, что идеально защитило бы каждого клиента, и всё ещё сидеть на одном инстансе не стоит, если вам важна доступность. Но пока это хороший компромисс. И это важный шаг для всего рынка. Так получилось, что мы задаём некоторые стандарты, и я надеюсь, что хотя бы такой стандарт, который мы точно можем обещать, станет базовым для сферы.

Естественно, мы сделали многое, чтобы это не повторилось, но вот эта история с SLA — для нас она очень важна, потому что мало кто делает что-то подобное. Пока смотрим.

Спутник
Мы наконец-то запустили свой спутник. Разбор — вот здесь, разбор аварии с ним — вот тут.

Коротко: флеш-память борткомпьютера смёрзлась и не читается. Когда мы разбирали аварию, то говорили, что есть призрачный шанс перезапустить всё по питанию и посмотреть, что получится.

Успешно перезапустить борткомпьютер так и не получилось.

Мы отработали на спутнике первый космический CTF, а потом решили, что раз уж борткомпьютер не пашет, то почему бы не отдать это всё на благо науки. Было очень конкретное применение: наши друзья из «Позитива» просили пожертвовать спутник для изучения, чтобы русские хакеры (белые шляпы) попробовали отработать его практический взлом и перехват управления. Потому что такая угроза сейчас возникает всё сильнее, а учиться особо не на чем.

Ну мы и отдали спутник сообществу. В CTF летом спутник использовался пассивно, ключ забирался просто с ретрансляции. А в Hacking Week «Позитива» уже надо было взломать его полноценно. То есть мы развернули копию ЦУПа для хакеров, куда надо было пробиться через реальные защиты, спереть протокол для управления, получить доступ к управлению антенной, навестись на нужный спутник по координатам, дать сигнал. Единственное исключение — в протоколе для Hacking Week были вставки «учебный», на которые спутник отвечал: «Типа ОК» вместо настоящих действий.

Эта история очень хорошая, потому что раньше для анализа киберрисков никто не давал спутников. А история заключается в том, что раньше все спутники были военными с кастомными платформами, и достать второй экземпляр было сложно. С появлением кубсатов можно скачать базовые прошивки примерно 10 % спутников в опенсорсе, воспользоваться уязвимостями ОС Linux и других систем, аппаратными багами стандартных платформ и так далее. То есть можно просто купить домой железо и сидеть анализировать его. Это резко повышает опасность для новых проектов. Понятно, что все кубсаты с орбиты не свести, но повредить несколько процентов вполне реально.

Наши партнёры с МКС очень опасались этой истории, потому что всё это звучит несколько страшно для индустрии, где рулит Security through obscurity. Но тут мы независимые исследователи. Поиск уязвимостей космических аппаратов — это научно-образовательный проект. Пикоспутник — наш, нам его не жалко, даём ломать. Он выполнил программу, насколько смог, дальше можно добивать.

Надо сказать, что не добили, и можно попробовать то же самое ещё раз, наверное.

DNS-сервис
Функционально это почти амазоновский Route53. Интересные применения такие:

• GeoIP, чтобы разрешать пользователя в ту страну, откуда он. Например, если из Швеции — на шведский поддомен. Точность получилась около 70–80 %.
• LoadBalancing: можно задать доли распределения, и пользователь будет пробрасываться на площадку не балансировщиком, а прямо с уровня DNS. Не самая точная в мире балансировка, но очень простая и применимая. И бесплатная.
• TimeOfDay: куда направлять и в какое время. Например, на пиковые вечерние часы можно добавлять дополнительный сервер, который отключается в спокойное время.
• GeoIPFilter: пускать или не пускать по GeoIP.

И так далее. Подробности — тут. Получилась бесплатная штука (в «Амазоне» это за деньги), которая не так чтобы увеличивала нам поток клиентов, но точно полезна для рынка.

Технически она сейчас в публичной бете, как только доведём до полного прода, возможно, станет платной.

Всё почему? Админы привыкают к хорошему! В России функционал хостингов — не Digital Ocean и не «Амазон», конечно, но мы делаем самые важные штуки, которые юзабельны. DNS плюс OpenAPI — это хороший шаг в сторону удобства.

OpenAPI
Ну тут всё просто. У нас был свой API, перешли стандарты OpenAPI. Теперь у нас — как в лучших домах Парижа: как в Digital Ocean.

Мобильной версии сайта снова нет
В прошлом году нас часто критиковали за то, что нельзя купить виртуалку с мобильного телефона. Серьёзно, есть админы, которые привыкли покупать виртуалку с мобильного телефона! Переделывать весь сайт долго, но со временем мы это сделаем. И опыт мобила очень сильно отличается от опыта десктопа.

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

Хостер года
Несколько лет мы подавались на эту номинацию и наконец-то выиграли.
rdca.ru/2023/nominant/319

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

В этом году мы сделали столько, что знали: мы отлично поработали! Плюс 47 % к клиентской базе, продажи лицензионного софта на хостинге, решение вопроса с платежами для себя и части рынка, выход в Казахстан и так далее.

Мы шутили про эти телефоны, а они пригодились на прошлых выходных. Точнее, пригодилось резервирование телефонии. Не конкретно эти, но похожие)

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

Но давайте обо всём по порядку.

Сколько клиентов пострадало?

На три часа и более в одном ЦОДе отключилось 7–10 % из 14 наших, то есть менее 0,5 % от общего числа клиентов хостинга (точнее, хостов). Тем не менее мы очень подробно рассказываем про эту аварию, потому что она вызвала очень много вопросов.

Почему вы занимаетесь ЦОДом, а не встаёте в готовый?

«Прекрасная история, спасибо! Совет автору: ищите компанию, которая занимается ЦОДами давно и профессионально, ну а вам — переориентироваться на продажу сервисов/мощностей в этих ЦОДах...»
Сейчас по миру у нас 14 ЦОДов, где можно разместиться. Один из них, первый в Москве, с которого всё начиналось, — наш. Именно в нём произошла эта авария, и именно поэтому я так подробно всё рассказываю. Естественно, было бы логично уже давно сосредоточиться только на VDS-хостинге, как мы делаем везде по миру, но это наш базовый ЦОД, он для нас дорог. В смысле пока всё же экономически обоснованнее держать его. Плюс у нас на площадке есть аттестация ФСТЭК, что позволяет строить защищённые сегменты. Ну и охрана у него впечатляющая, про это — ниже.

Вообще тут вопрос намного более сложный. RuCloud Королёв — это наш первый ЦОД. Мы его создали сразу после истории с «Караваном», когда «Караван» ушёл в небо. Напомню, что они при срочной необходимости переехать не смогли забрать с собой энергетику и много других вещей, и это стоило им бизнеса. Полностью. Теперь — про экономику ЦОДа: если вы строите свой, то с масштабом снижается доля постоянных издержек. То есть с экономической точки зрения надо строить ЦОД как можно большего размера. А вот с точки зрения ведения ИТ-бизнеса в России — как можно меньшего, потому что, если есть выбор между одним ЦОДом и двумя-тремя, второе намного надёжнее. Но каждый инстанс получается дороже. В итоге мы построили свой ЦОД, подняли в нём аттестованный ФСТЭК сегмент (это своё помещение, защита от прослушивания, защита от лазерного считывания вибраций, сертифицированное оборудование, сертифицированное ПО, аудиты) — такого на общих площадках в принципе не сделать, а некоторым клиентам это важно. В смысле по рекламным проспектам может создаться впечатление, что можно, но нет. Равно как и с PCI DSS в Европе чаще всего — так же. Опять же свои админы, свои правила. Но тут — как с 3F: лучше всё же арендовать.

Соответственно, дальше мы раскладывали яйца по разным корзинам. Сейчас их 14. К концу недели будет 15. Можно выбрать любую.

То есть надо читать блог, чтобы понимать некоторые незадокументированные особенности ЦОДов?

Да. Мы же не можем прямо на сайте явно написать про ЦОД в Амстердаме, что там в стране легальны порнография и варез, и поэтому там можно выкладывать свежий фильм Михалкова без юридических проблем. Точно так же мы не можем рассказать про все особенности других ЦОДов. По большому счёту они сводятся к тому, что «по беспределу не заберут сервер», к особенностям охраны, питания, законодательства страны и так далее. Корпоративных клиентов мы консультируем на переговорах, если надо.

Сразу скажу, что даже Tier-IV никак не защищает от аварии. У нас был пример, когда 10 часов не было Интернета в Швейцарии. Они каждые 15 минут писали, что сейчас всё будет, кстати. Молодцы! Хороший статус-апдейт.

Вкратце вот: в ZUR1 (Цюрих) — 2N по питанию и N+1 охлаждения, внутренний стандарт SLA — 99,999 % (это выше, чем в Tier IV по UI). Во Франкфурте (это наш второй Tier IV UI) — N+1, два городских ввода от разных станций. EQUINIX LD8 гарантирует SLA TIER III (99,98 % — те самые 105 минут простоя в год). Питание и охлаждение — N+1, но они очень сильно заморочились на резервирование Интернета, аплинки с нескольких магистралей. Linxdatacenter — питание N+1. Екатеринбург — N+1. AMS9 — N+1. Останкино — четыре независимых ввода, прямое подключение к ТЭЦ-21, N+N.

А вот что мы реальном можем сделать — это написать SLA в каком-то виде на каждом из ЦОДов при выборе места для создания VDS. Это мы сейчас обдумываем, потому что SLA надо считать и фактический, и какой-то ещё прогнозный.

Уложились ли вы в свой SLA?

«Было бы очень интересно послушать про SLA и про то, как оно сейчас реализуется в текущей действительности...»
У нас по этому ЦОДу SLA — с 99,98-процентной доступностью, это 1 час 45 минут возможного простоя в год. Сразу скажу: это только в рекламе, а в документах это никак не регламентировано. Но мы всё равно выплачиваем компенсации.

Напомню, что в этом ЦОДе были клиенты с простоем больше трёх часов (77 % пострадавших), около 10 % — с простоем около 12 часов, и около 1 % — с простоем больше. Естественно, мы сразу же обещали компенсации всем тем, кто попал под этот инцидент. Надо понимать, что речь идёт про оговорённые договором компенсации, то есть если там была трейдерская машина, которая должна была что-то выкупить в нужный момент и клиент от этого потерял или недополучил какую-то сумму, — простите, но по договору мы компенсируем время простоя сервера, а не недополученную прибыль в результате работы ПО. Для критичных случаев как раз используется георезервирование, и именно поэтому нас выбирают: среди российских VDS-провайдеров у нас наиболее широкая география.

Сейчас, возможно, мы ещё выдохнем и будем менять договоры в сторону более явного прописывания SLA. Если бы мы делали это заранее, то ЦОД в Королёве имел бы 99,96 % или 99,9 %, а не 99,98 %. Для примера: фактический аптайм 100 % с 1991 года есть в Останкино.

Собственно, поэтому Королёв и дешевле других ЦОДов по колокации. Мы продаём колокацию во всех точках нашего присутствия, но об этом мало кто знает. У нас много места везде, кроме М9.

Почему ИБП хватает только на одно переключение дизеля?

«Тут много всяких «полезных» решений насоветовали в комментариях, разумеется. Вроде стресс-проверок отключением электроэнергии каждую ночь и покупки ИБП с акумом на сутки работы. Лол».
Похоже, про ИБП всё же надо объяснить. На текущий момент общемировая практика — держать их из расчёта одного набора свинцовых батарей на юнит, что обеспечивает несколько минут работы. За эти несколько минут нужно сделать переключение питания, то есть завести дизель. Заряда хватает обычно и на второе переключение с дизеля на городской ввод. Батареи заряжаются около 9–12 часов минимум. В случае если отключений питания несколько, то с каждым новым разрядом вырастают шансы, что они отключатся вместе с частью стоек. Почему так? Потому что бесконечно копить батареи обычно не имеет смысла. Уже начиная с полуторного запаса начинаются сложности с их размещением (они травят водород, то есть нуждаются в своей вентиляции, им нужен свой климат-контроль, они очень тяжёлые, то есть давят на перекрытия). В ЦОДах высокой ответственности вместо свинцовых батарей используются ДДИБП — огромные волчки, вращающиеся в гелии или вакууме, которые крутят вал генератора. У нас такого в этом ЦОДе, естественно, не было. Если бы было — размещение было бы куда дороже, и логичнее было бы дублировать ЦОД целиком. Что, собственно, у нас сделано 14 раз.

Почему охрана не пускала админов в девять утра в субботу?

Потому что одна из главных фичей Королёва — это та самая охрана режимного объекта, которая не стесняется посылать на три буквы всех, кого нет в списках. То есть они как-то умудрились даже [данные удалены] лицом в пол [данные удалены] приехавших нас аттестовать [данные удалены]. Потому что они размахивали какими-то корочками и хамили.

В Останкино у нас, например, охрана — отдельным батальоном Росгвардии. Поверьте, туда не приедет никакой ретивый сотрудник МВД с документами на следственные действия по виртуальному серверу вынимать физический. А это известный российский риск: если рядом с вами стоят странные персонажи (а на любом крупном VDS-хостинге всегда есть доля таких клиентов, и я про это писал), то может приехать сотрудник и попытаться выдернуть сервер. А железо — оно не такое, что вот на этом сервере добрые, а на этом — злые. Оно общее. Мы по опыту коллег знаем, что самый быстрый возврат сервера по звонку начальника: «Ты что там такое творишь? Верни железку обратно!» — занимает пять часов даунтайма. Спасибо, такого не надо ни нам, ни нашим клиентам.

Поэтому охрана действовала ровно в рамках своих полномочий. Мы находимся на территории стратегического производства. С началом кое-каких событий тут очень поднялся уровень паранойи. Героев, желающих проскочить, потому что внутри что-то срочное, хоть отбавляй. Охрана — в нашем случае внешний периметр Росгвардии — пускает тех, кто есть в списке, и не пускает остальных. Аварийной команды в списке не было, им нужно было получить соответствующий приказ. В лица они нас знают прекрасно, но нет — правила есть правила! Как я уже говорил, они очень юзерфрендли, почти как UNIX. То, что нам надо обсудить, как пускать своих людей во время аварий, — это отдельный вопрос, его сейчас прорабатываем. Возможно, будем страховаться и выписывать дополнительные разовые пропуска каждую смену. Собственно, вы сейчас будете смеяться, но мы так и делали, просто не на всех, а на одного человека дополнительно на всякий случай, и как раз он смог приехать уже к концу инцидента.

Почему патрубок дизеля лопнул? Вы что, его не обслуживали?

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

Обычная практика ЦОДов нашего размера — резерв из N+1 дизелей. У нас был 2N, нужен 2N+1.

Как вы видите выше, даже Tier-IV ЦОДы не считают критичным подниматься до 2N+1.

Почему дизель чинили админы?

Потому что не было выбора: дизелист был снаружи. Естественно, админы не должны были этого делать, естественно, большое спасибо, что получилось. Админы — однозначно герои этой истории!

Почему на территории нет моториста постоянно?

Потому что при дублировании вторым вводом из города, дизелем, 2N дизелем и ИБП шанс, что понадобится моторист, исчезающе мал. Для предотвращения маловероятных рисков проще дублировать ЦОД, что, повторюсь, у нас и сделано 14 раз. Вообще каждый раз, когда встаёт вопрос повышения на 0,5 % шанса в случае аварии или при открытии новой площадки начиная с какого-то экономического порога лучше выбирать геораспределённость. Это же ответ про то, готовы ли мы запуститься после пожара топлива: нет, не готовы, мы потушимся штатно, но не перезапустим дизели в разумный срок. А вот что реально стоит пересмотреть — это режим работы вентиляции, нужны отдельные решения под неё.

Теперь — самое интересное. На каждые плановые работы или начало каждой аварии мы тут же зовём профессионалов с дизелем, который арендуем. То есть когда планируются работы на подстанции, у нас резерв 3N по дизелям (наши плюс привезённый мобильный) и мотористы в дежурстве. В данном случае ещё один дизель на 0,5 МВт и команда обслуживания прибыли и смогли попасть на территорию уже после включения луча из города.

Почему админы вручную включали оборудование?

«И «Админы бегали между стойками» — даже после отключения питания машины должны сами подниматься».
Как раз машины не должны сами подниматься. История знает слишком много ситуаций, когда несколько циклов включения-выключения по питанию разваливают рейды и ломается железо. У нас настроено так, что после нештатного отключения питания часть оборудования надо включать вручную осознанно. В обычное время, когда не надо зажимать руками патрубок дизеля, это очень хорошая практика. И нет, мы не собираемся менять её несмотря на произошедшую ситуацию. Это как с ремнём в машине: есть незначительный процент аварий, когда пристёгнутый ремень хуже, чем непристёгнутый. Но статистически верно пристёгиваться, если задача — выжить.

Были ли потери данных?

Нет, рейды не сыпались. Если не считать нештатных перезагрузок и потерь того, что было в оперативной памяти, всё остальное более-менее нормально (насколько мы знаем).

Почему вы не сделали всё, чтобы предотвратить аварию?

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

Как я уже говорил, мы исходили из двух неверных допущений в оценке рисков: что резервировать дизели надо по 2N, а не 2N+1 (уже исправили), и что DDoS-защита (за которой был мониторинг серверов) не нуждается в кластере коммутаторов, если есть один надёжный онлайн и один точно такой же в шкафу через 20 метров от стойки. Ну и главный косяк — мониторинг должен быть геораспределён, это мы знали, но не успели сделать.

От каких рисков вы защитились тогда, например?

Мы прекрасно отработали несколько прошлых рисков: и санкционные отключения оплат, и отзыв лицензии у банка с платёжным шлюзом, и крупные атаки прошлого года. У нас нет желания экономить на рисках, но у всего есть разумные пределы.

Например, мы очень долго занимались сетевыми драйверами и писали свои, а затем сертифицировали их в Microsoft (ну с последней версией уже не выйдет, а вот предыдущие сертифицированы и лежат в каталоге ПО гипервизора).

После общения с другими хостинг-провайдерами могу сказать, что ситуация с сетью у нас очень хорошая. Именно в Королёве у нас огромная плотность вычислительных машин — это из-за 30-рублёвых промотарифов. И у нас там порядок в сети. При последней большой DNS-атаке, затронувшей всю страну (привет, домены Битрикса!), пострадали, кажется, вообще все наши знакомые. У нас же только два человека хоть как-то пострадали среди всех клиентов. Два человека, Карл! Мне кажется, что это лучший показатель порядка в сети.

Мы предотвратили очень много инцидентов, направленных не в наш карман, а в сторону клиента, благодаря правильным ACL, драйверам и т. п. У этого есть оборотная сторона: в субботу не могли быстро включить коммутатор на замене вместо выгоревшего. Теперь продумаем и это, скорее всего, построим кластер.

В целом по этой аварии вопрос такой: «Действовал бы я точно так же, если бы мог вернуться в прошлое?» Ответ: «Скорее всего, да». Без проклятия знания все действия ДО были рациональными.

Почему вы пишете про такие вещи?

«Вот за такие триллеры вам можно простить горы проходного шлака, который обычно публикуется в этом блоге. Побольше бы таких историй! ;)»
Мы открыто рассказываем про все ситуации, которые влияют на хостинг. Да, мы прекрасно понимаем, что в России так не принято. Да, мы прекрасно понимаем, что из-за этого открывается много приподзакрытых глаз, не знающих, как всё изнутри. Да, мы понимаем, что другие хостинги, утаивающие детали про то, что у них происходило и происходит, до какого-то момента надёжнее смотрятся со стороны. Тем не менее моё осознанное решение как владельца компании — долговременная репутация. Если уж мы лажаем, то рассказываем об ошибке. Мы тут не на пару дней и вроде до этого момента более-менее успешно избегали серьёзных косяков.

«Захватывающая статья! Очень импонирует то, что вы открыто говорите о своих косяках. Думаю, что даже у недовольных отключением пользователей её прочтение повысит доверие к вам».

Если быть честными, то скорее наоборот. Это вот вторая публикация про менее чем 0,5 % клиентов хостинга, но при этом выглядящая так, как будто всё произошло по всему гриду. Но я очень надеюсь на то, что наши клиенты — всё же рациональные люди.

Как себя чувствуют админы?
С моей точки зрения, они герои той ночи! Но, тем не менее, они довольно сильно подавлены, потому что успели прочитать комментарии и чаты. Каждый раз возникает ощущение, что ты что-то недоработал, и при любой аварии ответственный человек начинает корить себя. Наши админы как раз очень ответственные, и ЦОД — их детище во многом. Естественно, они расстроены. Более того, мы с командой очень долго обсуждали, нужно ли публиковать материал про эту аварию второй раз: это ведь ещё один удар по ним фактически. Представьте себя сейчас на их месте: ощущение будет не из приятных. Полагаю, что девопсы и админы, которые знают, что у них в инфраструктуре что-то ещё неидеально (а это постоянное чувство, и оно сохраняется годами), это поймут.

ruvds.com

Коротко: 17 июня около часа ночи мы потеряли два ввода питания от города из-за аварии на подстанции, затем — один из дизелей, что вызвало «мигание» питания в подземном дата-центре. Итог инцидента — простой около 12 часов примерно 7–10 % машин одного из 14 наших ЦОДов.

Это просто дикая цепочка событий.


Это патрубок дизеля, перевязанный бинтом из админской аптечки. Сейчас расскажу, какую роль он тут сыграл.

Итак, мы потеряли оба городских ввода — всё как в худших домах Парижа. Как мы уже потом узнаем, вроде бы авария была на трансформаторе 110 кВт: при перераспределении мощностей с первого произошло замыкание второго. За полтора года это уже третий раз, когда пропадают оба луча, и вот тут я рассказывал, как мы почти сутки стояли на дизеле. Для клиентов это прошло незаметно (кроме той стойки, где при мигании света сгорел ИБП: там был простой на перезагрузку).

Штатно сработали ИБП, автоматически завелись дизель-генераторы, ЦОД продолжил работу. У нас общая энергосеть с соседним ЦОДом всё в том же подземном бомбоубежище. Общее потребление — 0,5 МВт, дизелей — на 1,05 МВт.

Через два часа, около 3:30 ночи, лопнул патрубок дизеля 0,5 МВт, отчего он внезапно перестал работать. Админы убежища переключили мощности на дизели 2 х 100 КВт и 2 х 200 КВт. В момент переключения нагрузка снова легла на ИБП, а за два часа они не успели восстановиться, и часть оборудования выключилась.

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

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

Дисклеймер: мы ещё не до конца разобрались с логами и причинно-следственными связями, но сейчас я пишу по горячим следам. Возможно, дальше выяснятся ещё интересные детали. Сейчас мы сосредоточились в основном не на расследовании инцидента, а на устранении последствий. Детальный разбор будет позже.

Что было с городскими вводами
Они пропали. Авария коснулась всего микрорайона. Мы относимся к важным потребителям электроэнергии, поэтому восстановление наших мощностей — первый приоритет для города. У нас не было городского ввода примерно с часа ночи до обеда, около 10 дали первый луч, через пару часов — второй.

Как можно видеть по заявкам в районе, жилые дома восстанавливали позже, то есть устраняли аварию максимально быстро для нас.



Почему только два админа
Ночь с субботы на воскресенье, особо охраняемая территория. В течение двух часов с начала инцидента всё идёт относительно предсказуемо, и помощь не нужна. Админы работают штатно. Примерно в 3:30 становится понятно, что нужно высылать подкрепление, но в этот момент уже:

Коммутатор защищённого сегмента сети вышел из строя.
Админы разбираются с дизелями и пытаются включить оборудование, то есть ходят от стойки к стойке и определяют, что случилось с каждой машиной.
Четыре других дизеля перегреваются и собираются отключиться.

Самое печальное — коммутатор защищённого сегмента, который включился, но работал неправильно. Это сегмент, в котором стоит DDoS-защита, то есть через него подключено около 7 % IP-адресов ЦОДа. Коммутатор зарезервирован по принципу HOT SWAP, то есть точно такой же лежит в коробке в шкафу в админской. Мы не думали строить кластер из двух коммутаторов, потому что не похоже, что DDoS-защита относится к критичным сегментам: при выходе её из строя примерно на 5–20 минут (время физической замены коммутатора) возможны DDoS.

То есть центральный коммутатор у нас нормально в кластере, а один из листов, относительно небольшая и относительно нетребовательная к непрерывности подсеть, на хотсвапе. Это была ошибка, и здесь мы здорово облажались.

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

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

В этот момент около 3:30 мы остались без сервисдеска, мониторинга, корпоративного мессенджера и одной из реплик сайта. Мессенджер тут же деградировал до «Телеграма», веб-сервер сайта автоматически поднялся в другом ЦОДе, а вот от мониторинга и сервисдеска такой подставы мы не ждали.

На мониторинг, в частности, было завязано определение оставшегося свободного места в ЦОДах, а оставшееся свободное место в ЦОДе определяет возможность создавать в нём новую виртуальную машину.

Это означало, что автоматика не видит свободного места, потому что источник данных для панели управления находился именно в глючившем защищённом сегменте. А потому система не даёт возможности создать новые ВМ в каждом из ЦОДов сети.

Выглядело это как крестик на создание ВМ на каждом из ЦОДов нашей сети, что начало вызывать панику в чате клиентов хостинга:

Это уже семь утра, когда существенная часть клиентов проснулась. До семи утра было ещё два отключения питания и перехода на уже истощённые ИБП. Перегрелся и начал нестабильно работать один из малых дизелей, а большой ещё не успели перебинтовать. И вообще, админы не очень хорошо ремонтируют дизели: это немного не их профиль работы.

Соответственно, клиенты пытались перенести свои ВМ в другие ЦОДы по миру, но из-за сбоя мониторинга не могли этого сделать: система не давала создать новые ВМ.

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


Админы были отрезаны от мира
Я неслучайно сказал, что это ночь с субботы на воскресенье на особо охраняемой территории. Дело в том, что после начала всем известных событий территория стала просто параноидально охраняемой.

Среди всего прочего в рамках общей параноизации нам отозвали все постоянные пропуска и заменили их на систему одноразовых пропусков персонала посменно. То есть около 3:40 ночи, когда уже стало понятно, что в ЦОДе не помешают лишние руки, никого отправить туда мы не могли, потому что люди встали бы на проходной.

Бюро пропусков по ночам не работает, по воскресеньям — тоже.

Это значит, что мы не можем отправить ещё админов и не можем отправить дизель. Дизель на 0,5 МВт у нас под рукой был после прошлого инцидента, и мы подтащили его к территории около девяти утра, но попасть внутрь не могли.

Охрана понимала всю серьёзность ситуации (насколько могла) и очень хотела помочь, но ровно в рамках своих полномочий: им нужно было разбудить своего начальника, чтобы он разрешил нештатную ситуацию. Попасть на территорию получилось только около 13:00.

До этого момента в ЦОДе было две пары рук.

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

Админы разрывались между попытками ремонта дизеля, жонглированием мощностями, включением стоек и сетевого оборудования и попытками понять, что происходит с защищённым сегментом. Плюс время от времени им было нужно подниматься на воздух, чтобы не разболелась голова.

Восстановление
Когда приехал резервный дизель, всё встало на свои места.

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


Последние сервера поднялись около 16 часов: это когда мы подключили в бой тот самый защищённый сегмент, стоявший за частично погоревшим коммутатором.

Клиенты, естественно, были не очень довольны:


Интересно, что больше всего тикетов с паникой было у пользователей наиболее экономичных тарифов. То есть те, у кого был действительно критичный проект, развернули его на нескольких геоплощадках. Бывалые админы достаточно спокойно наблюдали за паникой людей в чате:



Общий итог такой:

• 23% клиентов ДЦ вообще ничего не заметили, остальные могли ощутить даунтайм до 120 минут.
• 7-8 % виртуальных машин было недоступно более трёх часов. Мы не можем сказать точнее: верхняя оценка — 10 %, но мы знаем, что часть машин в рассыпавшемся сегменте отвечала, по косвенным данным, что это было всё же 7 %. Максимальный даунтайм на отдельных серверах из 7-8% составлял 16 часов.
• Всё 13 остальных ЦОДов работали штатно, но отсутствие мониторинга не давало создавать на них новые ВМ.
• Всё решилась после прибытия подмоги, то есть с 13:00 до 15:00. К 16:30-17:00 доступность была 100% восстановлена.
• В нашем ЦОДе не работало, по верхней оценке, 10 % оборудования. У соседей же была настоящая паника: у них пострадало до 75 % оборудования (судя по их письму клиентам).

Сколько/чего выключилось:

• Количество НОД перезагрузившихся из-за перепада/отсутствия питания в ночь аварии — 68 %: 24 % в 3:30, 26 % в 4:50 и 18 % в 6:00.
• Количество НОД дц Rucloud, которых не затронула авария — 23 %.
• Количество НОД дц Rucloud, которые стали доступны после решения проблемы с коммутатором (самое большое время простоя) — 8 %.
• Количество НОД дц Rucloud, которые были перезагружены 18-19 июня в результате выявленных последствий аварии — 1 %.

Разбор ошибок
Из того, на что мы могли повлиять:

• Нужен не двойной запас по дизелям, а больший: ночь показала, что двух недостаточно, нужно 2N + 1 минимум. Поскольку в кризисы мы объединяем энергосеть с соседями, договорились, что введем в эксплуатацию (дизель уже куплен, ожидаем к нему кожух) вместе ещё один 0,5 МВт ДГУ и разместим на территории.
• Коммутатор защищённого сегмента должен был быть задублирован в кластере. Как только мы разместили за DDoS-защитой мониторинг, сеть стала критичной, но мы этот момент упустили и оставили узкое место с ручной заменой железяки. Оказалось, что у неё есть не только бинарные состояния «однозначно работает» и «однозначно не работает», но и промежуточные.
• Тот факт, что мониторинг и тикет-система не были зарезервированы в другом ЦОДе, — это пощёчина нашему достоинству. Мы чёртовы параноики из финансов, и именно мы остались без мониторинга. Дублирование было в разработке и намечалось на конец июля. Немного не успели. Исторически эти системы размещались в первом нашем ЦОДе, теперь нужно распределять их по гриду, чтобы даже масштабный сбой никак не влиял на возможность заказывать виртуалки и обращаться в поддержку в других ЦОДах.

Я пережил несколько очень неприятных моментов этой ночью и понял, что нам нужен публичный мониторинг.

С моей точки зрения ситуация выглядела так: ужасно усталый я пришёл домой вечером, бросил телефон с 3 % заряда на столик и вырубился. Около шести часов я проснулся, решил, что быстро не засну, включил телефон почитать Хабр и сорвал джекпот в виде лавины уведомлений. Технический директор хостинга ночью тоже спал. Но он никогда не отключает телефоны, и звонки админов у него всегда дают громкий сигнал. Он разруливал ситуацию с часа ночи. Хорошо, что телефония в ЦОДе у нас как раз была зарезервирована правильно.

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

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

Мы рассылали вот такое письмо:

Всем привет!

В районе 3:00 по МСК произошла авария на подстанции, в результате чего в дата-центре Rucloud (г. Королёв) были нарушены оба ввода электроснабжения. Проблема повлекла за собой перезапуск коммутационного ядра и длительный период восстановления. На момент аварии оборудование дата-центра работало на аварийных дизель-генераторах, но сейчас проблема устранена, и доступность всех нод уже восстановлена. Специалисты работают над восстановлением доступа к единичным оставшимся оффлайн виртуальным машинам, и в ближайшее время доступ должен полностью восстановиться.

По предварительным данным, аварийные работы затронули не более 10 % серверного оборудования в дц Rucloud. Остальные 13 дата-центров работают в штатном режиме, и проблем там не наблюдалось.

Если ваша виртуальная машина была среди тех, что затронула сегодняшняя авария, обязательно свяжитесь с нами по почте support@ruvds.com. Каждый случай простоя будем решать индивидуально и начислять компенсации за простой.

Подробный отчёт по аварии ждите в нашем блоге на Хабре в ближайшие дни.
Приносим свои извинения за доставленные неудобства!

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

Никто не верил, что в одном из 14 ЦОДов был сбой, который затронул до 10 % железа. Отдельно меня обижали фразы вроде: «Чего вы хотите за такие деньги?» Аварии бывают и там, где на порядок дороже. У нас нет умышленной ставки на некачественные услуги. Неважно, сколько заплатить: зарезервироваться на 100 % не получится. Самое обидное в этой истории, что раздолбаями на этот раз оказались не мы. Точнее, мы тоже, но, трезво оценивая ситуацию, мы всё же в меньшей степени.

Вторая особенность была в том, что шквал звонков снёс поддержку нам и всем соседям, потому что люди звонили по всем телефонам и нам, и им.

Более-менее связную картину произошедшего мы получили только около восьми утра.

В целом это, наверное, — самый тяжёлый наш кризис, потому что мы его переживали при 100-процентно заполненном машзале. Когда гермозона стоит полупустой, есть резерв по мощности: формируется тот самый 2N + 1, а не просто 2N. У нас такой роскоши не было. В целом мы сейчас переберём архитектуру сети, но куда важнее, что мы в Москве принципиально делаем ставку на развитие Останкино (вот пост про него) — ЦОДа повышенной ответственности. И в убежище, и в М9 гермозоны уже заполнены полностью, и новых стоек просто нет. В случае М9, где мы делим площадку с другими компаниями, нет места даже в стойках соседей.

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

В процессе слова поддержки от вас были очень приятны. Благодарности в конце тоже очень грели. Спасибо! Это было очень тяжело, но то, что вы с пониманием отнеслись, — это очень приятно.

ruvds.com

Звонит как-то вендор и говорит, что в возврате бракованного железа — не их жёсткий диск.


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

Гарантийный отдел ковыряется с диском, а потом звонят:
— А зачем вы подменили диск?

Мы такие:
— В смысле подменили?
— Мы вам продавали другой. А тут корпус тот, а внутри — другой. Какие-то следы от отвёртки.

Дичь полнейшая! Мы начали было ругаться, но потом стали разбираться. Начали смотреть на камеры и увидели, что наш сотрудник очень подозрительно себя вёл, когда работал с этим диском в стойке. Как в плохих комедиях про жуликов: постоянно осматривался по сторонам, отходил в сторону, возвращался. Оказалось, что он подменил диск. Честно, я не знаю зачем. Его финансовая выгода минимальная, скорее всего, даже не окупает время работы по замене корпуса.

У нас было ещё несколько странных ситуаций, и сейчас я о них расскажу.

Форекс-трейдер
VDS часто покупаются для торговли на биржах. Ну, на нормальных биржах: я имею в виду тех, где важно географическое расположение сервера для минимизации задержек. Но есть и биржи уровня Форекса. Вернее их даже биржами назвать нельзя. Это на сленге трейдеров — кухня. Напомню, что многие из них попали в список компаний с признаками нелегальной деятельности, который завёл ЦБ. У меня есть глубокое личное убеждение, основанное на здравом смысле и математике, что система работает как качели для вытаскивания денег из не самых разбирающихся в вопросе клиентов. Возможно, это не так, но свою точку зрения я могу аргументировать и обосновать при необходимости. Но в истории важно другое. Звонит мой знакомый, который взял у нас сервер в Швейцарии. И вот он начинает в открытую меня и всех наших сотрудников обвинять в том, что мы залезаем к нему на сервер в процессе торгов и вмешиваемся в его форекс-сделки.

По его словам, он придумал великую стратегию, а убыточные сделки берутся рынком, плюсовые же вовремя не берутся, игнорируются. И в этом виноваты мы. Точнее, сначала он обратился с задачей, что его не устраивает производительность сервера. С его слов, она радикально падала в момент выхода новостей. В 16:30, когда выходит мировая статистика. В этот момент времени все трейдеры, кто работает с помощью автоматических торговых систем, начинают многократно усиливать свою активность. Если, грубо говоря, внутри дня он делает десять сделок, то в эти 16:30 и одну минуту он может сделать сто сделок. Естественно, это создаёт пик нагрузки, причём не локально, а на принимающем сервере. Но трейдер этого не понимает, он думает, что у нас сервер именно в 16:30, когда ему надо выставить заявку или закрыть заявку, тормозит. А это совпадает с самым нужным временем. И не верится, что это просто совпадение.

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

Здесь главная проблема — работа со знакомым. Если бы это был просто клиент, то мы бы провели диагностику и не получали оскорблений.

Игровые серверы школьников
Школьники довольно часто размещают у нас игровые серверы. Это, скажем так, сложные клиенты, потому что они выбирают третий по цене тарифный план. Первый — это промо за 30 рублей в месяц (по цене IP), второй — урезанная версия стандартных конфигураций за 130 рублей и третий уже полноценный сервер — от 300 рублей в месяц.

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

Поддержка вежливо объясняет суть проблемы и предлагает подключить защиту от DDOS-атак за 400 рублей (причём первый месяц бесплатно). По нашей практике, потом можно будет играть совершенно спокойно. На что клиент начинает нас обвинять в том, что это мы специально дидосим его, чтобы он нам заплатил ещё. Далее закономерно встаёт вопрос о возврате средств, и обычно мы средства возвращаем и с лёгкостью расстаёмся с таким клиентом.

Один из тикетов был похож на подобный, но с нюансом. Блокировки не было, дидоса не было, трёхэтажного мата тоже не было. Просто клиент запросил возврат средств с сервера, который был оплачен на несколько месяцев. А тут надо сказать, что у нас есть ссылка для оплаты, которую можно выставить наружу, и любой человек может оплатить хостинг для какого-то клиента. Это удобно, потому что бухгалтерии не обязательно логиниться в админпанель. Школьники использовали эту ссылку для краудфандинга, скинулись на сервак и начали играть.

Клиент пишет заявку на возврат средств, мы отправляем её в платёжный шлюз. И вдруг владелец удаляет сервер, начинаются тот самый мат и дикие крики про то, что вернуть надо на его счёт, а не на счета плательщиков. То есть условно у них было порядка сорока оплат по 100 рублей, и все их платёжный шлюз собирался распихать обратно по тем самым карточкам, с которых они платили. Но главному герою нужен был возврат на один — свой — счёт. В общем, в ходе диалога с поддержкой он уже прямо признался, что хотел получить чужие деньги. Через пару месяцев эта же история повторилась с минимальными вариациями с другим школьником.

Самый короткий детектив
Бывает, наши серверы берутся для обхода блокировок. Люди разворачивают VPN и просто ходят через наш сервер в большой интернет, если на работе он заблокирован. Ну или просто берут сервер в другой юрисдикции типа Швейцарии и ходят через него. Почему это важно, есть вот тут про маски-шоу.

И вот пишет клиент, что наш сервер не отвечает.

Мы просим трассировку. Клиент делает, присылает. Мы сообщаем, что RDP блокирует его отель, и желаем приятного отпуска в Таиланде. Клиент немного в панике, но мы поясняем, что его Wi-Fi-точка названа именно по отелю. И даём ссылку на то, как это обойти. В тот раз помогло.

Регистрации под ботами
Очень странная ситуация была с тестовыми периодами на наших 32-ядерных машинах. Кто-то научился брать американские номера, парсить голос, русский текст и цифры. Как только криптовалюты совершали очередной прыжок, начинались авторегистрации, а дальше серверы использовались (судя по характеру нагрузки) для майнинга криптовалют. Не знаю, что это было, но майнить биткоин на VDS без видеокарты — идея откровенно так себе. Процессор уходит в потолок, три дня они пытаются что-то там сделать, потом период заканчивается. Мы обновили капчи, но на следующей волне скачка курса биткоина снова начались авторегистрации. Я откровенно не понимаю, какой в этом смысл, ведь аренда американского номера стоит дороже, чем возможный профит с майнинга на процессоре три дня. Сейчас эти волны мы наконец-то победили.

Блокировки по IP
Мы выдаём один статический IP клиенту при аренде сервера. Это не карусель динамических адресов, не замены раз в месяц, а конкретный IP, привязанный к клиенту. Сначала мы проверяем его чистоту и отсутствие во всяких чёрных списках, а потом даём клиенту.

Дальше клиент может испортить этот айпишник. Например, инста-блогерки и инста-блогеры часто разворачивают у нас средства накрутки Инстаграма. Инстаграм их ожидаемо банит через некоторое время. Дальше в поддержку начинаются обращения: «Почему меня забанил Инстаграм?!» — с кучей смайликов. Или: «Почему меня забанило Авито, смените мне IP-адрес», но про Авито смайликов почти нет.

Ещё накручивают отзывы и просмотры на Амазоне. Потом — в поддержке: «Ребята, это мой не первый аккаунт, можете, пожалуйста, сменить мне IP-адрес, потому что меня забанило?»

Бывает так, что админ настраивает клиенту работу на сервере, но забывает уточнить вопрос про лицензии. Звонит генеральный директор, у которого 25 сотрудников, и они все сидят на удалённом рабочем столе, у нас размещали соответственно. Весь замес в том, что системный администратор, который это настраивал, был на аутсорсе. Он настроил кучу виртуальных рабочих мест. Человек платил около 35 тысяч. У него там размещалось 25 сотрудников, и 120 дней человек вообще не знал никакой проблемы с подключением к удалённому рабочему столу. А цимес в том, что Майкрософт даёт триалку на размещение этого удалённого сервера рабочих столов 120 дней ровно. Человек четыре месяца, получается, пользуется, и тут внезапно посреди пятого месяца обнаруживает, что у него ни один сотрудник не может зайти. Диктует нам ошибку, мы всё прекрасно понимаем, что у него там происходит. И предлагаем ему два варианта:
— Вы либо удаляете эту службу, которая не даёт вам подключиться вообще в принципе, либо платите за каждую лицензию.
— В общем, ребят, я не буду платить тройную цену от сервака.
Неудивительно, потому что лицензия стоит 91 тысячу рублей, а у него сервак стоит 36 тысяч.
— Ребята, надо, короче, решать. Давайте так: мне по-любому нужно это бесплатно. Что если мы оформим договор на другое лицо, и таким образом у меня будет ещё 120 дней? А что если вы измените человека, у меня сейчас есть знакомый, он зарегистрируется?
— А вы точно понимаете, что сейчас у официального партнёра MS спрашиваете, как их же обмануть?
— Да! Ребята, какие ещё варианты есть?

Неожиданный уход коллеги
Текучка у нас минимальная, поэтому, когда человек уходит, это целое событие. Главное в этом событии то, что на выходном интервью сотрудник уже может быть полностью откровенным, и мы часто узнаём про какие-то вещи, которые раздражают, но про которые обычно не говорят. Это самая полезная обратная связь для найма и удержания людей.

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

Это ничего не объясняло, но дальше удалось поговорить. Сотрудник сказал, что внимательно всё прочитал и не хочет, чтобы это случилось с ним. Поэтому увольняется.

Никаких выводов и действий. Просто, возможно, он счастлив где-то ещё.

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

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

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

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

Итак, бухгалтерше одного из клиентов нужны закрывающие документы о том, что услуга оказана. Документы есть в личном кабинете, они автоматически формируются. Она сообщает, что доступ утерян. Но она знает номер договора и все реквизиты. ОК, говорим мы: пришлите письмо на бланке организации с подписью генерального и печатью, восстановим вам доступ.

Письмо приходит, в нём просьба поменять основную почту доступа.

Мы соответственно меняем почту.

Потом нам пишет генеральный директор и сообщает, что бухгалтерша удалила его сервер 1С с базой. И слёзно просит нас его восстановить. Сотрудницу к этому моменту он уже уволил.

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

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

Как вам 2020 год? Для нас он оказался не только пятым, юбилейным для RUVDS, но и очень разным. В марте мы все резко перешли на удалёнку, перестали ездить в офис и, как многие, оценили насколько удобно и быстро было решать вопросы, просто повернувшись на стуле к коллеге.

Судя по статьям на Хабре, наш переход на удалёнку был похож на все остальные: странные фоны в зуме, частые созвоны, круглосуточный Slack. Единственное, что существенно отличало нас от других IT-компаний это была работа системных администраторов с ЦОДом, когда Москву полностью перекрыли и проезд был только по пропускам.

Но несмотря на все проблемы, год выдался неплохим. Онлайновым, диджитальным, высоконагруженным — действительно, год за три.


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

Админы менялись раз в неделю. Попасть на территорию можно было только по согласованным с руководством завода спискам, с обязательной проверкой температуры.

Наш главный администратор Костя показал себя настоящим героем – однажды у него выдались две недели, когда он работал без выходных 14 суток, потому что подменял ребят или просто давал им отдохнуть.

Было забавно наблюдать через зум, как поддержка постепенно начала обрастать бородой, рубашки постепенно сменились на толстовки и пижамы, а искусственные фоны из гор и океанов перестали включать и не стесняться даже немытой посуды на фоне. Как ни странно, это вынужденное расстояние сделало нас немного ближе.

Мы сумели сохранить некоторые офисные традиции, например, пицца-дей по пятницам — просто пицца теперь ехала не на Тверскую, а сразу по многим адресам по всей Москве и Подмосковью. В марте мы сделали внутренний сайт-шутку — калькулятор туалетной бумаги — сколько рулонов надо запасти на время, которое мы просидим на карантине (ну чтобы заказать потенциально дефицитный продукт сразу в достаточном количестве).

Поддержка: новый tone of voice и много человечности
Мы всегда уделяли особенное внимание поддержке: у нас она круглосуточная, ей можно не только писать, но и звонить. Среднее время ответа нашей поддержки — 15 минут, в авральные дни количество обращений может переваливать за 1000.

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

Этот год вывел на первый план человеческие отношения, вернул ценность общению, искренности. Наверное, неслучайно именно в 2020 мы сделали качественный скачок в том, как общаемся с клиентами.

Сравните:


Что мы сделали: заменили сложные бюрократические конструкции на понятный и простой русский язык, которым мы разговариваем между собой и с близкими. Отказались от страдательного залога, который создаёт ощущение разговора с корпоративной машиной, а не живым человеком. Каждый сотрудник теперь ведёт диалог от своего лица: я перезагружаю ваш сервер, я проверяю нагрузку. Ведь проблему решает конкретный человек и именно он сейчас заботится о клиенте.

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

Мы начали объяснять клиенту свои действия и почему надо подождать (если надо) — с полной информацией о происходящем людям проще переносить ожидание.

Изменились правила закрытия тикета — отныне тикет закрывается не когда решена техническая проблема, а когда у клиента больше не осталось вопросов.

Результаты не заставили себя ждать — теперь тикеты закрываются на сообщениях «Спасибо!» или «Теперь всё в порядке, спасибо вам» от клиентов, а не обрываются, как раньше, и нас это очень радует.

Подробно про то, как мы прокачивали общение поддержки — в посте на Хабре.

Инфраструктура года
Три новых дата-центра
С дата-центрами у нас случились три новости: во-первых, порог дата-центра бункера Rucloud впервые перешагнула женщина. Результатом стал фотоотчёт к статье Наш первый ЦОД в советском бомбоубежище: особенности вычислений в бункере и непередаваемый шок от того, что в дата-центре отсутствует женский туалет как класс.

Но, кроме этого, мы запустили три новых дата-центра.
Амстердам
Это центр обработки данных Interxion AMS9, расположенный в Амстердаме, в Science Park Data Center – ведущем центре межсетевых соединений города.

За что мы его любим?

• Удачное расположение: он соединён с крупными точками обмена интернет-трафиком, обеспечивает хорошую связь со странами как Нового, так и Старого Света и доступ к данным из любой точки мира с самой низкой задержкой – 99,99999%.
• Безопасность и конфиденциальность данных: у Interxion очень высокие внутренние стандарты безопасности. Несколько уровней физической безопасности и сертификацию Tier 3, биометрическая и двухфакторная аутентификация, доступ по магнитным картам. Камеры внутреннего и наружного наблюдения, многочисленные датчики движения, а картинка о происходящем в ЦОД круглосуточно транслируется на мониторы службы охраны. Сотрудники службы безопасности работают круглосуточно.

Останкино
Буквально на днях после упорной работы мы запустили новую локацию — дата-центр практически в самом сердце Москвы, Останкино.

ЦОД ТТЦ Останкино находится в Москве, по адресу 1-ая Останкинская ул., д. 1, стр. 1. Это ещё один дата-центр уровня TIER III в нашем парке. Старожилы говорят, что аптайм этого места 20 лет!

Почему мы его выбрали и за что любим:

• Обособленная территория в центре Москвы, куда мы сможем максимально быстро доставлять оборудование.
• Видеонаблюдение стоек без мёртвых зон и круглосуточная охрана на уровне стратегического объекта обеспечивает безопасность.
• Ремонты без отключения: резервные системы позволяют проводить плановые ремонтные работы и ТО, не затрагивая клиентов.
• Подведённая к объекту электрическая мощность – 11 МВА означает подключение мощных вычислительных кластеров и возможность расширить линейку тарифов и серверов.

Новосибирск
Это дата-центр «Калининский» по адресу г. Новосибирск, ул. Дуси-Ковальчук, 179/3.

Мы любим Новосибирский ДЦ за надёжную инфраструктуру:

• 2 городских ввода электропитания, каждый из которых зарезервирован собственным ИБП
• Система видеонаблюдения осуществляет круглосуточный контроль за всеми объектами ЦОД
• ДГУ Genelec с запасом топлива на 24 часа бесперебойной работы
• Техническая поддержка 24/7/365

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

Кое-что мы успешно запустили в этом году.

Локальная сеть
Локальные сети мы предоставляли и раньше, но только по запросу в Техническую Поддержку. Совсем давно всё делали вручную, не заморачиваясь с «технологиями»: все виртуальные машины, которые пользователь просил объединить в сеть, перетаскивались на один хост, на котором создавалась локалка. Спустя какое-то время мы отказались от перетаскивания, но, всё равно, вручную, за счёт VLAN-ов, объединяли виртуальные машины в локальные сети уже на разных хостах (но не цодах).

Это было долго и неудобно для клиентов, поэтому мы решили упростить и ускорить процесс, хотя услуга нужна далеко не каждому пользователю, и, в принципе, может быть заменена VPN'ами.

Но запросы продолжали приходить и мы хотели сделать всё удобнее. Мало того, можно понять тех клиентов, которым c VPN-ами и ZeroTier-ами разбираться не нравится и не хочется. Мы, кстати, заодно постарались немного упростить жизнь и тем, кому интересно использовать вышеупомянутые технологии. Для ZeroTier у нас есть образ в маркетплейсе, который существенно поможет в развёртывании и управлении, а также целый цикл статей (3 штуки, вот первая), который описывает эту технологию. Для VPN у нас также есть образ в маркетплейсе.

Некоторые хотят (например, из соображений безопасности) скрыть свою инфраструктуру за некоторым количеством «публичных» машин, ведь у нас с каждой проданной виртуалкой выдаётся белый адрес для доступа к ней. А кому-то нужен бродкаст и мультикаст, который недоступен иначе как в локальной сети.

В общем, нам хотелось исключить ручной труд по настройке сетей между виртуальными машинами, но при этом сделать так, чтобы настройка локальных сетей была доступна через Личный Кабинет всем пользователям; чтобы можно было максимально быстро соединять виртуальные машины в любых точках нашего присутствия (их целых десять, одиннадцатая «на носу») и чтобы получение услуги было проще, чем настройка любого VPN.

Теперь в Личном Кабинете на вкладке «Мои серверы» у каждого виртуального сервера появилась новая вкладка, на которой производится настройка сетей. На этой вкладке пользователь может создать локальную сеть (одну, но можно и две, если обратитесь в техническую поддержку) и добавить в неё виртуальные машины из своего Личного Кабинета. После развёртывания у выбранных виртуалок появляется дополнительный сетевой адаптер, которому будет назначен статический адрес. При необходимости адреса могут быть переназначены, из подсети выбранной при создании локалки, вручную или же можно настроить DHCP-сервер.

Снапшоты
Мы хотели добавить снапшоты по двум причинам: это удобно для клиентов и, как выяснилось, это существенный шаг в дальнейшем развитии нашего маркетплейса.

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

Именно в качестве решения для первой дополнительной задачи и появились снепшоты. Но с их помощью можно убить ещё нескольких зайцев. Теперь пользователь может сделать небольшой бекап не по расписанию, а конкретно тогда, когда это нужно. «Клонировать» виртуальную машину или перенести её в другой датацентр можно без обращения в Поддержку — всё делается через Личный Кабинет. Пока не без костылей, но начало положено.

Помимо нашего личного интереса в снапшотах, они сделали жизнь клиентов удобнее — появилась возможностью создать бекап «по клику». Выиграли в стоимости: хранение снапшотов гораздо дешевле! Но всё же необходимо понимать, что это совершенно разные услуги: снепшоты не предназначены для хранения больших объёмов данных, не призваны обеспечить высокую надёжность и не имеют возможности настроить их регулярное пересоздание.

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

Новая вкладка на странице «Мои серверы» у каждого виртуального сервера. На ней одна единственная кнопка: «Создать». Всё максимально просто.

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

Многие пишут нам в личку на Хабре. Есть клиенты, которые сидят в коллективных чатах с нашей командой — они сразу скидывают пожелания по UI/UX, репортят о каких-то мелочах, недочётах или высказывают пожелания по продуктовым изменениям.

Есть студенческие команды, которым мы выдаём бесплатные VPS для обучения технологиям — они помогают нам понимать не только тех клиентов, которые уже работают сейчас, а держать нос по ветру и понимать, чего захотят клиенты в будущие 3-4 года, какие технологии их интересуют и чего они хотят от сервиса будущего.

Поэтому превращение маркетплейса из лично нашей вотчины во что-то, что растёт и развивается само по потребностям рынка, было вполне логичным стратегическим шагом.

Так мы начали принимать образы от сторонних разработчиков и придумали систему защиты клиентов от бекдоров.

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

Спецпроекты года: Хабр, женщины, хакеры и пиво
Мы любим похулганить с пользой: в прошлом году была регата, запуск сервера в стратосферу, переписка с космосом и масса других безумных и крутых экспериментов. На 2020 год тоже было планов громадьё, но все они накрылись короной.

А раз отпал оффлайн, то кто, как не мы, должны были захватить онлайн? Сказано — сделано.

Спецпроект IT is Female на 8 марта
На 8 марта решили вывести на передний план наших коллег-женщин и сделали сайт с тепловой картой офисов, которые показывают компании, в которых работает больше девушек-айтишниц. На сайте проекта любая девушка могла загрузить свою фотографию, отметить кем она трудится в IT-индустрии и написать короткое пожелание остальным. Всего отметились почти 500 девушек.

От такой тепловой карты и на душе тепло.


Конкурс мемов с Хабром
В июле мы провели совместный с Хабром конкурс мемов. Авторы, попавшие в шорт-лист, получили ачивку в профиль, а мемы победителей пользовательского голосования стали основой для новой линии фирменного мерча в Хабр Киоске.

Под каждым вариантом принта был указан его автор и авторы получили экземпляр футболки с придуманным мемом и 500 рублей на внутренний счёт RUVDS, которые можно потратить на любые виртуальные серверы.

А вот и луч смеха в тёмном царстве 2020 года:


Про Хабр и конкурсы читайте там
habr.com/ru/company/ruvds/blog/534636/

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

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

Первая история — железо. Клиентов нереально бесит, когда полетел RAID-контроллер или вылетело сразу несколько дисков, и поддержка делает простой на замену. У нас был один клиент, которого сначала рикошетом зацепило DDoS по соседней VDS в том же серваке, потом через два часа начались плановые работы с сетевым адаптером, а потом ещё и рейд ушел в ребилд после включения-перезагрузки. К вопросу дидосов мы ещё вернёмся, кстати.

Так вот, можно взять дешёвое «околобытовое» железо и часто его чинить, а можно серверное — у нас Хуавей корпоративной линейки. Насколько я знаю, профессиональное серверное железо есть у нас и ещё у двух игроков на российском рынке. Поправьте меня, если ошибаюсь. Это потому что мы на старте считали, что проживём больше пяти лет и решили списывать старое железо минимум через пять лет после начала эксплуатации. Кстати, опять же, примерно так и появился тариф за 30 рублей за VDS, смекаете?

Дилемма с железом
Итак, у нас Хуавей корпоративного класса. Обычно у хостеров в России стоит самосбор, который покупается в оптовых магазинах с офисными и домашними десктопами по комплектующим, а затем с помощью разных дендральных методов собирается и работает. Влияет это на частоту поломок и стоимость услуг. Если с частотой поломок всё более-менее очевидно (чем хуже железо — тем выше шанс простоя), то вот со стоимостью услуг всё интереснее. При нашем цикле пять-шесть лет на железку получается дешевле покупать именно сервера и сетевые устройства корпоративных линеек для ЦОДов.

Да, они дороже в закупке. Да, у них очень дорогая гарантия (у нас на все новые устройства расширенная на next business day, плюс на не самые удачные серии расширенная далеко за пределы гарантии по времени). Да, нужно держать ремкомплект на площадке: мы меняем те же диски, RAID-контроллеры, планки оперативки и иногда блоки питания из собственных ЗИПов во всех десяти дата-центрах. Где-то ЗИП больше, где-то меньше, в зависимости от объективного количества и возраста серверов там.

Когда мы только начинали бизнес, то сразу решили брать железо понадёжнее. Потому что был случай проверить: до RUVDS мы занимались алготорговлей и использовали как раз самосборное дешёвое железо. И выяснилось, что разница действительно очень большая. Расходники покупаются просто центнерами. Естественно, если у хостинга такие затраты или более короткий цикл списания железа, то растёт цена на тарифы. А поскольку цены за более-менее одинаковые конфигурации более-менее фиксированы по всему рынку, деградирует что-то другое обычно. Как правило, не поддержка, а либо качество связи, либо ИБ.

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

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

Место ЦОДа
У большинства VDS-хостингов одна или две локации. У нас десять, причём есть не только в Москве, но и близкие к крупным российским городам (Екатеринбург, Новосибирск), что важно для серверов Майнкрафта и Контр-страйка, так и есть Швейцария, Англия и Германия. И при этом везде русскоязычная поддержка.

Зачем нужна вторая локация, понятно — сервисы надо геораспределять. А вот зачем нужны ЦОДы в других странах — это очень интересный вопрос.

Во-первых, ЦОД в Швейцарии считается более надёжным, чем российский. Это не объективная оценка, а мнение большей части наших клиентов. Надо сказать, что да, конечно, и там могут встретиться эпические раздолбаи, как и везде, но в целом у них гораздо более тщательно соблюдаются процедуры обслуживания и очень сильный внешний периметр безопасности. То есть проблемы у них случаться должны реже.

Во-вторых, конечно, за пределами России. Кому-то это важно, чтобы трейдить поближе к ключевым точкам, где обрабатываются заявки. Кому-то важно из-за собственных VPN (думаю, не меньше трети наших серверов куплены именно для организации VPN-тоннелей через другие юрисдикции). Ну и есть люди, которые застали маски-шоу в своих ЦОДах в России и теперь просто предпочитают хранить данные не у нас. Хотя, по идее, и там тоже никто от такого не застрахован. Просто умолчания по наезду на дата-центр другие.

Сразу скажу, что некоторые наши коммерческие ЦОДы не хуже того, что в Великобритании или Швейцарии. Например, в Петербурге площадка почти без косяков (и точно без серьёзных) и соблюдает стандарты Uptime Institute (T3). Охраняется хорошо. То есть объективно она очень хорошая, но среди клиентов как-то сложилось убеждение, что за границей безопаснее. И те русские хостеры, кто не даёт зарубежную локацию, сразу немного не вписываются в потребности рынка.

Изменение конфигурации сервера и тарификация
Мы делали опросы и изучали, что важно клиентам. Оказалось, очень высокое место занимают такие параметры, как единица квантования в тарифе и возможность быстро менять конфигурацию сервера. Мы знаем, что где-то виртуалка создаётся вручную за один-два часа по заявке, конфигурация меняется за сутки по заявке в поддержку.

Мы автоматизировали процессы до тех пор, пока медиана на создание виртуалки не стала равняться четырём минутам, а средний интервал от заявки до запуска 10-11 минутам. Это потому что некоторые сложные заявки всё ещё делаются руками за примерно 20 минут.

Тарификация у нас посекундная (а не часовая или суточная). Можно создать сервер, посмотреть на него и тут же удалить, сохранив свои деньги (мы просим предоплату за месяц, но возвращаем её, если не зашло). У большинства российских площадок нужно отдельно арендовать лицензию на ОС. У нас WinServer поставляется на все машины бесплатно и входит в тариф (но десктопный вариант Windows невозможен).

Конфигурация сервера меняется за примерно десять минут из интерфейса, причём как вниз, так и вверх. Два исключения — вниз по диску не всегда можно автоматически (если место чем-то занято), и при переносе с 2,2 ГГц на 3,5 ГГц делается через тикет. Ручные заявки имеют SLA на первый ответ 15 минут, время обработки 20-30 минут (могут и больше, в зависимости от объёма копируемых данных). В тарифах, кстати, где у нас HDD, везде по факту SSD с ограничениями до скоростей HDD (так оказалось дешевле, и полностью на SSD мы перешли примерно полтора года назад). Можно взять машину с видеокартой. Есть тариф по утилизации (там сложная формула от процессора, оперативки, дисков и трафика) — если у вас пиковые вычисления, так дешевле, но бывают и клиенты, которые не до конца правильно предсказывают свой расход и платят в два раза больше обычного тарифа иногда. Ну а кто-то экономит.

Да, это всё требует затрат на автоматизацию. Но как показывает практика, это же позволяет здорово экономить на поддержке и сохранять клиентов за счёт качества сервиса.

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

Маркетплейсы
За океаном наметилась тенденция предоставлять не только VDS, но и сразу набор предустановленного ПО. В том или ином виде маркетплейс есть у всех крупных хостингов и часто отсутствует у мелких. У нас провайдеры всё ещё часто продают пустые машины, как и в Европе.

Первым кандидатом на маркетплейс после WinServer стал Докер. У нас технические специалисты сразу сказали, что маркетплейс не нужен, потому что админы не настолько безрукие. Поставить Докер — это пара минут, и не надо вот считать их такими ленивыми, что они это не сделают. Но мы развернули маркетплейс и положили туда Докер. И они стали пользоваться, потому что лень. Время же экономит! Мало, но экономит. Это не жизненная необходимость для клиентов, конечно, но уже следующий стандарт рынка.

С другой стороны, у нас нет того же Кубера. Зато недавно появился сервер Майнкрафта. Он пока востребованнее. Есть интересные направления по VPS с предустановленным ПО: есть конфигурация с урезанной Win (чтобы она не жрала производительность), есть с уже предустановленной OTRS. Мы даём предустановленное ПО, а как уж вы его будете активировать — ваше дело, этого мы не видим.

Самые крутые в мире маркетплейсы, как мне кажется, у Amazon, Digital Ocean и Vultr. Стартапы хотят приходить на маркетплейс Амазона: если ты сделал какую-то тулзу типа Эластиксёрча, но не попал в маркетплейс — никто и не узнает, никто не купит. А если попал — вот и канал распространения появился.

DDoS
Атакуют каждый хостинг. Обычно это слабые ненаправленные атаки, которые похожи на естественную микрофлору Интернета. Но вот когда начинают класть какого-то конкретного клиента, начинаются проблемы у соседних с ним на одной «ветке». Как правило, это те, кто обслуживается с того же сетевого устройства.

Больше 99 % клиентов проблем не испытывают, но некоторым не везёт. Это частая причина, почему клиенты нас не любят — из-за простоев сервера по DDoS на соседа. Мы очень давно постарались минимизировать эти истории, но, конечно, не смогли избежать их полностью. Мы не можем всем подряд включать DDoS-защиту в стоимость тарифа, тогда услуги подорожают на нижних линейках примерно в два раза. Когда поддержка рекомендует клиенту под DDoS взять защиту (платную, конечно), клиент, бывает, считает, что мы его специально кладём, чтобы продать что-то. И, главное, никак не объяснить, а соседи страдают. В итоге нам пришлось залезть поглубже в начинку сетевых адаптеров и написать им собственные драйвера. Именно драйвера к железу, да, вы не ослышались. Второй контур — есть двойная система защиты, которая может переключить маршруты за минуты. Если попасть в противофазу проверок, то можно получить простой максимум четыре минуты. Сейчас переключение всё ещё создаёт некоторые проблемы в виртуальных свитчах и коммутаторах, мы доделываем стек.

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

У нас клиенты, кстати, выбирают локации в своих городах, как у нас шутит поддержка, чтобы ещё и морду при случае набить. Реально несколько человек заходили по дороге домой в офис.

И вот здесь-то пора начать рассказывать про наши эпические косяки.

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

Потом вышеупомянутые DDoS. В декабре 2018-го и в декабре 2019-го. Потом в январе и марте 2020-го. В последнем случае несколько серверов перестали отвечать (физические машины забили намертво, а виртуалки были на них) — понадобился хардовый ребут, чтобы сетевые адаптеры ожили. Развёртывание обратно — не самая весёлая процедура, и пара человек получила простой в часы, а не минуты. Атаки случаются каждый день, и в 99,99 % все контуры отрабатывают штатно, и никто этого не замечает, но бывают случаи когда что-то идёт не так.

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

Ещё важный момент: DDoS всегда локален. Никогда не было, чтобы проблемы в одном ЦОДе развивались одновременно с проблемами в другом. Ну и пока что худшее, что случалось локально — это перезагрузка коммутатора с несколькими машинами.

Чтобы окончательно успокоить наших клиентов по взломам, мы застраховали ответственность в AIG. Если нас ломанут, а клиенты пострадают — страховщики должны возместить. Это оказалось не очень дорого в расчёте на единичный тариф, но как-то придаёт уверенности.

Поддержка. Мы старались сделать дешёвый хостинг с разными фичами на выбор и достаточной надёжностью. Это значит, что наша поддержка не делает две вещи: не разговаривает с клиентом длинными вежливыми фразами и не лезет в прикладное ПО. Второе нам аукнулось в прошлом году, когда пришли многочисленные инстаграм-дивы, которые покупали VDS для установки накрутчиков лайков и автоматизаторы постов. Впечатляет, насколько некоторые люди, предельно далёкие от ИТ, способы грамотно разобраться в установке софта на виртуалку. Нет такой инструкции, которую фитоняша не осилит за 30 % увеличения подписчиков. Но ломались они на настройке исходящего трафика внутри своего софта почему-то. Возможно, инструкции этого не предусматривали. Мы не можем отвечать за работу стороннего софта. А проблемы там не только в том, что пользователь не понимает, как его сконфигурировать, но и в стабильности. Например, поставил вот человек вспомогательное ПО для накрутки просмотров на Ютубе. А оно поставляется с какого-то форума в комплекте с трояном. И в трояне баг, у него течёт память. А мы не чиним баги в троянах. Если мы ставим софт — то это продукт из коробки.

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

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

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

Как оказалось, такое описание тарифа мало кого остановило. 30 рублей — это всё равно дешевле, чем ipv4-адрес, а тут ещё виртуалка с ним сразу. Как мне кажется, многие покупали просто чтобы купить, потому что мы открываем его волнами. Первый раз всё прошло более-менее нормально, но мы тогда не придали должного внимания тому, что через три-четыре месяца утилизация стала постепенно расти — проекты там разворачивались не сразу, и нагрузка к концу года стала менее комфортной для среднего клиента, появились большие очереди на запись на диск, например. Да, там SSD, но мы его ограничиваем на тарифе до скоростей HDD, и это не NVMe, а специально закупленные на опыты дешёвые интеловские диски для серверных конфигураций. Мы поменяли диски на побольше и понормальнее, это позволило получить хоть какие-то производительности.

Второе открытие этого тарифа привело нам тысячи китайских пользователей. Они написали скрипты, которые палят наш сайт, потому что около 800 машин были выкуплены братским народом в окне между появлением новости на сайте и рассылкой, а это буквально несколько минут. Я не могу точно сказать, что они там делали, но судя по характеру трафика, это были диссиденты, которые обходили Великий Китайский Файрвол. Мы запретили по условиям акции покупать машину иначе как гражданам РФ. Чтобы защитить Кваймён, нам пришлось приостановить создание виртуалок. Сначала российские пользователи сказали нам спасибо, потом поддержка — часть пользователей «в процессе» надо было доделать руками. Ну и возник негатив, потому что много кто ждал, а когда получил письмо, тариф уже кончился.

Сейчас у нас несколько тысяч активных клиентов на 30-рублёвом тарифе. Если у админа руки прямые — он делает самый дешёвый в мире VPN. Кто-то стучал в поддержку со скринами Linux с каким-то GUI (не помню, что там было, но сам факт GUI на таких машинах с ограничением по оперативной памяти — это уже круто), кто-то ставил ISP-панель и так далее. Кто-то действительно использовал для обучения. Мы ещё раз сделаем эту акцию, учтя ошибки, но просто знайте, что где-то там, в Поднебесной, стоит маааленький форум на примерно миллион зарегистрированных участников, которые подписаны на тред про наши сервера.

Главный урок этой истории в том, что машины сначала работали быстрее, чем ожидалось, и у людей сформировались неверные ожидания по поводу производительности. Когда она стала падать до обещанного уровня, начались жалобы в поддержку, и её засыпало негативом. Сейчас, конечно, мы будем точнее объяснять, что ждёт на таком тарифе. Ещё раз нас простите, если вас задело этой историей.

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

По старой традиции мы подводим итоги года и рассказываем, что сделали для Вас в 2019 году, возможно Вы что-то пропустили.

• Весь 2019 год мы занимались улучшением нашего сервиса. Для Вашего удобства, мы запустили сразу 5 новых гермозон в России и в мире: в Санкт-Петербурге, Казани, Франкфурте, Екатеринбурге, и буквально на днях открывается новая гермозона в Новосибирске. Теперь у RUVDS 9 площадок в мире: cобственный дата-центр уровня TIER III в г. Королеве, Московская область, а также гермозоны в дата-центрах в Цюрихе Interxion ZUR1 (Швейцария), Лондоне Equinix LD8 (Великобритания), Москве ММТС-9 (Россия), Санкт-Петербурге Linxdatacenter (Россия), Казани IT Park (Россия), Екатеринбурге «Дата Центр Екатеринбург» (Россия), Франкфурте Telehouse (Германия) и в Новосибирске ДЦ “Калининский” (Россия). Все дата-центры являются высоконадежными площадками и соответствуют уровню надежности не ниже TIER III.
• В 2019 году мы кардинальным образом изменили работу технической поддержки. Помимо новой, полностью кастомизированной тикет-системы, мы значительно увеличили штат всех уровней поддержки, отказались от аутсорсинга первой линии и перешли на честные 24/7. Всё это уменьшило время обработки и ответа на Ваши входящие сообщения в разы.
• Для виртуальных серверов на ОС Linux стали доступны образы с предустановленной панелью управления Plesk и cPanel, до 31 января 2020 года панель Plesk будет бесплатной для всех новых серверов.
• В дата-центре RUCLOUD теперь Вы можете подключить видеокарту к виртуальному серверу (доступно только для “Мощного” процессора).
• В личном кабинете рядом с IP адресом сервера появилась кнопка “Настроить файрвол”. С ее помощью можно изменить правила фильтрации к входящему сетевому трафику до попадания на Ваш сервер, а к исходящему трафику после выхода с Вашего сервера.
• Чтобы Вы могли мониторить и управлять Вашими серверами с любимых мобильных устройств, мы подготовили мобильные приложения под ОС Android и IOS.

Все это помогло сделать наш сервис лучше и надежнее, наши заслуги также признали и в CNews Analytics. В новом рейтинге крупнейших поставщиков IaaS в России, RUVDS занял 16 место, поднявшись на 3 пункта с прошлого года.

А 2019 год запомнится нам интересными мероприятиями. В феврале мы провели закрытую презентацию Cloudrussia Interactive Course совместно с партнёрами из Huawei. На день Космонавтики запустили сервер в стратосферу, он поднялся на высоту 27 км и во время полёта раздавал интернет, снимал и передавал видео и данные телеметрии на землю. Мы познакомились с легендарными гейм дизайнерами и разработчиками компьютерных игр с Ричардом Levelordом (дизайнер Duke Nukem), Рэнди Питчфордом (SEO GearBox), Джоном Ромеро (разработчик и дизайнер Doom), которые рассказали клиентам RUVDS о том, как были созданы самые известные компьютерные хиты 90-х.

Благодарим Вас за то, что выбрали RUVDS и надеемся на продолжение сотрудничества в Новом 2020 году. Желаем Вам успехов в реализации намеченных планов.
Ваш поставщик IT-услуг, коллектив компании RUVDS.

ruvds.com/

В этой статье мы расскажем про новую версию панели, релиз которой состоялся на днях — Plesk Obsidian, лицензию на нее можно получить бесплатно при заказе VPS на нашем сайте.
pleskobsidian.com/
ruvds.com/vps_start/



Plesk продолжает развиваться от базовой функциональной веб-консоли к мощной платформе управления, проверенной на серверах, сайтах, приложениях, хостинге и облачных бизнесах. Plesk Obsidian позволяет веб-специалистам, реселлерам и поставщикам услуг интеллектуально управлять, защищать и запускать серверы, приложения, веб-сайты и хостинг-компании любого размера на профессиональном уровне.

В Plesk считают, что сейчас происходит быстрое изменение отрасли:

«Цифровое преобразование — больше не просто отличительный признак, это бизнес-императив. Мы хотим не только отслеживать, понимать и предвидеть это изменение, но и влиять на него. Цифровизация процессов и задач меняет способ управления серверами, приложениями и веб-сайтами в облаке… Общий хостинг уже является товаром, а голая инфраструктура недостаточно хороша, чтобы позволить вашим клиентам продвигаться вверх по современному веб-стеку. Постоянно растущее число клиентов готово платить за дополнительные услуги, такие как управляемый WordPress, управляемое резервное копирование, повышенная безопасность, повышенная скорость и производительность веб-сайтов и хостинг приложений и многое другое. Проще говоря, сегодня самой большой проблемой для компаний любого размера является понимание потенциала цифровых технологий, какие области их бизнеса могут извлечь выгоду из цифровой трансформации и насколько легко их можно внедрить и управлять ими. Спецификации чистой инфраструктуры больше не приоритетны… Поэтому теперь новая панель Plesk Obsidian использует технологии искусственного интеллекта, машинного обучения и автоматизации для расширения возможностей [администраторов и владельцев сайтов] и оказания помощи хостинговым предприятиям по всему миру для эффективного управления цифровыми преобразованиями»

И, собственно, о новом в панели Plesk Obsidian в рамках цифровой трансформации (документация здесь).
docs.plesk.com/en-US/obsidian/

Новые ключевые функции Plesk Obsidian
Современный веб-стек для быстрой разработки приложений и сайтов
С Plesk Obsidian — это оптимизированный веб-стек «из коробки» и ready-to-code инновационная платформа со всеми возможностями развертывания и удобными инструментами для разработчиков (Git, Redis, Memcached, Node.js и др).


PHP Composer — менеджер зависимостей для PHP
Одна из многих проблем, с которыми сталкиваются веб-разработчики, связана с зависимостями. Интеграция новых пакетов в проект часто доставляет больше хлопот, чем преимуществ. Это особенно верно для разработчиков PHP. Довольно часто программисты строят модули с нуля, а достижение постоянства данных между веб-страницами — это боль, которая тем больше, чем больше переменных. В результате хорошие разработчики тратят кучу времени и ресурсов на избыточные задачи, а при этом хотят быть продуктивными и быстро выпускать новый код. Вот зачем в Plesk Obsidian есть Composer — изящный и простой менеджер зависимостей для PHP, который позволяет легко управлять зависимостями PHP-проекта (расширение устанавливается вручную).

Docker NextGen — функция удобного предоставления услуг в Docker
Запуск приложений в контейнерах вместо виртуальных машин набирает обороты в мире ИТ. Технология считается одной из самых быстрорастущих в новейшей истории индустрии программного обеспечения. В основе лежит Docker — платформа, которая позволяет пользователям легко упаковывать, распространять и управлять приложениями в контейнерах. С функцией Docker NextGen стало проще использовать решения на основе Docker «под ключ» (Redis, Memcached, MongoDB, Varnish и т. д.), а не раскрывать саму технологию Docker, что удобно. Вспомогательные службы для веб-сайтов разворачиваются в один клик. Plesk настраивает службы, а затем легко автоматически интегрирует их с вашим веб-сайтом. (Скоро появится).

MongoDB — гибкая, универсальная и простая в использовании база данных
И наиболее востребованная, согласно Stack Overflow Developer Survey 2018, крупнейшему в мире опросу разработчиков с более чем 100 000 респондентов. Plesk Obsidian настраивает службу MongoDB. Управлять экземплярами MongoDB, как и любой другой базой данных, можно локально или удалённо. И беспрепятственно интегрировать их в рабочий процесс разработки.

Режим ограниченного доступа
Ограничение операций на стороне сервера обеспечивает большую степень контроля администраторам над тем, какие операции могут и не могут выполнять пользователи Plesk. Новый режим ограниченного доступа может применяться как к администратору панели (поставщиком услуг), так и к администраторам сайтов (администратором панели).

Подробности в документации
docs.plesk.com/en-US/obsidian/administrator-guide/about-plesk/customizing-power-user-view.70035/

Когда режим ограниченного доступа включен, вы можете:

• видеть, какие службы и ресурсы доступны администратору в режиме «Опытный пользователь»
• предоставлять администраторам права клиентов к Plesk, контролируя их доступ к потенциально рискованным операциям: управление обновлениями, перезагрузка, завершение работы и др.
• Узнавать, какие инструменты и параметры доступны администратору в режимах «Опытный пользователь» и «Поставщик услуг» для администрирования сервера и администрирования веб-хостинга (во вкладках «Инструменты администрирования» и «Инструменты хостинга» соответственно)

Более безопасные, полезные и надёжные инструменты для разработчиков
Несколько улучшений в службах PHP-FPM и Apache. Перезапуск Apache теперь достаточно надёжен для установки его по умолчанию, чтобы минимизировать время простоя сайтов.
Уменьшено дисковое пространство, необходимое для восстановления отдельных объектов из резервных копий, хранящихся в удалённом хранилище.
Движки PHP, поставляемые с Plesk Obsidian, содержат популярные расширения PHP (odium, exif, fileinfo и др).
Модуль PageSpeed теперь предварительно скомпилирован с NGINX.

Комплексная безопасность Plesk Security Core
Активированная по умолчанию первоклассная защита server-to-site от наиболее распространённых атак на веб-сайты и от злонамеренных пользователей.


Хороший хостинг по умолчанию

• Mod_security (WAF) и fail2ban активны из коробки.
• По умолчанию systemd теперь автоматически перезапускает сбойные службы Plesk через 5 секунд.
• На вновь созданных веб-сайтах по умолчанию включено перенаправление HTTP>HTTPS, оптимизированное для SEO.
• В Linux на системной основе (CentOS 7, RHEL 7, Ubuntu 16.04 / 18.04 и Debian 8/9) аварийные службы Plesk теперь перезапускаются автоматически.
• Ограничение PHP-FPM, часто называемое max_children — это настройка максимального количества параллельных PHP-FPM процессов, запускаемых на сервере (раньше было 5).
• SPF, DKIM и DMARC теперь включены по умолчанию для входящих и исходящих писем электронной почты.

Улучшения в почте

• Пользователи почты теперь получают уведомления по электронной почте, когда больше чем 95% из их дискового пространства почтового ящика занято. Подробнее.
• Пользователи почты также могут просматривать информацию о дисковом пространстве почтового ящика, его использовании и ограничениях в клиентах веб-почты Horde и Roundcube.
• Почтовый сервер Plesk и веб-почта теперь по умолчанию доступны через HTTPS: они защищены стандартным сертификатом SSL / TLS, который защищает сам Plesk. Подробнее.
• Администратор Plesk теперь может изменять пароли клиентов, посредников и дополнительных пользователей, автоматически отправляя им электронное письмо со ссылкой для сброса пароля. Почтовые пользователи и дополнительные пользователи теперь могут указывать внешний адрес электронной почты, который будет использоваться для сброса пароля в случае утери ими доступа к основному адресу электронной почты. Подробнее.
• По умолчанию включено автообнаружение почты в panel.ini, чтобы Plesk мог легко поддерживать самые популярные почтовые, настольные и мобильные почтовые клиенты. Эта новая функция позволяет автоматически настраивать почту для почтовых клиентов Exchange Outlook и Thunderbird. Подробнее.

Оптимизация резервного копирования

• Значительно уменьшено свободное дисковое пространство на сервере, необходимое для создания и восстановления резервных копий в облачном хранилище (Google Drive, Amazon S3, FTP, Microsoft One Drive и т. Д.). Это экономит и затраты на хранение.
• Время операций с резервными копиями, хранящимися удаленно, сокращено. Например, резервные копии, хранящиеся в облачном хранилище, теперь могут быть удалены в четыре раза быстрее, чем раньше.
• Чтобы восстановить одну подписку из полной резервной копии сервера, теперь вам нужно только дополнительное свободное дисковое пространство, равное пространству, занимаемому этой конкретной подпиской, а не полной резервной копии сервера.
• Для бэкапа сервера в облачное хранилище теперь требуется дополнительное свободное дисковое пространство, равное пространству, занимаемому двумя подписками, а не всем сервером.
• Plesk Obsidian поставляется с Repair Kit — мощным средством диагностики и самовосстановления, позволяющим вашим клиентам устранять потенциальные проблемы в любое время, где бы они ни находились и даже когда Plesk недоступен. Устраняет проблемы с: почтовым сервером, веб-сервером, DNS-сервером, FTP-сервером, базой данных Plesk Microsoft SQL Server или самой файловой системой Plesk — MySQL.

Подробнее в документации
docs.plesk.com/en-US/obsidian/administrator-guide/backing-up-and-restoration/configuring-remote-storage.59259/

Пользовательский опыт, UX


Упрощенное управление сервером и веб-сайтом
Plesk Obsidian предстаёт в совершенно новом, модернизированном пользовательском интерфейсе, который делает управление сервером ещё более простым. Теперь ваши клиенты могут комфортно работать со всеми веб-сайтами на одном экране: детально их просматривать, выбирать массовое управление или работать с ними по одному в виде списка или группы, используя соответствующие функции и элементы управления выбранной CMS.

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

Перемещение доменов между подписками
Раньше это была сложная ручная задача, требующая расширенного набора навыков администратора сервера. Plesk Obsidian позволяет легко перемещать домен в другую подписку с его содержимым, файлами конфигурации, файлами журналов, настройками PHP, приложениями APS, а также поддоменами и псевдонимами доменов (если есть). Можно делать это и через командную строку.

Подробнее в документации
docs.plesk.com/en-US/obsidian/administrator-guide/website-management/websites-and-domains/domains-and-dns/adding-and-removing-domains.65150/#moving-domains

Панель уведомлений
Важные уведомления в приятном для глаз формате HTML теперь отображаются непосредственно в пользовательском интерфейсе Plesk. Функция позволяет убедиться, что критические проблемы стали известны и принять меры для их решения, не теряя драгоценного времени и денег клиентов. Уведомления в панели (в будущем планируются и мобильные) пока что генерируют такие события, как: «отслеживаемый параметр достиг уровня «КРАСНЫЙ»»; «Обновление Plesk доступно / было установлено / не удалось установить»; «Набор правил ModSecurity установлен». Подробнее.

Улучшенный файловый менеджер
В File Manager теперь есть массовая загрузка и поиск файлов, что позволяет быть более продуктивным. Про предыдущую версию читайте в документации.

Что ещё нового:

• Загрузка и извлечение архивов RAR, TAR, TAR.GZ и TGZ.
• Поиск файлов по имени файла (или даже по части имени) или содержимого.

Скоро будет:

• Быстрый просмотр изображений и текстовых файлов без открытия новых экранов диспетчера файлов через панель предварительного просмотра.
• Файловый менеджер сохранит запросы и предложит их автоматически заполнять при вводе.
• Случайно удалили не тот файл или каталог через File Manager? Восстановите его через пользовательский интерфейс File Manager, даже если у вас нет резервной копии.
• Если вы нарушаете работу своего веб-сайта, изменяя права доступа к файлам или структуру каталогов файлов, исправьте это с помощью функции восстановления Plesk через пользовательский интерфейс диспетчера файлов.

Другие улучшения панели
Расширения и приложения
Каталог расширений теперь интегрирован в Plesk Obsidian. Это технология необходима для быстрого и гибкого решения проблем клиентов. Позволяет добавлять дополнительные продукты и услуги в собственную витрину магазина для клиентов без особых усилий. Подробнее.


Расширенный мониторинг
Заменяет существующий инструмент HealthMonitoring новым Grafana extension. Позволяет отслеживать доступность сервера и веб-сайта и настраивать оповещения, уведомляющие их владельцев о проблемах, связанных с потреблением ресурсов (ЦП, ОЗУ, дисковый ввод-вывод) по электронной почте или в мобильном приложении Plesk. Подробнее.


Управляемые службы
Услуги управляемого хостинга могут варьироваться от простого обновления ОС и установки панели в один клик только для WordPress до полностью управляемой инфраструктуры, включающей в себя ОС, приложения, безопасность, поддержку 24x7x365 (даже на уровне приложений WordPress), подходящую резервную копию и стратегию восстановления, инструменты мониторинга производительности, оптимизацию WordPress, улучшения SEO и многое другое.

К слову, WordPress по-прежнему является системой управления контентом, занимающей 60% мирового рынка CMS. Сегодня на WordPress создано около 75 миллионов веб-сайтов. Жизненный источник любого управляемого хостинга WordPress в Plesk остается WordPress Toolkit. Он был создан совместно с экспертами WordPress для пользователей всех уровней квалификации. Plesk тесно сотрудничает с сообществом WordPress, и мы постоянно обновляем WordPress Toolkit, ориентируясь на отзывы членов сообщества. WordPress Toolkit в сочетании со Smart Updates в настоящее время является единственным комплексным решением для управления WordPress, доступным на рынке, и позволяет вам снова внедрять инновации и мгновенно конкурировать с ведущими игроками на специализированном рынке хостинга WordPress.

Заключение
С начала 2000-х Plesk упростила жизнь веб-профессионалов, малых и средних предприятий и продолжает приносить пользу многим облачным сервисам. Находясь в штаб-квартире в Швейцарии, Plesk работает на 400 тыс. серверов по всему миру, обеспечивая работу более 11 миллионов веб-сайтов и 19 миллионов почтовых ящиков. Plesk Obsidian доступна на 32 языках, и многие ведущие поставщики облачных и хостинговых услуг сотрудничают с Plesk — в том числе и мы. До конца года все новые клиенты RUVDS при покупке виртуального сервера могут получить панель Plesk Obsidian бесплатно! ruvds.com/vps_start/

RUVDS при поддержке своего давнего партнера компании Huawei ввел новое мощное оборудование в эксплуатациюв двух гермозонах в Казани и Екатеринбурге.

В 2019 году хостинг-провайдер RUVDS открыл для своих клиентов 5 новых гермозон в дата-центрах по всему миру. На сегодня провайдер предоставляет своим клиентам виртуальные серверы на 8 площадках — две в Москве, по одной в Лондоне, Цюрихе, Санкт-Петербурге, Казани, Франкфурте, Екатеринбурге. Все дата-центры являются высоконадежными площадками и соответствуют уровню надежности не ниже TIER III.

В июле этого года в дата-центрах Казани и Екатеринбурга было поставлено новое оборудование. Теперь клиентам облачного провайдера во всех представленных дата-центрах доступны мощные VPS с частотой 3,4 ГГц с SSD дисками по прежним низким ценам.
«Дата-центр Екатеринбург» располагается на территории завода «Радиоаппаратуры». ЦОД оснащен всеми необходимыми инженерными системами для обеспечения постоянного функционирования оборудования, безопасности обработки и хранения информации. Общая площадь серверных 160 м2.
Дата-центр в Казанском IT Парке обладает сертификатом качества TIER III от Uptime Institute (Uptime Institute Management & Operations). ЦОД полностью соответствуют международным требованиям по операционной устойчивости дата-центров и имеет SLA 99.982%.

Справка
RUVDS российский хостинг-провайдер VDS серверов, специализирующийся на оказании услуг IAAS корпоративного класса. Партнерами компании являются АО «ФИНАМ», финансовая группа «БКС», Национальный расчетный депозитарий (Московская биржа), АО «ВЦИОМ», компания «Гарс-Телеком», оператор такси Gett, оператор доставки Delivery Club и многие другие.
Компания RUVDS обладает собственным дата-центром уровня TIER III в г. Королеве, Московская область, а также гермозонами в дата-центрах в Цюрихе Interxion ZUR1 (Швейцария), Лондоне Equinix LD8 (Великобритания), Москве ММТС-9 (Россия), Санкт-Петербурге Linxdatacenter (Россия), Казани IT Park (Россия), Екатеринбурге «Дата Центр Екатеринбург» (Россия) и Франкфурте Telehouse (Германия).

ruvds.com/ru-rub