Какие знаешь метрики сайта?

Ключевые метрики производительности и доступности сайта

Как DevOps-инженер с десятилетним опытом, я разделяю метрики сайта на несколько ключевых категорий: метрики производительности, метрики доступности, бизнес-метрики и метрики инфраструктуры. Каждая категория критически важна для обеспечения стабильной работы и удовлетворённости пользователей.

1. Метрики производительности (Performance Metrics)

Эти метрики напрямую влияют на пользовательский опыт и SEO.

• Core Web Vitals (Google):

    *   **Largest Contentful Paint (LCP):** Время загрузки самого крупного контента. Цель — < 2.5 секунд.
    *   **First Input Delay (FID) / Interaction to Next Paint (INP):** Задержка при первом взаимодействии пользователя (клик, ввод). Цель — < 100 мс.
    *   **Cumulative Layout Shift (CLS):** Визуальная стабильность. Цель — < 0.1.

• Другие ключевые метрики загрузки:

    *   **Time to First Byte (TTFB):** Время от запроса до получения первого байта от сервера.
    *   **First Contentful Paint (FCP):** Момент появления первого контента.
    *   **Total Blocking Time (TBT):** Общее время, когда основной поток был заблокирован и не мог реагировать на ввод.

Для сбора этих метрик используются инструменты вроде Google Lighthouse, WebPageTest, а также реальные данные пользователей (Real User Monitoring, RUM) через Google Analytics 4 или специализированные решения (e.g., New Relic, Dynatrace).

2. Метрики доступности и надежности (Availability & Reliability)

Основа стабильности любого сервиса.

• Доступность (Uptime / Availability): Процент времени, когда сайт доступен для пользователей. Часто измеряется как (Общее время - время простоя) / Общее время * 100%. Цели для критичных сервисов — 99.9% (три девятки) и выше.
• Частота ошибок (Error Rate): Процент запросов, завершившихся с ошибками (HTTP 5xx, 4xx). Мониторится на уровне балансировщиков (Nginx, HAProxy) и бэкенд-сервисов.

  # Пример логирования в Nginx для последующего анализа
  log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for" $request_time';
  

• Среднее время восстановления (Mean Time To Recovery, MTTR): Среднее время, необходимое для устранения сбоя и восстановления работы. DevOps-культура направлена на его минимизацию.

3. Метрики инфраструктуры и ресурсов

Позволяют планировать мощность и выявлять аномалии.

• Использование ЦП (CPU Utilization): Нагрузка на процессорные ядра.
• Использование памяти (Memory Usage): Потребление оперативной памяти, важно отслеживать утечки (memory leaks).
• Дисковые метрики: Свободное место, IOPS (Input/Output Operations Per Second), задержки чтения/записи.
• Сетевые метрики: Входящий/исходящий трафик, количество TCP-соединений, ошибки на сетевых интерфейсах.

Эти метрики собираются агентами (например, Prometheus Node Exporter, Telegraf) и визуализируются в Grafana.

# Пример правила оповещения Prometheus Alertmanager для высокой загрузки ЦП
groups:
- name: host_alerts
  rules:
  - alert: HighCPUUsage
    expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Высокая загрузка ЦП на {{ $labels.instance }}"

4. Бизнес-метрики (Business Metrics)

Связывают техническую работу с бизнес-результатами.

• Коэффициент конверсии (Conversion Rate): Процент посетителей, выполнивших целевое действие (покупка, регистрация).
• Среднее время на сайте (Average Session Duration).
• Ошибки в критичных бизнес-транзакциях (например, "не удалось оформить заказ").
• Активные пользователи в единицу времени (DAU/MAU).

Практический подход DevOps к метрикам

1. Единая панель мониторинга (Single Pane of Glass): Сведение ключевых метрик из всех слоев (frontend, backend, БД, инфраструктура) в единую дашборду Grafana для быстрого анализа инцидентов.
2. Сбор RUM и синтетических данных: Комбинация реальных данных от пользователей и автоматических проверок из разных точек мира (например, с помощью Grafana Synthetic Monitoring или Checkmk) для полной картины.
3. Настройка осмысленных алертов: Алерты должны срабатывать на симптомы, влияющие на пользователей (например, рост ошибок 5xx или падение LCP), а не просто на высокую загрузку ЦП. Используется подход SLI/SLO/SLA.

    *   **SLI (Service Level Indicator):** Измеряемая метрика (например, доступность 99.95%).
    *   **SLO (Service Level Objective):** Целевое значение SLI.
    *   **SLA (Service Level Agreement):** Договорное обязательство перед клиентом с последствиями за невыполнение SLO.

1. Логирование и трейсинг: Инструменты вроде ELK Stack (Elasticsearch, Logstash, Kibana) или Loki для агрегации логов и Jaeger/Zipkin для распределенной трассировки запросов (Distributed Tracing) помогают понять причину падения производительности или ошибки в сложных микросервисных архитектурах.

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