Задание 1. Найдите точки отказа
- Для схемы «балансировщик → два API → одна БД» укажите не менее двух возможных SPOF.
- Предложите, как уменьшить риск каждого отказа.
- Объясните, почему добавление копии БД не отменяет необходимость бэкапов.
Обеспечение качества функционирования компьютерных систем · работа 4/5
Надёжность, резервное копирование и восстановление
SPOF, отказоустойчивость, RPO, RTO и испытания восстановления. Сначала изучите теорию и интерактивные модели, затем выполните три практических задания и тест внизу страницы. Всё сохраняется в этом браузере автоматически.
01
Надёжность, доступность и отказоустойчивость
«Кампус» должен работать в течение семестра. Но любой компонент может перестать отвечать: накопитель, БД, сеть, процесс приложения, целый сервер. Задача инженера — не предполагать, что отказов не будет, а ограничивать их вероятность и последствия.
Надёжность — способность сохранять требуемое функционирование в определённых условиях и времени. Доступность описывает возможность воспользоваться системой тогда, когда она нужна. Отказоустойчивость позволяет продолжать предоставлять сервис при части отказов. Восстанавливаемость — возможность вернуться к рабочему состоянию после нарушения.
КомпонентМожет отказать
→ОбнаружениеМониторинг и сигнал
→РезервированиеРабота на другом узле
→ВосстановлениеУстранение причины и проверка
Резервный сервер и резервная копия решают разные задачи: один помогает пережить остановку узла, другая помогает восстановить состояние данных.
02
Единая точка отказа и резервирование
Single Point of Failure (SPOF) — компонент, отказ которого выводит систему из строя из-за отсутствия альтернативы. Если есть два сервера приложения, но одна БД и один сетевой коммутатор, доступность всё ещё ограничена этими единичными компонентами.
Где остаётся SPOF?
Балансировщик1 экземпляр — возможная SPOF
→API 1 / API 2Два экземпляра приложения
→База данных1 экземпляр — возможная SPOF
При репликации данные копируются на другую систему по определённым правилам. Реплика может повторить ошибочное удаление, шифрование вымогателем или повреждение — поэтому репликация не заменяет независимые резервные копии. Отказы в общей электросети или регионе могут одновременно затронуть несколько реплик.
03
RPO и RTO: два независимых требования
RPO (Recovery Point Objective) — максимально допустимая потеря данных, обычно выраженная во времени между последним пригодным состоянием и моментом сбоя. RTO (Recovery Time Objective) — целевой срок восстановления услуги. Одно не следует из другого.
12:00Последняя пригодная копия
→14:00Сбой и потеря данных после 12:00
→17:00Услуга восстановлена
🧮 Интерактив: RPO и RTO после аварии
Укажите время последнего пригодного снимка, момент сбоя и восстановление услуги. Время задаётся часами одних суток, без перехода через полночь.
В реальной системе фактический RPO следует определять по действительно восстановленным транзакциям, а не только по времени файла резервной копии; фактический RTO измеряется до восстановления согласованной работоспособной услуги.
04
Резервное копирование: правило 3–2–1
Практическая эвристика 3–2–1: иметь как минимум три копии данных (включая рабочую), на двух разных типах носителей/средах и одну копию вне основной площадки. Это ориентир, который адаптируют к рискам; отдельная изолированная или неизменяемая копия добавляет защиту от массовой порчи.
| Способ | Преимущество | Ограничение |
|---|---|---|
| Полная копия | Проще восстановить отдельно | Может занимать много места и времени |
| Инкрементальная | Копирует изменения с предыдущей копии выбранного типа | Восстановление может требовать цепочки |
| Дифференциальная | Изменения с последней полной копии | Объём растёт по мере удаления от полной копии |
| Снимок хранилища | Быстро фиксирует состояние на уровне платформы | Не всегда независим от основного хранилища |
Копия считается полезной после проверки восстановления. Наличие зелёного статуса backup job ещё не доказывает, что можно восстановить нужную версию БД со всеми зависимостями и правами.
Для базы данных важно согласованное резервное копирование: файлы, транзакции, журналы WAL и время снимка должны соответствовать выбранному методу. Простое копирование открытого файла базы не всегда даёт пригодную копию.
05
План реагирования и проверка восстановления
План аварийного восстановления описывает роли, порядок действий, зависимости и критерии возврата к нормальной работе. Важно не только поднять процессы, но и убедиться, что студент видит свои оценки, преподаватель может сохранять новые записи, а данные согласованы.
ЗафиксироватьКогда, что недоступно
→ИзолироватьОграничить дальнейший ущерб
→ВосстановитьИз проверенной точки
→ПроверитьДанные + вход + операции
→РазобратьПричины и улучшения
После аварии важны и неудачные решения
Поспешное переключение на устаревшую реплику без анализа может потерять новые оценки. Восстановление из заражённого бэкапа может повторить инцидент. Поэтому шаги должны включать подтверждение целостности и оценку допустимой потери данных.
06
Как оценивать частоту отказов и длительность восстановления
Для анализа оборудования и сервисов используют показатели вроде MTTR (среднее время восстановления/ремонта — точный смысл задаётся контекстом) и MTBF (среднее время между отказами для ремонтируемого объекта). Не путайте их с RTO — целевым требованием по восстановлению.
Пример: три отказа за период
Восстановление: 20, 40 и 60 минут
Среднее MTTR = (20 + 40 + 60) / 3 = 40 минут
Малое среднее не исключает редких очень длительных аварий. При оценке пользовательского опыта также полезны максимальная длительность инцидента и доля запросов с ошибками. Классическая приближённая формула стационарной доступности MTBF / (MTBF + MTTR) применима только при согласованных предположениях о циклах отказов и восстановления.
| Показатель | Показывает | Не путать с |
|---|---|---|
| RTO | Целевой предельный срок восстановления | Средней продолжительностью уже прошедших аварий |
| MTTR | Среднюю длительность по наблюдённым случаям | Максимально допустимым сроком |
| MTBF | Средний интервал между отказами | Сроком абсолютной гарантии без отказов |
Для сложной системы с резервированием надёжность отдельного диска и доступность сервиса связаны, но не одинаковы: отказ диска может не привести к остановке пользовательской операции.
07
Реальная проверка бэкапа: минимальный протокол
Испытание восстановления следует планировать заранее. Сначала выбирают конкретную копию и изолированное окружение, фиксируют целевое время, выполняют восстановление, а затем доказывают корректность результата. Протокол позволяет заметить проблемы прежде, чем произойдёт настоящая авария.
| Шаг | Что фиксируем | Критерий успеха |
|---|---|---|
| 1. Выбор копии | Дата, место хранения, контрольная сумма | Копия найдена и доступна |
| 2. Восстановление | Начало, конец, ошибки процесса | Данные успешно загружены |
| 3. Проверка данных | Контрольные оценки и число записей | Согласованность подтверждена |
| 4. Проверка сервиса | Вход, чтение, сохранение в тестовом контуре | Ключевые функции работают |
| 5. Отчёт | Фактические RPO/RTO, замечания | Результат принят или назначены меры |
Размещать тестовое восстановление прямо поверх действующей production-БД без безопасного плана нельзя. Оно может уничтожить более новые данные. Используйте специально выделенное изолированное окружение, а доступ к копиям ограничивайте и регистрируйте.
08
Сценарии отказов и принцип ограниченного ущерба
Отказоустойчивость проверяют не только по схеме архитектуры. Необходимо проверить, что произойдёт при обрыве соединения, остановке API, нехватке места, исчерпании пула БД или недоступности резервного узла. Испытания отказов проводятся контролируемо, с разрешением и возможностью восстановления.
| Отказ | Ожидаемое устойчивое поведение | Что проверить |
|---|---|---|
| Один экземпляр API недоступен | Трафик перенаправлен на исправные экземпляры | Частота ошибок и время переключения |
| Нет связи с БД | Операция корректно завершается ошибкой без ложного сохранения | Ответ пользователю и целостность данных |
| Место на диске заканчивается | Срабатывает предупредительный сигнал | Достаточно ли времени для реакции |
| Сломана основная площадка | Действует план восстановления из независимой копии | RPO, RTO, доступность копии |
Резервирование требует контроля: два одинаковых узла могут одновременно потерять питание, если включены в один удлинитель. Поэтому в анализ включают общие причины отказов, а не только количество компонентов.
09
Практика: план устойчивости «Кампуса»
Задание 2. Рассчитайте потери и восстановление
- В 08:00 создана последняя пригодная копия, в 11:00 возник сбой, в 12:30 сервис восстановлен (те же сутки).
- Рассчитайте фактическую потерю данных в часах и время восстановления.
- Проверьте соблюдение целей RPO ≤ 2 ч и RTO ≤ 2 ч. Сделайте вывод.
Задание 3. Разработайте план восстановления
- Опишите минимум шесть шагов от обнаружения аварии до возврата пользователей.
- Включите проверку целостности восстановленных оценок и разрешений.
- Укажите, как часто вы будете проводить тренировочное восстановление и почему.
Часть II · проверка знаний
Тест по изученному материалу
Выберите один ответ в каждом вопросе и нажмите «Проверить тест». После проверки появятся разборы. Практические задания и развёрнутые вопросы проверяет преподаватель — в процентах они не учитываются.
Часть A. Выберите правильный ответ
Часть Б. Объясните своими словами
Эти вопросы оценивает преподаватель. Не копируйте определения: приведите собственный аргумент и, где необходимо, расчёт или пример.
Источники для дополнительного изучения
Теоретические сведения адаптированы для обучения. Интерактивные расчёты и сценарии — учебные модели, не измерения работающей инфраструктуры. Внешние ссылки нужны только для дополнительного чтения: сама работа открывается без интернета.
Перед сдачей
✓ Заполнены ФИО, группа и дата.
✓ Выполнены три практических задания.
✓ Выбраны и проверены ответы на 15 тестовых вопросов.
✓ Записаны три развёрнутых ответа.
Нажмите «Отправить работу — сохранить PDF» и в диалоге печати выберите «Сохранить как PDF». В PDF попадут ФИО, ответы, результат тестирования и задания. Никакие данные не отправляются на сервер.
Открылось окно печати — выберите «Сохранить как PDF».