Критичні баги в мобільному застосунку: де ламається
Критичні баги в мобільному застосунку майже завжди живуть на стиках, а не в середині екранів. Холодний запуск — найчастіший сценарій відмови: падіння застосунку відбувається до відмалювання першого екрана, і користувач не розуміє, що взагалі сталося.
Другий за частотою — обрив сесії під час повернення з фону: термін дії ключа доступу минув, тихе продовження не спрацювало, і замість каталогу людина бачить порожній екран або форму повторного входу.
Найдорожче обходиться збій під час оплати. Платіж іде у шлюз, підтвердження не доходить до клієнта, кошти списано — замовлення не оформлено.
Це не просто втрачена покупка: користувач пише в підтримку й вимагає повернення, а розбір кожного такого випадку йде вручну та забирає час у команди, яка могла б займатися продуктом.
Окрема група — збої після оновлення версії. Нова збірка змінює структуру локального сховища, стара схема даних не мігрує, і застосунок падає в тих, хто встановив оновлення поверх попередньої версії.
Поруч стоять збої синхронізації після втрати мережі: накопичена черга запитів іде на сервер не в тому порядку, розходяться статуси замовлень.
Ціна такого збою — не лише нездійснені замовлення. Зростає потік звернень до підтримки, реліз доводиться зривати, а повернути попередню збірку через магазини застосунків швидко не вдасться: на публікацію та перевірку йдуть дні. Розбираємо, як це закривається.
Що змінює налагоджений розбір збоїв: ефект у цифрах
Метрики тут описують не «стало стабільніше», а конкретні величини: скільки часу минає від першого сигналу про збій до випуску виправлення, наскільки широко розходяться наслідки і як часто та сама відмова повертається.
Час до виправлення та вікно виявлення
Падіння або зависання в мобільному застосунку прив’язане до конкретної моделі пристрою, версії системи та ділянки сценарію.
Поки такі збої ловляться відгуками в магазині застосунків, вікно виявлення розтягується на дні, і на момент підтвердження відмова зачіпає помітну частку активних користувачів.
Автоматичний збір падінь — Crashlytics та подібні платформи — скорочує це вікно до годин: сигнал надходить із прив’язкою до збірки, пристрою та ланцюжка дій користувача.
Далі працює пріоритизація: спочатку лагодимо те, що блокує вхід, оплату й оформлення замовлення, решта йде в плановий випуск. Відтворення в тестовому контурі займає години, а не дні, тому час до виправлення перестає вимірюватися тижнями. Клас відмов, який раніше спливав лише в частини аудиторії, відсікається перевірками до випуску.
Частка повторних звернень щодо одного й того самого збою
Повторна відмова — ознака того, що причину заглушили, а не усунули. У розборі ми фіксуємо першопричину та закриваємо її перевіркою: сценарій, який призводив до падіння, потрапляє до набору автоматичних тестів, а на ту саму сигнатуру збою ставиться оповіщення.
На вимірюваннях реальних звернень частка повторних звернень щодо одного й того самого збою помітно знижується, а стабільність випуску стає вимірюваною величиною: кожне виправлення супроводжується перевіркою, що суміжні сценарії не зламалися.
Формати реакції на критичні баги: чергування, вікно виправлень
Критичний баг у проді не вирішується питанням «чи є вільний розробник» — режим реакції обирають заздалегідь. Робочих режимів два, і вони доповнюють один одного: постійне чергування з каналом оповіщення та вікно виправлень із правилами відкату.
Чергування та канал оповіщення
Черговий інженер отримує сигнал від системи моніторингу та підтверджує його до того, як про падіння напишуть користувачі.
Ротація та драбина ескалації фіксують, до кого йде сигнал, якщо перший черговий мовчить: загальний чат для цього не годиться, там повідомлення тоне в листуванні.
Вікно виправлень і правила відкату
Термінова правка йде поза звичайним регламентом випуску, але не замість нього: правило відкату узгоджують до початку робіт, а не в момент, коли збірка вже готова. Не знайшли причину за вікно — повертаємося на попередній випуск і продовжуємо розбір без тиску.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Постійне чергування з ескалацією | Платежі, авторизація, потік замовлень — простій помітний одразу | Потребує ротації та драбини оповіщення, вище організаційне навантаження |
| Чергування за розкладом | Навантаження зосереджене в робочі години | Ніч і вихідні залишаються без негайної реакції |
| Вікно виправлень із відкатом на попередній випуск | Інцидент зачіпає дані або платежі | Потрібна зворотна сумісність схеми даних |
| Плановий випуск за регламентом | Тексти, косметика, некритичні збої | Критичний баг чекає на найближчий випуск |
Як ми ведемо виправлення: від сигналу до перевірки
Критичний збій у робочому середовищі щогодини приносить втрачені сесії та звернення до підтримки, тому виправлення ведемо як конвеєр із фіксованими точками контролю. Порядок робіт однаковий для будь-якого сигналу — від приймання до передачі супроводу.
- Приймання та класифікація. Зводимо звіти про падіння, аналітику та звернення підтримки в один потік і рахуємо частку уражених сесій — вона задає пріоритет.
- Розбір сигналу. Зіставляємо збій із версією збірки, моделлю пристрою та версією системи, відновлюємо стек викликів.
- Відтворення збою. На стенді та на парку пристроїв доводимо сценарій до стабільного повторення — без цього правка перетворюється на вгадування.
- Правка та регрес. Мінімальна зміна в ураженому шляху плюс перевірки навколо: сусідні сценарії не повинні зламатися.
- Перевірка в робочому середовищі. Випускаємо хвилями, на кожній контролюємо частку збоїв.
- Передача супроводу. Причину, правку та перевірки фіксуємо в регламенті, щоб наступний схожий сигнал розбирався швидше.
Як будується розбір сигналу
Однакові падіння надходять десятками звітів, тому їх згортають в унікальні збої та сортують за часткою уражених сесій. Окремо перевіряють, чи відтворюється збій на конкретній моделі пристрою — це відсікає шум оточення. Стек викликів відновлюють за символами збірки: без цього у звіті залишається набір адрес.
Перевірка на реальних користувачах
Правка готова не після тестів, а після підтвердження на живому трафіку. Викочування йде хвилями — спочатку невелика частка аудиторії, потім решта, з автоматичним поверненням на попередню збірку, якщо частка збоїв виходить за поріг.
Регламенти, схеми та точки спостереження, які залишаються у вас
Роботи закінчуються не звітом, а набором артефактів, за якими ваша команда сама проведе розбір інциденту та випустить виправлення. Усе, що ми вибудовуємо в процесі, передається в робочому вигляді — із заповненими полями, а не шаблонами «на майбутнє».
Склад матеріалів, що передаються
- Регламент виправлень: рівні критичності, час реакції за кожним, хто ухвалює рішення про терміновий випуск і хто підтверджує відкат.
- Схема оповіщення: черговий канал, порядок ескалації, у який момент підключається керівник напряму.
- Матриця доступів і ролей: розмежування за репозиторієм, конвеєром збірки, сховищем релізів і панеллю спостереження — із зазначенням відповідальних.
- Документація щодо інциденту: шаблон розбору, куди пишуться причина, час виявлення та час до виправлення, і журнал уже розібраних випадків.
- Точки спостереження: набір сигналів і порогів, за якими збій видно раніше за скарги — частка падінь, зависання на старті, зростання помилок після публікації нової версії.
- Карта відкату: які збірки залишаються доступні в магазинах і реєстрах, як повернути попередню версію і що при цьому відбувається з локальними даними.
- Інструкція з відтворення: як зняти логи з пристрою, які стенди та облікові записи для цього потрібні.
Як підтримувати регламент без нас
Регламент живе, поки його переглядають. Пороги сигналів звіряємо з реальним потоком звернень раз на квартал: частина метрик застаріває після зміни версії системи або оновлення сторонніх модулів.
Після кожного великого інциденту шаблон розбору доповнюється новими полями — так накопичується база типових причин, і наступний схожий збій закривається швидше.
Чергового варто провести за схемою оповіщення на навчальному сценарії: імітуємо падіння та дивимося, чи вклалися в заявлений час реакції.
Розбір інциденту: час до виправлення до та після
Після релізу застосунок падав на підтвердженні оплати: спочатку в окремих користувачів, через добу — у кожного п’ятого. Сигнали про падіння в Firebase Crashlytics зростали, але не були прив’язані до конкретної дії користувача, а випуск виправлення займав дні. Розібрали кейс, де збій закрили не разовою правкою, а зміною процесу.
Що було до і що стало
| Показник | До | Після |
|---|---|---|
| Час від першого сигналу до виправлення в релізі | 4–6 днів | 6–10 годин |
| Частка повторних збоїв того самого класу | 38% | 4% |
| Збої, закриті до звернення користувача | 1 з 10 | 7 з 10 |
Істотніше за швидкість одного інженера виявився усунений клас відмов: падіння перестали повертатися в наступних релізах, бо причину фіксували як відтворюваний випадок, а не як точкову латку.
Що зробили інакше
Кожен реліз отримав мітку, за якою звіти про падіння розносяться за версіями, а не змішуються в один потік. Додали автоматичний збір контексту: екран, крок сценарію, стан сесії — цього вистачало, щоб відтворити збій без листування з підтримкою.
Налаштували правило автоматичного відкату на попередню версію при сплеску падінь у перші години після викочування та ввели обов’язковий перевірочний сценарій на кожен закритий інцидент. Час до виправлення скоротився, а частка повторних збоїв упала майже в десять разів.
Чим відрізняється термінове виправлення від планового релізу
Терміновий випуск — це зміна мінімальним дифом від тегу останнього стабільного релізу: у збірку потрапляє лише правка причини збою, усе інше залишається незмінним. Шлях до пристрою скорочується до годин, але перевіряється лише уражений сценарій, без повного прогону автотестів.
Звідси обмеження: терміновий випуск виправданий, коли збій роняє ключовий шлях — запуск, авторизацію, оплату — або зачіпає помітну частку пристроїв.
Плановий реліз накопичує правки та проходить повну регресію. Він передбачуваний і не залишає неперевірених ділянок, але цикл займає дні, а то й тижні: усе помічене чекає на наступне вікно викочування.
Якщо дефект не блокує користувача, лікувати його тут дешевше — менше ручних перевірок і нижчий ризик, що одна правка потягне за собою другу.
Відкат версії не лікує дефект, а повертає застосунок до останнього відомого робочого стану. Він обмежений двома умовами: попередня збірка справді стабільна, а серверна частина не змінила формат обміну даними настільки, що старий клієнт із нею не заговорить. Якщо схема даних уже мігрувала, відкат перетворює один збій на два.
Вибір режиму — це вибір класу ризику, а не швидкості. Ми дивимося на три ознаки: чи руйнується ключовий сценарій, чи є обхід, чи залишається минула версія сумісною із серверною частиною.
За цими відповідями видно, потрібен терміновий випуск, очікування планового релізу чи негайний відкат.
Доступи, строки та повторюваність: часті сумніви
Сумніви на старті рідко стосуються технології — частіше це організація: як швидко видадуть доступи, що робити з плаваючим збоєм, хто на зв’язку поза робочими годинами. Нижче — те, що обговорюємо до підписання плану робіт.
Які доступи до робочого середовища потрібні і як швидко їх видають?
Мінімальний набір — читання репозиторію, історія збірок, журнали падінь за релізами, метрики моніторингу та тестовий обліковий запис. Права лише на читання, видача через вашу систему управління доступами. Якщо частина джерел закрита, розбір іде за копіями логів і строки діагностики зростають.
Скільки часу займає вхід у проєкт?
Перший день іде на збір картини: які релізи уражені, на яких пристроях збій повторюється, що змінювалося перед першим випадком. Далі — відтворення на стенді або на групі користувачів. Оцінку та план фіксуємо до початку правок.
Збій плаваючий і ловиться один раз із десяти. Що тоді?
Діагностуємо телеметрією: розширений збір подій у збірці для групи користувачів, кільцевий буфер логів, розмітка сесії до падіння. Якщо причину не спіймано, ставимо захист від повторення сценарію та продовжуємо спостереження — так закривається клас відмов, а не один випадок.
Як влаштовано чергування і хто за що відповідає?
Фіксуємо вікно реакції на інцидент, склад чергових і порядок ескалації. Наша сторона — діагностика, виправлення та перевірка на регрес, ваша — доступи, вікна релізів і публікація збірки. Відкат на попередню версію тримаємо штатним сценарієм, а не аварійним.
Обговоримо задачу: що надіслати і як почнемо роботу
Чим точніші вхідні дані, тим швидше ми виходимо на причину критичного збою та на оцінку робіт. Нижче — те, що допомагає почати розбір без довгого листування: за цими матеріалами інженер одразу бачить картину та називає, де шукати вузьке місце.
- Симптоми та частота: на яких версіях системи й моделях пристроїв падає застосунок, чи відтворюється збій стабільно і в якому сценарії.
- Логи та звіти про падіння за період: стек викликів, ідентифікатори сесій, умови, за яких падіння повторюється.
- Доступ до репозиторію та збірки: гілка, у якій ведеться розробка, і канал, через який викладаються тестові збірки.
- Схема релізів: як часто виходять оновлення, хто підтверджує публікацію в магазинах застосунків.
- Перелік пов’язаних сервісів: серверна частина, повідомлення, оплата, аналітика, карти.
- Обмеження: вимоги до захисту даних, регламент доступів, вікна, коли допустимо випускати виправлення.
Порядок далі простий. Обговорюємо задачу, зіставляємо симптоми з логами та повертаємося з оцінкою і планом: що правимо в першу чергу, як перевіряємо і як відкочуємо, якщо виправлення не підтвердилося. Після узгодження стартують роботи.
Формат співпраці — разовий розбір критичного збою або постійний супровід із чергуванням за аварійними ситуаціями.
