مهندسی قابلیت اطمینان

1) SRE چیست و چرا مورد نیاز است

مهندسی قابلیت اطمینان سایت (SRE) یک رشته در رابط توسعه و بهره برداری است که قابلیت اطمینان را به یک ویژگی قابل اندازه گیری محصول تبدیل می کند. SRE معیارهای تجربه کاربر (SLIs)، اهداف کیفیت (SLOs)، بودجه خطا، اتوماسیون و تغییرات مدیریت شده را برای ارائه ارزش سریع تر بدون از دست دادن انعطاف پذیری متصل می کند.

اهداف کلیدی UX قابل پیش بینی، انتشار سریع، حداقل خرابی و هزینه کنترل مالکیت است.

2) اصول SRE

قابلیت اطمینان به عنوان یک ویژگی اولویت بندی به محدودیت های تعیین شده توسط SLO و اهداف کسب و کار.
بودجه خطا میزان تغییر را کنترل می کند. اگر بودجه سوزانده شود، تمرکز بر ثبات است.
اتوماسیون> عملیات دستی. هر وظیفه تکرار اسکریپت/اپراتور/خط لوله است.
قابلیت اندازه گیری فقط آنچه که اندازه گیری می شود (SLI/SLO) می تواند بهبود یابد.
فقط فرهنگ. پس از مرگ بدون اتهام، تمرکز بر علل سیستمیک.
شیفت به چپ کیفیت، ایمنی، آزمایش و قابلیت مشاهده بخشی از چرخه توسعه است.

3) سازمان و نقش

پلت فرم تیم SRE: ابزار مشترک، سیاست ها، خطوط لوله، GitOps، کاتالوگ خدمات.
SRE های جاسازی شده: در کنار تیم محصول، اهداف SLO مشترک کار کنید.
در تماس: چرخش، محدودیت بار، جبران خسارت، آموزش.
RACI: صاحب سرویس، صاحب SLO، IC در حوادث، Comms Lead، Scribe.

4) SLI/SLO و بودجه خطا (لینک محصول)

SLI: در دسترس بودن، تاخیر، موفقیت عملیات تجاری، ارتباط داده ها.
SLO: اهداف برای ویندوز 28-30 روز + استثنا.
بودجه خطا = 1 − SLO. سیاستمداران: نسخه ها، آزمایش ها، قناری ها و ویژگی ها توسط نرخ واقعی سوختگی تنظیم می شوند.
طراحی توسط گروه: مناطق، ارائه دهندگان، بخش های VIP - SLO های فردی به طوری که برای از دست دادن ناهنجاری ها.

5) مشاهده پذیری پیش فرض

معیارها: موفقیت/خطا، درصد p50/p95/p99، اشباع (CPU/mem/IO/conn).
سیاهههای مربوط: ساختار یافته، با همبستگی درخواست/انتشار/پرچم.
ردیابی: پایان به پایان نقشه از تاخیر و خطا، مسیرهای داغ.
Synthetics + RUM: نمونه های خارجی و تله متری مشتری واقعی.
داشبورد SLO: سوزاندن بودجه، حاشیه نویسی انتشار، قناری، ارائه دهندگان.

6) مدیریت تغییر و انتشار

CI/CD خط لوله: مجموعه های قطعی، امضای مصنوعی، اسکن های امنیتی، آزمایش های قرارداد.

استراتژی های پیشرفته: قناری/آبی سبز/سایه ؛ پرچم هایی با چرخه حیات

کیفیت دروازه: سیاست به عنوان کد، SLO-guardrails، بازگشت خودکار تحت تخریب.
GitOps: تنظیمات/سیاست ها به عنوان کد، ارتقاء محیط زیست، حسابرسی.

7) حوادث و پس از مرگ

اعلامیه در سطوح SEV/P، IC بلافاصله اختصاص داده می شود، با SEV-1 + آزاد می شود.
هشدار نرخ سوختگی: پنجره های کوتاه و بلند، حد نصاب بر اساس منطقه و نوع نمونه.
Playbooks: bickbacks, degradations, provider failover, limits/retrays.
RCA و CAPA: واقعیت، علیت، اقدامات قابل اندازه گیری، نقاط کنترل (D + 14/D + 30).
کاتالوگ دانش: استفاده مجدد از قالب ها و درس ها.

8) تست قابلیت اطمینان

تست های قرارداد و قراردادهای مبتنی بر مصرف کننده برای میکروسرویس ها

بارگذاری پروفایل ها با الگوهای واقعی، دم p99 test/GC pause/queue.
موارد هرج و مرج/انعطاف پذیری: غیر فعال کردن وابستگی ها، شبکه ها، تاخیر ؛ بازی روز و دریل DR.
مهاجرت پایگاه داده: گسترش → مهاجرت → قرارداد، برگشت پذیری، تست سازگاری دو نسخه.

9) مدیریت ظرفیت و هزینه (FinOps)

ظرفیت واحد و headroom در مسیرهای بحرانی.
HPA/VPA/KEDA توسط معیارهای کاربر و تاخیر صف.
چند ارائه دهنده: سهمیه، مسیریابی SLO/latency، خودکار feiler.
واحد اقتصاد: درخواست $/1k، $/معامله موفق ؛ بهینه سازی مخازن، سیاهههای مربوط، خروج.

10) ایمنی به عنوان بخشی از قابلیت اطمینان

SAST/DAST/SCA، جستجو برای اسرار، SBOM، امضای تصویر.
mTLS و سیاست های دسترسی (OPA/ABAC) حداقل امتیازات.
چرخش کلید/گواهی، نظارت بر مهلت، سناریوهای آزمون انقضا.
حوادث امنیتی - playbooks فردی، پزشکی قانونی، اطلاعیه تنظیم کننده.

11) فرهنگ و فرآیندها

بررسی SLO: هفتگی/ماهانه، اولویت بندی بدهی بیش از ویژگی های بنفش.
آموزش و شبیه سازی: آموزش در تماس، تمرین حادثه، روز هرج و مرج.
استانداردهای یکنواخت: چک لیست آمادگی برای تولید، ارتباطات SLA، فرمت پس از مرگ.
شاخص های خستگی هشدار: سر و صدا ≤ آستانه هدف، تنظیم منظم.

12) معیارهای بلوغ عملکرد SRE

معیارهای DORA: نرخ تخلیه، زمان سرب، MTTR، نرخ تغییر شکست.
اجرای SLO: سهم خدمات در منطقه سبز، روند سوزاندن نرخ.
بهداشت هشدار: اقدامات صفحه٪، هشدار متوسط/تغییر، نرخ کاذب.
RCA/CAPA: اجرای به موقع، سهم سیستم (غیر شخصی) دلایل، نرخ بازگشایی.
هزینه: نقطه $/SLO، درخواست $/1k، بهره وری خودکار.

13) چک لیست «آمادگی خدمات برای تولید»

• SLI/SLO، مالک SLO و پنجره مشاهده تعریف شده است.
• داشبورد و هشدار سوختگی تنظیم شده است، مصنوعی خارجی وجود دارد.
• خط لوله: امضا/اسکن، تست قرارداد/ادغام، قناری/پرچم، بازگشت خودکار.
• مهاجرت DB برگشت پذیر است، پروفایل های بار قله را پوشش می دهد.
• playbooks حادثه و اطلاعات تماس ارائه دهنده ؛ صفحه وضعیت
• صندلی ظرفیت تایید شده است ؛ HPA/KEDA و سهمیه ارائه دهنده بررسی شده است.
• پیکربندی ها و سیاست ها - در Git، ارتقاء چهارشنبه، حسابرسی فعال شده است.
• امنیت: اسرار خارج از کد، mTLS/چرخش، زمان TLS تحت کنترل.

14) ضد الگوهای

«99. 999٪ یا هیچ چیز" - اهداف غیر قابل دستیابی → نرخ سوختن قرمز ابدی.
انتشار بدون قناری و ویژگی های پرچم → انفجار بزرگ.
یک نقطه نظارت → آلارم کاذب و حذفیات.
تغییرات دستی از تنظیمات در محصول → رانش و unaudability.
پس از مرگ بدون CAPAs → حوادث تکراری.
SRE به عنوان «آتش نشانان» بدون حق تغییر معماری → بدهی بسته نشده است.

15) نقشه راه اجرای SRE (به عنوان مثال برای 3-6 ماه)

1. ماه 1: موجودی خدمات و مسیرهای بحرانی ؛ پیش نویس SLI/SLO ؛ داشبورد پایه و هشدار سوختگی ؛ شروع به تماس.

2. ماه 2: canaries/پرچم ویژگی، خودکار kickbacks ؛ تنظیمات GitOps ؛ کاتالوگ playbook حادثه ؛ صفحه وضعیت

3. ماه 3: تست قرارداد، پروفایل بار، مهاجرت پایگاه داده با توجه به طرح گسترش/قرارداد ؛ اولین روزهای بازی

4. ماه 4-6: مسیرهای چند ارائه دهنده، تمرینات DR، بهینه سازی هزینه، معیارهای بلوغ، KPI ها برای تیم ها.

16) خط پایین

SRE یک سیستم عامل توسعه است: اهداف کیفیت شفاف (SLO)، نرخ تغییر کنترل شده (بودجه خطا)، اتوماسیون و نظم و انضباط حادثه، تست انعطاف پذیری و هزینه آگاهانه. با این رویکرد، انتشارها معمول می شوند و قابلیت اطمینان به یک مزیت رقابتی تبدیل می شود.