هزینه و قابلیت اطمینان دو محدودیت جدا نیستند؛ هر تصمیم ظرفیت، افزونگی و نگه‌داری روی هر دو اثر می‌گذارد. امشب به‌جای توصیهٔ سادهٔ «resource را کوچک کنید» یا «همیشه uptime را بیشتر کنید»، سازوکاری برای تصمیم‌گیری با داده، هدف خدمت و ریسک می‌سازیم.

پرسش‌های ۹۱ تا ۹۵: بهینه‌سازی هزینهٔ ابر#

۹۱. cloud cost optimization چیست؟#

پاسخ کوتاه: بهینه‌سازی هزینهٔ ابر یعنی بیشینه‌کردن ارزش workload نسبت به هزینه، نه صرفاً کم‌کردن صورت‌حساب. باید هزینه به owner و محصول نسبت داده شود، مصرف و ظرفیت سنجیده شود و معماری، قیمت و عملیات پیوسته بهبود یابند.

خاموش‌کردن resource بدون فهم SLO می‌تواند outage گران‌تری بسازد. کارها شامل حذف resource بلااستفاده، right-sizing، زمان‌بندی محیط غیرتولیدی، tier مناسب storage، تعهد برای بار پایدار و Spot برای کار متحمل قطع است. هزینهٔ license، network egress و عملیات نیز دیده شود. FinOps همکاری مهندسی، محصول و مالی را برای تصمیم داده‌محور سازمان می‌دهد؛ یک پروژهٔ کاهش هزینهٔ یک‌باره نیست.

۹۲. Reserved Instance چیست؟#

پاسخ کوتاه: در Amazon EC2، Reserved Instance یا RI معمولاً تخفیف صورتحساب در برابر تعهد یک یا سه‌ساله به ویژگی‌های مشخص مصرف است؛ یک ماشین فیزیکی از پیش کنارگذاشته‌شده نیست. رزرو ظرفیت مفهوم جداگانه‌ای دارد، هرچند برخی RIهای zonal اثر ظرفیت نیز دارند.

مخزن منبع RI را ساده معرفی می‌کند، اما پاسخ امروزی باید Savings Plans را نیز بشناسد؛ AWS برای بسیاری از نیازهای compute آن را منعطف‌تر و معمولاً ترجیحی معرفی می‌کند. پیش از تعهد، baseline پایدار، utilization، region، instance family و ریسک تغییر معماری را بررسی کنید. تخفیف بالا با مصرف‌نشدن تعهد می‌تواند هزینهٔ مؤثر را بدتر کند. RI ابزار قیمت‌گذاری است، نه auto scaling یا HA.

۹۳. Spot Instance pricing چیست؟#

پاسخ کوتاه: Spot امکان استفاده از ظرفیت مازاد EC2 با قیمت کمتر را می‌دهد، اما AWS می‌تواند ظرفیت را پس بگیرد. بنابراین workload باید interruption را تحمل کند و با checkpoint، retry، توزیع میان نوع و zone و ظرفیت جایگزین طراحی شود.

batch، CI worker و پردازش stateless نمونه‌های مناسب‌اند؛ پایگاه تک‌نمونه و کار غیرقابل checkpoint معمولاً مناسب نیست. قیمت تنها معیار نیست؛ زمان انتظار، شکست کار و پیچیدگی عملیات هزینه دارند. handler هشدار قطع مفید است، اما تضمین زمان کافی نمی‌دهد. Spot با Savings Plans جمع نمی‌شود و بخشی از تعهد آن را مصرف نمی‌کند. ترکیب On-Demand پایه و Spot افزوده، ریسک را کنترل می‌کند.

۹۴. راهبرد cost tagging را چگونه پیاده می‌کنید؟#

پاسخ کوتاه: ابتدا taxonomy کوچک و اجباری مانند owner، product، environment و cost-center تعریف می‌کنیم؛ مقدارها، مالک، منبع حقیقت و قواعد ارث‌بری را مستند و سپس در IaC و policy هنگام ساخت enforce می‌کنیم.

تعداد زیاد tag اختیاری کیفیت را پایین می‌آورد. بعضی هزینه‌ها tagپذیر نیستند یا tag با تأخیر در گزارش ظاهر می‌شود؛ account، subscription و project hierarchy نیز بخشی از allocation است. shared cost باید با قاعده‌ای شفاف—ثابت، متناسب یا بر اساس مصرف—توزیع شود. compliance tag را اندازه بگیرید و برای exception مسیر داشته باشید. tag بدون گزارش و تصمیم، صرفاً metadata اضافی است.

۹۵. cost allocation report چیست؟#

پاسخ کوتاه: گزارش تخصیص هزینه، هزینه و مصرف را با metadata و ساختار حساب به تیم، محصول، محیط یا مرکز هزینه نسبت می‌دهد. هدف ایجاد شفافیت و مسئولیت برای تصمیم است، نه فقط بازتولید invoice provider.

گزارش باید هزینهٔ مستقیم، shared، تخفیف، tax و unallocated را جدا نشان دهد. showback اطلاعات را به owner نشان می‌دهد؛ chargeback هزینه را رسماً به واحد منتقل می‌کند. درصد تخصیص، روند، forecast، anomaly و unit economics مانند هزینهٔ هر درخواست مفیدند. دادهٔ صورتحساب ممکن است دیر یا اصلاح شود، پس زمان و نسخهٔ dataset را ثبت کنید. عدد بدون روش allocation می‌تواند اعتماد تیم‌ها را از بین ببرد.

پرسش‌های ۹۶ تا ۱۰۰: Site Reliability Engineering#

۹۶. SRE چیست؟#

پاسخ کوتاه: Site Reliability Engineering رویکردی مهندسی برای عملیات است که قابلیت اطمینان را با هدف قابل سنجش، automation و اصول نرم‌افزار مدیریت می‌کند. SRE می‌پرسد چه سطح خدمتی لازم است و چگونه کار دستی تکراری را کاهش دهیم.

SRE نام تازهٔ sysadmin یا تیمی که همهٔ incidentها به آن سپرده شود نیست. مالکیت باید با تیم محصول مشترک باشد. SLI، SLO و error budget میان نیاز کاربر و سرعت تغییر قرارداد می‌سازند. automation زمانی ارزش دارد که کار تکراری و منبع خطا را کم کند؛ خودکارکردن عملیات نادر و مبهم ممکن است هزینهٔ بیشتری داشته باشد. قابلیت اطمینان صددرصد معمولاً هدف اقتصادی یا حتی قابل دستیابی نیست.

۹۷. SLO چیست؟#

پاسخ کوتاه: Service Level Objective هدف داخلی یا قراردادی تیم برای مقدار یک SLI در یک بازه است؛ مثلاً ۹۹٫۹٪ درخواست‌های معتبر طی ۲۸ روز موفق باشند. SLO باید از تجربهٔ کاربر و نیاز کسب‌وکار بیاید.

عدد بدون population، معیار success و window مبهم است. چند SLO برای availability و latency ممکن است لازم باشد، اما زیادشدن هدف‌ها تصمیم را سخت می‌کند. SLO با SLA یکسان نیست؛ SLA توافق بیرونی و پیامد نقض دارد، در حالی که SLO ابزار مهندسی و تصمیم‌گیری است. هدف نباید پایین‌تر از سطح لازم برای رضایت کاربر باشد و باید در شرایط عادی دست‌یافتنی بماند؛ سخت‌گیری بیشتر از نیاز واقعی نیز هزینه را بی‌دلیل بالا می‌برد.

۹۸. SLI چیست؟#

پاسخ کوتاه: Service Level Indicator اندازه‌گیری کمی رفتار خدمت از دید کاربر است؛ معمولاً نسبت رویداد خوب به کل رویداد معتبر، مانند درخواست موفق یا درخواست زیر آستانهٔ latency.

CPU یک زیرساخت SLI مستقیم تجربهٔ کاربر نیست، هرچند signal تشخیصی مهمی است. نقطهٔ اندازه‌گیری—client، load balancer یا backend—نتیجه را تغییر می‌دهد. درخواست سلامت، bot یا ترافیک نامعتبر ممکن است از denominator حذف شود، ولی قاعده باید پیشاپیش روشن باشد. metric گمشده و خطای telemetry نیز نباید بی‌صدا به موفقیت تعبیر شوند. SLI خوب قابل محاسبه، پایدار و مرتبط با تصمیم است.

۹۹. error budget چیست؟#

پاسخ کوتاه: error budget مقدار عدم‌قابلیت‌اطمینان مجاز در بازهٔ SLO است. اگر SLO برابر ۹۹٫۹٪ باشد، بودجهٔ نظری ۰٫۱٪ رویداد ناموفق است. این بودجه سرعت تغییر را با سلامت خدمت متعادل می‌کند.

بودجه پول یا سهمیه‌ای برای ایجاد عمدی outage نیست. burn rate نشان می‌دهد با چه سرعتی مصرف می‌شود؛ alert چندبازه‌ای می‌تواند سوختن سریع و آهسته را جدا کند. policy باید مشخص کند پس از مصرف بودجه چه می‌شود: توقف انتشار پرخطر، تمرکز بر reliability یا review. استثناهای ترافیک باید از قبل تعریف شوند. بودجه بدون اقدام توافق‌شده فقط dashboard دیگری است.

۱۰۰. toil در SRE چیست؟#

پاسخ کوتاه: toil کار عملیاتی دستی، تکراری، خودکارشدنی، واکنشی و بدون ارزش ماندگار است که با رشد سرویس خطی یا سریع‌تر زیاد می‌شود. restart تکراری و اصلاح دستی حساب‌ها نمونه‌اند.

هر کار عملیاتی toil نیست؛ تحلیل incident تازه یا طراحی ظرفیت می‌تواند ارزش مهندسی پایدار بسازد. ابتدا toil را با زمان و تکرار اندازه بگیرید، علت را بیابید و سپس حذف، self-service یا automation کنید. یک script شکننده ممکن است toil را پنهان یا منتقل کند. runbook و guardrail قدم میانی مفیدند. هدف SRE حذف کامل عملیات نیست، بلکه حفظ ظرفیت برای کار مهندسی و یادگیری است.

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

هزینه و reliability را به واحد تصمیم تبدیل کنید: هزینهٔ هر تراکنش، رویداد خوب در بازه، burn rate و زمان toil. ابزار خرید تخفیف یا dashboard بدون owner و policy نتیجه نمی‌دهد. پاسخ حرفه‌ای نشان می‌دهد چگونه داده به اقدام مشخص تبدیل می‌شود.

منابع#