پاسخ کوتاه: تست سیستم خودترمیم یعنی ارزیابی یک ادعای محدود دربارهٔ Control loop مشخص: Fault یا degradation چگونه حس میشود، چه زمانی و با چه خطایی Detection/Diagnosis رخ میدهد، کدام Policy چه Actionی را مجاز میکند، Action روی چه State و Subjectی اجرا میشود، Outcome مستقل چگونه صحت و side effect را میسنجد، سیستم آیا در زمان محدود همگرا میشود، و چه وقت automation باید متوقف و به انسان Escalate کند. «Pod دوباره Running شد» یا «Dashboard سبز است» هنوز Self-healing موفق و امن را ثابت نمیکند.
این مقاله یک Healing Action Evidence Record میسازد و Fault→Signal→Detection→Diagnosis→Knowledge/Policy→Plan→Action→Verification→Convergence/Escalation را قابل Replay میکند. Mutation Testing کد، Chaos Engineering، Resilience Testing، Observability و Operational Readiness را نیز از این موضوع جدا نگه میدارد. یک آزمایش آفلاین فارسی نشان میدهد چرا detect شدن fault، اجرای restart، بازگشت replica count و health سبز میتوانند همچنان نتیجهای خطرناک و ناقص باشند.
سیستم خودترمیم دقیقاً چیست؟
Self-healing یک برچسب مطلق نیست. یک سامانه میتواند برای failure mode محدود، در سطح container، process، instance، route، dependency، data replica یا business workflow اقدام خودکار یا نیمهخودکار داشته باشد. Subject، symptom/fault، desired state، action repertoire، time bound، safety constraint و escalation policy باید صریح باشند. Restart process با repair داده، تصحیح root cause یا بازیابی outcome کاربر یکسان نیست.
Self-healing الزاماً بدون انسان نیست
سطح autonomy میتواند advisory، human-approved، supervised automatic یا bounded automatic باشد. Human approval همیشه بد و automation کامل همیشه بالغ نیست. وقتی diagnosis نامطمئن، action برگشتناپذیر، blast radius بزرگ، data state مبهم یا safety impact بالا است، توقف و Escalation بخشی از رفتار درست Control loop است؛ «هیچ دخالت انسانی» معیار قبولی عمومی نیست.
MAPE-K؛ حرف K را حذف نکنید
Monitor دادهٔ Sensor را جمع و qualify میکند؛ Analyze symptom/hypothesis میسازد؛ Plan گزینه/Action را با Policy انتخاب میکند؛ Execute از Effector استفاده میکند؛ و Knowledge شامل topology/model، desired state، policy، history، context و evidence مورد استفادهٔ حلقه است. K یک مرحلهٔ آخر نیست؛ ورودی/حافظهٔ مشترک حلقه است. Stale یا ناسازگار بودن Knowledge میتواند Action درست را روی Subject غلط اجرا کند.
مقالهٔ اولیهٔ IBM Research دربارهٔ معماری Autonomic Computing interface و requirementهای رفتاری componentها و patternهای self-configuration/optimization/healing/protection را شرح میدهد و از componentهای autonomous یا semi-autonomous سخن میگوید. این یک معماری پژوهشی و prototype evidence است، نه استاندارد پذیرش یا تضمین برای سامانهٔ شما.
قالب Healing Claim
ClaimID: HC-031 Managed subject/build/config/topology: ... Controller/policy/model/action versions: ... Fault/symptom and applicability boundary: ... Desired state and user/business outcome: ... Detection/diagnosis/action/convergence objectives: ... Safety invariants / forbidden actions / blast radius: ... Autonomy level / approval / escalation: ... Evidence profile / decision owner / expiry triggers: ...
مرز موضوعی با روشهای نزدیک
| روش | پرسش مالک | رابطه با Self-healing |
|---|---|---|
| Fault injection | Fault مشخص چگونه فعال میشود؟ | Stimulus آزمایش میسازد |
| Chaos Engineering | Steady-state hypothesis زیر experiment ایمن چه میشود؟ | میتواند loop را به چالش بکشد |
| Resilience Testing | سامانه در Failure mode چگونه degrade/recover میکند؟ | Outcome گستردهتر را میسنجد |
| Mutation Testing | Test suite جهش کد را میکشد؟ | قدرت تست منطق controller را میسنجد |
| Observability | از outputها چه سؤالهایی قابل پاسخ است؟ | Evidence و sensor visibility میدهد |
| Operational Readiness | توان operate/recover/rollback/support چه وضعی دارد؟ | مالکیت و آمادگی بهرهبرداری را میسنجد |
| Healing Action Test | Control loop چه Actionی را چرا و با چه پیامدی اجرا کرد؟ | موضوع اختصاصی این مقاله |
طراحی Steady State، Hypothesis، Blast Radius و Stop Condition در راهنمای مهندسی آشوب مالک مستقل دارد؛ Outcome گستردهٔ Failure/Degradation/Recovery نیز در راهنمای تست تابآوری پوشش داده میشود. این مقاله Chaos یا Resilience را مترادف Self-healing Testing نمیکند.
Control-loop Inventory بسازید
هر controller/automation را فهرست کنید: owner، managed resource، sensor، evaluator، desired state، policy، action/effector، cadence/event trigger، state store، dependency، lock/lease، autonomy، permission، stop و escalation. چند loop ممکن است روی یک resource عمل کنند—autoscaler، restart controller، traffic manager و operator—و تعامل آنها oscillation یا action conflict بسازد.
Subject و Topology را Pin کنید
Service name کافی نیست. Workload/controller build، artifact digest، config، policy/model/rule version، desired-state revision، deployment/replica/zone، dependency graph، storage mode، feature flags و traffic/data scope را ثبت کنید. Controller و managed subject ممکن است release cadence جدا داشته باشند؛ هر دو هویت لازم دارند.
Fault، Error، Failure و Symptom را یکی نکنید
Fault میتواند علت/شرط فعالشده باشد؛ Error یک state نادرست داخلی؛ Failure انحراف observable از خدمت؛ Symptom چیزی است که Sensor میبیند. یک Symptom چند علت و یک Fault چند symptom دارد. Test باید injected condition، activation، propagation، affected scope و cleanup را جدا ثبت کند. Kill کردن process لزوماً network partition، stale cache یا semantic corruption را نمایندگی نمیکند.
Fault Model و Sampling
از Incident/Near Miss، FMEA/Hazard، architecture dependency و change history یک universe بسازید: crash، hang، latency، loss، duplicate، reorder، partition، quota، exhaustion، corrupt/stale state، bad config، credential expiry، dependency degradation و controller failure. Risk×frequency×detectability×action hazard را برای نمونهگیری اعلام کنید و Unknown/Unsupported را در denominator نگه دارید.
Sensor Contract
SensorID / producer / version / subject binding Signal semantics / unit / dimensions / timestamp Sampling / aggregation / window / delay / loss policy Validity / freshness / missing / NaN / stale handling Source authentication / integrity / access Expected fault-to-signal relationship Calibration / false-positive / false-negative evidence Owner / expiry / change trigger
Detection را جدا بسنجید
Fault activation، first valid signal، detector evaluation و detection declaration timestampهای جدا هستند. Detection latency را از injection command نسنجید مگر activation همان لحظه ثابت باشد. True/false positive/negative، duplicate detection، suppression، cooldown، hysteresis و missing signal لازماند. Detector خاموشی را «سلامت» تفسیر نکند.
Diagnosis همیشه Root Cause نیست
Action ممکن است بر basis یک symptom classification اجرا شود، بدون اینکه root cause قطعی شده باشد. Record باید candidate causeها، evidence، confidence/calibration، alternative، unknown و chosen action basis را نگه دارد. «Pod unhealthy» diagnosis برنامه نیست؛ restart شاید symptom را موقتاً حذف کند و علت در config یا dependency بماند.
Knowledge و Policy را Version کنید
Topology، inventory، desired state، threshold، rule/model، recent actions، incident suppression، maintenance window، budget و ownership بخشی از Knowledgeاند. Authority/source/freshness/consistency و update event را ثبت کنید. Policy باید applicability، priority، conflict resolution، action budget، cooldown، precondition، forbidden state و fallback داشته باشد.
Plan فقط انتخاب یک Action نیست
Planner باید گزینههای observe/wait، restart، reschedule، isolate، reroute، scale، degrade، clear safe cache، rotate lease، rollback، compensate، page و no-action را با constraint مقایسه کند. Expected benefit، cost/risk، prerequisites، dependency/capacity، reversibility و confidence ثبت شوند. گاهی safest plan توقف automation است.
Action Contract و Effector
ActionID / attempt / controller / policy decision Target identity / expected current state / preconditions Command/parameters/idempotency key/action budget Authorization / approval / lock or lease Start/ack/commit/complete timestamps Timeout/retry/backoff/dedup/cancel semantics Expected state transition and side effects Verification oracle / compensation / escalation
Timeout-before و Timeout-after-commit
اگر Ack نرسید، Action ممکن است اجرا نشده یا اجرا و پاسخ گم شده باشد. Retry بدون idempotency scope میتواند دو replica replacement، دو traffic shift یا دو compensation بسازد. AttemptID، idempotency key، commit evidence، dedup window و reconciliation لازماند. «دستور موفق بود» از status client بهتنهایی قابل استنتاج نیست.
State Machine ترمیم را مدل کنید
نمونهٔ stateها: HEALTHY→SUSPECT→DEGRADED→ACTION_PENDING→ACTING→VERIFYING→RECOVERED یا FAILED/ESCALATED. Event، guard، owner و timeout هر transition را بنویسید. Late/duplicate/reordered signal و concurrent action باید rule داشته باشند. Dashboard label جای state authority نیست.
Desired State و Real Outcome متفاوتاند
Replica count=۳ یعنی controller object با desired count همسو است؛ نمیگوید سه instance آماده، درست، دارای data سازگار و قادر به انجام Journey هستند. Outcome Oracle باید user/service behavior، correctness، latency/error، queue/backlog، state/data invariants، side effects و dependency impact را بسنجد. Health endpoint میتواند shallow یا cached باشد.
Kubernetes چه چیزی را Self-heal میکند؟
مستند رسمی Kubernetes Self-Healing restart container، replacement replica، reschedule روی node failure، برخی مسیرهای persistent-volume attachment و حذف Pod failed از Service endpoint را توضیح میدهد. همان صفحه هشدار میدهد storage failure ممکن است recovery step بخواهد و restart، مشکل زیربنایی application را حل نمیکند. بنابراین replacement Pod evidence یک لایه است، نه ضمانت continuity یا business correctness.
Readiness، Liveness و Startup Probe را قاطی نکنید
Liveness ممکن است restart را trigger کند؛ Readiness ورود به traffic را کنترل کند؛ Startup زمان شروع آهسته را محافظت کند. Probe اشتباه میتواند restart loop یا premature routing بسازد. endpoint، initial delay، period، timeout، thresholds، dependency coupling، shallow/deep semantics و behavior هنگام overload را آزمایش کنید.
Convergence را تعریف و اندازه بگیرید
Convergence یعنی در یک time bound و تحت input/fault schedule تعریفشده، state و outcome به region پذیرفتنی برسند و همانجا پایدار بمانند. Detection time، action start/commit، first healthy، first correct outcome، backlog drain و stability window را جدا کنید. Recovery لحظهای که دوباره degrade میشود convergence نیست.
Oscillation، Thrashing و Retry Storm
Action count/rate، state transition frequency، alternating scale/restart/route، resource churn، queue growth و retry amplification را بسنجید. Cooldown، hysteresis، rate/action budget، max attempts و stabilization window لازماند. چند controller مستقل ممکن است هرکدام policy خود را درست اجرا کنند ولی در ترکیب ناپایدار شوند.
Safety Invariant و Harm Floor
Automation نباید duplicate side effect، data loss/corruption، unauthorized access، excessive blast radius، unsafe capacity depletion، irreversible action یا suppression بیانقضا بسازد. Invariant را مستقل از health metric بررسی کنید. Fast recovery که order را دوبار commit کرده Fail است، حتی اگر latency و replica سبز باشند.
Actionهای برگشتناپذیر و Approval
Delete state، promote primary، rotate key، disable control، compensate transaction یا broad traffic shift نیازمند risk-based authorization است. Dry-run/preview، two-person approval، bounded target selector، break-glass، audit trail و kill switch را طراحی کنید. Model confidence بهتنهایی authorization نیست.
Escalation بخشی از Self-healing است
شرطهای Escalate: diagnosis confidence پایین، action budget تمام، no-convergence، repeated recurrence، conflicting controllers، safety invariant breach، unsupported fault، missing telemetry یا irreversible step. Route، severity، context/evidence pack، acknowledgment، human decision authority و automation pause/resume semantics را ثبت کنید.
Observability؛ Signal شرط لازم است، نه Verdict
راهنمای رسمی OpenTelemetry درباره Observability آن را توان پرسش از state سیستم از طریق outputها و instrumentation میداند و trace/metric/log را telemetry میشمارد. داشتن این سه نام، correctness یا diagnosis را تضمین نمیکند؛ semantic convention، resource/subject identity، context propagation، sampling، loss/delay، clock، retention و correlation لازماند.
Healing Trace بسازید
HealingTraceID / FaultID / ClaimID Subject/controller/policy/model/build identities Fault activate→signals→detection→diagnosis candidates Plan options / selected action / rationale / authority Action attempts / ack / commit / side effects State transitions and user/business outcome checks Convergence/stability/recurrence/oscillation evidence Escalation/human intervention/decision/correction
Oracle را از Controller مستقل کنید
اگر همان health bit هم Action را trigger و هم Success را اعلام کند، خطای مشترک ممکن است پنهان بماند. Independent oracle میتواند probe خارج از controller، business invariant، reconciliation، synthetic journey یا state observer جدا باشد. Expected result و verdict vocabulary در راهنمای Test Oracle مالک مستقل دارد.
History و Replay برای رفتار همزمان
Operation/Message/Action history با stable ID، invoke/return، process/node، payload digest، causal/context link و fault schedule نگه دارید. Wall-clock order بهتنهایی causal order نیست. Duplicate، late، reorder، partition و concurrent controllerها را برای Replay حفظ کنید. مدل History/Consistency/Replay در راهنمای تست سیستم توزیعشده مرز تخصصی دارد.
Mutation Testing را با Fault Injection مخلوط نکنید
تغییر threshold یا bug در controller source یک Code mutation است اگر توسط mutation operator و test-suite assessment مدیریت شود؛ ایجاد latency/partition/crash در runtime Fault injection است؛ تغییر policy/config یک Configuration perturbation است. Universe، safety و Oracle آنها متفاوت است. Mutation score و survivor analysis در راهنمای تست جهش مالک مستقلاند.
Test Matrix برای Control loop
Fault type×location×duration×magnitude×timing×concurrency×traffic×state×controller version×policy×topology×dependency×data mode را مدل کنید. همهٔ ترکیبها قابل اجرا نیستند؛ Intended/Selected/Executed/Passed/Failed/Inconclusive/Blocked/Unsupported/Unknown denominator صریح میخواهد. Pairwise یا sampling، interactionهای پرریسک را خودکار پوشش نمیدهد.
False Positive و False Negative Action
False positive detection میتواند restart سالم، traffic churn و data risk بسازد؛ false negative اجازه میدهد failure ادامه یابد. اما حتی detection درست ممکن است action غلط داشته باشد. Detection precision/recall، action appropriateness، unnecessary-action rate و missed-action outcome را جدا اندازه بگیرید و label authority/uncertainty را ثبت کنید.
Layered Verdict
| لایه | نمونه Verdict | سؤال |
|---|---|---|
| FAULT | ACTIVATED / INVALID | Fault واقعاً و در Scope فعال شد؟ |
| SENSOR | VALID / STALE / LOST | Signal معتبر و تازه بود؟ |
| DETECTION | TP / FP / FN / INCONCLUSIVE | Detector درست اعلام کرد؟ |
| DIAGNOSIS | SUPPORTED / AMBIGUOUS | Action basis قابل دفاع بود؟ |
| ACTION | COMMITTED / FAILED / DUPLICATE | Effector چه کرد؟ |
| OUTCOME | CORRECT / HARM / UNKNOWN | رفتار و state درست شدند؟ |
| CONVERGENCE | STABLE / OSCILLATING / TIMEOUT | حلقه همگرا ماند؟ |
| CLAIM | SUPPORTED / NOT-SUPPORTED | ادعای محدود چه وضعی دارد؟ |
Healing Action Evidence Record
RecordID / version / status / supersedes Claim/Fault/Experiment/HealingTrace identities Managed subject/controller/policy/model/topology digests Sensor/detector/diagnosis/knowledge contracts Plan options / selected action / authority Attempts / idempotency / state transitions / side effects Independent outcome and safety oracles Detection/action/recovery/convergence/stability times Coverage denominator / findings / uncertainty / alternatives Layered verdict / decision / action / expiry / correction
Fault Injection Safety
Environment، authorization، target selector، blast radius، excluded resources، steady-state guardrail، abort/kill switch، observer، cleanup و evidence capture را پیش از Run ثبت کنید. Production experiment مجوز ضمنی ندارد. شروع از simulation/local/staging و افزایش fidelity/risk باید تصمیممحور باشد؛ برای Production safety، راهنمای Shift-Right و ORR مسیر جدا دارند.
Operational Readiness و Ownership
Controller owner، service owner، on-call، risk owner و action authority را مشخص کنید. Runbook، monitoring، rollback، incident route و exception تازه لازماند. راهنمای آمادگی عملیاتی مالک Capability/Rehearsal/Exception برای بهرهبرداری است؛ Healing evidence جای آن را نمیگیرد.
آزمایش آفلاین فارسی: Restart سبز اما Heal نامعلوم
Fixture خیالی SYN-HEALING-LOOP-01 یک Checkout ساختگی دارد. FaultDetected=true، RestartExecuted=true، DesiredReplicasRestored=true و HealthDashboardGreen=true هستند؛ Checker سطحی SELF_HEALED_AND_SAFE میدهد. اما fault activation، sensor freshness، subject binding، diagnosis، policy/model version، action idempotency، state/data invariant، business outcome، harmful side effect، convergence و escalation ثبت نشدهاند.
دادههای فارسی/ایرانی Fixture
Fixture از Order/PaymentAttempt/Callback/Ledger/Reconciliation کاملاً ساختگی، IRR canonical و «تومان» فقط presentation استفاده میکند؛ رقمهای فارسی/عربی/لاتین، ی/ی و ک/ک، ZWNJ/Bidi، UTC و نمایش Asia/Tehran/جلالی نمایشی دارد. timeout-before/after-fake-action-commit، retry، duplicate، late، reorder، stale sensor، restart loop و duplicate fake side effect در حافظه شبیهسازی میشوند. هیچ شبکه، Production، Kubernetes cluster، شرکت، سازمان، اپراتور، ترافیک، کاربر، سفارش، پرداخت، PSP، بانک، پول واقعی، PII، token یا credential وجود ندارد.
Validator مستقل و قابل تکرار
const sizes={identity:22,claim:18,topology:20,fault:24,sensor:24,
detection:26,diagnosis:20,knowledgePolicy:24,planning:20,action:28,
state:26,outcomeOracle:28,convergence:24,safety:24,observability:18,
escalation:16,evidenceDecision:22,lifecycle:13};
const controls=Object.entries(sizes).flatMap(([g,n])=>
Array.from({length:n},(_,i)=>`${g}.${String(i+1).padStart(2,'0')}`));
if(controls.length!==397||new Set(controls).size!==397) throw Error('CONTROL_SET');
خروجی Validator چه بود؟
CONTROL_COUNT=397 SUPERFICIAL=SELF_HEALED_AND_SAFE AUDIT=HOLD-397 INDEPENDENT_TARGET=real-system-organization-operator-or-traffic:false:PASS CORRECTED=READY_FOR_HEALING_ACTION_EVIDENCE_REVIEW-0
۳۹۷ کنترل در ۱۸ گروه با نام group-qualified و assertion یکتایی ساخته شدند. نسخهٔ اولیهٔ fixture حتی بهعلت جمع نادرست گروهها assertion خورد و اجرا متوقف شد؛ پس از اصلاح واقعی اندازهٔ گروهها نتیجهٔ بالا به دست آمد. Pin شدن همهٔ فیلدهای مصنوعی فقط Record را آمادهٔ review میکند، نه Self-healing عمومی، diagnosis درست، root-cause repair، safety، resilience، availability، continuity، Production readiness یا واقعیت هر سیستم.
Evidence Pack حداقلی
- Claim، controller inventory و Fault modelهای versioned؛
- subject/controller/policy/model/topology/config digests؛
- Sensor/Detector/Action/Outcome Oracle contracts؛
- fault schedule و safety/abort/cleanup record؛
- Healing Trace با stable IDs و timestamps؛
- state/data/business invariants و side-effect evidence؛
- coverage denominator، findings و uncertainty؛
- layered verdict، decision، expiry و correction.
۲۴ Anti-pattern رایج
- Restart مساوی repair؛
- Running Pod مساوی outcome صحیح؛
- Replica count مساوی continuity؛
- Health سبز مساوی safety؛
- Automation کامل مساوی بلوغ؛
- MAPE بدون Knowledge؛
- Symptom مساوی root cause؛
- Detection درست مساوی action درست؛
- همان health bit برای trigger و oracle؛
- سه telemetry signal مساوی observability؛
- Fault injection مساوی Chaos Engineering؛
- Code mutation مساوی runtime fault؛
- یک crash نمایندهٔ همهٔ failureها؛
- بدون Fault activation evidence؛
- نادیدهگرفتن stale/missing sensor؛
- Retry action بدون idempotency؛
- timeout بهعنوان not-executed؛
- Action بدون current-state precondition؛
- Controllerهای متعدد بدون conflict test؛
- اولین healthy بدون stability window؛
- نادیدهگرفتن oscillation/backlog؛
- Action برگشتناپذیر بدون authority؛
- Escalation بهعنوان شکست طراحی؛
- Record بدون expiry/correction.
چکلیست ۲۲ موردی مالک Healing Test
- Claim و fault scope محدود است؟
- Managed subject/controller هویت دقیق دارند؟
- Desired state و real outcome جدا هستند؟
- Fault/Symptom/Failure تفکیک شده؟
- Fault activation و cleanup شاهد دارد؟
- Sensor semantics/freshness/subject binding روشن است؟
- FP/FN و missing signal policy داریم؟
- Diagnosis uncertainty/alternatives ثبت شده؟
- Knowledge/policy/model versioned هستند؟
- Plan option و no-action وجود دارد؟
- Action precondition/authority/idempotency دارد؟
- Ack/commit/complete جدا هستند؟
- State transitionها مدل شدهاند؟
- Oracle از controller مستقل است؟
- Correctness و side effect سنجیده میشوند؟
- Convergence/stability window تعریف شده؟
- Oscillation/retry storm action budget دارد؟
- Safety invariant و kill switch داریم؟
- Multiple-loop conflict آزموده شده؟
- Escalation route/authority آماده است؟
- Coverage denominator و Unknown آشکارند؟
- Decision/expiry/change trigger/correction ثبت شده؟
Pilot سیروزه بدون سیستم واقعی
هفتهٔ اول Control-loop inventory، Claim، Fault model و state machine خیالی بسازید. هفتهٔ دوم sensor/detector/action/oracle قراردادها و crash/stale-signal/timeout-after-commit را در Runner آفلاین اجرا کنید. هفتهٔ سوم oscillation، duplicate action، controller conflict و Escalation را تمرین دهید. هفتهٔ چهارم Reviewer مستقل Healing Trace را Replay، Unknownها را challenge و Record/schema را version کند. اتصال به cluster، Production، account ابری، operator telemetry یا traffic واقعی مجوز و طراحی ایمنی جدا میخواهد و در این Pilot نیست.
تغییر و Expiry
تغییر controller code، policy/model/threshold، probe، topology، dependency، schema، traffic mix، action permission، telemetry pipeline یا incident learning میتواند Evidence را Stale کند. Expiry تقویمی و event-based، selective retest map و visible correction لازماند. Result قدیمی را برای controller جدید clone نکنید.
جمعبندی اجرایی
برای تست Self-healing، restart را با repair و desired state را با outcome اشتباه نگیرید. Subject/Fault/Sensor/Policy/Action را Pin کنید، activation تا convergence را trace کنید، diagnosis uncertainty و false detection را نگه دارید، Action را با idempotency/current state/authority محدود کنید، Oracle مستقل و safety invariant بسازید، oscillation و side effect را بسنجید و Escalation را رفتار درست بدانید. خروجی حرفهای یک Healing Action Evidence Record محدود و منقضیشونده است، نه وعدهٔ «سیستم خودش همهچیز را درست میکند».
سؤالات متداول تست سیستم خودترمیم
تست سیستم خودترمیم چیست؟
ارزیابی Evidence یک Control loop مشخص از Fault و Signal تا Detection، Policy، Action، Outcome، Convergence و Escalation است. Claim باید Subject، failure mode، time bound، safety invariant و autonomy level محدود داشته باشد.
آیا جایگزینی خودکار Pod یعنی Self-healing موفق؟
فقط نشان میدهد controller برای desired replica state اقدامی کرده است. Readiness، traffic continuity، data consistency، business correctness، backlog drain، recurrence و علت زیربنایی باید جدا سنجیده شوند؛ storage یا application failure ممکن است اقدام دیگری بخواهد.
فرق Mutation Testing و Fault Injection چیست؟
Mutation Testing کد را با operatorهای تعریفشده تغییر میدهد تا قدرت test suite سنجیده شود. Fault Injection condition runtime مانند crash/latency/partition را فعال میکند تا رفتار سیستم دیده شود. تغییر config/policy نیز perturbation دیگری است و universe/Oracle خاص خود را دارد.
Convergence را چگونه میسنجیم؟
Region پذیرفتنی state+outcome و stability window را از پیش تعریف کنید؛ fault activation، detection، action commit، first correct outcome، backlog drain و stable recovery را timestamp بزنید. بازگشت لحظهای health که دوباره degrade میشود convergence نیست.
حداقل Healing Action Evidence Record چه دارد؟
Claim/Fault/Trace IDs، subject/controller/policy/model identities، Sensor/Detector/Action contracts، state transitions، attempts/idempotency، Oracle و safety evidence، convergence/oscillation/escalation، coverage، uncertainty، layered verdict، decision، expiry و correction.
