Еженедельный регламент обслуживания: 40 минут в пятницу вместо аврала в понедельник

MAATRIX

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

Зачем нужен отдельный недельный слой, а не только обход и ТО

У обслуживания сервера должно быть три разных горизонта, и путать их — прямой путь либо к перегрузке, либо к слепым зонам.

Ежедневный обход (5-10 минут) отвечает на один вопрос: всё ли работает прямо сейчас. Он смотрит на текущее состояние — снимок, а не тренд. Свежие бэкапы за сутки, доступность сервисов, место на диске в моменте.

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

Между ними — вопросы, для ответа на которые нужна неделя данных, но которые не могут ждать месяц:

• Аномалия в логах, которая не видна за один день, но видна за семь.
• Тренд роста диска или памяти — по одной точке тренд не построить.
• Накопившиеся security-патчи, которые пока не критичны, но откладывать их до ежемесячного ТО — уже риск.
• Изменения в конфигурации, которые кто-то внёс на ходу и забыл зафиксировать — через месяц никто не вспомнит контекст.

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

Логи за неделю: аномалии, а не гигабайты (8 минут)

Цель — не прочитать все логи за неделю (это нереально и не нужно), а найти то, чего не было раньше или стало заметно больше.

Сначала — сводка по уровню ошибок за весь период разом:

journalctl --since "-7 days" -p err..alert --no-pager | less

Дальше — то, что обычный обход не считает, потому что там смотрят на «сейчас», а не на сумму за неделю. Количество неудачных попыток входа по SSH:

journalctl --since "-7 days" -u sshd | grep -c "Failed password"

Если за неделю их 40 — это фон интернета. Если 4000 — кто-то целенаправленно перебирает пароли, и это повод проверить fail2ban и, возможно, ужесточить правила.

Поиск OOM-killer — процессов, убитых нехваткой памяти, за неделю проще искать разом, чем ловить в моменте:

journalctl --since "-7 days" | grep -i "out of memory\|oom-kill"

Полезная привычка — вести простой файл с сигнатурами ошибок, которые уже видели и разобрали:

journalctl --since "-7 days" -p err --no-pager | \
  grep -oE '[A-Za-z_]+Error|[A-Za-z_]+Exception' | sort -u > /tmp/errors-this-week.txt
diff /var/log/known-errors.txt /tmp/errors-this-week.txt

Diff покажет только новые типы ошибок — те, что вы ещё не видели и не решили, что с ними делать. Именно это экономит время: не перечитывать знакомое, а замечать новое. Более подробно про разбор логов и поиск причины сбоя — в статье как читать логи и находить причину сбоя.

Бэкапы за неделю: восстановимость, а не «процесс завершился» (10 минут)

Ежедневный обход обычно проверяет факт: бэкап за сутки создался, файл не нулевого размера. Этого достаточно для утра, но недостаточно для недели — «процесс завершился с кодом 0» и «данные внутри читаемы» это разные утверждения.

Раз в неделю имеет смысл сделать то, что каждый день делать накладно: реальную частичную проверку восстановимости. Для restic — быстрая проверка целостности репозитория без скачивания всех данных:

restic check --read-data-subset=10%

Для borg — аналогично, с выборочной проверкой архивов:

borg check --verify-data /path/to/repo::latest

Для дампов БД — не просто наличие файла, а то, что он реально разворачивается. Возьмите дамп за неделю и восстановите его в тестовую базу:

createdb test_restore_check
gunzip -c /backups/db-$(date +%F).sql.gz | psql test_restore_check
psql test_restore_check -c "SELECT count(*) FROM users;"
dropdb test_restore_check

Если запрос отработал и вернул разумное число строк — бэкап живой не только на бумаге.

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

du -sh /backups/*.sql.gz | tail -7

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

Ресурсы и тренды роста: смотреть на кривую, а не на снимок (8 минут)

df -h и free -m в моменте отвечают только на вопрос «сколько свободно сейчас». Для тренда нужна точка сравнения — поэтому стоит вести короткий лог метрик, который пополняется каждую пятницу одной строкой:

{
  echo "$(date +%F) $(df -h / --output=pcent | tail -1 | tr -d ' %') $(free -m | awk '/Mem:/{print $3}') $(ss -s | awk '/estab/{print $2}')"
} >> /var/log/weekly-metrics.log

Через несколько недель такой лог даёт возможность считать не абсолютное число, а скорость роста:

Рост диска на 2-3 п.п. в неделю — это не авария сегодня, но при такой скорости до заполнения остаётся примерно 10 недель, и это уже повод спланировать расширение заранее, а не разбираться с этим ночью, когда место кончится. Точный темп у вас будет свой — ориентируйтесь на собственные цифры, а не на этот пример.

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

du -sh /var/log/* /var/lib/docker/* 2>/dev/null | sort -rh | head -10

Чаще всего виновник — логи без ротации, старые образы Docker или незамеченный core dump. Это тот самый разрыв между обходом (место есть) и месячным ТО (когда уже поздно) — недельная проверка ловит проблему на стадии тренда, а не на стадии инцидента.

Pending security-обновления: закрыть окно, не открывая нового (7 минут)

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

На Debian/Ubuntu — что реально накатилось за последнее время:

grep "^20" /var/log/unattended-upgrades/unattended-upgrades.log | tail -20
cat /var/run/reboot-required 2>/dev/null && echo "нужен перезапуск"

Что осталось необновлённым — включая пакеты, которые автоматика намеренно не трогает (major-версии, hold-пакеты):

apt list --upgradable 2>/dev/null
apt-mark showhold

На AlmaLinux/RHEL — список именно security-обновлений отдельно от прочих:

dnf updateinfo list security
dnf updateinfo summary

Ключевой вопрос недельной проверки не «применились ли обновления» (это должна показывать автоматика), а «висит ли что-то, что автоматика не закрывает». Обычно это: пакеты на hold, требующие ручного вмешательства из-за возможной несовместимости; обновления, которые требуют перезапуска сервиса (не системы) — они не попадают в reboot-required; CVE, для которых патч ещё не вышел, но есть временный workaround, который вы отслеживаете отдельно. Разбор частых ошибок автообновлений безопасности и того, что именно стоит проверять руками — в статье автообновления безопасности на сервере: частые ошибки и решения.

Что изменилось в конфигурации за неделю (7 минут)

Самая недооценённая часть регламента. За неделю кто-то (включая вас самого в момент разбора инцидента) правит nginx.conf, добавляет cron-задачу, меняет лимит в systemd-юните — и это не попадает ни в какой трекер, потому что «это же мелочь, я потом занесу в документацию». Через месяц никто не вспомнит, зачем это изменение появилось.

Если /etc уже под git через etckeeper — недельная проверка тривиальна:

cd /etc && sudo git log --since="7 days ago" --oneline
sudo git diff HEAD@{7.days.ago} -- nginx/ | head -60

Если etckeeper не настроен, минимальная версия — запустить его один раз:

apt install etckeeper && etckeeper init && etckeeper commit "baseline"

С этого момента каждое изменение в /etc через apt-хуки коммитится автоматически, и через неделю у вас уже есть история для diff. Без git — грубый, но рабочий вариант: сравнение хэшей файлов пакетов с эталоном через debsums, чтобы найти то, что отличается от версии из пакета:

debsums -c 2>/dev/null

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

Почему пятница, а не понедельник

Это не догма, а расчёт на конкретное свойство пятничного вечера — впереди два дня, когда трафика и рискованных изменений обычно меньше, но реагировать на находки всё ещё можно спокойно, при свете дня, а не в панике.

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

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

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

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

Частые вопросы