Наблюдаемость и надёжность
Что мониторить в базе данных?
Мониторят пользовательские симптомы: latency и ошибки запросов, throughput, число соединений и насыщение пула. Для причины нужны slow queries, планы, locks и deadlocks, cache hit, buffer или memory pressure, CPU, I/O и свободное место. В репликации смотрят lag, состояние replica и ошибки применения; для backup важен проверенный restore, а не только успешный job. Пороги строят по SLO и трендам, например время до заполнения диска, а не одному универсальному проценту. Метрики связывают с конкретными запросами и изменениями. Набор и названия показателей зависят от СУБД.
Ссылки для изучения
Какие сигналы ресурсов хоста нужно мониторить?
Для 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%» без очереди и деградации часто создаёт шум.
Ссылки для изучения
Как расследовать внезапную недоступность сервиса?
Сначала подтверждают масштаб, время начала и пользовательский симптом, затем назначают координацию и канал связи. Проверяют метрики, логи и traces на общей временной шкале, состояние зависимостей, DNS, сети, сертификатов и ресурсов. Отдельно смотрят последние deploy, конфигурации, feature flags и инфраструктурные изменения. Приоритет инцидента: снизить ущерб: rollback, отключение функции, переключение трафика или увеличение ёмкости, если риск понятен. Гипотезы и действия записывают с временем, чтобы не повторять проверки. После восстановления сохраняют доказательства, строят timeline и устраняют системную причину, а не только перезапускают сервис.
Ссылки для изучения
Что даёт Multi-AZ базе данных?
В managed database режим Multi-AZ обычно держит синхронный или близкий по модели standby в другой зоне и автоматизирует failover при отказе основной. Это повышает доступность и уменьшает ручное восстановление, но не делает RTO нулевым: соединения могут оборваться, DNS или endpoint переключаться, приложение должно переподключиться. Standby не обязательно обслуживает чтение; read replica решает масштабирование чтения и часто имеет lag, а не ту же роль отказоустойчивости. Реальные гарантии, стоимость и число зон зависят от сервиса. Failover регулярно тестируют вместе с приложением и мониторингом.
Ссылки для изучения