Технічна підтримка застосунку в Маркетплейсі: що ламається
Публікація в Маркетплейсі здається фінішем, але для власника застосунку саме там починається постійна робота.
Застосунок живе в чужих порталах: у кожного клієнта свої права, бізнес-процеси, зовнішні сервіси та налаштовані зв'язки, тому той самий код поводиться по-різному навіть на схожих впровадженнях.
Головне джерело збоїв після оновлення платформи — несподівана зміна контракту.
Обробник події, який учора спрацьовував штатно, після чергового оновлення ядра Битрикс24 перестає отримувати дані в очікуваному вигляді, і сценарій розвалюється без явної помилки: порожні поля, дублікати записів, мовчки пропущені дії. Помічає це не розробник, а клієнт — уже на своїх робочих даних.
Вузьке місце інтеграції майже завжди на стику із зовнішніми системами: синхронізація, вивантаження, черга.
Відмова тут зростає лавиною — один необроблений запис блокує пакет, пакет накопичує повтори, і потік звернень від клієнтів надходить одночасно в підтримку та у відгуки, де рейтинг падає швидше, ніж триває розбір причин.
Для власника продукту ціна такого збою — не години на виправлення, а втрачені встановлення та репутація: клієнт, у якого перший запуск упав, рідко дає другий шанс.
Підтримка застосунку в Маркетплейсі тому будується на випередженні, а не на розборі скарг, — далі розбираємо, як це закривається: від діагностики та перевірки сумісності до регламенту реакції.
Що дає виділена команда: ефект у вимірюваних показниках
Передача застосунку з Маркетплейсу Битрикс24 на супровід змінює не код, а режим роботи: замість одного автора, доступного за можливості, з'являється чергування за розкладом і регламент реагування.
Показники знімаємо двічі — спостерігаємо за застосунком на боці замовника до передачі та повторюємо заміри після виходу на робочий режим, тому в таблиці не оцінки, а динаміка за одними й тими самими метриками.
| Напрям | До передачі | Після передачі |
|---|---|---|
| Час реакції на інцидент | Від виявлення до першого відгуку минали години й залежали від зайнятості автора | Перший відгук чергового вкладається у погоджене вікно регламенту |
| Скорочення простоїв | Діагностику, відкат і виправлення робила одна людина послідовно | Ролі розділені: збір даних, відкат і правка йдуть паралельно |
| Зниження потоку звернень | Частина звернень повторювалася, рішення залишалися в листуванні | База типових випадків і сценарії самоперевірки; частка повторних звернень падає кратно |
| Передбачуваність релізів | Строки зсувалися, регрес ловили користувачі | Випуск за календарем, перевірка ключових сценаріїв проганяється до викочування |
| Покриття спостереженням | Про збій дізнавалися від клієнтів | Метрики та журнал інцидентів; частина відмов виявляється до звернення |
Ці напрями підсилюють один одного: чим раніше збій помічено спостереженням, тим коротший простій і тим менше звернень доходить до підтримки. У сумі застосунок переходить із режиму «працює, поки автор на зв'язку» в режим із передбачуваним відгуком і планованими оновленнями.
Формати роботи: чергування, пакет годин, повний цикл
Формат супроводу обирають за профілем навантаження на застосунок, а не за розміром команди. В одного продукту звернення йдуть рівним потоком встановлень і запитань, у іншого — сплеск після оновлення платформи або перевірки в Маркетплейсі.
Різниця між режимами — у тому, хто відповідає за час реакції і як закривається простій у момент інциденту.
Нижче — чотири режими, між якими реально обирають. Вони не взаємовиключні: часто беруть пакет годин на розвиток і чергування на інциденти, а зі зростанням навантаження переходять на повний цикл.
| Формат | Коли підходить | Обмеження |
|---|---|---|
| Чергування за регламентом | Стабільний застосунок із передбачуваним потоком звернень і обіцяним строком реакції | Потрібен регламент ескалації та черговий інженер у вікні; поза вікном реакція переноситься на наступний робочий день |
| Пакет годин інженерів | Доопрацювання та розбір завдань нерівним потоком, без цілодобових зобов'язань | Години не переносяться безстроково; при перевитраті пріоритет і строки перезбираються |
| Повний цикл супроводу | Регулярні релізи, вимоги до часу відновлення, робота із сумісністю версій | Потрібні доступи до репозиторію, моніторингу та тестового стенда; вхід займає довше |
| Разові доопрацювання | Точкові правки під конкретне встановлення або оновлення зовнішнього сервісу | Немає накопиченого контексту про продукт — кожне завдання починаємо із занурення |
Щоб запропонувати режим, дивимося журнал звернень і статистику встановлень за минулі періоди: за ними видно частоту сплесків і частку інцидентів, які не терплять до ранку. Цього достатньо, щоб погодити формат і план робіт.
Як ми впроваджуємо супровід: від аудиту до передачі
Супровід застосунку в Маркетплейсі починається не з чергування, а з розбору того, як він живе в контурі клієнта. Без карти обмінів і зовнішніх залежностей закриття заявок перетворюється на вгадування — тому порядок кроків фіксований і однаковий для всіх проєктів.
-
Аудит інтеграцій. Знімаємо карту обміну: які сутності йдуть у Битрикс24, що повертається через обробники та вебхуки, де стоять черги і що залежить від зовнішніх сервісів. Окремо позначаємо сценарії, в яких обмін падає мовчки.
-
Схема потоків і точок відмови. Позначаємо вузькі місця — таймаути, дублі, ліміти вивантаження, ручні дії адміністратора. На цю схему далі спираються і правки, і чергування.
-
Тестовий контур. Розгортаємо копію порталу з знеособленими даними: оновлення застосунку та правки обробників перевіряються на ньому, а не на живих користувачах.
-
Моніторинг. Налаштовуємо збір логів обміну та метрики за затримками і неуспішними викликами — алерт приходить раніше, ніж звернення користувача.
-
Регламент ескалації. Фіксуємо пріоритети, час реакції та канал зв'язку, а також того, хто на боці клієнта підтверджує випуск у робочий контур.
-
Перевірка на навчальному збої. Проганяємо інцидент від алерту до відновлення та уточнюємо регламент за фактичними кроками.
-
Передача в супровід. Віддаємо конфігурації, схему, журнал рішень і доступи черговій зміні — далі робота йде за погодженими строками реакції та плановими релізами.
На виході залишається не тека документів, а робочий процес: зрозуміла схема обмінів, тестовий контур під зміни та чергова зміна, яка знає порядок дій при відмові обміну.
Комплект документації та регламентів під час передачі
Комплект документації збирається по ходу робіт, а не в останній тиждень перед передачею — інакше він описує наміри, а не фактичний стан застосунку. Нижче — перелік артефактів, які залишаються в замовника та оновлюються за кожного релізу.
- Схеми інтеграцій — зовнішні сервіси, черги, вебхуки та вихідні запити, точки відмови і порядок деградації, якщо зовнішня система недоступна.
- Ролі та права доступу — матриця ролей порталу, набори дозволів застосунку та строки життя токенів, хто і що може змінювати в робочому контурі.
- Документація із супроводу — точки розширення, перевизначення ядра, фонові завдання та агенти, порядок міграцій і перелік місць, які правити не можна.
- Інструкції з відновлення — покроковий відкат оновлення, перевстановлення застосунку, дії при розсинхроні даних і контакти власників зовнішніх систем.
- Журнал змін — що і навіщо змінювалося від релізу до релізу, які оновлення ламали сумісність і як це виправляли.
- Регламент релізів — гілки, тестовий портал, порядок викочування на робочий контур і умови для термінового виправлення.
- Порядок ескалації — рівні критичності, строки реакції та перелік завдань, які підтримка вирішує без погодження.
Такий комплект знімає головну проблему передачі: підтримка не відновлює логіку застосунку за кодом. Новий інженер або ваша команда знаходять відповідь на питання «чому так зроблено» та «що робити при відмові» за хвилини, а не за дні розкопок.
Кейс: як зняли потік звернень після оновлення платформи
До нас потрапив застосунок з Маркетплейсу 1С-Битрикс — інтеграція із зовнішнім сервісом і кілька тисяч встановлень. Тестового контуру не було, перелік залежностей від платформи також ніхто не вів.
Після чергового оновлення підтримка отримала потік звернень: застосунок відвалювався у частини клієнтів, і кожен розбір починався з нуля.
Що показували звернення
Розібрали статистику за квартал: перша відповідь у середньому майже дві доби, близько третини звернень — повторні, щодо одного й того самого збою.
Основну частку давав один клас відмов: необроблена відповідь зовнішнього сервісу валила фонове завдання цілком, і підтримка гасила наслідки замість причини.
Що змінили і з чим вийшли
Зібрали окремий контур на даних, наближених до бойових, і перевірки, які на кожному релізі проганяють встановлення, оновлення та вимкнення застосунку — саме ці шляхи давали найбільше відмов.
Зовнішні виклики переписали на повтор із затримкою та зрозуміле повідомлення замість падіння завдання. Перед оновленнями платформи звіряємо використовувані виклики з журналом змін і випускаємо заміну раніше, ніж стара можливість вимикається.
- перша відповідь щодо критичних звернень — години замість доби;
- частка повторних звернень упала приблизно втричі: розбір закінчується правкою, а не тимчасовим обходом;
- клас відмов через необроблені відповіді зовнішнього сервісу зник із видимої частини застосунку;
- чергове оновлення платформи минуло без сплеску звернень.
Чим відрізняється підтримка застосунку від разових доопрацювань?
Разове доопрацювання закінчується прийманням: завдання закрили, збірку виклали, звіт віддали. Але застосунок продовжує жити в чужому середовищі — платформа оновлюється, вимоги Маркетплейсу Битрикс24 до прав і модерації змінюються, у користувачів з'являються нові сценарії. Постійний супровід потрібен тому, що після релізу нічого не завмирає.
Підтримка застосунку — це роботи, які не змінюють вимоги: стежити за доступністю, розбирати звернення, відтворювати збої на тестовому контурі, випускати виправлення та зберігати можливість відкату на попередню збірку.
Туди ж входить перевірка після оновлень платформи — частина відмов проявляється лише на нових версіях середовища, і знаходити їх у себе дешевше, ніж отримувати від користувачів.
Межа між підтримкою застосунку та доопрацюваннями проходить за вимогами, а не за розміром правки. Якщо робота повертає заявлену поведінку — це супровід: помилка в розрахунку, обмін, що відвалився, невірна відповідь після зміни формату.
Якщо поведінка змінюється — новий сценарій, поле, роль, інтеграція, розширення прав — оформлюється окреме завдання з описом, оцінкою та прийманням.
Змішувати потоки невигідно: доопрацювання витісняють регламентні роботи, відмови чекають у загальній черзі, а супровід перетворюється на набір разових звернень.
Тому ведемо журнал робіт, тримаємо окрему чергу змін і правило пріоритету: критична відмова обробляється поза чергою доопрацювань. Частка звернень, закритих без випуску нової функціональності, і час реакції показують, наскільки стійкий застосунок.
Часті питання із супроводу та доступів
Супровід застосунку в Маркетплейсі — це не лише код. Більша частина питань до старту — про доступи до робочого контуру, межі відповідальності та реакцію на зміни правил майданчика. Нижче — відповіді на технічні сумніви, з якими команди замовника приходять найчастіше.
Який доступ до робочого контуру вам потрібен?
Виділений користувач із роллю розробника та доступ лише до тестового контуру; до продуктива — за потреби та в режимі читання. Секрети, ключі та токени залишаються у вас, передаються через захищене сховище і підставляються змінними середовища. Доступ видається на час робіт і відкликається після завершення — слід у журналі аудиту залишається.
Хто відповідає за збій — майданчик чи застосунок?
Розділяємо за джерелом. Якщо відмовляє Битрикс24 — недоступність подій або вичерпання лімітів на виклики — показуємо це за логами та метриками, застосунок продовжує працювати в деградованому режимі.
Якщо причина в нашому коді, діагностика йде за пріоритетами: спочатку відновлення, потім розбір причин.
Що робити, якщо Маркетплейс змінює правила?
Відстежуємо вимоги модерації та регламенти майданчика, звіряємо набір запитаних дозволів із фактично використовуваними. Розбіжність — часта причина відхилення при оновленні.
Доопрацювання під нові правила оцінюємо окремо і ставимо в план; версія в тестовому контурі та в публікації синхронізовані.
Як виглядає робота при критичному збої?
Черговий інженер приймає алерт і підтверджує проблему протягом погодженого вікна реакції. Збірки версіонуються, попередній стабільний образ зберігається — відкат займає один крок, без перезбирання.
Після відновлення надсилаємо розбір: що зламалося, чому не зловили раніше, яка перевірка закриває цей клас відмов.
Якщо вашого питання тут немає — опишіть завдання, повернемося з оцінкою та планом робіт.Обговоримо завдання та повернемося з оцінкою і планом
Якщо застосунок уже опубліковано в Маркетплейсі, половину картини дає його експлуатаційна історія: звернення клієнтів, збої після оновлень ядра, простої. Щоб обговорити завдання предметно, а не за загальними словами, до розмови корисно зібрати:
- доступ до картки застосунку та прав порталу розробника — одразу бачимо версії, ліцензії та історію публікацій;
- вивантаження звернень у підтримку за кілька місяців і журнал помилок — за ними видно, де ламається частіше;
- перелік вбудов у інтерфейс і обробників подій, які працюють зараз;
- схему обміну з 1С і зовнішніми сервісами: які методи викликаються і з яким навантаженням;
- регламент випуску: як готується версія і що перевіряється перед публікацією;
- список того, що вже доводилося відкочувати, і з якої причини;
- контакт людини з вашого боку, яка ухвалює рішення щодо продукту.
За цими даними ми фіксуємо оцінку та план робіт: що закриваємо першим, які строки реакції та відновлення беремо, у якому порядку випускаємо версії.
Паралельно погоджуємо склад команди супроводу — черговий інженер першої лінії, розробник із ядра застосунку, відповідальний за релізи та перевірку перед публікацією.
Опишіть завдання та надішліть те, що вже є під рукою, — повернемося з оцінкою, планом робіт і пропозицією щодо складу команди.
