با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
اثر تعداد کاربر و اهمیت Process را میسنجد
اثر میزان اثر رخداد یا تغییر روی کاربران و فرایند کسبوکار است؛ تعداد کاربر تنها معیار نیست؛ اهمیت سرویس و وجود راه جایگزین هم مهم است اثر را با احساس فوریت فرد گزارشدهنده یکی ندان در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که اولویت با صدای بلندتر کاربر تعیین نمیشود؛ اثر بر کسبوکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشهای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست
Urgency سرعت نیاز به اقدام است
Urgency نشان میدهد مسئله چقدر زود باید رسیدگی شود؛ مثلاً Deadline نزدیک میتواند فوریت را بالا ببرد؛ اولویت معمولاً از Urgency در کنار اثر و قواعد سازمان ساخته میشود در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع میشود، نفر بعدی نباید مجبور باشد همه پرسشهای اولیه را از ابتدا تکرار کند برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که اولویت با صدای بلندتر کاربر تعیین نمیشود؛ اثر بر کسبوکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشهای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست
اولویت از اثر و Urgency ساخته میشود
اولویت مشخص میکند تیم با چه ترتیبی رسیدگی کند و معمولاً از اثر و Urgency ساخته میشود؛ خرابی برای مدیر مهم است اما معیار فنی باید یکسان باشد Severity فنی را با اولویت کسبوکاری یکی ندان در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع میشود، نفر بعدی نباید مجبور باشد همه پرسشهای اولیه را از ابتدا تکرار کند
Severity شدت فنی است
Severity شدت فنی رخداد را توصیف میکند، در حالی که اولویت ترتیب رسیدگی کسبوکاری است؛ یک مشکل فنی شدید ممکن است راه جایگزین داشته باشد و اولویت متفاوتی بگیرد در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع میشود، نفر بعدی نباید مجبور باشد همه پرسشهای اولیه را از ابتدا تکرار کند نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که اولویت با صدای بلندتر کاربر تعیین نمیشود؛ اثر بر کسبوکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشهای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست
فشار کاربر نباید معیار تنها باشد
اولویت باید از ترکیب اثر و Urgency ساخته شود، نه از صدای بلندتر کاربر؛ قطعی یک سرویس حیاتی برای چند بخش معمولاً از مشکل ظاهری یک فرد اولویت بالاتری دارد در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که اولویت با صدای بلندتر کاربر تعیین نمیشود؛ اثر بر کسبوکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشهای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست
فرض کن در میز خدمت و سامانه درخواستها مشکلی گزارش شده و احتمال میدهی به اولویت، Severity و اثر مربوط باشد. قبل از تغییر، وضعیت فعلی را با سامانه Ticketing، Queue، SLA و تاریخچه درخواست بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- تغییر دادن تنظیمات مرتبط با اولویت، Severity و اثر قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره اولویت، Severity و اثر فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با اولویت، Severity و اثر، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با سامانه Ticketing، Queue، SLA و تاریخچه درخواست وضعیت مرتبط با اولویت، Severity و اثر را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با اولویت، Severity و اثر بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- اثر تعداد کاربر و اهمیت Process را میسنجد
- Urgency سرعت نیاز به اقدام است
- اولویت از اثر و Urgency ساخته میشود
- Severity شدت فنی است
- فشار کاربر نباید معیار تنها باشد
- رمز و اطلاعات محرمانه را داخل Ticket عمومی ثبت نکن
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: اثر تعداد کاربر و اهمیت Process را میسنجد. بعد بگو در عمل چطور آن را بررسی میکنی.
اثر میزان اثر رخداد یا تغییر روی کاربران و فرایند کسبوکار است؛ تعداد کاربر تنها معیار نیست؛ اهمیت سرویس و وجود راه جایگزین هم مهم است
این نکته را با یک مثال توضیح بده: Urgency سرعت نیاز به اقدام است. بعد بگو در عمل چطور آن را بررسی میکنی.
Urgency نشان میدهد مسئله چقدر زود باید رسیدگی شود؛ مثلاً Deadline نزدیک میتواند فوریت را بالا ببرد. اولویت معمولاً از Urgency در کنار اثر و قواعد سازمان ساخته میشود
این نکته را با یک مثال توضیح بده: اولویت از اثر و Urgency ساخته میشود. بعد بگو در عمل چطور آن را بررسی میکنی.
اولویت مشخص میکند تیم با چه ترتیبی رسیدگی کند و معمولاً از اثر و Urgency ساخته میشود؛ خرابی برای مدیر مهم است اما معیار فنی باید یکسان باشد
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
