سنجه باید رفتار سامانه را برای تصمیم روشن کند، نه اینکه به هدف نمایشی تبدیل شود. Serverless نیز سرور را حذف نمی‌کند؛ مدل مسئولیت و مقیاس را تغییر می‌دهد. امشب تعریف‌های منبع را با ادبیات جدید DORA و مرزهای عملی Function as a Service تکمیل می‌کنیم.

پرسش‌های ۱۰۱ تا ۱۰۵: سنجه‌ها و KPIهای دوآپس#

۱۰۱. DevOps metrics چیست؟#

پاسخ کوتاه: سنجه‌های دوآپس جریان تحویل، پایداری و نتیجهٔ عملیاتی را اندازه می‌گیرند. خانوادهٔ شناخته‌شدهٔ DORA شامل deployment frequency، change lead time، failed deployment recovery time، change fail rate و در مدل جدیدتر deployment rework rate است.

مخزن منبع چهار سنجهٔ کلاسیک را جدا می‌پرسد؛ راهنمای کنونی DORA پنج سنجهٔ عملکرد تحویل را به کار می‌برد. تعریف و نسخهٔ چارچوب را همراه گزارش ثبت کنید. metric باید در سطح یک محصول و بازهٔ ثابت تفسیر شود؛ مقایسهٔ خام دو تیم با نوع کار متفاوت گمراه‌کننده است. هدف، یافتن bottleneck و بهبود سیستم است، نه امتیازدادن به فرد.

۱۰۲. MTTR چیست؟#

پاسخ کوتاه: MTTR مخفف مبهمی است و می‌تواند mean time to repair، recover، restore یا resolve باشد. در پاسخ ابتدا تعریف سازمان را روشن کنید. برای تحویل نرم‌افزار، DORA امروز از failed deployment recovery time برای زمان بازگرداندن خدمت پس از انتشار ناموفق استفاده می‌کند.

میانگین tail incidentهای بزرگ را پنهان می‌کند؛ median و percentile و تفکیک severity مفیدند. نقطهٔ شروع نیز مهم است: آغاز impact، alert یا اعلام incident؟ پایان می‌تواند restore موقت یا رفع کامل باشد. زمان تشخیص را اگر جدا می‌سنجید صریح بگویید. کم‌شدن MTTR با بستن زودهنگام ticket بهبود نیست؛ تجربهٔ کاربر و معیار restore باید ثابت بماند.

۱۰۳. change failure rate چیست؟#

پاسخ کوتاه: change failure rate نسبت deploymentهایی است که به impairment و اقدام اصلاحی مانند rollback، hotfix یا restore منجر می‌شوند، به کل deploymentها در همان بازه. تعریف failure باید پیشاپیش و یکدست باشد.

اگر batch تغییرها بزرگ باشد، یک deployment ناموفق ده‌ها تغییر را پنهان می‌کند؛ اندازهٔ تغییر کنار نرخ تفسیر شود. failure کوچک canary با توقف خودکار با outage کامل یکسان نیست و severity می‌تواند لایهٔ دوم گزارش باشد. هدف صفر مطلق ممکن است تیم را به انتشار کمتر سوق دهد. نرخ را همراه frequency و recovery time ببینید تا تعادل سرعت و پایداری حفظ شود.

۱۰۴. deployment frequency چیست؟#

پاسخ کوتاه: deployment frequency تعداد دفعات استقرار در production طی یک بازه است. این سنجه اندازهٔ batch و توان جریان تحویل را تقریب می‌زند، اما به‌تنهایی ارزش یا کیفیت تغییر را نشان نمی‌دهد.

تعریف production و deployment در معماری‌های مختلف فرق دارد: انتشار mobile، firmware و سرویس وب cadence یکسان ندارند. deploy کردن همان artifact چند بار نباید بی‌دلیل عملکرد را بهتر نشان دهد. feature release نیز با deploy جداست. افزایش frequency وقتی مفید است که lead time، failure و SLO آسیب نبینند. هدف باید کاهش اصطکاک و batch باشد، نه ساخت commitهای بی‌ارزش برای بالا بردن عدد.

۱۰۵. lead time for changes چیست؟#

پاسخ کوتاه: در DORA، change lead time فاصلهٔ commit در version control تا استقرار در production است. cycle time گسترده‌تر از شروع توسعه یا ایده تا ارائهٔ ارزش را می‌توان جداگانه سنجید.

میانگین کل، زمان انتظار review، CI و approval را پنهان می‌کند؛ مرحله‌ها و percentile را جدا کنید. کاهش lead time با حذف آزمون کنترل‌نشده بهبود نیست. queue و batch بزرگ معمولاً زمان را بیشتر می‌کنند. timestampها باید خودکار و یکسان جمع شوند. اگر تیم‌ها نقطهٔ شروع متفاوت دارند، رتبه‌بندی آن‌ها بی‌معناست. این سنجه برای دیدن جریان است، نه فشار بر برنامه‌نویس.

پرسش‌های ۱۰۶ تا ۱۱۰: معماری Serverless#

۱۰۶. serverless computing چیست؟#

پاسخ کوتاه: Serverless مدل اجرایی مدیریت‌شده‌ای است که provider فراهم‌سازی server، patch و بخشی از scaling را پنهان می‌کند و مشتری کد یا سرویس را با واحد مصرف اجرا می‌کند. serverها وجود دارند، اما مدیریت مستقیم آن‌ها مسئولیت مصرف‌کننده نیست.

FaaS یکی از شکل‌هاست؛ database و container serverless نیز وجود دارند. مزایا با workload رویدادمحور و نوسانی بیشتر است. محدودیت‌های runtime، cold start، timeout، quota، observability و وابستگی provider باید سنجیده شوند. هزینهٔ هر درخواست برای بار کم جذاب است، اما بار ثابت پرمصرف ممکن است روی مدل دیگر ارزان‌تر باشد. shared responsibility همچنان شامل کد، داده، IAM و dependency مشتری است.

۱۰۷. AWS Lambda چیست؟#

پاسخ کوتاه: AWS Lambda سرویس FaaS است که function را در پاسخ به event یا invocation اجرا می‌کند و scaling و محیط اجرا را مدیریت می‌کند. trigger می‌تواند API، queue، object storage یا event service باشد.

رفتار retry و احتمال تحویل تکراری به نوع invocation و منبع رویداد بستگی دارد؛ در مسیرهای دارای retry، عملیات اثرگذار باید idempotent باشد. concurrency روی downstream فشار می‌آورد و باید reserve یا limit شود. function package، IAM role، timeout، memory و شبکه تنظیم‌اند. قرار دادن Lambda در VPC یا اتصال به database پیامد latency و connection دارد. لاگ و trace correlation لازم است. Lambda جایگزین خودکار هر سرویس طولانی یا stateful نیست.

۱۰۸. مزایای serverless چیست؟#

پاسخ کوتاه: کاهش مدیریت زیرساخت، scaling خودکار، پرداخت متناسب با مصرف و سرعت ساخت integration رویدادمحور از مزایا هستند. تیم می‌تواند زمان بیشتری روی منطق محصول بگذارد، به‌ویژه برای workloadهای پراکنده یا bursty.

این مزایا مشروط‌اند. سرویس‌های بسیار خرد می‌توانند deployment، local testing و observability را پیچیده کنند. هزینهٔ event، log، network و سرویس‌های جانبی باید محاسبه شود. abstraction provider عملیات را حذف نمی‌کند؛ quota، permission، retry و DLQ هنوز نیازمند طراحی‌اند. portability ممکن است کمتر شود، ولی همیشه بد نیست اگر قابلیت مدیریت‌شده ارزش بیشتری بسازد. تصمیم باید بر اساس الگوی واقعی مصرف گرفته شود.

۱۰۹. بهترین رویه‌های serverless کدام‌اند؟#

پاسخ کوتاه: function را کوتاه، stateless و idempotent نگه دارید؛ dependency و package را حداقل کنید؛ timeout و memory را اندازه‌گیری کنید؛ IAM را محدود، secret را بیرون کد و retry و failure destination را صریح تعریف کنید.

correlation ID، structured log، metric و trace برای زنجیرهٔ event لازم‌اند. schema و version event را مدیریت کنید. concurrency را با ظرفیت downstream هماهنگ و برای poison message سیاست داشته باشید. IaC محیط و permission را تکرارپذیر می‌کند. راهبرد deploy تدریجی و rollback نیاز است. حساسیت به cold start را با داده بسنجید؛ optimization حدسی یا warm نگه‌داشتن بی‌دلیل می‌تواند هزینه بسازد.

۱۱۰. FaaS چیست؟#

پاسخ کوتاه: Function as a Service مدلی است که واحد deployment و scaling آن function رویدادمحور است. provider runtime، scheduling و instanceها را مدیریت می‌کند و function از event ورودی، context و سرویس‌های بیرونی استفاده می‌کند.

FaaS با Serverless یکسان نیست؛ Serverless چتر بزرگ‌تری است. function نباید state ماندگار را روی filesystem محلی فرض کند، چون instance قابل تعویض است. ترتیب و تعداد تحویل event به منبع بستگی دارد. orchestration چند function می‌تواند به workflow engine نیاز داشته باشد، وگرنه retry و state میان فراخوانی‌ها مبهم می‌شود. برای پردازش طولانی یا latency بسیار قابل پیش‌بینی، گزینه‌های دیگر را نیز ارزیابی کنید.

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

metric وقتی سالم است که تعریف ثابت، دادهٔ قابل اعتماد و تصمیم مشخص داشته باشد. Serverless نیز وقتی مفید است که مدل event و مصرف با محدودیت سرویس بخواند. در هر دو مورد، بهینه‌سازی یک عدد بدون دیدن نتیجهٔ کاربر می‌تواند رفتار نامطلوب ایجاد کند.

منابع#