Все люди, которые со мной общались по поводу «у меня есть проблемасайт и я хочу переехать на другой хостинг» слышали от меня фразу «shared-хостинг? да не, точно мудаки, бери VDS». Пришло время сорвать покровы (раз уж у меня период графомании) и на примерах показать-рассказать, почему в 2015-м году использовать шареды нельзя от слова «совсем».

Дабы не быть совсем уж негативным, я сначала расскажу о том, что есть хорошего в shared-ах.
— обычно они дешевле VPS/VDS (хотя и с приходом digitalocean/linode/flops и прочих это не всегда так).
— чтобы положить файл на shared-хостинг обычно ничего толком не нужно знать. Ну то есть уж знаний в администрировании точно не нужно — достаточно почитать хелп по панели, которую использует хостер.
— если вам повезло с саппортом хостера, то вам объяснят, почему ваш код не работает на хостинге.
— вам действительно не нужен сисадмин, даже знакомый. Многие хостеры помогают переехать/настроить домен и прочую фиговину, после чего вы забываете про всю механику до тех пор, пока не собираетесь менять хостинг.
— обычно в комлекте дают настроенную почту/dns и прочее, так что думать нужно ещё меньше

И прежде чем начать, хочу сразу оговориться, что есть действительно хорошие хостинги. Правда, они по большей части приватные, стоят от $50 за один сайт, имеют зубров в поддержке и лишены почти всех минусов, описанных ниже. И найти их очень тяжело. Я сталкивался с двумя, ещё про один слышал на тостере, при том те, с кем я взаимодействовал, уже не принимают новых клиентов. И это за почти 10 лет с момента создания первой бесполезной хоумпаги на народе (сайт школы моей, ага).
Ну а теперь к делу.
1) Первая и самая главная проблема — вы вообще ни на что толком не можете повлиять в настройках. Мне встречались хостеры, где на серверах не были установлены php5-curl и php5-imap. С некоторыми удалось договориться, они поставили эти модули (казалось бы — php без курла?) достаточно быстро. С некоторыми пришлось пободаться и дойти до третьей линии саппорта со скандалами. На одном хостинге удалось (случайно) договориться об установке php5-imap на нужный сервер через тех.дира, с которым удалось пересечься где-то в irc — саппорты упорно слали в лес. На где-то 5 хостингах imap не поставили вообще, и пришлось оттуда уезжать.
Казалось бы — мелочь. Но если у вас нет опыта, то мало того, что вы не знаете, какие модули php вам нужны, мало того, что почти никто из хостеров не публикует exact-список установленных модулей (чтобы можно было пробежаться по нему до переезда), так ещё и на том конце телефона козлятся.

2) Вторая (для меня — самая главная), хоть и не столь важная проблема для обывателей — https. https на shared-хостинге — это оксюморон. Хорошо, если он вообще просто выключен на сервере (и по 443-му порту ничего не доступно). Это правда счастье для тех, кому нужно, чтобы сайт работал только по http. Намного же чаще встречается такое, что по https://вашсайт открывается гребаная неведомая фигня и делать с этим ничего не будут. Конечно же, при этом там ругаются на невалидный сертификат все браузеры. В век дополнений, похожих на https-anywhere это действительно проблема.
Причина-то очень простая — обычно на https:// хостеры вешают какую-нибудь панельку (тот же ispmanager так делает). Само собой, в конфигах вхостов про https ничего нет, но порт доступен — значит nginx тот-же будет показать default vhost. И хорошо, если там просто страница об ошибке — частенько там может оказаться и чей-то чужой сайт ;)
Но даже если вы взяли отдельный IP (кстати не факт, что там тоже не будет неведомой хрени на https) и купили себе сертификат (и даже смогли его установить на хостинг, что даже для меня не очень тривиально в некоторых панелях — в конфиге nginx как-то сильно проще получается), то получить A-grade на sslrat-ингах вы вряд ли сможете — хостер делать ничего не будет, а дефолтовые конфиги дают только С.

3) Безопасность. Всё плохо, всё оооооочень плохо (с).
Уязвимости не фиксятся не то, что месяцами — годами. В сети _до сих пор_ есть хостеры, уязвимые к heartbleed (кому интересно, их можно найти здесь — https://zmap.io/heartbleed/ , если приложить немножко усидчивости).
Так как ребутить сервера shared-хостинга — это целая эпопея длиною в жизнь (тонны заявок, недовольных возгласов and etc), то и ядра там обрастают уязвимостями (в том числе и на тему получения рутового доступа через публично доступные эксплойты). А уж про libc я молчу.
Сама модель «1 сервер, много пользователей, которые хотят навредить друг-другу» — достаточно сложна в администрировании (я её всегда стараюсь избегать — никто не готов оплачивать 10-20 часов работы по приведению такой помойки в порядок). Как следствие — у некоторых хостеров можно случайно подарить всем соседям свои файлы, выставив chmod 777 там, где не нужно (впрочем, тот же ispmanager от такой ситуации защищает из коробки и обойти эту «защиту» сможет только рут — чего не всегда скажешь о самописных панелях).
У некоторых хостеров можно пойти и почитать что-нибудь в /var/log. Да, часть логов доступна только root (и группе adm). Но иногда находится что-нибудь повеселее — /var/log/mail.log, какой-нибудь. И да, в возможности чтения почтового лога всех пользователей саппорт того хостинга проблемы не видел =)
Ещё в почти всех дистрах пользователь может посмотреть список пакетов. Тоже мало веселого. Ну или вот команда last интересная — её могут запустить пользователи, а она позволяет посмотреть список ip-адресов с привязкой к дате-времени логина по ssh и имени пользователя.
Ну а уж если ваш сайт работает под пользователем www-data, то файлы сайта проще сразу положить на сервере отдельным архивчиком и выложить ссылку на этот архив на морде сайта. php-шеллы никто не отменял.
Конечно, есть хостеры, которые засовывают каждого пользователя в отдельный контейнер/чрут/whatever, там с безопасностью получше. Но и цена там кусается, обычно. И проблем с обновлением софта никто не отменяет =)

4) Лимиты.
У многих хостеров есть огромные развесистые лимиты (не всегда описанные в условиях тарифа, а только где-нибудь в оферте, которую никто никогда не читиает). Лимиты на количество mysql-запросов, лимиты на количество запросов к диску, лимиты на количество посетителей, на количество одновременно открытых соединений, на RAM, на процессор, на количество внешних запросов, на количество принятых/отправленных писем… Да черт возьми, на всё они там могут быть.
И если с VPS бывает такая же хрень (привет, openvz), то там мы хотя бы можем примерно оценивать использование этих лимитов (да и подсчет там не такой дорогой получается).
А теперь представьте — каждый mysql запрос должен быть куда-то залоггирован и по всем этим миллионам запросов в час нужно уметь строить какую-то статистику. Мхм. Само ведение подобного рода статистики жрет приличное количество ресурсов.
Ах да — нам не всегда дают посмотреть на то, насколько мы используем эти ресурсы. О графиках вообще приходится только мечтать. Обычно, о «закончившихся лимитах» узнают тогда, когда сайт упал, а саппорт (спустя несколько часов ковыряния в этой своей непонятной системе лимитов) наконец-то сообщил нам, что мы сделали курлом за сутки не 100 запросов, а 101 и до 0:00 следующего дня сайт отключен =)

5) О том, когда сайт отключают.
Я ни разу не видел, чтобы сайт отключали корректно. Видел редирект на сайт хостера (на страницу о том, что нужно заплатить денег), видел открывающуюся 404-ку хостера, видел наглецов, которые просто показывали сайт хостинга на отключенном за неуплату домене, видел 200ю страницу с текстом о необходимости оплаты.
Но ни разу не видел 503-й страницы с указанием причины отключения и хоть какой-нибудь датой окончания даунтайма (например, текущее время + неделя). Такое ощущение, что ни один из хостеров не может прочитать статью Как справляться с запланированной недоступностью веб-сайта
Ну а последствиях вы уже подумайте сами. Забыли оплатить хостинг, промучались неделю с их биллингом — а сайта нет в поисковых базах. Или, что ещё веселее, он склеился с сайтом хостера. Хехе.

6) Страницы об ошибках от хостера.
Да, вы заливаете свой сайт, рисуете красивую 404-ку, заливаете её… И видите вместо 404-ки что-то в духе «Хостинг ГовноХост приветствует вас, такой страницы нет, но вы можете написать нам письмо». А ещё она может быть с 200-м кодом ответа, что совсем феерично.
Да, скорее всего её можно поменять, да, скорее всего быстро, да только кто ж такие вещи проверяет, кроме дураков, вроде меня?

7) Чисто российская фишка — РосКомНадзор.
Да да, у нас в стране есть эта адская штука, а ещё есть приличное количество провайдеров, которые всё ещё не смогли завернуть трафик для IP-адресов с заблокированными сайтами на отдельный фильтрующий squid.
В итоге, ваш сайт (про… ммм… котиков) показывает заглушку у трети населения РФ со словами о том, что на вашем сайте продавались наркотики. Ля-ля-ля.
(забыл уточнить — сайт, который продавал наркотики, IP уже сменил и открывается у той самой трети населения — у остальных двух он зафильтрован по домену).
Ну и да, ещё суд может постановить, что заблокировать нужно именно конкретный IP-адрес, тогда без переезда точно не обойтись. Если заблокировали домен соседа — то сколько-то времени у вас будет показываться заглушка, а потом пройдет.

8) И ещё одно следствие одного ip на всех — вас могут забанить не только в росцензурнадзоре.
Отвалился однажды у человека сайт. Попросил меня разобраться, благо сайт был знакомым (и я им пользовался). Вспоминаю, что там было, припомнился апплет с курсами рубля от ЦБ РФ. При том рисовался он в коде сайта синхронно, с кешом на сутки. Но вот если кеш протухал, то там делался синхронный http-запрос в сторону серверов ЦБ.
Тыкаемся курлом в ЦБ — курл через 180 секунд задумчиво говорит нам, что connection timeout. Хрена же себе, думаем мы. Заворачиваем запросы через проксю, всё работает, идём разбираться с хостером. Хостер дотумкался запустить tcpdump, в котором увидел примерно 2 запроса в секунду в сторону ЦБ. Да-да, по соседству жил сайт с курсами, достаточно популярный, но без кешей. И ЦБ у себя сделал -j DROP.
(само собой, вся конкретика в этой истории заменена на выдуманную, и там вообще было не про ЦБ).

9) Ваша база почти ничем не защищена.
На нормально настроенной VPS mysql слушает только порты на локалхосте. А заодно там выданы гранты только на то, что пользователь может зайти только с локалхоста. И рут может зайти только с локалхоста.
То бишь, чтобы люди могли поделать запросы в вашу базу, им нужно попасть на ваш сервер (залить шелл, найти уязвимость в коде сайта, нужное подчеркнуть), помимо того, что спереть логин с паролем.
На шареде у вас есть множество добрых соседей, которым уже залили шелл, из которого они могут пойти в вашу базу.
Ещё есть популярная схема, когда mysql-сервер стоит в сети хостера на отдельной машине. Там иногда, конечно, выдают правильные гранты на правильные хосты (но тогда есть добрые соседи с залитым шеллом), но в особенно упоротых случаях гранты выдаются на все хосты и в базу потом можно ходить с любого IP.

10) Во время ddos-а вас с куда большей вероятностью просто выключат.
Да-да, самым простым способом для хостера отбиться от ddos-а — просто отключить ваш сайт. Ведь есть добрые соседи, которые заплатили деньги и они страдать не должны.
Ну то есть сделать map в nginx и банить ддосящих в нём и только для вашего сайта — это архисложно (не говоря уж о том, чтобы банить просто адреса в fw — ведь тогда ддосеры не смогут зайти на другие сайты нашего хостинга!). А просто выключить — дешево.
И да — для некоторых хостеров ддос это 20 запросов в секунду. Ну или чуть больше.
А ещё, если у вас стоит лимит на одновременное количество подключений, то уронить весь сайт может случайно чихнувший на ваш сайт поисковый робот.
Нет, конечно VDS-ки тоже будут падать под досом, но хостерам на вас будет начхать до тех пор, пока ему аплинк не забьют. Так что от школьников можно будет отбиваться своими силами.

11) Вы намного больше страдаете от действий соседей.
Если хостер всё же добрый и лимиты не настроил, то один бедный сайт может уронить всю железку. Ну или кто-то специально так сделает — написать скрипт, который забьёт IO SATA-сервера — дело 10 минут копания в гугле.
Можно забить память, можно забить сеть исходящими запросами, можно забить диски по IO, можно забить диски по inodes, можно засрать CPU, можно… да много чего можно, если лимиты конкретно на это забыты.

12) Версии PHP/Python/whatever.
На примере php — у большинства хостеров на сервере стоит ровно одна версия php, которую на этом сервере обновлять никогда не будут (а если будут — то это ещё хуже, кхе).
У более продвинутых хостеров есть возможность выбрать версию, но вот работать она будет в каком-нибудь режиме CGI и адово тормозить (ну и напоследок там отломается кеширование через акселераторы).
В итоге, хочется новую версию — ищем нового хостера (или переезжаем на новый сервер хостера, что в принципе равноценно, разве что искать не нужно будет).

13) низкий аптайм
Да, хорошо настроенная VPS у хорошего хостера будет работать стабильнее любого shared-хостинга. А ещё она будет уходить на обслуживание тогда, когда вам это нужно, за редким исключением (вроде «ой блин, не тот шнурок выдернули»).
Шареды страдают от досов (кому ваш сайт нужен? а если нужен — то почему вы всё ещё не в soyoustart на физической железке?), от ошибок в конфигурации (поставили точку с запятой, порестартили nginx, не посмотрели выхлоп), ребутов в дневное время ну и прочего.

14) О бэкапах нужно думать самому.
Все хостеры делают бэкапы. Вот только не факт, что вы ими сможете воспользоваться, не факт, что в них будут актуальные данные, не факт, что хостер сам не восстановит сайт из бэкапа тогда, когда вам не нужно, не факт… В общем, надеяться на бэкапы хостера нельзя. Ни в коем случае.
В конце концов, «Дело в том, что у нас было настроено автоматическое сохранение копий баз данных на другой сервер. Но этот сервер тоже располагался в сгоревшем Датацентре Hosting.ua.» (с)

15) если вы поняли большинство слов в этой статье — то дорого.
Хороший shared стоит 400-500 рублей (ну то бишь $10). Он будет избавлен от хотя бы половины из описанного выше. Там иногда будет отвечать саппорт. Ещё он будет на SSD, скорее всего, что тоже сильно помогает.
Но за $10 можно взять виртуальную машину в… эээ… наверное уже двух десятках компаний с гигабайтом памяти, настроить её и жить-радоваться.