В прошлой серии: мы рассказывали, как устроен интернет, зачем нужны IP-адреса и DNS-серверы, рисовали схемы и разбирались в фреймворках и CMS-ках. Если пропустили, лучше вернитесь и перечитайте. А сегодня новая порция технических тонкостей простым языком от нашего техдира Ивана. Кстати, можете вместо чтения посмотреть видео (и даже увидеть в реальном времени, как «программисты программируют»).

Для начала, напомним: хостинг — это услуга по предоставлению ресурсов для размещения файлов на сервере, постоянно находящемся в сети. А вот на каком именно сервере — есть варианты: Shared-хостинг (виртуальный), VPS (Virtual Private Server) — виртуальный выделенный сервер и VDS (Virtual Dedicated Server) — виртуальный частный сервер.

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

Виртуальный приватный и выделенный сервер — это практически одно и тоже по возможностям настройки: можно поставить нужный софт. На Shared-хостинге, если вам надо поставить генератор PDF-документов на сайт, — не выйдет, если захотите там сменить поисковый движок на Sphinx — тоже, скорее всего, не прокатит. Зато на VPS и Dedicated — легко.

Отличия двух последних видов: VPS это как квартира в многоэтажке, а Dedicated — как собственный дом. Dedicated-сервер — большой и мощный по ресурсам, но просто так расширить их нельзя (отжать территорию у соседа не получится — только покупать новый участок для застройки).

С VPS-сервером за счет того, что он виртуальный, практически всегда можно переключиться на более дорогой тариф с большим количеством ресурсов, при этом на самом сервере не придётся ничего перенастраивать (пополнение в семье — сними квартиру в той же многоэтажке, только побольше). Хотя бывают исключения — наращивание мощности можно делать только в рамках одной линейки тарифов и без смены технологии виртуализации (это движок, который позволяет имитировать на одном сервере — несколько операционных систем). Чаще всего VPS используют на мелких и средних проектах, а на масштабных (вроде интернет-магазина «Орматек») — лучше Dedicated.

Кроме того, очень популярны облачные серверы — объединённая система серверов, на которых располагается проект: выделяемые мощности не ограничиваются одним сервером, а распределяются сразу между несколькими серверами. Их обычно содержат крупные, технологичные игроки рынка вроде Amazon или Яндекс.Облака.

Плюс облачного сервера — чаще всего с ним можно работать через API: он предоставляет интерфейс, и можно написать нужный скрипт, чтобы регулировать нагрузку на сервер. Например, скрипт будет автоматически запускать дополнительные 1−2-3 сервера в зависимости от времени суток для более быстрой обработки запросов пользователей (если количество юзеров сайта сильно разнится в течение суток).

Минус облачных серверов — они дороже, чем VPS. Тарификация часто почасовая, и стоимость работы 24 часа в сутки за месяц выходит в 2−3 раза дороже, чем у аналогичных по ресурсам VPS-серверов. Зато, когда вам не нужны дополнительные ресурсы, вы их и не оплачиваете. Но в целом, облако у нас получалось в 2−3 раза дороже, чем иметь свой сервер (речь про довольно мощные конфигурации с большим количеством трафика).

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

При переезде на новый виртуальный сервер всё просто: вы покупаете более мощный тариф, и вам добавляют ресурса. С Dedicated-сервером такой номер не пройдёт: придётся покупать новый отдельный сервер, настраивать его с нуля, копировать данные со старого сервера на новый (а это уже не тестовый, а весь реальный контент с текущего сайта: миллиарды картинок, огромная база данных и так далее). А ведь всё это требует времени.

Существует несколько принципиально разных стратегий наращивания серверных мощностей. Можно выносить отдельные сервисы на отдельные серверы (например, вынести базу данных на отдельный сервер, но тут важно не проиграть по каналу связи до остальных серверов). А можно вести обработку пользователей на разных серверах, используя механизм балансировки. Кроме того, если мощностей сервера базы станет не хватать, ее также можно распределить по нескольким серверам (например, используя механизм шардирования).

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

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

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

Для настройки сервера нужен полный административный доступ к нему. В Linux администратор называется root-ом или root-пользователем. Соответственно, заказчик при покупке сервера должен передать разработчику логин и пароль от root-пользователя и адрес самого сервера, чтобы разработчики знали, куда подключаться. Доступ к серверу может быть по паролю и по ключу.

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

Мы предпочитаем делать настройку серверов самостоятельно и не очень любим преднастроенные серверы. Исторически, любимая — операционная система Debian (либо Ubuntu как ветка Дебиана) с уже отобранным набором скриптов, которые мы используем на чистом сервере для автоматической установки нужного софта и создания конфигураций и доступов. Плюс подхода с самостоятельной настройкой еще и в том, что наш набор скриптов для настройки централизованно обновляется, если выходит какая-то критическая уязвимость. Хотя вопрос выбора операционной системы («какая лучше») — такой же холиварный, как и какими клавишами менять раскладку.

Битрикс, понимая, что пользователи запускают сайты «как придётся», подготовил набор скриптов и виртуальный сервер BitrixVM с уже настроенными параметрами. Он неплохо сконфигурирован под типовые задачи, а если усилить его собственными дополнительными модулями, получается вообще огонь: и быстро, и чётко. Чаще всего мы дополняем его модулями для генерации PDF-файлов и модулем Google Pagespeed для улучшения производительности (оптимизация картинок и некоторых скриптов).

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

Затем программист проверяет, что все корректно перенесено на рабочий сервер, проверяет все интеграции и работу установленных модулей — и, в общем-то, первичная выкладка проекта на этом заканчивается.

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

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

В общем, при деплое есть риск что-то потерять, и обязательно нужен смоук-тест (тест самого базового функционала, с которым юзер может исполнить свой пользовательский сценарий без проблем). Он нужен, чтобы убедиться, что не отпало что-то крупное, что было задето изменениями.

При частых и ответственных деплоях процедуру лучше вообще польностью автоматизировать. Для этого придуманы подходы continuous integration и continuous delivery. Важно автоматизировать рутину, чтобы исключить человеческий фактор. Покрыть автоматическими тестами критические части проекта. Однако этот подход целесообразно использовать на очень крупных и постоянно меняющихся проектах, так как он влечет серьезные транзакционные затраты (дорого).

У Гугла рейтинг сайта в поиске уже несколько лет зависит в том числе от параметров самого сайта: скорости его загрузки, адаптации для мобилок, общего веса и отсутствия лишнего контента при загрузке. У нас на серверах автоматически ставится модуль для оптимизации картинок, поскольку основная проблема прохождения Google PageSpeed, из-за которой сайт не попадает в зелёную зону, — слишком большой объем картинок в передаваемом трафике.

Помимо известных форматов для изображений .png и .jpg, не так давно появился формат .webp, который поддерживается не всеми браузерами (фактически сейчас только Safari и старые версии IE с ним не дружат). Плюс в том, что на большей части картинок он экономит немного места, а на некоторых графических файлах (одноцветных, с прозрачными областями) экономия места получается значительная. Например, png-файл с прозрачностью, который весит 200 Кб, в формате .webp может весить всего 20 Кб.

Но поскольку некоторые браузеры .webp не поддерживают, приходится хитрить: олдскульным браузерам отдавать картинки в старых форматах, а тем, кто уже в теме, — отдавать в .webp. Так вот, вышеупомянутый модуль понимает, какой перед ним браузер, и может на лету конвертировать картинку, чтобы сделать её меньшей по весу.

Если мы используем Shared-хостинг, и модуль для оптимизации поставить там невозможно, то GPS может дать баллов 30 — только потому, что картинок на сайте на 5 Мб. Но если использовать VPS-сервер и настроить на нем оптимизацию изображений, можно легко оказаться в зеленой зоне (от 80 баллов).

Вторая распространенная проблема с GPS после большого объёма картинок — слишком тяжелый JavaScript. И об оптимизации скриптов должны думать программисты, и уже начиная с этапа вёрстки. Если на сайт установлена куча метрик, счетчиков, дополнительных чатов или коллтрекеров — в зеленую зону GPS выйти не получится, потому что все эти скрипты занимают миллисекунды/секунды/десятки секунд работы процессорного времени при открытии сайта. Гуглу это сильно не нравится.

В нашей практике очень регулярно встречается, что добавленные в ходе экспруатации сторонние скрипты, чатики, метрики и т. д. выводят сайт из зеленой зоны — в красную. Что делать — надо решать по ситуации и исходя из целесообразности каждого скрипта. Если удается убедить заказчика, что какие-то из этих «фишечек» не нужны и только вредят, — это ок. Если так не получается, приходится откладывать загрузку тяжелых скриптов вручную — и тогда они начинают подтягиваться спустя 1−3 секунды после полной загрузки сайта. Это, по сути, «обманка». С метриками такой номер не проходит.

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

Обычно резервные копии делаются по трём причинам:

• защита от неумышленного повреждения — например, когда кто-то случайно удалил инфоблок или заказ;
  
• защита от умышленного повреждения — когда сайт взломали и намеренно удалили с него что-либо;
  
• защита от выхода из строя оборудования — компьютеры всё-таки физические объекты, и у них иногда умирают жесткие диски со всей информацией.
  

Одно из преимуществ Dedicated-серверов перед VPS — у первых обычно не один жесткий диск, а два, которые являются полной копией друг друга (зеркальный raid). Если вдруг откажет один, со второго данные можно восстановить.

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

В Битриксе есть автоматическое создание резервных копий. Если у Битрикса активная лицензия, он может загружать свои бэкапы в свое же облако. Минус — в зависимости от лицензии есть ограничения по месту в этом облаке, и поэтому в нем хранится только несколько последних бэкапов.

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

Обычно мы делаем бэкапы так, чтобы они автоматически хранились на серверах минимум две недели. Раз в неделю делается полный бекап (мастер-бекап), в остальные 6 дней пересохраняются только изменённые файлы относительно этого мастера. Благодаря этому в любой день из этого промежутка всегда можно было откатиться к копии сайта.

Если на сервере много места, можно и «поиграться» с частотой резервного копирования. Если проект крупный, и у него используется более одного сервера (отдельные серверы для базы данных и отдельные для выполнения кода), можно настроить так, чтобы они друг на друга делали резервные копии — и тогда дополнительное место для бэкапов не понадобится.

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

На серверах можно использовать жесткий диск SSD или HDD. Битрикс содержит огромное количество мелких файлов, и SDD куда быстрее работает с ними, чем HDD. Поэтому, если есть возможность, лучше покупать хостинг с SSD.

Для выкладки проекта в сеть важно не только настроить сервер, но и настроить домен, чтобы он вел на этот сервер. В первой части основ мы уже рисовали картинку, как это всё происходит.

Так вот, чтобы браузер знал, куда ему идти при запросе конкретного сайта, на NS-серверах нужно прописать IP-адрес нашего сервера. И чаще всего доступ к NS-серверу — это отдельный доступ, который заказчик либо настраивает сам, либо выдает доступ нам, чтобы мы настроили.

На NS-серверах есть различные типы записей:

Запись о соответствии домена и IP-адреса. Она может настраиваться как для самого домена, так и для поддоменов внутри этого домена. На всякий случай, загляните в инфографику, чтобы понимать, как там всё действительно происходит.

NS-серверы могут быть частью услуги регистратора, иногда — частью услуги хостера, или вовсе быть отдельной услугой. Если это часть услуги регистратора, то в одной панели можно управлять и самим доменом, и его NS-записями. Если это часть уже существующего хостинга, на котором сейчас размещен сайт, — тут все сложнее. Но как правило, бывает, что если вы покупаете хостинг, то хостер автоматически предоставляет место для NS-серверов. Иногда заказчик покупает домен и хостинг без NS-серверов — тогда услугу предоставления NS приходится покупать где-то отдельно.

Если заказчик хочет изредка отправлять автоматические письма со своего домена, свой почтовый сервер не нужен: хостинг можно настроить так, чтобы «прикидывался» доменом и мог отправлять письма, скажем, Гуглу. В этом случае отдельную MX-запись настраивать не нужно: письмо и так дойдёт до адресата. Но на такое письмо невозможно будет прислать ответ.

Если всё-таки нужно именно отправлять письма со своего домена через почтовые сервисы вроде Яндекса или Гугла (чтобы общаться и вести переписку с клиентами), надо либо настраивать отдельный почтовый сервер, либо воспользоваться почтой для домена у той же Яндекс. Почты (бесплатно) или у Gmail (за денежку). И вот здесь уже понадобится MX-запись, в которой будет указан почтовый домен, привязанный к конкретному «почтовику».

Еще один вариант — установить на сервере специальные программы для обслуживания почтового сервера и настроить их. Но это занимает много времени, и объективно не стоит этих усилий. Другие почтовики больше доверяют письмам, отправленным от Яндекса или Гугла, чем письмам от какого-то другого сервера.

Это записи, обеспечивающие безопасность почты.

SPF описывает, кому разрешено отправлять письма этого домена — в ней указывается либо IP-адрес сервера, либо IP-адрес каких-то сторонних почтовых служб (сервисов для рассылок вроде Unisender).

Когда какой-то почтовый сервер получает почту, где указан какой-то домен, он идет на этот домен и проверяет, есть ли там SPF-запись, и смотрит, кому разрешено отправлять письма, «прикидываясь» этим доменом. Если источник попадает в этот список — гуд, письмо «хорошее». Если SPF-запись не настроена, либо там не указан IP-адрес — очень высока вероятность, что письмо попадет в спам.

DKIM — это криптографическая подпись письма. Каждое отправляемое сервером письмо шифруется криптографическим ключом. В этой записи содержится его публичная часть: почтовик получил письмо, проверил подпись публичной части, если она совпадает — значит этот точно тот сервер.

Бывает, что на проекте SPF-запись не настраивают: спам никто не рассылает, письма шлют изредка, почтовики сайту доверяют. К заказчику приходят SEO-шники и говорят, что хотят настроить регулярные рассылки через сервис — и для этого настраивают SPF, где прописывают нужный сервис для рассылок. Из-за этих изменений доверие почтовиков к письмам падает, и все любовно приготовленные рассылки начинают попадать в спам. Поэтому, если есть доступ к NS-серверам, лучше SPF-записи настраивать сразу. В любом случае необходимо настраивать SPF корректно, причем вместе с DKIM и, возможно, DMARC.

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

HTTPS-шифрование — это end-to-end несимметричное шифрование. Когда пользователь отправляет запрос, на его стороне тот шифруется, и далее на сервер передаются зашифрованные данные, где они расшифровываются. Никто не сможет вклиниться в процесс передачи этой информации и украсть её. Это особенно полезно, когда вы сидите через открытый wi-fi в какой-нибудь кафешке. Также это защитит от недобросовестных действий со стороны провайдера либо государства :) По HTTPS можно понять, к какому домену вы обращаетесь, но неясно, какую страницу вы запрашиваете и какие данные вы передаете. Так вот, за HTTPS-шифрование как раз отвечают SSL-сертификаты.

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

Но несколько лет назад появился сервис Let's Encrypt, который предоставляет бесплатные сертификаты почти кому угодно. Для большей части сайтов достаточно простого шифрования без какого-либо подтверждения. Подтверждение раньше бывало разным — либо в адресной строке появлялся зеленый замочек, либо высвечивалось зеленым название организации плюс замочек. Сейчас от этого постепенно отказываются: теперь любой шифрованный сайт помечается иконкой зеленого замочка.

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

Сам SSL-сертификат — это просто сгенерированный ключ из двух половинок. Чтобы его получить, совершенно непонятно, зачем платить тысячи и десятки тысяч рублей в год. По факту вы платите только за то, что сделали это через организацию, которой все доверяют. При этом Let's Encrypt — тоже доверенная компания, но она выпускает их бесплатно. Но есть и минусы. Например, ограниченный срок сертификата (3 месяца) — частая смена обусловлена безопасностью.

С wildcard-сертификатами для поддоменов сложнее — чтобы получить подтверждение для них, надо в NS-серверах добавлять дополнительную TXT-запись специального вида. И тогда программа, установленная от Let’s Encrypt и запущенная на сервере, должна иметь доступ к редактированию NS-сервера (менять его через API). Такая возможность есть на крупных регистраторах (чаще американских), вроде GoDaddy. Большая часть российских такого доступа не предоставляют.

Если проект сначала запустился на одном домене, а потом заказчик внезапно понял, что ему нужны поддомены по городам, ему, скорее, всего придется покупать новый wildcard-сертификат (потому что «расширить» его нельзя, только выпустить заново).

Если вы, прочитав обе части нашего технического ликбеза, всё равно чувствуете себя не слишком уверенно в роли руководителя проектов, — не беда. Издательская группа ЭКСМО выпустила книгу Владимира Завертайлова «Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий»: 700+ страниц текста с классными иллюстрациями. Или подписывайтесь на наш YouTube-канал: там постоянно появляются новые полезные видео.