Обслуживание одного сервера в человеко-часах за год: честный замер

MAATRIX

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

Почему интуитивная оценка почти всегда врёт

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

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

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

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

Категория 1: рутинные обновления безопасности

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

Типичный цикл для одного сервера на Debian/Ubuntu с unattended-upgrades:

# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Автоматика снимает рутинное применение патча, но не снимает три вещи, которые всё равно требуют человека:

• Проверку после обновления — зашёл ли сервис после релоада/ребута, не изменилось ли поведение зависимостей, нет ли новых предупреждений в логе автообновления (/var/log/unattended-upgrades/unattended-upgrades.log).
• Разбор изменений вручную, когда пакет не попадает под автоматическое правило — например, мажорное обновление PHP, PostgreSQL или ядра, которое сознательно исключено из автопатча, чтобы не сломать прод без контроля.
• Ротацию сертификатов и её проверку — даже с certbot renew в cron раз в квартал стоит вручную свериться, что nginx перечитал новый сертификат, а не продолжает отдавать старый из кэша воркера.

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

Категория 2: реактивное решение проблем

Это непредсказуемая часть, и именно она чаще всего искажает интуитивную оценку. Сюда входит всё, что случилось без предупреждения и потребовало вмешательства: сайт лёг, диск заполнился, сертификат не обновился и упал HTTPS, процесс съел всю память, кто-то ломится по SSH перебором, приложение начало возвращать 500-е.

Ключевая характеристика этой категории — распределение с тяжёлым хвостом. Большинство инцидентов — это 15–30 минут: увидел алерт, посмотрел лог, перезапустил сервис, убедился, что не повторится. Но раз в несколько месяцев случается что-то, что съедает полдня или больше: разбор скомпрометированного сервиса, восстановление из бэкапа после испорченных данных, поиск утечки памяти, копившейся неделями. Посчитаете только среднее за короткий период — легко попасть в затишье и получить заниженную цифру; захватит наблюдение один крупный инцидент — среднее взлетит в другую сторону.

Практический подход к замеру:

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

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

Категория 3: плановые задачи — аудит, оптимизация, апгрейды

Это работа, которая не горит, но без неё реактивная категория со временем растёт: периодический аудит конфигурации (открытые порты, неиспользуемые сервисы, устаревшие правила файрвола), планирование ёмкости диска заранее, тестовое восстановление из бэкапа (не «бэкап есть», а «бэкап реально разворачивается»), мажорные апгрейды ОС и СУБД, разовая оптимизация конфигурации под текущую нагрузку.

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

Ориентировочный список того, что стоит проверять на регулярной основе (частоту определяете сами исходя из критичности сервиса):

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

Категория 4: мониторинг — время, которое не видно

Здесь скрыта, пожалуй, самая недооценённая часть трудозатрат. Мониторинг — это не только настройка дашбордов и алертов (разовая работа из категории 3), но и постоянное, размазанное по неделям время на то, чтобы смотреть: заглянуть в Grafana, проверить, что алерт не тихо сломался, пролистать логи, даже если формально всё зелёное.

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

Для честного замера этой категории полезны две вещи:

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

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

Как вести журнал: методика на месяц-два

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

Минимальный набор столбцов, который покрывает все четыре категории:

дата, категория, время_начала, время_конца, минут, задача, заметка
2026-08-04, monitoring, 09:12, 09:14, 2, "проверка Grafana", ""
2026-08-04, routine, 14:00, 14:20, 20, "патч-цикл, проверка после апдейта", ""
2026-08-06, incident, 22:40, 23:35, 55, "диск 95%, чистка логов", "root cause: logrotate не подхватил новый юнит"
2026-08-11, planned, 10:00, 11:30, 90, "аудит открытых портов", "нашли забытый dev-порт 8080"

Это может быть обычный CSV-файл, таблица в Google Sheets или заметка в текстовом редакторе — инструмент вторичен, важна дисциплина заполнения в момент, когда время потрачено, а не задним числом. Практический приём — быстрая функция, которая одной командой дописывает строку с текущим временем, а длительность и заметку вы дозаполняете постфактум в течение дня:

logtime() {
  echo "$(date +%F), $1, $(date +%H:%M), , , \"$2\", \"\"" >> ~/server-time.csv
}
# использование: logtime incident "алерт по диску"

Часть категории 1 (рутинные обновления) можно снять автоматически, не полагаясь на память — journalctl уже содержит метки времени выполнения патч-циклов:

journalctl -u apt-daily-upgrade.service --since "-30 days" | grep Started

Это даёт объективные точки для категории 1, но не заменяет ручную запись времени на проверку результата — сам факт запуска патча автоматикой не значит, что кто-то не потратил 15 минут на ручную сверку после него.

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

Как посчитать итоговую цифру и что с ней делать

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

Рутинные обновления — самая линейная категория: если за месяц ушло N минут на патч-циклы и проверки, умножайте на 12 (или на фактическую частоту цикла).

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

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

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

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

Дальше эту цифру можно использовать практически:

• Перевести часы в деньги через стоимость часа своего времени или найма — сравнение подробно разобрано в статье сколько стоит час админа и когда дешевле доплатить.
• Сравнить с тем, что реально происходит на горизонте нескольких лет, а не одного года — динамика обслуживания редко бывает постоянной, она разобрана в материале «настроил и забыл»: обслуживание за пять лет.
• Решить, стоит ли часть категорий (в первую очередь рутина и часть планового аудита) отдать на аутсорс или managed-услугу, оставив себе только то, что требует контекста именно вашего продукта — обычно это часть реактивной категории и архитектурные решения.

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

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