Обслуживание и обновления

Инфраструктура не заканчивается на моменте установки. Любой сервер, сервис, сайт, облако, reverse proxy, система мониторинга или сетевой узел нужно обслуживать: обновлять, проверять, документировать и иногда восстанавливать после ошибок.

В домашней инфраструктуре обслуживание особенно важно. Здесь часто нет отдельной команды администраторов, дежурной смены и формального регламента. Поэтому порядок должен быть простым, понятным и удобным для владельца.

Главная идея простая: изменения нужно вносить так, чтобы после них было понятно, что изменилось, что проверить и как вернуться назад.

Почему обслуживание важно

Многие системы ломаются не потому, что были плохо установлены, а потому что со временем их перестали обслуживать.

Сервис может долго работать без внимания, но постепенно появляются риски:

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

Обслуживание нужно не для того, чтобы постоянно трогать работающую систему. Оно нужно, чтобы система оставалась понятной и управляемой.

Главный принцип

Главный принцип обслуживания FASTRAID LAB:

одно изменение — одна проверка — одна запись в документации.

Это простое правило защищает от хаоса.

Плохой подход — обновить сразу всё, перезапустить несколько сервисов, изменить конфигурацию proxy, поправить firewall и только потом проверять результат. Если что-то сломается, будет сложно понять причину.

Хороший подход — менять систему небольшими шагами.

Сначала сделать backup.
Потом изменить один компонент.
Потом проверить результат.
Потом посмотреть логи.
Потом зафиксировать изменение.
И только после этого переходить к следующему шагу.

Что относится к обслуживанию

Обслуживание — это не только обновление операционной системы. Это весь набор действий, которые поддерживают инфраструктуру в рабочем состоянии.

Область	Что обслуживается
Операционная система	пакеты, безопасность, службы, логи
Web-сервер	конфигурация, HTTPS, маршруты, журналы
Сервисы	версии, состояние, доступность, зависимости
Контейнеры	образы, compose-файлы, volumes, переменные
Хранилище	место, права доступа, структура данных
Backup	успешность копий, возраст, проверка восстановления
Мониторинг	проверки, уведомления, ложные тревоги
DNS	записи, маршруты, внутренние имена
Firewall	открытые порты, правила доступа
Документация	актуальность команд, схем и заметок

Если какая-то часть не обслуживается, со временем она становится источником проблем.

Подготовка перед изменениями

Перед любым важным изменением нужно подготовиться.

Минимальный порядок:

понять, что именно меняется;
проверить текущее состояние;
убедиться, что есть резервная копия;
понять, как откатиться назад;
выполнить изменение;
проверить результат;
посмотреть журналы;
записать, что было сделано.

Это особенно важно для действий, которые затрагивают доступ, данные или запуск сервисов.

К таким действиям относятся:

обновление сервиса;
изменение reverse proxy;
изменение DNS;
изменение firewall;
перенос данных;
изменение прав доступа;
обновление контейнеров;
изменение backup-схемы;
обновление операционной системы;
изменение конфигурации сайта.

Проверка текущего состояния

Перед изменением полезно зафиксировать, что система работает.

Например:

сайт открывается;
HTTPS работает;
сервис отвечает;
backup свежий;
диск не заполнен;
reverse proxy без ошибок;
нужные службы запущены;
мониторинг не показывает критических событий.

Это важно, потому что иногда проблема существовала ещё до изменения. Если не проверить состояние заранее, можно ошибочно решить, что сбой появился из-за новой правки.

Backup перед изменениями

Перед важными изменениями нужна точка возврата.

Backup особенно важен перед:

обновлением сервиса;
миграцией данных;
изменением базы данных;
изменением структуры каталогов;
обновлением контейнеров;
изменением конфигурации reverse proxy;
изменением DNS и внешнего доступа;
обновлением операционной системы;
удалением старых файлов.

Backup не обязан быть сложным. Но он должен давать реальную возможность вернуться назад.

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

Обновления

Обновления нужны для безопасности, совместимости и исправления ошибок. Но обновления должны выполняться осознанно.

Плохой подход:

обновить всё сразу;
не читать изменения;
не делать backup;
не проверять сервисы после обновления;
не смотреть логи;
не фиксировать результат.

Хороший подход:

обновлять по одному важному компоненту;
проверять, что именно меняется;
делать backup перед рисковыми изменениями;
проверять сервис сразу после обновления;
смотреть журналы;
иметь план отката.

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

Откат

Откат — это возможность вернуться к предыдущему рабочему состоянию.

Перед изменением нужно понимать:

какую конфигурацию можно вернуть;
где лежит старая версия;
как восстановить данные;
как перезапустить сервис;
как проверить, что откат помог;
что делать, если откат не сработал.

Если откат не продуман заранее, аварийная ситуация становится намного сложнее.

Особенно важно иметь откат для:

reverse proxy;
DNS;
firewall;
backup;
облачных сервисов;
баз данных;
контейнерных проектов;
web-сайта.

Проверка после изменений

После любого изменения нужно проверить результат.

Минимальный список проверок:

сервис открывается;
HTTPS работает;
нужный домен отвечает;
reverse proxy не возвращает ошибки;
backend доступен;
логи не показывают критических проблем;
мониторинг не показывает новые аварии;
backup не сломался;
пользователи имеют нужный доступ.

Если изменение касалось сайта, нужно проверить не только HTTP-ответ, но и внешний вид страницы.

Если изменение касалось backup, нужно проверить не только запуск задачи, но и наличие новой копии.

Журналы после изменений

После обновления или изменения конфигурации полезно смотреть журналы.

Журналы могут показать проблемы, которые ещё не видны пользователю:

предупреждения;
ошибки доступа;
проблемы с backend;
неверные маршруты;
ошибки сертификатов;
проблемы с правами;
повторяющиеся рестарты;
нехватку места;
ошибки синхронизации.

Хорошая привычка — после изменения не сразу закрывать терминал, а несколько минут посмотреть состояние сервиса.

Регламент обслуживания

Даже в домашней инфраструктуре полезен простой регламент.

Он не должен быть бюрократией. Это просто список регулярных проверок.

Пример еженедельных проверок:

сайт открывается;
основные сервисы доступны;
backup выполняется;
свободное место в норме;
нет failed services;
нет критических ошибок в мониторинге;
сертификаты действуют;
журналы не разрослись слишком сильно.

Пример ежемесячных проверок:

обновления системы;
проверка документации;
проверка восстановления из backup;
пересмотр открытых портов;
проверка DNS-записей;
проверка устаревших сервисов;
ревизия временных решений.

Регламент помогает не забывать важные вещи.

Временные решения

В инфраструктуре часто появляются временные решения. Например, временно открыть порт, временно отключить проверку, временно запустить тестовый сервис, временно изменить маршрут.

Проблема в том, что временное часто становится постоянным.

Поэтому любое временное решение нужно записывать:

что изменено;
зачем;
когда нужно убрать;
какие риски;
как вернуть нормальное состояние.

Временные изменения без записи — частая причина будущих проблем.

Изменения в firewall

Firewall требует особой осторожности.

Перед изменением правил нужно понимать:

какой порт открывается;
кому нужен доступ;
можно ли ограничить источник;
не открывается ли backend напрямую;
есть ли reverse proxy;
как проверить результат;
как отменить правило.

После изменения нужно проверить список правил и убедиться, что не появилось лишнего доступа.

Лучший принцип: наружу открыто только то, что действительно необходимо.

Изменения в reverse proxy

Reverse proxy часто является центральным местом для web-сервисов. Ошибка в его конфигурации может сделать недоступными сразу несколько сервисов.

Перед изменением нужно:

сохранить текущую конфигурацию;
изменить только один маршрут;
проверить конфигурацию;
перезагрузить proxy;
проверить нужный домен;
проверить остальные домены;
посмотреть логи.

Если добавляется новый сервис, важно убедиться, что backend не открыт напрямую и весь доступ идёт через контролируемый маршрут.

Обслуживание сайта

Для статического сайта обслуживание выглядит проще, но оно тоже нужно.

Важно контролировать:

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

После изменения сайта нужно проверять:

успешность сборки;
HTTP-ответ главной;
HTTP-ответ новых страниц;
внешний вид в браузере;
отсутствие битых ссылок в меню.

Сайт — это тоже сервис, просто более простой и устойчивый.

Документирование изменений

После изменения полезно записывать короткую заметку.

Например:

Поле	Что писать
Дата	когда было изменение
Что изменено	краткое описание
Причина	зачем это сделали
Проверка	как проверили результат
Откат	как вернуть назад
Примечания	особенности и проблемы

Такая запись помогает через месяц понять, почему система выглядит именно так.

Частые ошибки

В обслуживании часто повторяются одни и те же ошибки.

Первая ошибка — менять слишком много сразу.

Вторая ошибка — не делать backup перед рисковым изменением.

Третья ошибка — не проверять сервис после обновления.

Четвёртая ошибка — не смотреть журналы.

Пятая ошибка — не фиксировать изменения.

Шестая ошибка — оставлять временные решения навсегда.

Седьмая ошибка — обновлять важные сервисы без плана отката.

Восьмая ошибка — считать, что если команда выполнилась без ошибки, значит всё работает.

Практический результат

Хорошее обслуживание даёт несколько преимуществ.

Во-первых, инфраструктура меньше ломается неожиданно.

Во-вторых, проблемы проще диагностировать.

В-третьих, изменения становятся безопаснее.

В-четвёртых, владелец не зависит только от памяти.

В-пятых, систему проще развивать.

В-шестых, аварии перестают быть хаосом, потому что есть порядок действий.

Итог

Обслуживание — это не отдельная задача после установки. Это постоянная часть жизни инфраструктуры.

Обновления должны быть контролируемыми.
Backup должен быть перед рисковыми изменениями.
Откат должен быть понятным.
Проверка должна выполняться после каждого изменения.
Журналы должны просматриваться.
Документация должна обновляться.
Временные решения должны фиксироваться.

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