https://virgool.io/feed/@bardia مهندس نرم افزار - مهندس اتکاپذیری fa 2026-06-13 11:57:04 https://files.virgool.io/upload/users/52/avatar/pwDRvJ.jpeg?height=120&width=120 https://virgool.io/@bardia https://virgool.io/cafebazaar/%D8%B2%DB%8C%D8%B1%D8%B3%D8%A7%D8%AE%D8%AA-%DA%A9%D8%A7%D9%81%D9%87-%D8%A8%D8%A7%D8%B2%D8%A7%D8%B1-%D9%81%D8%B1%D9%87%D9%86%DA%AF-%D8%AF%D9%88%D8%A2%D9%BE%D8%B3-%D8%B1%D8%A7-%DA%86%DA%AF%D9%88%D9%86%D9%87-%D8%B4%DA%A9%D9%84-%D8%AF%D8%A7%D8%AF%DB%8C%D9%85-atqkkwsiafhs دوآپس چیست و چرا؟چیزی که باعث شده ما توی کافه بازار اهمیت زیادی برای اتکاپذیری (reliability) سرویس‌هامون داشته باشیم اینه که ما داریم به ۴۵ میلیون کاربر فعال سرویس می‌دیم و هر لحظه از دسترس خارج بودن بازار ضرر مالی زیادی بهمون وارد می‌کنه . سه تا فاکتور هست که برای ما اهمیت داره: کارایی (performance)، دسترس‌پذیری (availability)، مقیاس‌پذیری (scalability). کارایی یعنی برنامه بتونه توی زمان معقول با استفاده از منابع معقول جواب کاربر رو بده. زیاد شدن زمان پاسخ دهی می‌تونه باعث نارضایتی و از دست رفتن کاربرها بشه. دسترس‌پذیری یعنی سعی کنیم ارتباط کاربر‌ها با سرور همیشه برقرار باشه چون اگه ارتباط کاربر با سرور قطع بشه عملا از اپلیکیشن بازار استفاده‌ای نمیتونه بکنه و مقیاس‌پذیری هم یعنی اگه با رشد ناگهانی کاربرها مواجه شدیم، بتونیم همچنان جوابگوی درخواست‌ها باشیم.ولی یک نکته مهم اینجا هست. تلاش ما برای افزایش اتکاپذیری نباید باعث کند شدن فرایند‌های توسعه محصول ما بشه!به صورت سنتی تیم توسعه (Development) و تیم عملیات (Operations) جدا از همن. هدف تیم توسعه اضافه کردن قابلیت‌های جدید به برنامست و هدف تیم عملیات حفظ کردن شرایط پایداری سرویس. مشکلی که این فرآیند ایجاد می‌کنه تضاد منافع بین تیم‌هاست. تیم توسعه دوست داره فیچرهای جدید رو هر چه سریع‌تر توسعه بده در حالی که تغییر توی سرویس یعنی به خطر افتادن پایداری! پس تیم عملیات همیشه باید مطمئن باشه تغییرات جدید مشکلی توی سرویس ایجاد نمی‌کنن. اگه اختیار عمل رو کامل به تیم توسعه بدیم احتملا پایداری سرویس ازبین می‌ره و اگه اختیار عمل رو به تیم عملیات بدیم توسعه محصول به کندی پیش میره.اینجاست که ما به یک تعامل خوب و سازنده بین این دو تا تیم نیاز داریم. این هدفِ تیم عملیاته که پایداری سرویس رو تضمین کنه. ولی خیلی مواقع پیش میاد که بهبود پایداری نیاز به تسلط روی سورس کد داره برای همین تیم توسعه باید توی این فرآیند کمک بکنه. همینطور توسعه سریع‌تر و اتکاپذیری بیشتر، دو کفه یک ترازو هستند پس برای رسیدن به بهترین تعادل به ارتباط قوی بین تیم توسعه و عملیات و همینطور مارکتینگ و محصول نیاز داریم.طبق تعریف، دوآپس ترکیبی از ارزش‌ها و فرآیندها و ابزارهاست که باعث نزدیک شدن فرآیند توسعه و فرآیند عملیات به هم می‌شه تا به سازمان این قابلیت رو بده که بتونه سرویس‌هاش رو با سرعت و کیفیت به دست کاربر برسونه.کافه بازار چطوری به این ساختار رسید؟اون اول وقتی تیم فنی کافه‌ بازار کوچک بود، مرزی بین توسعه و عملیات دیده نمی‌شد. همون کسی که کدی رو می‌نوشت، اول تستش می‌کرد و بعد روی سرورها دیپلوی می‌کرد تا سرویس به روز بشه. خودش هم کارای مانیتورینگ و بقیه کارای عملیاتی رو انجام می‌داد. با بزرگ شدن تیم فنی چاره ای نبود که تقسیم وظایف صورت بگیره. ما بین یک دوراهی قرار گرفتیم. راه اول این بود که نقش‌های مختلف رو از هم جدا کنیم و هر کدوم توی یک تیم مستقل باشن که به component team معروفه. یعنی یک تیم بک‌اند داشته باشیم و یک تیم زیرساخت (و همینطور تیم اندروید و فرانت و مارکتینگ و غیره) یا اینکه بیایم تیم‌‌ها رو بر اساس هدف نهاییشون، یعنی رسوندن یک سرویس خاص به‌ دست کاربر جدا کنیم و توی هر تیم افراد مختلف با نقش‌های مختلف وجود داشته باشن که به feature team معروفه.ما با الهام گرفتن از اسپاتیفای سمت راه دوم رفتیم. توی ساختاری که ما بهش رسیدیم همچنان مثل قدیم که یک شرکت کوچک بودیم مرزی بین توسعه و عملیات دیده نمی‌شه و رفع کردن مشکلات مقیاس‌پذیری و دسترس‌پذیری، مقابله با مخاطرات احتمالی که به بخش عملیات معروفه توسط توسعه‌دهنده‌های بک‌اند انجام می‌شه.توی فرهنگ کافه‌ بازار فقط زمانی می‌شه از تیمی توقع مسئولیتی رو داشت که اون تیم قدرت و اختیار تمام و کمال روی اون موضوع داشته باشه. ما نمی‌تونیم از تیمی توقع داشته باشیم که دسترس‌پذیری و کارایی یک سرویس رو بهتر کنه در حالی‌که تیم دیگه‌ای کدش رو توسعه داده.این نوع شکستن تیم‌ها نیاز ما رو به معماری میکروسرویس زیاد کرد. اگه قرار بود یک تیم بتونه با استقلال به سمت اهدافش بره منطقا اولین چیزی که باید از بقیه مستقل می‌کرد سورس کد پروژه‌ای بود که روش کار می‌کنه. مهاجرت به سمت معماری میکروسرویس یک‌ شبه انجام نشد و چند سال طول کشید تا خورد خورد هر تیم پروژه خودش رو از سرویس یکپارچه کافه بازار جدا کنه.در حال حاضر، هر تیم کافه بازار چندین میکروسرویس داره و دیگه برای نوشتن یک فیچر جدید، به کد نوشتن روی سورس کدی که توسط تیم‌های دیگه مدریریت می‌شه تقریبا نیازی نیست.مدیریت کردن این همه میکروسرویس خودش کار سختیه. برای همین ما توی کافه‌ بازار نقشی به اسم «صاحب سرویس» تعریف کردیم. «صاحب سرویس» کسیه که بیشترین تسلط رو روی اون میکروسرویس داره و مسئولیت اینو داره که کدش رو همیشه با کیفیت نگهداره، کدای بقیه رو بررسی کنه و اگه مشکلی براش رخ داد در اسرع وقت درستش کنه.مقایسه feature team با component teamخوبی و بدی این ساختار چیه؟خوبی:این مدل شکستن باعث می‌شه تضاد منافع بین dev و ops باعث کند شدن ما در رسیدن به یک تجربه خوب برای کاربرامون نشه.شناسایی اینکه مشکل یک میکروسرویس از سورس کدشه یا از پلتفورمی که روش مستقر شده (شامل تنظیمات سرور، دیتابیس، کش (cache) و غیره) راحت تر پیدا می‌شه. توی مدل سنتی شرایطی پیش میاد که تیم ops برای بهبود اتکاپذیری یک سرویس کلی وقت می‌ذارن درحالی‌که ممکنه اون مشکل با یک تغییر کوچیک توی کد حل شه.فرآیند‌های release و deployment راحت‌تر می‌شن چون دیگه خبری از یک سورس کد خیلی بزرگ نیست که هر کس فقط بخشی ازش رو بلد باشه به جاش کلی میکروسرویس کوچیک داریم که صاحبش روی کدش کامل تسلط داره و میتونه سریع یک کد جدید رو بررسی کنه و روی محصول اصلی deployش کنه.بین وقت گذاشتن روی توسعه فیچر جدید یا وقت گذاشتن روی بهتر کردن reliablity خیلی تعادل برقرار میشه. چرا که ارتباط درون تیمی بین افراد یک تیم خیلی راحت تر از ارتباط بین تیمی صورت می‌گیره.بدی:تجربه‌هایی که داخل تیم‌ها به دست میاد تو همون تیم می‌مونه و به سختی با بقیه به اشتراک گذاشته می‌شه. مثلا فرض کنید یکی از بچه‌ها برای افزایش کارآیی میکروسرویسی که صاحبشه وقت زیادی روی tuning دیتابیس می‌ذاره. اگه یک میکروسرویس از یک تیم دیگه مشکل مشابه داشته باشه، به احتمال زیاد صاحب میکروسرویس دوم باید از اول وقت بذاره. ولی توی ساختار سنتی چون افراد با توجه به مهارتشون توی یه تیم قرار میگیرن انتقال دانش بینشون راحت اتفاق میوفته. جلسات هفتگی chapter برای بهتر کردن این مشکل برگزار می‌شن ولی یه جلسه توی هفته هیچوقت نمی‌تونه جای چندین ساعت هم‌تیمی بودن رو بگیره.وقت زیادی صرف کارای تکراری می‌شه. برای مثال یک تیم زمانی رو اختصاص می‌ده که برای مانیتورینگ سرویس ها از prometheus استفاده کنه و برای میکروسرویس های داخل تیم، کلی alert و dashboard مختلف میسازه. اگه یک تیم دیگه هم بخواد از prometheus استفاده کنه باید همون کارارو تکرار بکنه در حالی که شاید یک سری alert و dashboard تکراری وجود داشتن که می‌شد فقط یک بار به صورت کلی انجامش داد.داشتن یک نیرو که کل تمرکزش فقط روی مباحث زیرساختی باشه (DevOps Engineer) توی هر تیم هزینه زیادی داره و برای ما ممکن نیست. صاحب‌های سرویس‌ها هم بیشتر از نصف وقتشون رو دارن روی توسعه اون سرویس میذارن برای همین دانششون توی مباحث زیرساخت سطحی تر از یک نیروی متخصصه.ماموریت تیم پلتفورم چیه؟بالاتر به معایب ساختاری که ما بهش رسیدیم پرداختیم. تیم پلتفورم بازار با هدف ارائه سرویس‌ و ابزار برای میزبانی از میکروسرویس‌های بازار و بهبود اتکاپذیری آنها تشکیل شد تا بتونه معیابی که بهش اشاره کردیم رو کمرنگ‌تر کنه. ولی توی تشکیل تیم پلتفورم یک چالش بزرگ داشتیم. چالش اصلی این بود که نمی‌خواستیم ساختار قبلی رو بهم بزنیم چون در اون صورت مزیت‌هاش رو از دست می‌دادیم. تیم فنی شرکت به تعدادی تیم محصولی شکسته شده بود که اهداف خودشون رو داشتن ما و ما نمی‌خواستیم با تشکیل تیم پلتفورم استقلال اون هارو از بین ببریم. توی ساختار سنتی تیم پلتفورم میتونه نظارت سختگیرانه روی تیم توسعه داشته باشه و برای افزایش پایداری خودش مستقیما وارد عمل بشه. ولی توی ساختار کافه بازار که استقلال تیم ها برای ما مهمه. تیم پلتفورم نمی‌تونه بقیه تیم‌هارو مجبور به رعایت کردن یک سری الگو بکنه یا خودش مستقیم وارد بشه و اون الگو هارو پیاده سازی کنه.برای حفظ استقلال تیم‌های محصولی ما به خود تیم پلتفورم به چشم یه تیم محصولی نگاه کردیم با این تفاوت که مشتری‌های تیم پلتفورم دیگه کاربرهای کافه‌بازار نیسن و در واقع تیم‌های محصولی دیگه شرکت رو به عنوان مشتری خودمون می‌بینیم و باید براشون خلق ارزش کنیم. تلاش می‌کنیم تا مشکلاتشون رو شناسایی کنیم و ابزارهایی ارائه بدیم که اون مشکل‌ رو حل کنه. اگه ابزاری ارائه بدیم و تیمی ازش استفاده نکنه، یعنی توی شناسایی مشکلات تیم‌های محصولی خوب عمل نکردیم. برای هل دادن تیم های محصولی برای رعایت کردن الگوهای درست سعی میکنیم ابزارهایی ارائه بدیم که انجام دادن یک کار از روش درستش راحت تر از انجامش به صورت اشتباه باشه.کار هایی که تا الان توی تیم پلتفورم انجام دادیم:بالاتر خیلی کلی از اهداف و آرمان های تیم پلتفورم گفتیم توی این بخش اشاره می‌کنیم که واقعا چه کارهایی رو تا الان تونستیم انجام بدیم. بعضی از این کارها خودش یک بلاگ پست جدا نیاز داره که حتما سعی می‌کنیم در آینده بنویسیم ولی توی این پست جهت آشنایی با تیم پلتفورم صرفا در حد چند خط بهشون اشاره می‌کنیم.ایجاد chaos یا هرج و مرج در کوبرنتیزبیشتر سرویس‌های ما توی کافه بازار روی کوبرنتیز مستقر شدن. باید بدونیم که اپلیکیشن‌هایی که روی کوبرنتیز مستقر میشن باید در برابر restart شدن و منتقل شدن به یک node دیگه مقاوم باشن. اگه اینطور نباشه اضافه و کم کردن یک سرور به کلاستر کوبرنتیز می‌تونه باعث داون تایم بشه و همینطور کوبرنتیز وقتی تشخیص بده یک سرویس‌ حالش خوب نیست ری‌استارتش می‌کنه. اگه قرار باشه اون سرویس با ری‌استارت شدن حالش بدتر بشه پس عملا استفاده از کوبرنتیز منفعتی برای ما نداشته. دیده می‌شد که خیلی از تیم ها این مسئله رو رعایت نمی‌کنن و خب ما هم نمی‌تونستیم مستقیم وارد تیم‌ها بشیم و چک کنیم که تک‌تک میکروسرویس‌هایی که تیم‌ها نوشتن نسبت به این اتفاقات مقاوم هستن یا نه. راه حلی که ما تصمیم گرفتیم انجامش بدیم ایجاد اختلال عمدی روزانه بود که با این اختلال‌ها تیم‌ها بتونن سریع مشکلاتشون رو شناسایی و رفع کنن. شبیه‌سازی خاموش شدن یک node کوبرنتیز و کاهش کیفیت شبکه داخلی کوبر دو تا از هرج‌ومرج‌هایی هستن که ما روزانه ایجاد می‌کنیم.ارائه‌دادن زیرساخت مانیتورینگبا بررسی مستندات downtime های ۲ سال گذشته (که به postmortem معروفن) به این نتیجه رسیدیم کم کیفیت بودن مانیتورینگ سرویس‌هامون اصلی‌ترین دلیل کاهش uptime بوده برای همین تیم ما داره تلاش می‌کنه که کیفیت مانیتورینگ رو در کافه بازار بیشتر کنه.برای بهتر کردن کیفیت مانیتورینگ تا الان دو تا رویکرد رو جلو بردیم. اولی ارائه ابزار‌های زیرساختی برای مانیتورینگ بوده مثل ارائه sentry و prometheus و grafana. و دومین رویکردمون درست کردن داشبوردها و آلرت‌های عمومی و کلی برای همه میکروسرویس‌ها. به این صورت که الان تیم‌های محصولی کافه بازار میتونن مشخصات میکروسرویس جدیدشون جای مشخص ثبت کنن تا به صورت خودکار براشون سیستم alerting و monitoring ساخته شه.سامانه نظارتهمونطور که اشاره کردیم یکی از مشکلات ما متمرکز نبودن صاحب‌ سرویس‌ها روی کارهای زیرساختی بود که باعث می‌شد خیلی از مواقع به دلیل کم بودن اطلاعات یا حواس پرتی کار تظیمات اشتباهی روی سرور قرار بگیره. برای کم کردن این مشکل ما پروژه «ناظر» رو شروع کردیم. در حال حاضر پروژه ناظر قابلیت نظارت روی کوبرنتیز و ماشین‌های مجازی رو داره و احتمالا در آینده نظارت روی سورس کد سرویس‌ها هم بهش اضافه بشه. توی قدم اول ما اول اومدیم اشتباهات متداولی که بچه‌ها موقع deploy کردن یک سرویس روی کوبرنتیز یا setup کردن یک سرور مجازی انجام می‌دن رو شناسایی کردیم. بعد اومدیم پروژه ای نوشتیم که به صورت زمانبندی شده بیاد کل کلاستر کوبرنتیز و سرورهامون رو نظارت کنه و اگه یکی از این اشتباهات دیده شد به تیم مربوطه پیام بفرسته. خاموش بودن firewall سرور یا رزرو اشتباه منابع توی کوبر، دو تا از ۸ نوع مشکلی هستن که پروژه ناظر قابل به شناسایی اون‌ها در لحظه‌ است. همینطور ناظر یک صفحه گزارش داره که به صورت هفتگی توی جلسه توسط نماینده تیم و CTO بررسی می‌شه تا تیم ها از تعداد اشتباهاتی که توی تنظیمات زیرساختیشون دارن آگاه باشن.راه اندازی محیط stagingسورس کد بزرگ کافه‌ بازار و میکروسرویس‌های زیاد توسعه محصول را سخت کرده. توسعه و تست یک کامپوننت شاید چالشی نداشته باشه ولی تست نهایی اون کامپوننت در کنار همه میکروسرویس‌های بازار نیاز به یک محیط بزرگی داره که به staging معروفه. هر تغییر قبل از رسیدن به دست کاربر‌های نهایی می‌تونه توی محیط staging که یک نسخه کامل از کل بک‌اند‌های بازاره تست بشه. یکی از کار‌های تیم پلتفورم که سمتش رفتیم ساده‌تر کردن این فرآیند بود. مثلا تلاش داریم با استفاده از سرویس مش ریکوئست‌های alpha tester ها رو از ریکوئست‌های production جدا کنیم و اگه میکروسرویسی خودش رو staging معرفی کرد ریکوئست پروداکشن دریافت نکنه. ابزار دیگه ای که برای اینکار توسعه دادیم پروژه staging database ه. این پروژه هر روز از دیتابیس اصلی یک بک‌آپ میگیره و برنامه‌نویس‌ها می‌تونن با استفاده از cli یک نسخه از دیتابیس دیروز رو روی سرور اجرا کنن و بهش وصل بشن.جمع بندیتوی این پست توضیح دادیم که چطور فرهنگ دوآپس رو توی کافه‌ بازار پیاده کردیم. اینکه ما نیروی متمرکز برای کارهای Ops نداریم و کارهای عملیاتی توسط خود برنامه‌نویس‌ها انجام میشه. همینطور به چالش‌های این ساختار یعنی سطحی بودن دانش و وجود کار‌های تکراری اشاره کردیم و با مثال سعی کردیم توضیح بدیم چطور تیم پلتفورم بازار سعی داره بدون دخالت مستقیم روی پروژه های بچه‌ها این چالش‌ها رو برطرف کنه تا کیفیت و اتکاپذیری سرویس‌های بازار افزایش پیدا کنه. بردیا حیدری بردیا حیدری Mon, 26 Apr 2021 10:46:22 +0430 https://virgool.io/@bardia/%D8%B3%D8%B1%D8%A8%D8%A7%D8%B2-%D9%81%D9%86%D8%A7%D9%88%D8%B1-%DA%A9%DB%8C%D8%B3%D8%AA-mzwgfzwvg47u سربازی یکی از ترسناک‌ترین بخش‌های زندگی یه پسر ایرانیه. بخاطر ترس از سربازی خیلیا کنکور می‌دن که برن دانشگاه، خیلیا لیسانس رو که گرفتن کنکور میدن برای ارشد، حتی بعضی‌ها برای فرار از سربازی تا مقطع دکتری هم پیش می‌رن. یه عده دیگه هم گزینه مهاجرت رو انتخاب می‌کنن.توی این پست قصد دارم تجربیات ناقص خودم درباره نظام وظیفه فناور بگم چون حس کردم اطرافم آدمایی هستن که اطلاعاتشون از من هم کمتره و دوست دارن بدونن. اگه اشتباهی توی متن بود ممنون میشم کامنت بذارید تا اصلاحش کنم.با اینکه درسته یا غلطه، عادلانست یا ناعادلانه کاری ندارم ولی چند ساله که از طرف معاونت علمی فناوری طرحی/طرح‌هایی تصویب شده که افراد به اصطلاح نخبه (!؟) سربازی کم درد تری رو داشته باشن. برای استفاده از این تصحیلات دو تا شرط هست:شرط اول اینه که شما باید یه نخبه باشید! حالا اینکه نخبه واقعا به کی گفته می‌شه و یه آدم نخبه چه شکلیه رو نمی‌دونم ولی اگه می‌خواید بدونید از نظر دولت شما نخبه هستید یا نه این فایل PDF رو بخونید. شرط لازمش هم اینه که حداقل لیسانس داشته باشید. مواردی مثل رتبه کنکور، معدل کارشناسی و ارشد، مقام توی المپیاد‌های علمی و از همه مهم تر کار کردن توی شرکت‌های دانش‌بنیان باعث می‌شه شما امتیاز نخبگی بدست بیاری.شرط دوم هم اینه که شما باید یه شرکت دانش‌بنیان پیدا کنی که چندماه توش کار کرده باشی و حاضر باشه از سهمیش استفاده کنه برای معرفی شما به بنیاد نخبگان.انواعبعد اینکه شما به بنیاد نخبگان معرفی بشی سه تا گزینه جلوت هست که ممکنه این فرایند رو برای باور اول کمی پیچیده کنه. درواقع سه مدل مختلف نظام‌وظیفه مختلف داریم که زیاد می‌بینم بقیه اینارو با هم اشتباه بگیرن و می‌خوام یکم راجع بهشون توضیح بدم.نوع اول اسمش «امریه»ست. شرکت‌های داش‌بنیان سهمیه‌ای دارن که بستگی به میزان درآمدشون داره که می‌تونن هر سال تعداد محدودی سرباز استخدام کنن. برای اینکه بتونید سربازیتون رو به شکل امریه بگذرونید باید حداقل ۶۰ امتیاز نخبگی داشته باشید. طول امریه مثل خدمت معمولی ۲۴ ماهه. خلاصشم اینطوری که بعد اینکه همه کاراتون انجام شد نخبه شدید و میرید آموزشی به مدت دو ماه. آموزشی هم توی پادگان ۰۱ ارتشه که خب هرکسی می‌خواد بره سربازی ارتش از خداشه ۰۱ بیوفته چون امکاناتش از همه جا بیشتره. بعد از آموزشی ۲۴ ماه با یه حقوق خیلی کم سربازی به استخدام اون شرکت دانش‌بنیان در میاید و بعدش تمام. التبه اون شرکت اگه شمارو واقعا بخواد (مثلا از قبل اونجا کار می‌کنید و از کارمندهای اصلی شرکت هستید) می‌تونه با شما یه قرارداد پروژه‌ای جدا ببنده که حقوقتون بیشتر باشه.نوع دوم «پروژه جایگزین خدمت برای اورگان‌های کشوری و لشکری»ه. بعضی شرکت‌های دولتی که معمولا وابسته به اورگان‌های نظامی مثل ستاد کل نیروهای مسلح یا ناجا یا ارتش هستن یه ظرفیتی دارن که در سال یه سری پروژه تعریف کنن و سربازهای فناور به جای رفتن به خدمت این پروژه رو جاش انجام بدن. این پروژه‌ها معمولا مرتبط با فعالیت خودشونه و بیشتر جنبه تحقیق و توسعه داره. برای این مورد اگه لیسانس دارید باید حداقل ۱۰۰ امتیاز و اگه ارشد دارید ۱۱۰ امتیاز نخبگی داشته باشید. (از وقتی این وبلاگ رو نوشتم قوانین عوض شدن و الان فقط فارغ‌التحصیلین ارشد میتونن از این نوع سربازی استفاده کنن) خلاصش هم اینطوریه که شما بعد اینکه نخبه بودنتون مشخص شد بنیاد نخبگان یه نامه میزنه به دانشگاه عالی دفاع ملی تحقیقات راهبردی اونجا هم با توجه به رزومه و مهارت‌هاتون معرفیتون می‌کنن به یکی از این اورگان‌ها که پروژشون رو انجام بدید. اگه از پس پروژه بر نمیومدین اعلام می‌کنید و اون اورگان نامه عدم نیاز شمارو به دانشگاه عالی میفرسته که باعث میشه برید ته صف معرفی شدن به یه اورگان دیگه. اگر هم با پروژه اوکی بودید باید یه پروپوزال تهیه کنید که توی این پروژه قراره چی کار انجام بدید. این پروپوزال رو دانشگاه عالی باید تایید کنه و از بعد از تایید پروپوزال خدمت شما شروع میشه به مدت حداقل ۱۴ ماه یعنی حتی اگه پروژه زیر این تموم شد باید کشش بدید و الا باید یه پروژه دیگه انجام بدید. ولی اگه پروژه بیشتر از ۱۴ ماه براتون طول بکشه باید بمونید و تمومش کنید. اگه این فرآیند بیشتر از ۲۴ ماه طول بکشه و نتونید از پس پروژه بربیاید و تموم نشه کارشناس تعیین میکنه تا اینجای کاری که انجام دادید معادل چند ماه خدمت بوده و مابقیشو باید خدمت معمولی انجام بدید. آموزشی این مدل نوع ۴۵ روزه و توی پادگان ۰۱ ارتش یا شهید مدرس سپاه (به انتخاب خودتون) هست که فقط ۲ بار در سال می‌تونید برید. (قوانین عوض شده و الان آموزشی سرباز های نخبه فقط توی شهید مدرس سپاه برگزار می‌شه) برنامه آموزشیتون متفاوت از بقیست که خودش یه نکته مثبته چون خیلی راحت تر می‌گیرن. آموزشی هم وسط یا انتهای پروژه میتونید برید و باز هم انتخاب با خودتونه. نسبت به امریه این مدل امتیاز بیشتری می‌خواد طول زمانش کمتره و آموزشیش راحت تره ولی خیلی ریسک و استرس داره. یه نکته ای رو یادم رفت بگم. اگه شما قبل از مراجعه به دانشگاه عالی با یه اورگان صحبت کرده باشید و با پروژشون اوکی باشید و اون اورگان هم با شما اوکی باشه می‌تونه یه نامه اعلام نیاز برای دانشگاه عالی بفرسته که دانشگاه عالی شمارو با اون اورگان بندازه اینطوری ریسک اینکه یه جای بد بیوفتید که اذیتتون کنن کمتره. اینم حواستون باشه که قانونا اون اورگان می‌تونه از شما توقع داشته باشه که تمام وقت حضور داشته باشید ولی معمولا اینکارو نمی‌کنن و اجازه میدن از راه دور روی پروژه کار کنید اینطوری میتونید همزمان با انجام پروژه شغل خودتون رو کنارش داشته باشید.نوع سوم و آخر هم «پروژه جایگزین خدمت برای شرکت‌های دانش‌بنیان»ه. خیلی شبیه به بالاییه تفاوتاش اینه که به جای ۱۰۰ امتیاز ۲۵۰ امتیاز لازم داره که هرکسی این امتیاز رو نمیتونه بیاره. مذیتش اینه به جای اینکه از یه شرکت نظامی پروژه بگیرید برای یه شرکت دانش‌بنیان پروژه انجام میدید که قطعا برخورد بهتری خواهند داشت یه نکته اینکه اون شرکت دانش‌بنیان می‌تونه همون شرکتی باشه که شما توش کار می‌کنید (البته اگه سهمیه پروژه داشته باشه) که خب توی این شرایط خیلی به نفعتونه. میشه گفت این نوع سوم خوبی‌های نوع اول و دوم رو با هم داره هم زمانش کمتره و هم ریسکش پایینه ولی ظرفیتش خیلی کمه.نتیجه‌گیریفرآیند نظام وظیفه فناور یه چیز جدید و مدام در حال تغییر اگه قصد اینکارو دارید حتما با افراد مطلع مشورت کنید و قوانینش رو توی سایت‌ها بخونید. کار کردن توی یه شرکت دانش‌بنیان فقط یکی از شروط سرباز فناور شدنه پس اگه یه شرکت با دانش‌بنیان بودنش خواست شمارو جذب کنه حواستون به این باشه که اول اون شرکت ظرفیت داشته باشه و دوم اینکه شما امتیاز کافی نخبگی داشته باشید. بردیا حیدری بردیا حیدری Fri, 31 Jan 2020 22:21:42 +0330 https://virgool.io/devops/%DA%86%DA%AF%D9%88%D9%86%D9%87-%D9%85%D8%A7%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3%D9%87%D8%A7%D8%B1%D8%A7-%D8%B4%D9%86%D8%A7%D8%B3%D8%A7%DB%8C%DB%8C-%DA%A9%D9%86%DB%8C%D9%85-w8jyxwc4tfxd داستان از پاییز ۹۵ شروع می‌شود وقتی به عنوان برنامه نویس سمت سرور به پروژه آریو پیوستم. آن موقع به دلایلی تصمیم گرفته شد پروژه را با معماری مایکروسرویس بنویسیم اصطلاحی که خیلی وقت بود در محافل داغ شده بود. ولی خیلی هزینه دادیم که فهمیدیم تصمیم اشتباهی بود. در یک سال و نیم همکاریم در اون پروژه تجربیات زیادی در این زمینه کسب کردم و تمام مقاله‌ و کتاب هایی که راجع به مایکروسرویس خوانده بودم را از نزدیک حس کردم. الآن هم چند ماهی هست که به مجموعه کافه‌بازار پیوستم. در این بلاگ و این یکی دو نفر از تاثیرگذارترین افراد فنی مجموعه تجربیات خودشان را نوشته‌اند که کافه‌بازار را شاید نمونه موفق در مایکروسرویس بدانم (صد البته که بی ایراد نبوده). من در این وبلاگ سعی دارم با تجربیات شخصیم به این سوال جواب بدهم که اگر می‌خواهیم از مایکروسرویس استفاده کنیم، چطور از پروژه‌ای که داریم مایکروسرویس‌ها را شناسایی کنیم و تصمیم به جدا کردن آنها بگیریم. البته این وبلاگ صرفا تجربه شخصی من است و ممکن است که اشتباهات زیادی داشته باشد پس بخوانید ولی کورکورانه اعتماد نکنید.شما شرکت X نیستید.در مقدمه باید بگویم هیچ قانونی در مهندسی نرم‌افزار را نمی‌توان به عنوان یک اصل کلی در نظر گرفت چرا که این شاخه بیش از آنکه با کامپیوتر سروکار داشته باشد به ما انسان‌ها مرتبط است. اگر روزی رباتی ساخته شود که خودش کد می‌نویسد قطعا همه مباحثی مثل معماری‌های نرم‌افزاری، کد تمیز و یا متودولوژی‌های توسعه به زباله‌دان ریخته خواهند شد. (و همینطور ما برنامه‌نویس ها)اگر راجع به مایکروسرویس تحقیق کنید به مباحث کاملا متناقض بر خواهید خورد. برای مثال از نظر مارتین فاولر معماری مایکروسرویس مجموعه‌ای از سرویس‌هاست که مستقلا اجرا می‌شوند اما کریس ریجاردسن در وبسایت خود یکی از الگو‌های مدیریت اطلاعات را استفاده از دیتابیس مشترک نام برده است که با تعریف اول هم‌خوانی ندارد. یا در تمام کتاب‌هایی که من خوانده‌ام، مانند این کتاب، گفته شده برای جواب به یک درخواست بیزینسی باید ارتباط بین مایکروسرویس‌ها بسیار کم باشد. این در حالی است که آمازون که در یک وبلاگ ،درباره‌ی تجربیات خود در مهاجرت به مایکروسرویس، ذکر کرده است که در سایت آمازون برای تولید محتوی یک صفحه ۱۰۰ تا ۱۵۰ مایکروسرویس دخیل هستند. پس درست نیست به صرف خواندن یک مقاله کورکورانه از آن پیروی کنید. چرا که شرایط شما با شرکت x یکسان نیست. چه از نظر بزرگی بازار، چه از نظر تعداد کارمندها. پارامترهای زیادی وجود دارند که روی تصمیمات فنی تاثیر می‌گذارند اما در یک مقاله ذکر نمی‌شوند چه بسا شرکت x از بعضی تصمیمات خود پشیمان شده باشد اما در وبلاگ آنها را خوب جلوه دهد.سری که درد نمی‌کند دستمال نمی‌بندند.باید در ذهن ما باشد اکثر دو راهی‌هایی که در نرم‌افزار به آن برمیخوریم یک trade-off هستند. شما به عنوان یک مهندس باید تصمیم بگیرید که چه چیزی را فدای دیگری کنید. هیچ کسی پیدا نمی‌شود که سرطان نداشته باشد و شیمی درمانی انجام دهد. از مونولیتیک به مایکرسرویس رفتن همانقدر که می‌تواند مشکلات شما را حل کنند می‌توانید برای شما مشکل تولید کند.وقتی برنامه‌ی خود را به چندین بخش بشکنید که هر کدام جداگانه اجرا می‌شود در مرحله اول ارتباط مایکروسرویس‌ها خود یک مسئله است که پیچیدگی زیادی به برنامه اضافه می‌کند و شاید شما را مجبور کند ابزارها و تکنولوژی‌هایی را استفاده کنید که قبلا با آنها کار نکرده بودید، تا کمی از این پیچیدگی کاسته شود. حتی بعد از انتشار پروژه، نگهداری از چند سرویس بسیار زمان بر تر از نگهداری یک سرویس است.فقط وقتی به سمت مایکرو سرویس مهاجرت کنید که برای تک تک سرویس هایی که جدا می‌کنید یک دلیل داشته باشید.اول راهاین سوال که «آیا درسته از اول پروژه را به صورت مایکروسرویس شروع کرد؟» را از خیلی‌ها شنیده‌ام. جواب من این است که تنها به یک شرط:‌ اگر شما یک گوی‌جادو یا آینه سحرآمیز در اختیار دارید که آینده را به شما می‌گوید پس مشکلاتی که در آینده به آن برخواهید خورد را پرسید و اگر با مایکروسرویس حل میشد پروژه را از همان ابتدا با مایکروسرویس شروع کنید ولی اگر مثل من یک آدم عادی بدون superpower هستید خیر.و در نظر داشته باشید از مونولیتیک به مایکرسرویس رفتن قرار نیست یکباره اتفاق بیفتد. big bang rewrite یعنی از اول نوشتن کل محصول برای من کار بسیار ترسناکی است که هیچ وقت سمتش نخواهم رفت. (اما مثال هایی مانند دیجیکالا هستند که به خوبی این کار را انجام داده اند)پس فرض ما در این وبلاگ این است که پروژه‌ای بزرگ داریم که چند وقتی است از انتشار آن گذشته است. در ادامه به مشکلاتی که مایکروسرویس می‌تواند آنها را حل کند می‌پردازیم.۱- تحمل باروقتی مشتری‌های یک محصول آنلاین زیاد می‌شود، باید در لحظه به کاربرهای همزمان بیشتری پاسخ داد. این موضوع یعنی استفاده از منابع محاسباتی بیشتر. خب اولین و ساده ترین راه زیاد کردن منابع سرور است. یعنی برای مثال محصول شما تا قبل روی یک سرور با ۸ گیگ حافظه مستقر بود و با زیاد شدن کاربرها شما محصول را به سروری قوی تر مثلا با ۸۰ گیگ رم انتقال می‌دهید. با زیاد تر شدن مشتری‌ها ارتفاع به سرور بزرگ‌تر به صرفه نیست چرا که سرورهای خیلی بزرگ نایاب هستند. چاره‌ی شما این است که محصول را روی چند سرور مستقر کنید. برای مثال به جای اینکه سروری با ۴۰۰ گیگ رم خریداری کنید ۴ سرور دیگر با همان ۸۰ گیگ رم خریداری می‌کنید و روی هر کدام یک کپی از محصول قرار می‌دهید و با ابزارهایی مثل nginx یا haproxy بار را بین آنها تقسیم کنید. در اصطلاح به این کار scale out گفته می‌شود.خب حالا فرض کنیم این دو تا کار را انجام دادیم ولی باز هم در لحظه‌های پیک ترافیک محصول دچار اختلال می‌شود. اکثرا بخشی از کد وجود دارد که نسبت به بقیه بار خیلی بیشتری را تحمل می‌کند. اگر آن بخش را شناسایی کنیم و به صورت یک سرویس مستقل از بقیه پروژه جدا کنیم به صورتی که حداقل وابستگی را به کل پروژه داشته باشد باعث می‌شود در لحظه‌ی پیک فقط آن سرویس از دسترس خارج شود و بقیه محصول سالم بماند. حتی می‌شود این مایکروسرویس را روی یک سرور دیگر مستقر کرد تا در لحظه‌های اوج ترافیک بقیه سرویس ها کاملا ایزوله باشند و دچار اختلال نشوند. برای مثال قابلیت جستجو در یک فروشگاه خیلی بیشتر از خرید استفاده می‌شود. حال اگر جستجو یک مایکروسرویس باشد و پروژه زیر بار برود سایت به درستی باز می‌شود و خرید محصول با مشکلی رو به رو نخواهد شد. فقط جستجو دچار مشکل می‌شود.البته دقت کنید که مایکروسرویس جدید شما نباید به ازای هر درخواست از دیتابیس مشترک با پروژه اصلی استفاده کند یک راه حل استفاده از cache است و راه دیگر جدا کردن دیتابیس ها و تکرار اطلاعات مورد نیاز در دیتابیس جدید. همینطور مایکروسرویس جدید نباید به ازای هر درخواست پروژه اصلی را از طریق api فراخوانی کند چرا که همان باری که قرار بود مایکروسرویس جدید تحمل کند روی بقیه پروژه تاثیر می‌گذارد. راه حل این مشکل استفاده از task queue به جای استفاده از پروتکلی مانند http یا rpc است. ابزاری مثل Kafka یا RabbitMQ پیام‌ها را در خود ذخیره می‌کنند و میکروسرویس مقصد در فرصت مناسب آن‌هارا پردازش می‌کند. با این کار زیر بار رفتن اولی باعث فشار آمدن به میکروسرویس دوم نمی‌شود.۲- بهینه سازی خواندن/نوشتناین مورد بسیار شبیه مورد قبلی است ولی از زاویه متفاوتی به قضیه نگاه شده است. فرض کنید اطلاعاتی در محصول خود دارید که نرخ خواندن آن نسبت به نوشتن آن بسیار متفاوت است برای مثال اطلاعاتی هست که در روز ۱۰ بار تغییر می‌کنند ولی در ثانیه ۱۰۰۰ بار خوانده می‌شوند. برای مثال در سایتی مثل دیوار، خیلی بیشتر از ثبت آگهی استفاده می‌شود. این مسئله می‌تواند برعکس باشد برای مثال ۱۰۰۰ بار در ثانیه اطلاعات تغییر میکند ولی فقط ۱۰۰ بار در روز خوانده می‌شود مثالش می‌تواند ذخیره اطلاعات رفتارهای کاربر‌ها باشد. مثلا میخوایم وقتی کاربری از محصولی بازدید کرد جایی ذخیره شود تا مدیر محصول بتواند آمار دقیقی از کاربر ها داشته باشد. مدیر محصول شاید فقط روزی یک بار به این اطلاعات نیاز پیدا کند.در این شرایط الگویی معروفی به اسم Command-Query Responsibility Segregation وجود دارد. یعنی جداسازی بخش نوشتن و خواندن اطلاعات. در مثال‌های گفته شده نوشتن و خواندن یک داده تفاوت زیادی دارند و احتمالا ما می‌خواهیم از تکنولوژی‌های مختلفی برای این دو استفاده کنیم. مثلا وقتی نرخ نوشتن اطلاعات بالاست دوست داریم آن را روی مموری ذخیره کنیم تا سریع باشد یا آن را روی kafka قرار دهیم تا بعدا پردازش شود. یا وقتی نرخ خواندن بالاست می‌خواهیم از ابزار هایی مثل memcache یا varnish استفاده کنیم. به مرور تفاوت این دو بخش و دغدغه‌های آن زیاد و زیاد تر خواهند شد که برای راحتی در توسعه و تمیزتر شدن کدها مجبوریم این دو را به عنوان دو مایکروسرویس جدا بنویسیم.۳- استفاده از یک زبان دیگردر مجموع من با بزرگ کردن استک تکنولوژی موافق نیستم چرا که در بلند مدت از نظر منابع انسانی به پروژه ضربه‌هایی وارد میکند. ولی فرض کنید مجبور هستید بخشی از پروژه خود را با زبانی دیگر بنویسید. برای مثال پروژه شما با php نوشته شده اما در بخشی نیاز به یک کتابخانه هوش‌مصنوعی دارید که فقط در زبان پایتون است و هیچ مشابهی در php ندارد. یا خرید سرور بیشتر برای شما دیگر به صرفه نیست و برای افزایش کارایی بخشی از پروژه که همروندی زیادی دارد را می‌خواهید با Go یا Erlang باز نویسی کنید. اگر بستر مایکروسرویس در پروژه‌ی شما وجود داشته باشد جدا کردن یک بخش و بازنویسی آن با یک زبان جدید کار بسیار راحتی خواهد بود. برای خود من زبان پایتون برای توسعه یک محصول جدید اولویت دارد چرا که بسیار راحت است و با کتابخانه‌ها و چهارچوب‌هایی که دارد توسعه را خیلی سریع می‌کند. این در حالیست که پایتون در لود بالا نمی‌تواند خوب عمل کند که انتخاب من برای هندل کردن درخواست‌های زیاد زبان گو است. ولی توسعه یک محصول با زبان گو بسیار وقتگیر است. استفاده از مایکروسرویس این آزادی را می‌دهد که هر بخش برنامه با یک زبان نوشته شود.۴- استفاده از کدهای قدیمیتعداد پروژه‌هایی که چندین سال است در حال توسعه هستند بسیار کم است. در این پروژه‌ها قسمت‌هایی وجود دارد که معمولا همه برنامه نویس ها از دست زدن به آن واهمه دارند. یک کد بسیار بزرگ و پیچیده که معمولا از پروتکل‌های قدیمی استفاده می‌کند مانند SOAP یا RMI. اگر در چنین پروژه‌ای قصد بازنویسی یا ریفکتور کردن را بگیرید شاید وجود بخش های بزرگ و پیچیده شما را منصرف کند. در این شرایط یکی از راه‌های متداول این است که بخشی از پروژه به عنوان یک سرویس مستقل بازنویسی شود و بخش قدیمی و جدید می‌توانند از طریق api با هم ارتباط برقرار کنند. مثلا پروژه کافه‌بازار کدهایی دارد که تاریخ کامیت آنها برای ۸ سال پیش است که بازنویسی کامل آن به صرفه نیست.۵- تیم های محصولیخیلی از برنامه نویس‌ها دوست دارند به تنهایی روی محصول کار کنند. معمولا بین برنامه نویس‌های تازه کار خیلی دیده می‌شود چون کار تیمی برایشان سخت است. از نظر خود من برنامه‌نویسی خیلی به نقاشی شباهت دارد و فکر نمی‌کنم چند نقاش با هم بتوانند تابلوی زیبایی را بکشند. مباحث مهندسی‌نرم افزار هم بیشتر راجع به همین موضوع است که چطور برنامه نویس‌ها بتوانند با هم کنار بیایند و روی یک محصول کار کنند. مواردی مثل git workflow و code style و design pattern و هزاران مورد دیگر به ما کمک می‌کنند تا راحت‌تر با هم کار کنیم. ولی قبول کنید که این هم حدی دارد. هرچه تعداد برنامه نویسان یک محصول بیشتر می‌شوند چابکی کمتر می‌شود باگ‌ها افزایش پیدا می‌کند و در نهایت محصول دچار لختی‌ای می‌شود که توسعه‌ی آن کار بسیار سخت و زمان‌بری خواهد شد و تعداد زیادی نفر فقط برای نگهداری از پروژه وقت خود را صرف می‌کنند.خب اگه بیایید کامپوننت‌های پروژه را تک به تک از پروژه اصلی جدا کنید و به عنوان مایکروسرویس از آن استفاده کنید باعث می‌شود بتوانید تیم را شکسته و تعداد کسانی که روی یک پروژه کار میکنند را کم کنید.این مدل شکاندن پروژه از نظر من چالشی‌ترین حالت است. اول باید دقت کنید مایکروسرویس جدید کمترین وابستگی را به بقیه پروژه داشته باشه. یک مفهومی مطرح می‌شود به اسم bounded context که بد نیست راجع به آن مطالعه کنید. یادتان نرود هدف ما این بود که تیم ها را جدا کنیم پس اگه دوتا مایکروسرویس به هم وابستگی داشته باشند ما از هدفمان دور شده‌ایم چرا دو تیم جدا سر هر موضوعی مجبور می‌شوند با تیم دیگر همکاری کنند که در این حالت به جای آسان کردن روابط آن را دو چندان کرده‌ایم. این دو مایکروسرویس حتی می‌توانند ادبیات جدا از خودشان را داشته باشند مثلا یک سایت فروش لباس می‌تواند یک مایکروسرویس پرداخت داشته باشد و لزومی نباشد هیچ کدام از برنامه‌نویس‌های تیم پرداخت از اینکه چه چیز به فروش می‌رسد اطلاع داشته باشند. در این حالت تصمیمات محصولی تیم نمایش لباس به تیم فروش تاثیری نخواهد گذاشت. مسئله دوم راجع به این مدل از شکاندن پروژه این است که معمولا باعث افت پرفورمنس (بعضی موقع ها شدید) می‌شود. سعی بر این است که یک user story یا به بیان دیگر یه business feature تنها توسط یک مایکروسرویس انجام شود ولی خب زیاده روی در این اصل هم باعث افزایش کد های تکراری و دیتای تکراری می‌شود.حرف آخرآینده را پیشبینی نکنید! این دام بزرگی است که خیلی ها گرفتارش می‌شوند (از جمله خود من). هر وقت به مشکلی بر خوردید دنبال راه حل باشید. و تمام افکارتون راجع به اینکه این پروژه قراره تو آینده بار زیادی بیاد روش یا برنامه‌نویس‌های زیادی قراره روش کار کنند را بریزید دور (خیلی دور). در پروژه آریو ما با ۳ برنامه‌نویس بکند، پروژه را ۱۱ میکروسرویس محصولی شکسته بودیم که با دیدن سربار زیاد آن مجبور شدیم تعدادی از مایکروسرویس‌ها را ترکیب کنیم و تعداد را به ۷ مایکروسرویس برسانیم. جمله‌ای معروفی از دونالد نوت در کتاب «برنامه نویسی کامپیوتر به عنوان یک هنر» می‌گوید «Premature optimization is the root of all evil». بهینه سازی یک پروژه نابالغ ریشه تمام مشکلات است.همونطور که اول گفتم با bigbang rewrite کردن پروژه مخالفم. از مونولیتیک به مایکروسرویس رفتن کار یک شبه نیست. هر وقت با مشکلات مونولیتیک مواجه شدید تک به تک آنها را حل کنید. شاید وسط راه حس کردید مایکروسرویس به دردسرش نمی‌ارزد.نکته آخر اینکه مایکروسرویس بودن زیرساخت خاص خودش را نیاز دارد. هرچه تعداد مایکروسرویس‌ها بیشتر می‌شود مدیریت آنها وقت بیشتری خواهد برد. ابزارهای زیادی هست که به ما کمک میکنند مثل داکر یا کوبرنیتیز. درباره‌ی آنها تحقیق کنید و از هر کدام که کار شما را راحت می‌کرد (توجه کنید که همه آنها نه! فقط آنهایی که به درد شما می‌خورد) استفاده کنید. بردیا حیدری بردیا حیدری Tue, 07 Aug 2018 13:03:34 +0430