درس ۴ از ۲۰

کاربر، حساب، دستگاه، سرویس و برنامه را از هم جدا کنیم

بسیاری از خطاهای پشتیبانی از اینجا شروع می‌شوند که چند مفهوم متفاوت را یکی فرض می‌کنیم؛ در این درس یاد می‌گیری دقیقاً چه چیزی خراب است و درباره چه چیزی سؤال می‌پرسی این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی

این درس برای مطالعه کامل نوشته شده است

با حوصله بخوان، مثال‌ها را تحلیل کن و تمرین‌ها را انجام بده؛ هدف حفظ کردن تعریف‌ها نیست

کاربر با حساب کاربری یکی نیست

کاربر همان فرد یا استفاده‌کننده است؛ حساب کاربری هویت دیجیتالی است که سیستم برای شناسایی او استفاده می‌کند؛ یک کاربر ممکن است چند حساب کاربری داشته باشد و یک حساب سرویس هم ممکن است اصلاً متعلق به انسان نباشد وقتی می‌گوییم «کاربر قفل شده» باید دقیق شویم: خود فرد مشکل دارد یا حساب کاربری او قفل شده است؛ این دقت در نوشتن درخواست پشتیبانی و عیب‌یابی مهم است ممکن است یک نفر حساب کاربری ویندوز، ایمیل، نرم‌افزار مالی و VPN جداگانه داشته باشد؛ خراب شدن یکی از آن‌ها به معنی خراب شدن همه هویت‌های او نیست برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، در محیط واقعی، ارزش پشتیبانی زمانی دیده می‌شود که سرویس قابل استفاده بماند و کاربر بداند چه اتفاقی افتاده است؛ برای همین همیشه مسئله را از سه زاویه ببین: اثر روی کاربر و کسب‌وکار، جزء فنی درگیر و شواهدی که می‌توانی اندازه‌گیری یا ثبت کنی؛ این نگاه مانع می‌شود هر مشکل را سریع به یک دستگاه یا یک نفر نسبت بدهی و کمک می‌کند وابستگی بین Client، Network، Identity، Server و Application را مرحله‌به‌مرحله بررسی کنی

دستگاه چیست

دستگاه وسیله‌ای است که در محیط فناوری اطلاعات استفاده می‌شود؛ کامپیوتر، لپ‌تاپ، موبایل، چاپگر، سوئیچ و سرور همه دستگاه هستند اما نقش آن‌ها متفاوت است برای پشتیبانی بهتر هر دستگاه باید دارایی مشخصی داشته باشد؛ نام، مدل، شماره سریال، IP در صورت نیاز، محل استقرار و واحد استفاده‌کننده اطلاعات مفیدی هستند وقتی درخواست پشتیبانی درباره یک دستگاه است نام دقیق یا برچسب دارایی آن را ثبت کن تا نفر بعدی مجبور نباشد حدس بزند منظور کدام سیستم است نکته‌ای که هنگام پشتیبانی نباید از آن عبور کنی این است که در محیط واقعی، ارزش پشتیبانی زمانی دیده می‌شود که سرویس قابل استفاده بماند و کاربر بداند چه اتفاقی افتاده است؛ برای همین همیشه مسئله را از سه زاویه ببین: اثر روی کاربر و کسب‌وکار، جزء فنی درگیر و شواهدی که می‌توانی اندازه‌گیری یا ثبت کنی؛ این نگاه مانع می‌شود هر مشکل را سریع به یک دستگاه یا یک نفر نسبت بدهی و کمک می‌کند وابستگی بین Client، Network، Identity، Server و Application را مرحله‌به‌مرحله بررسی کنی برای عیب‌یابی درست، این بخش را فقط به‌عنوان یک اصطلاح حفظ نکن و توجه داشته باش که برای کارشناس پشتیبانی، ثبت اطلاعات بخشی از حل مشکل است؛ زمان شروع، دامنه اثر، پیام خطا، تغییرات اخیر و نتیجه هر تست باید کوتاه و دقیق ثبت شوند؛ این اطلاعات هنگام ارجاع، تکرار رخداد یا بررسی علت اصلی ارزش پیدا می‌کنند؛ همچنین قبل از تغییری که می‌تواند سرویس را تحت تأثیر قرار دهد، وضعیت فعلی و راه بازگشت مشخص شود تا عیب‌یابی به مجموعه‌ای از آزمون‌های بدون کنترل تبدیل نشود

نرم‌افزار چیست

نرم‌افزار برنامه‌ای است که کاربر برای انجام کار استفاده می‌کند، مثل مرورگر، نرم‌افزار حسابداری یا اوت‌لوک؛ برنامه ممکن است روی همان رایانه کاربر نصب باشد یا بخشی از آن به سرور متصل شود اگر نرم‌افزار باز نمی‌شود لزوماً خود برنامه خراب نیست؛ ممکن است سرویس پشت آن، پایگاه داده، DNS یا مجوز دسترسی کاربر مشکل داشته باشد قبل از نصب مجدد نرم‌افزار بررسی کن آیا همان برنامه برای کاربر دیگر کار می‌کند، آیا وب نسخه موجود است و پیام خطا دقیقاً به کدام بخش اشاره می‌کند برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، برای کارشناس پشتیبانی، ثبت اطلاعات بخشی از حل مشکل است؛ زمان شروع، دامنه اثر، پیام خطا، تغییرات اخیر و نتیجه هر تست باید کوتاه و دقیق ثبت شوند؛ این اطلاعات هنگام ارجاع، تکرار رخداد یا بررسی علت اصلی ارزش پیدا می‌کنند؛ همچنین قبل از تغییری که می‌تواند سرویس را تحت تأثیر قرار دهد، وضعیت فعلی و راه بازگشت مشخص شود تا عیب‌یابی به مجموعه‌ای از آزمون‌های بدون کنترل تبدیل نشود برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، در محیط واقعی، ارزش پشتیبانی زمانی دیده می‌شود که سرویس قابل استفاده بماند و کاربر بداند چه اتفاقی افتاده است؛ برای همین همیشه مسئله را از سه زاویه ببین: اثر روی کاربر و کسب‌وکار، جزء فنی درگیر و شواهدی که می‌توانی اندازه‌گیری یا ثبت کنی؛ این نگاه مانع می‌شود هر مشکل را سریع به یک دستگاه یا یک نفر نسبت بدهی و کمک می‌کند وابستگی بین Client، Network، Identity، Server و Application را مرحله‌به‌مرحله بررسی کنی

سرویس چیست

سرویس قابلیتی است که یک سیستم به سیستم یا کاربر دیگر ارائه می‌دهد. DNS، DHCP، فایل اشتراک‌گذاری، احراز هویت و وب سرویس مثال هستند سرویس ممکن است در پس‌زمینه اجرا شود و کاربر نام آن را نداند؛ وظیفه کارشناس این است که از روی نشانه‌های کاربر تشخیص دهد کدام سرویس در زنجیره دخیل است مثلاً کاربر فقط می‌گوید «پوشه باز نمی‌شود» اما پشت این درخواست ممکن است DNS، SMB، احراز هویت و مجوز دسترسی هم‌زمان نقش داشته باشند برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، برای کارشناس پشتیبانی، ثبت اطلاعات بخشی از حل مشکل است؛ زمان شروع، دامنه اثر، پیام خطا، تغییرات اخیر و نتیجه هر تست باید کوتاه و دقیق ثبت شوند؛ این اطلاعات هنگام ارجاع، تکرار رخداد یا بررسی علت اصلی ارزش پیدا می‌کنند؛ همچنین قبل از تغییری که می‌تواند سرویس را تحت تأثیر قرار دهد، وضعیت فعلی و راه بازگشت مشخص شود تا عیب‌یابی به مجموعه‌ای از آزمون‌های بدون کنترل تبدیل نشود برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، در محیط واقعی، ارزش پشتیبانی زمانی دیده می‌شود که سرویس قابل استفاده بماند و کاربر بداند چه اتفاقی افتاده است؛ برای همین همیشه مسئله را از سه زاویه ببین: اثر روی کاربر و کسب‌وکار، جزء فنی درگیر و شواهدی که می‌توانی اندازه‌گیری یا ثبت کنی؛ این نگاه مانع می‌شود هر مشکل را سریع به یک دستگاه یا یک نفر نسبت بدهی و کمک می‌کند وابستگی بین Client، Network، Identity، Server و Application را مرحله‌به‌مرحله بررسی کنی

منبع چیست

منبع چیزی است که کاربر یا سرویس می‌خواهد به آن دسترسی داشته باشد؛ پوشه، چاپگر، پایگاه داده، وب‌سایت یا حتی یک API می‌تواند منبع باشد وقتی پیام خطای نداشتن دسترسی می‌بینی باید بپرسی دسترسی به کدام منبع و با کدام حساب کاربری انجام می‌شود؛ این سؤال ساده محدوده را بسیار دقیق‌تر می‌کند برای عیب‌یابی درست، این بخش را فقط به‌عنوان یک اصطلاح حفظ نکن و توجه داشته باش که در محیط واقعی، ارزش پشتیبانی زمانی دیده می‌شود که سرویس قابل استفاده بماند و کاربر بداند چه اتفاقی افتاده است؛ برای همین همیشه مسئله را از سه زاویه ببین: اثر روی کاربر و کسب‌وکار، جزء فنی درگیر و شواهدی که می‌توانی اندازه‌گیری یا ثبت کنی؛ این نگاه مانع می‌شود هر مشکل را سریع به یک دستگاه یا یک نفر نسبت بدهی و کمک می‌کند وابستگی بین Client، Network، Identity، Server و Application را مرحله‌به‌مرحله بررسی کنی در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: برای کارشناس پشتیبانی، ثبت اطلاعات بخشی از حل مشکل است؛ زمان شروع، دامنه اثر، پیام خطا، تغییرات اخیر و نتیجه هر تست باید کوتاه و دقیق ثبت شوند؛ این اطلاعات هنگام ارجاع، تکرار رخداد یا بررسی علت اصلی ارزش پیدا می‌کنند؛ همچنین قبل از تغییری که می‌تواند سرویس را تحت تأثیر قرار دهد، وضعیت فعلی و راه بازگشت مشخص شود تا عیب‌یابی به مجموعه‌ای از آزمون‌های بدون کنترل تبدیل نشود

چرا تفکیک این مفاهیم مهم است

اگر کاربر بگوید «اکانتینگ قطع است» باید مشخص شود منظور نرم‌افزار حسابداری است، سرور آن خاموش است، حساب کاربری کاربر اجازه ندارد یا شبکه به سرور نمی‌رسد هرچه موضوع درخواست پشتیبانی دقیق‌تر نوشته شود احتمال شروع از مسیر اشتباه کمتر می‌شود؛ این مهارت ساده بعدها در عیب‌یابی پیچیده ارزش زیادی دارد برای عیب‌یابی درست، این بخش را فقط به‌عنوان یک اصطلاح حفظ نکن و توجه داشته باش که در محیط واقعی، ارزش پشتیبانی زمانی دیده می‌شود که سرویس قابل استفاده بماند و کاربر بداند چه اتفاقی افتاده است؛ برای همین همیشه مسئله را از سه زاویه ببین: اثر روی کاربر و کسب‌وکار، جزء فنی درگیر و شواهدی که می‌توانی اندازه‌گیری یا ثبت کنی؛ این نگاه مانع می‌شود هر مشکل را سریع به یک دستگاه یا یک نفر نسبت بدهی و کمک می‌کند وابستگی بین Client، Network، Identity، Server و Application را مرحله‌به‌مرحله بررسی کنی در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: برای کارشناس پشتیبانی، ثبت اطلاعات بخشی از حل مشکل است؛ زمان شروع، دامنه اثر، پیام خطا، تغییرات اخیر و نتیجه هر تست باید کوتاه و دقیق ثبت شوند؛ این اطلاعات هنگام ارجاع، تکرار رخداد یا بررسی علت اصلی ارزش پیدا می‌کنند؛ همچنین قبل از تغییری که می‌تواند سرویس را تحت تأثیر قرار دهد، وضعیت فعلی و راه بازگشت مشخص شود تا عیب‌یابی به مجموعه‌ای از آزمون‌های بدون کنترل تبدیل نشود

هر مشکل را به لایه درست نسبت بده

وقتی کاربر می‌گوید «سیستم من باز نمی‌شود»، ابتدا مشخص کن منظورش دستگاه است، حساب کاربری است یا نرم‌افزار؛ همین جمله مبهم می‌تواند به سه مسیر عیب‌یابی کاملاً متفاوت منجر شود اگر کاربر روی یک دستگاه دیگر با همان حساب کاربری مشکل ندارد، اطلاعات مهمی به دست آورده‌ای؛ اگر همان دستگاه با حساب کاربری کاربر دیگر سالم است، دوباره دامنه مشکل تغییر می‌کند؛ مقایسه کنترل‌شده یکی از ابزارهای قوی برای محدود کردن محدوده است در مراحل بعد یاد می‌گیری هر لایه را با ابزار مناسب تست کنی، اما از همین حالا عادت کن اسم دقیق چیزی را که خراب است مشخص کنی و از واژه کلی «سیستم» استفاده نکنی روش عیب‌یابی قابل اتکا از تعیین دامنه مشکل شروع می‌شود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویس‌ها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیه‌ها از کم‌ریسک‌ترین تست‌ها بررسی شوند؛ تغییر چند عامل هم‌زمان تشخیص علت را دشوار می‌کند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود

وابستگی بین حساب کاربری و منبع

داشتن حساب کاربری به معنی دسترسی به همه منابع نیست؛ ممکن است احراز هویت موفق باشد اما مجوز دسترسی اجازه ورود به یک پوشه اشتراکی را ندهد؛ این تفاوت در پشتیبانی روزانه بسیار رایج است همچنین یک نرم‌افزار ممکن است با حساب کاربری شخصی کاربر وارد شود اما در پشت صحنه حساب سرویس جداگانه‌ای برای ارتباط با پایگاه داده داشته باشد؛ بنابراین موفق بودن ورود کاربر، سلامت همه وابستگی‌ها را ثابت نمی‌کند وقتی مسیر دسترسی را می‌نویسی مشخص کن چه هویتی در هر بخش استفاده می‌شود؛ این کار هم در عیب‌یابی و هم در بررسی امنیتی ارزش زیادی دارد برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، برای کارشناس پشتیبانی، ثبت اطلاعات بخشی از حل مشکل است؛ زمان شروع، دامنه اثر، پیام خطا، تغییرات اخیر و نتیجه هر تست باید کوتاه و دقیق ثبت شوند؛ این اطلاعات هنگام ارجاع، تکرار رخداد یا بررسی علت اصلی ارزش پیدا می‌کنند؛ همچنین قبل از تغییری که می‌تواند سرویس را تحت تأثیر قرار دهد، وضعیت فعلی و راه بازگشت مشخص شود تا عیب‌یابی به مجموعه‌ای از آزمون‌های بدون کنترل تبدیل نشود

مثال محیط واقعی

کارمند جدید وارد شرکت شده و می‌گوید «سیستم ندارم». ممکن است دستگاه هنوز تحویل نشده باشد، حساب کاربری ساخته نشده باشد، نرم‌افزار نصب نشده باشد یا مجوز دسترسی پوشه‌ها تنظیم نشده باشد. یک جمله مبهم می‌تواند چند کار کاملاً متفاوت داشته باشد

اشتباهات رایج

این اشتباه‌ها را تکرار نکن

  • استفاده از کلمه «سیستم» برای همه چیز
  • ثبت درخواست پشتیبانی بدون مشخص کردن نام دستگاه یا نرم‌افزار
  • فرض اینکه مشکل حساب کاربری همان مشکل کامپیوتر است
  • نصب مجدد نرم‌افزار قبل از بررسی سرویس پشت آن
تمرین عملی

حالا خودت انجام بده

  1. برای محیط خودت پنج دستگاه، پنج نرم‌افزار و پنج سرویس فهرست کن
  2. یک درخواست مبهم مثل «سرور کار نمی‌کند» را به پنج سؤال دقیق تبدیل کن
  3. برای یک کاربر فرضی مشخص کن چه حساب کاربری‌هایی ممکن است داشته باشد
  4. برای یک پوشه اشتراکی بنویس کاربر، دستگاه، نرم‌افزار و سرویس مربوط چه چیزهایی هستند

نکته‌هایی که باید با خودت ببری

  • کاربر شخص است و حساب کاربری هویت دیجیتال
  • نرم‌افزار چیزی است که کاربر با آن کار می‌کند و سرویس می‌تواند پشت صحنه آن را پشتیبانی کند
  • دستگاه و منبع باید دقیق و قابل شناسایی باشند
خودسنجی

قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده

آیا اوت‌لوک یک سرویس است

خود اوت‌لوک یک نرم‌افزار است اما برای کار به سرویس‌های ایمیل و شبکه وابسته است

آیا هر حساب کاربری متعلق به انسان است

خیر، حساب سرویس‌ها برای سرویس‌ها و برنامه‌ها استفاده می‌شوند

مطالعه درس همیشه عمومی است

برای ذخیره پیشرفت، دوره را رسمی شروع کن

با ثبت‌نام، تکمیل درس‌ها و نمره آزمون روی حساب ذخیره می‌شود

ثبت‌نام و شروع رسمی