Як написати план відновлення після катастрофи англійською мовою

План відновлення після аварії (DR) — це документ, який, ви сподіваєтеся, ніколи не буде потрібно використовувати під тиском, що означає, що англійською мовою він повинен бути однозначним навіть для когось, хто читає його о 3 годині ранку під час фактичного відключення. Цей посібник містить стандартний словник і шаблони фраз для написання плану відновлення після аварії, який буде ясним, конкретним і реалізовуваним.

Ключовий словник

** RPO (Recovery Point Objective) ** — максимально допустима кількість втрат даних, виміряна за часом, у разі аварії.

• “Наша RPO для основної бази даних становить 15 хвилин, тобто ми можемо терпіти втрати не більше 15 хвилин записів.” *

** RTO (Recovery Time Objective) ** — максимально прийнятний час для відновлення роботи служб після аварії. “РТО для платіжної служби - одна година - якщо вона не працює довше, ніж це, ми ескалюємо до виконавчого інциденту мосту.”

** Відновлення після аварії ** — процес переключення операцій на резервну систему, регіон або центр обробки даних, якщо основний з них зазнає аварії. “Відновлення до вторинного регіону автоматизоване і повинно завершитися протягом п’ яти хвилин після невдалого завершення перевірки стану.”

** Відновлення після аварії ** — процес повернення операцій до початкової системи після її відновлення.

• “Резервне копіювання — це вручну виконаний крок — ми не автоматизуємо його, оскільки хочемо, щоб людина спочатку підтвердила стабільність первинного регіону.” *

** Runbook step ** — єдина, специфічна, впорядкована інструкція у процедурі відновлення, написана так, щоб її можна було виконати без додаткових викликів судження.

• “Кожен крок runbook називає точну команду для виконання і очікуваний вивід, отже інженер, який не знайомий з системою, все одно зможе виконати її правильно.” *

Звичайні фрази

• «У разі регіонального відключення, відключення запускається автоматично, як тільки перевірки стану не спрацьовують протягом двох послідовних хвилин»
• “Ця процедура припускає, що первинна база даних недоступна, а не просто повільна.”
• «Втрата даних в цьому сценарії обмежена нашим RPO [X]»
• «Ескалювати до [ролі/команді], якщо відновлення не було завершено в межах [RTO]»
• Цей план тестується щоквартально за допомогою запланованого тренування з відмови

Приклади висловлювань

Визначення обсягу у верхній частині документа:

• “Цей план включає процедури відновлення для основного кластера Postgres і шару зберігання об’ єктів. Вона не включає відновлення внутрішнього аналітичного конвеєра, який має окремий план DR з різними цілями RPO / RTO. ”*

Запис недвозначного кроку Runbook:

• “Крок 4: Переконайтеся, що затримка реплікації резервної репліки менше 10 секунд, виконавши команду SELECT now() - pg_last_xact_replay_timestamp(); на репліку. Не переходьте до кроку 5, поки це значення не буде менше 10 секунд.”*

Явно вказати припущення:

• “Ця процедура передбачає, що відновлення DNS вже завершено. Якщо трафік все ще маршрутизується до первинного регіону, зупиніть і ескалуйте — не продовжуйте з підвищенням бази даних. *

Описує частоту тестування:

• “Ми проводимо повне тренування з відновлення кожного кварталу, і результати — включаючи фактичний час відновлення — записуються у журналі тестування відновлення, посилання на який знаходиться в кінці цього документа.” *

Професійні поради

• Зазначте **RPO і RTO як конкретні числа **, а не нечіткі терміни, такі як «мінімальна втрата даних» - число можна перевірити, і інженер на виклику може діяти на нього під тиском.
• Записувати кроки runbook як ** імперативні речення з однією дією у кожному**: « Запустити X », « Підтвердити Y », « Не продовжувати до Z » — уникати поєднання декількох дій у одному кроці.
• Відрізняти ** відключення ** (перехід на резервне копіювання) від ** відновлення ** (повернення до основного) явно — об’ єднання їх у плані спричиняє справжню плутанину під час реального інциденту.
• На початку кожної процедури вкажіть ваші припущення (« це припускає, що X вже є істинним »), щоб читач під тиском точно знав, коли застосовувати процедуру.
• Включити ** кому і коли ескалувати ** як явну умову тригера, а не нечітку “якщо щось пішло не так”

Практичні вправи

1. Написати твердження RPO і RTO для гіпотетичної служби з вказаними номерами.
2. Написати три впорядковані кроки runbook для процедури відключення, кожен з яких є однією імперативною дією.
3. Напишіть одне речення, у якому буде вказано припущення, яке читач повинен підтвердити перед початком процедури.

Національний інститут статистики: Англійська мова для професійного використання

Написання міцного плану відновлення після аварії (DR) не просто про клацання на кнопці; це про чітке формулювання стратегій зменшення ризику для зацікавлених сторін. Для не-англомовних носіїв, технічний словник - RPO, RTO, перехід на іншу мову - може відчуватися особливо пригнічуючим. Окрім простого перекладу термінів, освоєння * фразування *, що використовується у професійних контекстах, є ключовим для того, щоб ваш план було зрозуміло і ефективно реалізовано. Давайте подивимося, як це перекладається на повсякденне спілкування на робочому місці.

Розглянемо коментар перегляду коду на запиті pull, що описує нове налаштування реплікації бази даних: «Поточний RTO 30 хвилин недостатній, враховуючи вплив на бізнес. Нам потрібно дослідити варіанти для зменшення цього, можливо, через синхронну реплікацію з гарантованою послідовністю даних. Чи можете ви розібратися у процесі відключення і його потенційному впливі на користувача?» Зауважте, що потрібні детальніші відомості — не лише про RTO, але і про його обґрунтування, пропозиції щодо рішень і передбачення питань щодо самого * процесу*. Використання фраз на кшталт « гарантована послідовність даних » має набагато більший вплив, ніж просто сказати « реплікація ». Це демонструє глибше розуміння основних технічних обставин.

Інший сценарій: повідомлення Slack під час критичного відключення. Уявіть, що ви отримуєте повідомлення: «System X experiences intermittent downtime. Розслідування потенційних проблем з базою даних. Негайна відповідь не повинна бути технічним жаргоном. Замість цього, ясно і чітко повідомлення, наприклад, “Гаразд, чи можете ви надати оцінений RTO для відновлення обслуговування? Який поточний вплив на користувачів - чи бачимо ми якісь конкретні помилки? “Це фокусується на * бізнес * наслідках простою, що призводить до пріоритетної відповіді на основі критичних показників. Формування ситуації як «перерваний простой» також більш професійне, ніж просто заява «система не працює», що може звучати тривожно і менш контролюється.

Нарешті, при написанні опису PR для нової процедури DR, уникайте надто технічної мови. Замість того, щоб сказати « Система автоматично запустить відновлення після виявлення помилки на головному сервері », спробуйте сказати: « У разі помилки на головному сервері система автоматично переключиться на допоміжний сервер, зменшуючи тим самим перешкоди для користувачів. Цей автоматизований процес забезпечує швидке відновлення і дотримується нашого визначеного RTO. ” Остання фраза є більш доступною і підкреслює * переваги * - мінімальні перерви - що в кінцевому підсумку турбує зацікавлених осіб. Звернення уваги на структуру речення — використання активного голосу, коли це можливо — може значно поліпшити ясність і професіоналізм.