وقتی اپی که با هوش مصنوعی ساخته‌اید ساعت ۲ بامداد خراب می‌شود چه کنید (و شما برنامه‌نویس نیستید)

اپتان دیروز کار می‌کرد. حالا نیمه‌شب است و چیزی ایراد دارد. این هم یک راهنمای آرام و غیرفنی برای اینکه واقعاً چه کار کنید — بدون اینکه بتوانید کد بخوانید.

یک اپ ساختید بدون اینکه حتی یک خط کد بنویسید. تمام هفته کار کرد. بعد یک کاربر ساعت ۱:۴۷ بامداد به شما پیام می‌دهد که دکمهٔ ثبت‌نام هیچ کاری نمی‌کند، و شما با درخشش گوشی روی پاتختی از خواب بیدار می‌شوید.

اگر هیچ‌وقت مجبور نشده‌اید یک اپ زنده را درست کنید، این لحظه می‌تواند وحشتناک حس شود. شما کد نمی‌خوانید. نمی‌دانید «پایگاه داده» واقعاً یعنی چه. مطمئن نیستید خرابِ خراب است یا فقط عجیب، و آدم‌هایی که معمولاً کمکتان می‌کنند خواب‌اند.

این هم یک راهنمای آرام و مرتب برای اینکه وقتی اپی که با هوش مصنوعی ساخته شده خراب می‌شود و شما نمی‌توانید کد بنویسید چه کنید. بیشترش دربارهٔ بدتر نکردن اوضاع است، که بخشی است که هیچ‌کس به شما هشدارش را نمی‌دهد.

اول: دوباره منتشر نکنید

جایی در اپ‌ساز هوش مصنوعی‌تان دکمه‌ای هست که چیزی شبیه «بازانتشار»، «استقرار مجدد» یا «عرضه» می‌گوید. شما دارید به مرز فشار دادنش می‌رسید. هنوز نه.

فشار دادن استقرار مجدد روی یک اپ نیمه‌خراب می‌تواند حالت خراب را قفل کند، هر اطلاعات اشکال‌زدایی داده‌ای را که این دور و بر بوده از بین ببرد، و کار را برای هر کسی — از جمله خود اپ‌ساز — برای فهمیدن اینکه چه چیزی اشتباه پیش رفته سخت‌تر کند.

اولین حرکت همیشه نگاه کردن است، نه عمل کردن. شما حتی هنوز تأیید نکرده‌اید چه چیزی خراب است.

قدم ۱ — مشکل را خودتان بازتولید کنید

اپ را در یک پنجرهٔ تازهٔ مرورگر باز کنید — حالت ناشناس یا خصوصی بهترین است، چون هر ورود یا کش قدیمی را که ممکن است باعث شود چیزها برای شما متفاوت از کاربرتان رفتار کنند حذف می‌کند.

سعی کنید دقیقاً همان کاری را که کاربر گزارش داده انجام دهید. اگر گفتند دکمهٔ ثبت‌نام کار نمی‌کند، سعی کنید ثبت‌نام کنید. اگر گفتند داشبورد خالی است، سعی کنید وارد شوید و داشبورد را ببینید.

دنبال یکی از سه چیز می‌گردید:

  1. برای همه خراب است. شما به همان مشکل می‌خورید. این در واقع آسان‌ترین نوع برای رفع کردن است، چون پایدار است.
  2. برای شما کار می‌کند. این سخت‌ترین سناریوست، چون چیزی دربارهٔ موقعیت خاص کاربر (مرورگرش، حسابش، داده‌اش) مشکل است.
  3. متناوب است. یک‌بار کار می‌کند و دفعهٔ بعد خراب می‌شود. این پراسترس‌ترین است اما همچنین آموزنده‌ترین — معمولاً یعنی چیزی دارد منقضی می‌شود یا یک منبع دارد تمام می‌شود.

بنویسید کدام‌یک از این سه را دیدید. وقتی درخواست کمک می‌کنید بهش نیاز خواهید داشت.

قدم ۲ — قبل از مقصر دانستن اپتان، چیزهای بدیهی بیرونی را بررسی کنید

تعداد شگفت‌آوری از لحظه‌های «اپم خراب است» اصلاً اپ شما نیست. پیش از آنکه در اپ‌سازتان غواصی کنید، این‌ها را بررسی کنید:

  • آیا خود اینترنت مشکلی ندارد؟ چند سایت دیگر را باز کنید. اگر وای‌فای‌تان ناپایدار است، شاید اپ شما خوب باشد و شما آن خرابه باشید.
  • آیا خود اپ‌ساز قطعی داشته؟ اکثر اپ‌سازهای هوش مصنوعی یک صفحهٔ وضعیت دارند (نام محصول به‌علاوهٔ «status» را جست‌وجو کنید). اگر آن‌ها شب بدی دارند، لازم نیست چیز دیگری بفهمید.
  • آیا یکی از ابزارهای متصلتان از کار افتاده؟ اگر اپ شما از Stripe برای پرداخت، یک سرویس ایمیل برای اعلان‌ها، یا یک سرویس پایگاه داده برای ذخیرهٔ داده استفاده می‌کند، هر کدام از این‌ها می‌توانند قطعی داشته باشند. هر کدام صفحهٔ وضعیت خودش را دارد. آن‌هایی را که اپتان به آن‌ها وابسته است بررسی کنید.

تقریباً یک‌بار از هر پنج بار، پاسخ این است که «در واقع اپ من نیست»، و می‌توانید برگردید بخوابید.

قدم ۳ — به پیام خطا نگاه کنید، حتی اگر بترساندتان

اگر اپتان صفحه‌ای با متن روی آن نشان می‌دهد — حتی متنی به‌ظاهر بی‌معنی — بخوانیدش. یک اسکرین‌شات بگیرید. به‌خصوص اگر یک رشتهٔ طولانی از حروف و اعداد هست (مردم به این می‌گویند «استک‌ترِیس»؛ شبیه سوپ الفبا به نظر می‌رسد اما مفیدترین چیزی است که می‌توانید موقع درخواست کمک داشته باشید).

اکثر اپ‌سازهای هوش مصنوعی هم جایی برای دیدن خطاهایی که اخیراً رخ داده دارند. شاید نامش Logs، Activity، Errors یا Console باشد. بازش کنید. لازم نیست اکثر آنچه می‌بینید را بفهمید — دنبال جدیدترین متن قرمز یا جدیدترین خطا هستید، و زمانی که اتفاق افتاده. زمان مهم است: یک خطا از دیروز صبح احتمالاً دلیل این نیست که کاربرتان همین الان نتوانست ثبت‌نام کند.

آن خطا را کپی کنید. تا یک دقیقهٔ دیگر می‌خواهید جایی مفید بچسبانیدش.

قدم ۴ — از اپ‌ساز بپرسید چه چیزی تغییر کرد

این حرکتی است که اکثر سازندگان غیرفنی کم از آن استفاده می‌کنند. گفت‌وگو با اپ‌سازتان را باز کنید و به زبان ساده بگویید:

«اپم خراب است. کاربران نمی‌توانند ثبت‌نام کنند — دکمه هیچ کاری نمی‌کند. این هم خطا از لاگ‌ها: [بچسبانید]. در ۲۴ ساعت گذشته چه چیزی تغییر کرد، و چه چیزی می‌تواند باعث این باشد؟»

یک اپ‌ساز خوب به شما خواهد گفت کدام تغییر اخیر محتمل‌ترین مسئول است. گاهی فوراً می‌شناسیدش («آها، دیروز ازش خواستم فرم را قشنگ‌تر کند و این احتمالاً منطق ارسال را خراب کرده»). گاهی به چیزی اشاره می‌کند که یادتان نمی‌آید بهش دست زده باشید، که آن هم مفید است — یعنی چیزی به‌صورت خودکار تغییر کرده، مثل یک ابزار متصل که به‌روزرسانی شده.

نگذارید اپ‌ساز هنوز شروع به اعمال رفع‌ها کند. شما هنوز در حالت تشخیص هستید. رایج‌ترین راهی که دیده‌ام مردم یک مشکل کوچک را بدتر می‌کنند، اجازه دادن به یک هوش مصنوعی برای «درست کردن» چیزها پیش از آن است که کسی بفهمد چه چیزی خراب است.

قدم ۵ — تصمیم بگیرید که برگردانید یا نه

تقریباً هر اپ‌ساز هوش مصنوعی به شما اجازه می‌دهد به نسخهٔ قبلی اپتان برگردید. گاهی نامش «تاریخچه»، «نسخه‌ها»، «نقاط بازرسی» یا «بازگردانی» است.

اگر می‌توانید به‌روشنی ساعت یا روزی را که اپ کار می‌کرد به یاد بیاورید، برگشتن به آن نسخه قابل‌اعتمادترین حرکت تنهاست. به قیمت هر تغییری که در این فاصله کرده‌اید تمام می‌شود (که شاید دیگر حتی نخواهیدشان)، و یک اپ کارآمد به شما می‌دهد که با آن بیدار شوید.

یک قاعدهٔ خوب: اگر چیز خراب چیزی است که کاربران هر روز انجامش می‌دهند (ثبت‌نام، ورود، پرداخت)، اول برگردانید و بعداً به جلو درست کنید. کارآمد-ولی-قدیمی هر بار از خراب-ولی-روز بهتر است.

اگر چیز خراب قابلیتی است که امروز اضافه کرده‌اید و هنوز هیچ‌کس به آن وابسته نیست، می‌توانید تا صبح خراب رهایش کنید و با ذهنی آرام درستش کنید.

قدم ۶ — اگر مجبورید بگذارید اپ‌ساز درستش کند

اگر برگرداندن ممکن نیست، یا تصمیم گرفته‌اید برنگردانید، آنگاه بگذارید اپ‌ساز یک رفع پیشنهاد دهد. دو چیز را موقع انجامش به یاد داشته باشید:

پیش از تأیید بخوانید قرار است چه چیزی را تغییر دهد. همه‌اش را نخواهید فهمید، اما می‌توانید تشخیص دهید که آیا دارد یک چیز متمرکز را ویرایش می‌کند یا نیمی از اپ را بازنویسی می‌کند. تغییرات کوچک و متمرکز ساعت ۲ بامداد بسیار امن‌تر از تغییرات فراگیر هستند.

رفع را به کسل‌کننده‌ترین شکل ممکن آزمایش کنید. فقط نپرسید «درست شد؟» و به پاسخ اعتماد نکنید. واقعاً خودتان در یک پنجرهٔ ناشناس به اپ بروید و کاری را که خراب بود انجام دهید. اگر رفع جواب داده، چیز خراب حالا کار می‌کند. اگر نمی‌کند، فقط چون اپ‌ساز گفت جواب داد تغییر را نپذیرید.

قدم ۷ — به کاربر پاسخ بنویسید، حتی اگر درستش نکردید

کاربری که ساعت ۱:۴۷ بامداد به شما پیام داد انتظار ندارد آنلاین باشید. اما اگر هستید، یک پاسخ کوتاه بیشتر از یک رفع اهمیت دارد:

«ممنون که خبر دادی — همین الان دارم بررسی‌اش می‌کنم. به‌محض اینکه دوباره کار کرد یک پیام برایت می‌فرستم.»

اگر کاربر پولی است، آن یک پیام تفاوت میان این است که او به مردم بگوید شما سریع جواب می‌دهید و این‌که بگوید شما او را ندیده گرفتید. رفع می‌تواند تا صبح صبر کند. پاسخ نمی‌تواند.

درس بزرگ‌تر: اپتان را طوری بسازید که انگار ممکن است خراب شود

اگر این برایتان پراسترس بود، نقطهٔ روشن این است که این تجربه نحوهٔ ساختنتان را بازشکل می‌دهد. بعد از اولین حادثهٔ ساعت ۲ بامدادتان، شروع به انجام کارها به شکل متفاوتی می‌کنید:

  • یک بررسی وضعیت اضافه می‌کنید. یک صفحهٔ ساده که به شما می‌گوید آیا بخش‌های مهم اپتان کار می‌کنند، تا مجبور نباشید برای فهمیدنش وارد شوید.
  • یک پشتیبان از دادهٔ کاربران نگه می‌دارید. اکثر اپ‌سازها دادهٔ شما را به‌درخواست صادر می‌کنند. انجام این کار هفته‌ای یک‌بار ۳۰ ثانیه طول می‌کشد و در بدترین حالت نجاتتان می‌دهد.
  • می‌نویسید اپتان به چه چیزی وابسته است. فهرستی کوتاه از هر ابزار متصل (پرداخت، ایمیل، پایگاه داده، ذخیره‌سازی)، تا وقتی چیزی ساعت ۲ بامداد خراب می‌شود، به جای حدس یک چک‌لیست داشته باشید.
  • هر بار یک چیز را تغییر می‌دهید. وقتی ۱۰ تغییر را یک‌جا انجام می‌دهید و اپ خراب می‌شود، هیچ ایده‌ای ندارید کدام تغییر خرابش کرد. وقتی هر بار یک تغییر انجام می‌دهید، دارید.

می‌توانید بدون کدنویسی یک اپ بسازید. همچنین می‌توانید بدون برنامه‌نویس بودن یکی را در حال اجرا نگه دارید — اما مهارت‌های درگیر با مهارت‌های ساختن فرق دارند. آن‌ها را بیشتر به روش سخت یاد می‌گیرید، معمولاً در یک ساعت نامناسب.

خبر خوب: هر بار که اتفاق می‌افتد، کمتر ترسناک می‌شود. بار سوم، به جای ترسناک، آزاردهنده است. بار دهم، فقط یک سه‌شنبهٔ معمولی است.