Что делать, когда ваше приложение на ИИ ломается в 2 часа ночи (а вы не разработчик)

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

Если вам никогда раньше не приходилось чинить живое приложение, этот момент может ощущаться ужасно. Вы не читаете код. Вы не знаете, что на самом деле значит «база данных». Вы не уверены, сломано-сломано оно или просто-странно, а те, кто обычно помог бы, спят.

Вот спокойный, упорядоченный сценарий того, что делать, когда приложение на ИИ ломается, а вы не умеете писать код. Бóльшая его часть — о том, как не сделать хуже, и это та часть, о которой никто не предупреждает.

Сначала: не передеплойте

Где-то в вашем ИИ-конструкторе приложений есть кнопка с надписью вроде «опубликовать заново», «передеплоить» или «выпустить». Вам вот-вот захочется её нажать. Пока не надо.

Нажатие «передеплоить» на наполовину сломанном приложении может закрепить сломанное состояние, стереть всю отладочную информацию, что валялась рядом, и затруднить — в том числе самому ИИ-конструктору — выяснение того, что пошло не так.

Первый ход — всегда смотреть, а не действовать. Вы ведь даже ещё не подтвердили, что именно сломано.

Шаг 1 — Воспроизведите проблему сами

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

Попробуйте сделать ровно то, о чём сообщил пользователь. Если он сказал, что кнопка регистрации не работает, попробуйте зарегистрироваться. Если он сказал, что дашборд пуст, попробуйте войти и посмотреть дашборд.

Вы ищете одну из трёх вещей:

Сломано у всех. Вы натыкаетесь на ту же проблему. Это, на самом деле, самый лёгкий для починки вид, потому что он стабилен.
У вас работает. Это самый сложный сценарий, потому что проблема в чём-то, специфичном для конкретной ситуации пользователя (его браузер, его аккаунт, его данные).
Это непостоянно. Один раз работает, а в следующий ломается. Это самое стрессовое, но и самое информативное — обычно это значит, что что-то истекает по таймауту или исчерпывает какой-то ресурс.

Запишите, какой из трёх вы увидели. Это понадобится вам, когда будете просить о помощи.

Шаг 2 — Проверьте очевидные внешние вещи, прежде чем винить своё приложение

Удивительное число моментов «моё приложение сломалось» — это не ваше приложение. Прежде чем нырять в свой ИИ-конструктор, проверьте:

В порядке ли сам интернет? Откройте пару других сайтов. Если ваш wi-fi барахлит, ваше приложение может быть в порядке, а сломанным можете быть вы.
Не было ли сбоя у самого ИИ-конструктора? У большинства ИИ-конструкторов приложений есть страница статуса (поищите название продукта плюс «status»). Если у них плохая ночь, вам не нужно выяснять что-либо ещё.
Не упал ли один из ваших подключённых инструментов? Если ваше приложение использует Stripe для платежей, почтовый сервис для уведомлений или сервис базы данных для хранения данных, у любого из них может быть сбой. У каждого своя страница статуса. Проверьте те, от которых ваше приложение зависит.

Примерно в одном случае из пяти ответ — «дело не в моём приложении», и вы можете снова лечь спать.

Шаг 3 — Посмотрите на сообщение об ошибке, даже если оно вас пугает

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

У большинства ИИ-конструкторов приложений также есть место, где можно увидеть недавно произошедшие ошибки. Оно может называться Logs, Activity, Errors или Console. Откройте его. Вам не нужно понимать большую часть того, что вы видите, — вы ищете самый свежий красный текст или самую свежую ошибку и время, когда она произошла. Время важно: ошибка со вчерашнего утра, вероятно, не причина того, что ваш пользователь не смог зарегистрироваться только что.

Скопируйте эту ошибку. Через минуту вы вставите её в полезное место.

Шаг 4 — Спросите ИИ-конструктор, что изменилось

Это ход, который недоиспользует большинство нетехнических разработчиков. Откройте чат с вашим ИИ-конструктором и скажите простым языком:

«Моё приложение сломано. Пользователи не могут зарегистрироваться — кнопка ничего не делает. Вот ошибка из логов: [вставить]. Что изменилось за последние 24 часа и что может это вызывать?»

Хороший ИИ-конструктор скажет вам, какое недавнее изменение наиболее вероятно виновато. Иногда вы сразу узнаете его («а, я попросил вчера сделать форму покрасивее, и это, наверное, сломало логику отправки»). Иногда он укажет на что-то, чего вы не помните, чтобы трогали, что тоже полезно — это значит, что что-то изменилось автоматически, например подключённый инструмент обновился.

Не давайте ИИ-конструктору начинать вносить исправления пока. Вы всё ещё в режиме диагностики. Самый частый способ, каким, как я видел, люди превращают маленькую проблему в бóльшую, — это позволить ИИ начать «чинить», прежде чем кто-либо понял, что сломано.

Шаг 5 — Решите, откатываться ли

Почти каждый ИИ-конструктор приложений позволяет вернуться к более ранней версии вашего приложения. Иногда это называется «история», «версии», «контрольные точки» или «откат».

Если вы ясно помните час или день, когда приложение работало, возврат к той версии — единственный самый надёжный ход. Он стоит вам тех изменений, что вы внесли в промежутке (которые вы, может, уже и не хотите), и даёт вам рабочее приложение, к которому вы проснётесь.

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

Если сломанное — это функция, которую вы добавили сегодня и от которой пока никто не зависит, можете оставить её сломанной до утра и починить со свежей головой.

Шаг 6 — Если приходится дать ИИ-конструктору чинить

Если откат невозможен или вы решили его не делать, тогда дайте ИИ-конструктору предложить исправление. Две вещи держите в голове, пока он это делает:

Прочитайте, что он планирует изменить, прежде чем одобрять. Вы не поймёте всего, но вы можете заметить, правит ли он одну конкретную вещь или переписывает половину приложения. Маленькие, сфокусированные изменения гораздо безопаснее размашистых в 2 часа ночи.

Протестируйте исправление самым скучным из возможных способов. Не просто спрашивайте «починено?» и доверяйте ответу. Реально зайдите в приложение сами в окне инкогнито и сделайте то, что было сломано. Если исправление сработало, сломанное теперь работает. Если нет — не принимайте изменение только потому, что ИИ-конструктор сказал, что оно сработало.

Шаг 7 — Напишите пользователю в ответ, даже если вы не починили

Пользователь, который написал вам в 1:47 ночи, не ожидает, что вы онлайн. Но если вы онлайн, короткий ответ значит больше, чем значило бы исправление:

«Спасибо, что дали знать — я смотрю прямо сейчас. Напишу вам, как только всё снова заработает.»

Если он платящий пользователь, это одно сообщение — разница между тем, расскажет ли он людям, что вы отвечаете быстро, или что вы пропали. Исправление может подождать до утра. Ответ — нет.

Урок побольше: стройте приложение так, будто оно может сломаться

Если вам было от этого стрессово, светлая сторона в том, что этот опыт изменит то, как вы строите. После вашего первого инцидента в 2 часа ночи вы начнёте делать вещи иначе:

Вы добавите проверку статуса. Простую страницу, которая говорит вам, работают ли важные части вашего приложения, чтобы не приходилось входить, чтобы это узнать.
Вы будете держать бэкап данных пользователей. Большинство ИИ-конструкторов экспортируют ваши данные по запросу. Делать это раз в неделю занимает 30 секунд и спасает вас в худшем случае.
Вы запишете, от чего ваше приложение зависит. Короткий список каждого подключённого инструмента (платежи, почта, база данных, хранилище), чтобы, когда что-то сломается в 2 часа ночи, у вас был чек-лист вместо догадок.
Вы будете менять по одной вещи за раз. Когда вы делаете 10 изменений сразу и приложение ломается, вы понятия не имеете, какое из них его сломало. Когда вы делаете по одному изменению за раз — понимаете.

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

Хорошая новость: каждый раз, когда это случается, становится менее страшно. К третьему разу это раздражает, а не пугает. К десятому это просто вторник.