آزمون کارایی باید ظرفیت و گلوگاه را با یک workload تعریف‌شده آشکار کند؛ API Gateway نیز باید سیاست‌های ورودی را بدون تبدیل‌شدن به جعبهٔ جادویی اعمال کند. امشب ده پرسش را با محور قرارداد قابل اندازه‌گیری مرور می‌کنیم: چه باری، چه هدفی، چه خطری و چه شواهدی؟

پرسش‌های ۷۱ تا ۷۵: آزمون کارایی#

۷۱. performance testing چیست؟#

پاسخ کوتاه: آزمون کارایی رفتار سامانه را زیر workload کنترل‌شده اندازه می‌گیرد تا latency، throughput، خطا، مصرف resource و محدودیت ظرفیت با هدف مشخص مقایسه شوند. نتیجه باید به سؤال طراحی یا آمادگی انتشار پاسخ دهد.

عبارت «هزار کاربر» بدون الگوی درخواست، concurrency، اندازهٔ داده و think time مبهم است. محیط، نسخه، dataset و dependency باید ثبت شوند. آزمون روی production فقط با مجوز، guardrail و طرح توقف قابل قبول است. performance test بهینه‌سازی را ثابت نمی‌کند؛ baseline و تکرار هم‌شرایط لازم است. همچنین سرعت client مولد بار نباید bottleneck پنهان باشد.

۷۲. انواع آزمون کارایی کدام‌اند؟#

پاسخ کوتاه: load test رفتار زیر بار مورد انتظار را می‌سنجد؛ stress test از ظرفیت عبور می‌کند تا نقطهٔ شکست و بازیابی را ببیند؛ spike جهش ناگهانی، soak یا endurance اثر زمان طولانی، و scalability اثر افزودن resource را بررسی می‌کند.

volume test حجم زیاد داده و capacity test سقف قابل قبول را هدف می‌گیرند. این نام‌ها در تیم‌ها کمی متفاوت‌اند، پس هدف را همراه نام بگویید. برای نمونه، soak باید leak، رشد queue و افت pool را طی ساعت‌ها ببیند. stress test بدون معیار توقف می‌تواند محیط را از کار بیندازد. آزمون هر نوع باید ramp-up، steady state، ramp-down و recovery را پوشش دهد.

۷۳. ابزارهای performance testing کدام‌اند؟#

پاسخ کوتاه: Apache JMeter، k6، Gatling و Locust نمونه‌های رایج تولید بارند. ابزار را بر اساس پروتکل، مدل بار، زبان سناریو، توزیع generator، گزارش، integration با CI و مهارت تیم انتخاب می‌کنیم.

خود ابزار پاسخ معماری نیست. generator باید resource کافی و ساعت هماهنگ داشته باشد؛ چند generator نیازمند تجمیع درست metric است. telemetry سرور مانند metric، log، trace و profile باید هم‌زمان جمع شود تا فقط «کند شد» نبینیم. سناریوی version-controlled، دادهٔ ساختگی و threshold قابل اجرا در pipeline ارزش بیشتری از dashboard اختصاصی بی‌تکرار دارد. محدودیت و مجوز هر ابزار را نیز بررسی کنید.

۷۴. بهترین رویه‌های آزمون کارایی چیست؟#

پاسخ کوتاه: هدف و SLO را پیش از آزمون تعریف کنید، workload را از رفتار واقعی مدل کنید، baseline بگیرید، محیط و داده را کنترل کنید، به‌آرامی بار را افزایش دهید و هم client و هم server را مشاهده کنید.

cache گرم و سرد، connection reuse، authentication و failure dependency روی نتیجه اثر دارند. یک بار اجرا evidence کافی نیست؛ تکرار و پراکندگی را ببینید. percentileها از average مفیدترند، اما p99 با نمونهٔ کم ناپایدار است. دادهٔ حساس را وارد test نکنید و cleanup داشته باشید. پس از هر تغییر فقط عدد بهتر را گزارش نکنید؛ هزینهٔ resource و اثر بر error rate را نیز مقایسه کنید.

۷۵. نتیجهٔ performance test را چگونه تحلیل می‌کنید؟#

پاسخ کوتاه: ابتدا صحت workload و سلامت generator را تأیید می‌کنم، سپس latency percentile، throughput و error را در طول زمان با saturation منابع و dependencyها هم‌بسته می‌کنم. نقطهٔ knee جایی است که افزایش بار، latency یا خطا را نامتناسب بالا می‌برد.

متوسط latency tail را پنهان می‌کند. خطای timeout ممکن است در client، gateway یا backend ساخته شود و باید با trace یا log تفکیک شود. CPU پایین به معنی ظرفیت آزاد نیست؛ lock، I/O، connection pool و queue می‌توانند محدودکننده باشند. نتیجه باید شامل محیط، commit، سناریو، بازهٔ اطمینان یا پراکندگی، bottleneck محتمل و آزمایش بعدی باشد؛ نه فقط یک screenshot.

پرسش‌های ۷۶ تا ۸۰: API Gateway و API#

۷۶. API Gateway چیست؟#

پاسخ کوتاه: API Gateway نقطهٔ ورودی مدیریت‌شده برای APIهاست که درخواست client را route می‌کند و policyهای مشترکی مانند authentication، rate limit، TLS termination، transformation و telemetry را اعمال می‌کند.

Gateway با load balancer هم‌پوشانی دارد، اما معمولاً در لایهٔ application، هویت و چرخهٔ API نقش بیشتری می‌گیرد. نباید منطق کسب‌وکار گسترده در آن جمع شود؛ وگرنه bottleneck سازمانی و فنی می‌شود. خود gateway باید highly available و محدودیت اندازه، timeout و header آن روشن باشد. اگر تمام سرویس‌ها فقط از آن قابل دسترسی‌اند، bypass شبکه‌ای نیز باید بسته شود.

۷۷. مزایای API Gateway چیست؟#

پاسخ کوتاه: policy مشترک و یک ورودی پایدار، کاهش تکرار authentication و telemetry، پنهان‌کردن توپولوژی داخلی، version routing و کنترل مصرف از مزایای آن‌اند. client به‌جای شناختن هر سرویس، قرارداد ورودی مشخصی می‌بیند.

متمرکزکردن policyها اجرای یکدست آن‌ها را آسان می‌کند، اما blast radius و latency نیز افزایش می‌یابند. gateway نمی‌تواند authorization شیء کسب‌وکار را همیشه بفهمد؛ backend باید مجوز دامنه‌ای را حفظ کند. aggregation پاسخ ممکن است round trip را کم کند، اما coupling را بالا ببرد. مزیت واقعی وقتی حاصل می‌شود که مالک، policy as code، آزمون قرارداد و روش rollout وجود داشته باشد.

۷۸. API security چیست؟#

پاسخ کوتاه: امنیت API حفاظت از endpoint، داده و عملیات در برابر دسترسی یا مصرف نامجاز است. authentication هویت را می‌سنجد؛ authorization اجازهٔ هر عمل و هر object را؛ و validation، limit، encryption و audit لایه‌های مکمل‌اند.

داشتن token به‌تنهایی کافی نیست. Broken Object Level Authorization زمانی رخ می‌دهد که کاربر با تغییر شناسه به دادهٔ دیگری برسد. schema ورودی، اندازهٔ body، timeout، inventory نسخه‌ها و egress به APIهای ثالث باید کنترل شوند. secret در URL و log نرود. پاسخ خطا اطلاعات داخلی نشت ندهد، ولی correlation ID برای عیب‌یابی باقی بماند. OWASP API Security Top 10 یک نقطهٔ شروع است، نه چک‌لیست کامل.

۷۹. rate limiting چیست؟#

پاسخ کوتاه: rate limiting تعداد یا هزینهٔ درخواست را در یک بازه برای هویت، کلید، IP یا منبع محدود می‌کند تا عدالت مصرف، کنترل هزینه و مقاومت در برابر سوءاستفاده بهتر شود.

الگوریتم‌هایی مانند token bucket امکان burst کنترل‌شده، leaky bucket خروجی هموار و fixed یا sliding window شمارش زمانی می‌دهند. کلید محدودسازی باید با مدل تهدید سازگار باشد؛ IP پشت NAT می‌تواند کاربران زیادی را یکی کند. پاسخ 429 و Retry-After به client امکان backoff می‌دهد. rate limit جای کنترل concurrency، quota بلندمدت، WAF یا ظرفیت backend را نمی‌گیرد و state توزیع‌شدهٔ آن نیازمند سازگاری روشن است.

۸۰. API documentation چیست؟#

پاسخ کوتاه: مستند API قرارداد قابل استفادهٔ endpointها، روش‌ها، schema، authentication، خطا، limit، versioning و مثال را توضیح می‌دهد. OpenAPI می‌تواند بخش HTTP API را ماشین‌خوان کند و برای اعتبارسنجی، client یا portal به کار رود.

مستند خوب فقط فهرست URL نیست؛ semantics فیلد، idempotency، pagination، زمان و سیاست سازگاری را روشن می‌کند. مثال باید با schema سازگار و secret آن ساختگی باشد. تولید خودکار از کد drift را کم می‌کند، ولی توضیح نیت را جایگزین نمی‌کند؛ design-first نیز بدون آزمون implementation منحرف می‌شود. contract test و review تغییر ناسازگار با client را زودتر نشان می‌دهند.

جمع‌بندی مصاحبه‌ای#

در آزمون کارایی، workload قرارداد آزمایش است؛ در API نیز schema و policy قرارداد تعامل‌اند. هر دو اگر مبهم باشند خروجی گمراه‌کننده می‌دهند. عدد را بدون واحد و بازه نگویید و کنترل را بدون failure mode معرفی نکنید.

منابع#