با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
Error و Server مقصد را پیدا کن
در خطای اتصال Database نام یا نشانی سرور، Port، پیام Error و اینکه مشکل برای همه است یا یک Client را مشخص کن؛ Reinstall نرمافزار قبل از این بررسیها منطقی نیست برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که در سناریوهای چندلایه، ترتیب آزمون اهمیت دارد؛ ابتدا تستی را انتخاب کن که با کمترین ریسک بیشترین اطلاعات را بدهد و اگر فرضیه رد شد مسیر بعدی را انتخاب کن؛ ارتباط با کاربران و ثبت Timeline هم بخشی از مدیریت رخداد است چون بعداً برای تحلیل علت، گزارش مدیریتی و جلوگیری از تکرار استفاده میشود برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، سناریوی واقعی را مثل یک رخداد زنده مدیریت کن: ابتدا دامنه اثر و سرویس حیاتی را مشخص کن، سپس شواهد جمع کن و از تغییرهای پرخطر دوری کن؛ اگر چند نشانه همزمان وجود دارند، ممکن است یک علت مشترک مانند DNS، Uplink، Storage یا Identity پشت آنها باشد؛ وابستگی سرویسها را روی کاغذ یا Diagram دنبال کن
DNS و Reachability را تست کن
DNS نام را به اطلاعاتی مانند IP تبدیل میکند تا کاربر مجبور نباشد نشانی عددی سرویسها را حفظ کند؛ اگر IP مقصد کار میکند ولی نام نه، Query DNS را جداگانه آزمایش کن پاک کردن Cache ممکن است کمک کند اما جای بررسی Record، Resolver و مسیر DNS را نمیگیرد DNS سامانه نامگذاری توزیعشدهای است که نام را به دادههایی مانند IP مرتبط میکند و بسیاری از سرویسهای سازمانی به Name Resolution درست وابستهاند؛ خطای DNS ممکن است در ظاهر شبیه قطعی شبکه یا خرابی برنامه دیده شود، بنابراین باید جداگانه بررسی شود که Client به DNS Server درست اشاره میکند، Query پاسخ میگیرد، Zone و Record مورد نیاز وجود دارند و زمان و دامنه جستوجو با طراحی شبکه سازگارند نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که سناریوی واقعی را مثل یک رخداد زنده مدیریت کن: ابتدا دامنه اثر و سرویس حیاتی را مشخص کن، سپس شواهد جمع کن و از تغییرهای پرخطر دوری کن؛ اگر چند نشانه همزمان وجود دارند، ممکن است یک علت مشترک مانند DNS، Uplink، Storage یا Identity پشت آنها باشد؛ وابستگی سرویسها را روی کاغذ یا Diagram دنبال کن
Port Database را بررسی کن
Port عدد منطقی داخل TCP یا UDP است که سرویس مقصد را مشخص میکند؛ برای تست سرویس باید IP مقصد، پروتکل و Port را با هم بدانیم Port فیزیکی Switch با Port نرمافزاری TCP/UDP یکی نیست برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، سناریوی واقعی را مثل یک رخداد زنده مدیریت کن: ابتدا دامنه اثر و سرویس حیاتی را مشخص کن، سپس شواهد جمع کن و از تغییرهای پرخطر دوری کن؛ اگر چند نشانه همزمان وجود دارند، ممکن است یک علت مشترک مانند DNS، Uplink، Storage یا Identity پشت آنها باشد؛ وابستگی سرویسها را روی کاغذ یا Diagram دنبال کن در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: در سناریوهای چندلایه، ترتیب آزمون اهمیت دارد؛ ابتدا تستی را انتخاب کن که با کمترین ریسک بیشترین اطلاعات را بدهد و اگر فرضیه رد شد مسیر بعدی را انتخاب کن؛ ارتباط با کاربران و ثبت Timeline هم بخشی از مدیریت رخداد است چون بعداً برای تحلیل علت، گزارش مدیریتی و جلوگیری از تکرار استفاده میشود برای کامل شدن تصویر این موضوع، در این درس تمرکز روی روش فکر کردن در رخداد واقعی است؛ به جای آزمونهای تصادفی باید Scope، Timeline، Recent Change و Evidence را مشخص کنی و هر تست را برای تأیید یا رد یک فرضیه انجام بدهی؛ هدف فقط رسیدن به Fix نیست، بلکه باید بتوانی علت، نتیجه تستها، Validation و اقدام پیشگیرانه را توضیح و مستند کنی
سرویس و Login Database را کنترل کن
در خطای Database بررسی کن سرویس پایگاه داده در حال اجراست و Login مورد استفاده مجاز و منقضینشده است؛ پیام Authentication با Timeout شبکه، مسیر عیبیابی متفاوتی دارد پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: سناریوی واقعی را مثل یک رخداد زنده مدیریت کن: ابتدا دامنه اثر و سرویس حیاتی را مشخص کن، سپس شواهد جمع کن و از تغییرهای پرخطر دوری کن؛ اگر چند نشانه همزمان وجود دارند، ممکن است یک علت مشترک مانند DNS، Uplink، Storage یا Identity پشت آنها باشد؛ وابستگی سرویسها را روی کاغذ یا Diagram دنبال کن
شبکه را از Credential جدا کن
اول Reachability و Port پایگاه داده را جدا از Username/Password آزمایش کن؛ اگر TCP Connection برقرار نمیشود، تغییر Credential معمولاً اولین اقدام درستی نیست برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، سناریوی واقعی را مثل یک رخداد زنده مدیریت کن: ابتدا دامنه اثر و سرویس حیاتی را مشخص کن، سپس شواهد جمع کن و از تغییرهای پرخطر دوری کن؛ اگر چند نشانه همزمان وجود دارند، ممکن است یک علت مشترک مانند DNS، Uplink، Storage یا Identity پشت آنها باشد؛ وابستگی سرویسها را روی کاغذ یا Diagram دنبال کن در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: در سناریوهای چندلایه، ترتیب آزمون اهمیت دارد؛ ابتدا تستی را انتخاب کن که با کمترین ریسک بیشترین اطلاعات را بدهد و اگر فرضیه رد شد مسیر بعدی را انتخاب کن؛ ارتباط با کاربران و ثبت Timeline هم بخشی از مدیریت رخداد است چون بعداً برای تحلیل علت، گزارش مدیریتی و جلوگیری از تکرار استفاده میشود برای کامل شدن تصویر این موضوع، در این درس تمرکز روی روش فکر کردن در رخداد واقعی است؛ به جای آزمونهای تصادفی باید Scope، Timeline، Recent Change و Evidence را مشخص کنی و هر تست را برای تأیید یا رد یک فرضیه انجام بدهی؛ هدف فقط رسیدن به Fix نیست، بلکه باید بتوانی علت، نتیجه تستها، Validation و اقدام پیشگیرانه را توضیح و مستند کنی
فرض کن در سناریوی واقعی شرکت مشکلی گزارش شده و احتمال میدهی به سناریو: نرمافزار به Database وصل نمیشود مربوط باشد. قبل از تغییر، وضعیت فعلی را با ابزارهای مرتبط با همان سناریو و مستندات شرکت بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- پاک کردن Cache ممکن است کمک کند اما جای بررسی Record، Resolver و مسیر DNS را نمیگیرد
- تغییر دادن تنظیمات مرتبط با سناریو: نرمافزار به Database وصل نمیشود قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره سناریو: نرمافزار به Database وصل نمیشود فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با سناریو: نرمافزار به Database وصل نمیشود، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با ابزارهای مرتبط با همان سناریو و مستندات شرکت وضعیت مرتبط با سناریو: نرمافزار به Database وصل نمیشود را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با سناریو: نرمافزار به Database وصل نمیشود بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- Error و Server مقصد را پیدا کن
- DNS و Reachability را تست کن
- Port Database را بررسی کن
- سرویس و Login Database را کنترل کن
- شبکه را از Credential جدا کن
- در هر مرحله فقط یک تغییر کنترلشده انجام بده تا اثر آن قابل تشخیص باشد
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
چرا باید Error و Server مقصد را پیدا کنی و از کجا میفهمی نتیجه درست است؟
در خطای اتصال Database نام یا نشانی سرور، Port، پیام Error و اینکه مشکل برای همه است یا یک Client را مشخص کن؛ Reinstall نرمافزار قبل از این بررسیها منطقی نیست
چرا باید DNS و Reachability را تست کنی و از کجا میفهمی نتیجه درست است؟
DNS نام را به اطلاعاتی مانند IP تبدیل میکند تا کاربر مجبور نباشد نشانی عددی سرویسها را حفظ کند؛ اگر IP مقصد کار میکند ولی نام نه، Query DNS را جداگانه آزمایش کن
چرا باید Port Database را بررسی کنی و از کجا میفهمی نتیجه درست است؟
Port عدد منطقی داخل TCP یا UDP است که سرویس مقصد را مشخص میکند؛ برای تست سرویس باید IP مقصد، پروتکل و Port را با هم بدانیم
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
