Вопросы и ответы

Общие вопросы

Что критически важно для работы любого проекта

Всегда имейте резервную копию, с которой сможете восстановиться. Если нет бэкапов или они нерабочие — вы в любой момент рискуете потерять ваш проект.
Мониторьте важные параметры. Если у вас нет мониторинга, то это не продакшн.
Заботьтесь о безопасности до того, как ваш проект взломают. Это необратимый процесс и о безопасности необходимо думать всегда.
Имейте важные сервисы в нескольких экземплярах, чтобы на них можно было быстро переключиться в случае отказа.
Логируйте работу ваших сервисов. Логи очень помогают во многих ситуациях, они помогут найти ошибки конфигурации, баги, бреши безопасности и подозрительное поведение. Они же помогут спланировать развитие проекта и избежать очень многих проблем еще на старте.
Автоматизируйте всё, что можно автоматизировать. Автоматизацией не только экономите свое время, но и снижаете риски «человеческого фактора». Делайте всю рутину автоматически.
Документируйте ваши действия. Хорошая документация просто необходима, когда над проектом работает более одного человека. Она же поможет при масштабировании сервиса.

Это лишь минимальный список.

Железо (hardware)

Как выбирать сервер?

Скорость работы вашего проекта критически зависит от физической конфигурации сервера. К сожалению, иногда сначала заказывается стандартный сервер, а затем на него ставится софт по принципу «заработает как заработает». Это подход в корне неверный.
Конфигурацию сервера необходимо выбирать в зависимости от задач и ожидаемой нагрузкой. Обычно типовых конфигураций, предлагаемых хостерами, хватает для решения большинства проектов. Чтобы определиться с конкретной конфигурацией необходимо:

Определиться с задачами, которые будет решать сервер и планируемой нагрузкой (количество клиентов, CPU, RAM, место на диске, скорость сети),
По возможности попытаться определить «узкие места», которые будут лимитировать производительность. Если проект уже работает на каком-то сервере,, то лучший способ узнать лимитирующие факторы — проанализировать данные мониторинга. По минимуму это: CPU, RAM, I/O (input-output), нагрузку на БД и код.

Некоторые физические параметры сервера после установки будет изменить невозможно, поэтому к вопросу стоит подойти серьезно.

Имеет ли смысл использовать на сервере SSD?

SSD дает желаемый результат в скорости работы на очень узком круге задач. Он будет полезен в задачах, где требуется много случайного чтения. В остальных случаях оптимальнее использовать производительный RAID и увеличить объем ОЗУ. Причина — Page cache. На эту тему можно посмотреть и экспериментальные картинки.

Чем различаются shared hosting, VPS, VDS, dedicated server?

Публичный хостинг (shared hosting) — вид хостинга, при котором веб-сайты разных клиентов расположены на одном веб-сервере. Вам выделяется определённое место на HDD, количество баз данных MySQL, FTP, e-mail аккаунты и ограничивается нагрузка на ЦП. Преимущество этого типа хостинга: низкая цена. Основные недостатки:

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

VPS (virtual private server) и VDS (virtual dedicated server) — это способы хостинга (и не только хостинга) основанные на виртуализации. При этом под VPS обычно (но не всегда) понимается виртуализация на уровне ОС, VDS — полная виртуализация. Оба типа виртуализации позволяют:

Устанавливать свое ПО и делать свои настройки к нему.
Иметь отдельный ip-адрес только для своего виртуального сервера.
Обезопасить находящийся на сервере контент с помощью более тонких настроек софта, настройки firewall, разделения прав доступа.

Полная виртуализация обычно оказывается лучше виртуализации ОС для контейнера со сходными номинальными параметрами. В полной виртуализации ресурсы действительно гарантированны и там же обычно ниже нагрузка на ввод-вывод (input-output). Услугу полной виртуализации обычно можно легко отличить по возможности установки в контейнер любой операционной системы, тогда как при виртуализации уровня ОС доступна лишь одна версия ядра ОС и модулей к ней. Поэтому, VDS с полной виртуализацией обычно предпочтительнее VPS, даже если у последних выше номинальные параметры.

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

Имеет ли смысл использовать software-RAID взамен fake-RAID на дешёвых материнских платах?

На простых материнских платах часто имеется возможность создания «RAID». Однако, железа на материнской плате для этого не хватает, поэтому фактически это будет эмуляция RAID, которая работает под драйверами материнской платы. Такой RAID имеет некоторый смысл для резервирования информации, но не приносит никакого результата для производительности: запросы на большинстве таких драйверов идут попеременно к дискам и не распределяются. В плане резервирования целесообразность использования такого RAID тоже сомнительна — в случае падения процедура восстановления оказывается не проще, чем в software-RAID.
По вышеуказанным причинам использовать fake-RAID не имеет смысла. Если требуется производительность или резервирование, но не хватает денег на железный (hardware-RAID), лучше собрать software-RAID. Управляемость, устойчивость и переносимость конфигурации у него будет точно не хуже fake-RAID.

Софт (software)

Какую операционную систему поставить на сервере?

У тройки наиболее популярных серверных операционок (Linux, BSD, Windows) есть существенные различия и эти ОС в разной степени пригодны для разных задач. С другой стороны, качество настройки операционной системы тоже может сильно различаться. Имеет смысл полагаться на два основных критерия:

Задачи и роли сервера. Под некоторые задачи лучше подходит Windows, под какие-то — BSD или Linux. Часть задач (например, многие сетевые) лучше решать специализированным «железом» (hardware).
Качество настройки и администрирования. В общем случае лучше иметь качественно настроенный и легко управляемый сервер, пусть и не оптимального выбора ОС (и софта) под задачу, чем что-то сложноуправляемое и неподдерживаемое. Необходимо учитывать, как объективные стороны ОС (гибкость в настройке, поддержка, своевременность и удобство обновлений), так и субъективные: насколько грамотно сможете настроить выбранную ОС под задачу.
Возможность масштабирования и интеграции. Хороший сервис через некоторое время потребует увеличения аппаратных и программных ресурсов, поэтому заранее стоит предусмотреть пути масштабирования и интеграции с другими системами.

Какой выбрать дистрибутив Linux?

Как и в предыдущем вопросе, лучше иметь качественно настроенный и хорошо администрируемый сервер на любом из дистрибутивов, чем оптимизированный, но которым непонятно как управлять. Тот же принцип относится и к прикладному софту и настройкам: если умеете работать только с помощью панелей управления (вроде ISP Manager, DirectAdmin, cpanel, Plesk, etc) — имеет смысл работать именно в них, несмотря на невысокую скорость. Если настраивать самостоятельно — целесообразно выбрать дистрибутив с более удобной вам системой конфигов или по которому можете получить лучшую поддержку.

Сеть

Имеет ли смысл использовать CDN?

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

Безопасность (security)

От чего нужно защищать сервер?

Среди основных причин, которые могут привести к взлому, можно выделить следующие:

Уязвимости используемого программного обеспечения и кода проекта,
Небезопасная конфигурация программного обеспечения,
Человеческий фактор.

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

Как обезопасить доступ на сервер?

Наилучший способ — ограничить доступ по IP-адресам к критически важным компонентам (ssh, ftp, админки, …), работать с которыми должен только определённый круг лиц. Этот способ в отличие от защиты с помощью паролей-ключей имеет следующие преимущества:

Слабо чувствителен к внутренним уязвимостям защищаемых компонент. Можно иметь дырявую админку для внутреннего пользования и не беспокоиться о возможности взлома её из «широкого интернета».
Защищает от сканирования на уязвимости.
Уменьшает роль человеческого фактора. Ненамеренная компрометация пары логин-пароль не так опасна, если её некуда применить. Также, если испортились отношения с кем-то из сотрудников, использовать реквизиты для входа при ограниченном доступе будет очень проблематично.

Естественно, ограничение по IP-адресам не должно быть единственным способом защиты. Пароли должны быть сильными. А ещё лучше использовать несимметричные ключи (например, RSA). И поменьше пользоваться незащищёнными протоколами, вроде ftp для передачи важных данных.

FTP or not FTP? Использовать ли FTP доступ к сайту?

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

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

Можно ли сделать FTP побезопаснее? Да. Например, ограничить доступ по ip-адресам (что полезно и во многих других случаях).
Еще лучше использовать безопасные протоколы SSH/SCP, SFTP. Они передают данные в шифрованном виде и из их менее распространенных клиентов реже воруют пароли. Эти протоколы обычно оптимальный выбор для работы с контентом.

Нужен ли SSL-сертификат?

SSL-сертификат на сайте обеспечивает защиту информации от пользователя к серверу и обратно от перехвата и подмены. Поэтому, если ваш сайт проходит ежедневно масса конфиденциальной информации, имеет смысл купить сертификат. Даже если на сайте просто имеется вход по логину-паролю, то уже стоит заказать SSL-сертификат, поскольку без него все данные легко прослушиваются на любом промежуточном хосте. Или в незащищённой беспроводной сети. То же самое относится и к почте, если по ней работать по незащищённому каналу.
Кроме этого, в последнее время стало популярно подмешивать рекламу в «бесплатных» публичных беспроводных сетях. Избежать этой подмены и добиться загрузки сайта в первоначальном виде у любого пользователя тоже поможет SSL.
Для шифрования информации по каналу связи достаточно не заверенного центром сертификации (самоподписанного) сертификата. Однако, на публичных сервисах лучше использовать подписанные сертификаты.

Как, какие и в каком количестве делать бэкапы?

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

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

RAID, реплики БД и другие «зеркальные» средства реального времени бэкапом не являются, поскольку не защищают от ошибок пользователей и вредного кода.

Чем протестировать безопасность

Тест для SSL
[пополняется]

Производительность

Чем можно проверить скорость открытия сайта?

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

Стоит отметить, что не всё, что предлагают подобного рода сервисы нужно воплощать в жизнь. Это автоматические проверки, они предлагают в том числе и трудоёмкие способы, которые не принесут ожидаемого прироста скорости. С другой стороны, они не «знают» специфики вашего проекта.