Безперервність і відновлення

Доступність і резервні копії

Резервування підтримує роботу при відмові компонента; резервна копія дозволяє повернути дані після пошкодження чи помилкової зміни. Ці механізми доповнюють один одного.

Критерії готовності

Для критичної функції задають цільовий час відновлення, допустиму втрату даних і спосіб вимірювання. Перевіряють перемикання, повернення в основний режим та цілісність даних. RTO, RPO та перевірка відновлення →.

Безперервність починається з критичної операції

План відновлення варто будувати навколо того, що має знову запрацювати. Для обліку це збереження й перегляд операцій, для сайту — доступ до сторінок і приймання звернень, для аналітики — продовження обробки. Перелік серверів допомагає інвентаризації, але не визначає порядок повернення сервісів.

Для кожної операції потрібні залежності: дані, доступи, мережа, зовнішні сервіси та конфігурація. Частина з них може відновлюватися довше за основний застосунок. Саме тому час копіювання файлів не дорівнює повному часу повернення робочого процесу.

RTO та RPO на практиці

RTO описує цільовий час відновлення, RPO — допустиму втрату даних у часі. Їх визначають для конкретного сервісу. Потрібно окремо погодити момент початку відліку, сценарій відмови та контрольну операцію, за якою відновлення вважається завершеним.

Навчальна перевірка включає підготовку середовища, доступ до копії, відновлення даних, запуск залежностей та прикладний тест. Виявлені ручні кроки записують у процедуру. Якщо для операції потрібна одна людина з особисто відомими налаштуваннями, це окрема залежність, яку також потрібно врахувати.

Відмова, помилка даних і оновлення

Резервний вузол допомагає при частині апаратних відмов, але помилкова зміна може бути відтворена на ньому разом із правильними даними. Для повернення попереднього стану потрібні історичні копії та спосіб вибрати узгоджену точку. При цьому важливо розуміти, які нові операції доведеться повторно звірити.

Для оновлення визначають початковий стан, перевірку після зміни й умови відкату. Відкат коду та відкат структури даних можуть вимагати різних дій. Тому план перевіряють до робіт, а не складають під час інциденту.

У підсумковому протоколі потрібні сценарій, фактичні часові позначки, результат контрольної операції та перелік проблем. Наступна перевірка має враховувати зміни в даних, обладнанні й залежностях. Назва Zero-Downtime позначає інженерний напрям роботи, а не обіцянку відсутності будь-яких перерв у кожній системі.

Контрольний сценарій перед запуском

Для приймання обирають конкретну робочу операцію й фіксують її початкові умови. Після звичайного проходження перевіряють погоджений збій: перерву зв’язку, перезапуск компонента або повторне надходження даних. Результат має пояснювати, що збереглося, що відновилося автоматично та де потрібна дія оператора. Ці відомості передають разом із правилами супроводу.

Як часто повторювати перевірку?

Періодичність визначають критичність сервісу та швидкість його змін. Окрема перевірка потрібна після суттєвої зміни сховища, формату даних, залежностей або процедури копіювання. Варто мати короткий контроль доступності копій і повний сценарій запуску відновленої системи. Успішний попередній тест не пояснює стан після наступної міграції. Під час навчальної перевірки використовуйте ізольоване середовище, щоб відновлений застосунок не надсилав робочі повідомлення й не змінював зовнішні системи. Після завершення запишіть фактичний результат, невиконані кроки та відповідального за їх виправлення.