99.9% доступности звучит как лозунг, пока не переведёшь проценты во время. В году 8 760 часов; одна десятая процента от них — около 8 часов 46 минут. В пересчёте на месяц — примерно 43 минуты. Это и есть весь запас на сбои, обновления и человеческие ошибки, вместе взятые.
Уложиться в него помогает не редкая технология, а несколько скучных практик, которые соблюдаются каждый день. Расскажем, какие именно.
Доступность — это бюджет
О 43 минутах в месяц удобно думать как о деньгах на счёте. Их тратит всё подряд: перезагрузка после обновления ядра, неудачный релиз, переполненный диск, истёкший сертификат, сбой у магистрального провайдера. Одна долгая перезагрузка сервера с проверкой файловой системы способна израсходовать месячный запас целиком.
Отсюда главный принцип: простой не должен быть неожиданным и не должен быть долгим. Первое решают мониторинг и регламенты, второе — резервирование и отработанное восстановление. Что именно считается простоем и как его измеряют, записывается в договоре — подробнее в статье о том, как читать SLA.
Мониторинг: узнавать раньше пользователей
Мониторинг у нас работает круглосуточно. Но важно не то, что он есть, а то, что именно он проверяет. Мы разделяем три слоя.
- Снаружи. Открывается ли сайт для посетителя: код ответа, время ответа, содержимое страницы. Сервер может быть жив, а сайт — нет.
- Изнутри. Диск, память, нагрузка на процессор, очереди, время ответа базы данных. Эти показатели предупреждают о проблеме за часы и дни: диск заполняется не мгновенно.
- По срокам. Сертификаты, домены, свежесть резервных копий. Самые обидные простои случаются по календарю — и их проще всего предотвратить.
Вторая половина дела — оповещения. Сигнал должен требовать действия; если на него можно не реагировать, его нужно отключить или перенастроить. Система, которая шлёт сотню уведомлений в день, хуже системы без уведомлений: в ней привыкают не читать. Время реакции инженера на настоящий сигнал зафиксировано в договоре — от 30 минут до 4 часов в зависимости от тарифа.
К слову, у нас есть и собственный продукт в этой области — Website Director, сервис мониторинга и аудита сайтов.
Резервирование и восстановление
Любой компонент, который существует в единственном экземпляре, однажды станет причиной простоя. Вопрос в том, что дешевле: продублировать его или быстро восстановить.
Зеркалирование дисков — обязательный минимум: отказ диска рано или поздно случается, а в зеркале его меняют без остановки сервиса. Дальше начинается расчёт. Второй сервер приложений за балансировщиком, реплика базы с автоматическим переключением, резервная площадка — каждая ступень заметно увеличивает и бюджет, и сложность. А сложность сама становится источником сбоев: кластер, который никто не тренировался переключать, надёжности не добавляет.
Не каждому проекту нужен кластер. Каждому нужен проверенный план восстановления.
Поэтому для многих проектов честнее и дешевле один хорошо обслуживаемый сервер с отработанным восстановлением, чем отказоустойчивая схема, которую некому поддерживать.
Резервные копии не повышают аптайм напрямую. Они ограничивают худший сценарий: вместо «данные потеряны» получается «восстановимся за известное время». Мы храним копии вне обслуживаемого сервера и проверяем восстановление — разворачиваем копию и убеждаемся, что из неё поднимается рабочая система. Иначе не узнать главного: сколько времени восстановление займёт на самом деле. Как устроить это у себя — в статье «Бэкапы, которые восстанавливаются».
Изменения по регламенту
Работающая система чаще ломается не сама, а после того, как в ней что-то поменяли. Отказаться от изменений нельзя — обновления безопасности нужно ставить, — значит, изменения нужно сделать предсказуемыми.
- Окно. Плановые работы проводятся в согласованное время, когда нагрузка минимальна, и о них известно заранее.
- План отката. До начала работ записано, как вернуть прежнее состояние и по какому признаку принимается решение возвращаться.
- Проверка на копии. Крупное обновление сначала проходит на тестовом контуре.
- По одному изменению. Если одновременно обновить систему, базу и приложение, причину сбоя придётся искать втрое дольше.
То же относится к релизам приложения. О том, как выкатывать новую версию, не останавливая сервис, — в статье «Деплой без простоев».
Когда всё-таки случилось
Инциденты бывают при любом уровне подготовки. Разница — в том, как на них отвечают. Порядок у нас такой.
- Сначала восстановить сервис. Поиск виноватого и красивое исправление подождут. Если быстрее откатиться — откатываемся.
- Потом найти причину. Не «перезагрузили — заработало», а что именно произошло и почему мониторинг не предупредил раньше.
- Затем сообщить заказчику. Отчёт: что случилось, что сделано, что изменится, чтобы это не повторилось.
- И закрыть причину. Новая проверка в мониторинге, правка в регламенте, изменение в конфигурации. Инцидент, после которого ничего не изменилось, повторится.
Худший вариант для заказчика — узнать о проблеме от собственных клиентов. Лучший — прочитать о ней утром в отчёте, когда всё уже работает.
Что из этого стоит забрать себе
Всё перечисленное не требует ни большой команды, ни дорогого оборудования — только дисциплины. Минимальный набор для любого проекта:
- внешняя проверка сайта с уведомлением человеку, который может что-то сделать;
- контроль диска, сертификатов и срока оплаты домена;
- резервные копии за пределами сервера и восстановление, которое хотя бы раз проводили;
- обновления по расписанию и с планом отката, а не «когда дойдут руки»;
- запись о каждом инциденте: причина, решение, вывод.
Надёжность — это скучно, и так и должно быть. Интересно становится только тогда, когда чего-то из этого списка не оказалось на месте.