با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
میز خدمت چه میکند
میز خدمت معمولاً اولین نقطه تماس کاربر است؛ دریافت درخواست پشتیبانی، ثبت اطلاعات، پاسخ به سؤالهای رایج، حل مشکلات ساده و هدایت درست درخواستها بخش اصلی کار آن است در بعضی شرکتها میز خدمت فقط ثبت و دستهبندی میکند و در بعضی شرکتها همان تیم بسیاری از مشکلات رایانه کاربر را هم حل میکند؛ عنوان شغلی همیشه همه چیز را مشخص نمیکند و باید محدوده واقعی تیم را دانست کارشناس میز خدمت باید بتواند از یک توضیح مبهم اطلاعات دقیق بیرون بکشد؛ مثلاً «اینترنت خرابه» را به این سؤالها تبدیل کند: برای یک نفر یا همه، کابل یا وایفای، از چه زمانی، آیا شبکه داخلی در دسترس است و چه پیامی دیده میشود در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد
پشتیبانی چه تفاوتی دارد
پشتیبانی معمولاً دامنه فنی گستردهتری دارد؛ نصب و عیبیابی ویندوز، نرمافزارها، چاپگر، دسترسیها، اتصال شبکه، پشتیبانی از راه دور و هماهنگی با تیمهای دیگر نمونههای آن است یک کارشناس پشتیبانی خوب باید از شبکه و سرور در حدی بداند که مشکل را درست طبقهبندی کند حتی اگر اجازه تغییر روی تجهیزات اصلی را نداشته باشد پشتیبانی خوب یعنی مسئولیت درخواست پشتیبانی تا رسیدن به نتیجه گم نشود؛ حتی وقتی درخواست پشتیبانی به سطح تخصصیتر ارجاع داده میشود، اطلاعات باید کامل باشد تا تیم بعدی دوباره همه سؤالها را از اول نپرسد در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، در محیط واقعی، ارزش پشتیبانی زمانی دیده میشود که سرویس قابل استفاده بماند و کاربر بداند چه اتفاقی افتاده است؛ برای همین همیشه مسئله را از سه زاویه ببین: اثر روی کاربر و کسبوکار، جزء فنی درگیر و شواهدی که میتوانی اندازهگیری یا ثبت کنی؛ این نگاه مانع میشود هر مشکل را سریع به یک دستگاه یا یک نفر نسبت بدهی و کمک میکند وابستگی بین Client، Network، Identity، Server و Application را مرحلهبهمرحله بررسی کنی
مدیر شبکه
مدیر شبکه بیشتر روی سوئیچ، مسیریاب، فایروال، وایفای، VLAN، مسیریابی، VPN، ارتباط با ISP و پایش شبکه تمرکز دارد وقتی مشکل نیازمند تغییر روی سوئیچ مرکزی یا فایروال است ممکن است کارشناس پشتیبانی فقط شواهد را جمع کند و درخواست پشتیبانی را همراه با اطلاعات درست به سطح تخصصیتر ارجاع بدهد کارشناس پشتیبانی قرار نیست بدون دانش کافی وارد تنظیمات شبکه شود، اما باید بتواند علائم را تشخیص دهد و تستهای اولیه کمریسک مثل بررسی IP، دروازه شبکه و مقایسه کاربران را انجام دهد در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: در محیط واقعی، ارزش پشتیبانی زمانی دیده میشود که سرویس قابل استفاده بماند و کاربر بداند چه اتفاقی افتاده است؛ برای همین همیشه مسئله را از سه زاویه ببین: اثر روی کاربر و کسبوکار، جزء فنی درگیر و شواهدی که میتوانی اندازهگیری یا ثبت کنی؛ این نگاه مانع میشود هر مشکل را سریع به یک دستگاه یا یک نفر نسبت بدهی و کمک میکند وابستگی بین Client، Network، Identity، Server و Application را مرحلهبهمرحله بررسی کنی
مدیر سیستم
مدیر سیستم معمولاً مسئول سرور، اکتیو دایرکتوری، سیاست گروهی، سرور فایل، سرویسهای ویندوز یا لینوکس، مجازیسازی، نسخه پشتیبان و بخشی از فضای ذخیرهسازی است در شرکتهای کوچک ممکن است شبکه و سیستم یک نفر باشند؛ در شرکتهای بزرگتر این حوزهها جدا میشوند و حتی نسخه پشتیبان، امنیت یا مجازیسازی تیم مستقل دارند برای کارشناس پشتیبانی شناخت نقش مدیر سیستم مهم است چون بسیاری از درخواستهای پشتیبانی کاربران در نهایت به حساب کاربری، مجوز دسترسی، DNS داخلی یا سرویسهای سرور مرتبط میشوند در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که در محیط واقعی، ارزش پشتیبانی زمانی دیده میشود که سرویس قابل استفاده بماند و کاربر بداند چه اتفاقی افتاده است؛ برای همین همیشه مسئله را از سه زاویه ببین: اثر روی کاربر و کسبوکار، جزء فنی درگیر و شواهدی که میتوانی اندازهگیری یا ثبت کنی؛ این نگاه مانع میشود هر مشکل را سریع به یک دستگاه یا یک نفر نسبت بدهی و کمک میکند وابستگی بین Client، Network، Identity، Server و Application را مرحلهبهمرحله بررسی کنی
محدوده و ارجاع به سطح تخصصیتر
محدوده یعنی محدوده مسئولیت، دسترسی و کاری که برای یک نقش یا قرارداد تعریف شده است؛ دانستن محدوده از اقدام ناخواسته روی سیستمی که مسئول آن نیستی جلوگیری میکند ارجاع به سطح تخصصیتر یعنی وقتی مشکل از سطح دانش، دسترسی، زمان یا مسئولیت تو خارج است آن را با اطلاعات کامل به فرد یا تیم مناسب ارجاع دهی؛ ارجاع به سطح تخصصیتر نشانه ضعف نیست ارجاع به سطح تخصصیتر خوب باید بگوید چه چیزی خراب است، چه کسانی تحت تأثیرند، از چه زمانی، چه تستهایی انجام شده، نتیجه چه بوده و چرا به تیم بعدی نیاز است در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد
سطحبندی پشتیبانی
بعضی سازمانها از سطح ۱، سطح ۲ و سطح ۳ استفاده میکنند؛ سطح ۱ مشکلات پرتکرار و بررسی اولیه را انجام میدهد، سطح ۲ بررسی عمیقتر دارد و سطح ۳ معمولاً متخصص همان فناوری یا شرکت سازنده یا ارائهدهنده است هدف سطحبندی پاس دادن کاربر بین تیمها نیست؛ هدف این است که مشکل سریع به سطحی برسد که ابزار، دسترسی و دانش حل آن را دارد در یک تیم کوچک ممکن است این سطحها روی کاغذ وجود نداشته باشند، ولی منطق آن همچنان مفید است: هرکس باید بداند کجا میتواند مستقل اقدام کند و کجا باید کمک بگیرد در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد
مرز نقشها در شرکتهای کوچک و بزرگ
در یک شرکت کوچک ممکن است یک نفر هم میز خدمت باشد، هم شبکه را مدیریت کند و هم ویندوز سرور را نگه دارد؛ این موضوع نقشها را حذف نمیکند؛ فقط چند نقش روی یک نفر قرار گرفتهاند؛ باید بدانی در هر لحظه با کدام مسئولیت روبهرو هستی در سازمان بزرگتر دسترسیها تفکیک میشوند؛ میز خدمت ممکن است اجازه بازنشانی رمز عبور داشته باشد اما اجازه تغییر روی فایروال نداشته باشد؛ شبکه تیم ممکن است روی مسیریابی کار کند ولی مالک پایگاه داده نباشد؛ این تفکیک برای امنیت و کنترل خطر مهم است وقتی محدوده نقش خودت را میدانی، ارجاع به سطح تخصصیتر نشانه ضعف نیست؛ برعکس، یعنی تشخیص دادهای ادامه کار نیاز به دانش یا اختیار دیگری دارد و قبل از ایجاد آسیب، موضوع را درست منتقل کردهای در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد
یک ارجاع به سطح تخصصیتر خوب چه اطلاعاتی دارد
ارجاع خوب نباید فقط یک جمله مثل «کار نمیکند» باشد؛ باید بنویسی چه کسی مشکل دارد، نشانه چیست، از چه زمانی شروع شده، چه بخشهایی سالم هستند، چه تستهایی انجام شده و نتیجه هر تست چه بوده است اگر تغییر مرتبطی وجود داشته، زمان و شرح آن را اضافه کن؛ اگر گزارش رویداد یا تصویر صفحه مفیدی داری، آن را همراه درخواست پشتیبانی بفرست؛ هدف این است که تیم بعدی مجبور نباشد از صفر همان سؤالها را دوباره بپرسد بعد از ارجاع به سطح تخصصیتر هم مالکیت پیگیری را فراموش نکن؛ ممکن است حل فنی با تیم دیگری باشد اما کاربر همچنان نیاز دارد بداند وضعیت درخواستش چیست و چه زمانی بهروزرسانی بعدی دریافت میکند در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد
کاربر VPN وصل نمیشود. سطح ۱ اطلاعات حساب کاربری، اینترنت کاربر و پیام خطا را بررسی میکند. اگر چند کاربر همزمان همین مشکل را دارند و شواهد به فایروال اشاره میکند، درخواست پشتیبانی با زمان شروع، کاربران درگیر، تستهای انجامشده و پیام خطا به مدیر شبکه ارجاع میشود
این اشتباهها را تکرار نکن
- تغییر تنظیمات خارج از محدوده بدون هماهنگی
- ارجاع به سطح تخصصیتر با جمله «کار نکرد» و بدون شواهد
- نگه داشتن طولانی درخواست پشتیبانی فقط برای اینکه خودت حتماً آن را حل کنی
- دادن دسترسی مدیریتی به خودت فقط برای اینکه سریعتر مشکل را بررسی کنی
حالا خودت انجام بده
- برای پنج مشکل رایج مشخص کن اولین تیم مسئول کدام است
- یک نمونه ارجاع به سطح تخصصیتر خوب بنویس که شامل مشکل، اثر، تستها و نتیجه باشد
- محدوده شغلی فرضی خودت را در پنج خط بنویس
- یک درخواست پشتیبانی بنویس که سطح ۱ بررسی کرده اما برای سطح ۲ آماده ارسال است
نکتههایی که باید با خودت ببری
- عنوان شغلی مهم است اما محدوده واقعی مهمتر است
- ارجاع به سطح تخصصیتر باید همراه اطلاعات کافی باشد
- کارشناس پشتیبانی باید بتواند مشکل را طبقهبندی کند حتی اگر حل نهایی با تیم دیگری باشد
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
چه زمانی ارجاع به سطح تخصصیتر لازم است
وقتی مشکل خارج از دانش، دسترسی، مسئولیت یا زمان قابل قبول تو باشد و ادامه کار بدون کمک خطر ایجاد کند
آیا ارجاع به سطح تخصصیتر یعنی شکست
خیر، بخشی از فرآیند حرفهای پشتیبانی است
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
