با حوصله بخوان، مثال‌ها را تحلیل کن و تمرین‌ها را انجام بده؛ هدف حفظ کردن تعریف‌ها نیست
زمان شروع مشکل را بپرس
زمان شروع را تا حد ممکن دقیق کن و بپرس آخرین بار چه زمانی سالم بوده است؛ این بازه برای مقایسه تغییر، Alert و Log بسیار ارزشمند است روش عیب‌یابی قابل اتکا از تعیین دامنه مشکل شروع می‌شود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویس‌ها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیه‌ها از کم‌ریسک‌ترین تست‌ها بررسی شوند؛ تغییر چند عامل هم‌زمان تشخیص علت را دشوار می‌کند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن می‌شود که ارتباط حرفه‌ای با مشتری یعنی مسئله فنی را بدون تحقیر، ابهام یا وعده غیرواقعی توضیح بدهی؛ ابتدا نشانه را با زبان خود کاربر بشنو، سپس سؤال‌های مشخص درباره زمان، دامنه و تغییر اخیر بپرس؛ هنگام توضیح، اصطلاح فنی را فقط جایی استفاده کن که به تصمیم یا اقدام کمک می‌کند و در صورت استفاده معنای ساده آن را هم روشن کن
دامنه افراد درگیر را بپرس
سؤال کن فقط خود کاربر، یک تیم، یک طبقه یا همه مشکل دارند؛ پاسخ محدوده را کوچک می‌کند و نشان می‌دهد باید از دستگاه فردی شروع کنی یا سرویس مشترک برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، ارتباط حرفه‌ای با مشتری یعنی مسئله فنی را بدون تحقیر، ابهام یا وعده غیرواقعی توضیح بدهی؛ ابتدا نشانه را با زبان خود کاربر بشنو، سپس سؤال‌های مشخص درباره زمان، دامنه و تغییر اخیر بپرس؛ هنگام توضیح، اصطلاح فنی را فقط جایی استفاده کن که به تصمیم یا اقدام کمک می‌کند و در صورت استفاده معنای ساده آن را هم روشن کن در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: در طول رخداد، حتی نبود نتیجه نهایی هم باید مدیریت شود؛ زمان به‌روزرسانی بعدی، کاری که در حال بررسی است و محدودیت فعلی را واضح بگو؛ بعد از رفع مشکل از کاربر بخواه نتیجه را در همان سناریویی که مشکل داشت تأیید کند و Closure را با خلاصه اقدام و راه پیشگیری در صورت وجود ثبت کن برای کامل شدن تصویر این موضوع، این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی
پیام خطا را دقیق بخواه
متن کامل پیام، Code و زمان خطا را ثبت کن؛ بازنویسی از حافظه ممکن است مهم‌ترین سرنخ را از بین ببرد روش عیب‌یابی قابل اتکا از تعیین دامنه مشکل شروع می‌شود: یک User یا چند User، یک Device یا یک Segment، یک Service یا همه سرویس‌ها؛ بعد باید تغییر اخیر و شواهد قابل مشاهده جمع شوند و فرضیه‌ها از کم‌ریسک‌ترین تست‌ها بررسی شوند؛ تغییر چند عامل هم‌زمان تشخیص علت را دشوار می‌کند؛ پس از رفع نیز باید سرویس از دید کاربر تأیید، علت ثبت و در صورت نیاز اقدام پیشگیرانه تعریف شود در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن می‌شود که ارتباط حرفه‌ای با مشتری یعنی مسئله فنی را بدون تحقیر، ابهام یا وعده غیرواقعی توضیح بدهی؛ ابتدا نشانه را با زبان خود کاربر بشنو، سپس سؤال‌های مشخص درباره زمان، دامنه و تغییر اخیر بپرس؛ هنگام توضیح، اصطلاح فنی را فقط جایی استفاده کن که به تصمیم یا اقدام کمک می‌کند و در صورت استفاده معنای ساده آن را هم روشن کن اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، در طول رخداد، حتی نبود نتیجه نهایی هم باید مدیریت شود؛ زمان به‌روزرسانی بعدی، کاری که در حال بررسی است و محدودیت فعلی را واضح بگو؛ بعد از رفع مشکل از کاربر بخواه نتیجه را در همان سناریویی که مشکل داشت تأیید کند و Closure را با خلاصه اقدام و راه پیشگیری در صورت وجود ثبت کن
آخرین تغییر را سؤال کن
پرسش درباره آخرین تغییر در دستگاه، رمز، شبکه یا نرم‌افزار می‌تواند Timeline را روشن کند؛ تغییر اخیر سرنخ است و باید با شواهد بررسی شود، نه اینکه فوراً مقصر اعلام شود Change Enablement بر این تأکید دارد که تغییر با ارزیابی ریسک، مجوز متناسب، زمان‌بندی، برنامه اجرا، معیار موفقیت و راه بازگشت کنترل شود؛ حتی تغییر کوچک اگر روی سرویس مشترک انجام شود می‌تواند دامنه اثر بزرگی داشته باشد؛ قبل از اجرا باید وضعیت فعلی ثبت شود، وابستگی‌ها شناخته شوند و بعد از تغییر هم آزمون فنی و تأیید کارکرد سرویس انجام شود؛ اگر شرایط از برنامه خارج شد، توقف و Rollback بخشی از اجرای حرفه‌ای است اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، ارتباط حرفه‌ای با مشتری یعنی مسئله فنی را بدون تحقیر، ابهام یا وعده غیرواقعی توضیح بدهی؛ ابتدا نشانه را با زبان خود کاربر بشنو، سپس سؤال‌های مشخص درباره زمان، دامنه و تغییر اخیر بپرس؛ هنگام توضیح، اصطلاح فنی را فقط جایی استفاده کن که به تصمیم یا اقدام کمک می‌کند و در صورت استفاده معنای ساده آن را هم روشن کن
راه جایگزین را برای اثر بررسی کن
اثر میزان اثر رخداد یا تغییر روی کاربران و فرایند کسب‌وکار است؛ تعداد کاربر تنها معیار نیست؛ اهمیت سرویس و وجود راه جایگزین هم مهم است اثر را با احساس فوریت فرد گزارش‌دهنده یکی ندان برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، ارتباط حرفه‌ای با مشتری یعنی مسئله فنی را بدون تحقیر، ابهام یا وعده غیرواقعی توضیح بدهی؛ ابتدا نشانه را با زبان خود کاربر بشنو، سپس سؤال‌های مشخص درباره زمان، دامنه و تغییر اخیر بپرس؛ هنگام توضیح، اصطلاح فنی را فقط جایی استفاده کن که به تصمیم یا اقدام کمک می‌کند و در صورت استفاده معنای ساده آن را هم روشن کن برای عیب‌یابی درست، این بخش را فقط به‌عنوان یک اصطلاح حفظ نکن و توجه داشته باش که در طول رخداد، حتی نبود نتیجه نهایی هم باید مدیریت شود؛ زمان به‌روزرسانی بعدی، کاری که در حال بررسی است و محدودیت فعلی را واضح بگو؛ بعد از رفع مشکل از کاربر بخواه نتیجه را در همان سناریویی که مشکل داشت تأیید کند و Closure را با خلاصه اقدام و راه پیشگیری در صورت وجود ثبت کن
فرض کن در ارتباط با کاربر یا مشتری مشکلی گزارش شده و احتمال می‌دهی به سؤال درست در پشتیبانی مربوط باشد. قبل از تغییر، وضعیت فعلی را با Ticket، یادداشت تماس، ایمیل و سابقه ارتباط بررسی می‌کنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه می‌کنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر می‌دهی و بعد همان تست را دوباره اجرا می‌کنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباه‌ها را تکرار نکن
- تغییر دادن تنظیمات مرتبط با سؤال درست در پشتیبانی قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجه‌گیری درباره سؤال درست در پشتیبانی فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با سؤال درست در پشتیبانی، فقط وضعیت فعلی را مشاهده کن و سه نکته‌ای را که برای تشخیص حالت سالم مهم‌اند یادداشت کن
- با Ticket، یادداشت تماس، ایمیل و سابقه ارتباط وضعیت مرتبط با سؤال درست در پشتیبانی را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو می‌گویند
- یک خطای فرضی مرتبط با سؤال درست در پشتیبانی بنویس و مشخص کن اولین تست کم‌خطر تو چیست و چه نتیجه‌ای فرضیه‌ات را رد می‌کند
نکته‌هایی که باید با خودت ببری
- زمان شروع مشکل را بپرس
- دامنه افراد درگیر را بپرس
- پیام خطا را دقیق بخواه
- آخرین تغییر را سؤال کن
- راه جایگزین را برای اثر بررسی کن
- چیزی را که هنوز مطمئن نیستی به‌عنوان نتیجه قطعی به کاربر اعلام نکن
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: زمان شروع مشکل را بپرس. بعد بگو در عمل چطور آن را بررسی می‌کنی.
زمان شروع را تا حد ممکن دقیق کن و بپرس آخرین بار چه زمانی سالم بوده است. این بازه برای مقایسه تغییر، Alert و Log بسیار ارزشمند است
این نکته را با یک مثال توضیح بده: دامنه افراد درگیر را بپرس. بعد بگو در عمل چطور آن را بررسی می‌کنی.
سؤال کن فقط خود کاربر، یک تیم، یک طبقه یا همه مشکل دارند. پاسخ محدوده را کوچک می‌کند و نشان می‌دهد باید از دستگاه فردی شروع کنی یا سرویس مشترک
این نکته را با یک مثال توضیح بده: پیام خطا را دقیق بخواه. بعد بگو در عمل چطور آن را بررسی می‌کنی.
متن کامل پیام، Code و زمان خطا را ثبت کن؛ بازنویسی از حافظه ممکن است مهم‌ترین سرنخ را از بین ببرد
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبت‌نام، تکمیل درس‌ها و نمره آزمون روی حساب ذخیره می‌شود
