Рейтинг
0.00

RUvds Хостинг

1 читатель, 41 топик

Выручка RUVDS по первому кварталу выросла на более чем 30%



Выручка хостинг-провайдера VPS-серверов RUVDS в первом квартале выросла на 31% по сравнению с аналогичным периодом прошлого года. За это время у компании появилось почти 3,5 тыс. новых клиентов, заказавших виртуальные серверы как на российских, так и на зарубежных площадках.

Индустрия продолжает меняться, адаптируясь к новым реалиям, и мы можем сказать, что ставка RUVDS на географический фактор продолжает себя оправдывать. Если пару лет назад особым спросом пользовались наши зарубежные площадки, то сегодня мы отслеживаем другой тренд: две трети новых клиентов выбрали площадки, расположенные внутри страны. За последние два года нам удалось нарастить число серверов в полтора раза, и цифры, которые мы видим сегодня, обеспечены в том числе и этими мерами
отметил генеральный директор хостинг-провайдера VPS-серверов RUVDS Никита Цаплин.

При этом более половины виртуальных серверов, созданных на иностранных площадках компании в первом квартале, пришлись на мощности RUVDS в Казахстане и Турции. В то же время спрос на вычислительные мощности, размещенные в западной Европе, не претерпел заметных изменений.

Мы запускаем новую акцию, приуроченную к наступлению лета

Клиентов компании ждут традиционная скидка 30% и яркие летние подарки.



Каĸ получить сĸидĸу
Акция будет действовать с 1 до 30 июня. Для получения скидки 30% нужно пополнить баланс и продлить серверы на год в личном кабинете, либо заказать новый сервер. В последнем случае скидка рассчитается автоматически.
ruvds.com/ru-rub/my/servers
ruvds.com/ru-rub

Суперприз – iPad Pro 13
Для того, чтобы принять участие в розыгрыше суперприза, достаточно пополнить баланс в течение июня на более чем 10 000 рублей. Победитель, имя которого станет известно 1 июля в нашей группе RUVDS в Telegram, будет выбран с помощью генератора случайных чисел.
t.me/ruvds_community

Также каждую неделю RUVDS будет разыгрывать призы поменьше — для трёх клиентов, которые оплатили услуги за год на прошедшей неделе.
1. Увлажнитель воздуха
Приз за первое место – увлажнитель воздуха Xiaomi Smart Humidifier 2. Он не просто поможет поддерживать комфортный уровень влажности в помещении, но и окажет положительное влияние на здоровье и сон.
2. Будильниĸ с имитацией рассвета и заĸата
Обладатель второго места получит будильник с имитацией рассвета и заката YouSENS Wake-up. Этот стильный аксессуар сделает пробуждения максимально естественными, настраивая на нужный лад с самого утра.
3. Фитнес-браслет
Призом за третье место станет многофункциональный умный браслет Xiaomi Smart Band 8. Браслет предлагает большой и яркий дисплей, удобство использования и компактные размеры – всё, необходимое для активного летнего досуга и отдыха.

Генеральный директор RUVDS признан человеком года на премии «ЦОДы.РФ»



Генеральный директор хостинг-провайдера RUVDS Никита Цаплин признан человеком года по версии национальной премии «ЦОДы.РФ». Торжественная церемония вручения награды состоялась в Москве 18 апреля.

«Хотел бы поблагодарить всех за невероятную поддержку и доверие. Такие премии – это показатель того, что мы движемся в верном направлении. Путь, который мы проделываем на пути к победе, это вклад в развитие всей индустрии», – подчеркнул в своей речи Никита Цаплин.

В 2023 году хостинг-провайдер VPS-серверов RUVDS вышел на новый этап своего развития: компания реализовала сразу несколько уникальных проектов и значительно повысила свои ключевые показатели. В частности, был реализован уникальный проект по выводу на орбиту первого в истории спутника-сервера и проведен первый в мире CTF с использованием искусственного космического аппарата, компания вышла на рынок Турции и на треть увеличила клиентскую базу сервиса RUVDS.

За прошлый год Никита Цаплин подготовил и опубликовал 13 авторских колонок, дал более 50 экспертных комментариев, что в сумме дало более 1000 упоминаний в ведущих федеральных СМИ. Также гендиректор RUVDS выступил в качестве приглашенного эксперта от бизнеса в Минцифры России.

ruvds.com

Увеличили выручку по первому кварталу почти на треть



Пришло время промежуточных отчётов, и нам есть чем поделиться: выручка RUVDS в I квартале 2024-го выросла на 31% по сравнению с аналогичным периодом прошлого года.

За это время у компании появилось почти 3,5 тыс. новых клиентов, которые заказали виртуальные серверы на наших российских и зарубежных площадках. Примечательно, что пару лет назад особым спросом пользовались зарубежные площадки RUVDS, а сегодня мы фиксируем обратное: 2/3 новых клиентов выбрали площадки, расположенные внутри России. При этом более половины виртуальных серверов, созданных на таких иностранных мощностях компании в первом квартале, пришлись на наши площадки в Казахстане и Турции.

Напоминаем, что RUVDS постоянно работает над улучшением условий для наших клиентов, например, заморозив цены на ispmanager до конца 2024-го. А ознакомиться с ключевыми событиями из жизни нашей компании в этом году можно с помощью подборки:
  • Генеральный директор RUVDS признан человеком года на премии «ЦОДы.РФ»
  • Космонавт Александр Лазуткин стал новым лицом нашего бренда
  • Угадай местоположение льдины с арктическим ЦОДом и получи приз от RUVDS
  • RUVDS запускает дата-центр в полярном лагере на дрейфующей льдине
  • Админы на северный полюс доставлены
  • Дарим до трёх месяцев бесплатного пользования ispmanager

ruvds.com/ru-rub

Мы нарастили число серверов в полтора раза за два года



Новый год — новые показатели, и да, нам есть, чем похвастаться. Ведь если считать с 2021-го, то число серверов, находящихся в нашем активе, увеличилось в полтора раза. Благодаря этому парк оборудования RUVDS достиг максимальных объёмов за всё время существования компании (а нам, напомним, недавно «стукнуло» восемь лет).

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

Только в этом году компания RUVDS запустила площадки с вычислительными мощностями в Турции и Казахстане, а также начала предоставлять услуги аренды VPS-серверов на оборудовании, расположенном во Владивостоке. По состоянию на конец 2023 года в нашем активе 15 дата-центров, семь из которых находятся за пределами России.

Мы продолжаем совершенствоваться, расширяться и внедрять что-то новое. Самое важное — вот тут, в нашей подборке:
  • Теперь приобрести VPS-сервер RUVDS можно и в Telegram
  • Мы вводим новые стандарты ответственности перед клиентами
  • Дарим панель ispmanager при заказе сервера на Linux
  • RUVDS заходит в Турцию
  • Новый дата-центр во Владивостоке
  • RUVDS уже в Казахстане
  • Теперь серверы RUVDS можно оплатить в рассрочку через Яндекс Сплит
ruvds.com/ru-rub

Сложный был год



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

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

С 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/