🚀 🧪 ترمینولوژی تست نرم‌افزار - ویراست ۰.۵

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

پیشاپیش از هر نقد و پیشنهاد و تذکری که موجب بهبودش بشه سپاسگزارم.

سعی کردم تا فایل PDF کیفیت مطلوبی داشته باشه تا برای مطالعه و زوم یا حتی پرینت مناسب باشه.
⬇️ دانلود نسخه PDF
⬇️دانلود فایل JPEG

💬 مثل همیشه؛ نظر ؟ پیشنهاد ؟ نقد ؟ 😉

🔔 ۲۵ دقیقه دیگه 😉

گوگل میت

2️⃣ جلسه دوم مرور مهارت‌های مورد نیاز و مسیر رسیدن به مهندس ارشد نرم‌افزا

اگر نظر مثبتی نسبت به جلسه اول «مرور مهارت‌های مورد نیاز و مسیر رسیدن به مهندس ارشد نرم‌افزار» داشتید و فکر می‌کنید ادامه بحث می‌تونه براتون جالب باشه، لطفا از طریق فرم زیر بگید 😊

🗓 برای روز یکشنبه ۷ اردیبهشت (۲۷ اپریل) ساعت ۱۸:۳۰ به وقت تهران

https://forms.gle/ayy2Q3MESKnhrNt3A

📱 معماری سلولی چیه، لزوم توجه بهش؛ و چرا slack رفت دنبالش؟

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

توی معماری سلولی سیستم‌های پیچیده به واحدهای مستقل و خودکفا (سلول‌ها) تقسیم می‌شن. هر سلول می‌تونه به تنهایی کار کنه و اگر یک سلول دچار مشکل بشه، بقیه سلول‌ها می‌تونن به کار خودشون ادامه بدن.

❓ مشکل slack از کجا شروع شد؟
یه روز توی اسلک، نمودارهای مانیتورینگ نشون دادن که یکی از Availability Zone (AZ) های AWS در منطقه us-east-1 داره پکت‌های زیادی رو از دست میده. این باعث خطا و کندی سرویس برای کاربرها شده بود.
مشکل اصلی اینجا بود که با وجود اینکه اسلک از چند AZ استفاده می‌کرد، وقتی یک AZ دچار مشکل می‌شد، کل سرویس تحت تأثیر قرار می‌گرفت! خب این اصلاً منطقی نیست! مگه نه اینکه هدف استفاده از چند AZ همین هست که اگه یکی به مشکل خورد، بقیه کار رو پیش ببرن؟

در مورد اسلک، هر AZ تبدیل به یک سلول شد. یعنی مجموعه‌ای از سرویس‌هایی که در یک AZ هستن و می‌تونن به عنوان یک واحد از سرویس خارج بشن یا به سرویس برگردن.

🎯 اسلک چهار هدف اصلی داشت:

- حذف ترافیک از یک AZ در کمتر از ۵ دقیقه (سرعت)
- حذف ترافیک نباید باعث خطای قابل مشاهده برای کاربر بشه
- خروج و بازگشت ترافیک یک AZ باید تدریجی باشه (مثلاً ۱٪ یا ۱۰٪)
- مکانیزم Drain نباید به AZ مشکل‌دار وابسته باشه

🧠 استراتژی‌های پیاده‌سازی در اسلک

*️⃣منزوی‌سازی (Siloing): سرویس‌ها در یک AZ فقط با سرویس‌های همون AZ ارتباط داشته باشن. ساده‌ترین روش، اما برای همه سرویس‌ها امکان‌پذیر نیست.

*️⃣مدیریت سرویس‌های با consistency قوی: سرویس‌هایی مثل Vitess (لایه شاردینگ روی MySQL) نیاز به مدیریت failover دارن.

*️⃣تقسیم‌بندی براساس CAP: سرویس‌ها براساس نیازشون به Consistency یا Availability دسته‌بندی شدن:
🔤سرویس‌های Stateless مثل webapp ها (راحت‌ترین)
🔤سرویس‌های Eventually Consistent مثل Memcache (نسبتاً راحت)
🔤سرویس‌های Strongly Consistent مثل Vitess (سخت‌ترین)


*️⃣کنترل ترافیک با Envoy و xDS: استفاده از traffic weighting برای هدایت تدریجی ترافیک

چرا این بار موفق شدن؟
اسلک قبلاً یک بار تلاش کرده بود این کار رو انجام بده و شکست خورده بود. این بار چند اصل مهم رو رعایت کردن:

- تدریجی بودن (Incrementality): به جای ساخت یک سیستم کاملاً جدید و تغییر یکباره، هر سرویس رو جداگانه و تدریجی تغییر دادن.
- نگاه از پایین به بالا (Bottom-up): با هر تیم سرویس جداگانه کار کردن و راهکار مخصوص اون سرویس رو پیدا کردن.
- به اندازه کافی خوب (Good Enough): پذیرفتن اینکه لازم نیست همه سرویس‌ها یکجا و کامل تغییر کنن.
- رویکرد Roofshot به جای Moonshot: به جای یک حرکت مستقیم و بلندپروازانه، مجموعه‌ای از قدم‌های کوچکتر که در هر مرحله ارزش ایجاد می‌کنه.
- تست‌های منظم: هر هفته یک AZ رو drain می‌کردن و پیشرفت رو اندازه می‌گرفتن.

⛳️ نتایج:

- الان می‌تونن یک AZ رو در ۶۰ ثانیه از سرویس خارج کنن
- هزینه‌های انتقال داده بین AZ کاهش پیدا کرده
- یک مکانیزم blue-green deployment جدید به دست آوردن
- راهکار عمومی برای مقابله با مشکلات محدود به یک AZ دارن

📝 نکته‌های کلیدی برای پروژه‌های زیرساختی بزرگ

*️⃣تدریجی ولی مداوم کار کنید: پروژه‌های بزرگ زیرساختی باید گام به گام پیش برن
*️⃣در نظر بگیرید هر سرویس دلیلی برای وضعیت فعلیش داره: تصور نکنید که افراد دیگه اشتباه کردن
*️⃣ارزش رو در هر مرحله قفل کنید: پروژه باید در هر مرحله ارزش ایجاد کنه، نه فقط در پایان
*️⃣کارآیی رو برای کاهش ریسک فدا کنید: گاهی راه مستقیم، بهترین راه نیست

🔔 اگر سرویسی دارین که مردم بهش وابسته هستن یا با از دسترس خارج شدنش کار مردم می‌خوابه، لطفا قبل از وقوع حادثه، به فکر علاج باشین... تابستان در پیش است و قطعی برق نزدیک. دیتاسنترهای مختلف (ترجیحا پراکندگی شهری/استانی) می‌تونه در کنار معماری سلولی کمک کنه، هم به اعتبار و درآمد سازمان شما و مهم‌تر به کار مردم...

💬 اگر دوست داشتید در موردش صحبت کنیم، حتمن بگید، سوال و پیشنهاد هم مثل همیشه باعث خوشحالی...

📇 تاریخچه و زمینه پیدایش مایکروسرویس

شاید بد نباشه تا دفعه بعد که خواستید در مورد معماری و ساختار یه پروژه تصمیم بگیرید، یه بار پیشینه‌ی پیدایش مایکروسرویس رو مرور کنین تا از تناسب «نیاز» و «راهکار»ی که مدنظر دارید مطمئن باشید.

نمیشه دقیق و قاطع گفت «اولین» بار کی مفهوم مایکروسرویس رو پیاده کرده. مفهوم مایکروسرویس‌ از تکامل معماری‌های قبل‌تر از خودش، خصوصا به عنوان یک پاسخ به محدودیت‌های سیستم‌های یکپارچه، و پیچیدگی معماری سرویس‌گرا (SOA) شکل گرفت. حالا دو چیز رو باید توضیح داد، یک شیوه‌های امروزی‌تر پیاده‌سازی مایکروسرویس، و یکی مفهوم و معماری‌اش. برای پیاده‌سازی مدرن، نتفلیکس رو می‌شه به عنوان یکی از اولین و تأثیرگذارترین پذیرندگان رویکرد میکروسرویس‌ توی مقیاس بزرگ شناخت. نتفلیکس مهاجرت خودش از معماری یکپارچه به مایکروسرویس‌ها رو حدود سال ۲۰۰۹ شروع کرد، خیلی قبل از اینکه اصطلاح "مایکروسرویس‌" به طور رسمی سال ۲۰۱۱ مطرح بشه. تا سال ۲۰۱۱، نتفلیکس طراحی مجدد بخش قابل توجهی از سیستم‌هاش به مایکروسرویس‌ها رو تکمیل کرده بود و از AWS استفاده می‌کرد، و خیلی از الگوهایی که امروز به عنوان استاندارد یا best practice شناخته می‌شن رو پیاده کرده بود.

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

پذیرندگان بعدی این معماری، از eBay و Spotify و... همه یک سری دغدغه مشترک داشتن، یعنی مقیاس‌پذیری، پیچیدگی و وسعت سیستم، و استقرار، اونم با تیم‌های بزرگ.

بیایم نگاه بندازیم به روایات!
جناب Fred George یکی از پیشگامان معماری مایکروسرویس می‌گه هر مایکروسرویس باید به قدری ساده و کوچک باشه که توی ذهن یک توسعه‌دهنده جا بشه:

"small enough and simple enough that a single developer can understand the whole thing"

بعدتر همین رو مارتین فولر هم به نحوی تکرار می‌کنه.

حالا سوال اینه که اگر تیم توسعه و تعداد سرویس‌ها بزرگ نیستند، آیا مقیاس‌پذیری مورد نیازمون به حدی رسیده که scale-up پاسخگو نباشه و بریم سراغ شکست و توزیع سرویس‌ها؟ آیا زیرساخت لازم رو از پردازش ابری تا DevOps تا مونیتورینگ/observabilty و... داریم؟ آیا ظرفیت مستندسازی API، فرایند، کاتالوگ داده‌ها و فرایندها و... رو داریم؟

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

توی مباحث DDD به تفصیل خواهم گفت که معماری سازمانی ما هم حتی باید با شیوه تحلیل نیازمندی‌ها و شیوه ترجمه‌ی اون‌ها به راهکارهای نرم‌افزاری سازگار باشه.

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

لذا مایکروسرویس، در زمان مناسبش و با فراهم کرن پیش‌نیازهاش، و علی‌الخصوص وقتی که در خدمت حل‌کردن مسائل ما باشه همون قدر خوب و مفیده که وقتی زودهنگام یا بدون پیش‌نیازهاش می‌ریم سراغش، مضر!

💬 نظر یا تجربه شما چیه؟