Відмова GitHub, викликана зростанням трафіку через штучний інтелект та помилку конфігурації

9 лютого цього року, у пізню ночі за пекінським часом, мільйони розробників по всьому світу відкрили GitHub і побачили одну й ту саму сторінку.

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

github.com не працює.

API вимкнено.

GitHub Actions не працює.

Операції Git зупинилися — навіть Copilot не вдалося врятуватися.

Тієї ночі хтось зупинив свою CI/CD-пайплайн на найважливішому етапі, хтось застряг у напіврозгорнутому автоматичному розгортанні, а хтось чекав на PR, який ніяк не міг бути об’єднаний — за цим стояла функція, яка чекала на запуск, і користувачі, які чекали на неї.

Після цього GitHub опублікував звіт про інцидент. Коренева причина, за технічною термінологією, полягала в «перевантаженні основного кластера бази даних, відповідального за аутентифікацію та управління користувачами». Але за цими словами ховається ланцюжок тривожних подій —

Два дні тому інженерна команда, щоб якомога швидше впровадити нову модель для користувачів, змінила час оновлення «кешу налаштувань користувача» з 12 годин на 2 години. Саме ця зміна одного числового параметра.

Як наслідок, кеш-переписування, яке зазвичай розподілялося протягом 12 годин, було стиснене до 2 годин, що спричинило щільну «бурю кеш-переписування»: асинхронна черга завдань миттєво переповнилася, компоненти спільної інфраструктури зламалися, ланцюгова реакція поширилася на сервіс, відповідальний за проксування HTTPS-операцій Git, і в кінцевому підсумку призвела до вичерпання всіх підключень на платформі.

Число змінилося з 12 на 2.

GitHub був зламаний власним зміненим конфігом.

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

Інцидент 9 лютого — це не ізольована подія.

Насправді, за перші три місяці 2026 року GitHub зазнав щонайменше восьми серйозних аварій. Лише у лютому було зафіксовано 37 випадків різного ступеня складності. Пізніше CTO GitHub Влад Федоров у блозі визнав, що протягом цих двох місяців GitHub не зміг забезпечити обіцяну корпоративним клієнтам «три дев’ятки» — 99,9% доступності.

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

2 лютого: проблеми з постачальником обчислень Azure, GitHub Actions був недоступний майже 4 години, постраждали Copilot, CodeQL та Dependabot.

9 лютого: шторм перезапису кешу, перевантаження бази даних аутентифікації.

5 березня: відмова кластера Redis, 95% робочих процесів GitHub Actions не могли запуститися протягом 5 хвилин, середня затримка — 30 хвилин.

18 березня: затримка вебхуків зросла до 32 разів від нормального рівня.

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

На мові інженерів, фундамент GitHub уже почав тріскатися під тиском нових навантажень.

А цей «новий навантаження» має конкретну назву.

Ключові дані

Загальна кількість commit за 2025 рік: приблизно 1 мільярд

Кількість комітів за тиждень у 2026 році: 275 мільйонів

За цим темпом, прогноз на повний 2026 рік: 14 мільярдів (зростання на 14 разів щорічно)

Обчислювальна потужність GitHub Actions: 5 мільярдів хвилин на тиждень у 2023 році → 10 мільярдів у 2025 році → 21 мільярд хвилин на тиждень на початку 2026 року

Якщо б ви були інженером інфраструктури GitHub, порівняння інформаційних панелей моніторингу за 2025 та 2026 роки, мабуть, здивувало б вас.

У 2025 році GitHub обробив приблизно 1 мільярд комітів коду. Це число само по собі велике — результат багаторічного розвитку платформи GitHub. Але в 2026 році тижневий обсяг комітів досяг 275 мільйонів. Перераховуючи — якщо цей темп зберігатиметься протягом усього року, загальна кількість комітів у 2026 році наблизиться до 14 мільярдів, що в 14 разів більше, ніж у 2025 році.

Це не плавна крива зростання, а стрімкий схил. Зміни обчислювальних потужностей GitHub Actions краще це ілюструють: у 2023 році щотижня витрачалося 500 мільйонів хвилин, у 2025 році ця цифра подвоїлася до 1 мільярда, а потім на тиждень на початку 2026 року вона стрімко стрибнула до 2,1 мільярда хвилин.

Що таке божевільно надсилає код?

Не людина-розробник.

Дані GitHub показують, що AI Agent стає найактивнішим «користувачем» на цій платформі. Один лише інструмент Claude Code зараз забезпечує 4,5% усіх публічних комітів на GitHub. Щотижня — 2,6 мільйона комітів, тоді як кінець вересня 2025 року цей показник становив лише 100 000 — зростання в 25 разів за три місяці.

Кількість PR, відкритих AI-агентами, також стрімко зростає. У вересні 2025 року AI-згенеровані PR становили близько 4 мільйонів на місяць, а до березня 2026 року ця цифра стрибнула до 17 мільйонів — більше ніж у чотири рази за півроку.

Є зображення, яке допоможе вам зрозуміти, що це означає.

Раніше «користувачами» GitHub були переважно людські програмісти. Вони працювали вдень, спали вночі, відпочивали в вихідні, кожен коміт робили з думкою, з коливаннями, і їхня швидкість мала верхню межу. Навантаження системи слідувало за розкладом людей — були піки та спади, і воно було передбачуваним.

Зараз все більше «користувачів» — це AI-агенти. Вони не сплять, не відпочивають, не коливаються; одне завдання може запускати кілька паралельних агентів, кожен з яких може здавати більше роботи за годину, ніж справжній інженер за тиждень. Ще важливіше те, що вони не просто подають код — вони постійно створюють нові репозиторії, вважаючи репозиторії «вихідними продуктами» робочого процесу, а не «робочим простором» для людей.

Інженери інфраструктури GitHub стоять перед не просто більшою за обсягом версією тієї ж проблеми, а перед проблемою зовсім іншого роду.

Часті відмови — це лише одна сторона проблеми; GitHub має ще одну більш неприємну проблему — під час розрахунків виявляється, що ти втратив.

Початкова логіка ціноутворення Copilot ґрунтувалася на раціональному припущенні: користувачі в основному використовували його для «доповнення», кожна взаємодія була короткою, а обчислювальні витрати передбачуваними. Модель з ціною 10 доларів США на місяць для особистого використання та 19 доларів США на місяць для бізнес-версії, що сплачується за місце, добре працювала протягом останніх кількох років.

Потім з’явився агентний ШІ.

Агентні робочі процеси та традиційне доповнення — це два різні види. Стандартне доповнення коду має лінійний, передбачуваний запит і короткий обчислювальний цикл. Натомість агентний сеанс кодування може тривати кілька годин, одночасно запускаючи кілька паралельних потоків, виконуючи багатокрокові міркування, самокорекцію та рефакторинг між репозиторіями — один сеанс споживає кількість токенів, яка легко перевищує щомісячну абонентську плату звичайного користувача.

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

У відповідь на цю ситуацію GitHub діяв прямо — спочатку обмежив потік, а потім змінив ціну.

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

1 червня GitHub завершив більш фундаментальну реформу ціноутворення: Copilot повністю перейшов на оплату за використання, замінивши попередні пакети на «AI Credits» — 1 AI Credit дорівнює 1 центу, а використання обчислюється в реальному часі за спожитими токенами.

Ера плати за місце досягла кінця перед обличчям агентного ШІ.

Ця зміна — це не лише проблема GitHub. Це колективний кризис ціноутворення, який весь індустрія інструментів ШІ переживає у 2026 році — коли ШІ починає замінювати людей у виконанні цілих робочих процесів, а не просто «допомагати» людям у роботі, усі підписки на основі «за людину на місяць» стають неефективними.

Повернемося до питання інфраструктури. Як саме GitHub збирається вирішити цей «14-кратний ріст»?

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

Кінець грудня 2025 року агентні робочі процеси раптово почали прискорюватися. Інженери GitHub усвідомили, що вдесятеро недостатньо. До лютого 2026 року, після того як сталася серйозна зупинка, GitHub оголосив, що потрібно переробити архітектуру в 30 разів більше за поточний розмір.

Не розширення, а переробка.

Ці два терміни сильно відрізняються. Масштабування означає збільшення кількості існуючих серверів та додавання пам’яті до існуючих баз даних — напрямок залишається тим самим, змінюється лише масштаб. Переробка означає, що існуючі архітектурні припущення при 30-кратному збільшенні масштабу системно перестануть працювати, і необхідно з нуля переглянути підхід до розбиття сервісів, потоків даних та ізоляції відмов.

Деталі розкриття GitHub включають роз’єднання ключових сервісів для запобігання каскадним відмовам, введення механізмів зворотного тиску та здатності зниження трафіку, розгортання окремих хостів для гарячих сервісів, усунення точок одиночної відмови та більш досконале управління змінами — уникнення таких дій, як «зміна TTL кешу з 12 годин на 2 години» без достатнього навантажувального тестування.

Варто зауважити, що GitHub не одинокий.

Stripe вже зіткнулася з проблемою масового створення облікових записів за допомогою AI Agent, AWS розробляє спеціальні системи ідентифікації, логування та механізми контролю виробництва для агентів. Ці дії не є профілактичними — це відповідь на сигнали, які вже з’явилися на панелях моніторингу.

GitHub — це лише перший, який було проникнуто — бо він знаходиться в самому серці ланцюжка інструментів AI.

Зупиніться і подумайте про суть усього цього.

Що таке GitHub? Найбільш наочна відповідь: це місце, де програмісти зберігають свій код. Але глибше — це інфраструктура людської співпраці в розробці програмного забезпечення: коміти — це сліди співпраці, PR — контейнери для обговорень, Issues — збереження намірів, а Actions — канали виконання. Ціла система створена під людський темп роботи, спосіб мислення та моделі співпраці.

AI Agent змінив усе.

Коли AI-агент може надсилати сотні комітів за день, і за кожним «комітом» немає людського міркування чи зважування — лише крок у циклі виконання завдання — чи все ще є репозиторій коду «контейнером для співпраці»?

Коли інструменти ШІ автоматично створюють репозиторії, автоматично відкривають PR, автоматично запускають CI та автоматично об’єднують — чи залишаються розробники суб’єктами цього процесу, чи вони вже перетворилися на «рецензентів» або навіть «глядачів»?

Генеральний директор GitHub під час опису цього кризису використав термін «швидке зростання навантаження». Але цей термін, ймовірно, недооцінює суть проблеми — це не просто зростання обсягу, а якісна зміна способу використання. У старій моделі GitHub був «інструментом для розробників»; у новій моделі GitHub перетворюється на «вихлопну трубу для ШІ», канал виведення автоматизованих робочих процесів.

Це ще не має відповіді щодо GitHub. 30-кратне масштабування може вирішити проблеми з трафіком, але не зможе вирішити переозначення бізнес-моделі ні проблему «Хто мої справжні користувачі?».

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

Платформа, яка була прорізана власним успіхом, повинна розібрати себе і відбудувати з нуля — і цей процес сам по собі є випробуванням на здатність витримати.

Тієї ночі 9 лютого інженер, який чекав на об’єднання PR, напевно, все ж дочекався зеленого світла. Але він, можливо, не усвідомлював, що цей відмов у роботі, який змусив його чекати, — це не випадкова поломка GitHub, а звук, що оголосив про початок нової ери в індустрії розробки програмного забезпечення.

Цей матеріал з надрукованого веб-сайту WeChat «GeekPark» (ID: geekpark), автор: KosmonautMonkey