На совещании лежат десять отчётов: uptime, загрузка CPU, ROI, технический долг, скорость команды. Цифр много, а ответа нет. Нужно ли менять сервер, хватит ли апгрейда или пора разделить 1С, терминальные сессии и файловое хранилище?
Метрики ИТ-проектов делят на технические, продуктовые и управленческие. Если собрать их на одной панели без вопроса к данным, получится отчёт ради отчёта. Для закупки нужны три—пять показателей, которые меняют выбор железа.
Рабочая связка выглядит так:
бизнес-ограничение → показатель → порог → действие с железом
Она позволяет объяснить директору не то, что CPU занят на 80%, а почему текущая платформа не выдержит рост нагрузки или допустимый простой.
Начни с процесса, который нельзя остановить
Допустим, на одном сервере работают 1С, терминальные сессии и файловое хранилище. Компания открывает второй офис. Число пользователей вырастет, но директор не готов покупать новое оборудование «на всякий случай».
Первый вопрос — какой процесс пострадает при нехватке ресурсов или отказе сервера. Например, бухгалтерия не сможет проводить документы, сотрудники потеряют терминальный доступ, а отдел продаж — открыть договоры.
Дальше нужно определить, какие из этих функций критичны. Покрытие критических возможностей считают как отношение поддерживаемых возможностей к их общему числу. Для закупки формула полезна не сама по себе: она показывает, какую часть работы компании остановит отказ одного узла.
Так из отчёта уходят DAU, velocity и другие продуктовые показатели. DAU отражает число активных пользователей, а velocity — объём задач, закрытых командой за спринт. Ни одна из этих метрик не подсказывает, нужен ли второй блок питания или ещё четыре NVMe.
Остаются доступность критических систем, время отклика и использование CPU, памяти и хранилища. Они описывают именно ту нагрузку, под которую выбирают оборудование.
Загрузка CPU ничего не решает без порога
Uptime показывает долю времени, когда система доступна без перебоев. Response time — время обработки запроса. Resource utilization отражает использование процессора, памяти и хранилища (kaiten.ru; go-diagram.com).
Каждая метрика описывает состояние, но не предписывает покупку.
CPU может держаться на 80% во время закрытия месяца, а пользователи при этом укладываются в согласованное время проведения документов. Такой график ещё не обосновывает замену сервера. Сначала проверь частоту ядра, очередь к дискам, расход памяти и длительность пика.
Обратная ситуация опаснее: процессор загружен умеренно, но рабочий набор базы не помещается в память, а хранилище ждёт операции ввода-вывода. Покупка процессора с большим числом ядер не устранит задержку. Здесь нужно увеличить память, заменить дисковую подсистему или вынести файловую нагрузку на отдельный узел.
Универсального порога загрузки для закупки нет. Порог задаёт бизнес:
- какое время отклика мешает провести операцию;
- какой простой нарушает SLA;
- сколько пользователей добавится за срок эксплуатации сервера;
- какой ресурс первым исчерпает запас при этом росте.
SLA фиксирует согласованный уровень сервиса, например доступность 99,9%. Но сама цифра 99,9% не доказывает, что архитектура подходит компании. Если вся критическая нагрузка живёт на одном узле без резервирования, нужно сопоставить допустимый простой со временем восстановления и ценой остановки.
Порог должен вести к одному из трёх действий
У измерения есть смысл, если оно направляет закупку: апгрейдировать сервер, заменить платформу или разделить нагрузки.
Апгрейд подходит, когда платформа поддерживает нужный объём памяти и дисков, а процессору хватает запаса под рост. Например, замеры показывают нехватку памяти и вытеснение рабочего набора базы, но свободные слоты позволяют увеличить объём RDIMM. Тогда замена всего сервера добавит расходов, а не пропускной способности.
Новая платформа нужна, когда ограничение нельзя снять отдельным компонентом. Старый процессор не держит требуемое время отклика на ядро, контроллер или шина ограничивают диски, нужный объём памяти недоступен, гарантия закончилась, а запасных частей нет. Эти признаки складываются в аргумент. Один график CPU — нет.
Разделение нагрузок оправдано, когда сервисы мешают друг другу. Файловые операции занимают диски во время пика 1С, терминальные сессии выбирают память, а обслуживание одной системы требует остановить остальные. Отдельный сервер под базу или хранилище локализует нагрузку и отказ, но добавляет ещё один узел для обслуживания.
У каждого варианта своя цена. Апгрейд дешевле сегодня, зато сохраняет ограничения старой платформы. Новый сервер оставляет запас по слотам, дискам и гарантии, но требует больше денег сразу. Второй узел снижает последствия отказа, однако увеличивает расходы на лицензии, питание и сопровождение.
Стоимость и риск заканчивают расчёт
Технические замеры нужно перевести в деньги. ROI считают как разницу между экономическим эффектом и затратами, делённую на затраты. Бюджетное отклонение показывает разницу между плановыми и фактическими расходами.
Для сравнения железа этого мало. В расчёт нужно добавить стоимость простоя: потерянные операции, простой сотрудников, восстановление данных и срочную работу подрядчика. Тогда дорогой резервный узел можно сравнить не с нулём рублей, а с последствиями отказа.
Технический долг тоже имеет цену. Один из способов оценить его — разделить часы обслуживания на часы разработки. Для серверной закупки вместо разработки можно взять часы полезных изменений: подключение новых пользователей, перенос баз, запуск сервисов. Если команда тратит время на обход ограничений старой платформы, дешёвый апгрейд лишь переносит замену.
Решение удобно свести к трём сценариям:
| Вариант | Что проверяем | Главный компромисс |
|---|---|---|
| Апгрейд | Есть ли свободные слоты памяти, отсеки и пропускная способность контроллера | Меньше затрат сейчас, но старая платформа остаётся |
| Новый сервер | Снимет ли платформа измеренное ограничение и выдержит ли плановый рост | Больше начальных расходов |
| Разделение нагрузок | Перестанут ли сервисы конкурировать за память и хранилище | Меньше взаимного влияния, больше узлов и лицензий |
Архитектуру оценивают по двум осям: возможностям ИТ и критичности процесса для бизнеса. Поэтому сервер с достаточным запасом ресурсов всё равно не подходит, если отказ одного блока питания останавливает процесс, для которого согласован короткий простой.
Руководству и ИТ нужны разные срезы
Не пытайся поместить всё на один экран. Архитектурную отчётность разделяют на стратегический, тактический и операционный уровни.
Директору нужны стоимость вариантов, риск простоя, ROI и покрытие критических процессов. В отчётах для руководства рекомендуют показывать финансовый эффект, уровень риска и поддержку стратегических возможностей.
ИТ-руководителю нужны SLA, время отклика, инциденты, технический долг и использование ресурсов. Эти показатели объясняют, где возникло ограничение и какое изменение его снимет.
Стратегию и бюджет имеет смысл пересматривать на квартальном обзоре, а риски, инциденты и эксплуатационные показатели — ежемесячно: такое разделение частоты используют в архитектурной отчётности. Доступность и загрузку ресурсов лучше собирать автоматически — ручной сбор повышает риск ошибок и задерживает отчёт.
Карточка для разговора с директором
Перед запросом цены у поставщика заполни пять строк:
- Критический процесс: что остановится при отказе или нехватке ресурсов.
- Обязательный SLA: сколько простоя и какая задержка допустимы.
- Текущее состояние: доступность и время отклика на рабочем пике.
- Ограничение: CPU, память, хранилище или отсутствие резервирования.
- Цена вариантов: апгрейд, новый сервер, разделение нагрузок и стоимость простоя.
Если строку нельзя заполнить замером или согласованным требованием, обоснование ещё не готово. Поставщик подберёт конфигурацию по общим вводным, а директор увидит лишь сумму.
Архитектура работает, когда поддерживает критические процессы в заданном SLA, укладывается в согласованный риск и обходится дешевле последствий отказа. Метрика, которая не меняет выбор между апгрейдом, заменой и разделением нагрузки, в заявке на закупку не нужна.
