با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
Client چیست
Client به دستگاه یا نرمافزاری گفته میشود که از یک سرویس درخواست میفرستد؛ مثلاً مرورگر هنگام باز کردن یک وبسایت نقش Web Client را دارد و کامپیوتر کاربر هنگام باز کردن یک پوشه اشتراکی، Client سرویس فایل است یک رایانه کاربر میتواند همزمان از چند سرویس مختلف استفاده کند؛ در معماری Client/Server، «Client» بیشتر یک نقش ارتباطی است تا یک نوع خاص سختافزار Client فقط خود کامپیوتر نیست و میتواند یک نرمافزار هم باشد؛ مرورگر Web Client است و Outlook نیز برای دریافت و ارسال پیام نقش Client سرویس ایمیل را دارد در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: برای کارشناس پشتیبانی، ثبت اطلاعات بخشی از حل مشکل است؛ زمان شروع، دامنه اثر، پیام خطا، تغییرات اخیر و نتیجه هر تست باید کوتاه و دقیق ثبت شوند؛ این اطلاعات هنگام ارجاع، تکرار رخداد یا بررسی علت اصلی ارزش پیدا میکنند؛ همچنین قبل از تغییری که میتواند سرویس را تحت تأثیر قرار دهد، وضعیت فعلی و راه بازگشت مشخص شود تا عیبیابی به مجموعهای از آزمونهای بدون کنترل تبدیل نشود
سرور چیست
سرور سیستمی است که یک سرویس را در اختیار رایانههای کاربران قرار میدهد؛ سرور فایل، فایلها و پوشههای اشتراکی را در اختیار کاربران قرار میدهد، DNS سرور نام را به IP مرتبط میکند و کنترلکننده دامنه بخشی از احراز هویت را انجام میدهد سرور میتواند فیزیکی یا ماشین مجازی باشد؛ حتی یک نرمافزار روی یک کامپیوتر معمولی میتواند نقش سرور داشته باشد، هرچند در محیط سازمانی طراحی مناسبتری برای پایداری لازم است نام سرور به این معنی نیست که آن دستگاه فقط یک سرویس دارد؛ یک سرور کوچک ممکن است چند نقش داشته باشد، ولی برای عیبیابی باید بفهمی کدام سرویس دقیقاً مشکل دارد در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که در محیط واقعی، ارزش پشتیبانی زمانی دیده میشود که سرویس قابل استفاده بماند و کاربر بداند چه اتفاقی افتاده است؛ برای همین همیشه مسئله را از سه زاویه ببین: اثر روی کاربر و کسبوکار، جزء فنی درگیر و شواهدی که میتوانی اندازهگیری یا ثبت کنی؛ این نگاه مانع میشود هر مشکل را سریع به یک دستگاه یا یک نفر نسبت بدهی و کمک میکند وابستگی بین Client، Network، Identity، Server و Application را مرحلهبهمرحله بررسی کنی
درخواست و پاسخ
ارتباط معمولاً با درخواست شروع میشود؛ رایانه کاربر درخواست مشخصی به مقصد میفرستد و سرور اگر در دسترس و مجاز باشد پاسخ میدهد اگر پاسخ نرسد چند احتمال وجود دارد: درخواست اصلاً از رایانه کاربر خارج نشده، در مسیر مسدود کردن شده، سرور سرویس را گوش نمیدهد یا پاسخ در مسیر برگشت مشکل دارد این مدل ذهنی بعداً در پورت، فایروال، DNS، مسیریابی و نرمافزار بسیار مهم میشود در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که در محیط واقعی، ارزش پشتیبانی زمانی دیده میشود که سرویس قابل استفاده بماند و کاربر بداند چه اتفاقی افتاده است؛ برای همین همیشه مسئله را از سه زاویه ببین: اثر روی کاربر و کسبوکار، جزء فنی درگیر و شواهدی که میتوانی اندازهگیری یا ثبت کنی؛ این نگاه مانع میشود هر مشکل را سریع به یک دستگاه یا یک نفر نسبت بدهی و کمک میکند وابستگی بین Client، Network، Identity، Server و Application را مرحلهبهمرحله بررسی کنی
یک کاربر یا همه کاربران
اگر فقط یک کاربر به سرور فایل وصل نمیشود اما بقیه وصل میشوند احتمال مشکل رایانه کاربر، حساب کاربری یا مسیر مخصوص همان کاربر بیشتر است؛ اگر همه کاربران همزمان مشکل دارند احتمال سرور یا بخش مشترک شبکه بیشتر میشود این یک قانون قطعی نیست اما روش خوبی برای محدود کردن محدوده است؛ همیشه با تست آن را تأیید کن نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که در محیط واقعی، ارزش پشتیبانی زمانی دیده میشود که سرویس قابل استفاده بماند و کاربر بداند چه اتفاقی افتاده است؛ برای همین همیشه مسئله را از سه زاویه ببین: اثر روی کاربر و کسبوکار، جزء فنی درگیر و شواهدی که میتوانی اندازهگیری یا ثبت کنی؛ این نگاه مانع میشود هر مشکل را سریع به یک دستگاه یا یک نفر نسبت بدهی و کمک میکند وابستگی بین Client، Network، Identity، Server و Application را مرحلهبهمرحله بررسی کنی نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که برای کارشناس پشتیبانی، ثبت اطلاعات بخشی از حل مشکل است؛ زمان شروع، دامنه اثر، پیام خطا، تغییرات اخیر و نتیجه هر تست باید کوتاه و دقیق ثبت شوند؛ این اطلاعات هنگام ارجاع، تکرار رخداد یا بررسی علت اصلی ارزش پیدا میکنند؛ همچنین قبل از تغییری که میتواند سرویس را تحت تأثیر قرار دهد، وضعیت فعلی و راه بازگشت مشخص شود تا عیبیابی به مجموعهای از آزمونهای بدون کنترل تبدیل نشود
نام و IP
کاربر معمولاً سرور را با نام میشناسد اما شبکه برای ارتباط به IP نیاز دارد. DNS بین نام و IP ارتباط ایجاد میکند به همین دلیل ممکن است سرور با IP باز شود اما با نام باز نشود؛ در چنین حالتی مسیر IP شاید سالم باشد ولی DNS یا فرایند تبدیل نام به IP نیاز به بررسی دارد این مقایسه یکی از تستهای کمریسک و بسیار مفید است چون بدون تغییر اطلاعات خوبی درباره محل مشکل میدهد نشانی IP هویت منطقی Interface در لایه شبکه است و باید همراه Prefix یا Subnet Mask تفسیر شود؛ Prefix مشخص میکند کدام بخش نشانی برای شبکه و کدام بخش برای Host استفاده میشود و همین موضوع تعیین میکند مقصد محلی است یا باید به Router فرستاده شود؛ در عیبیابی، فقط دیدن یک IP کافی نیست و باید Prefix، Gateway، DNS، روش دریافت تنظیمات، Route Table و احتمال وجود نشانی تکراری نیز بررسی شوند اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، در محیط واقعی، ارزش پشتیبانی زمانی دیده میشود که سرویس قابل استفاده بماند و کاربر بداند چه اتفاقی افتاده است؛ برای همین همیشه مسئله را از سه زاویه ببین: اثر روی کاربر و کسبوکار، جزء فنی درگیر و شواهدی که میتوانی اندازهگیری یا ثبت کنی؛ این نگاه مانع میشود هر مشکل را سریع به یک دستگاه یا یک نفر نسبت بدهی و کمک میکند وابستگی بین Client، Network، Identity، Server و Application را مرحلهبهمرحله بررسی کنی
سرویس روی سرور
روشن بودن سرور ثابت نمیکند همه سرویسهای آن سالم هستند؛ ممکن است ویندوز روشن باشد اما سرویس پایگاه داده توقف شده باشد یا فضای ذخیرهسازی پر شده باشد در عیبیابی همیشه بین دسترسیپذیری شبکه خود سرور و سلامت نرمافزار یا سرویس روی آن تفاوت بگذار نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که برای کارشناس پشتیبانی، ثبت اطلاعات بخشی از حل مشکل است؛ زمان شروع، دامنه اثر، پیام خطا، تغییرات اخیر و نتیجه هر تست باید کوتاه و دقیق ثبت شوند؛ این اطلاعات هنگام ارجاع، تکرار رخداد یا بررسی علت اصلی ارزش پیدا میکنند؛ همچنین قبل از تغییری که میتواند سرویس را تحت تأثیر قرار دهد، وضعیت فعلی و راه بازگشت مشخص شود تا عیبیابی به مجموعهای از آزمونهای بدون کنترل تبدیل نشود نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که در محیط واقعی، ارزش پشتیبانی زمانی دیده میشود که سرویس قابل استفاده بماند و کاربر بداند چه اتفاقی افتاده است؛ برای همین همیشه مسئله را از سه زاویه ببین: اثر روی کاربر و کسبوکار، جزء فنی درگیر و شواهدی که میتوانی اندازهگیری یا ثبت کنی؛ این نگاه مانع میشود هر مشکل را سریع به یک دستگاه یا یک نفر نسبت بدهی و کمک میکند وابستگی بین Client، Network، Identity، Server و Application را مرحلهبهمرحله بررسی کنی
یک سرور میتواند چند نقش داشته باشد
در محیط کوچک ممکن است یک سرور هم سرور فایل باشد، هم DNS و هم نرمافزار خاصی را اجرا کند؛ این کار از نظر فنی ممکن است اما باعث میشود خرابی همان سرور روی چند سرویس اثر بگذارد و نگهداری آن حساستر شود در محیط بزرگتر نقشها معمولاً جدا میشوند تا مدیریت، امنیت و دسترسپذیری بهتر شود؛ با این حال برای عیبیابی مهم است بدانی هر سرویس واقعاً روی کدام سرور یا ماشین مجازی اجرا میشود و فقط از روی اسم دستگاه حدس نزنی یک سرور بودن به ظاهر دستگاه ربط ندارد؛ یک ماشین مجازی کوچک هم میتواند سرور بسیار مهمی باشد و یک سختافزار قدرتمند ممکن است فقط میزبان چند VM باشد برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، برای کارشناس پشتیبانی، ثبت اطلاعات بخشی از حل مشکل است؛ زمان شروع، دامنه اثر، پیام خطا، تغییرات اخیر و نتیجه هر تست باید کوتاه و دقیق ثبت شوند؛ این اطلاعات هنگام ارجاع، تکرار رخداد یا بررسی علت اصلی ارزش پیدا میکنند؛ همچنین قبل از تغییری که میتواند سرویس را تحت تأثیر قرار دهد، وضعیت فعلی و راه بازگشت مشخص شود تا عیبیابی به مجموعهای از آزمونهای بدون کنترل تبدیل نشود
هم Client و هم Server را بررسی کن
وقتی رایانه کاربر نمیتواند به سرویس وصل شود، فقط رایانه کاربر را راهاندازی مجدد نکن؛ ابتدا مشخص کن آیا سرور سرویس را ارائه میدهد، آیا رایانه کاربر مسیر شبکه دارد و آیا پورت یا فایروال بین آنها اجازه ارتباط میدهد اگر چند رایانه کاربر مختلف به همان سرور مشکل دارند، احتمال مشکل سمت سرور یا مسیر مشترک بیشتر میشود؛ اگر فقط یک رایانه کاربر مشکل دارد، تنظیمات محلی، حساب کاربری یا مسیر مخصوص همان دستگاه ارزش بررسی بیشتری دارد این مقایسه ساده اساس بسیاری از سناریوهای حرفهای است؛ در مراحل بعد با Ping، پرسوجوی DNS، بررسی پورت و گزارش رویداد آن را دقیقتر انجام خواهی داد اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، برای کارشناس پشتیبانی، ثبت اطلاعات بخشی از حل مشکل است؛ زمان شروع، دامنه اثر، پیام خطا، تغییرات اخیر و نتیجه هر تست باید کوتاه و دقیق ثبت شوند؛ این اطلاعات هنگام ارجاع، تکرار رخداد یا بررسی علت اصلی ارزش پیدا میکنند؛ همچنین قبل از تغییری که میتواند سرویس را تحت تأثیر قرار دهد، وضعیت فعلی و راه بازگشت مشخص شود تا عیبیابی به مجموعهای از آزمونهای بدون کنترل تبدیل نشود
کاربر مسیر \\FileServer\public را باز نمیکند. اگر همان اشتراک با IP باز شود، سرنخ مهمی داری که سرور فایل و مسیر IP احتمالاً در دسترس هستند و باید DNS یا Name Resolution را بررسی کنی
این اشتباهها را تکرار نکن
- فرض اینکه سرور همیشه یک دستگاه بزرگ فیزیکی است
- راهاندازی مجدد Server قبل از بررسی اینکه مشکل فقط برای یک Client است
- نادیده گرفتن تفاوت دسترسی با نام و IP
- فرض اینکه Ping موفق یعنی نرمافزار حتماً سالم است
حالا خودت انجام بده
- سه نمونه Client/Server از محیط شرکت بنویس
- برای حالتی که فقط یک Client مشکل دارد سه علت محتمل بنویس
- مسیر یک درخواست مرورگر تا وب سرور را رسم کن
- برای یک سرور بنویس چه سرویسهایی ممکن است روی آن اجرا شوند
نکتههایی که باید با خودت ببری
- Client درخواست میفرستد و Server سرویس ارائه میدهد
- یک دستگاه یا نرمافزار میتواند بسته به معماری در نقش Client یا Server قرار بگیرد
- مقایسه چند رایانه کاربر و تست نام/IP کمک میکند محدوده مشکل را محدود کنی
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
اگر همه کاربران یک سرویس را از دست بدهند چه نتیجهای میگیری
احتمال مشکل در بخش مشترک مثل سرور یا شبکه بیشتر میشود اما هنوز باید با تست تأیید شود
چرا تست با IP و نام مفید است
چون میتواند مشکل تبدیل نام به IP را از مشکل دسترسی شبکه جدا کند
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
