Как измерить работу админа: метрики, понятные владельцу бизнеса

MAATRIX

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

Почему «вроде работает» — это не показатель

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

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

1. Доступность (uptime) — сколько времени сервис реально работал.
2. Время реакции на инциденты — как быстро на проблему отреагировали и как быстро её решили.
3. Темп закрытия задач — двигаются ли заявки или копятся в очереди.
4. Соблюдение бюджета — тратится ли оговорённое время и деньги так, как договаривались.

Это статья именно про то, откуда брать эти четыре цифры, что считать нормой и как их интерпретировать без технического образования. Она не заменяет более широкий разговор о поведенческих признаках качественной работы — регулярность отчётов, наличие документации, готовность объяснять решения простым языком — этот набор косвенных маркеров подробно разобран в статье «Как проверить работу админа, если сами вы не технарь». Там — про поведение и разовую оценку в моменте. Здесь — про измеримые числа, которые вы собираете регулярно и сравниваете в динамике.

Доступность: не «uptime 99.9%» на веру, а откуда цифра берётся

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

Что нужно понимать, не разбираясь в мониторинге:

• Кто и чем измеряет. Если единственный источник цифры — сам администратор, который «смотрит логи и говорит, что всё было доступно», это не измерение, а мнение. Честная метрика доступности снимается независимым внешним сервисом, который раз в одну-пять минут стучится на ваш сайт снаружи — так же, как это делает реальный посетитель — и фиксирует, ответил сервер или нет. Многие такие сервисы бесплатны для одного-двух сайтов и не требуют участия админа для настройки: вы или он подключаете внешний мониторинг один раз, и дальше цифра существует независимо от того, что говорит подрядчик.
• Что считается простоем. Пять секунд лишней задержки — не простой. Страница, которая не открывается вообще или отдаёт ошибку сервера дольше минуты, — простой. Плановые технические работы, о которых вас предупредили заранее и в удобное время, обычно не засчитываются в аварийный простой отдельным пунктом соглашения — но должны быть отдельно видны в отчёте, а не спрятаны внутри общего процента.
• Сам процент без контекста ничего не значит. «99.9% за месяц» звучит внушительно, но это чуть больше 43 минут простоя за 30 дней — и разница между одним провалом на 43 минуты ночью и десятком провалов по 4 минуты в рабочее время огромна для бизнеса, хотя итоговый процент одинаковый. Ориентир: для большинства небольших и средних проектов на VPS без специальных требований к отказоустойчивости приемлемым считается диапазон от 99.5% до 99.9% за месяц — но это именно ориентир, а не гарантированный стандарт, и у вас в договоре может быть прописано иначе. Важнее не абсолютное число, а то, растёт простой от месяца к месяцу или нет, и происходят ли провалы в критичное для бизнеса время (рабочие часы, распродажи, пиковые дни) или в три часа ночи, когда почти никто не заметил.

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

Время реакции на инциденты: два разных числа, а не одно

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

• Время до первой реакции (response time). Сколько прошло от момента, когда проблема стала заметна, до момента, когда вы получили любое подтверждение, что её увидели: «принял, разбираюсь», а не полное решение. Это число почти целиком зависит от организации работы админа, а не от сложности проблемы — и именно поэтому оно самое честное для оценки дисциплины.
• Время до решения (resolution time). Сколько прошло до момента, когда проблема реально устранена. Это число сильно зависит от сложности — простая перезагрузка сервиса занимает минуты, восстановление после серьёзного сбоя базы данных может занять часы, и это нормально при условии, что первое число (реакция) было быстрым.

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

Дата: 14 августа 2026, 22:10
Что заметили: сайт не открывается (сообщил клиент)
Первая реакция админа: 22:34 (24 минуты)
Проблема решена: 23:05 (55 минут от начала)

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

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

Темп закрытия задач: очередь растёт или сокращается

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

Как это отслеживать без глубокого погружения:

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

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

Соблюдение бюджета: часы и деньги без сюрпризов

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

Что стоит сверять каждый месяц:

• Совпадает ли количество оплаченных часов с детализацией. Счёт вида «работа над сервером — 12 часов» без расшифровки не даёт возможности что-либо проверить. Хороший счёт разбит по задачам: что делалось, сколько заняло — тогда видно, тратится ли время на реальную работу или на что-то, что не должно быть в биллинге вовсе (например, обучение самого исполнителя новой для него технологии за ваш счёт). Подробный разбор того, как выстроить прозрачный учёт часов с почасовым подрядчиком, — в статье «Аутсорс-админ на почасовой: как считать часы и не платить за воздух».
• Растёт ли счёт быстрее, чем растёт инфраструктура. Если количество серверов и объём задач не изменились, а часы в счетах за полгода выросли вдвое, — это повод спросить, почему, а не просто оплатить. Возможные честные причины есть (накопившийся технический долг, разовый крупный проект), но они должны называться прямо, а не растворяться в общей сумме.
• Соответствуют ли фактические траты на инфраструктуру (сами серверы, лицензии, сертификаты) тому, что заложено в бюджете. Если тариф сервера незаметно вырос за год, потому что «нагрузка увеличилась», а по факту ресурсы простаивают, вы переплачиваете за мощности, которыми никто не пользуется — и это тоже часть метрики бюджета, просто с другой стороны.

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

Как собрать четыре метрики в одну табличку

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

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

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

Как запросить эти метрики у админа, не испортив отношения

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

• Объясняйте цель, а не только просьбу. «Мне нужна эта таблица не чтобы искать повод для претензий, а чтобы понимать картину, не отвлекая вас вопросами каждую неделю» — это меняет тон разговора с допроса на управленческий инструмент, которым пользуетесь вы оба.
• Начинайте с того, что не требует усилий от админа. Внешний мониторинг доступности вы можете настроить сами, без его участия — начните с этого, чтобы у вас уже была одна независимая цифра до любого разговора.
• Просите формат, а не конкретные слова. Не диктуйте, каким инструментом вести учёт задач или часов — попросите, чтобы раз в месяц вы получали четыре числа в понятном виде. Способ, которым он их считает у себя, — его дело.
• Зафиксируйте ожидания письменно один раз, а не обсуждайте заново каждый месяц. Это может быть короткий абзац в переписке или пункт в договоре — что именно вы ожидаете видеть, с какой периодичностью и в каком формате.
• Реагируйте на цифры, а не только собирайте их. Если метрики регулярно ухудшаются, а вы никак на это не реагируете, сбор данных превращается в ритуал без последствий — и админ довольно быстро это заметит, что снижает мотивацию присылать честные цифры вообще.

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

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