- PVSM.RU - https://www.pvsm.ru -

Управлять VPS-бизнесом в 10 городах — это же просто

Управлять VPS-бизнесом в 10 городах — это же просто - 1


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

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

Это, пожалуй, главное.

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

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

Мониторинг

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

Например, у нас есть робот, который анализирует трафик. Если начинаются аномалии, он показывает их другому роботу, который оповещает нашу команду о начавшемся DDoS на клиента хостинга [1]. За ними смотрит третий робот, который проверяет их работоспособность. Все три вида работы когда-то выполнялись руками, но были быстро автоматизированы.

Мониторинг инфраструктуры делается где-то Заббиксом, но по большей части данные сводятся в нашу кастомную самописную систему. Мониторинг физических нод выполняется из учёта интересов бизнеса. Например, нам постоянно нужно знать количество свободных IP-адресов. Если они кончаются, нужно успеть заказать новые, чтобы клиент не жал кнопку впустую в интерфейсе. Есть служба, которая следит за свободными ресурсами серверов: одно применение нужно для того, чтобы мы не объявляли акцию там, где ресурсов не очень много — иначе клиенты не смогут завести VPS [1] в этом ЦОДе. Другое приложение — квотирование в конфигураторе сайта ресурсов для создания новой машины или сайзинг, имеющейся в конкретном дата-центре. Если осталось 10 Гб диска, то интерфейс в данном ЦОДе не позволит создать машину на 20 Гб. Личный кабинет на сайте напрямую связан с мониторингом и при каждом создании сервера получает актуальные данные. По факту это означает отсутствие множества тикетов в поддержку на ручное создание машин и разруливание таких случаев.

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

Управлять VPS-бизнесом в 10 городах — это же просто - 2

Пример работы конфигуратора, когда в датацентре нет возможности создать сервер максимальной конфигурации 16 GB RAM, 600 GB; для серверов с 9-16 GB доступно лишь 20 GB диска, для серверов с 4-8 GB доступно 430 GB, диск 600 GB доступен для серверов с 1-3 GB памяти

Управлять VPS-бизнесом в 10 городах — это же просто - 3

Полное отсутствие серверов, доступных для создания

Поддержка использует OTRS (кстати, у нас есть готовый образ [2] для быстрого развёртывания на клиентских машинах прямо из внутреннего маркетплейса). OTRS мониторит робот, который «подсвечивает» все первые ответы дольше 15 минут, а затем отправляет отчёт о качестве работы в почту руководителю команды и мне (в понедельник приходит за пятницу и выходные).

Управлять VPS-бизнесом в 10 городах — это же просто - 4

Отчёт о количестве обработанных тикетов

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

Управлять VPS-бизнесом в 10 городах — это же просто - 5

Отчёт о количестве прочтенных тикетов: здесь не только поддержка, но и команды маркетинга

Боты шлют SMS, уведомления в почту и в Слаку. Первым корпоративным мессенджером у нас был Скайп ещё где-то в районе 2012 года (это тоже традиция из мира финансов), но он так тормозил, что мы перешли на Слак (во время интервью [3] с Ромеро он рассказал мне про удобство Слака, и мы решили попробовать) — не в последнюю очередь благодаря его крутым API. Например, маркетинг получает уведомления об упоминании нас в СМИ, о выходе постов на Хабре на интересующие нас темы и так далее.

Управлять VPS-бизнесом в 10 городах — это же просто - 6

Бот, который сообщает о дежурных админах и сотрудниках поддержки

Управлять VPS-бизнесом в 10 городах — это же просто - 7

Бот, присылающий статистику из дата-центра

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

Бизнес-модель с минимальными издержками

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

Мы решили, что у нас будет ровно два типа железа и одинаковые цены по всему миру.

Это сразу означает очень простые интерфейсы, где человек не путается. Это означает упрощение автоматизации со стороны хостинга [1]. Это гораздо более простая поддержка на уровне железа. Если бы было четыре типа железа, то пришлось бы вдвое увеличить те же ЗИПы на площадках, что сказалось бы на тарифах (да, у нас есть next business day-гарантия от Хуавея, но мы держим свой ЗИП, чтобы реагировать сразу).

Существенная часть себестоимости услуг VDS-хостинга — это железо и зарплаты. Если ФОТ мы оптимизируем автоматизацией и мониторингом, то железо становится куда более дешёвым, если его покупать сразу большими контрактами. И ещё дешевле, если просчитать его обслуживание заранее — поэтому у нас не «кухонные сборки», а нормальные серверы корпоративного класса. И поэтому у нас даже на тарифах с HDD стоят SSD-диски (с лимитером по скорости). Мы считаем окончательную стоимость владения за несколько лет до списания. И считаем не только с учётом конкретной системы, а по всей компании, то есть с учётом удорожания той же разработки для разных типов железа.

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

Когда мы только заходили на рынок, то немного демпинговали, то есть были в сегменте «самый дешёвый VDS-хостинг». Финансово-разумно находиться чуть выше: это позволяет не срезать качество там, где это аукается на клиенте. Дальше было важно выстроить продукт так, чтобы туда входило только необходимое, это предоставлялось с достаточным качеством и не создавало издержек. Хотите извращений — есть дорогие хостинги. Хотите на 5 % дешевле — есть менее надёжные хостинги с поддержкой, возможно, чуть хуже. Цены мы поднимали за всё это время ровно два раза: на 5 и на 10 % в кризисы, когда рубль открывал нам новые горизонты падений. И не посреди года, а в конце года. То есть за время работы хостинга [1] мы индексировали цены даже медленнее инфляции. Так вот, при первом поднятии цен мы обнаружили, что аудитория самого дешёвого хостинга [1] сильно отличается от аудитории «нормального фастфуда на рынке хостингов». Буквально за несколько месяцев поддержка отметила, как качественно поменялась аудитория: тогда пришло много опытных админов, которые точно знали, что хотели.

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

Открытие нового ЦОДа

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

  1. Выбираем интересующий регион, в нём весь список доступных ЦОДов, смотрим на требования по физическому доступу, близости к узлам обмена магистральным трафиком и так далее.
  2. Смотрим, есть ли там два «наших» провайдера. Сначала у нас были разные провайдеры, но оказалось, что гораздо выгоднее договариваться с одним основным и одним резервным. На наших объёмах один ЦОД не высасывает полосу, поэтому нужно шерить её между разными точками. Плюс для этого одного провайдера мы крупный клиент, и он делает так, как мы любим. Поэтому в итоге если раньше мы плясали от ЦОДа и разговаривали с ним, то теперь переговоры с площадкой ведёт фактически провайдер. Мы общаемся удалённо, самая главная часть — ЦОД заполняет бриф на стабильность бизнеса. Это экономит море времени на переговорах: мы берём параметры и просто загоняем в оценку бизнес-модели.
  3. Проверяем качество работы поддержки. Это одна из тех вещей, которые надо делать вручную: нам очень важно, чтобы в субботу в 18:15 нам не сказали: «Ну давайте в понедельник решим». Это нормальная картина для ряда даже дорогих ЦОДов Европы.
  4. Проверяем возможность арендовать гермозону и расширяться по мере роста бизнеса. От пары отличных вариантов пришлось отказаться, поскольку не было возможности воткнуть через некоторое время дополнительные серверы (по нашей оценке).
  5. Проверяем стабильность бизнеса ЦОДа. Мы хотим вставать надолго, и переезды нам не нужны, как и изменение условий из-за смены владельца. Наш второй ЦОД в Швейцарии был ошибкой: он был прекрасен всем, в него даже подземная река заходила для охлаждения. Но мы не учли, что цены были слишком низкими для такой сказки. Он был слишком хорош. В итоге инвесторы решили, что он генерирует слишком мало денег и преобразовали его в майнинг-ферму. Река холодной воды тут очень пригодилась. С тех пор мы используем свой опыт оценки бизнеса для оценки того, сколько проживёт ЦОД. Началось это со вторых грабель на самом деле: сначала мы уезжали из внезапно закрывающегося Каравана в России. Потом в Швейцарии [4]. Но двух ударов нам обычно хватает, чтобы больше так не делать.
  6. Заказываем железо у своего проверенного поставщика в Амстердаме или у другого проверенного поставщика для другой географии. Оказалось, что возить железо из Голландии по Европе выгоднее, чем заключать десять контрактов на местах. Такой же принцип: у нас большой объём, который даёт не только скидку, но и особое отношение.

Швейцария как второй ЦОД была на самом деле риск-манёвром. Когда мы его открывали, расположение было очень важным для ряда наших заказчиков. Для многих «Швейцария» означало «надёжность сейфа». Нам было очень тяжело объяснить некоторым из них, что мы везём железо в другое место. Но мы не могли поступить так, поскольку было крайне важно уйти от модели одного ЦОДа (тогда у нас было только бомбоубежище в Королёве) — даже в таком надёжном месте нельзя складывать все яйца в одну корзину. Мы видели, как пожар перенёс пару ЦОДов в облако. Вместе с бизнесом владельцев. С тех пор у нас застраховано ВСЁ железо от пожаров, наводнений и цунами.

Вообще это стратегия постоянного поиска слабого места (концепция антихрупкости). Уже на второй год работы хостинга [1] кошмаром было падение ЦОДа по каким-то независящим от нас причинам. Бешеные экскаваторы находят даже лучших из лучших. Сейчас ЦОДов десять штук, и этот вопрос давно закрыт.

Сейчас вот рассматриваем ещё один нестандартный ЦОД. Можно развернуть площадку в Останкино, где стоят телевизионщики. У них самый высокий аптайм — 100 % без перерывов с 1991 года. Кстати, есть примета, что если про такое написать на Хабре, что-то сразу упадёт. Посмотрим)

Ещё одно место, где мы ушли от переговоров — это работа с клиентами-юрлицами.

Работа с юрлицами

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

У нас появилась гипотеза, что мы упускаем что-то важное. И мы создали отдел продаж. Он проработал некоторое время, а потом мы его закрыли. Упускали мы откаты: некоторые люди хотели повысить цену контракта за вознаграждение себе. Мы несколько секунд думали про автоматизацию процесса ретробонусов. Ползунок «процент отката» в интерфейсе так и не появился, зато наша партнёрская программа [5] позволяет выбирать, какой процент скидки оставить референту, а какой забрать тому, кто привёл лидов. Так что не откат, а ретробонус агенту.

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

Пока всё

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

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

Источник [6]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/avtomatizatsiya/359541

Ссылки в тексте:

[1] хостинга: https://www.reg.ru/?rlink=reflink-717

[2] готовый образ: https://ruvds.com/ru-rub/marketplace/otrs#order

[3] во время интервью: https://habr.com/ru/company/ruvds/blog/467821/

[4] Потом в Швейцарии: https://habr.com/ru/company/ruvds/blog/432170/

[5] партнёрская программа: https://ruvds.com/ru-rub/partner

[6] Источник: https://habr.com/ru/post/531918/?utm_source=habrahabr&utm_medium=rss&utm_campaign=531918