Що робити, коли ваш застосунок на ШІ ламається о 2-й ночі (а ви не розробник)

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

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

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

Спершу: не передеплоюйте

Десь у вашому конструкторі застосунків на ШІ є кнопка, що каже щось на кшталт «перепублікувати», «передеплоїти» чи «відправити». Вам зараз захочеться її натиснути. Поки що не треба.

Натискання «передеплой» на наполовину зламаному застосунку може зафіксувати зламаний стан, знести будь-яку зневаджувальну інформацію, що лежала навколо, і ускладнити будь-кому — включно із самим конструктором на ШІ — з’ясувати, що пішло не так.

Перший хід — завжди дивитися, а не діяти. Ви ще навіть не підтвердили, що зламано.

Крок 1 — Відтворіть проблему самі

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

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

Ви шукаєте одне з трьох:

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

Запишіть, яке з трьох ви побачили. Воно знадобиться, коли проситимете по допомогу.

Крок 2 — Перевірте очевидні зовнішні речі, перш ніж винуватити свій застосунок

Напрочуд багато моментів «мій застосунок зламано» — це не ваш застосунок. Перш ніж занурюватися у свій конструктор на ШІ, перевірте:

Чи сам інтернет у порядку? Відкрийте кілька інших сайтів. Якщо ваш wifi глючить, ваш застосунок може бути в порядку, а зламаними можете бути ви.
Чи був у самого конструктора на ШІ збій? Більшість конструкторів застосунків на ШІ мають сторінку статусу (пошукайте назву продукту плюс «status»). Якщо в них погана ніч, вам не треба з’ясовувати нічого іншого.
Чи не лежить один із ваших під’єднаних інструментів? Якщо ваш застосунок використовує Stripe для платежів, поштовий сервіс для сповіщень чи сервіс бази даних для зберігання, у будь-якого з них можуть бути збої. Кожен має власну сторінку статусу. Перевірте ті, від яких залежить ваш застосунок.

Приблизно один раз із п’яти відповідь — «це насправді не мій застосунок», і ви можете повертатися спати.

Крок 3 — Подивіться на повідомлення про помилку, навіть якщо воно вас лякає

Якщо ваш застосунок показує екран із текстом — навіть текстом, що виглядає як абракадабра — прочитайте його. Зробіть скриншот. Особливо якщо є довгий рядок літер і цифр (люди називають це «стек-трейс»; виглядає як алфавітний суп, але це найкорисніша річ, яку ви можете мати, прохаючи по допомогу).

Більшість конструкторів застосунків на ШІ також мають місце, де можна бачити недавні помилки. Воно може називатися Logs, Activity, Errors чи Console. Відкрийте його. Вам не треба розуміти більшість того, що бачите — ви шукаєте найсвіжіший червоний текст чи найсвіжішу помилку й час, коли вона сталася. Час важить: помилка вчора зранку, ймовірно, не причина, чому ваш користувач щойно не зміг зареєструватися.

Скопіюйте цю помилку. За хвилину ви вставите її кудись корисно.

Крок 4 — Запитайте конструктор на ШІ, що змінилося

Це хід, який нетехнічні будівники недовикористовують найбільше. Відкрийте чат із конструктором на ШІ й скажіть, простими словами:

«Мій застосунок зламано. Користувачі не можуть зареєструватися — кнопка нічого не робить. Ось помилка з логів: [вставте її]. Що змінилося за останні 24 години і що могло це спричинити?»

Хороший конструктор на ШІ скаже вам, яка недавня зміна найімовірніше відповідальна. Іноді ви її одразу впізнаєте («о, я вчора попросив зробити форму гарнішою, і це, мабуть, зламало логіку надсилання»). Іноді він вкаже на щось, чого ви не пам’ятаєте, щоб торкалися, що теж корисно — це означає, що щось автоматичне змінилося, на кшталт оновлення під’єднаного інструмента.

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

Крок 5 — Вирішіть, чи відкочувати

Майже кожен конструктор застосунків на ШІ дає змогу повернутися до ранішої версії вашого застосунку. Іноді це називається «історія», «версії», «контрольні точки» чи «відкат».

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

Хороша засада: якщо зламана річ — це те, що користувачі роблять щодня (реєстрація, вхід, платіж), відкотіть спершу й лагодьте вперед потім. Робоче-але-застаріле б’є зламане-й-актуальне щоразу.

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

Крок 6 — Якщо вам таки треба дати конструктору на ШІ це виправити

Якщо відкат неможливий чи ви вирішили його не робити, тоді дайте конструктору на ШІ запропонувати виправлення. Дві речі тримайте в голові, поки він це робить:

Прочитайте, що він планує змінити, перш ніж затвердити. Ви не зрозумієте всього, але можете помітити, чи редагує він одну зосереджену річ, чи переписує половину застосунку. Маленькі, зосереджені зміни набагато безпечніші за масштабні о 2-й ночі.

Протестуйте виправлення найнуднішим можливим способом. Не просто питайте «це виправлено?» й довіряйте відповіді. Справді зайдіть у застосунок самі у вікні інкогніто й зробіть річ, що була зламана. Якщо виправлення спрацювало, зламана річ тепер працює. Якщо ні, не приймайте зміну лише тому, що конструктор на ШІ сказав, що вона спрацювала.

Крок 7 — Напишіть користувачу у відповідь, навіть якщо ви не виправили

Користувач, що написав вам о 1:47 ночі, не очікує, що ви онлайн. Але якщо ви онлайн, коротка відповідь важить більше за виправлення:

«Дякую, що повідомили — я зараз дивлюся. Напишу вам, щойно воно знову працюватиме».

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

Більший урок: будуйте свій застосунок так, ніби він може зламатися

Якщо вам це було стресово, світла сторона в тому, що цей досвід переформує те, як ви будуєте. Після свого першого інциденту о 2-й ночі ви почнете робити речі інакше:

Ви додасте перевірку статусу. Просту сторінку, що каже вам, чи працюють важливі частини вашого застосунку, щоб вам не треба було входити, щоб з’ясувати.
Ви триматимете резервну копію даних користувачів. Більшість конструкторів на ШІ експортують ваші дані на запит. Робити це раз на тиждень займає 30 секунд і рятує вас у найгіршому випадку.
Ви запишете, від чого залежить ваш застосунок. Короткий список кожного під’єднаного інструмента (платежі, пошта, база даних, сховище), щоб коли щось ламається о 2-й ночі, у вас був чекліст замість здогадок.
Ви мінятимете одну річ за раз. Коли ви робите 10 змін одразу й застосунок ламається, ви не маєте уявлення, яка зміна його зламала. Коли ви робите одну зміну за раз, маєте.

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

Хороша новина: щоразу, коли це стається, воно стає менш страшним. До третього разу це дратує замість того, щоб лякати. До десятого — це просто вівторок.