تحلیل علت ریشه‌ای؛ RCA از Evidence تا اقدام مؤثر

ساعت ۱۰:۰۲، کاربر پرداخت را تأیید می‌کند؛ PSP مبلغ را ثبت می‌کند اما پاسخ در شبکه گم می‌شود. سرویس Checkout، Timeout را «عدم پرداخت» می‌فهمد و با مرجع تازه دوباره درخواست می‌فرستد. ساعت ۱۰:۰۴، مشتری دو برداشت می‌بیند. نوشتن «علت ریشه‌ای: خطای برنامه‌نویس در Retry» سریع است، اما توضیح نمی‌دهد چرا State مبهم بود، چرا مرجع تازه مجاز شد، چرا Reconciliation قبل از Retry وجود نداشت، چرا تست Timeout-after-commit غایب بود و چرا Alert اختلاف Ledger را دیر دید.

تحلیل علت ریشه‌ای (Root Cause Analysis یا RCA) فرایندی Evidence-led برای بازسازی رخداد، آزمودن چند فرضیهٔ علّی و تبدیل یادگیری به کنترل قابل‌راستی‌آزمایی است. خروجی خوب، داستان متقاعدکننده یا نام یک مقصر نیست؛ زنجیره‌ای از Fact→Causal hypothesis→Evidence for/against→Action→Effectiveness verification است. این راهنما RCA را برای نقص‌ها، رخدادهای Production و Near missهای نرم‌افزاری از ابتدا تا بسته‌شدن اقدام‌ها اجرا می‌کند.

تحلیل علت ریشه‌ای چیست و چه چیزی نیست؟

RCA عنوان جمعی برای روش‌هایی است که می‌کوشند بفهمند یک پیامد نامطلوب چگونه و تحت چه شرایطی ممکن شد و چه تغییر کنترل‌شده‌ای احتمال یا شدت تکرار آن را کاهش می‌دهد. در سیستم توزیع‌شده، معمولاً «یک ریشه» وجود ندارد؛ Trigger، شرایط نهفته، کنترل غایب، عامل تشدیدکننده و شکاف تشخیص ممکن است با هم Incident را بسازند.

RCA با Fix باگ یکی نیست

Fix رفتار معیوب فعلی را اصلاح می‌کند؛ RCA می‌پرسد چرا آن رفتار ایجاد، پذیرفته، منتشر، دیر کشف یا سخت بازیابی شد. همهٔ باگ‌ها به RCA کامل نیاز ندارند و هر RCA نیز الزاماً به تغییر کد ختم نمی‌شود. برای گردش یک Defect از ثبت تا Verification، راهنمای مدیریت نقص نرم‌افزار را ببینید؛ این مقاله نقطهٔ عمیق یادگیری پس از Triggerهای تعریف‌شده را مالک است.

RCA با Troubleshooting یکی نیست

Troubleshooting در لحظه می‌پرسد «چه چیزی را تغییر دهیم تا سرویس برگردد؟». RCA پس از تثبیت می‌پرسد «چه ترکیبی از شرایط و کنترل‌ها این رخداد و این Impact را ممکن کرد؟». Restart ممکن است Recovery مؤثر باشد، اما علت و اقدام پیشگیرانه نیست.

RCA با Postmortem یکی نیست

Postmortem یک Artifact وسیع‌تر است: Summary، Impact، Timeline، Detection، Response، آنچه خوب/بد پیش رفت، عوامل علّی، جاهایی که خوش‌شانس بودیم و Action itemها. RCA بخش تحلیل علّی آن است. یک Defect مهم بدون Incident نیز می‌تواند RCA داشته باشد؛ یک Postmortem نیز ممکن است چند مسیر علّی داشته باشد.

RCA با Retrospective و FMEA یکی نیست

Retrospective چرخهٔ عمومی بازاندیشی تیم است؛ RCA حول یک Event یا Cluster شواهدی شکل می‌گیرد. FMEA و Threat modeling آینده‌نگرند و Failure modeهای ممکن را پیش از رخداد تحلیل می‌کنند؛ RCA عمدتاً پس‌نگر است. یادگیری RCA باید مدل‌های آینده‌نگر را به‌روزرسانی کند، نه اینکه جای آن‌ها را بگیرد.

ابتدا مهار؛ تحلیل عمیق بعد از تثبیت

در زمان Incident، اولویت با ایمنی کاربر، محدودکردن Blast radius، توقف زیان، Recovery و ارتباطات است. جلسهٔ طولانی «پنج چرا» هنگام برداشت تکراری یا نشت داده، Attention پاسخ‌گوها را مصرف می‌کند.

سه جریان را از هم جدا کنید

Response: Detect، Triage، Contain، Mitigate، Recover و Communicate؛
Evidence preservation: حفظ لاگ، Trace، Snapshot پیکربندی، فرمان‌ها و Decision log بدون ایجاد خطر تازه؛
Learning: Timeline، RCA، اقدام، Verification و انتشار متناسب پس از تثبیت.

NIST در SP 800-61 Revision 3 Incident response را بخشی از Cybersecurity risk management می‌بیند و بر بهبود آمادگی، Detection، Response و Recovery تأکید می‌کند. برای رخداد امنیتی، الزامات قانونی/قراردادی، Evidence handling و افشای هماهنگ را با تیم Security/Legal تعیین کنید؛ این مقاله مشاورهٔ حقوقی نیست.

Fix فوری را با Cause اشتباه نگیرید

Mitigation: Retry پرداخت موقتاً خاموش شد.
Recovery: تراکنش‌های مبهم Reconcile و مبالغ تکراری بازگردانده شد.
Correction: State machine رفتار Unknown را اصلاح کرد.
Corrective action: Retry فقط با همان Operation ID و پس از lookup مجاز شد.
Detection action: اختلاف PSP↔Ledger ظرف ۵ دقیقه Alert می‌شود.
Systemic action: همین قرارداد در تمام Adapterهای پرداخت Audit شد.

هر شش مورد ارزش دارند، اما نقش یکسان ندارند. خاموش‌کردن Retry Incident را مهار می‌کند؛ به‌تنهایی اثبات نمی‌کند Failure class برطرف شده است.

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

اگر هر Bug یک جلسهٔ چندساعته بسازد، فرایند به تشریفات تبدیل می‌شود. Triggerها را پیش از رخداد تعریف و عمق تحلیل را با Risk متناسب کنید.

Triggerهای مناسب

Impact کاربر یا کسب‌وکار از آستانهٔ تعریف‌شده عبور کرده است؛
از دست‌رفتن/خرابی داده، زیان مالی، Security/Privacy یا Safety مطرح است؛
Rollback، Failover، مداخلهٔ On-call یا Recovery طولانی لازم شده است؛
Monitoring شکست خورده و مشتری یا عملیات رخداد را زودتر دیده است؛
Defect یا Failure mechanism در چند محصول/تیم تکرار یا Cluster شده است؛
Near miss نشان داده فقط شانس، ساعت روز یا حضور فرد خاص مانع Impact شده است؛
Stakeholder مجاز بر پایهٔ Risk درخواست تحلیل کرده است.

راهنمای فرهنگ Postmortem در Google SRE نیز معیارهایی مانند اختلال کاربر، Data loss، مداخلهٔ On-call، زمان رفع بالا و Monitoring failure را مثال می‌زند و توصیه می‌کند Triggerها از قبل روشن باشند.

سه عمق عملی

عمق	مناسب برای	حداقل خروجی
Learning note	نقص کم‌اثر و تک‌موردی با Mechanism روشن	Fact، Cause hypothesis، Fix، Regression evidence
Mini RCA	تکرار، Near miss یا Risk متوسط	Timeline کوتاه، چند فرضیه، Action/Owner/Verification
Full RCA/Postmortem	Impact شدید، داده/مالی/امنیت یا چندسیستمی	Scope، Impact، Timeline، Causal graph، Response review، Action portfolio، review

Severity به‌تنهایی تعیین‌کننده نیست. Incident کم‌اثر که فقط با خوش‌شانسی کوچک مانده، ممکن است یادگیری عمیق‌تری از یک Failure پراثر اما کاملاً شناخته‌شده داشته باشد.

تیم RCA و حق تصمیم

RCA نباید گزارش انفرادی کسی باشد که قرار است از تصمیم خودش دفاع کند. تیم کوچک اما چنددیدگاهی تشکیل دهید و Scope/Authority را از ابتدا روشن کنید.

نقش‌های پیشنهادی

Facilitator: فرایند، زبان بی‌طرف، Timebox و تفکیک Fact/Hypothesis را نگه می‌دارد؛
Incident/Defect owner: Timeline و زمینهٔ Response را ارائه می‌کند؛
Service/Engineering owner: Mechanism و معماری را بررسی می‌کند؛
QA/Test: Test basis، Evidence gap، Oracle و بازتولید را می‌آورد؛
SRE/Ops/Data/Security: Telemetry، تغییر، ظرفیت، داده و تهدید مربوط را بررسی می‌کند؛
Product/Support/Business: Impact واقعی و Journey مشتری را اصلاح می‌کند؛
Action owner: تحویل و Evidence اثر هر اقدام را می‌پذیرد؛
Risk/decision owner: Residual risk، بودجه و استثنا را می‌پذیرد یا رد می‌کند.

مسئولیت کیفیت و اقدام‌ها بین نقش‌ها توزیع می‌شود؛ مدل عملی در رهبری کیفیت با مالکیت همگانی توضیح داده شده است.

Blameless یعنی بدون مسئولیت نیست

Blameless یعنی رفتار افراد را در اطلاعات، ابزار، فشار، Incentive و Guardrail همان لحظه تحلیل کنیم و زبان تحقیرآمیز به کار نبریم. Action owner، Due date، Escalation و Risk acceptance همچنان لازم‌اند. رفتار عمدی زیان‌بار یا مسائل انضباطی ممکن است مسیر مستقل سازمانی داشته باشد، اما نباید بهانه‌ای برای توقف تحلیل System factors شود.

Evidence Pack را قبل از فراموشی بسازید

حافظه پس از Incident با Outcome و روایت‌های دیگران تغییر می‌کند. ابتدا دادهٔ خام و محدودیت آن را حفظ کنید؛ سپس جلسهٔ مشترک را برگزار کنید.

حداقل بستهٔ شواهد

{
  "case_id": "INC-PAY-2026-0812",
  "scope": "checkout → payment adapter → PSP → ledger",
  "build_commit": "checkout-2841@a4c91e7",
  "config_flags_hash": "sha256:...",
  "environment": "production-ir-2",
  "time_basis": "UTC; display=Asia/Tehran",
  "impact_window_utc": ["06:31:02Z", "06:48:19Z"],
  "affected": { "orders": 27, "confirmed_duplicate_charges": 3 },
  "correlation_keys": ["order_id", "payment_operation_id", "psp_reference"],
  "evidence": ["trace", "app_log", "audit_log", "deploy", "psp_export", "ledger"],
  "redactions": ["card", "mobile", "token"],
  "known_gaps": ["PSP network trace unavailable"]
}

Evidence فرّار را اولویت دهید

Log/Traceهایی که Retention کوتاه دارند؛
Config، Feature flag، Secret version و Runtime image در زمان رخداد؛
Deploy، Migration، Dependency status و Vendor notice؛
Queue offset، DB state، Cache state و Replica lag؛
فرمان‌های دستی و Decisionهای Incident channel با Timestamp؛
Ticketهای Support و Impact تأییدشده، نه تخمین تکراری؛
نمونهٔ Sanitized Request/Response با Correlation ID.

Evidence safety

شماره کارت، موبایل، Token، Cookie، Secret و دادهٔ هویتی را در Postmortem عمومی کپی نکنید. دسترسی، Retention، Redaction و Audit را متناسب با حساسیت تعریف کنید. فایل Vendor را با Source، زمان دریافت و Hash نگه دارید؛ نبود داده را «Unknown» ثبت کنید، نه اینکه با حدس پر شود.

Timeline را با Fact بسازید، نه داستان

Timeline ستون فقرات RCA است. برای هر ردیف، زمان Event، زمان مشاهده، Source و Confidence را ثبت کنید. Log timestamp ممکن است زمان ثبت باشد نه زمان واقعی وقوع؛ Clock skew و timezone باید معلوم باشند.

سه برچسب اجباری

Observation: «PSP export دو Reference موفق برای Order O-۷۳۱ دارد.»
Inference: «احتمالاً Retry دوم پس از Timeout باعث Reference دوم شده است.»
Unknown: «نمی‌دانیم پاسخ اول در PSP edge یا شبکهٔ بین‌راهی گم شد.»

عبارت «PSP خراب شد» نه Observation دقیق است و نه Mechanism اثبات‌شده.

Timeline نمونه

UTC	Observation	Source	معنا/وضعیت
06:31:02.114	Operation P-۷۳۱ ایجاد شد	Audit log	Fact
06:31:03.408	PSP Reference R-A موفق شد	PSP export	Fact
06:31:08.409	Client timeout ثبت شد؛ Local state=FAILED	Trace/App log	Fact؛ State classification مشکوک
06:31:09.021	Retry با Operation P-۷۳۲/Reference تازه ارسال شد	Audit/Trace	Fact
06:31:10.206	PSP Reference R-B موفق شد	PSP export	Fact
06:31:12.050	Callback C-A پردازش شد	Inbox/Ledger	Fact
06:31:12.330	Callback C-A دوباره پردازش شد	Inbox/Ledger	Fact؛ dedupe غایب
06:46:41.002	Support نخستین گزارش مشتری را ثبت کرد	CRM	Detection gap

زمان ذخیره‌شده UTC و نمایش تهران باید جدا باشد. Timestamp جلالی یا متن فارسی برای ارتباط مفید است، اما Join فنی میان App، PSP و Ledger باید بر Instant و Correlation ID پایدار تکیه کند.

Problem Statement و Impact را قابل آزمون بنویسید

«سیستم پرداخت مشکل داشت» محدوده و Oracle ندارد. Problem statement باید Condition، رفتار مشاهده‌شده، Expected behavior، Scope، Impact، Window و Unknown را روشن کند.

قالب Problem statement

Between [start/end, clock basis], for [cohort/environment/build],
when [condition/event], the system [observed behavior]
instead of [expected invariant], resulting in [verified impact].

Confirmed scope: ...
Potential scope: ...
Excluded by evidence: ...
Unknown: ...

نمونهٔ پرداخت

بین ۰۶:۳۱ تا ۰۶:۴۸ UTC در Build ۲۸۴۱، برای سفارش‌هایی که PSP پس از Commit پاسخشان Timeout شد، Checkout وضعیت را Failed و Retry را با Operation تازه مجاز کرد؛ در سه سفارش از ۲۷ مورد بررسی‌شده دو برداشت موفق تأیید شد، برخلاف Invariant «حداکثر یک Capture موفق برای هر Payment intent». دامنهٔ Vendorهای دیگر هنوز Unknown است.

واژگان علّی را دقیق کنید

بحث «این Root cause است یا نه؟» زمانی بی‌پایان می‌شود که واژگان قرارداد ندارند. یک Taxonomy عملی انتخاب و در Template ثبت کنید.

Trigger

Event آغازگر نزدیک به رخداد است: Deployment، Timeout، Spike، پیام تکراری یا Expired certificate. Trigger ممکن است کاملاً عادی باشد؛ سیستم باید آن را تحمل می‌کرده است.

Causal factor

شرط یا رویدادی است که از طریق Mechanism مشخص در پیامد سهم داشته است. «مرجع تازه در Retry» Causal factor است اگر Timeline و Replay نشان دهد مسیر برداشت دوم را باز کرده است.

Contributing condition

احتمال یا شدت را بیشتر می‌کند اما به‌تنهایی مسیر را کامل نمی‌سازد: فشار Release، مستندات مبهم Vendor، Visibility کم یا Coupling بالا.

Latent/system condition

ضعفی است که پیش از Trigger وجود داشته: State machine بدون Unknown، نبود DB constraint، Review checklist ناقص یا مالک نامعلوم Contract.

Detection، mitigation و recovery gap

این‌ها شاید رخداد را ایجاد نکرده باشند، اما Impact را بزرگ کرده‌اند: Alert فقط HTTP 5xx را دیده، Kill switch وجود نداشته، Runbook قدیمی بوده یا Reconciliation دیر اجرا شده است.

Actionable root/system cause

عامل سطح سیستمیِ دارای Mechanism و Evidence است که با تغییر آن می‌توان مسیر مشابه را به‌طور معنادار دشوارتر یا کم‌اثرتر کرد. یک RCA می‌تواند چند عامل از این نوع داشته باشد؛ واژهٔ Root نباید وانمود کند شبکهٔ علّی فقط یک انتها دارد.

فرضیهٔ علّی را مثل Test case مدیریت کنید

جلسهٔ Brainstorming علت تولید می‌کند، نه حقیقت. هر Candidate باید شناسه، Mechanism، شواهد موافق/مخالف، Alternative و آزمون داشته باشد.

کارت فرضیه

id: H-PAY-02
statement: >
  وقتی PSP پس از Commit پاسخ نداد، طبقه‌بندی Timeout به FAILED
  و ساخت Operation ID تازه، Retry دوم را مانند پرداخت مستقل پذیرفت
  و امکان Capture دوم را ایجاد کرد.
mechanism: ambiguous-outcome → false-failure → new-identity → second-capture
evidence_for:
  - PSP export shows R-A and R-B successful for the same order
  - audit log shows new operation before R-B
evidence_against:
  - no duplicate on 24 timeout-before-commit cases
alternatives:
  - PSP duplicated one request internally
counterfactual:
  - same operation + reconcile-before-retry should yield one capture
test:
  - replay timeout-after-commit against PSP contract stub and sandbox sample
confidence: medium
owner: payments-team
status: open

صورت‌بندی علّی بی‌طرف

When [operating condition], [control/design state]
allowed [mechanism], which contributed to [observable outcome].

Evidence: [for / against / gap]
Counterfactual: if [control], we expect [observable difference].

«توسعه‌دهنده فراموش کرد Idempotency بگذارد» Mechanism، شرایط تصمیم و Control system را حذف می‌کند. صورت بهتر: «وقتی Outcome شبکه مبهم بود، API داخلی State=FAILED و Operation ID تازه را مجاز کرد؛ هیچ Contract test یا constraintی این Transition را رد نکرد.»

Evidence علّی را درجه‌بندی کنید

هم‌زمانی یا وقوع پس از یک Deploy، به‌تنهایی علت را اثبات نمی‌کند. قدرت Evidence را صریح ثبت کنید.

نردبان عملی Evidence

Temporal association: عامل پیش از پیامد دیده شده است؛
Covariation: Cohort دارای عامل، Failure بیشتری از Cohort مقایسه دارد؛
Mechanism trace: Trace/State transition مسیر اثر را نشان می‌دهد؛
Reproduction: همان شرایط Outcome را در محیط کنترل‌شده تولید می‌کند؛
Counterfactual/intervention: با حذف یا کنترل عامل، Outcome تحت همان شرایط رخ نمی‌دهد؛
Field confirmation: پس از تغییر، در فرصت‌های کافی و مشابه، Signal هدف بهتر و Guardrail سالم می‌ماند.

این نردبان رتبه‌بندی دانشگاهی یا اثبات قطعی نیست؛ ابزاری برای نمایش عدم‌قطعیت است. Reproduction آزمایشگاهی ممکن است Fidelity محدود داشته باشد و Field confirmation نیز با تغییرات هم‌زمان Confound شود.

Evidence مخالف را اجباری کنید

برای هر Hypothesis بپرسید چه چیزی آن را رد می‌کند. اگر هیچ مشاهده‌ای نمی‌تواند فرضیه را False کند، احتمالاً ادعا بیش از حد کلی است. کنترل سوگیری شناختی در تست نرم‌افزار برای Anchoring، Hindsight و Premature closure در RCA حیاتی است.

پنج چرا را شاخه‌ای و شواهدمحور اجرا کنید

Five Whys یک ابزار Drill-down است، نه شمارنده و نه اثبات. مستندات ASQ دربارهٔ Five Whys نیز تصریح می‌کند رسیدن به جزئیات ممکن است کمتر یا بیشتر از پنج پرسش بخواهد.

روش صحیح

از Problem statement قابل مشاهده آغاز کنید.
برای هر «چرا»، Evidence source و Owner سؤال را ثبت کنید.
وقتی چند پاسخ هم‌زمان معتبرند، شاخه بسازید؛ یکی را دلخواه انتخاب نکنید.
Trigger، Creation، Escape، Detection و Recovery را در شاخه‌های جدا دنبال کنید.
در «خطای انسانی»، «فرایند ضعیف» یا «آموزش ناکافی» توقف نکنید.
وقتی Cause به Control قابل‌آزمون رسیده و شاخه‌های مهم Evidence دارند، Stop کنید؛ نه صرفاً در Why شمارهٔ پنج.

پنج چرای شاخه‌ای برای پرداخت

Outcome: دو Capture موفق برای یک Payment intent
├─ چرا Capture دوم ایجاد شد؟
│  └─ Retry با Operation/Reference تازه ارسال شد. [audit + PSP export]
│     ├─ چرا تازه؟ Timeout به FAILED قطعی نگاشت شد. [state transition]
│     │  └─ چرا Unknown نبود؟ Contract نتیجه مبهم را مدل نکرده بود. [spec/code]
│     └─ چرا قبل از Retry lookup نشد؟ Reconciliation API/flow وجود نداشت. [design]
├─ چرا Control جلوی آن را نگرفت؟
│  ├─ Unique business constraint روی active capture نبود. [schema]
│  └─ PSP idempotency semantics در Adapter contract نشده بود. [contract gap]
└─ چرا پیش از مشتری کشف نشد؟
   ├─ تست timeout-after-commit در suite نبود. [test inventory]
   └─ Alert فقط HTTP error را دید، نه PSP↔Ledger mismatch. [monitor config]

خطای رایج

پرسش هدایت‌کننده مثل «چرا QA این را نگرفت؟» مسیر را از قبل به یک نقش می‌بندد. سؤال بهتر: «چه Evidence پیش از Release برای این Failure mechanism وجود داشت، چرا کافی نبود و چه Signals دیگری می‌توانستند آن را Detect یا Mitigate کنند؟»

Fishbone فرضیه تولید می‌کند، نه Cause اثبات‌شده

نمودار Ishikawa یا Cause-and-effect برای بازکردن فضای جست‌وجو مفید است. دسته‌ها باید با Software context سازگار شوند؛ الزاماً People/Process/Technology کافی نیست.

دسته‌های پیشنهادی نرم‌افزار

Requirement/Decision؛
Design/Architecture/State؛
Code/Dependency/Configuration؛
Test/Data/Environment/Oracle؛
Deployment/Operation/Capacity؛
Monitoring/Alert/Response؛
Vendor/Network/External contract؛
Organization/Ownership/Incentive/Workload.

بعد از Brainstorm چه کنیم؟

هر استخوان فقط Candidate است. Duplicateها را ادغام، ادعاهای بدون Mechanism را بازنویسی، Evidence جمع و Alternativeها را آزمایش کنید. رأی اکثریت یا حضور یک علت روی نمودار، آن را واقعی نمی‌کند.

Timeline، Change analysis، Barrier analysis و Fault tree

ابزار را بر اساس سؤال انتخاب کنید؛ «بهترین تکنیک RCA» مستقل از مسئله وجود ندارد.

ابزار	بهترین سؤال	خروجی	محدودیت
Timeline	چه رخ داد و کدام تصمیم چه زمانی بود؟	توالی Fact/Unknown	به‌تنهایی علت را ثابت نمی‌کند
Five Whys	این مسیر چگونه از علامت به Control رسید؟	زنجیره/شاخهٔ پرسش	Anchoring و تک‌علتی‌شدن
Fishbone	چه خانواده‌هایی از Hypothesis جا مانده‌اند؟	فضای Candidate	فهرست، Evidence نیست
Change analysis	چه چیز میان Cohort سالم و معیوب تغییر کرد؟	Deltaهای قابل آزمون	تغییر هم‌زمان ≠ Cause
Barrier analysis	چه Controlهایی باید Prevent/Detect/Mitigate می‌کردند؟	Barrier gap/degradation	ممکن است Trigger را کم‌رنگ کند
Fault tree	چه AND/OR ترکیبی Top event را ممکن می‌کند؟	منطق و Minimal cut set	به Model/Evidence خوب وابسته است
Pareto	کدام Cluster بیشترین حجم/Impact را دارد؟	اولویت Investigation	قانون ۸۰/۲۰ و Cause را اثبات نمی‌کند

Pareto را قانون طبیعت ندانید

ممکن است ۲۰٪ Categoryها ۸۰٪ Impact را بسازند، ممکن هم هست نسازند. Category باید Mutually meaningful، داده باید Canonical و Impact باید وزن‌دار باشد. Pareto می‌گوید از کجا شروع کنیم؛ نمی‌گوید چرا رخداد اتفاق افتاد.

Barrier map پرداخت

Prevent:
  stable business operation identity      → absent
  explicit UNKNOWN state                  → absent
  uniqueness/transition constraint        → absent

Detect:
  PSP↔Ledger near-real-time reconciliation → delayed
  duplicate-capture invariant alert        → absent

Mitigate:
  retry kill switch                        → present, manual
  refund workflow                          → present, slow

Recover/Learn:
  transaction replay fixture               → absent
  incident trigger and action owner         → partial

در «Human error» توقف نکنید

OSHA در راهنمای Incident Investigation هشدار می‌دهد نتیجه‌گیری‌هایی مانند Carelessness یا رعایت‌نشدن Procedure، عوامل زیربنایی و تغییرات سیستمی لازم را پنهان می‌کنند. این اصل از ایمنی صنعتی آمده، اما پرسش سیستمی آن برای نرم‌افزار نیز مفید است.

پرسش‌های جایگزین

فرد در لحظه چه اطلاعات و Constraintsی داشت؟
آیا Safe action آسان‌تر از Unsafe action بود؟
چه Validation خودکاری می‌توانست حالت خطرناک را ناممکن یا آشکار کند؟
آیا Procedure قابل اجرا، به‌روز، تمرین‌شده و در دسترس بود؟
آیا Deadline، Queue، Alert fatigue یا Incentive تصمیم را شکل داد؟
چرا Review/Test/Deploy/Monitorهای چندلایه اثر را متوقف نکردند؟

Accountability واقعی

زبان سیستمی به معنی پاک‌کردن Decision log یا Owner نیست. ثبت می‌کنیم چه کسی در چه نقش و با چه داده‌ای تصمیم گرفت، اما Action را به «آدم دقیق‌تری باش» تقلیل نمی‌دهیم. مسئولیت‌پذیری سالم یعنی Owner اقدام، موعد، Evidence اثر و Escalation روشن باشد.

از علت به اقدام: RCA بدون Action ناقص است

منبع RCA² مؤسسه IHI در حوزهٔ ایمنی بیمار، با افزودن Actions به نام روش تأکید می‌کند که هدف نهایی پیشگیری از آسیب است. حوزهٔ سلامت با نرم‌افزار یکسان نیست، اما اصل انتقال‌پذیر مهم است: اقدام‌های سیستمی که اتکای کمتری به حافظه دارند، معمولاً از آموزش/هشدار تنها قوی‌ترند.

انواع اقدام را جدا کنید

Correction: رفع نمونهٔ فعلی؛
Corrective: بستن همان مسیر علّی؛
Preventive/systemic: یافتن و بستن مسیر مشابه در Scopeهای دیگر؛
Detection: کوتاه‌کردن زمان کشف؛
Mitigation/recovery: کم‌کردن Impact و زمان بازگشت؛
Learning: حفظ Knowledge و به‌روزرسانی Test/Risk/Runbook.

نردبان قدرت اقدام

قدرت نسبی	مثال نرم‌افزاری	ریسک/ملاحظه
قوی‌تر	حذف State خطرناک؛ DB constraint؛ forcing function؛ idempotent state machine؛ کاهش Coupling	پیچیدگی Migration و Failure mode تازه
قوی/میانی	Validation خودکار؛ Contract test؛ reconciliation؛ circuit/limit؛ independent alert	False positive، هزینه و Coverage gap
میانی	Checklist در Workflow؛ peer approval هدفمند؛ Runbook تمرین‌شده؛ ظرفیت/On-call بهتر	هنوز به اجرا و نگهداری انسان وابسته
ضعیف‌تر	ایمیل، Warning، Policy، «دقت بیشتر»، آموزش یک‌باره، double-check دستی	Decay، Alert fatigue و دورزدن

ضعیف‌تر یعنی بی‌ارزش نیست؛ Training برای Skill gap لازم است، اما اگر UI یک Operation خطرناک را آزادانه مجاز می‌کند، آموزش تنها Control کافی نیست.

قرارداد Action item

action_id: A-PAY-04
causal_links: [H-PAY-02, H-PAY-05]
type: corrective+detection
change: >
  introduce UNKNOWN state; reuse immutable operation_id;
  reconcile before any retry; alert duplicate-capture invariant
scope: all PSP adapters
owner: payments-platform
approver: financial-risk-owner
due: 2026-09-05
rollout: shadow → 5% → 25% → 100%
rollback: disable new adapter path, preserve reconciliation
implementation_evidence: code + migration + config hash
effectiveness_test: timeout-after-commit replay + sandbox sample
success_oracle: one capture and one ledger effect per payment intent
guardrails: false-block rate, checkout completion, reconcile latency
residual_risk: PSP without lookup contract remains partially controlled
review_at: 2026-10-05

آزمایش قطعی: Counterfactual replay پرداخت

برای نشان‌دادن تفاوت «Fix ظاهری» و کنترل مسیر علّی، یک Event sequence ساختگی را Replay می‌کنیم: PSP درخواست اول را Commit می‌کند ولی پاسخ Timeout می‌شود؛ برنامه Retry می‌کند؛ Callback اول نیز دوبار تحویل می‌شود. چهار پیکربندی با همان توالی مقایسه می‌شوند.

کد قابل‌بازتولید

function replay({ reconcileBeforeRetry, callbackInboxDedupe }) {
  const pspCaptures = [];
  const callbackInbox = new Set();
  const ledger = [];

  const capture = reference => pspCaptures.push(reference);
  const onCallback = event => {
    if (callbackInboxDedupe && callbackInbox.has(event.id)) return;
    callbackInbox.add(event.id);
    ledger.push({ event: event.id, reference: event.reference });
  };

  capture('R-A');                         // PSP committed
  const clientObserved = 'TIMEOUT';       // response lost after commit

  if (clientObserved === 'TIMEOUT') {
    const found = reconcileBeforeRetry && pspCaptures.includes('R-A');
    if (!found) capture('R-B');            // unsafe new attempt
  }

  onCallback({ id: 'C-A', reference: 'R-A' });
  onCallback({ id: 'C-A', reference: 'R-A' }); // duplicate delivery
  if (pspCaptures.includes('R-B'))
    onCallback({ id: 'C-B', reference: 'R-B' });

  return {
    captures: pspCaptures.length,
    duplicateCaptures: Math.max(0, pspCaptures.length - 1),
    ledgerEffects: ledger.length,
    duplicateLedgerEffects: Math.max(0, ledger.length - 1),
  };
}

خروجی Replay

پیکربندی	Capture	Capture تکراری	Ledger effect	Ledger effect تکراری
Baseline	۲	۱	۳	۲
فقط Reconcile-before-retry	۱	۰	۲	۱
فقط Callback inbox dedupe	۲	۱	۲	۱
هر دو کنترل	۱	۰	۱	۰

Baseline دو Capture و سه اثر Ledger می‌سازد. Reconciliation مسیر Charge دوم را می‌بندد اما Duplicate callback هنوز یک اثر اضافه می‌سازد. Inbox dedupe تحویل تکراری یک Event را مهار می‌کند، ولی دو Capture مستقل را یکی نمی‌پندارد. فقط ترکیب دو Control در این Event sequence هر دو Invariant را نگه می‌دارد.

این آزمایش چه چیزی را اثبات نمی‌کند؟

مدل ساختگی و Deterministic است؛ رفتار PSP واقعی، Race، Crash، Out-of-order callback، Refund و Concurrency را کامل شبیه‌سازی نمی‌کند. نتیجه فقط Mechanism و نیاز به دفاع چندلایه را نشان می‌دهد؛ علت سازمانی، نرخ تکرار Production یا اثر همهٔ Vendorها را ثابت نمی‌کند. پیاده‌سازی واقعی باید با Contract رسمی PSP، Stub، Sandbox محدود و Reconciliation مستقل آزموده شود.

مثال کامل RCA برای Checkout ایرانی

Scope و Invariant

Scope: Checkout → Payment intent → PSP adapter → Callback inbox → Ledger
Invariant 1: برای هر Payment intent حداکثر یک Capture موفق مجاز است.
Invariant 2: هر Callback event حداکثر یک اثر Ledger دارد.
Invariant 3: مبلغ Canonical به IRR است؛ تومان فقط نمایش است.
Invariant 4: Outcome مبهم باید UNKNOWN باشد، نه FAILED قطعی.
Invariant 5: Reconciliation باید PSP، Order و Ledger را همگرا کند.

Cause portfolio

Trigger: Timeout پس از Commit در مسیر پاسخ؛
Creation factor: نگاشت Timeout به FAILED و Operation تازه در Retry؛
Control gap: نبود Reconcile-before-retry و constraint حالت؛
Secondary path: Callback inbox فاقد uniqueness بر Event ID؛
Escape factor: تست‌ها فقط Timeout-before-commit را مدل کرده بودند؛
Detection gap: Alert بر HTTP error بود، نه Invariant مالی؛
Impact amplifier: Runbook بازپرداخت و مالک Risk مبهم بود؛
Unknown: Contract lookup همهٔ PSPها یکسان نیست.

Action portfolio

State machine نتیجهٔ Payment را Pending/Unknown/Failed/Success با Transitionهای معتبر مدل می‌کند.
Payment operation identity در Retry ثابت و ارتباط Order/Attempt/PSP reference غیرقابل‌ابهام می‌شود.
پیش از تلاش تازه، Outcome از PSP/Callback/Ledger Reconcile می‌شود؛ برای Vendor بدون lookup، Risk/flow جدا تعریف می‌شود.
Callback inbox روی Vendor+Event ID یا کلید قراردادشده Idempotent می‌شود.
DB constraint و Transaction boundary جلوی دو اثر کسب‌وکاری را می‌گیرد؛ فقط UI check کافی نیست.
تست timeout-before/after-commit، duplicate/late/out-of-order callback و crash-between-write-and-ack افزوده می‌شود.
Alert بر Capture-per-intent و PSP↔Ledger mismatch همراه Runbook/Owner ساخته می‌شود.
Adapterهای دیگر با همان Failure mechanism، نه صرفاً همان خط کد، Audit می‌شوند.

جزئیات ایران که RCA را منحرف می‌کند

ریال Canonical و تومان نمایشی را مخلوط نکنید؛ اختلاف ۱۰× ممکن است Cause مستقل باشد.
اعداد فارسی/عربی/لاتین و Unicode normalization را در Correlation و Data join کنترل کنید.
زمان PSP، سرور و CRM را به UTC همگرا و Asia/Tehran را فقط نمایش دهید.
قطعی/کندی شبکه و محدودیت دسترسی Vendor را Fact کنید؛ «اینترنت ایران» Cause کافی نیست.
شماره موبایل، کارت، Token و متن پیامک را در Artifact عمومی Mask کنید.
اگر Sandbox از Production fidelity ندارد، محدودیت را در Confidence و Residual risk ثبت کنید.

برای آزمودن Timeout، Retry، Idempotency و Recovery با Safety gate، راهنمای تست تاب‌آوری سیستم مکمل مستقیم این RCA است.

Verification: پیاده‌سازی اقدام با اثربخشی آن فرق دارد

بسته‌شدن Ticket فقط نشان می‌دهد کاری انجام شده؛ نشان نمی‌دهد مسیر Failure بسته شده است.

چهار لایهٔ راستی‌آزمایی

Implementation: تغییر با Build/Config/Migration identity واقعاً Deploy شده است؟
Mechanism: Replay یا Fault injection نشان می‌دهد Control دقیقاً مسیر هدف را می‌بندد؟
Guardrail: Checkout completion، latency، false block یا عملیات دستی بدتر نشده است؟
Sustainability/field: در فرصت‌های کافی و مشابه، Recurrence/Impact/Detection signal مطابق انتظار است؟

عدم‌تکرار فوری، اثبات نیست

اگر Failure ماهی یک بار فرصت وقوع دارد، «هفت روز بدون Incident» Evidence ضعیفی است. Opportunity denominator بسازید: تعداد Timeout-after-commit، تعداد Callback duplicate، تعداد Release با همان مسیر یا تعداد تراکنش واجد شرایط. صفر رخداد بدون فرصت، معنای محدودی دارد.

اگر بازتولید ممکن نیست

Evidence را جعل نکنید. از State/model test، Contract stub، Trace replay، property/invariant test، Canary و Monitoring استفاده و Fidelity gap را بنویسید. وضعیت Action می‌تواند Implemented-but-effectiveness-partial باشد؛ Closure باید Residual risk و مرجع پذیرش داشته باشد.

تعریف Done برای RCA

Report منتشرشده پایان کار نیست. Done باید Gate داشته باشد.

RCA Done when:
  scope/impact/timeline reviewed
  facts, inferences and unknowns separated
  major alternatives considered
  causal statements have evidence and mechanism
  trigger/creation/escape/detection/recovery factors distinguished
  every material causal path has mitigate/accept rationale
  actions have owner, due, rollout, oracle and guardrail
  critical implementation evidence exists
  effectiveness verified or explicitly pending with review date
  residual risk accepted by authorized owner
  sanitized learning shared to intended audience

AWS در راهنمای Post-incident analysis بر دادهٔ پشتیبان علت، مالک روشن، اقدام اصلاحی، بررسی اینکه چرا تست مسئله را نیافته و مخزن Lessons learned تأکید می‌کند.

قالب آمادهٔ RCA/Postmortem نرم‌افزار

# Identity
Case ID / owner / facilitator / reviewers / classification / access

# Executive summary
What happened / verified impact / current state / residual risk

# Scope and invariants
Systems, cohorts, builds, configs, clocks, expected properties

# Trigger criteria
Why this depth of review was selected

# Timeline
Event time / observed time / fact / source / confidence / decision

# Impact
Confirmed / potential / excluded / unknown; user, finance, data, security

# Detection and response
How detected / contain / mitigate / recover / communicate

# Causal analysis
Trigger / causal factors / contributing conditions / control gaps
Detection / mitigation / recovery gaps / alternative hypotheses
Evidence for / evidence against / unknowns / counterfactual tests

# What went well / poorly / where we got lucky
Mechanism and evidence, without personal judgment

# Actions
Cause link / type / strength / owner / due / rollout / rollback
Success oracle / verification / guardrail / residual risk / review date

# Review and learning
Approvals / redaction / sharing scope / taxonomy / related cases

Google Cloud در راهنمای Conduct thorough postmortems چرخهٔ Capture facts→Identify/analyze causes→Plan→Execute را پیشنهاد می‌کند و هشدار می‌دهد راه‌حل بیش‌ازحد پیچیده برای رخداد کم‌احتمال می‌تواند ناپایداری تازه بسازد.

جلسهٔ RCA را چگونه تسهیل کنیم؟

پیش از جلسه

Incident stabilized و Evidence Pack آماده باشد.
Problem statement، Scope، Timeline draft و Unknownها از قبل توزیع شوند.
افراد نزدیک به Event و صاحبان سیستم/Impact دعوت شوند؛ جلسه را بیش‌ازحد بزرگ نکنید.
Facilitator بی‌طرف و Recorder مشخص باشد.
Security/Privacy access و Redaction پیش از نمایش Artifact کنترل شود.

در جلسه

هدف و قواعد Blameless/accountable را مرور کنید.
Impact و Invariant را پیش از Cause تأیید کنید.
Timeline را Event به Event و Source به Source بازبینی کنید.
Silent-first، هر نفر Candidate/Unknown خود را مستقل بنویسد تا Anchoring کم شود.
Hypothesisها را به Creation/Escape/Detection/Recovery تقسیم کنید.
برای هر مسیر Evidence موافق/مخالف و Next test تعیین کنید.
اقدام را فقط پس از توافق نسبی روی Mechanism طراحی کنید.
موارد حل‌نشده را با Owner و موعد، نه با اجماع مصنوعی، خارج کنید.

پس از جلسه

Draft باید توسط فرد فنی، نمایندهٔ Impact و Owner اقدام Review شود. Commentهای باز بسته، نسخه منتشر، Actionها وارد سیستم کار و Critical actionهای عقب‌افتاده Escalate شوند. Postmortem بدون پیگیری، Knowledge base تزئینی است.

متریک‌های سالم برای فرایند RCA

تعداد RCA یا تعداد Action، Outcome کیفیت نیست. Metric باید سؤال و Denominator داشته باشد.

کیفیت Analysis

درصد RCAهای دارای Timeline source-linked و تفکیک Fact/Hypothesis؛
درصد Causeهای مادی با Evidence مخالف/Alternative و Verification plan؛
درصد Actionها که به Causal statement مشخص متصل‌اند؛
درصد Reportهای Reviewشده پیش از Publication.

کیفیت Action

Action aging و درصد Critical action overdue؛
نسبت اقدام‌های سیستمی/خودکار به Training/Policy-only، با تفسیر زمینه‌ای؛
Implementation-verified و Effectiveness-verified به‌صورت جدا؛
Lead time از RCA approval تا Control فعال؛
Residual riskهای پذیرفته‌شده و منقضی‌شده.

Outcome و Guardrail

Recurrence per comparable opportunity برای Failure cluster؛
Impact severity/exposure و Detection time در فرصت‌های مشابه؛
درصد مشابهت‌هایی که Action systemic پوشش داده است؛
Regression/availability/latency/cost پس از Control؛
نرخ گزارش Near miss و کیفیت Psychological safety survey، بدون Target اجباری برای افزایش/کاهش Incident count.

کاهش Incident count ممکن است به‌علت کاهش Traffic یا گزارش‌نکردن باشد؛ افزایش آن نیز شاید Detection بهتر باشد. برای طراحی Numerator/Denominator و ضدبازی، راهنمای متریک‌های تست نرم‌افزار را به کار بگیرید.

از یک RCA به یادگیری سازمانی

ارزش واقعی زمانی ایجاد می‌شود که Patternها از مرز یک Ticket عبور کنند.

Taxonomy برای Trend، نه رتبه‌بندی افراد

Causeها را با واژگان چندبرچسبی مانند State/identity، Dependency contract، Data integrity، Change/config، Test/Oracle gap، Detection، Capacity، Ownership و Recovery ثبت کنید. یک Case می‌تواند چند Tag داشته باشد. «Developer error» یا «QA miss» Category قابل‌آموزش نیست.

Action را به سیستم‌های دیگر تعمیم دهید

اگر Failure mechanism «Outcome مبهم + Retry با Identity تازه» است، فقط همان Endpoint را Patch نکنید؛ Refund، Wallet top-up، Shipment booking، SMS billing و Job consumers را برای همان Pattern جست‌وجو کنید. Scope expansion باید Risk-based و دارای Owner باشد، نه بازنویسی بی‌پایان همه‌چیز.

حلقهٔ بستهٔ بهبود

Incident/Defect/Near miss
→ Evidence-led RCA
→ Action portfolio
→ Pilot/rollout
→ Mechanism + field verification
→ Standard/Test/Risk/Runbook update
→ Trend review
→ Adapt / scale / rollback / accept residual risk

برای تبدیل یافته‌ها به Experiment و Standard پایدار، سیستم بهبود مستمر QA مسیر کامل‌تری ارائه می‌دهد.

ابزار و هوش مصنوعی در RCA

ابزار می‌تواند جمع‌آوری Timeline، Join بر Correlation ID، Link کردن Deploy، خوشه‌بندی Failure signature، پیگیری Action و یادآوری Due date را آسان کند. اما Tool نمی‌تواند Cause معتبر را از Log ناقص «استخراج» کند.

کارهای مناسب برای Automation/AI

نرمال‌سازی Timestamp و پیشنهاد Timeline با Citation به Source؛
خوشه‌بندی Incidentهای مشابه برای Review انسانی؛
پیداکردن Actionهای Overdue و Scopeهای مشابه؛
Redaction پیشنهادی PII/Secret با بازبینی؛
تولید پرسش یا Alternative hypothesis، نه اعلام Root cause.

Guardrailهای AI

Log، کد، مشتری و Security evidence را بدون مجوز به سرویس بیرونی نفرستید.
هر ادعا باید Citation به Artifact و Confidence داشته باشد.
Hallucinated timestamp، Actor یا Action قابل پذیرش نیست.
مدل نباید Owner، تقصیر یا Risk acceptance را تعیین کند.
نمونه‌ای از موارد خوشه‌بندی‌نشده برای False negative بازبینی شود.
Prompt/model/version و تغییر انسانی در Audit باقی بماند.

برنامهٔ ۳۰روزه برای راه‌اندازی RCA

روزهای ۱ تا ۵: Policy و Trigger

Learning note/Mini/Full RCA و Trigger هرکدام را تعریف کنید.
نقش Facilitator، Case owner، Action owner و Risk owner را مشخص کنید.
Access/Redaction/Retention و Security escalation را تصویب کنید.

روزهای ۶ تا ۱۰: Template و Evidence

قالب Identity/Impact/Timeline/Hypothesis/Action/Verification را بسازید.
Correlation ID و Deploy/Config identity را در سامانه‌ها Audit کنید.
یک Runbook حفظ Evidence فرّار بنویسید.

روزهای ۱۱ تا ۱۵: Pilot

یک Incident بسته‌شدهٔ متوسط و Sanitized را انتخاب کنید.
Timeline را مستقل بسازید و جلسه را با Facilitator اجرا کنید.
حداقل دو Alternative hypothesis و Evidence مخالف ثبت کنید.

روزهای ۱۶ تا ۲۰: Action و Verification

هر Action را به Cause link و Action hierarchy وصل کنید.
یک Replay/Fault injection با Success oracle و Guardrail اجرا کنید.
Implemented و Effective را دو Status جدا در Tracker قرار دهید.

روزهای ۲۱ تا ۲۵: Review و Sharing

Technical، Impact و Privacy review را اجرا کنید.
نسخهٔ Sanitized را در Repository قابل جست‌وجو منتشر کنید.
Critical overdue action و Risk acceptance expiry را Alert کنید.

روزهای ۲۶ تا ۳۰: Calibration

زمان/Toil، کیفیت Evidence، Action strength و Feedback شرکت‌کنندگان را ببینید.
Triggerهای خیلی حساس یا خیلی کم‌حساس را اصلاح کنید.
Taxonomy و Template را Version کنید.
تصمیم Adopt/Adapt/Continue/Stop و بازبینی ۶۰روزه ثبت شود.

نمونهٔ Before/After معتبر

این قالب، دادهٔ واقعی سایت نیست و نباید به‌عنوان Benchmark استفاده شود:

Scope: payment incidents with ambiguous PSP outcome
Before window: 8 comparable events / 14 weeks
After window: 9 comparable opportunities / 16 weeks

Change:
  UNKNOWN state + reconcile-before-retry + callback inbox uniqueness

Before:
  duplicate capture = 3/8 opportunities
  median detection = 19 min
  actionable RCA actions effectiveness-verified = 1/6

After:
  duplicate capture = 0/9 opportunities
  median detection = 4 min
  actionable RCA actions effectiveness-verified = 5/6

Guardrails:
  checkout completion unchanged within stated uncertainty
  p95 confirmation latency +6s during reconciliation

Limits:
  small samples; PSP mix changed; no claim of universal causality;
  continue monitoring through 40 opportunities.

کاهش صفر تا سه با Sample کوچک قطعیت نمی‌سازد. Context، Opportunity، Confounder، Latency cost و بازهٔ بازبینی باید همراه نتیجه منتشر شوند.

Anti-patternهای تحلیل علت ریشه‌ای

یک Root cause برای سیستم پیچیده: شبکهٔ علّی به داستان خطی تبدیل می‌شود.
شروع از مقصر: Evidence پنهان و گزارش‌دهی کمتر می‌شود.
پنج Why دقیقاً: تحلیل زود یا دیر و بدون معیار Stop تمام می‌شود.
Fishbone به‌عنوان نتیجه: Candidateها بدون Verification Cause اعلام می‌شوند.
Deploy قبلی=Cause: Temporal correlation جای Mechanism می‌نشیند.
Pareto ۸۰/۲۰ قطعی: نسبت فرضی جای داده و علت را می‌گیرد.
Human error: ابزار، فشار، اطلاعات و Guardrailها حذف می‌شوند.
Training-only: Hazard در طراحی باقی می‌ماند و فقط حافظه مسئول می‌شود.
RCA پیش از مهار: Attention از کاربر و Recovery دور می‌شود.
بستن با انتشار Report: Actionها بدون Owner/Verification فراموش می‌شوند.
صفر Recurrence بدون Opportunity: نبود فرصت با اثر اقدام اشتباه می‌شود.
RCA برای هر Bug: Toil زیاد و تحلیل‌های مهم سطحی می‌شوند.
مخزن محرمانه و غیرقابل جست‌وجو برای همه: یا دانش حبس می‌شود یا PII نشت می‌کند؛ Sharing باید لایه‌بندی شود.
AI به‌عنوان داور علت: روایت بی‌منبع با لحن مطمئن ساخته می‌شود.

چک‌لیست کیفیت RCA

آیا Incident پیش از تحلیل تثبیت شده است؟
آیا Trigger عمق RCA از قبل تعریف شده بود؟
آیا Scope، Build، Config، Environment و Clock روشن است؟
آیا Impact تأییدشده از Potential/Unknown جداست؟
آیا PII/Secret در Evidence و Report محافظت شده است؟
آیا Timeline به Source لینک و Clock skew بررسی شده است؟
آیا Observation، Inference و Unknown برچسب دارند؟
آیا Trigger با Cause اشتباه نشده است؟
آیا Creation/Escape/Detection/Mitigation/Recovery جدا تحلیل شده‌اند؟
آیا چند Alternative hypothesis بررسی شده است؟
آیا Evidence موافق و مخالف هر Cause مهم ثبت شده است؟
آیا Human error به System factors شکافته شده است؟
آیا Five Whys شاخه دارد و با عدد پنج متوقف نشده است؟
آیا Fishbone فقط Candidate generator تلقی شده است؟
آیا Counterfactual یا Reproduction plan وجود دارد؟
آیا هر Action به Causal link مشخص متصل است؟
آیا حداقل یک Control سیستمی متناسب بررسی شده است؟
آیا Owner، Due، Rollout، Rollback و Risk owner روشن‌اند؟
آیا Success oracle و Guardrail پیش از اجرا تعریف شده‌اند؟
آیا Implementation و Effectiveness جدا Verify می‌شوند؟
آیا Field outcome بر Opportunity denominator تکیه دارد؟
آیا Residual risk و Unknown منقضی/بازبینی می‌شود؟
آیا Learning به Test، Risk model، Runbook یا Standard برگشته است؟

پرسش‌های متداول تحلیل علت ریشه‌ای

۱. تحلیل علت ریشه‌ای یا RCA چیست؟

RCA فرایندی ساختاریافته برای بازسازی یک مشکل یا Incident، شناسایی و آزمودن عوامل علّی و طراحی اقدام‌هایی است که احتمال یا Impact تکرار را کاهش دهند. خروجی معتبر، Cause ادعایی را به Evidence، Mechanism، اقدام و Verification متصل می‌کند.

۲. آیا هر باگ به RCA نیاز دارد؟

خیر. Triggerها را بر اساس Impact، تکرار، Near miss، داده/مالی/امنیت، Detection failure و فرصت یادگیری تعریف کنید. باگ کم‌اثر با Mechanism روشن شاید فقط Learning note بخواهد؛ رخداد چندسیستمی یا مالی Full RCA/Postmortem.

۳. تفاوت ۵ Whys و Fishbone چیست؟

Five Whys یک مسیر را با پرسش‌های متوالی عمیق می‌کند و باید در علت‌های متعدد شاخه بسازد؛ Fishbone خانواده‌های Candidate cause را گسترده می‌کند. هیچ‌کدام بدون Evidence، Alternative و Verification علت را اثبات نمی‌کند.

۴. Blameless RCA یعنی هیچ‌کس پاسخ‌گو نیست؟

خیر. Blameless از تحقیر و تقلیل Cause به فرد جلوگیری می‌کند تا Factها آشکار شوند؛ در عین حال Role، Decision، Action owner، Due date، Review و Risk acceptance دقیق ثبت می‌شوند. ایمنی روانی و مسئولیت‌پذیری مکمل یکدیگرند.

۵. چگونه بفهمیم اقدام RCA مؤثر بوده است؟

اول Deploy/پیاده‌سازی را تأیید، سپس همان Failure mechanism را با Replay، Fault injection یا Test مناسب فعال و Oracle/Guardrail را بررسی کنید. بعد در فرصت‌های واقعی و قابل مقایسه، Recurrence، Impact و Detection را با Denominator بسنجید و Confounder/Residual risk را گزارش کنید.

جمع‌بندی

RCA خوب از «چه کسی اشتباه کرد؟» به «چه شرایط، تصمیم‌ها و کنترل‌هایی این پیامد را ممکن کردند و کدام تغییر آن مسیر را می‌بندد؟» حرکت می‌کند. برای این کار، مهار را از یادگیری جدا، Evidence را پیش از روایت حفظ، Timeline را بر Clock واحد بنا، فرضیه‌ها را با شواهد موافق و مخالف آزمون و چند مسیر Creation/Escape/Detection/Recovery را نگه دارید.

مهم‌تر از نام تکنیک، بسته‌شدن حلقه است: Cause بدون Action فقط توضیح است؛ Action بدون Causal link حدس است؛ و Action بسته‌شده بدون Effectiveness verification فقط فعالیت ثبت‌شده است. وقتی این سه اتصال برقرار شوند، تحلیل علت ریشه‌ای از جلسهٔ پس از بحران به یک سامانهٔ یادگیری و پیشگیری تبدیل می‌شود.

مدیریت باگ

تحلیل علت ریشه‌ای؛ راهنمای RCA از شواهد تا اقدام