Управление хостингом: вид из головы тактика
Есть три уровня управления VDS-хостингом: стратегический, когда вы выбираете, что за продукт вы делаете, какое железо и у кого покупаете и в какие ЦОДы и на каких условиях встаёте, — по сути, это формирование ДНК хостинга. Есть операционный — это рутина вроде «отбить диапазон IP-адресов, который попыталась заблокировать Сони», «опять железо застряло на границе» или «админ заболел, кого поставить в смену», «сложный тикет третьей линии». Например, на уровне ДНК мы решаем, что нужно заменить поддержку на разработку (чтобы клиент мог сам всё решать из личного кабинета), а на уровне тактики уже определяем, как именно это сделать.
И есть промежуточный тактический уровень, которым занимается операционный директор. Это не решение конкретной формализованной задачи, но и не глобальная стратегия.
Первое, что нужно видеть, — это чёткая картина всех имеющихся ресурсов. Для этого нужно знать маркетинговые параметры и параметры финансовой модели. То есть нужно знать состояние счетов хостинга на неделю, месяц и полгода вперёд на основе оплат, которые планируются, и расходов, которые планируются. То есть нужно знать процент выхода из строя железа и его ремонты, оплаты сотрудникам, прогнозировать приток и отток клиентов и так далее. Второе — нужно управлять разработкой, то есть выбирать фичи для реализации и находить время для рефакторинга.
Плохой операционный директор для принятия решений начинает собирать данные. Хороший эти данные уже имеет. У нас все решения принимаются очень быстро, потому что мы гики автоматизации и автоформирования отчётов. Каждый раз, когда нам нужен какой-то показатель, мы не получаем его руками, а пишем скрипт, который режет отчёты по нему или добавляет показатель в уже имеющийся отчёт. Наличие информации обо всём в компании — одна из самых главных вещей в управлении бизнесом.
Так что добро пожаловать в рубрику «Хостер наконец-то пишет про хостинг в своём корпоративном блоге».
▍ Очистка IP
IP-адреса у нас выдаются клиенту раз и навсегда статические. Кстати, именно поэтому популярны промотарифы за 30 рублей (когда они есть) — там в комплекте тоже идёт IP-адрес, и стоимость тарифа ниже, чем отдельная услуга выделения этого адреса. Но при этом, если клиент где-то «испачкал» свой адрес, мы не меняем его по щелчку пальцами. Поэтому регулярно встают вопросы:
- Что делать, если на клиента пришла жалоба.
- Что делать, если арендованный нами IP-адрес раньше принадлежал спамеру или ещё кому-то подобному.
Блокировка бывает разного характера. Первое, с чем сталкивается хостер, — это Спамхаус. По сути, эта организация должна бороться со спамом по всему миру. Но формально она независимо отслеживает спамеров, ботнет-сети и вообще всё то, что запрещено и что можно автоматически сдетектировать не сильно сложными алгоритмами. Их основная функция — если они видят с какого-то адреса рассылку спама или находят, что с какого-то адреса идёт DDoS-атака, то блокируют его. Но блокировка происходит не сразу. Сначала они шлют уведомление в компанию-владельца адресов. Это крупные компании, которые покупают IP-адреса.
Покупают они их не для себя, а для сдачи в аренду компаниям поменьше. У таких компаний мы арендуем свои пулы адресов. В итоге жалоба спускается по цепочке к нам. Письмо приходит от арендатора крупного сегмента, а нам надо написать в Спамхаус, что меры приняты. Спамхаус редко ошибается, поэтому «меры» — это обычно разобраться и заблокировать. Кстати, по их письмам мы периодически обновляем список запрещённого ПО в договоре, чтобы не возникало вообще никаких сомнений. Список запрещенного ПО держим в секрете, чтобы было сложнее его обходить.
Если нам достаётся адрес, который уже находится в базе Спамхауса, то обычно после письма в течение суток он оттуда исключается. Но в последней аренде, например, была подсеть в чёрном списке, которую мы выколупывали почти неделю. Если такой адрес попадёт клиенту, то у него не всё будет хорошо работать в интернете. То есть не отрубит, но пойдут разные гейзенбаги как минимум.
Второй ключевой игрок в российской юрисдикции — это Роскомнадзор. Но попадание в его блокировки на практике — это редкость. Приходит уведомление, что по такому-то адресу такая-то вредоносная деятельность. Мы это уведомление должны переслать тому, кто эту деятельность ведёт. Есть 24 часа на устранение. Дальше владелец либо устраняет нарушение, либо же РКН отправляет его адрес в чёрный список. Принцип работы чёрного списка несколько раз менялся, но всегда это та или иная отправка адресов по всем операторам связи в автоматическом режиме. Это просто пул адресов, который загружается на коммутационное оборудование в виде правил. Именно эта система стала самой большой импровизированной «рекламной кампанией» использования VPN в России в своё время.
Если клиент не отвечает в РКН и не прекращает вредоносную деятельность), то мы блокируем такого клиента со своей стороны. Но на практике случаев блокировки не было ни одного — клиент всегда всё делал как надо. Был случай, когда нам достался один адрес в аренде с уже применённой блокировкой (обычно арендатор адресов очищает свои подсети сам перед передачей другому клиенту), — пришлось писать письмо про аренду в РКН со смыслом «там такой деятельности уже нет, удалите». Удалили довольно быстро.
▍ Аспекты разработки
Мы стараемся заменить поддержку на разработку. Первая линия поддержки, по сути, выполняет функции скрипта: читает тикеты, разбирается в них и либо отправляет во вторую линию, либо делает что-то, что можно было сделать автоматизацией. В самом-самом начале хостинга, когда мы только добавили в личный кабинет возможность быстро менять параметры машины (диск, память, останавливать-запускать), это сильно разгрузило поддержку. Теперь мы хотим вовсе от неё избавиться, сделав так, чтобы технические вопросы решались кнопками в личном кабинете.
Речь идёт про первую линию. Сложные тикеты и тикеты, имеющие отношение к организации и клиентским отношениям, безусловно, останутся.
Исходя из этой модели мы рассматриваем разработку как средство развития хостинга (новые фичи) и средство разгрузки поддержки (всё большая автоматизация). Обе функции относятся к business critical, то есть требуют минимума потерь в коммуникациях. Поэтому у нас плоская иерархия в разработке. Нет тимлидов, нет «лидеров ячеек» вроде «я сеньор, пасу двух мидлов и джуна», нет никаких менеджерских функций в разработке. Менеджерские функции берёт на себя непосредственно управляющий хостингом. Понятно, что при кратном росте, скорее всего, понадобится выделенный CTO, но пока в любом случае техническое состояние всей компании должно быть функцией директора: это критично для эффективности.
▍ Пара слов про маркетинг
Хостинг — далеко не первый наш бизнес. Могу сказать, что в маркетинге главное отличие хостинга от других предприятий сферы услуг в том, что IT-специалисты покупают рационально. В смысле, что не работают традиционные механизмы рекламы, включаются совершенно другие критерии оценки «цена — качество», люди понимают важность стабильности и поддержки. Как следствие — у многих есть любимые хостинги, и «пересадить» IT-спеца на новый (наш) довольно сложно. Вот это «работает — не трогай» создаёт такой здоровый консерватизм. Да, у нас в клиентах — не только IT-специалисты (особенно в последние годы), но во многом всё же мы продаём рациональным людям.
▍ Аспекты системного администрирования
Сначала у нас были тимлиды среди админов, поскольку очень много операций нужно было делать вручную. По мере автоматизации хостинга потребность в этом постепенно начала отпадать, и образовалась такая же одноранговая сеть, как в случае разработки. Потом выяснилось, что каждый раз, когда разработчики что-то делают для внутренней автоматизации, у админов высвобождается немного ресурсов, то есть им становится в целом проще жить. В итоге развития этого явления отдел разработки фактически возглавил отдел администрирования. И автоматизировали большую часть функций администратора.
Это дало ещё одну важную вещь: обычные администраторы не имеют сейчас прямого доступа к железу, а работают через нашу внутреннюю панель управления. Это позволило решить очень много вопросов с безопасностью в том числе. Как я говорил, мы не интересуемся, какая гостевая ОС установлена на машине, и не видим, что там. Поскольку нам не нужны были инциденты с ошибками или утечками, мы очень тщательно позаботились и о логировании всех действий админов, и об автоматических проверках их целесообразности, и об отчётах об этом. Ну и о разграничении прав, конечно. Несколько лет назад ушло одно из традиционно уязвимых мест хостингов, в котором люди-администраторы имели неограниченный доступ к хостовым машинам.
Сама техническая возможность влезать в данные пользователей нам никогда не нравилась, и, несмотря на то что это данность и стандарт рынка, мы от этого уходили. Чтобы получить доступ к той или иной хостовой машине, администратор запрашивает у системы пароль. Есть несколько ограничений: например, количество машин за промежуток времени, действия с этими машинами и так далее. Мы минимизировали действия через консоль (по сути, это осталось прерогативой разработчиков) и обезопасили бизнес-процессы от несанкционированных доступов со стороны сотрудников.
В итоге квалифицированные админы фокусируются на вопросах железа и инфраструктуры, а функции админа, по сути, выполняет поддержка. Причём та самая поддержка, которая постепенно заменяется скриптами.
Итог такого подхода — мы получаем серьёзную экономию в количестве нужных людей на ЦОД, что позволяет держать цены низкими, и при этом параллельно улучшаем качество хостинга. То есть мы не в самом нижнем сегменте по рынку, но нащупали тот уровень, где показатель «цена — качество» очень нравится клиентам.
Плюс на самых дешёвых тарифных планах мы не обеспечиваем часть админской поддержки (например, не ставим Апач, а даём ссылку на внутренний маркетплейс с ним и инструкцию), а на дорогих проектах уже можем дать и личное сопровождение. Как правило, в такой ситуации клиент уже отлично понимает, что делает, и последние два раза админ ему был нужен для подбора локаций, железа и конфигураций под задачу, а потом — проведение тестов. Но всё равно каждый месяц к нам стучится китайский клиент, который на ломаном русском пишет тикет про то, что у него не запускается какая-нибудь китайская прикладная программа.
▍ Управление людьми
Любая большая IТ-система — это управление хаосом с размытыми рисками. В системах нет ни одного полностью надёжного элемента, все они рано или поздно выходят из строя. Ярчайший пример — комплектующие, которые регулярно надо заменять без простоя. Но при этом сама система может оставаться достаточно надёжной в целом, если есть механизмы самовосстановления и резервирования. Возможно, я скажу крамольную вещь, но с точки зрения управления люди также относятся к точкам отказа и, соответственно, требуют резервирования.
А это требует пересмотра архитектуры отделов и подхода к найму вообще. Некоторое время назад мы искали универсальных людей, способных решить любую задачу хостинга одной левой. Но с точки зрения поддержки бизнеса — это неверно. Трудно было, когда человек болел, уходил в отпуск. Без него было невозможно. Особенно в части поддержки и администрирования. Мы наняли дополнительного сменщика, который в обычное время работает в режиме 5/2, а когда кто-то в отпуске или уходит, — временно переходит в сменный график. В итоге у нас в каждом подразделении всегда на одного человека больше, чем нужно, либо эти функции «дополнительного человека» распределены между несколькими другими людьми. Если кто-то заболеет, то ни один процесс и ни одна задача не остановятся. Может быть, просядут по скорости, но не остановятся. Это звучит немного странно в компании, которая работает в нижнем ценовом сегменте, но мы посчитали длинные периоды и получилось, что избыточные специалисты обходятся в целом (в системном эффекте для компании) дешевле, чем их отсутствие.
Что делать с позициями, которые требуют очень необычных людей? Например, что делать с руководителем маркетинга? Здесь мы тоже пару раз знатно обожглись. Сначала мы думали, что нужно брать человека из похожей сферы, в идеале — имеющего опыт продвижения хостинга. В принципе подход-то разумный. Человека не нужно будет вводить в тему. Он видит то, что нужно делать. Возможно, у него уже есть какой-то опыт, который он может помножить на наш и получить что-то большее в итоге. Закончилось всё это печально, так как мы не учли, что если человек переходит к конкурентам, то он там уже копирует наши бизнес-процессы. В итоге мы пришли к тому, что все творческие задачи разбиваем на такую же автоматизацию, как и для администрирования. То есть каждый бизнес-процесс должен быть описан и покрыт хотя бы инструкциями, а ещё лучше — инструкциями, примерами и инструментами, как с этим работать. Смысл в том, что всё работающее должен почти бесшовно подхватывать другой человек.
Это звучит как попытка избавиться от незаменимости сотрудников и превратить всё в квадратно-гнездовую работу, но на деле достигается другой эффект. Понятное дело, что хорошего специалиста можно заменить только другим хорошим специалистом, и при этом часть компетенций компании в целом потеряется, а часть новых появится. Но самая важная часть — это не давать никому погрязнуть в рутине. Рутина — для роботов. Если больше половины вашего рабочего времени занимает что-то, что вы уже делали, или что-то, что в принципе может быть автоматизировано или делегировано кому-то с рабочим временем дешевле, то это боль для компании. Чтобы расти, нужно делать вещи, которые дают максимальный эффект, а для этого нужно постоянно скидывать рутину сначала на уровень подчинения ниже, а потом — на автоматизацию.
Поэтому, кстати, у нас очень низкая текучка. Возможно, потому, что нет погружения в рутину и есть постоянный прогресс.
▍ Подбор специалистов
Зарплаты в IТ — это функция, которая постоянно растёт. Зарплаты очень высоки и находятся, наверное, сейчас на максимуме за всё время существования индустрии. Теперь представьте ситуацию: у вас в команде есть разработчик, который получает 100 условных мёртвых енотов. Таких 100 енотов получает разработчик другой компании. Это стандарт рынка. Чтобы переманить к себе разработчика из другой компании, нужно предложить ему лучшие условия. В итоге это будет или 110 енотов и какие-то нематериальные плюшки либо условно 120 енотов. Процесс повторяется несколько итераций, и вот мы получаем выравнивание зарплат в соответствии с потребностью рынка в новых людях и ожиданиями самых богатых компаний. Это нормальный процесс выравнивания спроса и предложения.
Мы долгое время пользовались услугами HR-агентств. Платили гонорары за подбор кадров. Кого только мы так не подбирали! В последние годы это стало очень дорого, и всё равно вы получаете кота в мешке. И в целом нас устраивает уровень зарплат рынка, только мы хотим найти человека, который останется в компании дольше года и при этом без фундаментальных пробелов в образовании. Дообучать человека месяц-другой, чтобы он ушёл через год, дорого.
В итоге мы пришли к тому, что гораздо практичнее обучать собственных специалистов, уже знакомых с хостингом. Например, в админы приходит студент технического вуза. Если есть желание — мы берём его на стажировку в разработку. Да, он растёт два года, но потом получается человек, который чётко понимает, что и как работает. Он знает все проблемы хостинга. Дальше следите за руками: при той же рыночной зарплате мы получаем человека, который поменяет место работы с гораздо меньшей вероятностью (поскольку у него нет на это стимулов) и который гораздо глубже понимает продукт.
Ещё один наш принцип — не брать людей на высокие должности без того, что они пройдут тест или стажировку на более простых позициях.
Ещё у нас коллегиальное управление. Есть компании, где установлены тоталитарные правила управления. Они очень эффективны в кризисы, очень эффективны, пока в них до 50 человек, но дальше начинают терять людей и рыночную эффективность. Дальше выбирается структура с сильными руководителями отделов либо же вводится какой-то демократический процесс. У нас коллегиальное управление. Меня как человека, хорошо умеющего развивать маленькие проекты в большие, оно местами бесит чисто эмоционально, но это хорошая бизнес-модель.
Например, у меня есть рыночное понимание, что нам нужна какая-то новая фича. Я не могу прийти в разработку и сказать: «Делаем вот так». Мне нужно продать эту идею коллегам. Раздражает, собственно, момент, когда ты сам уже с самого начала понимаешь, что это нужно сделать, но нужно ещё объяснить другим, зачем это нужно сделать. И это проверка умения объяснять: может оказаться так, что сбой произошёл именно там. Тем не менее, если так не делать, то не будет здоровой ситуации в коллективе.
Когда нас станет 100–150 человек, понятно, что эти принципы будут неактуальны, но сейчас так.
▍ Аспекты поставки оборудования
Поставка оборудования хорошо автоматизируется и покрывается типовыми процессами, но только до определённого предела. Потом всё это начинает сбоить на конкретных заказах, и за каждой поставкой всё равно надо следить вручную.
Общий принцип такой: мы заказываем оборудование в Москве в офис, его развозим по MSK-IX, Останкино и Королёву после короткой настройки. Для России оборудование тоже заказывается в Москву. Мы его предварительно готовим, в оконечных ЦОДах нужно просто воткнуть его в стойку, в сеть и в питание. Доставка до ЦОДа делается DHL или СДЭК специально обученными грузчиками. Бывает, что вендор или дистрибьютор своими силами сразу направляет оборудование в РФ, а документы к нам. В любом случае окончательная настройка делается из офиса, когда железка вошла в наш контур администрирования.
В Европе мы сейчас покупаем в Амстердаме и возим по всем странам оттуда. Это не всегда выгодно и не всегда быстро на первый взгляд, но, как оказалось, — лучший системный эффект достигается именно так. Во-первых, однажды мы нашли цены сильно ниже в РФ и хотели привезти один конкретный сервер через границу, потому что даже с учётом таможенных операций получалось куда быстрее и выгоднее. Оказалось, не всё так просто — для вывоза железа надо получить разрешение ФСБ. Для этого мы обратились к логистам. Они допустили ошибки в оформлении (ну или решили немного всерую отвезти, сейчас уже не понять). В любом случае машину прямо на границе окружил спецназ и положил водителя лицом в пол. Потому что нельзя вывозить серверное оборудование, не уведомив ФСБ. А они, видимо, не уведомили. Сервер год лежал как вещественное доказательство, потом нам пришлось заплатить штраф, равный стоимости сервера в декларации. С тех пор поняли, что перемещения за границу серверов туда-сюда делать не стоит. Покупаем в Европе со всеми издержками.
Внутри Европы вопросов по доставке почти нет: сервера во Франкфурт, Цюрих, Лондон и так далее едут из Амстердама. «Почти» — это Швейцария, там другое таможенное пространство. Если из Амстердама во Франкфурт доставка идёт как из области в область, то в Швейцарию нужен отдельный таможенный брокер. Сначала он возвращает налог при вывозе, потом мы платим другой НДС в Швейцарии. Но это «вернули-отдали» занимает около месяца. У нас был момент, когда серверы в Европе поставили и заполняли —, а швейцарские ещё ехали в ЦОД. Но всё равно покупать в единой точке всё дешевле.
▍ В общем
Если вы умеете управлять подбором людей, знаете все свои ресурсы и понимаете, как именно нужно реализовывать стратегию компании, — это идеальное операционное управление. Понятное дело, в реальном мире всё даже близко не так. В некоем идеальном состоянии на всё есть инструкции, всё понятно и предсказуемо, рутина автоматизируется. Но очень многие вещи до того, как описать процессами, нужно сделать руками. Я помню, как возил железо сам, как мы переписывались про первые очистки IP-адресов, как ездили на первые переговоры (а потом через пару лет переговоры вообще упразднили), и тогда было решительно непонятно, что нужно идти именно к текущему состоянию компании. Так что тут ещё важный вопрос, что именно вы делаете и как, то есть стратегический уровень. Без хорошей цели тактики не будет.
