با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
RCA بعد از تثبیت سرویس است
در رخداد شدید ابتدا سرویس را ایمن و پایدار کن؛ تحلیل علت اصلی بعد از کنترل وضعیت انجام میشود تا زیر فشار، بازیابی را با تحقیق طولانی عقب نیندازی نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که در رخداد پیچیده، لایهها را جدا کن و یک نقطه سالم مرجع پیدا کن؛ مقایسه Client سالم و مشکلدار، Port سالم و مشکلدار یا زمان قبل و بعد از Change میتواند تفاوت معنیدار را آشکار کند؛ وقتی علت پیدا شد، Workaround و Root Cause را از هم جدا ثبت کن و بعد از Fix سرویس را از دید کاربر و Monitoring تأیید کن در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که عیبیابی حرفهای یعنی مسئله را کوچک کنی نه اینکه تعداد تغییرها را زیاد کنی؛ Scope، Timeline، Recent Change و Evidence چهار ستون اولیهاند؛ سپس هر Test باید یک فرضیه را تأیید یا رد کند و نتیجه ثبت شود؛ اگر یک Test اطلاعات جدیدی نمیدهد، صرف تکرار آن ارزش تشخیصی ندارد برای کامل شدن تصویر این موضوع، در این درس تمرکز روی روش فکر کردن در رخداد واقعی است؛ به جای آزمونهای تصادفی باید Scope، Timeline، Recent Change و Evidence را مشخص کنی و هر تست را برای تأیید یا رد یک فرضیه انجام بدهی؛ هدف فقط رسیدن به Fix نیست، بلکه باید بتوانی علت، نتیجه تستها، Validation و اقدام پیشگیرانه را توضیح و مستند کنی
Five Whys ابزار ساده است
Five Whys با چند بار پرسیدن «چرا» زنجیره علت را از نشانه به فرایند یا ریشه نزدیک میکند؛ لازم نیست دقیقاً پنج بار باشد و هر پاسخ باید با شواهد پشتیبانی شود برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، عیبیابی حرفهای یعنی مسئله را کوچک کنی نه اینکه تعداد تغییرها را زیاد کنی؛ Scope، Timeline، Recent Change و Evidence چهار ستون اولیهاند؛ سپس هر Test باید یک فرضیه را تأیید یا رد کند و نتیجه ثبت شود؛ اگر یک Test اطلاعات جدیدی نمیدهد، صرف تکرار آن ارزش تشخیصی ندارد برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که در رخداد پیچیده، لایهها را جدا کن و یک نقطه سالم مرجع پیدا کن؛ مقایسه Client سالم و مشکلدار، Port سالم و مشکلدار یا زمان قبل و بعد از Change میتواند تفاوت معنیدار را آشکار کند؛ وقتی علت پیدا شد، Workaround و Root Cause را از هم جدا ثبت کن و بعد از Fix سرویس را از دید کاربر و Monitoring تأیید کن
علت فنی و فرایندی ممکن است باشند
RCA میتواند هم علت فنی مثل Configuration غلط و هم علت فرایندی مثل نبود Review یا Test را پیدا کند؛ اقدام پیشگیرانه باید متناسب با هر دو باشد برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، در رخداد پیچیده، لایهها را جدا کن و یک نقطه سالم مرجع پیدا کن؛ مقایسه Client سالم و مشکلدار، Port سالم و مشکلدار یا زمان قبل و بعد از Change میتواند تفاوت معنیدار را آشکار کند؛ وقتی علت پیدا شد، Workaround و Root Cause را از هم جدا ثبت کن و بعد از Fix سرویس را از دید کاربر و Monitoring تأیید کن اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، عیبیابی حرفهای یعنی مسئله را کوچک کنی نه اینکه تعداد تغییرها را زیاد کنی؛ Scope، Timeline، Recent Change و Evidence چهار ستون اولیهاند؛ سپس هر Test باید یک فرضیه را تأیید یا رد کند و نتیجه ثبت شود؛ اگر یک Test اطلاعات جدیدی نمیدهد، صرف تکرار آن ارزش تشخیصی ندارد برای کامل شدن تصویر این موضوع، در این درس تمرکز روی روش فکر کردن در رخداد واقعی است؛ به جای آزمونهای تصادفی باید Scope، Timeline، Recent Change و Evidence را مشخص کنی و هر تست را برای تأیید یا رد یک فرضیه انجام بدهی؛ هدف فقط رسیدن به Fix نیست، بلکه باید بتوانی علت، نتیجه تستها، Validation و اقدام پیشگیرانه را توضیح و مستند کنی
Corrective Action جلوی تکرار را بگیرد
Corrective Action باید علت یا عامل کمککننده را کاهش دهد؛ فقط نوشتن «دقت بیشتری شود» اقدام اصلاحی قابل اندازهگیری نیست برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، در رخداد پیچیده، لایهها را جدا کن و یک نقطه سالم مرجع پیدا کن؛ مقایسه Client سالم و مشکلدار، Port سالم و مشکلدار یا زمان قبل و بعد از Change میتواند تفاوت معنیدار را آشکار کند؛ وقتی علت پیدا شد، Workaround و Root Cause را از هم جدا ثبت کن و بعد از Fix سرویس را از دید کاربر و Monitoring تأیید کن در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: عیبیابی حرفهای یعنی مسئله را کوچک کنی نه اینکه تعداد تغییرها را زیاد کنی؛ Scope، Timeline، Recent Change و Evidence چهار ستون اولیهاند؛ سپس هر Test باید یک فرضیه را تأیید یا رد کند و نتیجه ثبت شود؛ اگر یک Test اطلاعات جدیدی نمیدهد، صرف تکرار آن ارزش تشخیصی ندارد برای کامل شدن تصویر این موضوع، در این درس تمرکز روی روش فکر کردن در رخداد واقعی است؛ به جای آزمونهای تصادفی باید Scope، Timeline، Recent Change و Evidence را مشخص کنی و هر تست را برای تأیید یا رد یک فرضیه انجام بدهی؛ هدف فقط رسیدن به Fix نیست، بلکه باید بتوانی علت، نتیجه تستها، Validation و اقدام پیشگیرانه را توضیح و مستند کنی
RCA برای سرزنش نیست
RCA برای سرزنش نیست تحلیل علت اصلی برای یادگیری و جلوگیری از تکرار است، نه پیدا کردن فرد مقصر؛ تمرکز روی سیستم، کنترل و فرایند باعث گزارش دقیقتر میشود نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که عیبیابی حرفهای یعنی مسئله را کوچک کنی نه اینکه تعداد تغییرها را زیاد کنی؛ Scope، Timeline، Recent Change و Evidence چهار ستون اولیهاند؛ سپس هر Test باید یک فرضیه را تأیید یا رد کند و نتیجه ثبت شود؛ اگر یک Test اطلاعات جدیدی نمیدهد، صرف تکرار آن ارزش تشخیصی ندارد نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که در رخداد پیچیده، لایهها را جدا کن و یک نقطه سالم مرجع پیدا کن؛ مقایسه Client سالم و مشکلدار، Port سالم و مشکلدار یا زمان قبل و بعد از Change میتواند تفاوت معنیدار را آشکار کند؛ وقتی علت پیدا شد، Workaround و Root Cause را از هم جدا ثبت کن و بعد از Fix سرویس را از دید کاربر و Monitoring تأیید کن برای کامل شدن تصویر این موضوع، در این درس تمرکز روی روش فکر کردن در رخداد واقعی است؛ به جای آزمونهای تصادفی باید Scope، Timeline، Recent Change و Evidence را مشخص کنی و هر تست را برای تأیید یا رد یک فرضیه انجام بدهی؛ هدف فقط رسیدن به Fix نیست، بلکه باید بتوانی علت، نتیجه تستها، Validation و اقدام پیشگیرانه را توضیح و مستند کنی
فرض کن در یک رخداد عیبیابی واقعی مشکلی گزارش شده و احتمال میدهی به تحلیل علت اصلی مربوط باشد. قبل از تغییر، وضعیت فعلی را با ابزارهای شبکه، Logها و مقایسه قبل و بعد بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- تغییر دادن تنظیمات مرتبط با تحلیل علت اصلی قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره تحلیل علت اصلی فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با تحلیل علت اصلی، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با ابزارهای شبکه، Logها و مقایسه قبل و بعد وضعیت مرتبط با تحلیل علت اصلی را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با تحلیل علت اصلی بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- RCA بعد از تثبیت سرویس است
- Five Whys ابزار ساده است
- علت فنی و فرایندی ممکن است باشند
- Corrective Action جلوی تکرار را بگیرد
- RCA برای سرزنش نیست
- قبل از تغییر، محدوده مشکل را مشخص کن و از کمخطرترین تست شروع کن
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: RCA بعد از تثبیت سرویس است. بعد بگو در عمل چطور آن را بررسی میکنی.
در رخداد شدید ابتدا سرویس را ایمن و پایدار کن؛ تحلیل علت اصلی بعد از کنترل وضعیت انجام میشود تا زیر فشار، بازیابی را با تحقیق طولانی عقب نیندازی
این نکته را با یک مثال توضیح بده: Five Whys ابزار ساده است. بعد بگو در عمل چطور آن را بررسی میکنی.
Five Whys با چند بار پرسیدن «چرا» زنجیره علت را از نشانه به فرایند یا ریشه نزدیک میکند؛ لازم نیست دقیقاً پنج بار باشد و هر پاسخ باید با شواهد پشتیبانی شود
این نکته را با یک مثال توضیح بده: علت فنی و فرایندی ممکن است باشند. بعد بگو در عمل چطور آن را بررسی میکنی.
RCA میتواند هم علت فنی مثل Configuration غلط و هم علت فرایندی مثل نبود Review یا Test را پیدا کند. اقدام پیشگیرانه باید متناسب با هر دو باشد
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
