Спостережуваність і надійність
Навіщо це
Section titled “Навіщо це”О третій ночі приходить сповіщення: сайт повільний. Що саме повільне: усі запити чи лише оплата? Одна зона доступності чи всі? Почалося після вчорашньої викатки чи за годину до неї? Без даних відповідь звучить як здогадка, а здогадки в аварії коштують хвилин.
Спостережуваність (observability) є здатністю відповідати на такі питання про систему за її зовнішніми сигналами, не змінюючи код і не заходячи на сервер. Надійність є другою половиною: коли ви бачите збій, треба знати, скільки його можна терпіти, і мати числа, за якими вирішується, чи зупиняти викатки й чинити систему, чи працювати далі.
Є й третя тема, про яку часто забувають: логи й метрики самі є рахунком. У розділі про вартість буде приклад, де один рядок логу на запит обходиться в тисячі доларів на місяць.
Передумови. Ролі й федерація (модуль 3), мережа й балансувальники (модуль 5), керовані бази (модуль 7), доставка й стратегії розгортання (модуль 10). Про системні виклики й eBPF, на яких будуються агенти, див. модуль 18 курсу ОС.
Метрики, логи, трейси
Section titled “Метрики, логи, трейси”Три види сигналів відповідають на різні питання, і жоден не замінює інші.
Метрика (metric) є числом, виміряним у часі: запитів за секунду, відсоток завантаження процесора, затримка на 99-му перцентилі. Метрики дешеві, бо агрегуються: мільйон запитів перетворюється на кілька чисел за хвилину. Вони відповідають на питання «чи є проблема і наскільки велика», але не на питання «чому».
Лог (log) є записом окремої події з текстом і полями: помилка, запит, рішення. Логи мають найбільшу деталізацію і найвищу ціну, бо зберігається кожна подія. Вони відповідають на питання «що саме сталося з цим запитом».
Трейс (trace) описує шлях одного запиту крізь кілька сервісів. Він складається зі спанів (span): кожен має початок, тривалість і батьківський спан. Трейс показує, що з 800 мс відповіді 700 витратила база даних, яку викликав третій сервіс. Відповідає він на питання «де саме тривало».
Головне вміння полягає в тому, щоб рухатися від одного сигналу до іншого.
Сповіщення спрацьовує за метрикою, трейс показує повільну ділянку, а лог
цієї ділянки містить помилку. Це можливо, лише якщо всі три сигнали
несуть спільний ідентифікатор запиту (trace id). Тому логи пишуть
структуровано, як JSON з полями, а не як вільний текст:
знайти trace_id=4bf9... у структурованих логах легко, а виловлювати його
регулярним виразом у мільйонах рядків дорого.
Для вибору метрик є перевірений мінімум, чотири «золоті сигнали» з книги Google SRE: затримка, трафік, частка помилок і насиченість (наскільки система близька до ліміту). Для сервісу «запит-відповідь» цього достатньо, щоб побачити майже кожну поширену проблему.
OpenTelemetry як нейтральний шар
Section titled “OpenTelemetry як нейтральний шар”Кожен провайдер має власні агенти й формати, тож інструментування, зроблене під CloudWatch, довелося б переписувати для Azure Monitor. OpenTelemetry (OTel) прибирає цю прив’язку до постачальника (vendor lock-in) там, де вона найдорожча, у коді застосунку. Проєкт належить CNCF і складається з чотирьох частин:
- API й SDK для мов програмування: код створює спани й метрики, а SDK їх збирає й пакує;
- семантичні конвенції: єдині назви атрибутів (
http.request.method,service.name), тож дашборди не залежать від того, хто написав сервіс; - протокол OTLP, яким сигнали передаються між компонентами;
- Collector: окремий процес, який приймає OTLP, обробляє дані (пакетує, фільтрує, дописує атрибути) і відправляє в один чи кілька бекендів.
Застосунок налаштовується змінними середовища й нічого не знає про хмару:
export OTEL_SERVICE_NAME=checkoutexport OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317Вибір бекенда переїжджає в конфігурацію Collector. Приймальна частина однакова для всіх:
receivers: otlp: protocols: grpc: http:
processors: batch:А експортери відрізняються:
exporters: awsxray: region: eu-central-1 awsemf: region: eu-central-1
service: pipelines: traces: receivers: [otlp] processors: [batch] exporters: [awsxray] metrics: receivers: [otlp] processors: [batch] exporters: [awsemf]Трейси йдуть у X-Ray, метрики в CloudWatch у вбудованому метричному форматі
(EMF). CloudWatch також приймає OTLP напряму: трейси на адресу вигляду
https://xray.РЕГІОН.amazonaws.com/v1/traces, логи на
https://logs.РЕГІОН.amazonaws.com/v1/logs, тож для простих випадків
Collector між застосунком і хмарою не обов’язковий.
exporters: azuremonitor: connection_string: ${env:APPLICATIONINSIGHTS_CONNECTION_STRING}
service: pipelines: traces: receivers: [otlp] processors: [batch] exporters: [azuremonitor] metrics: receivers: [otlp] processors: [batch] exporters: [azuremonitor] logs: receivers: [otlp] processors: [batch] exporters: [azuremonitor]Сигнали потрапляють в Application Insights, дані лежать у робочому просторі Log Analytics. Для застосунків без Collector Microsoft пропонує Azure Monitor OpenTelemetry Distro для .NET, Node.js і Python: один виклик у коді підключає інструментування й експортер.
exporters: googlecloud: project: acme-prod
service: pipelines: traces: receivers: [otlp] processors: [batch] exporters: [googlecloud] metrics: receivers: [otlp] processors: [batch] exporters: [googlecloud] logs: receivers: [otlp] processors: [batch] exporters: [googlecloud]Google Cloud Observability має власний OTLP-ендпоінт, Telemetry API
на telemetry.googleapis.com: клієнтові достатньо вказати кореневу адресу,
а шляхи /v1/traces, /v1/metrics і /v1/logs додаються автоматично.
Google також випускає власну збірку Collector.
Змінити бекенд означає змінити блок exporters і не чіпати жодного
рядка коду застосунку. Тому OTel вважають нейтральним шаром: він захищає
вкладення в інструментування, а не дані, які вже лежать у сховищі.
Як це в трьох хмарах
Section titled “Як це в трьох хмарах”| AWS | Azure | Google Cloud | |
|---|---|---|---|
| Метрики | CloudWatch Metrics | Azure Monitor Metrics | Cloud Monitoring |
| Логи | CloudWatch Logs | Azure Monitor Logs (Log Analytics) | Cloud Logging |
| Трейси | AWS X-Ray, CloudWatch Application Signals | Application Insights | Cloud Trace |
| Мова запитів до логів | Logs Insights QL | KQL | Logging query language |
| SLO | Application Signals | Azure Monitor SLI/SLO | Service Monitoring |
| Нативна OTLP-точка | так, для трейсів, логів і метрик | через Distro й експортери | Telemetry API |
Сервіс Google Cloud Observability раніше називався Cloud Operations (і ще раніше Stackdriver); у старих статтях трапляються всі три назви.
Ось однакові задачі командами. Прочитати недавні помилки й обмежити, як довго логи зберігаються:
aws logs start-query \ --log-group-name /app/checkout \ --start-time $(date -d '1 hour ago' +%s) --end-time $(date +%s) \ --query-string 'fields @timestamp, @message | filter @message like /ERROR/ | limit 20'
aws logs put-retention-policy \ --log-group-name /app/checkout --retention-in-days 30start-query повертає queryId, результат читають командою
aws logs get-query-results --query-id ....
az monitor log-analytics query \ --workspace 00000000-0000-0000-0000-000000000000 \ --analytics-query 'AppExceptions | where TimeGenerated > ago(1h) | take 20'
az monitor log-analytics workspace update \ --resource-group rg-obs --workspace-name law-prod --retention-time 30Перша команда вимагає розширення log-analytics, і Azure CLI запропонує його
встановити. Ідентифікатор у запиті є ідентифікатором робочого простору
(customerId), а не його назвою.
gcloud logging read 'severity>=ERROR AND resource.type="cloud_run_revision"' \ --freshness=1h --limit=20
gcloud logging buckets update _Default --location=global --retention-days=30SLI, SLO і бюджет помилок
Section titled “SLI, SLO і бюджет помилок”Сповіщення «процесор вищий за 80%» говорить про машину, а не про користувача. Користувачеві байдуже до процесора: йому важливо, що відповіді приходять і приходять швидко. Тому надійність вимірюють з його точки зору.
- SLI (service level indicator) є виміряною часткою вдалих подій: вдалі запити, поділені на всі допустимі. Наприклад: відповіді зі статусом не 5xx і швидше за 300 мс.
- SLO (service level objective) є цільовим значенням SLI за період: «99,9% запитів вдалі за 30 днів».
- SLA є юридичною обіцянкою клієнтові, зазвичай слабшою за SLO і з компенсацією, якщо порушена. SLA провайдера дає вам кредити, а не надійність, тож на ньому не будують архітектуру.
Різниця між 100% і SLO називається бюджетом помилок (error budget). Це кількість збоїв, яку ви вирішили терпіти. Ціль 100% недосяжна й недоречна: кожна наступна дев’ятка коштує дорожче, а користувач на телефоні з поганим зв’язком її вже не помітить.
Візьмемо сервіс з 10 мільйонами запитів на місяць і SLO 99,9%:
- бюджет помилок становить 0,1%, тобто 10 000 невдалих запитів за 30 днів;
- у часі це 43,2 хвилини повної недоступності (43 200 хв × 0,001);
- SLO 99,99% залишає лише 4,32 хвилини: людина, що отримала сповіщення, не встигне навіть відкрити ноутбук, тож виправляти має автоматика.
Бюджет змінює розмову між тими, хто випускає функції, і тими, хто тримає систему. Поки бюджет не вичерпано, команда викочує зміни, і ризик уже врахований. Якщо ж витрачено, викатки замінюють роботою над надійністю. Суперечка «стабільність проти швидкості» стає арифметикою.
Скільки може витримати ваша залежність
Section titled “Скільки може витримати ваша залежність”Сервіс не може бути надійнішим за те, від чого залежить синхронно. Якщо ваш запит проходить крізь три залежності по 99,9%, разом отримується 0,999 × 0,999 × 0,999 ≈ 99,7%, тобто 130 хвилин на місяць, а не 43. Тому для критичного шляху скорочують кількість послідовних залежностей або переходять на асинхронну обробку через чергу (модуль 9).
Сповіщення за швидкістю витрати бюджету
Section titled “Сповіщення за швидкістю витрати бюджету”Просте правило «помилок понад 1%» або спрацьовує на кожен спалах, або пропускає повільну деградацію. Швидкість витрати (burn rate) дорівнює відношенню поточної частки помилок до допустимої. При burn rate 1 бюджет витрачається рівно за 30 днів. При 14,4 закінчився б за 50 годин: 720 год / 14,4.
Робоча книга Google SRE пропонує кілька порогів, які комбінують два вікна, щоб відсіяти короткі сплески:
| Дія | Burn rate | Вікно | Витрата бюджету за вікно |
|---|---|---|---|
| Сповістити негайно | 14,4 | 1 година (і 5 хвилин для підтвердження) | 2% |
| Сповістити негайно | 6 | 6 годин (і 30 хвилин) | 5% |
| Завести тікет | 1 | 3 дні | 10% |
Для SLO 99,9% burn rate 14,4 означає частку помилок 1,44%. Кожна хмара може рахувати це сама: у Google Cloud це умова «SLO burn rate» в політиці сповіщень, в AWS вбудована підтримка є в Application Signals, а в Azure Monitor SLI й SLO нещодавно з’явилися як окремі об’єкти.
Вартість логів: прихована стаття
Section titled “Вартість логів: прихована стаття”Логи вимірюються обсягом, і ціна залежить від кількості байтів, а не від
корисності. Ось ціни на вересень 2026 (регіони us-east-1, eastus,
us-central1):
| CloudWatch Logs | Azure Monitor Logs | Cloud Logging | |
|---|---|---|---|
| Надходження, стандартний клас | $0.50 за ГБ | $2.30 за ГБ (Analytics logs, оплата за фактом) | $0.50 за ГіБ |
| Безкоштовно щомісяця | 5 ГБ | 5 ГБ на білінг-акаунт | 50 ГіБ на проєкт |
| Дешевший клас | Infrequent Access, $0.25 за ГБ | Auxiliary logs, $0.05 за ГБ | немає окремого класу |
| Зберігання | $0.03 за ГБ на місяць (архів) | 31 день включено, далі $0.10 за ГБ на місяць | 30 днів включено, далі $0.01 за ГіБ на місяць |
У CloudWatch запити Logs Insights оплачуються окремо, за обсяг просканованих даних, тому регулярний запит по місяцю логів теж є рядком рахунку. Читання логів у Cloud Logging, за даними Google, не тарифікується.
Приклад. Сервіс отримує 1000 запитів за секунду й пише один рядок логу розміром 1 КБ на запит. Це 1 МБ/с, або 86,4 ГБ за добу, або 2592 ГБ за місяць. Один INFO-рядок на запит без жодного ускладнення коштує на місяць приблизно:
- CloudWatch Logs: 2592 × $0.50 ≈ $1300;
- Azure Monitor Logs: 2592 × $2.30 ≈ $5960;
- Cloud Logging: (2414 ГіБ − 50) × $0.50 ≈ $1180.
На тих самих байтах Azure виходить приблизно вп’ятеро дорожче за два інші варіанти, але головна цифра спільна: тисячі доларів на місяць лише через рішення писати кожен запит. У Azure Monitor Logs є ще рівні з попередньою резервацією (commitment tiers): за резервацію 1000 ГБ на добу беруть $1700 на добу, тобто $1.70 за ГБ замість $2.30.
Метрики теж мають прихований множник, кардинальність. Кожна унікальна
комбінація значень міток є окремим часовим рядом. Якщо додати до метрики
мітку user_id і маємо 100 000 користувачів, отримаємо 100 000 рядів.
У CloudWatch перші 10 000 нестандартних метрик коштують $0.30 за метрику
на місяць, наступні $0.10, тож така мітка додасть приблизно
10 000 × $0.30 + 90 000 × $0.10 = $12 000 на місяць. Ідентифікатор користувача
належить логу або трейсу, але не мітці метрики.
Керують вартістю чотирма важелями:
- Рівень логування. У продакшні за замовчуванням WARN і вище, а DEBUG вмикають точково й ненадовго.
- Фільтри до збереження. Виключення перед записом коштує нуль, а після запису вже сплачене.
- Термін зберігання. Дані, які ніхто не відкриє через 30 днів, не мають лежати рік. Аудиторські журнали, які вимагає регулятор, кладуть в об’єктне сховище (модуль 6), де байт дешевший.
- Вибірка трейсів. Зберігати кожен трейс немає потреби: достатньо 1–10% звичайних і всіх помилкових.
resource "aws_cloudwatch_log_group" "checkout" { name = "/app/checkout" retention_in_days = 30 log_group_class = "INFREQUENT_ACCESS"}Клас Infrequent Access удвічі дешевший за стандартний на вході, але має обмежену функціональність. Перед вибором звірте перелік обмежень.
resource "azurerm_resource_group" "obs" { name = "rg-observability" location = "northeurope"}
resource "azurerm_log_analytics_workspace" "main" { name = "law-prod" location = azurerm_resource_group.obs.location resource_group_name = azurerm_resource_group.obs.name sku = "PerGB2018" retention_in_days = 30 daily_quota_gb = 50}daily_quota_gb є запобіжником: після ліміту прийом припиняється до
наступної доби. Так ви обмежуєте рахунок, але й втрачаєте логи, тому квоту
ставлять із сповіщенням заздалегідь.
variable "project_id" { type = string}
resource "google_logging_project_exclusion" "drop_debug" { name = "drop-debug-logs" project = var.project_id description = "Не зберігати DEBUG і нижчі рівні з контейнерів" filter = "severity < WARNING AND resource.type = \"k8s_container\""}
resource "google_logging_project_bucket_config" "app" { project = var.project_id location = "global" bucket_id = "app-logs" retention_days = 30}Виключення діє до збереження, тож відфільтровані рядки не тарифікуються як надходження.
Розбір: AWS us-east-1, 19–20 жовтня 2025
Section titled “Розбір: AWS us-east-1, 19–20 жовтня 2025”Джерело: офіційний постмортем (postmortem) AWS («Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region»). Усі часи нижче за тихоокеанським літнім часом (PDT), як у документі AWS; UTC на сім годин пізніше.
Хронологія. Збій почався о 23:48 PDT 19 жовтня (06:48 UTC 20 жовтня) і завершився о 14:20 PDT 20 жовтня, тобто тривав близько 14,5 години. Запис DNS для DynamoDB відновили о 02:25 PDT, після 2 годин 37 хвилин без нього; решту часу відновлювалися залежні системи.
Механізм у DynamoDB. Система керування DNS для DynamoDB складається з двох частин. Planner стежить за станом балансувальників і формує плани (набори IP-адрес для регіонального ендпоінта). Enactor, працюючи в трьох зонах доступності, застосовує плани в Route 53 транзакціями. Помилка виникла з гонки між двома Enactor, і кроки такі:
- Enactor 1 узяв план і перевірив, що він свіжіший за застосований. Далі він незвично довго затримався.
- Поки він чекав, з’явилися новіші плани. Enactor 2 застосував найновіший план і запустив очищення старих планів.
- Enactor 1 нарешті застосував свій застарілий план, перезаписавши новий: перевірка на свіжість була зроблена на початку й до цього моменту застаріла.
- Очищення Enactor 2 вважало цей план «дуже старим» і видалило його.
Разом з планом зникли всі IP-адреси регіонального ендпоінта
dynamodb.us-east-1.amazonaws.com, а система опинилася в стані, в якому жоден Enactor уже не міг застосувати нові плани. Виправили це вручну.
Розповсюдження. DynamoDB сама є залежністю для багатьох сервісів AWS, у тому числі для тих, що керують EC2:
- EC2 і DWFM. Менеджер DropletWorkflow Manager (DWFM) утримує оренди (lease) на фізичні сервери. Їх оновлення залежить від стану в DynamoDB, тож з 23:48 до 02:24 оренди спливали. Коли DynamoDB повернулася, DWFM кинувся відновлювати їх усі разом, і нові запити спливали швидше, ніж оброблялися: це класичний колапс від перевантаження (congestive collapse). О 04:14 інженери обмежили вхідну роботу й перезапустили хости DWFM; оренди відновилися до 05:28.
- Network Manager. Через затримки DWFM накопичилася черга розповсюдження мережевих конфігурацій: з 06:21 нові інстанси отримували мережу із запізненням.
- NLB. Перевірки стану починали працювати раніше, ніж мережа розповсюдилася, і вузли то виходили з ладу, то поверталися. Автоматичний перехід між зонами доступності знімав потужність з обігу, тож о 09:36 його вимкнули вручну (повернули о 14:09).
- Інші сервіси. Помилки викликів Lambda, контейнерні платформи, вхід через STS, консоль для користувачів IAM у N. Virginia, Redshift і Amazon Connect.
Що з цього випливає.
- Загальний час збою в 14,5 години, розтягнутий на всі залежні системи, становить понад 20 місячних бюджетів помилок для SLO 99,9% (870 хв проти 43,2). Один запис DNS, який відсутній 157 хвилин, дорівнює приблизно 3,6 бюджету.
- Автоматика без перевірки на «порожній результат» перетворила помилку на аварію. AWS вимкнула автоматику Planner і Enactor у всьому світі до виправлення й обіцяє додати запобіжники.
- Відновлення створює власне навантаження. Систему, яка вже впала, можна добити тим, що всі клієнти одночасно намагаються повернутися.
- Перевірки стану можуть шкодити: NLB, знімаючи вузли з обігу, посилював дефіцит. AWS додасть обмеження швидкості видалення потужності.
- Для вашої архітектури це аргумент за статичну стійкість (static stability): критичний шлях не повинен потребувати створення нових ресурсів або виклику площини керування (control plane) під час збою. Тримайте запас потужності й не покладайтеся на автомасштабування як на єдиний спосіб пережити проблему в регіоні (модуль 13).
Розбір: Google Cloud, 12 червня 2025
Section titled “Розбір: Google Cloud, 12 червня 2025”Джерело: звіт про інцидент Google Cloud Status. Часи за PDT (UTC на сім годин пізніше).
Хронологія. О 10:49 з’явилося багато помилок 503 у багатьох продуктах одночасно. Уже о 10:51 почалося офіційне повідомлення, о ~10:59 знайшли причину, о ~11:14 було готове рішення (у Google його називають «червоною кнопкою»), а о ~11:29 його розгорнули, і менші регіони відновилися. О 12:30 працювали всі регіони, крім us-central1; офіційно інцидент закрили о 13:49, тож загалом близько трьох годин. У us-central1 відновлення тривало до 2 годин 40 хвилин.
Механізм. Service Control є регіональною службою, яка виконує авторизацію, перевірки політик і квот для API-запитів; дані про політики й квоти вона читає з регіонального сховища на Spanner.
- 29 травня 2025 року Google додав у Service Control нову перевірку квотних політик і викочував її регіон за регіоном. Гілка коду, що обробляє ці дані, під час викатки жодного разу не виконувалася: для цього потрібна була саме така зміна політики, якої ще не було.
- 12 червня близько 10:45 у регіональні таблиці Spanner потрапила зміна політики з незаповненими полями. Метадані розповсюдилися глобально за секунди.
- Код зчитав порожнє значення й пішов у цю гілку. Вона не мала ні обробки помилок, ні захисту feature flag, яким можна було б її вимкнути. Виникло розіменування нульового вказівника (null pointer), і процес аварійно завершувався.
- Service Control стоїть на шляху запитів, а процеси падали в усіх регіонах водночас, тому API багатьох продуктів повертали 503. За словами Google, обхідного шляху для клієнтів не було.
Відновлення теж ускладнилося. Коли процеси Service Control у us-central1 масово перезапустилися, вони одночасно навалилися на Spanner. Без випадкової експоненційної затримки (randomized exponential backoff) виник ефект «зграї» (herd effect), і інженерам довелося вручну обмежувати створення задач і перенаправляти трафік.
Що з цього випливає.
- Дані, які розповсюджуються глобально й миттєво, є глобальною зміною без поетапного розгортання. Код викочували поступово, а дані, які його запускають, розповсюдилися одразу. Google пообіцяв поетапне розповсюдження таких даних.
- Нова гілка коду має вмикатися під feature flag (модуль 10): без нього вимкнути її можна лише відкатом усього, а тут довелося чекати «червону кнопку».
- Компонент на шляху кожного запиту має відмовляти відкрито (fail open) там, де це безпечно. Google обіцяє відокремити частини Service Control, щоб збій однієї не зупиняв решту.
- Для клієнтів це приклад спільної залежності: багаторегіональна схема захищає від збою регіону, але не від збою глобальної системи на шляху кожного запиту. Від такого захищає лише вміння працювати в деградованому режимі або інший провайдер.
Розбір: CrowdStrike і віртуальні машини Azure, 19 липня 2024
Section titled “Розбір: CrowdStrike і віртуальні машини Azure, 19 липня 2024”Джерела: аналіз причини від CrowdStrike (6 серпня 2024), блог Microsoft, рекомендації Microsoft для віртуальних машин Azure, звіт Azure про окремий збій у Central US.
Цей випадок відрізняється від двох попередніх: збій не був у хмарі. Відмовило програмне забезпечення клієнтів усередині їхніх власних віртуальних машин.
Що сталося. О 04:09 UTC 19 липня CrowdStrike випустила оновлення вмісту (Channel File 291) для сенсора Falcon на Windows. О 05:27 UTC його відкликали, тобто воно було доступне 78 хвилин. Сенсор працює як драйвер режиму ядра й підвантажує такі файли, щоб виявляти нові загрози без оновлення самого сенсора.
Механізм. Опис типу шаблону (IPC Template Type) вимагав 21 поле вхідних даних, тоді як сенсор надавав лише 20. Під час обробки інтерпретатор вмісту прочитав пам’ять за межами масиву. Причини, за аналізом CrowdStrike, були процесні: кількість полів не перевірялася під час компіляції сенсора, у рантаймі бракувало перевірки меж масиву, тести шаблону не покривали достатньо варіантів, а валідатор вмісту мав логічну помилку. Оскільки код виконувався в режимі ядра, помилка призводила не до аварії програми, а до аварії Windows: синього екрана, що повторювався при кожному завантаженні. Microsoft за вибіркою звітів про збої оцінила уражені пристрої в 8,5 мільйона машин Windows, що менше одного відсотка всіх.
Що це означало для Azure. Віртуальні машини Windows з агентом Falcon поводилися так само, як фізичні. Провайдер не міг їх «полагодити», бо гіпервізор працював справно, а ламався гостьовий код. Через модель спільної відповідальності (shared responsibility model, модуль 1) операційна система й усе, що на ній встановлено, залишається на боці клієнта. Microsoft опублікувала три способи відновлення:
- Перезавантажувати машину, іноді повторно: повідомлялося про випадки, коли потрібно було до 15 перезавантажень. За словами Microsoft, після перезавантаження агент Falcon часто встигає оновитися й отримує виправлений файл.
- Відновити з резервної копії, зробленої до 04:09 UTC 19 липня.
- Приєднати диск до допоміжної ВМ і видалити файли
C-00000291*.sysу каталозі драйверів CrowdStrike.
Третій спосіб і є єдиним, що не залежить від удачі: диск від’єднується
від ВМ, яка не завантажується, підключається до робочої, файл видаляється,
і диск повертається на місце. У хмарі така операція виконується командою (в Azure
для цього є az vm repair), але вручну для тисяч ВМ це години роботи.
Не плутати з іншим збоєм. Одночасно в Azure тривав окремий інцидент у Central US (ID 1K80-N_8): з 21:40 UTC 18 липня, а сховище відновили до 02:55 UTC 19 липня. Перелік дозволених адрес для сховища сформували з неповними даними про хости ВМ, і сховище відхиляло законні запити дисків. У настановах Microsoft ці два випадки названо різними. Для стороннього читача вони зливаються в одну «аварію Azure 19 липня», тому причину завжди треба звіряти з першоджерелом.
Що з цього випливає.
- Критичне програмне забезпечення з правами ядра, яке саме оновлюється за розкладом виробника, є залежністю без вашого контролю за розгортанням. CrowdStrike пообіцяла дати клієнтам керування поетапним розгортанням вмісту.
- Зі збою немає виходу, який залежить від самої хмари. Потрібні заздалегідь підготовлені процедури: образи з відомим станом, резервні копії, репетиція відновлення дисків і доступ до серійної консолі.
- Панель провайдера могла показувати сервіси справними, поки користувачі бачили синій екран. Тому SLI вимірюють з боку користувача.
Типові помилки розуміння
Section titled “Типові помилки розуміння”«Хмара доступна на 99,99%, отже мій сервіс теж». SLA провайдера стосується окремого сервісу. Ваш сервіс залежить від кількох сервісів, від вашого коду і від вашої конфігурації, тому його доступність нижча, ніж у кожного з компонентів.
«Сповіщення на кожну помилку кращі за сповіщення за SLO». Сповіщення на все призводить до втоми й ігнорування. Швидкість витрати бюджету сповіщає тоді, коли це справді загрожує цілі.
«Мультирегіональність рятує від будь-якого збою». Вона рятує від збою регіону. Збій глобальної системи (як Service Control) чи однакова помилка в конфігурації обох регіонів дістає обидва.
«Логи безплатні, бо вже є». Кожен байт надходження тарифікується, а зберігання додає ще. Ціна різниться між хмарами до п’яти разів.
«OpenTelemetry замінює сховище». Він стандартизує збирання й передачу сигналів. Сховище, запити й сповіщення лишаються за провайдером або іншим продуктом, і саме там ви платите.
«Провайдер винен у кожному збої, що з’являється в новинах». Збій CrowdStrike відбувся в клієнтському програмному забезпеченні, а сервіси Azure працювали. Про будь-яку аварію слід питати, у чиїй зоні відповідальності лежить механізм.
Перевір себе
Джерела
Section titled “Джерела”- AWS: Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region, 19–20 жовтня 2025
- Google Cloud Service Health: інцидент Service Control, 12 червня 2025
- CrowdStrike: Channel File 291 Incident Root Cause Analysis, 6 серпня 2024
- Microsoft: Helping our customers through the CrowdStrike outage
- Microsoft: Windows security best practices for integrating and managing security tools
- Microsoft Tech Community: Recovery options for Azure Virtual Machines affected by CrowdStrike Falcon agent
- Azure status history: 1K80-N_8 (Storage, Central US)
- Google SRE Workbook: Alerting on SLOs
- Amazon CloudWatch: ціни, Azure Monitor: ціни, Google Cloud: Cloud Logging pricing
- Google Cloud Telemetry (OTLP) API, CloudWatch OTLP endpoints, Azure Monitor OpenTelemetry
- Amazon CloudWatch: Service level objectives