Logo GH

سیستم های خودکار شفا و خود بهبودی

1) درمان خودکار چیست و چرا لازم است

بهبود خودکار تثبیت خودکار سرویس در صورت عدم موفقیت بدون مداخله انسان، با اولویت بهبود علائم (SLO) نسبت به جستجوی علت ریشه (RCA) است.
MTTR پایین، حفاظت از بودجه ناقص، کاهش هزینه های عملیاتی و خطای انسانی.

خواص کلیدی:
  • تشخیص (معیارها/سیاهههای مربوط/synthetics/رویدادها).
  • راه حل (قوانین/سیاست ها/اکتشاف ML).
  • عمل (راه اندازی مجدد/مقیاس/ریختن/ficheflag/بازگشت/feilover).
  • تأیید (SLO سبز در پنجره داده شده).
  • بازگشت به تنزل.

2) نقشه مکانیسم بهبود خودکار

در سطح برنامه: idempotency، timeouts، retry + backoff + jitter، قطع کننده مدار، دیواره، تخریب حافظه پنهان (برازنده).
Kubernetes: زندگی/آمادگی/راه اندازی پروب، restartPolicy، PDB، HPA/VPA، Descheduler، Pod/Node خودکار اصلاح.
شبکه/لبه: محدودیت نرخ، سهمیه هر مستاجر، تخلیه اتصال، شکست باز/بستن، قوانین WAF.
صف/جریان: مصرف کننده autoscale، فشار پشتی مبتنی بر تاخیر، DLQ/پارکینگ.
ذخیره سازی/DB: replica-feilover، تعمیر خودکار (بازسازی)، autovacuum کاهش یافته، تعادل مجدد استخر اتصال.
CI/CD: محاسبات قناری، تحویل پیشرفته، بازگشت خودکار.
هماهنگ سازی رویداد: کنترل کننده ها/اپراتورها، موتورهای گردش کار (Argo، Airflow) با سیاست های سعی مجدد.
Watchdog/Heartbeats: سوئیچ مرد مرده برای مشاغل پس زمینه.

3) اصول طراحی ایمن خود بازیابی

1. SLO-driven: تمام اقدامات اتوماتیک توسط علائم مرتبط با تجربه کاربر ایجاد می شود.
2. Canary-first: ابتدا به صورت محلی/نقطه ای، سپس در سطح جهانی.
3. یک طرفه guardrails درب: عقبگرد توسط تایمر/شرایط، «کلید دو» برای عملیات مخاطره آمیز است.
4. Idempotency: هر عمل (راه اندازی مجدد، مهاجرت، چرخش) برای تکرار امن است.
5. قابلیت مشاهده توسط طراحی: برچسب های عمل، همبستگی با ردیابی، چه کسی/چه/چه زمانی/چرا ورود به سیستم.
6. کمترین امتیاز: اتوماسیون دارای حداقل حقوق (RBAC، اسرار محدوده).
7. هزینه آگاه: محدودیت در «گران» اقدامات (پوسته پوسته شدن, خروج, عکس های فوری).

4) تشخیص: سیگنال هایی برای شروع بهبودی خودکار

Метрики: 5xx٪، تاخیر p95/p99، تاخیر کافکا، قفل/تاخیر DB، فشار گره.
Synthetics: رگرسیون سقوط/مسیر uptime (ورود/سپرده).
سیاهههای مربوط: امضای خطای جدید، نرخ استثنا.
События K8s: CrashLoopBackOff، NodeNotReady، FailedScheduling.
ضربان قلب: سکوت کار> N دقیقه.

نمونه ای از PromQL باعث:
promql
API error regression sum (rate (http_requests_total{status=~"5"..}[5m]) )/sum (rate (http_requests_total[5m]))> 0. 01

Kafka: lag> threshold max by (topic, group) (kafka_consumergroup_lag)> 10000

K8s: pod в CrashLoopBackOff increase(kube_pod_container_status_restarts_total[5m]) > 3

5) اقدامات بازیابی خودکار (playbook)

5. 1 برنامه/شبکه

قطع کننده مدار ON با ناهنجاری باطن → سریع شکست سریع + پاسخ های حافظه پنهان/چاقو.
Retry + backoff + jitter با محدودیت و تکرار مجدد.
محدودیت نرخ/بارگذاری: تحت اضافه بار - اولویت بندی مسیرهای بحرانی.

5. 2 کوبرنتیز

راه اندازی مجدد ظرف (زنده بودن) و حذف hearth بر روی یک گره غیر سالم.
HPA/VPA: مقیاس خودکار توسط RPS/CPU/تاخیر/تاخیر ؛ VPA - فقط توصیه و یا خارج از ساعت اعمال می شود.
خودکار اصلاح گره: cordon + تخلیه برای مشکلات مداوم (tains).
Affinity/توپولوژی گسترش برای حفاظت در برابر AZ-فایل ها.

5. 3 صف/جریان

مصرف کنندگان در مقیاس خودکار по تاخیر ؛ کاهش موقت تولید کنندگان.

DLQ برای پیام های سمی ؛ بازپخش از آرشیوها

5. 4 DB/کش

خرابی در رونوشت با اعتبارسنجی حالت/پیکربندی.
بازنشانی استخر اتصال برای نشت اتصال.
داغ آماده به کار ترویج با پیکربندی خودکار از مشتریان.

5. 5 سی آی/سی دی

بازگشت خودکار با رشد 5xx/p95 در ترافیک قناری.
پرچم های ویژگی: خودکار خاموش از ویژگی های مشکل ساز به جای بازگشت جهانی.

6) تحویل پیشرفته و بازگشت خودکار

مثال (استراتژی قناری آرگو)

yaml strategy:
canary:
canaryService: api-canary stableService: api-stable steps:
- setWeight: 10
- pause: {duration: 5m}
- analysis:
templates:
- templateName: api-slo-check
- setWeight: 25
- pause: {duration: 10m}
- analysis:
templates:
- templateName: api-slo-check

اگر تجزیه و تحلیل قالب «شکست» را بازگرداند (خطاها/تأخیر بیش از حد)، راه اندازی به طور خودکار به عقب رانده می شود.

7) پرچم های ویژگی به عنوان یک ابزار خود بازیابی

کشتن سوئیچ برای ویژگی های مشکل ساز (سمت سرور).
هدف قرار دادن: غیر فعال کردن ویژگی در بخش/منطقه.
قانون خودکار: اگر 5xx٪ از ویژگی> X در Y دقیقه خاموش است و بلیط در عقب افتاده است.
تأیید: ویژگی پانل SLO با بودجه.

8) بیش از حد: چگونه به «درمان» خود را به مرگ

Shed-load: رد/کاهش QoS درخواست های غیر بحرانی (تعرفه ها، گزارش های سنگین).
Token-bucket/leaky-bucket و سهمیه مستاجر/کلید.
همزمانی تطبیقی (در سطح پروکسی/SDK) - کاهش همزمانی در صورت افزایش تأخیر.
Bulkhead: جدا کردن استخر موضوع/اتصال.

9) سازگاری و idemotency

کلید Idempotent (request_id) → حفاظت در برابر تکرار.
معاملات ترسناک (پرداخت، نوشتن) - فرآیندهای دو مرحله ای، تأیید/جبران خسارت (حماسه).
صندوق ورودی/صندوق ورودی и دقیقا یک بار через ذخیره سازی idempotency.

10) ایمنی و انطباق

حداقل RBAC برای اتوماسیون (فقط منابع لازم).
حسابرسی از تمام اقدامات: چه کسی/چه زمانی/چه سیگنال/چه اثر.
لغو دستی و «دکمه قرمز» برای غیر فعال کردن خودکار اقدامات.
برگزاری حقوقی در مصنوعات حادثه و سیاهههای مربوط به اتوماسیون.
اسرار - از طریق یک مدیر مخفی، چرخش کلیدی در طول اقدامات خود.

11) FinOps: قیمت «خود شفا»

محدودیت در حداکثر مقیاس خودکار به طوری که با چلپ چلوپ شکسته نشود.
هزینه هر معیار عمل: هزینه 1 راه اندازی مجدد، 1 ماکت اضافی، 1TB خروج.
Aggregates: هزینه هر دقیقه SLO صرفه جویی شده، هزینه هر حادثه کاهش یافته است.
سیاست های «حالت شب»: اگر ترافیک تجاری کم باشد، تهاجمی بودن اتوماسیون کمتر است.

12) قابلیت مشاهده اتوماسیون

برچسبها روی گرافها: 'remediation _ action =' rollback ',' source = 'argo' ',' reason = 'slo _ burn' '.
داشبورد جداگانه: فرکانس اقدامات خودکار، موفقیت، زمان بازیابی متوسط، نرخ بازگشت.

اثر → همبستگی SLO برای ارزیابی سود

13) پیکربندی و نمونه

13. 1 K8s: پروب ها و سیاست های راه اندازی مجدد

yaml livenessProbe:
httpGet: { path: /healthz, port: 8080 }
initialDelaySeconds: 20 periodSeconds: 10 timeoutSeconds: 2 readinessProbe:
httpGet: { path: /readyz, port: 8080 }
periodSeconds: 5 failureThreshold: 3 startupProbe:
httpGet: { path: /startupz, port: 8080 }
failureThreshold: 30 periodSeconds: 5

13. 2 هشدار → خودکار عمل (شبه)

yaml rule: api_5xx_rate_high action:
type: feature_flag target: "payments. new_flow"
set: false guardrails:
cooldown: 10m max_actions_per_hour: 2 rollback_if:
- condition: "5xx% not reduced within 5m"

13. 3 کافکا تاخیر autoscale (HPA توسط متریک سفارشی)

yaml metrics:
- type: Pods pods:
metric:
name: kafka_consumer_lag target:
type: AverageValue averageValue: "500"

14) تست خودکار شفا (هرج و مرج و روز بازی)

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

15) معیارهای «آمادگی خودکار بازیابی»

  • SLO ها تعریف شده اند، معیارها پایدار هستند، مصنوعی وجود دارد.
  • نمونه ها/healthz ،/readyz ،/startupz به درستی شرایط را منعکس می کنند.
  • هویت و حفاظت دوگانه (به ویژه در پرداخت).
  • پرچم ویژگی و نمایش قناری در دسترس هستند.
  • Guardrails: cooldown، اقدامات محدود کننده نرخ، کلید دوگانه برای عملیات با خطر بالا.
  • داشبورد اتوماسیون و سیاهههای مربوط به ممیزی.
  • لغو دستی و برنامه ریزی runbooks در مورد مسدود کردن.

16) پیاده سازی توسط فاز (4 تکرار)

1. پایه: SLO را تعریف کنید، پروب ها را اضافه کنید، شامل هشدارهای راه اندازی مجدد/اصلی باشید.
2. اقدامات محلی: phicheflag-kill-switch، مصرف کنندگان lag-scaling، canaries auto-rollback.
3. سطح مادون قرمز: اصلاح گره، پایگاه داده/حافظه پنهان، سایه بار.
4. بهینه سازی: گارد محافظ، محدودیت های FinOps، آزمایش های هرج و مرج، اکتشاف ML برای تشخیص.

17) خطاهای مکرر و ضد الگوهای

درمان علت به علائم → MTTR طولانی.
اقدامات جهانی بدون مرحله قناری.
بدون بازگشت و یا هیچ معیار خنثی.
بررسی سلامت کاذب (200 برای اعتیاد شکسته).
مقیاس خودکار «Bloat» بدون محدودیت/آستانه هزینه.
طوفان retray کور بدون عقب نشینی و deduplication.

18) مینی سوالات متداول

آیا شما نیاز به ML برای خودکار به ثمر رساند ؟

نه، اينطور نيست با قوانین SLO/metrics و guardrails شروع کنید. ML برای ناهنجاری ها و پیش بینی ها مفید است.

چرا راه اندازی مجدد همیشه کمک نمی کند ؟

اگر ریشه وابسته باشد (پایگاه داده، حافظه پنهان، شبکه)، راه اندازی مجدد فقط طوفان را تشدید می کند. نیاز به یک شکن/ریختن/feilover.

چگونه منافع را اثبات کنیم ؟

مقایسه MTTR و مصرف اشتباه قبل/بعد از بودجه. اضافه کردن هزینه در هر متریک کاهش.

مجموع

بهبود خودکار یک سیستم است، نه مجموعه ای از «راه اندازی مجدد عصا»: SLO-detection → اقدامات نقطه امن → تأیید هنگامی که بدتر شد. با ترکیب پروب، محاسبات قناری، ویژگی های پرچم، پوسته پوسته شدن، سایه، faylovers و guardrails سخت، شما کاهش MTTR، نگه داشتن بودجه اشتباه و نگه داشتن هزینه تحت کنترل است.

Contact

با ما در تماس باشید

برای هرگونه سؤال یا نیاز به پشتیبانی با ما ارتباط بگیرید.ما همیشه آماده کمک هستیم!

Telegram
@Gamble_GC
شروع یکپارچه‌سازی

ایمیل — اجباری است. تلگرام یا واتساپ — اختیاری.

نام شما اختیاری
ایمیل اختیاری
موضوع اختیاری
پیام اختیاری
Telegram اختیاری
@
اگر تلگرام را وارد کنید — علاوه بر ایمیل، در تلگرام هم پاسخ می‌دهیم.
WhatsApp اختیاری
فرمت: کد کشور و شماره (برای مثال، +98XXXXXXXXXX).

با فشردن این دکمه، با پردازش داده‌های خود موافقت می‌کنید.