تجزیه و تحلیل علت ریشه

1) RCA چیست و چرا لازم است

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

2) اصول (فرهنگ عادلانه)

بدون اتهام. ما مردم را مجازات نمی کنیم، بلکه اقدامات خطرناک را مجازات می کنیم.
واقعيت داره. فقط داده ها و مصنوعات قابل اثبات است.
چشم انداز E2E از مشتری به عقب به ارائه دهندگان.
تست پذیری فرضیه ها هر بیانیه - با آزمون/آزمایش.
بسته شدن CAPA اقدامات اصلاحی و پیشگیرانه با صاحبان و مهلت ها.

3) آثار هنری ورودی و آماده سازی

خط زمان UTC: تشخیص T0 → T + اقدامات → بازیابی T +.
داده های قابل مشاهده: گزارش ها، معیارها (از جمله کوهورت)، مسیرهای پیاده روی، مصنوعی، صفحه وضعیت.
تغییرات: انتشار, پرچم ویژگی, پیکربندی, رویدادهای ارائه دهنده.
محیط زیست: نسخه ها، هش مصنوعی، SBOM، برچسب های زیرساخت.
پایه حادثه: شرح تاثیر (SLO/SLA، مشتریان، گردش مالی)، تصمیمات گرفته شده، راه حل.
زنجیره نگهداری: چه کسی و چه زمانی جمع آوری/اصلاح شواهد (مهم برای انطباق).

4) روش های RCA: زمانی که

1. 5 چرا - به سرعت زنجیره علت و معلول را برای مشکلات باریک کشف کنید. ریسک: «جمع کردن» یک سیستم پیچیده به یک خط.
2. Fishbone - عوامل را به عنوان افراد/فرآیند/پلت فرم/سیاست/شریک/محصول طبقه بندی کنید. در ابتدا مفید است.
3. تجزیه و تحلیل درخت خطا (FTA) - کسر از رویداد به علت مجموعه (AND/OR). برای زیرساخت ها و شکست درختان.

4. Causal Graph/Event Chain - نمودار وابستگی با احتمالات و وزن مشارکت. مناسب برای میکروسرویس ها و ارائه دهندگان خارجی

5. FMEA (تجزیه و تحلیل حالت ها و اثرات شکست) - پیشگیری: حالت های شکست، شدت (S)، فرکانس (O)، تشخیص (D)، RPN = S × O × D.
6. تجزیه و تحلیل تغییر - مقایسه «همانطور که بود/همانطور که شد» (diff config، schema، versions).
7. بررسی عوامل انسانی - زمینه تصمیمات مردم (خستگی هشدار، کتاب های بد، بیش از حد).

ترکیب توصیه شده: استخوان ماهی → تجزیه و تحلیل تغییر → نمودار علیت/FTA → 5 چرا توسط شاخه های کلیدی.

5) فرآیند گام به گام RCA

1. آغاز: تعیین مالک RCA، تعیین مهلت برای صدور گزارش (به عنوان مثال، 5 روز کاری)، جمع آوری یک تیم (IC، TL، Scribe، نمایندگان ارائه دهنده).
2. جمع آوری حقایق: جدول زمانی، نمودارها، نسخه ها، سیاههها، مصنوعات ؛ نسخه های ثابت و کنترل مقدار.
3. تأثیر نقشه: کدام SLI/SLO ها تحت تأثیر قرار گرفتند، کدام گروه ها (کشورها، ارائه دهندگان، VIP ها).
4. ساخت فرضیه: اولیه، جایگزین ؛ بررسی کنید که در حال حاضر قابل بررسی است.
5. فرضیه های تست: پخش در مرحله/شبیه سازی/قناری، تجزیه و تحلیل ردیابی، تزریق خطا.
6. ریشه و علل مشارکت را تعیین کنید: تکنولوژیکی، فرآیندی، سازمانی.
7. فرم CAPA: اصلاحی (صحیح) و پیشگیرانه (جلوگیری) ؛ معیارهای موفقیت و جدول زمانی.
8. آشتی دادن و انتشار گزارش: پایگاه دانش داخلی +، در صورت لزوم، نسخه خارجی برای مشتریان/تنظیم کننده.

9. بررسی اثر: بازرسی پس از 14/30 روز ؛ بسته شدن فعالیت ها

6) آنچه به عنوان «علت ریشه ای» محسوب می شود

• تست های ضعیف/پرچم های ویژگی، محدودیت ها/هشدارهای گمشده، مستندات مبهم، پیش فرض های نادرست، معماری شکننده.
• اغلب این ترکیبی از عوامل (پیکربندی × عدم وجود دروازه × ارائه دهنده × بار) است.

7) CAPA: اقدامات اصلاحی و پیشگیرانه

• اصلاح کد/پیکربندی، بازگشت الگو، تغییر محدودیت/زمان بندی، اضافه کردن شاخص ها، replica/sharding، توزیع مجدد ترافیک، به روز رسانی گواهی.

• تست ها (قرارداد، موارد هرج و مرج)، هشدارها (میزان سوختگی، حد نصاب مصنوعی)، سیاست انتشار (قناری/آبی-سبز)، GitOps برای پیکربندی ها، آموزش/چک لیست ها، تکثیر ارائه دهنده، تمرینات DR.

هر اقدام: مالک، مهلت، اثر مورد انتظار، متریک تأیید (به عنوان مثال، کاهش نرخ تغییر شکست توسط X٪، بدون تکرار 90 روز).

8) تایید فرضیه ها و اثرات

آزمایش: تزریق خطا/هرج و مرج، ترافیک سایه، پیکربندی A/B، بار با پروفایل های واقعی.
معیارهای موفقیت: بهبود SLO، تثبیت کننده p95/p99، بدون افزایش خطا، کاهش MTTR، روند سوختگی و صفر برای 30 روز.
نقاط کنترل: D + 7، D + 30، D + 90 - تجدید نظر در اجرای CAPA و تاثیر.

9) قالب گزارش RCA (داخلی)

1. خلاصه: چه زمانی اتفاق افتاد، چه کسی تحت تاثیر قرار گرفت.
2. تاثیر: SLI/SLO، کاربران، مناطق، گردش مالی/مجازات (در صورت وجود).
3. خط زمانی (UTC): رویدادهای اصلی (هشدارها، تصمیمات، نسخه ها، رفع).
4. مشاهدات و داده ها: نمودار ها، سیاهههای مربوط، آثار، پیکربندی (diffs)، وضعیت ارائه دهنده.
5. فرضیه ها و آزمون: پذیرفته/رد, مراجع به آزمایش.
6. علل ریشه ای: تکنولوژیکی، فرآیندی، سازمانی.
7. عوامل موثر: «چرا متوجه نشد/متوقف نشد».
8. طرح CAPA: جدول اقدامات با صاحبان/مهلت/معیارها.

9. خطرات و آسیب پذیری های باقی مانده: چه چیز دیگری باید مورد نظارت/آزمایش قرار گیرد

10. برنامه های کاربردی: مصنوعات، لینک ها، نمودار ها (لیست).

10) مثال (کوتاه، عمومی)

رویداد: موفقیت پرداخت در 35٪ در 19: 05-19: 26 (SEV-1).
تاثیر: 21 دقیقه نقض e2e-SLO، 3 کشور تحت تاثیر قرار می گیرد، بازده/جبران خسارت.
دلیل 1: نسخه جدید اعتبار سنج کارت تاخیر را به 1 افزایش داد. 2 s → زمان بندی به ارائه دهنده.
دلیل 2 (درصد): هیچ قناری برای ارائه دهنده «A» وجود نداشت، انتشار بلافاصله 100٪ بود.
دلیل 3 (org): آستانه هشدار در SLI کسب و کار یک محدوده BIN خاص (گروه VIP) را پوشش نمی دهد.
CAPA: نسخه قدیمی اعتبار سنج را برگردانید. قناری را وارد کنید 1/5/25٪ ؛ SLI های تجاری را توسط گروه های BIN اضافه کنید. موافقت با شکست 30٪ برای ارائه دهنده «B» ؛ مورد هرج و مرج «آهسته بالادست».

11) معیارهای بلوغ فرآیند RCA

تکمیل CAPA در زمان (٪ در 30 روز بسته).
نرخ بازگشایی (حوادث در 90 روز بازگشایی).
نرخ تغییر شکست قبل/بعد.
نسبت حوادثی که در آن علل سیستماتیک یافت می شود (نه فقط «خطای انسانی»).
تست پوشش سناریوهای جدید از RCA.
زمان انتشار گزارش (انتشار SLA).

12) ویژگی های دامنه های تنظیم شده (fintech/iGaming، و غیره)

گزارش به خارج: نسخه های مشتری/نظارتی گزارش بدون جزئیات حساس، اما با برنامه ای برای جلوگیری از تکرار.
گزارش حسابرسی و غیر قابل تغییر: ذخیره سازی مصنوعات، گزارش های امضا شده، پیوند به بلیط، CMDB، سیاهههای مربوط به انتشار.
داده های کاربر: depersonalization/masking در سیاهههای مربوط به نمونه.
دوره اطلاع: گره خورده است به قراردادها و مقررات (به عنوان مثال،. n ساعت در هر اطلاع اولیه).

13) ضد الگوهای

«واسیا مقصر است» - توقف در عامل انسانی بدون دلایل سیستمیک.
فقدان آزمون فرضیه - نتیجه گیری توسط شهود.
RCA بیش از حد عمومی («سرویس بیش از حد بارگیری شد») - هیچ تغییر خاصی وجود ندارد.
بدون CAPA یا بدون صاحبان/مهلت - گزارش به خاطر گزارش.
پنهان کردن اطلاعات - از دست دادن اعتماد، ناتوانی در آموزش سازمان.
اضافه بار با معیارهای SLI غیر SLO/کسب و کار.

14) ابزار و شیوه

مخزن RCA (ویکی/پایگاه دانش) با ابرداده: سرویس، SEV، دلایل، CAPA، وضعیت.
قالب ها و ربات ها: تولید یک فریم گزارش از یک حادثه (جدول زمانی، نمودارها، نسخه ها).
نمودار علیت: ساخت یک نقشه رویداد-علیت (به عنوان مثال، بر اساس سیاهههای مربوط/ردیابی).
کاتالوگ هرج و مرج: اسکریپت برای بازتولید حوادث گذشته در مرحله.
داشبورد «پس از RCA»: ویدجت های فردی، که اثر CAPA را تایید می کند.

15) چک لیست «آماده برای انتشار»

• جدول زمانی و مصنوعات کامل و تایید شده است.
• علل ریشه شناسایی و اثبات شده توسط آزمایش/آزمایش.

[1] علل ریشه ای و مشارکتی از هم جدا هستند.

• CAPA شامل صاحبان، مهلت ها، معیارهای اثر قابل اندازه گیری است.
• یک برنامه تأیید در 14/30 روز وجود دارد.
• نسخه برای ذینفعان خارجی آماده شده است (در صورت لزوم).
• گزارش مورد بررسی فنی/درصد قرار گرفت.

16) خط پایین

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