Почему у нас такое жёсткое лицензионное соглашение

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

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

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

▍ «AS IS» против крупных рисков

VDS-хостинг — это продукт, который складывается из того, что хостер собрал в одном месте услуги ЦОДа, аренды железа в стойке, софта виртуализации и лицензий на гостевой софт типа операционной системы. Железо делают наши китайские братья, дата-центрами владеют наши соотечественники и европейские коллеги, электричество в ЦОДы подаёт кто получится, софт делает MS или кто-то ещё — в общем, тут море точек отказа, каждая из которых не может управляться хостером. Например, наш продукт в принципе не может являться отказоустойчивым по определению, потому что любая базовая ОС, будь то Windows или Linux, не является таковой. К примеру, Microsoft пишет в своих соглашениях, что их ПО нельзя использовать в жизненно важных областях, где важны бесперебойность и непрерывность работы. Например, в медицине. Точнее, так: можно, но вы это делаете на свой страх и риск, а MS умывает руки и отказывается от любой ответственности в принципе.

В том, что касается технических вопросов, мы делаем следующее:

1. Компенсируем простои по своей вине (точнее, по вине кого-то из поставщиков) клиенту хостинга напрямую.
2. Перенаправляем претензии в ЦОД или ещё куда-то, где произошла проблема, чтобы они это скомпенсировали уже нам.

То есть SLA в лицензионном соглашении с компенсацией за простои означает SLA во всех договорах с хостингами, производителями железа и так далее. Кстати, именно поэтому у нас при next business day-гарантии на всё серверное железо всё равно стоят свои склады ЗИПов на каждой площадке: нам надо сразу, а не через день.

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

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

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

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

Резюмируя по этой части:

• Мы несём ответственность в рамках SLA и компенсируем свои технические косяки.
• Продукт поставляется «AS IS», то есть мы не несём ответственности за ваши финансовые риски в результате использования сервиса.
• Ответственность нас перед вами страхуется в AIG: в частности, это урон нашей деловой репутации из-за длительной недоступности вашего ресурса, невозможность «выдернуть» данные, утечка данных и всё самое страшное из возможного.

▍ Хорошие условия против правил коммунальной квартиры

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

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

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

Вот пример пункта:

1.2.4. Исполнитель не размещает сайты и иные ресурсы Заказчика, на которые осуществляется сетевая атака (DDoS). Ресурсы под атакой будут выключены для сохранения стабильности предоставления услуг прочим клиентам. Возможность повторной активации атакуемого сервера Заказчика обсуждается в индивидуальном порядке.

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

2.5.1. Суммарный трафик виртуального сервера меньше 150 Гбайт в день (для серверов на тестовом периоде — 30 Гбайт в день) предоставляется без ограничений по скорости в соответствии с возможностями физического сервера и телекоммуникационного оборудования Исполнителя.
2.5.2. В случае превышения трафика более 150 Гбайт в день (для серверов на тестовом периоде — 30 Гбайт в день) полоса пропускания для виртуального сервера Заказчика может быть ограничена до 5 Мбит в секунду по усмотрению Исполнителя до конца суток, в которые было зафиксировано превышение (время UTC).

По факту мы проверяем соотношение входящего трафика к исходящему и начинаем ограничивать скорость при поведении, похожем на входящую или исходящую атаку. Поскольку мы не видим и не можем видеть сам трафик, речь идёт исключительно про его статистический анализ. По факту ложноположительные срабатывания также возникают при жёстком парсинге, разной спам-деятельности и так далее. Если клиент при этом не мешает остальным на сервере, то автоматика ничего не делает. Как только начинает мешать (обычно это случается далеко за пределами 150 Гбайт в сутки, через порядок или два) — применяются пункты лицензионного соглашения выше. То есть мы сами не заинтересованы делать что-то подобное, потому что клиентам это не нравится. Но общий принцип VDS-хостинга — живи сам и не мешай жить другим, поэтому мы ограничены этой концепцией.

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

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

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

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

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

А вот один из самых странных размытых пунктов:

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

Он означает, по сути, «если у вас сложный джойн через 20-гиговую MySQL-базу, то подумайте два раза, нужен ли он».

▍ Лицензионное соглашение MS против российских законов

Существенную долю нашего лицензионного соглашения занимает трансляция пунктов соглашений MS на клиентов, которым мы предоставляем лицензии на продукты Microsoft разных версий.

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

То есть клиент хостинга обязан соблюдать соглашения с MS: свои SPLA, SPUR (общее) и Mobility License. В этих документах среди прочего написано, что нарушитель обязан возместить стоимость потери MS, неустойку 20 % к этим потерям и заплатить за проверку. В общем, каждый аудит для нас — это печаль. Но если коротко — мы не знаем ни одного случая, когда клиент хостинга после нашего предупреждения про аудит не удалил бы что-то или не залицензировал правильно свой десктопный ключ. Причём чисто российская фишка «удалить на время аудита» тоже случается, поэтому особого смысла в таких действиях нет. Сейчас MS готовит новый пакет мер и новую систему работы, где все будут отвечать за всех, включая хостинг и дистрибьютора софта, чтобы они отвечали за клиента. Но про это я лучше расскажу позже, когда будет понятнее, что именно происходит.

▍ Ещё аспекты оферты

У нас нельзя делать субхостинг без того, чтобы не предупредить нас:

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

В списке запретов есть:

2.3.5. Размещение открытых (публичных) proxy- или VPN-серверов, а также систем для проверки работоспособности сторонних. Либо размещение приватных с использованием более 10 Гбайт суммарного трафика в сутки.

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

Расторжение, широкая формулировка:

8.1.2. По требованию Исполнителя при нарушении Заказчиком условий п.п. 3.2.1., 3.2.4. настоящего Договора; при совершении Заказчиком технических или иных действий, не предусмотренных Договором, не санкционированных Исполнителем, повлекших или могущих повлечь причинение убытков Исполнителю или третьим лицам.

Здесь важно то, что мы можем убрать с хостинга любого клиента, который мешает другим в коммуналке.

Ещё, как вы можете видеть на картинке вверху поста, мы можем отказать в обслуживании клиенту, который материт поддержку. По факту мы не отказываем тем, кто матерится случайно и безадресно («*** твою мать, ну что за день!»), но защищаем поддержку от тех, кто пытается оскорбить их осознанно и систематически.

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

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

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