Як написати runbook для cutover міграції з годинником на кожному кроці

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

Проблема: ніч є найгіршим часом, щоб думати

Кожне рішення, ухвалене під час вікна (яка синхронізація йде першою, скільки чекати на репліку, коли здатися і відкотитися), ухвалюють втомлені люди під тиском, зазвичай з власником сайту на телефоні. Мета runbook у тому, щоб нікому не довелося під час вікна вирішувати нічого з того, що можна було вирішити тиждень тому.

Список завдань не є runbook. Runbook має п’ять колонок.

П’ять колонок

Крок	Бюджет	Відповідальний	Перевірка	Шлях назад
Заморозити записи на джерелі	2 хв	app	вхід адміністратора відхилено, черга замовлень порожня	зняти заморозку
Фінальна синхронізація файлів	3 хв	ops	rsync не перелічує подальших змін	не потрібен, джерело недоторкане
Фінальне наздоганяння бази даних і promote	3 хв	db	GTID однаковий з обох боків, ціль у режимі read write	demote цілі, розморозити джерело
Перемкнути DNS і балансувальник	2 хв	net	новий origin відповідає через публічне ім’я	повернути запис
Smoke-тести	5 хв	app	чекліст сторінок, вхід, оформлення замовлення, пошук	повернути DNS

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

До вікна: перемістіть майже все заздалегідь

Cutover має переміщувати лише те, що змінилося з останньої синхронізації. Усе інше відбувається за кілька днів до того, поки джерело продовжує обслуговувати:

• Побудуйте призначення з нуля за виміряними специфікаціями, замість відновлювати образи старих серверів.
• Засійте базу даних з фізичного backup і тримайте її актуальною реплікацією. Тієї ночі наздоганяння є справою секунд дельти.
• Попередньо синхронізуйте файли багаторазово, щоб останній прохід був малим. Зробіть пробний запуск за день до того, щоб побачити, що перемістить фінальний прохід:

rsync -aHAX --numeric-ids --delete --itemize-changes --dry-run \
      source:/var/www/ /var/www/ | wc -l

• Скопіюйте пошукові індекси власним віддаленим переіндексуванням рушія, а не повторним обходом контенту через застосунок.
• Знизьте TTL DNS до кількох хвилин щонайменше за два старі TTL до вікна, щоб резолвери забули довге значення до моменту перемикання. Перевірте, що насправді бачить світ:

dig +noall +answer www.example.com @<public-resolver-1>
dig +noall +answer www.example.com @<public-resolver-2>

Репетируйте на копії, із секундоміром

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

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

Напишіть критерії go або no go заздалегідь

Домовтеся, до вікна і з власником сайту, що має бути істинним, щоб почати, і що спричинить відкат:

• Go: затримка реплікації на призначенні нижча за узгоджену цифру, остання пробна синхронізація в межах бюджету, моніторинг призначення зелений, люди, названі в колонці відповідальних, присутні.
• Тригер відкату: будь-який крок, що перевищує подвійний бюджет, або smoke-тести, які не пройшли до фіксованого часу після перемикання.

Записаний тригер прибирає найнебезпечніший інстинкт будь-якої ночі cutover: «дайте ще десять хвилин». Якщо годинник каже відкотитися, ви відкочуєтеся і пробуєте знову іншої ночі з кращим runbook.

Зробіть шлях назад дешевим

Відкат, який вимагає відновлення з backup, не є відкатом, яким хтось захоче скористатися. Проєктуйте кожен крок так, щоб його скасування було швидким:

• Джерело залишається недоторканим і працює, доки призначення не доведе себе. Його дані ніколи не видаляються під час вікна.
• На призначенні все, що замінюється, перейменовується, а не видаляється. Повернення назад є перейменуванням і зміною DNS.
• Promote бази даних відбувається лише після того, як обидві сторони повідомляють однаковий GTID, тож demote повертає вас до відомої позиції.
• Зміни конфігурації застосовуються як файли, які можна поміняти місцями, а не як правки, які треба пам’ятати.

mv /var/www/site /var/www/site.pre-cutover-$(date +%F)
mv /var/www/site.new /var/www/site

Проведіть вікно, потім проведіть аудит

Під час вікна одна людина читає runbook уголос і записує фактичний час навпроти кожного бюджету. Ніхто не імпровізує. Коли останній smoke-тест проходить, залиште джерело працювати і спостерігайте за обома сторонами: трафік має стікати зі старого origin у міру того, як спливають кеші. Усе, що досі прибуває на джерело після того, як минув старий TTL, є залежністю, яку ніхто не вніс до списку, як-от завдання cron, клієнт API або жорстко прописана адреса, і її треба знайти, перш ніж джерело вимкнуть.

Після цього порівняйте нову платформу зі старим базовим рівнем: зовнішня експозиція, часи відповіді, частка влучань у кеш, частота помилок. Лише тоді виводьте джерело з експлуатації, і зберігайте його дані, доки власник не підпише приймання.

Ваш чекліст

• Кожен крок має бюджет, відповідального, перевірку і шлях назад.
• Дані засіяні і файли попередньо синхронізовані за кілька днів до того; вікно переміщує лише дельту.
• TTL знижені заздалегідь і перевірені ззовні.
• Хронометрована репетиція на копії, з уроками, внесеними до шаблону.
• Критерії go і відкату узгоджені письмово до тієї ночі.
• Джерело збережене недоторканим, доки аудит не завершено і власник не підписав приймання.

Якщо переїзд на вашому горизонті, ми радо допоможемо написати runbook.

Поговоріть з інженером

Related (rows[1])

Пов’язане: Міграції датацентрів з керуванням, відрепетирувані · Реплікація баз даних і віддалені репліки · Live migration і вихід з hypervisor