اسپرسو، سرویس محاسبه هزینه سفر اسنپ چگونه متولد شد!

از وقتی که بعنوان یک مهندس نرم‌افزار وارد تیم بک‌اند اسنپ شدم بخشی از زمانم به جز توسعه و نوشتن کد به نوشتن داکیومنت و تست گذشت و هرچند نسبت به گذشته نمیتونم نظری بدم اما روال توسعه‌ی کد توی تیمی که من داخلش کار می‌کنم علاوه بر نوشتن کد با کیفیت شامل نوشتن مستندات مرتبط و تست میشه و تا زمانی که این سه گانه تکمیل نشه عملا امکان ارسال کد برای QA وجود نداره.

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

این توضیحات رو داشته باشید تا داستان جدا کردن یکی از قسمت‌های جالب سیستم و تبدیل اون به یک سرویس رو براتون تعریف کنم.

مدتی قبل بود که زمزمه‌ی جدا کردن سیستم محاسبه هزینه سفر شد و قرار شد این کار به تیم ما سپرده بشه. تو زمان‌های آزادمون هر کدوم از بچه ها روی تکنولوژی‌ها و بهینه سازی های ممکن کار کردیم و همچنین به مطالعه کدهای سیستم قدیمی(در اون زمان فعلی) گذروندیم تا یه ایده‌ی کلی داشته باشیم که با چه چیزی درگیریم و احتمالا چه مقدار میتونیم بهینه سازی داشته باشیم و معماری سیستم جدید چطور باید باشه و دنبال چه مقدار انعطاف برای آینده هستیم.

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

اسم پروژه را هم اسپرسو گذاشتیم و هر باری که درخواست سفر ارسال می‌کنید برای قیمت سیستم ما یه اسپرسو براتون آماده می‌کنه.

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

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

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

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

اواسط پروژه نوع کار من مقداری تغییر کرد و از اونجایی که تیم ما مسئول دیپلوی پروژه هم بود کارهای مرتبط با CI/CD را هم توسط ما انجام شد و مزیت این کار برای تیم این بود که در نهایت روی تک تک اجزای کد و نحوه‌ی اجرای اون میتونستیم کنترل داشته باشیم و سرورها را به صورتی که میخواستیم پیکربندی کنیم، همچنین سرعت کارمون هم بالاتر می‌رفت. احتمالا اسم اسنپ کلاود را شنیدید (زیرساخت ابری اسنپ)، ما پایپ لاین ها را طوری طراحی کردیم که هم برای زیرساخت فعلی اتوماسیون داشته باشیم و هم برای زیرساخت کلاود و این بخش جزو جذابترین قسمت‌های کار بود و روز به روز داریم بهبودش میدیم.

در همین حین بچه های دیگه داشتن ابزارهایی برای تست خودکار خروجی و مقایسه دو سیستم آماده میکردن و وقتی همه‌ی این کارها تموم شد سرورهای پروداکشن رو تحویل گرفتیم و کد را دیپلوی کردیم و یک سری تست گرفتیم و با تیم DevOps برای یک تغییر روی دیتابیس مکاتبه کردیم و وقتی این تغییر انجام شد با استفاده از مکانیزمی که قبلا توسعه داده بودیم یک کپی از ترافیک واقعی اسنپ را پلکانی (Gradually) روی سیستم خودمون فرستادیم و لاگ کردیم. بعد از اون شروع کردیم به مقایسه هزینه سفری که سیستم قدیمی و سیستم جدید محاسبه میکردند. ما برای شروع مثلا ده درصد از ترافیک واقعی را به سمت سیستم سرازیر کردیم و shadow test گرفتیم و بعد مقدار این ترافیک را اضافه کردیم تا جاییکه تونستیم با تقریب مناسبی مصرف واقعی منابع و همچنین عملکرد سیستم را اندازه گیری کنیم. در همین حین ابزارهای مونیتورینگ را بهبود دادیم.

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

آمارهایی که سیستم جدید میداد حقیقتا خوب بودن و طی مدتی که در حال Shadow testing بودیم سعی کردیم تا حد امکان کدها و پیکربندی سرورها رو طوری بهینه کنیم که حداقل زمان پاسخگویی را داشته باشیم.

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

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


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