Ежемесячный отчёт о состоянии сервера: одна страница для заказчика

MAATRIX

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

Зачем формальный отчёт, если и так всё работает

Первое возражение, которое звучит от инженеров: «зачем тратить час на бумажку, если можно потратить его на реальную работу?». Возражение справедливое ровно до момента, когда у заказчика появляется вопрос «а вы вообще там что-то делаете?» — и ответить на него нечем, кроме «ну, всё же работает».

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

Есть и вторая причина, более прагматичная. Отчёт — это единственный документ, к которому можно вернуться через полгода при споре о бюджете, продлении договора или разборе претензии. Если в феврале в отчёте написано «диск заполняется быстрее прогноза, рекомендуем апгрейд в течение квартала», а в мае диск действительно переполнился — это не «мы не предупреждали», а «мы предупреждали, вот дата». Разница в таком споре о том, кто виноват в простое, огромная.

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

Что попадает на одну страницу: пять блоков без лишнего

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

Структура, которая закрывает почти любой запрос заказчика:

1. Доступность за месяц — одно число и одна фраза о том, что оно значит.
2. Критические события — были или нет, и если были — что случилось и как решили.
3. Что сделано за месяц — коротко, без списка тикетов, только то, что относится к стабильности и безопасности.
4. План на следующий месяц — 2-4 пункта, которые заказчику стоит знать заранее.
5. Риски, требующие внимания или бюджета — если они есть; если нет, так и написать.

Ниже — шаблон, который можно адаптировать под конкретный проект:

ОТЧЁТ О СОСТОЯНИИ СЕРВЕРА — АВГУСТ 2026

Доступность сервиса: 99,95% (простой ~22 минуты за месяц)
Статус: в пределах нормы, без влияния на бизнес-показатели

КРИТИЧЕСКИЕ СОБЫТИЯ
15 августа, 02:14-02:31 — недоступность личного кабинета из-за сбоя
базы данных после планового обновления. Устранено откатом версии,
клиенты не почувствовали влияния (ночное время, низкая нагрузка).
Причина зафиксирована, добавлена проверка перед будущими обновлениями.

СДЕЛАНО ЗА МЕСЯЦ
- Обновления безопасности установлены без простоя
- Резервные копии проверены восстановлением на тестовом стенде
- Расширено дисковое пространство под рост базы данных

ПЛАН НА СЕНТЯБРЬ
- Перенос почтовой очереди на отдельный сервер (снизит риск
  влияния рассылок на основной сайт)
- Плановое окно обслуживания 12 сентября, 02:00-03:00 (уведомим
  заранее)

РИСКИ И БЮДЖЕТ
Текущий тариф сервера рассчитан на нагрузку до конца года.
При сохранении темпа роста трафика (сейчас +12% в месяц)
потребуется апгрейд в IV квартале — обсудим за 3-4 недели
до необходимости.

Заметьте: в шаблоне нет ни одной команды, конфига или упоминания конкретного ПО. Это осознанное решение — отчёт для заказчика и внутренний postmortem для команды это два разных документа, и смешивать их не стоит.

Доступность за месяц: как не соврать процентами и не запугать ими же

Самая частая ошибка — писать «uptime 99,95%» и считать, что это самодостаточная фраза. Для инженера она читается мгновенно, для владельца бизнеса — нет: он не хранит в голове таблицу перевода процентов в минуты простоя. Разница между 99,9% и 99,95% на слух кажется малозначительной, а по факту это разница между 43 и 22 минутами простоя в месяц — почти вдвое.

Полезно всегда указывать вместе с процентом абсолютное время простоя и, если это уместно, — было ли оно в рабочие часы или ночью. «22 минуты простоя, из них 17 — в 3 часа ночи в воскресенье» звучит совсем иначе, чем «22 минуты простоя» без контекста, хотя число одно и то же.

Не нужно бояться показывать метрику, которая ухудшилась — важно сразу дать её значение и план. Более полное объяснение того, почему сам процент SLA редко говорит всё, что нужно знать заказчику, разобрано в статье о мифе про SLA 99,99% — полезно как справочный материал, если заказчик спросит «а что вообще значит наш SLA».

Критические события: что считать критическим и как их описывать

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

Для описания инцидента в отчёте для заказчика работает простая структура из трёх предложений: что случилось (без техдеталей), как долго это длилось и на кого повлияло, что сделано, чтобы это не повторилось. Никаких stack trace, названий процессов или команд восстановления — это язык другого документа.

Сравните:

• Технически точно, но не для заказчика: «В 02:14 UTC процесс postgres упал с OOM после миграции схемы, wal-файлы переполнили /var/log, systemd перезапустил сервис через 40 секунд, но connection pool приложения не переподключился автоматически».
• Для отчёта заказчику: «15 августа ночью личный кабинет был недоступен 17 минут из-за сбоя базы данных после планового обновления. Клиенты не пострадали благодаря ночному времени. Причина устранена, добавлена дополнительная проверка перед будущими обновлениями».

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

План на следующий месяц: не список задач, а то, что касается заказчика

Здесь легко скатиться в перечисление внутреннего бэклога: «обновить версию ядра, пересмотреть cron-задачи, почистить старые Docker-образы». Для инженера это осмысленная работа, для заказчика — шум, за которым не видно, зачем он это читает.

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

Хороший пункт плана отвечает на вопрос «а что мне с этим делать» — даже если ответ «ничего, просто держим вас в курсе»:

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

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

Риски и бюджет: как говорить о деньгах до того, как это стало пожаром

Раздел про риски — самый ценный и самый часто пропускаемый. Пропускают его по понятной причине: сказать «через два месяца потребуется апгрейд, это будет стоить X» неприятнее, чем промолчать и решить вопрос, когда он станет неизбежным. Но именно этот раздел отличает партнёра, которому доверяют, от подрядчика, которого терпят.

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

Формулировка риска работает лучше всего по схеме «что происходит → что будет, если не вмешаться → когда нужно решение»:

• «Трафик растёт на 12% в месяц третий месяц подряд. При сохранении темпа текущего тарифа хватит примерно до конца ноября. Апгрейд стоит обсудить в течение сентября-октября, чтобы избежать спешки».
• «Текущая схема резервного копирования не покрывает восстановление за последние 24 часа — при инциденте в конце дня возможна потеря дневных данных. Обсудим переход на более частое резервирование».

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

Как выстроить процесс, чтобы отчёт не был разовой затеей

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

Практические привычки, которые держат процесс живым:

• Фиксировать факты по ходу месяца, а не в последний день. Заведите файл или страницу в трекере, куда любой из команды одной строкой добавляет событие сразу после того, как оно произошло: «15.08 — сбой БД после обновления, 17 минут». В конце месяца остаётся собрать эти строки в структуру, а не вспоминать их из логов.
• Фиксированная дата, а не «когда будет время». Первый рабочий день месяца или последняя пятница — не так важно, какая именно, важно, что она не плавает: плавающая дата — первый шаг к тому, что отчёт вообще перестанет выходить.
• Один человек отвечает за отчёт, даже если пишет команда. Не обязательно самый старший инженер — это может быть тот, кто лучше остальных переводит технические детали на язык бизнеса.
• Шаблон, а не чистый лист каждый раз. Одна и та же структура месяц за месяцем экономит время и позволяет заказчику быстро находить нужный раздел, не читая заново всю страницу.
• Архив прошлых отчётов доступен заказчику. Даже папка с файлами по датам превращает единичный отчёт в историю, по которой виден тренд — растёт ли число инцидентов, ускоряется ли рост инфраструктуры.

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