Надёжность бизнес-системы: резервирование и восстановление

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

Ниже — регламент в шести разделах. Формулировки пригодны для приложения к договору.

1. Классы отказов

1.1. Отказ оборудования или хостинга. Сервер недоступен, данные на нём сохранны либо утрачены.

1.2. Порча данных. Ошибочная выгрузка, неверная массовая правка, сбой интеграции. Система работает, содержимое неверно.

1.3. Утрата доступа. Блокировка учётной записи хостинга, неоплата, потеря ключей, увольнение сотрудника с единственным доступом.

1.4. Отказ внешнего сервиса. Платёжный сервис, служба доставки, отправка сообщений. Собственная система работает, часть операций невозможна.

1.5. Ошибка обновления. После установки новой версии функция работает неверно либо не работает вовсе.

Классы различаются не тяжестью, а способом устранения. Копия данных помогает при 1.1 и 1.2, не помогает при 1.4 и частично помогает при 1.3.

2. Состав резервирования

2.1. База данных. Полная копия ежедневно, журнал изменений — непрерывно, если система принимает заказы или платежи.

2.2. Пользовательские файлы. Изображения, документы, вложения. Копируются отдельно от базы, глубина хранения не меньше базы.

2.3. Исходный код. Хранится в системе контроля версий, доступ у владельца. Отдельного бэкапа не требует при условии, что доступ владельца подтверждён.

2.4. Конфигурация и ключи. Переменные окружения, ключи платёжного сервиса, токены интеграций. Хранятся отдельно от архивов данных, в менеджере паролей владельца.

2.5. Реестр доступов. Перечень: хостинг, домен, платёжный сервис, служба доставки, почтовый сервис, аналитика. Для каждого — владелец учётной записи и способ восстановления пароля.

2.6. Копии хранятся не менее чем в двух местах, одно из которых вне сервера системы и вне учётной записи хостинга.

3. Целевые показатели восстановления

3.1. Допустимая потеря данных определяется в часах и фиксируется до начала работ.

3.2. Допустимое время простоя определяется отдельно для витрины и для внутренней части.

3.3. Рекомендуемые значения для типовых случаев:

3.4. Ужесточение показателей увеличивает стоимость сопровождения. Значения выбираются исходя из потерь за час простоя, а не из желания.

4. Порядок восстановления

4.1. Зафиксировать факт и время отказа, определить класс по разделу 1.

4.2. Остановить операции, способные усугубить порчу данных: импорт, массовые правки, автоматические выгрузки.

4.3. Уведомить владельца. При классе 1.1 и 1.3 — до начала работ, при остальных — в течение часа.

4.4. Развернуть копию на резервной площадке, не затирая текущее состояние системы. Текущее состояние сохраняется до окончания разбора.

4.5. Проверить восстановленную систему по контрольному перечню раздела 5.

4.6. Переключить трафик, зафиксировать время возобновления работы.

4.7. В течение трёх рабочих дней составить справку: причина, длительность, объём потерянных данных, меры предотвращения.

5. Контрольный перечень готовности после восстановления

5.1. Открывается главная страница и страница каталога либо рабочего раздела.

5.2. Выполняется вход под учётной записью администратора и под учётной записью рядового сотрудника.

5.3. Создаётся тестовая запись, редактируется, удаляется.

5.4. Проходит тестовая оплата на минимальную сумму с последующим возвратом, если система принимает платежи.

5.5. Отправляется тестовое уведомление на почту и в мессенджер.

5.6. Проверяется последняя по времени запись, созданная до отказа. Её наличие подтверждает фактическую глубину восстановления.

5.7. Проверяется работа интеграций: выгрузка в учётную систему, создание отправления, обмен остатками.

6. Проверки и периодичность

6.1. Автоматическая проверка успешности создания копии — ежедневно, с уведомлением при ошибке. Отсутствие уведомления не считается подтверждением.

6.2. Пробное восстановление на отдельной площадке — не реже одного раза в квартал, с прохождением перечня раздела 5 и фиксацией затраченного времени.

6.3. Сверка реестра доступов — не реже двух раз в год и обязательно при смене подрядчика или увольнении сотрудника с доступами.

6.4. Пересмотр показателей раздела 3 — при существенном изменении нагрузки или состава операций.

6.5. Результаты проверок вносятся в журнал: дата, вид проверки, затраченное время, выявленные отклонения, срок устранения.

Практическое замечание к пункту 6.2. Незакрытым обычно остаётся именно оно: копии создаются годами, а первое восстановление выполняется в день аварии. Разница между расчётным и фактическим временем в этот момент выясняется впервые и в худших условиях.

7. Разграничение ответственности

7.1. При разовой разработке без договора сопровождения обязанности по созданию копий и восстановлению несёт владелец системы.

7.2. При наличии договора сопровождения в нём указываются: перечень резервируемых объектов, периодичность, срок реакции на обращение и время работы исполнителя.

7.3. Срок реакции и допустимое время простоя из раздела 3 — разные величины. Реакция означает начало работ, а не возобновление работы системы.

7.4. При передаче проекта другому исполнителю выполняются: сверка реестра доступов, смена паролей и ключей, проверка наличия последней копии, контрольное восстановление силами принимающей стороны.

7.5. Гарантийные обязательства исполнителя действуют три месяца и распространяются на ошибки исполнителя. Отказы, вызванные действиями третьих лиц, изменением условий хостинга или действиями сотрудников владельца, устраняются как отдельные работы.

8. Типовые нарушения регламента

8.1. Копии создаются на том же сервере, где размещена система. При отказе оборудования утрачиваются вместе с данными.

8.2. Ключи и пароли хранятся внутри архива с данными. Компрометация архива означает компрометацию всех подключённых сервисов.

8.3. Доступы оформлены на учётную запись сотрудника или подрядчика, а не владельца. При увольнении или смене исполнителя восстановление становится невозможным в заявленные сроки.

8.4. Глубина хранения ограничена одними сутками. Порча данных, обнаруженная позже, восстановлению не подлежит.

8.5. Пробное восстановление ни разу не проводилось. Показатели раздела 3 в этом случае носят расчётный характер и в отчётности как выполненные не указываются.

Коротко

Надёжность описывается четырьмя ответами по каждому классу отказа: что резервируется, сколько данных допустимо потерять, за какое время система поднимается и кто это делает. Копии хранятся минимум в двух местах, одно из которых вне учётной записи хостинга, ключи — отдельно от архивов. Пробное восстановление проводится ежеквартально; без него показатели раздела 3 остаются предположением.