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