با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
فناوری اطلاعات فقط کامپیوتر نیست
وقتی در یک شرکت از فناوری اطلاعات صحبت میکنیم منظور مجموعهای از آدمها، تجهیزات، نرمافزارها، حسابهای کاربری، شبکه، سرورها، سرویسها، اطلاعات و روشهای کاری است که باعث میشوند کسبوکار بتواند با کمک فناوری کار کند یک کامپیوتر سالم بهتنهایی کافی نیست؛ همان کامپیوتر باید به شبکه متصل باشد، کاربر بتواند با حساب خودش وارد شود، فایلهای موردنیازش را ببیند، نرمافزار سازمانی اجرا شود، چاپگر در دسترس باشد و اطلاعات بهصورت امن نگهداری شوند در یک شرکت کوچک ممکن است یک نفر بخش بزرگی از این مسئولیتها را انجام دهد؛ در سازمان بزرگتر همین مسئولیتها بین میز خدمت، شبکه، سیستم، امنیت و نرمافزار تقسیم میشوند اما منطق مشترک این است که سرویس باید پایدار، امن و قابل پشتیبانی باشد نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که برای کارشناس پشتیبانی، ثبت اطلاعات بخشی از حل مشکل است؛ زمان شروع، دامنه اثر، پیام خطا، تغییرات اخیر و نتیجه هر تست باید کوتاه و دقیق ثبت شوند؛ این اطلاعات هنگام ارجاع، تکرار رخداد یا بررسی علت اصلی ارزش پیدا میکنند؛ همچنین قبل از تغییری که میتواند سرویس را تحت تأثیر قرار دهد، وضعیت فعلی و راه بازگشت مشخص شود تا عیبیابی به مجموعهای از آزمونهای بدون کنترل تبدیل نشود
کارشناس پشتیبانی دقیقاً چه کاری انجام میدهد
کارشناس پشتیبانی نقطه تماس کاربران با واحد فناوری اطلاعات است؛ او مشکل را دریافت میکند، اطلاعات درست جمع میکند، شدت و محدوده مشکل را تشخیص میدهد، بررسی اولیه انجام میدهد و تا رسیدن به نتیجه مسئول پیگیری است بخش مهم کار پشتیبانی پیشگیرانه است؛ بررسی وضعیت نسخه پشتیبان، ظرفیت فضای ذخیرهسازی، هشدارهای پایش، سلامت سرویسها، وضعیت تجهیزات و مستندات کمک میکند مشکل قبل از اینکه کاربر متوجه شود پیدا شود کارشناس حرفهای فقط نمیگوید «درست شد»؛ باید بداند چه چیزی خراب بود، چه تغییری انجام داد، نتیجه چگونه بررسی شد و اگر همان مشکل دوباره اتفاق افتاد نفر بعدی از کجا ادامه دهد اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، در محیط واقعی، ارزش پشتیبانی زمانی دیده میشود که سرویس قابل استفاده بماند و کاربر بداند چه اتفاقی افتاده است؛ برای همین همیشه مسئله را از سه زاویه ببین: اثر روی کاربر و کسبوکار، جزء فنی درگیر و شواهدی که میتوانی اندازهگیری یا ثبت کنی؛ این نگاه مانع میشود هر مشکل را سریع به یک دستگاه یا یک نفر نسبت بدهی و کمک میکند وابستگی بین Client، Network، Identity، Server و Application را مرحلهبهمرحله بررسی کنی
پشتیبانی خوب چه ویژگیهایی دارد
پشتیبانی خوب قابل پیشبینی، قابل پیگیری و کمریسک است؛ کاربر باید بداند درخواستش ثبت شده، چه کسی آن را بررسی میکند و در چه وضعیتی قرار دارد سرعت مهم است اما سرعت بدون روش میتواند خطرناک باشد؛ خاموش کردن یک سرویس، تغییر فایروال یا حذف فایل برای آزاد کردن فضا شاید سریع باشد اما اگر دلیل و اثر آن بررسی نشده باشد میتواند مشکل بزرگتری ایجاد کند هدف این دوره این است که یاد بگیری قبل از هر اقدام فکر کنی، شواهد جمع کنی، تغییر کنترلشده انجام بدهی و نتیجه را تأیید کنی در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: برای کارشناس پشتیبانی، ثبت اطلاعات بخشی از حل مشکل است؛ زمان شروع، دامنه اثر، پیام خطا، تغییرات اخیر و نتیجه هر تست باید کوتاه و دقیق ثبت شوند؛ این اطلاعات هنگام ارجاع، تکرار رخداد یا بررسی علت اصلی ارزش پیدا میکنند؛ همچنین قبل از تغییری که میتواند سرویس را تحت تأثیر قرار دهد، وضعیت فعلی و راه بازگشت مشخص شود تا عیبیابی به مجموعهای از آزمونهای بدون کنترل تبدیل نشود
یک روز کاری واقعی چه شکلی است
ممکن است صبح با بررسی هشدارهای شب گذشته شروع شود، بعد کاربر جدید برای حساب کاربری و دسترسی نیاز داشته باشد، یک چاپگر مشکل پیدا کند، اینترنت واحدی کند شود و عصر نسخه پشتیبان شبانه بررسی شود در تمام این کارها سه چیز مشترک است: فهم دقیق درخواست، اقدام کنترلشده و ثبت نتیجه؛ همین سه عادت ساده تفاوت زیادی بین کارشناس حرفهای و کار تصادفی ایجاد میکند اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، در محیط واقعی، ارزش پشتیبانی زمانی دیده میشود که سرویس قابل استفاده بماند و کاربر بداند چه اتفاقی افتاده است؛ برای همین همیشه مسئله را از سه زاویه ببین: اثر روی کاربر و کسبوکار، جزء فنی درگیر و شواهدی که میتوانی اندازهگیری یا ثبت کنی؛ این نگاه مانع میشود هر مشکل را سریع به یک دستگاه یا یک نفر نسبت بدهی و کمک میکند وابستگی بین Client، Network، Identity، Server و Application را مرحلهبهمرحله بررسی کنی در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: برای کارشناس پشتیبانی، ثبت اطلاعات بخشی از حل مشکل است؛ زمان شروع، دامنه اثر، پیام خطا، تغییرات اخیر و نتیجه هر تست باید کوتاه و دقیق ثبت شوند؛ این اطلاعات هنگام ارجاع، تکرار رخداد یا بررسی علت اصلی ارزش پیدا میکنند؛ همچنین قبل از تغییری که میتواند سرویس را تحت تأثیر قرار دهد، وضعیت فعلی و راه بازگشت مشخص شود تا عیبیابی به مجموعهای از آزمونهای بدون کنترل تبدیل نشود
مسیر دوره چگونه ساخته شده
در مراحل بعدی سختافزار، ویندوز، شبکه، IP، سوئیچینگ، مسیریابی، میکروتیک، ویندوز سرور، DNS، DHCP، سرور فایل، مجازیسازی، نسخه پشتیبان، امنیت، وایفای، لینوکس، پایش، سامانه ثبت درخواست، مستندسازی و عیبیابی را یاد میگیری هر مرحله روی دانش قبلی ساخته میشود؛ آزمون پایان هر مرحله فقط برای نمره نیست و مشخص میکند آیا پایه لازم برای رفتن به مرحله بعد را داری یا نه نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که در محیط واقعی، ارزش پشتیبانی زمانی دیده میشود که سرویس قابل استفاده بماند و کاربر بداند چه اتفاقی افتاده است؛ برای همین همیشه مسئله را از سه زاویه ببین: اثر روی کاربر و کسبوکار، جزء فنی درگیر و شواهدی که میتوانی اندازهگیری یا ثبت کنی؛ این نگاه مانع میشود هر مشکل را سریع به یک دستگاه یا یک نفر نسبت بدهی و کمک میکند وابستگی بین Client، Network، Identity، Server و Application را مرحلهبهمرحله بررسی کنی در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که برای کارشناس پشتیبانی، ثبت اطلاعات بخشی از حل مشکل است؛ زمان شروع، دامنه اثر، پیام خطا، تغییرات اخیر و نتیجه هر تست باید کوتاه و دقیق ثبت شوند؛ این اطلاعات هنگام ارجاع، تکرار رخداد یا بررسی علت اصلی ارزش پیدا میکنند؛ همچنین قبل از تغییری که میتواند سرویس را تحت تأثیر قرار دهد، وضعیت فعلی و راه بازگشت مشخص شود تا عیبیابی به مجموعهای از آزمونهای بدون کنترل تبدیل نشود
از دید کسبوکار به فناوری اطلاعات نگاه کن
برای یک مدیر، سالم بودن فناوری اطلاعات یعنی کار شرکت متوقف نشود؛ ممکن است از نظر فنی یک سرور روشن باشد اما اگر نرمافزار فروش نتواند به پایگاه داده وصل شود، از دید کسبوکار سرویس هنوز خراب است؛ بنابراین کارشناس پشتیبانی باید علاوه بر وضعیت تجهیزات، اثر مشکل روی کار واقعی کاربران را هم بفهمد وقتی یک رخداد گزارش میشود بپرس چه فرایندی متوقف شده است، چند نفر درگیر هستند، آیا راه جایگزین وجود دارد و تأخیر چه اثری دارد؛ این اطلاعات به تعیین اولویت کمک میکند و باعث میشود انرژی تیم روی مهمترین مسئله متمرکز شود در محیط حرفهای هدف نمایش دانش فنی نیست؛ هدف این است که با کمترین خطر سرویس به وضعیت پایدار برگردد؛ گاهی بهترین تصمیم این است که فعلاً راهحل موقت امن اجرا شود و علت اصلی در زمان مناسبتر بررسی شود اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، برای کارشناس پشتیبانی، ثبت اطلاعات بخشی از حل مشکل است؛ زمان شروع، دامنه اثر، پیام خطا، تغییرات اخیر و نتیجه هر تست باید کوتاه و دقیق ثبت شوند؛ این اطلاعات هنگام ارجاع، تکرار رخداد یا بررسی علت اصلی ارزش پیدا میکنند؛ همچنین قبل از تغییری که میتواند سرویس را تحت تأثیر قرار دهد، وضعیت فعلی و راه بازگشت مشخص شود تا عیبیابی به مجموعهای از آزمونهای بدون کنترل تبدیل نشود
عادتهایی که از روز اول باید بسازی
هر بار که مشکلی میبینی قبل از تغییر سه چیز را ثبت کن: وضعیت فعلی، نشانه دقیق و آخرین تغییری که ممکن است مرتبط باشد؛ همین عادت ساده در مراحل بعدی دوره بارها به کمک تو میآید هیچ دستور یا تغییر را فقط چون قبلاً جواب داده تکرار نکن؛ ابتدا مطمئن شو شرایط این رخداد با مورد قبلی یکسان است؛ دو مشکل با ظاهر مشابه میتوانند علت کاملاً متفاوت داشته باشند بعد از رفع مشکل از کاربر یا با تست فنی نتیجه را دوباره بررسی کن؛ سپس نتیجه را در درخواست پشتیبانی بنویس؛ وقتی این چرخه به عادت تبدیل شود، کار تو قابل اعتماد و قابل تحویل به نفر بعد خواهد بود برای عیبیابی درست، این بخش را فقط بهعنوان یک اصطلاح حفظ نکن و توجه داشته باش که در محیط واقعی، ارزش پشتیبانی زمانی دیده میشود که سرویس قابل استفاده بماند و کاربر بداند چه اتفاقی افتاده است؛ برای همین همیشه مسئله را از سه زاویه ببین: اثر روی کاربر و کسبوکار، جزء فنی درگیر و شواهدی که میتوانی اندازهگیری یا ثبت کنی؛ این نگاه مانع میشود هر مشکل را سریع به یک دستگاه یا یک نفر نسبت بدهی و کمک میکند وابستگی بین Client، Network، Identity، Server و Application را مرحلهبهمرحله بررسی کنی
فرض کن حسابداری میگوید نرمافزار مالی باز نمیشود. کارشناس تازهکار ممکن است فوراً نرمافزار را پاک و نصب کند. کارشناس حرفهای ابتدا میپرسد مشکل برای یک نفر است یا همه، شبکه در دسترس است یا نه، سرور نرمافزار فعال است یا نه، پیام خطا چیست و مشکل از چه زمانی شروع شده. همین چند سؤال مسیر عیبیابی را کاملاً عوض میکند
این اشتباهها را تکرار نکن
- شروع تغییر بدون اینکه مشکل را دقیق فهمیده باشی
- تمرکز روی اولین حدس و نادیده گرفتن شواهد
- بستن درخواست پشتیبانی فقط چون کاربر فعلاً میگوید مشکل ندارد
- انجام تغییر بدون ثبت آن
حالا خودت انجام بده
- محیط کاری خودت یا یک شرکت فرضی را تصور کن و فهرست کن چه تجهیزات و سرویسهایی برای کار روزانه لازم هستند
- برای سه مشکل «اینترنت قطع است»، «فایل باز نمیشود» و «چاپگر چاپ نمیکند» بنویس قبل از هر تغییر چه سؤالهایی میپرسی
- یک تعریف یکجملهای از وظیفه کارشناس پشتیبانی با زبان خودت بنویس
نکتههایی که باید با خودت ببری
- فناوری اطلاعات مجموعه تجهیزات، سرویسها، اطلاعات و روشهای کاری است نه فقط کامپیوتر
- کارشناس پشتیبانی باید مشکل را بفهمد، پیگیری کند، امن تغییر دهد و مستند کند
- پیشگیری و پایش بخشی از پشتیبانی حرفهای هستند
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
چرا جمله «کامپیوتر روشن است پس فناوری اطلاعات سالم است» اشتباه است
چون کاربر برای انجام کار به زنجیرهای از شبکه، حساب کاربری، سرویس، نرمافزار و اطلاعات وابسته است
بعد از رفع مشکل چه چیزی باید ثبت شود
شرح مشکل، علت یا یافته اصلی، اقدام انجامشده و نتیجه بررسی
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
