با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
پیام خطا دقیق ثبت شود
متن کامل Error، Code، Source، زمان و عملی که کاربر انجام میداد را ثبت کن؛ بازنویسی مبهم مثل «خطا داد» اطلاعاتی را که برای جستوجو و مقایسه لازم است از بین میبرد روش عیبیابی قابل اتکا از تعیین دامنه مشکل شروع میشود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویسها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیهها از کمریسکترین تستها بررسی شوند؛ تغییر چند عامل همزمان تشخیص علت را دشوار میکند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که عیبیابی حرفهای یعنی مسئله را کوچک کنی نه اینکه تعداد تغییرها را زیاد کنی؛ Scope، Timeline، Recent Change و Evidence چهار ستون اولیهاند؛ سپس هر Test باید یک فرضیه را تأیید یا رد کند و نتیجه ثبت شود؛ اگر یک Test اطلاعات جدیدی نمیدهد، صرف تکرار آن ارزش تشخیصی ندارد در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: در رخداد پیچیده، لایهها را جدا کن و یک نقطه سالم مرجع پیدا کن؛ مقایسه Client سالم و مشکلدار، Port سالم و مشکلدار یا زمان قبل و بعد از Change میتواند تفاوت معنیدار را آشکار کند؛ وقتی علت پیدا شد، Workaround و Root Cause را از هم جدا ثبت کن و بعد از Fix سرویس را از دید کاربر و Monitoring تأیید کن
زمان دقیق رخداد مهم است
زمان دقیق رخداد را ثبت کن چون Logها، تغییرها و Alertها با زمان به هم وصل میشوند؛ جمله «صبح خراب شد» برای ساخت Timeline دقیق کافی نیست برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، عیبیابی حرفهای یعنی مسئله را کوچک کنی نه اینکه تعداد تغییرها را زیاد کنی؛ Scope، Timeline، Recent Change و Evidence چهار ستون اولیهاند؛ سپس هر Test باید یک فرضیه را تأیید یا رد کند و نتیجه ثبت شود؛ اگر یک Test اطلاعات جدیدی نمیدهد، صرف تکرار آن ارزش تشخیصی ندارد در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: در رخداد پیچیده، لایهها را جدا کن و یک نقطه سالم مرجع پیدا کن؛ مقایسه Client سالم و مشکلدار، Port سالم و مشکلدار یا زمان قبل و بعد از Change میتواند تفاوت معنیدار را آشکار کند؛ وقتی علت پیدا شد، Workaround و Root Cause را از هم جدا ثبت کن و بعد از Fix سرویس را از دید کاربر و Monitoring تأیید کن برای کامل شدن تصویر این موضوع، در این درس تمرکز روی روش فکر کردن در رخداد واقعی است؛ به جای آزمونهای تصادفی باید Scope، Timeline، Recent Change و Evidence را مشخص کنی و هر تست را برای تأیید یا رد یک فرضیه انجام بدهی؛ هدف فقط رسیدن به Fix نیست، بلکه باید بتوانی علت، نتیجه تستها، Validation و اقدام پیشگیرانه را توضیح و مستند کنی
Configuration قبل تغییر ذخیره شود
قبل از تغییر، مقدار فعلی تنظیمات مرتبط را ذخیره یا ثبت کن؛ این کار هم مقایسه Before/After را ممکن میکند و هم بازگشت امن را از حدس زدن نجات میدهد در ذخیرهسازی باید رابط فیزیکی، پروتکل، نوع رسانه و الگوی کار را از هم جدا دید؛ SATA و PCIe مسیر ارتباطی هستند و NVMe پروتکلی است که معمولاً روی PCIe کار میکند، بنابراین صرف دیدن فرم M.۲ نوع ارتباط را مشخص نمیکند؛ برای ارزیابی سلامت نیز ظرفیت آزاد، خطاهای ثبتشده، وضعیت SMART، دمای درایو، تأخیر I/O و رفتار سیستم در زمان بار باید با هم بررسی شوند و یک شاخص بهتنهایی برای نتیجهگیری کافی نیست Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمانبندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود میتواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگیها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفهای است
وضعیت پایه معیار سالم است
وضعیت پایه، وضعیت عادی و سالم سیستم است که برای مقایسه هنگام خرابی استفاده میشود؛ مصرف معمول CPU، Latency و Config سالم نمونه وضعیت پایه است عدد خارج از عادت لزوماً بد نیست؛ اثر روی سرویس را هم ببین اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، عیبیابی حرفهای یعنی مسئله را کوچک کنی نه اینکه تعداد تغییرها را زیاد کنی؛ Scope، Timeline، Recent Change و Evidence چهار ستون اولیهاند؛ سپس هر Test باید یک فرضیه را تأیید یا رد کند و نتیجه ثبت شود؛ اگر یک Test اطلاعات جدیدی نمیدهد، صرف تکرار آن ارزش تشخیصی ندارد نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که در رخداد پیچیده، لایهها را جدا کن و یک نقطه سالم مرجع پیدا کن؛ مقایسه Client سالم و مشکلدار، Port سالم و مشکلدار یا زمان قبل و بعد از Change میتواند تفاوت معنیدار را آشکار کند؛ وقتی علت پیدا شد، Workaround و Root Cause را از هم جدا ثبت کن و بعد از Fix سرویس را از دید کاربر و Monitoring تأیید کن
گفته کاربر با Test فنی تکمیل شود
گزارش کاربر نقطه شروع است نه نتیجه نهایی؛ حرف او را دقیق ثبت کن و سپس با آزمایش فنی، پیام خطا و نمونه سالم مشخص کن نشانه دقیقاً در کدام لایه رخ میدهد اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، در رخداد پیچیده، لایهها را جدا کن و یک نقطه سالم مرجع پیدا کن؛ مقایسه Client سالم و مشکلدار، Port سالم و مشکلدار یا زمان قبل و بعد از Change میتواند تفاوت معنیدار را آشکار کند؛ وقتی علت پیدا شد، Workaround و Root Cause را از هم جدا ثبت کن و بعد از Fix سرویس را از دید کاربر و Monitoring تأیید کن در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: عیبیابی حرفهای یعنی مسئله را کوچک کنی نه اینکه تعداد تغییرها را زیاد کنی؛ Scope، Timeline، Recent Change و Evidence چهار ستون اولیهاند؛ سپس هر Test باید یک فرضیه را تأیید یا رد کند و نتیجه ثبت شود؛ اگر یک Test اطلاعات جدیدی نمیدهد، صرف تکرار آن ارزش تشخیصی ندارد
فرض کن در یک رخداد عیبیابی واقعی مشکلی گزارش شده و احتمال میدهی به جمعآوری شواهد و وضعیت پایه مربوط باشد. قبل از تغییر، وضعیت فعلی را با ابزارهای شبکه، Logها و مقایسه قبل و بعد بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- زمان دقیق رخداد را ثبت کن چون Logها، تغییرها و Alertها با زمان به هم وصل میشوند. جمله «صبح خراب شد» برای ساخت Timeline دقیق کافی نیست
- تغییر دادن تنظیمات مرتبط با جمعآوری شواهد و وضعیت پایه قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره جمعآوری شواهد و وضعیت پایه فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با جمعآوری شواهد و وضعیت پایه، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با ابزارهای شبکه، Logها و مقایسه قبل و بعد وضعیت مرتبط با جمعآوری شواهد و وضعیت پایه را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با جمعآوری شواهد و وضعیت پایه بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- پیام خطا دقیق ثبت شود
- زمان دقیق رخداد مهم است
- Configuration قبل تغییر ذخیره شود
- وضعیت پایه معیار سالم است
- گفته کاربر با Test فنی تکمیل شود
- قبل از تغییر، محدوده مشکل را مشخص کن و از کمخطرترین تست شروع کن
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: پیام خطا دقیق ثبت شود. بعد بگو در عمل چطور آن را بررسی میکنی.
متن کامل Error، Code، Source، زمان و عملی که کاربر انجام میداد را ثبت کن. بازنویسی مبهم مثل «خطا داد» اطلاعاتی را که برای جستوجو و مقایسه لازم است از بین میبرد
این نکته را با یک مثال توضیح بده: زمان دقیق رخداد مهم است. بعد بگو در عمل چطور آن را بررسی میکنی.
زمان دقیق رخداد را ثبت کن چون Logها، تغییرها و Alertها با زمان به هم وصل میشوند. جمله «صبح خراب شد» برای ساخت Timeline دقیق کافی نیست
این نکته را با یک مثال توضیح بده: Configuration قبل تغییر ذخیره شود. بعد بگو در عمل چطور آن را بررسی میکنی.
قبل از تغییر، مقدار فعلی تنظیمات مرتبط را ذخیره یا ثبت کن. این کار هم مقایسه Before/After را ممکن میکند و هم بازگشت امن را از حدس زدن نجات میدهد
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
