قسمت اول

داشتم رایتاپ I Thought It Was a Safe Deploy… Until Checkout Disappeared رو میخوندم نکات جالبی توش داشت. طرف مسئول بخش payments بوده. شروع میکنه به استقرار نسخه ی جدید. تست ها گرفته شده بوده و روی محیط Dev همه چی اوکی به نظر می‌رسید. همه چیز آروم بوده تا اینکه Slack اشون پر شده بود از پیام های: «صفحه چک‌اوت لود نمی‌شه.»، «صفحه سفیده هیچی نمیاد.» ، «اپل پِی (Apple Pay) کار نمی‌کنه.».

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

دقیقا چیشده بود؟

بخش payments از اون جاهاست که وقتی همه چی مرتب و درست کار می‌کنه، خیلی ساکت و آروم اون پشت‌صحنه به کارش ادامه می‌ده... اما وای به روزی که یه جای کارش بلنگه و یه چیزی خراب بشه؛ اونوقته که تبدیل به یه هرج و مرج می‌شه.
چند وقت پیش SDK مربوط به Apple Pay رو آپدیت کرده بودند چون نسخه‌ای که داشتن استفاده می‌کردن، دیگه توسط خود تیم اپل پشتیبانی نمی‌شد و منسوخ شده بود. نسخه‌ی جدید هم یه سری تغییرات توی API contract داشت—که بیشترش مربوط به این بود که موقع شروع کار و مقداردهی اولیه ورودی‌ها چطوری باید بهش داده بشن. اینا هم تغییرات لازم رو انجام داده بودن، همه چی رو روی محیط توسعه تست شده بود و به نظر می‌رسید همه چی ردیفه. یه مدت میگذره و میبینن هشدار های تعداد خطاهای مربوط به Apple Pay یهو خیلی بالا رفته. فهمیدن که اون SDK آپدیت‌شده، به یه تابع خاص وابسته بود که توی بعضی از مرورگرهای قدیمی‌تر پشتیبانی نمی‌شد. نتیجه‌اش این بود که همون اولِ فرآیند پرداخت، یه خطای زمان اجرا اتفاق می‌افتاد؛ یعنی انقدر زود این خطا رخ می‌داد که کلاً کل تجربه‌ی چک‌اوت رو از کار می‌نداخت. نه دیگه خبری از Apple Pay بود. نه هیچ روش پرداخت دیگه‌ای کار می‌کرد. فقط یه صفحه‌ی سفیدِ خالی جلو چشم کاربر بود.

⚠️ اول از همه: با دیباگ کردن شروع نکنید!

قبل از اینکه وارد جزئیات بشیم، یه درس خیلی مهم هست:

وقتی با یه مشکل جدی و قطعی (outage) تو محیط پروداکشن روبرو می‌شین، اولین غریزه‌تون نباید این باشه که بپرین سراغ دیباگ کردن.

چون وقتی پای کد شما وسطه، مغزتون اتوماتیک می‌ره تو این فاز که:
«خب، باگ کجاست؟ چی خراب شده؟ باید زود پیداش کنم و درستش کنم.»

ولی نکته اینجاست: دیباگ کردن زمان‌بره.

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

مگه اینکه دقیقاً بدونین مشکل چیه و صددرصد مطمئن باشین که راه حلش امنه و می‌شه خیلی سریع دیپلوی‌اش کرد، وگرنه بهترین و عاقلانه‌ترین کار اینه:

کامیتی که باعث مشکل شده رو برگردونین عقب (Revert). کد قبلی رو دوباره دیپلوی کنین (Redeploy). اوضاع رو پایدار کنین.

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

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

—-

⬅️ ادامه در قسمت بعدی

💡 تا قسمت بعدی مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily