با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
درخواست پشتیبانی چیست
درخواست پشتیبانی ثبت رسمی یک رخداد یا درخواست خدمت است؛ باید مشخص کند چه کسی درخواست داده، مشکل چیست، چه زمانی شروع شده، چه اثری دارد و چه اقدامهایی انجام شده است درخواست پشتیبانی حافظه تیم است؛ اگر همه چیز در تماس تلفنی یا پیام شخصی بماند نفر بعدی از سابقه کار بیخبر است عنوان درخواست پشتیبانی باید قابل جستوجو باشد. «مشکل سیستم» عنوان ضعیفی است اما «عدم دسترسی کاربر فروش به پوشه اشتراکی» موضوع را روشنتر میکند در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد مستندسازی زیرساخت باید آنقدر دقیق باشد که وضعیت فعلی را بدون تکیه به حافظه افراد بازسازی کند؛ Inventory داراییها، Diagram ارتباطات، IP Plan، VLANها، نقش Serverها، مسیر Backup، وابستگی سرویسها و تاریخچه تغییرات هر کدام بخشی از تصویر هستند؛ اطلاعات Credential بهتر است در محل امن و جدا از سند عمومی زیرساخت نگهداری شود؛ هر تغییر مهم نیز باید بعد از اجرا در مستندات منعکس شود تا سند با محیط واقعی فاصله نگیرد
رخداد و درخواست خدمت
رخداد یعنی سرویس مطابق انتظار کار نمیکند؛ مثلاً اینترنت قطع است؛ درخواست خدمت درخواست معمول مثل ساخت حساب کاربری جدید یا نصب نرمافزار مجاز است تفکیک این دو به گزارشدهی، اولویت و روند کاری کمک میکند درخواست تغییر هم ممکن است فرایند جدا داشته باشد چون خطر و تأیید آن با رخداد متفاوت است در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد مستندسازی زیرساخت باید آنقدر دقیق باشد که وضعیت فعلی را بدون تکیه به حافظه افراد بازسازی کند؛ Inventory داراییها، Diagram ارتباطات، IP Plan، VLANها، نقش Serverها، مسیر Backup، وابستگی سرویسها و تاریخچه تغییرات هر کدام بخشی از تصویر هستند؛ اطلاعات Credential بهتر است در محل امن و جدا از سند عمومی زیرساخت نگهداری شود؛ هر تغییر مهم نیز باید بعد از اجرا در مستندات منعکس شود تا سند با محیط واقعی فاصله نگیرد
اولویت و اثر
اولویت باید با اثر و فوریت سنجیده شود نه فقط با صدای بلندتر کاربر؛ قطع سرویس برای کل شرکت معمولاً اولویت بالاتری از مشکل شخصی یک چاپگر دارد با این حال نقش کاربر و فرایند کسبوکار هم مهم است؛ مشکل یک سیستم پرداخت ممکن است کاربران کمی داشته باشد اما اثر مالی زیادی ایجاد کند اولویت باید بر اساس ماتریس یا قانون مشخص تیم تعیین شود تا تصمیمها قابل دفاع و یکسان باشند در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد مستندسازی زیرساخت باید آنقدر دقیق باشد که وضعیت فعلی را بدون تکیه به حافظه افراد بازسازی کند؛ Inventory داراییها، Diagram ارتباطات، IP Plan، VLANها، نقش Serverها، مسیر Backup، وابستگی سرویسها و تاریخچه تغییرات هر کدام بخشی از تصویر هستند؛ اطلاعات Credential بهتر است در محل امن و جدا از سند عمومی زیرساخت نگهداری شود؛ هر تغییر مهم نیز باید بعد از اجرا در مستندات منعکس شود تا سند با محیط واقعی فاصله نگیرد
SLA
SLA سطح سرویس توافقشده است و میتواند زمان پاسخ یا هدف راهحل را مشخص کند. SLA به معنی قول غیرواقعی نیست؛ معیار مشترکی برای انتظار و پیگیری است اگر درخواست پشتیبانی در خطر عبور از SLA است باید زودتر ارجاع داده شود یا درباره وضعیت آن اطلاعرسانی شود SLA ممکن است بر اساس اولویت متفاوت باشد؛ رخداد بحرانی انتظار پاسخ سریعتری از درخواست عادی دارد در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد مستندسازی زیرساخت باید آنقدر دقیق باشد که وضعیت فعلی را بدون تکیه به حافظه افراد بازسازی کند؛ Inventory داراییها، Diagram ارتباطات، IP Plan، VLANها، نقش Serverها، مسیر Backup، وابستگی سرویسها و تاریخچه تغییرات هر کدام بخشی از تصویر هستند؛ اطلاعات Credential بهتر است در محل امن و جدا از سند عمومی زیرساخت نگهداری شود؛ هر تغییر مهم نیز باید بعد از اجرا در مستندات منعکس شود تا سند با محیط واقعی فاصله نگیرد
محدوده
محدوده مشخص میکند چه سرویسها، دستگاهها، محلها یا کارهایی در مسئولیت تیم یا قرارداد هستند درخواست خارج از محدوده نباید نادیده گرفته شود؛ باید واضح ثبت و به مسیر درست هدایت شود وقتی محدوده مبهم است قبل از تغییر مهم از مسئول یا مدیر تأیید بگیر در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد مستندسازی زیرساخت باید آنقدر دقیق باشد که وضعیت فعلی را بدون تکیه به حافظه افراد بازسازی کند؛ Inventory داراییها، Diagram ارتباطات، IP Plan، VLANها، نقش Serverها، مسیر Backup، وابستگی سرویسها و تاریخچه تغییرات هر کدام بخشی از تصویر هستند؛ اطلاعات Credential بهتر است در محل امن و جدا از سند عمومی زیرساخت نگهداری شود؛ هر تغییر مهم نیز باید بعد از اجرا در مستندات منعکس شود تا سند با محیط واقعی فاصله نگیرد
کار گزارش رویداد
هر بررسی و تغییر مهم را در درخواست پشتیبانی ثبت کن: چه چیزی بررسی شد، نتیجه چه بود، چه تغییری انجام شد و بعد از آن بعد از آن چه نتیجهای به دست آمد جمله «بررسی شد و درست شد» برای رخداد جدی کافی نیست و هیچ دانشی برای آینده باقی نمیگذارد زمان ثبت و نام فرد اجراکننده در تغییرهای مهم ارزش زیادی دارند پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد
بستن درست
قبل از بستن، نتیجه فنی را دوباره بررسی کن و در صورت نیاز تأیید کاربر را بگیر؛ اگر فقط راهحل موقت داری وضعیت را طوری ثبت کن که علت اصلی فراموش نشود بستن یادداشت باید کوتاه اما مفید باشد: علت اصلی یا یافته، اقدام و نتیجه نهایی در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد مستندسازی زیرساخت باید آنقدر دقیق باشد که وضعیت فعلی را بدون تکیه به حافظه افراد بازسازی کند؛ Inventory داراییها، Diagram ارتباطات، IP Plan، VLANها، نقش Serverها، مسیر Backup، وابستگی سرویسها و تاریخچه تغییرات هر کدام بخشی از تصویر هستند؛ اطلاعات Credential بهتر است در محل امن و جدا از سند عمومی زیرساخت نگهداری شود؛ هر تغییر مهم نیز باید بعد از اجرا در مستندات منعکس شود تا سند با محیط واقعی فاصله نگیرد
درخواست پشتیبانی باید داستان رخداد را قابل بازسازی کند
فردی که فردا درخواست پشتیبانی را میخواند باید بتواند بفهمد چه اتفاقی افتاده است بدون اینکه دوباره از کاربر همه چیز را بپرسد؛ زمان شروع، نشانه، اثر، دستگاه یا سرویس، اقدامات و نتیجه تستها را واضح ثبت کن از جملههای مبهم مثل «بررسی شد» یا «اوکی شد» پرهیز کن؛ بنویس چه چیزی بررسی شد و نتیجه چه بود؛ مثلاً «رایانه کاربر از DHCP IP گرفت اما DNS نام سرور را رفع نکرد» اطلاعات قابل استفاده میدهد اگر درخواست پشتیبانی به تیم دیگر میرود، همین مستندسازی سرعت ارجاع به سطح تخصصیتر را بالا میبرد و از تکرار کار جلوگیری میکند در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد
SLA را با کیفیت اشتباه نگیر
رسیدن به زمان SLA مهم است اما نباید باعث تغییر خطرناک شود؛ اگر برای حل امن به زمان یا تیم دیگری نیاز است، قبل از نقض SLA بهروزرسانی و ارجاع به سطح تخصصیتر انجام بده اولویت باید بر اساس قواعد مشخص باشد؛ کاربر مهم یا صدای بلندتر همیشه به معنی اولویت بالاتر نیست؛ اثر و فوریت را با اطلاعات واقعی بسنج وقتی محدوده درخواست تغییر میکند، آن را ثبت کن؛ ممکن است درخواست پشتیبانی با مشکل چاپگر شروع شود اما در بررسی مشخص شود سوئیچ واحد مشکل دارد؛ حالا اثر و مسیر رسیدگی عوض شده است در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد
اینترنت یک واحد قطع شده. درخواست پشتیبانی خوب مینویسد: «از ساعت ۰۹:۲۰ پنج کاربر واحد فروش اینترنت ندارند، شبکه داخلی و سرور فایل در دسترس است، دروازه شبکه پاسخ میدهد، DNS نامها را رفع میکند، روی فایروال تغییر جدیدی ثبت نشده و بررسی ISP در حال انجام است»
این اشتباهها را تکرار نکن
- نوشتن عنوان «سیستم خرابه»
- ثبت نکردن زمان شروع
- تغییر درخواست پشتیبانی به بسته بدون بررسی نهایی
- قول زمان حل خارج از SLA و بدون بررسی
- ثبت نکردن بررسیهای ناموفق
حالا خودت انجام بده
- سه درخواست پشتیبانی بد را بهعنوان و شرح دقیقتر تبدیل کن
- برای سه رخداد مختلف اولویت پیشنهادی و دلیل بنویس
- یک کار گزارش رویداد پنجمرحلهای برای مشکل چاپگر بنویس
- یک بستن یادداشت مناسب برای قطعی DNS بنویس
نکتههایی که باید با خودت ببری
- درخواست پشتیبانی باید مشکل، اثر، زمان و اقدامها را ثبت کند
- اولویت بر اساس اثر و فوریت تعیین میشود
- SLA و محدوده انتظار و مسئولیت را روشن میکنند
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
چرا درخواست پشتیبانی فقط برای آمار نیست
چون سابقه فنی، ارتباطات و اقدامها را برای پیگیری و یادگیری تیم نگه میدارد
اولویت را چه چیزی تعیین میکند
ترکیبی از اثر، فوریت و اهمیت سرویس برای کسبوکار
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
