درس ۲ از ۱۰

رخداد، Service Request و Problem

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

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

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

رخداد اختلال سرویس است

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

Service Request درخواست استاندارد است

Service Request معمولاً برای دریافت چیزی از پیش تعریف‌شده مثل ساخت حساب، نصب نرم‌افزار مجاز یا دسترسی استاندارد است و با رخداد که اختلال سرویس است فرق دارد در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری می‌شود و Service Request معمولاً درخواست از پیش تعریف‌شده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافق‌شده برای سطح خدمت را مشخص می‌کند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجام‌شده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع می‌شود، نفر بعدی نباید مجبور باشد همه پرسش‌های اولیه را از ابتدا تکرار کند در کار روزمره بهتر است این موضوع را این‌طور بررسی کنی: اولویت با صدای بلندتر کاربر تعیین نمی‌شود؛ اثر بر کسب‌وکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشه‌ای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست

Problem علت زیربنایی رخدادها را بررسی می‌کند

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

نوع Ticket فرایند را مشخص می‌کند

تشخیص درست نوع درخواست مشخص می‌کند چه فرایندی دنبال شود؛ رخداد برای اختلال، Service Request برای درخواست معمول و Problem برای بررسی علت تکرارشونده کاربرد متفاوت دارند در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری می‌شود و Service Request معمولاً درخواست از پیش تعریف‌شده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافق‌شده برای سطح خدمت را مشخص می‌کند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجام‌شده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع می‌شود، نفر بعدی نباید مجبور باشد همه پرسش‌های اولیه را از ابتدا تکرار کند برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، اولویت با صدای بلندتر کاربر تعیین نمی‌شود؛ اثر بر کسب‌وکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشه‌ای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست

خرابی تکراری نیاز Problem Management دارد

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

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

فرض کن در میز خدمت و سامانه درخواست‌ها مشکلی گزارش شده و احتمال می‌دهی به رخداد، Service Request و Problem مربوط باشد. قبل از تغییر، وضعیت فعلی را با سامانه Ticketing، Queue، SLA و تاریخچه درخواست بررسی می‌کنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه می‌کنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر می‌دهی و بعد همان تست را دوباره اجرا می‌کنی تا مطمئن شوی مشکل واقعاً برطرف شده است

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

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

  • تغییر دادن تنظیمات مرتبط با رخداد، Service Request و Problem قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
  • نتیجه‌گیری درباره رخداد، Service Request و Problem فقط از روی یک نشانه و بدون انجام تست نهایی
تمرین عملی

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

  1. در یک نمونه آزمایشی مرتبط با رخداد، Service Request و Problem، فقط وضعیت فعلی را مشاهده کن و سه نکته‌ای را که برای تشخیص حالت سالم مهم‌اند یادداشت کن
  2. با سامانه Ticketing، Queue، SLA و تاریخچه درخواست وضعیت مرتبط با رخداد، Service Request و Problem را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو می‌گویند
  3. یک خطای فرضی مرتبط با رخداد، Service Request و Problem بنویس و مشخص کن اولین تست کم‌خطر تو چیست و چه نتیجه‌ای فرضیه‌ات را رد می‌کند

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

  • رخداد اختلال سرویس است
  • Service Request درخواست استاندارد است
  • Problem علت زیربنایی رخدادها را بررسی می‌کند
  • نوع Ticket فرایند را مشخص می‌کند
  • خرابی تکراری نیاز Problem Management دارد
  • رمز و اطلاعات محرمانه را داخل Ticket عمومی ثبت نکن
خودسنجی

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

این نکته را با یک مثال توضیح بده: رخداد اختلال سرویس است. بعد بگو در عمل چطور آن را بررسی می‌کنی.

رخداد اختلال یا کاهش کیفیت یک سرویس است و هدف اولیه بازگرداندن سرویس است؛ یک راه‌حل موقت امن می‌تواند قبل از علت اصلی استفاده شود

این نکته را با یک مثال توضیح بده: Service Request درخواست استاندارد است. بعد بگو در عمل چطور آن را بررسی می‌کنی.

Service Request معمولاً برای دریافت چیزی از پیش تعریف‌شده مثل ساخت حساب، نصب نرم‌افزار مجاز یا دسترسی استاندارد است و با رخداد که اختلال سرویس است فرق دارد

این نکته را با یک مثال توضیح بده: Problem علت زیربنایی رخدادها را بررسی می‌کند. بعد بگو در عمل چطور آن را بررسی می‌کنی.

Problem علت یا علت‌های احتمالی یک یا چند رخداد را بررسی می‌کند؛ رخداد تکراری باید از حالت رفع موقت خارج و ریشه‌ای بررسی شود

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

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

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

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