Вступ: Орієнтація у складності хмарних розгортань
Уявіть це: ваша інженерна команда виконує стандартне розгортання за методикою blue-green на висококласній хмарній платформі. Перевірки на staging пройшли успішно, індикатори здоров'я зелені, і фінальний перехід ось-ось відбудеться. Проте, через кілька хвилин після запуску в реальну експлуатацію, ваші користувачі стикаються з помилками: “Сервіс недоступний”, “Часова помилка з'єднання”. Те, що здавалося звичайним випуском, перетворюється на кризову ситуацію.
Саме такий сценарій стався з Atlassian у 2019 році. Серія неправильних налаштувань під час розгортання призвела до масштабного збоїв, що підкреслює, як навіть незначні помилки можуть призвести до серйозних аварій. У цьому блозі ми розбираємо технічні деталі, аналізуємо корінні причини і виділяємо уроки, які повинен засвоїти кожен досвідчений інженер.
Інцидент: Що пішло не так
Серцем аварії Atlassian став їх хмарний балансувальник навантаження, критично важливий компонент для розподілу трафіку між серверами бекенду. Аварія розвивалася наступним чином:
1. Помилки під час розгортання за методикою Blue-Green
Було введено новий набір серверів (green), щоб замінити існуючі (blue). Хоча ця стратегія передбачена для безшовних переходів, нові сервери виявилися неготовими до роботи в реальному середовищі.
2. Кризи ресурсів: Помилки Out-of-Memory (OOM)
Незабаром після того, як зелені сервери почали обробляти трафік, вони зіштовхнулися з помилками OOM через недостатнє виділення пам'яті. Ці збої заважали обробці запитів.
3. Невідповідність налаштувань балансувальника навантаження
Балансувальник не зміг ефективно перенаправити трафік. Перевірки стану не виявили ресурсних проблем зелених серверів, що тільки погіршило ситуацію, направляючи трафік на сервери, що не працюють.
Негайний вплив
Користувачі пережили широкомасштабні збої в роботі сервісів, а інженери зазнали величезного тиску, намагаючись діагностувати і мінімізувати каскадні відмови.
Аналіз корінної причини: Ланцюг неправильних налаштувань
Інцидент виявив критичні прогалини в практиках розгортання та налаштуванні хмар:
1. Недостатнє попереднє прогрівання
Хмарні балансувальники навантаження масштабуються динамічно, але вони потребують попереднього прогрівання для обробки різких сплесків трафіку. Це було проігноровано, і балансувальник виявився неготовим до навантажень на рівні продакшн.
2. Неефективні перевірки стану
Перевірки стану зосереджувалися на пінгах на рівні додатків, але не враховували проблеми на рівні ресурсів, такі як перевантаження пам'яті. У результаті несправні сервери були визнані "здоровими".
3. Невідповідність масштабування ресурсів
Нові сервери були недостатньо налаштовані для роботи з продакшн-навантаженнями, що призвело до швидких збоїв. Тестування навантаження на staging не відтворювало умови реального трафіку.
Реакція Atlassian на інцидент: Шлях до відновлення
Негайні заходи
- Повернення до попереднього розгортання: Команда повернула трафік на стабільні сервери blue, щоб відновити роботу сервісу.
- Перенаправлення трафіку: Несправні зелені сервери були ізольовані, щоб вони більше не отримували живий трафік.
Довгострокові коригувальні заходи
- Перехід на поетапне розгортання: Atlassian перейшли на поетапні розгортання, поступово замінюючи сервери для мінімізації ризиків.
- Покращені механізми перевірки стану: Перевірки стану були оновлені для моніторингу критичних метрик, таких як використання пам'яті та навантаження на процесор.
- Стратегії попереднього прогрівання: У співпраці з хмарним провайдером Atlassian впровадили попереднє прогрівання, щоб підготувати балансувальник до різких сплесків трафіку.
Уроки для досвідчених інженерів
Цей інцидент надає корисні поради для архітекторів та старших розробників:
1. Глибоке розуміння поведінки балансувальників навантаження
Кожен хмарний балансувальник навантаження — AWS ELB, GCP Load Balancer тощо — має свої особливості. Ознайомтесь із порогами масштабування, механізмами відмов та нюансами перевірок стану.
2. Реалістичне тестування навантаження
Середовище staging повинно відтворювати трафік на рівні продакшн. Інструменти, такі як JMeter і Locust, можуть допомогти виявити потенційні вузькі місця до розгортання.
3.
Покрокові розгортання замість великих розгортань Big Bang
Покрокові розгортання дають кращий контроль, замінюючи лише частину серверів за раз, мінімізуючи вплив на систему загалом.
4. Прокачка моніторингу метрик
Налаштуйте сповіщення для порогових значень ресурсів (CPU, пам'ять, мережа). Використовуйте інформаційні панелі для реального часу відстеження стану системи.
5. Розвиток міцних партнерських відносин з хмарними провайдерами
Співпрацюйте з хмарними провайдерами, щоб використовувати просунуті функції, такі як попереднє прогрівання та налаштування масштабування під ваші потреби.
Будування стійких систем: Проактивні заходи
Щоб запобігти подібним інцидентам, розгляньте ці стратегії:
- Динамічне формування трафіку: Поступово збільшуйте трафік до нових інстансів під час розгортання.
- Автоматизовані відкатні механізми: Інтегруйте автоматизовані механізми відкату у ваші CI/CD пайплайни для неуспішних розгортань.
- Мульти-регіональна архітектура: Розподіляйте навантаження між різними регіонами для підвищення стійкості до відмов.
- Хаос-інженерія: Регулярно симулюйте відмови, щоб переконатися в стійкості системи при стресових навантаженнях.
Висновок: Стійкість через підготовленість
Аварія з балансувальником навантаження в Atlassian є попереджувальним прикладом для організацій, орієнтованих на хмарні технології. Це підкреслює необхідність ретельного тестування, надійних налаштувань та культури постійного навчання. Для старших інженерів це нагадування, що стійкість — це не лише про відновлення після збоїв, а й про їх передбачення та запобігання.
Приймаючи ці уроки, ми можемо створювати системи, які не лише ефективно відновлюються, але й надихають впевненістю у своїй надійності. Як ви забезпечуєте стійкість своїх розгортань? Поділіться своїм досвідом у коментарях — давайте вчитися разом.
Перекладено з: Lessons from Atlassian’s Load Balancer Outage: In-Depth Analysis and Critical Insights