پرش به محتوا
۲۰ اوت ۲۰۲۶ · پشت‌صحنه‌ی بیلد

روز راه‌اندازی: دفترچه‌ی خاطرات ۲۴ ساعت اول پس از زنده شدن

این مقاله محصول را در زمان انتشار توصیف می‌کند. برای قابلیت‌های فعلی به AI Builder و Agent Teams مراجعه کنید.

روز راه‌اندازی: دفترچه‌ی خاطرات ۲۴ ساعت اول پس از زنده شدن

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

۶:۵۸ صبح — انتشار

شب قبل هدف استقرار را روی دامنه‌ی خود پریا تنظیم کرده بودم، پس این بخش بی‌هیجان بود: انتشار را زدم، تماشا کردم رکورد صحت‌سنجی ساخت بررسی‌هایش را اجرا کند:

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

همه سبز بود. ساعت ۶:۵۸ صبح لینک را برای پریا پیامک کردم چون می‌دانستم درست در همان لحظه دارد وارد شیفتش می‌شود و می‌خواستم آن را زنده ببیند قبل از شروع روز، نه بعدش.

۷:۱۵ صبح — اولین کاربر واقعی کاری می‌کند که من تست نکرده بودم

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

۹:۴۰ صبح — سکوت، و من از سکوت نگران می‌شوم

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

۱۱:۵۲ صبح — باگ

۳ پرستار در عرض شش ثانیه از هم همان شیفت را ادعا کردند

نقطه‌ی پایانی ادعا هر سه را پذیرفت، چون منطق «علامت‌گذاری به‌عنوان ادعاشده» را به‌صورت یک بررسی ساده‌ی به‌روزرسانی-اگر-باز-باشد بدون قفل نوشته بودم، و در تست معمولی تک‌کاربره این شرایط رقابتی اصلاً فضایی برای رخ‌دادن ندارد. زیر سه ضربه‌ی هم‌زمان از سه گوشی مختلف، فضای زیادی دارد. هر سه پرستار پیامک تأییدیه دریافت کردند که شیفت را پوشش داده‌اند. دنیس یکی از آن‌ها بود، برای دومین بار در همان روز، و این‌بار عصبانی بود.

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

اپ می‌گه ۳ نفر همون شیفتو گرفتن لول

۱۲:۱۰ ظهر — وارد چت ساخت

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

۱۲:۳۴ ظهر — راه‌حل منتشر می‌شود، و من پریا را منتظر می‌گذارم

پچ کوچک بود. با این حال آن را مستقیم روی دامنه‌ی زنده در طول یک شیفت فعال ارسال نکردم — اول آن را روی یک نسخه‌ی پیش‌نمایش اجرا کردم و از همکار پرستار مسئول پریا، که در شیفت نبود، خواستم همان کار سه‌ضربه‌ی هم‌زمان را از سه تب مرورگر امتحان کند. جواب داد. یک ادعا موفق شد، دو تای دیگر به‌جای تأیید نادرست، پیام «این شیفت هم‌اکنون توسط شخص دیگری ادعا شده» را دریافت کردند. ساعت ۱۲:۳۴ آن را منتشر کردم، حدود چهل‌و‌دو دقیقه پس از وقوع باگ، که در آن لحظه کند به‌نظر می‌رسید و با نگاهی به گذشته سریع.

۲:۰۰ تا ۶:۰۰ بعدازظهر — بخش خسته‌کننده‌ی خوب

  • ۱۱ شیفت دیگر پست شد
  • ۹ بدون مشکل ادعا شد
  • ۲ بدون ادعا منقضی شدند و به تخته‌ای که پریا هنوز دستی مدیریت می‌کند برگشتند — که اشکالی ندارد، ابزار لازم نیست همه‌چیز را در روز اول حل کند، فقط باید همان چیز مشخصی را حل کند که خراب بود
  • ۰ ادعای دوگانه‌ی دیگر

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

چه چیزی را متفاوت انجام می‌دادم

دو چیز.

  1. سناریوی ادعای همزمان را باید در پرامپت اصلی ساخت توصیف می‌کردم به‌جای اینکه آن را زنده کشف کنم — «چند کاربر، یک عملیات، یک لحظه» یک جمله است، نه یک درخواست سخت، و فقط به ذهنم نرسید که آن را بگنجانم چون تست خودم ذاتاً ترتیبی است؛ من همیشه فقط یک دکمه را در یک لحظه کلیک می‌کنم.
  2. در هفته‌ی دوم روی متن اطلاع‌رسانی پیامکی بیش‌ازحد سرمایه‌گذاری کردم — سه بازنویسی جداگانه از یک متن تأییدیه که هیچ‌کس شکایتی از آن نداشت — و درست همان نوع مورد لبه‌ی هم‌زمانی که یک بخش پر از پرستار در استراحت، همه در همان لحظه خیره به گوشی‌هایشان، همیشه قرار بود در روز اول به آن برخورد کند، کم‌سرمایه‌گذاری کردم.

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

پشت‌صحنهٔ ساخت
اشتراک‌گذاریXLinkedInFacebookRedditQuoraواتساپتلگرامایمیل
← همه مطالب