Спочатку напишіть відкат: шаблон для рутинних оновлень

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

Знайте, що реліз існує, до того, як він вам знадобиться

Ми публікуємо кожну нову збірку, з її changelog, у нашому операційному чаті в день її виходу.

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

Підготуйте зміну

Читайте changelog як контракт

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

Передпольотна перевірка кожного сервера

Потім перевірте кожен сервер, якого торкнетеся, а не парк загалом, і звірте список його плагінів, розширень та інтеграцій з новим релізом.

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

Зробіть backup, на який ви справді подивилися

«Завдання backup виконалося» не те саме, що «у нас є backup». Перед зміною зробіть узгоджений дамп і перевірте його:

mysqldump --single-transaction --routines --triggers --events <db> \
  | gzip > <db>-pre-upgrade-$(date +%F-%H%M).sql.gz
gzip -t <db>-pre-upgrade-*.sql.gz && ls -lh <db>-pre-upgrade-*.sql.gz

Напишіть відкат до зміни

Це крок, який перетворює ризиковане оновлення на рутинне. Перш ніж починати, запишіть, по порядку, точні кроки, які повернули б систему туди, де вона є зараз. У системах на базі RPM пакетна частина зазвичай коротка:

dnf history list | head
dnf history undo <transaction-id>

А щоб відомо робочий пакет не зрушив, поки ви тестуєте, плагін versionlock його закріплює:

dnf versionlock add <package>

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

Змінюйте по одній машині за раз

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

Вимірюйте і перевіряйте

Вимірюйте простій замість оцінювати його

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

while true; do
  printf '%s %s\n' "$(date +%T.%3N)" \
    "$(curl -s -o /dev/null -m 2 -w '%{http_code}' https://<service>/health)"
  sleep 0.5
done | tee upgrade-probe-$(date +%F).log

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

Перевірте ззовні, потім підтягніть ОС

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

Шаблон

1. Реліз помічено й оголошено, бекпорти промарковано.
2. Changelog прочитано на предмет виправлень безпеки, несумісних змін і міграцій.
3. Кожен сервер пройшов передпольотну перевірку, включно з кожним плагіном.
4. Свіжий backup зроблено і оглянуто.
5. Відкат написано, крок за кроком, до зміни.
6. По одному вузлу за раз, мажорні спочатку на власних системах.
7. Простій виміряно пробою, повідомлено в секундах.
8. Перевірено ззовні, ОС оновлено в тому самому вікні.

Якщо ваші платформи відстали і наступне оновлення здається проєктом, ми можемо допомогти вам повернутися до рутини. Поговоріть з інженером

Related (rows[1])

Пов’язане: Актуальність платформ і дисципліна оновлень · Реагування на критичні вразливості в той самий день · Моніторинг парку і маршрутизація тривог