با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
قبل از Close نتیجه تأیید شود
قبل از بستن Ticket همان سناریوی کاربر را بررسی نهایی کن و در صورت سیاست سازمان تأیید کاربر را بگیر؛ صرف اینکه Error در Console ناپدید شده برای Closure کافی نیست در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که اولویت با صدای بلندتر کاربر تعیین نمیشود؛ اثر بر کسبوکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشهای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست
Resolution Note علت و اقدام را ثبت کند
Resolution Note باید علت یا یافته، اقدام انجامشده و وضعیت نهایی را خلاصه کند تا کاربر و تیم بعدی بفهمند چرا Ticket بسته شده است در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که اولویت با صدای بلندتر کاربر تعیین نمیشود؛ اثر بر کسبوکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشهای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست
راهحل موقت با Fix دائمی فرق دارد
راهحل موقت با Fix دائمی فرق دارد راهحل موقت سرویس را موقتاً قابل استفاده میکند ولی علت را برطرف نمیکند؛ Fix دائمی باید علت یا شرایط ایجاد مشکل را حل کند و بعد بررسی نهایی شود در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، اولویت با صدای بلندتر کاربر تعیین نمیشود؛ اثر بر کسبوکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشهای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست
Reopen بالا نشانه Closure ضعیف است
اگر Ticketها زیاد دوباره باز میشوند ممکن است بررسی نهایی ناقص، ارتباط پایان کار ضعیف یا Fix موقت وجود داشته باشد؛ نرخ Reopen را بهعنوان نشانه کیفیت فرایند بررسی کن در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع میشود، نفر بعدی نباید مجبور باشد همه پرسشهای اولیه را از ابتدا تکرار کند اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، اولویت با صدای بلندتر کاربر تعیین نمیشود؛ اثر بر کسبوکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشهای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست
Solution تکراری میتواند Knowledge Article شود
وقتی یک راهحل معتبر چند بار تکرار میشود میتوان آن را به مقاله دانش تبدیل کرد؛ مقاله باید شرط استفاده، مراحل، خطر و روش بررسی نهایی را داشته باشد در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، اولویت با صدای بلندتر کاربر تعیین نمیشود؛ اثر بر کسبوکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشهای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع میشود، نفر بعدی نباید مجبور باشد همه پرسشهای اولیه را از ابتدا تکرار کند
فرض کن در میز خدمت و سامانه درخواستها مشکلی گزارش شده و احتمال میدهی به بررسی نهایی و Closing Ticket مربوط باشد. قبل از تغییر، وضعیت فعلی را با سامانه Ticketing، Queue، SLA و تاریخچه درخواست بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- قبل از بستن Ticket همان سناریوی کاربر را بررسی نهایی کن و در صورت سیاست سازمان تأیید کاربر را بگیر. صرف اینکه Error در Console ناپدید شده برای Closure کافی نیست
- تغییر دادن تنظیمات مرتبط با بررسی نهایی و Closing Ticket قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره بررسی نهایی و Closing Ticket فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با بررسی نهایی و Closing Ticket، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با سامانه Ticketing، Queue، SLA و تاریخچه درخواست وضعیت مرتبط با بررسی نهایی و Closing Ticket را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با بررسی نهایی و Closing Ticket بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- قبل از Close نتیجه تأیید شود
- Resolution Note علت و اقدام را ثبت کند
- راهحل موقت با Fix دائمی فرق دارد
- Reopen بالا نشانه Closure ضعیف است
- Solution تکراری میتواند Knowledge Article شود
- رمز و اطلاعات محرمانه را داخل Ticket عمومی ثبت نکن
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: قبل از Close نتیجه تأیید شود. بعد بگو در عمل چطور آن را بررسی میکنی.
قبل از بستن Ticket همان سناریوی کاربر را بررسی نهایی کن و در صورت سیاست سازمان تأیید کاربر را بگیر. صرف اینکه Error در Console ناپدید شده برای Closure کافی نیست
این نکته را با یک مثال توضیح بده: Resolution Note علت و اقدام را ثبت کند. بعد بگو در عمل چطور آن را بررسی میکنی.
Resolution Note باید علت یا یافته، اقدام انجامشده و وضعیت نهایی را خلاصه کند تا کاربر و تیم بعدی بفهمند چرا Ticket بسته شده است
این نکته را با یک مثال توضیح بده: راهحل موقت با Fix دائمی فرق دارد. بعد بگو در عمل چطور آن را بررسی میکنی.
راهحل موقت سرویس را موقتاً قابل استفاده میکند ولی علت را برطرف نمیکند؛ Fix دائمی باید علت یا شرایط ایجاد مشکل را حل کند و بعد بررسی نهایی شود
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
