https://virgool.ir/feed/@mostafarمهندس نرم‌افزار در Yelpfa2026-11-11 07:01:23https://files.virgool.ir/upload/users/2388/avatar/e4uDUy.pnghttps://virgool.ir/@mostafarhttps://virgool.ir/@mostafar/مستند-کالبدشکافی-postmortem-document-ivfagepohpa7سروش، لیلا و رضا از تیم برنامه‌نویسیِ شرکت "خرید-آنلاین" مدتی‌است روی پروژه‌ی ارسال پیام کوتاه به کاربر پس از ثبت سفارش کار می‌کنند. پس از دو هفته پیاده‌سازیِ کد و تست‌های خودکار و هم‌چنین انجام تست‌های واقعی روی سرورهای استیجینگ و اصلی، بالاخره سه‌شنبه صبح سرویس جدید برای همه‌ی کاربرها فعال می‌شود. همه‌چیز به نظر طبق برنامه‌ریزی پیش می‌رود، سه‌شنبه غروب در ساعت پیک ترافیک چند خطای ۵۰۴ در پنل مانیتورینگ مشاهده می‌شود که با توجه به تعداد نه‌چندان زیادشان توجه کسی را جلب نمی‌کنند. چهارشنبه صبح کل تیم برنامه‌نویسی در جلسه‌ی برنامه‌ریزیِ پروژه‌ی آینده شرکت می‌کنند و از پیام‌کوتاه‌هایی که دیشب بعد از ثبت سفارش‌های تستی دریافت کرده‌اند ابراز رضایت می‌کنند.اما چهارشنبه غروب پس از آن‌که بیشتر برنامه‌نویس‌ها محل شرکت را ترک می‌کنند، پنل مانیتورینگ تعداد زیادی خطای ۵۰۴ گزارش می‌دهد. پس از چند دقیقه محمد از تیم پشتیبانی تماس می‌گیرد و اعلام می‌کند کاربرها پس از ثبت سفارش و با وجود کسر شدن پول از حساب بانکیِ آن‌ها، صفحه‌ی خطایی مشاهده می‌کنند. سینا که در آن زمان آن‌کال بوده‌است، با بررسی لاگ‌های سرور و مطالعه‌ی بخش‌هایی از کد حدس می‌زند اشکال هنگام ارسال پیام کوتاه رخ می‌دهد. سینا با توجه به عدم آشنایی با سرویس پیام‌کوتاه با لیلا تماس می‌گیرد و پس از مشورت تصمیم به غیر فعال‌سازیِ سرویس پیام‌کوتاه می‌گیرند. خوشبختانه با تغییری جزئی در تنظیمات سرور می‌توان امکان پیام‌کوتاه را غیرفعال کرد. دقایقی پس از انجام این تغییر خطاهای ۵۰۴ ناپدید شده و ثبت‌سفارش‌ها از سر گرفته می‌شوند. سینا نفس راحتی کشیده و به خانه می‌رود.شنبه صبح لیلا مشغول بررسیِ اشکال پیش‌آمده در چهارشنبه‌ی قبل می‌شود، از سینا درباره‌ی روش رفع اشکال سوال می‌کند و سپس با سروش و رضا درباره‌ی کل اتفاق مشورت می‌کند. لیلا که اخیرا درباره‌ی مستند کالبدشکافی مطالعه کرده‌است، تصمیم می‌گیرد اولین مستند کالبد شکافی در خرید-آنلاین را بنویسد، نوشتن این مستند تقریبا دو ساعت از زمان روز او را می‌گیرد.مستند کالبدشکافیمتوقف شدن ثبت سفارش‌ها به دلیل وجود اشکال در سیستم ارسال پیامک تاییدخلاصهروز سه‌شنبه تیم برنامه‌نویسی سرویس پیام کوتاه تایید سفارش را برای همه‌ی کاربرها فعال کرد، روز چهارشنبه در ساعت حدود ۷ عصر تعداد بسیار زیادی خطای ۵۰۴ در پنل مانیتورینگ گزارش شد و کاربران برای یک‌ساعت قادر به ثبت سفارش نبودند. در نهایت با غیرفعال کردن سرویس پیام کوتاه خطاها اتمام یافتند و کارکرد سیستم به حالت عادی بازگشت.تاثیرگذاریثبت سفارش از ساعت ۶:۵۵ تا۸:۰۰ دچار اختلال شدید شده‌است. اطلاعات پایگاه‌داده تنها ۲۰ سفارش ثبت شده در این فاصله‌ی زمانی را نشان می‌دهد. لاگ‌های سیستم ۱۴۳۲خطای ۵۰۴ را ثبت‌کرده اند. اما در زمان مشابه در چهارشنبه‌ی هفته‌ی گذشته ۸۱۰ سفارش در سیستم ثبت‌شده است. احتمالا تعداد بیشتر خطای ۵۰۴ به دلیل سعی مجدد کاربران برای ثبت سفارش بوده‌است. بنابراین تخمین می‌زنیم در زمان بروز اشکال، امکان ثبت ۸۱۰ - ۲۰ = ۷۹۰ سفارش از دست رفته‌است. با توجه به میانگین ۲،۰۰۰ تومان درآمد از هر سفارش (به دست آمده از سفارش‌های سه‌ماه گذشته‌ی خرید-آنلاین)، اشکال به وجود آمده باعث ایجاد ۷۹۰ *‌۲۰۰۰ = ۱،۵۸۰،۰۰۰ تومان ضرر شده است.هم‌چنین با توجه به‌این‌که ۴۲٪ از سفارش‌ها توسط کاربران جدید ثبت می‌شوند (به دست‌آمده از سفارش‌های سه‌ماه گذشته‌ی خرید-آنلاین)، حدود ۳۰۰ کاربر جدید با تجربه‌ی بسیار بدی مواجه شده‌اند که به احتمال زیاد باعث روی‌گردادن آن‌ها از خرید-آنلاین و استفاده از سرویس‌های رقیب خواهد شد.تجربه‌ی بد کاربری روی کاربرهای قدیمی نیز تاثیر منفی گذاشته و ممکن‌است به روی‌گردادن آن‌ها بی‌انجامد.جدول زمانی رویداد‌هاسه‌شنبه ۱۰:۰۰: فعال‌سازیِ سرویس پیام‌کوتاه تایید سفارش برای همه‌ی کاربرها.سه‌شنبه ۱۹:۳۰: ثبت ۲۴ خطای ۵۰۴ در پنل مانیتورینگ که به دلیل تعداد کم باعث ارسال هشدار به آن‌کال را نشده بود.چهارشنبه ۱۸:۰۰: سینا (آن‌کال) هشدار Error Peak را از پنل مانیتورینگ دریافت و شروع به بررسیِ دلیل بروز خطا می‌کند.چهارشنبه ۱۸:۱۰: محمد (کارمند بخش پشتیبانی) با تیم برنامه‌نویسی تماس می‌گیرد و اعلام می‌کند کاربران امکان ثبت سفارش ندارند.چهارشنبه ۱۸:۴۰: سینا با لیلا تماس می‌گیرد و روش غیرفعال کردن سرویس پیام کوتاه را می‌پرسد.چهارشنبه ۱۸:۵۰: سرویس پیام کوتاه غیرفعال شده و خطاهای ۵۰۴ رو به کاهش می‌روند.چهارشنبه ۱۹:۰۰: خطایی مشاهده نمی‌شود و سفارش‌های ثبت شده‌ی جدیدی در پنل مانیتورینگ نمایش داده می‌شوند.تحلیلدر سرویس جدید، پیام‌کوتاه پس از ثبت‌سفارش و بررسیِ انجام پرداخت و قبل از نمایش صفحه‌ی تایید سفارش، به مشتری ارسال می‌شود(فایل kharid/logic/checkout.py، تابع notify_customer). ارسال پیام‌کوتاه با ارسال یک HTTP Request از نوع POST به سرویس‌دهنده‌ی خارجی (پیام‌رسانان شرق) انجام می‌شود (فایل kharid/logic/sms_notification.py فایل send_sms). ما ارسال این درخواست را با استفاده از کتاب‌خانه‌ی urllib2 و به صورت یک درخواست Synchronous پیاده‌سازی کرده‌ایم.در روز چهارشنبه سرویس پیام‌رسانان شرق بسیار کند شده و ارسال هر پیام‌کوتاه به طور متوسط ۴۵ ثانیه زمان برده‌است (گزارش کندی سیستم در http://payamresanan.ir/status). با توجه به تنظیمات uwsgi خرید-آنلاین،در صورت عدم دریافت پاسخ از worker در ۳۰ ثانیه، خطای ۵۰۴ را گزارش می‌شود. با توجه به این‌که تراکنش پایگاه‌داده در هنگام ارسال پاسخ commit می‌شود، سفارش‌هایی که با خطای ۵۰۴ مواجه شده‌اند، در پایگاه‌داده ثبت نشده‌اند.پس از شناساییِ اشکال در روز چهارشنبه، سرویس پیام‌کوتاه را با تغییر مقدار service_enabled به false در فایل configs/sms_notification.yaml و اعمال تغییر توسط puppet غیر‌فعال کردیم. خوش‌بختانه، ‌یک Batch Job به نام refund_unsuccessful_orders پرداخت‌های انجام‌شده برای سفارش‌های ثبت نشده در پایگاه‌داده را بازپرداخت می‌کند. بنابراین نیاز به اقدام جداگانه‌ای برای بازپرداخت سفارش‌ها نداشتیم.کارهایی که باید انجام شوند۱. پیاده‌سازیِ timeout مناسب برای اتصال به سرویس‌دهنده‌ی پیام‌کوتاه۲. اضافه‌کردن روش غیرفعال سازیِ سرویس پیام‌کوتاه به کتاب‌چه‌ی راهنمای آن‌کال برای مواقع بروز مشکل۳. تغییر احتمالیِ تنظیمات هشداردهیِ پنل مانیتورینگاقدامات بلند‌مدت‌تر:۴. پیاده‌سازیِ اتصال غیر هم‌زمان به سرویس‌دهنده‌ی پیام‌کوتاه (Asynchronous)۵. پیاده‌سازیِ امکان تغییر سرویس‌دهنده‌ی پیام‌کوتاه در صورت بروز مشکل در سرویس‌دهیِ آنها و ثبت قرارداد با یک سرویس‌دهنده به عنوان پشتیبان۶. برنامه‌ریزی برای فعال‌سازی امکانات و سرویس‌های جدید به نحوی که ریسک کمتری برای محصول ایجادکنند.درس‌های گرفته‌شده۱. هر اتصال هم‌زمان (Synchronous) به یک سرویس‌دهنده‌‌ی خارجی به معنای یک ریسک برای سیستم است. برای کنترل این ریسک باید از اتصال غیرهم‌زمان و یا تنظیم timeout مناسب استفاده کرد.۲. فعال سازیِ ناگهانیِ یک سرویس جدید برای همه‌ی کاربرها ریسک زیان ناشی از خطاهای احتمالی را افزایش می‌دهد. فعال‌سازیِ تدریجی باعث کاهش قبال ملاحضه‌ی این ریسک می‌شود. لیلا مستند را برای رضا، سروش و سینا ای‌میل کرده و از آن‌ها می‌خواهد آن‌را بازبینی کنند. پس از تایید مستند، لیلا آن‌را به کل تیم برنامه‌نویسی ارسال می‌کند. مسوول تیم پشتیبانی نیز یک نسخه از مستند را دریافت می‌کند.در تمام تیم‌های برنامه‌نویسی،هر روز سناریو‌هایی شبیه آن‌چه بالا آمد اتفاق می‌افتند، گاهی ساده‌تر، گاهی پیچیده‌تر. معمولا چنین اشکالاتی باید خیلی سریع برطرف شوند تا کمترین تاثیر را در کارکرد معمول سیستم بگذارند. اما ثبت دانش به‌دست‌آمده از اشکال رخ‌داده می‌تواند به همان‌اندازه اهمیت داشته باشد. تهیه‌ی مستند کالبدشکافی، یک راه‌حلِ مرسوم برای ثبت این دانش است.درواقع مستند کالبدشکافی باید به چهار سوال اساسی پاسخ دهد:۱- چه اتفاقی رخ داده است؟۲- چرا این اتفاق رخ داده است؟۳- چه کارهایی توسط تیم پس از وقوع این اتفاق انجام شده است؟۴- چگونه می‌توانیم از وقوع این اتفاق و اتفاق‌های مشابه در آینده جلوگیری کنیم؟روال تهیه‌ی این مستند باعث افزایش دانش تهیه‌کنندگان آن نسبت به ریسک‌های سیستم می‌شود. بنابراین بهتر است این مستند توسط فرد یا افرادی که بیشترین ارتباط فنی را با اشکال پیش‌آمده داشته‌اند تهیه شده و سپس توسط کل افراد تحت‌تاثیر قرار گرفته بررسی و تایید شود.مصطفی رکوعیمصطفی رکوعیSun, 24 Dec 2017 16:37:11 +0330