---
title: Наблюдаемость и надёжность
questionDates:
  q-transfer-0419: '2026-10-01'
  q-transfer-0420: '2026-10-01'
  q-transfer-0421: '2026-10-01'
  q-transfer-0430: '2026-10-01'
seo:
  description: >-
    Тема «Наблюдаемость и надёжность» для собеседования DevOps. Что мониторить в
    базе данных? Какие сигналы ресурсов хоста нужно мониторить?
  title: Наблюдаемость и надёжность — DevOps
---

[Все темы DevOps](/prep/devops)

## Что мониторить в базе данных? [#q-transfer-0419]

Мониторят пользовательские симптомы: latency и ошибки запросов, throughput, число соединений и насыщение пула. Для причины нужны slow queries, планы, locks и deadlocks, cache hit, buffer или memory pressure, CPU, I/O и свободное место. В репликации смотрят lag, состояние replica и ошибки применения; для backup важен проверенный restore, а не только успешный job. Пороги строят по SLO и трендам, например время до заполнения диска, а не одному универсальному проценту. Метрики связывают с конкретными запросами и изменениями. Набор и названия показателей зависят от СУБД.

:::note[Ссылки для изучения]

1. [Мониторинг PostgreSQL по USE и RED: запросы, ошибки, задержки, соединения и блокировки](https://habr.com/ru/articles/514180/)
   :::

---

## Какие сигналы ресурсов хоста нужно мониторить? [#q-transfer-0420]

Для CPU нужны utilization, load, run queue и steal; для памяти: available, pressure, swap, page faults и OOM. По диску следят отдельно за capacity, inode, latency, IOPS, throughput и queue. Для сети важны bandwidth, drops, errors, retransmits и исчерпание conntrack или портов. Добавляют здоровье критичных процессов, число открытых файлов и время. Все сигналы смотрят как временные ряды и связывают с SLO сервиса. Алерт должен указывать на действие или пользовательский симптом; постоянный сигнал «CPU выше 80%» без очереди и деградации часто создаёт шум.

:::note[Ссылки для изучения]

1. [Сигналы ресурсов Linux: CPU, память, дисковый I/O и сетевые счётчики](https://habr.com/ru/companies/ruvds/articles/1000218/)
   :::

---

## Как расследовать внезапную недоступность сервиса? [#q-transfer-0421]

Сначала подтверждают масштаб, время начала и пользовательский симптом, затем назначают координацию и канал связи. Проверяют метрики, логи и traces на общей временной шкале, состояние зависимостей, DNS, сети, сертификатов и ресурсов. Отдельно смотрят последние deploy, конфигурации, feature flags и инфраструктурные изменения. Приоритет инцидента: снизить ущерб: rollback, отключение функции, переключение трафика или увеличение ёмкости, если риск понятен. Гипотезы и действия записывают с временем, чтобы не повторять проверки. После восстановления сохраняют доказательства, строят timeline и устраняют системную причину, а не только перезапускают сервис.

:::note[Ссылки для изучения]

1. [Управление инцидентами в Туту: координация, восстановление и разбор причин](https://habr.com/ru/companies/tuturu/articles/346946/)
   :::

---

## Что даёт Multi-AZ базе данных? [#q-transfer-0430]

В managed database режим Multi-AZ обычно держит синхронный или близкий по модели standby в другой зоне и автоматизирует failover при отказе основной. Это повышает доступность и уменьшает ручное восстановление, но не делает RTO нулевым: соединения могут оборваться, DNS или endpoint переключаться, приложение должно переподключиться. Standby не обязательно обслуживает чтение; read replica решает масштабирование чтения и часто имеет lag, а не ту же роль отказоустойчивости. Реальные гарантии, стоимость и число зон зависят от сервиса. Failover регулярно тестируют вместе с приложением и мониторингом.

:::note[Ссылки для изучения]

1. [Multi-AZ в Amazon RDS: резервный инстанс, репликация и автоматическое переключение](https://aws.amazon.com/ru/rds/features/multi-az/)
   :::