Три класичні схеми каскадних провалів

Провали передають через залежності

Паттерн 1: Громовий стад. Об'єкт спільного використання (кач, блокування, база даних) згортається або перезапускається. Кожен клієнт, який залежить від нього, одночасно повторює спробу. Повтори перекриваєть поточний стан; повтори накопичуються швидше, ніж відновлення може їх вжити; відновлення ніколи не закінчується.

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

Паттерн 3: Смертельна черга. Оброблювальна черга без над壓ки обробляє швидше, ніж обробляє. Черга зростає безмежно. Пам'ять вичерпується; споживач згортається; перезапускається; знаходить ще більшу чергу; згортається знову.

Об'єднана нитка: невелика початкова порушення спрацьовує позитивний зв'язок. Відповідь системи посилює провал, а не гасить його.

Механізми гасіння

Експоненціальне затримання з джиттером. Клієнти, які повторюють, чекають довше кожен раз, з випадковим зсувом. Запобігає синхронним хвилям повторів.

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

Балка. Ізолюйте ресурси на залежність. Балка A для бази даних, окрема балка B для кешу. Повільна база даних не може зірвати всі підключення; виклики кешу продовжують працювати.

Відведення навантаження. Коли перегружено, відкидаєте запити на периферії, а не приймаєте та провалюєте повільно. 429 в 1 мс краще, ніж 500 в 30 секунд.

Надпірний тиск. Повільні виробники, коли споживачі не можуть утримати швидкість. Черги стають обмеженими; відправники блокують; початкова джерело роботи відчуває тертя.

Діагностуйте каскад

Підрозділ заривається під час планової міграції бази даних. Хронологія:

- 14:00:00 — оператор переводить резервну базу даних в режим роботи. Очікувана недоступність: ~10 секунд.

- 14:00:08 — основна база даних стає недоступною. Зарядка API починає віддавати помилки з'єднання з базою даних.

- 14:00:08 — API зарядка повторює (вимовна конфігурація: 5 повторів, без затримки, кожен через 100 мс).

- 14:00:11 — резерв переводиться в режим роботи, приймає нові з'єднання.

- 14:00:11 — API зарядка відкриває тисячі нових з'єднань з базою даних одночасно (кожна копія реплики × кожен паралельний запит × кожен повтор).

- 14:00:13 — нова основна база даних перевантажена пулом з'єднань; нові з'єднання відхиляються.

- 14:00:13-14:05:00 — реплики API перевантажені пулом з'єднань, кидають виключення, перезапускаються, повторюють.

- 14:05:00 — оператор вручну зупиняє трафік API; база даних стабілізується.

- 14:10:00 — повільне відновлення трафіку завершується. Загальна перерва: ~10 хвилин (проти очікуваної ~10 секунд).

DNS SERVFAIL: Два Впливові Вадливости

Правдивий Постмортем

Наступний текст - це санітована версія правдивого інциденту. Назви вендорів змінені, IPs анонімізовані; форма, хронологія та уроки справжні.

Огляд

Сайт example.com віддавав SERVFAIL з усіх публічних серверів DNS протягом приблизно 3-4 годин. Всі інші 46 зон на тому ж сервері DNS не були вплинути.

1. Вендор A (додатковий провайдер DNS) додав новий внутрішній IP синхронізації, який не був у списку allow-axfr-ips.

2. Зона example.com мала стару RFC-порушуючий конфлікт CNAME (demo.example.com мав як CNAME, так і MX/TXT на одній жетоні)

Хронологія (UTC)

- ~15:00 — Вендор A додає новий IP синхронізації 198.51.100.42 до своїх інфраструктур

- 15:02 — first AXFR-out denied for 198.51.100.42 appears in primary DNS logs (no alerting on this signal)

- ~18:00 — SOA expire window reached; Vendor A drops example.com zone from cache

- ~18:30 — SERVFAIL detected externally

- ~19:45 — root cause identified

- 20:00 — 198.51.100.42 added to allow-axfr-ips; primary restarted

- 20:05 — NOTIFY sent; AXFR initiated; zone STILL SERVFAIL (CNAME conflict)

- 20:07 — check-zone reveals 1 error: CNAME conflict on demo.example.com

- 20:09 — CNAME replaced with A record; zone check clean (0 errors)

- 20:10 — NOTIFY sent; AXFR completes; Vendor A begins serving zone

- 20:11 — dig @8.8.8.8 example.com A returns correct IP — RESOLVED

Чому лише example.com?

Все 47 зон partagerують одну та ж DNS-першу. IP-адреса AXFR вплинула на всі зони. Але лише example.com мав конфлікт CNAME, та лише example.com потрібна нова AXFR у момент, коли заборонили. Інші зони вже оновилися до моменту заборони або ще не потребували оновлення.

Схована вада

Конфлікт CNAME на demo.example.com існував роками. Він працював тому, що перша серверила зону зі своєї бази даних (дозволяючи порушеннями RFC) та Vendor A служив застарілі дані з кешу до моменту, коли порушення було введено. Коли Vendor A викинув свій кеш та потребував нових даних, порушення з'явилося.

Витяг

Vendor A безшумно додала нову IP-адресу для синхронізації. Allowlist першої не включала його. AXFR заборонено. Три години потому (SOA expire), Vendor A викинув зону. Схована вада з'явилася, коли система намагалася відновитися.

Написання безпрецедентних дій

Безпрецедент: Мета - системи, а не люди

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

Добрі безпрецедентні пункти дій зосереджуються в трьох ознаках:

- Попередження: зробити погане важчим або неможливим

- Виявлення: помітити це раніше, якщо це сталося

- Відновлення: обмежити збитки, коли це сталося

Кожен пункт повинен назвати (1) конкретні зміни в системі, (2) команду-оператора, та (3) ознаку, на яку він служить.

Компартименти, які потонуть без корабля

Отримано від військово-морського інженерного забезпечення

Кораблі мають водонепроникні перебірки: вертикальні стіни, які розділяють корпус на відсіки. Один відсік може затопитися без потоплення корабля; інший може зірватися без впливу на інші.

Розподілені системи позаймають ту саму фразу та ту саму ідею.

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

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

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

Кільцевий розбір

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

- Закритий (нормальний): виклики проходять. Невдачі відраховуються.

- Відкритий (зірваний): після порогу невдач (наприклад, 50% невдач за останні 30 секунд), розбір відкривається. Виклики миттєво зіштовхуються з невдачею без спроб звернення до залежності. Зберігає викликаючий від витрат на роботу; зберігає залежність від отримання навантаження, поки вона не здоров'я.

- Піввідкритий (тестування): після періоду відключення, розбір дозволяє невеликому відсотку викликів. Якщо вони успішні, він закривається назад до нормального. Якщо вони зіштовхуються з невдачею, він знову відкривається для іншого періоду відключення.

Ключове розуміння: кільцевий розбір запобігає витратам на роботу під час відомо-здоров'я періодів та дозволяє нижестримальній службі одужати без продовжуваного навантаження.

Перебірки обмежують радіус вибуху. Кільцеві розбір запобігають тривалому собі вибуху.

Ограничуйте радіус вибуху

Ваш сервіс API викликає чотири віддалені служби: User Service, Recommendation Service, Notification Service та третій Payment API. Команда почула, що 'Recommendation Service має бути трохи нестабільним' та хоче бути впевненим, що при його збої система залишається здоровою.

Сьогодні сервіс використовує єдину спільну поточну пул з 200 потоками та єдину спільну HTTP-кулюру. Всі чотири віддалені конкурують за ці ресурси. Не має циркуляційних зламів.

Організуйте Ревізію Збою

Синтез

Ви вчитеся виявляти SPOFs шляхом інспекції, визнавати шаблони каскадних збоїв, розділяти спрацювання від латентного дефекту при читанні постмортему, писати безпрецедентні дії по всьому попередженню / виявленню / відновленню та зв'язувати радіус вибуху за допомогою блоків ресурсів + циркуляційних зламів + гладкого зношування.

Застосуйте всі п'ять.

Ваші команда запускає нову службу search.example.com, яка залежить від трьох віддалених служб: основного пошукового індексу (index.example.com), аналітичної служби (analytics.example.com) та служби рекомендацій (recs.example.com). Команда хоче, щоб ви провели 'ревізію збою' перед запуском.

Куди Провадить Цей Курс

Куди Провадить Цей Курс

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

Останнє заняття в цьому курсі (cs_distsys_observability_and_capacity) вчить, що вимірювати потрібно, щоб виявляти проблеми, коли вони відбуваються, а не коли користувачі вже про це дізнаються. Провірки здоров'я, версійні конечні точки, чотири золоті сигнали на рівні проксі-сервера та як рішення про збільшену потужність пов'язані з спостережуваними даними.

Паралельне заняття: geometry_of_failure_modes_and_blast_radius вивчає міжнесумісність центальність (який графічний вузол є ботнеlem) та мінімальний переріз (границя радіусу вибуху).

Добре зроблено. Надалі.