GHES може не передати діагностичний пакет під час інциденту: що перевірити до 18 серпня

Пакет створився, але передавання не працює

Уявіть збій у GHES: розробники не можуть нормально працювати, команда вже зібрала діагностичний пакет, а інтерфейс командного рядка (CLI) не передає його до служби підтримки GitHub. Колеги чекають на діагноз, проте звичний шлях ескалації зупинився саме тоді, коли кожна хвилина важлива.

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

Саме такий ризик виникає після 18 серпня 2026 року. Тому перевіряти потрібно не лише стан GHES, а весь маршрут: визначити версію, створити пакет, передати його дозволеним способом і підтвердити, що підтримка може його прийняти.

Що зміниться 18 серпня

GitHub повідомив, що з 18 серпня 2026 року відхилятиме передавання з командного рядка діагностичних пакетів (support bundle) з екземплярів GHES без потрібних патчів безпеки. Зміна стосується процесів, у яких використовуються такі команди:

• ghe-support-bundle;
• ghe-cluster-support-bundle;
• ghe-support-upload.

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

Для перелічених у повідомленні гілок мінімальні версії такі: 3.21.3, 3.20.5, 3.19.9, 3.18.12 і 3.17.18. Екземпляр на нижчому патчі відповідної гілки потрібно позначити для оновлення. Непідтримувану гілку слід винести в окрему категорію: одного порівняння номера тут недостатньо, потрібен узгоджений перехід на підтримувану версію або план зі службою підтримки GitHub.

Крок 1. Знайдіть усі екземпляри, а не лише основний

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

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

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

Крок 2. Перетворіть оновлення на контрольовану зміну

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

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

Крок 3. Перевірте весь маршрут діагностичного пакета

Репетицію проводьте в погоджений час і за правилами роботи з діагностичними даними. Пакет може містити службову інформацію, тому не копіюйте його в довільне сховище й не передавайте через особисті канали.

Повна перевірка має підтвердити, що команда може:

1. обрати правильну команду для звичайної або кластерної інсталяції;
2. створити пакет і зафіксувати місце його збереження;
3. передати пакет затвердженим способом;
4. побачити підтвердження приймання, а не лише успішне завершення локальної команди;
5. видалити тимчасові копії відповідно до правил зберігання даних.

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

Якщо оновитися вчасно неможливо

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

Не варто самостійно вигадувати запасний спосіб, наприклад надсилати архів електронною поштою або завантажувати його у випадкове хмарне сховище. Такий обхід може порушити правила захисту даних і все одно не допомогти підтримці отримати пакет.

Типові помилки, які приховують ризик

Кілька скорочень створюють видимість готовності, але не доводять, що діагностичні дані справді можна передати:

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

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

Що додати до інструкції реагування

Короткий запис може виглядати так:

Умова: для аналізу інциденту потрібен діагностичний пакет GHES.
Перевірити: екземпляр, версію, стан кластера та номер звернення.
Створити: використати затверджену команду для цієї архітектури.
Передати: лише через погоджений канал служби підтримки GitHub.
Підтвердити: записати час і результат приймання пакета.
Якщо передавання відхилено: не публікувати архів; перейти до запасного контакту підтримки та залучити власника GHES.

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

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

Джерела

• GitHub Changelog — Upcoming GHES change impacting uploading support bundles