کتابخانه زیربنایی فناوری اطلاعات: تفاوت میان نسخه‌ها

محتوای حذف‌شده محتوای افزوده‌شده
AliBot (بحث | مشارکت‌ها)
جز ربات:صفحه یتیم، افزودن الگو
AliBot (بحث | مشارکت‌ها)
جز ربات:اصلاح فاصلهٔ مجازی
خط ۱۵:
در برخی موارد راهنماها به کلی از بین رفتند. CCTA IT Security و Privacy group وارد شدن CCTA IT Security Library را به GITMM فراهم کردند، اما Security Service وقتی که CCTA از بازی خارج شد امور این بخش را به عهده گرفت و در ادامه جنگی که بر سر مسئولیت‌های امنیتی داشتند، ادامه کار را متوقف کرد.
 
همچنان که در دهه ۸۰ میلادی ITIL توسعه پیدا می‌کرد، به دلایلی که در بالا بدان‌ها اشاره شد، تا میانه دهه ۹۰ میلادی آداپته نشد. این زمان زیاد آداپته شدن و آگاهی‌های بدست آمده، منجر به ایجاد تعدادی استاندارد شد، که شامل ISO/IEC ۲۰۰۰۰، که در برگیرنده و معرف استاندارد بین المللیبین‌المللی IT Service Management هست نیز می‌باشد.ITIL اغلب در کنار دیگر تجربیات موفق (Best Practice) مانند Information Service Procurement Library – ISPL و Application Services Library – ASL و Dynamic Systems Development Method – DSDM و Capability Maturity Model – CMM / CMMI قرار می‌گیرد. و اغلب بوسیله Control Objectives for Informayion and Related Technology – COBIT با موسسات IT دولتی (‌وابسته به دولت) پیوند داده می‌شود.
در ماه دسامبر (آذر) ۲۰۰۵ میلادی OGC یک بازنگری در ITIL انجام داد که به ITIL v۳ یا نسخه سوم ITIL مشهور شده‌است و در ماه May (خرداد) ۲۰۰۷ در دسترس عموم قرار گرفت. نسخه سوم ITIL پنج نقطه مرکزی دارد: #Service Strategy — استراتژی سرویس
# Service Design – طراحی سرویس
خط ۲۹:
خارج از ITIL دیدگاه‌های دیگر IT Service Management و زیربناها (Frameworks) وجود دارند که شامل ; کتابخانه Enterprise Computing Institute’s است که دربرگیرنده مسایل (Issue) عمومی (General) در سطح کلان مدیریت IT است.
 
The British Educational Communications and Technology Agency – BECTA زیربنای پشتیبانی تکنیکی فن آوری اطلاعات و ارتباطات، (FITS - Framework for ICT Technical Support ) را که بر اساس ITIL است را توسعه داد، اما فقط برای مدارس اصلی و ثانویه انگلیس (که معمولامعمولاً دارای واحدهای IT کوچک بودند) مورد استفاده قرار گرفت. بطور مشابه The Visible OPS Handbook: Implementing ITIL in ۴ Practical and Auditable Steps که بر اساس ITIL بود، بطور خاص بر روی بزرگترین المان‌های bang for the buck متمرکز شد.
 
سازمان‌هایی که لازم دارند تا بدانند که فرایند ITIL چگونه به رنج بیشتر فرآیندهای IT لینک (متصل) می‌شود و یا آنها که نیاز سطح وظیفه (Task Level) برای راهنمایی پیاده سازی مدیریت سرویس دارند می‌توانند ازIBM Tivoli Unified Process – ITUP استفاده نمایند، ITUP هم مانند MOF، هم بر اسا ITIL طراحی شده اما یک فرآیند یکپارچگی مدل (Integrated Process Model) کامل را معرفی می‌کند.
خط ۲۰۰:
 
* Call Center (مرکز تماس) : تاکید اصلی بر روی رسیدگی به پاسخگویی به تعداد بسیار زیادی از تماس‌های تلفنی است.
* Help Desk (پیش‌خوان کمک و یاری [ برنامه پشتیبانی ]) : مدیریت، هماهنگی، رسیدگی و رفع مشکلات مربوط به رخدادها در سریع ترینسریع‌ترین زمان ممکن.
* Service Desk (پیش‌خوان سرویس) : فقط به رخدادها، مشکلات و پرسش‌ها رسیدگی نمی‌کند، بلکه علاوه اینها یک واسط برای سایر فعالیت‌ها مانند درخواست‌های تغییر، قراردادهای نگهداری، مجوزهای نرم‌افزار (Software Licenses )، مدیریت سطح سرویس (Service Level Management )، مدیریت پیکربندی (Configuration Management )، مدیریت موجودی (Availability Management )، مدیریت مالی (Financial Management) و مدیریت بهبود مداوم سرویس‌های فن‌اوری اطلاعات (IT Services Continuity Management ) فراهم می‌کند.
 
خط ۲۲۱:
هر رخدادی که جزیی از یک عملیات استاندارد سرویس نیست و به بروز وقفه یا کاهش کیفیت سرویس دهی منجر شده یا می‌شود.
 
هدف ITIL رسیدن به عملیات عادی و طبیعی در کمترین و کوتاه ترینکوتاه‌ترین زمان ممکن، با کمترین میزان تاثیر در تجارت یا کاربر، با صرف یک هزینه مقرون به صرفه‌است. رخدادها ممکن است به دلایل مشخص و یا نامشخصی به وقوع بپیوندند ونهایتا به منظور کنترل کردن مدیریت مشکلات (problem management) در Known Error Database – KeDB ثبت می‌شوند.
 
در جایی که محیط ‍پیرامون کارِ از پیش تعریف شده , توسعه پیدا کرده‌است , پیشنهاد می‌شود که service desk یک محیط سریع را برای برطرف کردن مشکل, در اولین مرحله فراهم کند.
خط ۲۳۰:
رخدادها نتایج مشکلات و خطاهای زیربناهای فن‌آوری اطلاعات هستند. علت بروز رخداد ممکن است پیدا و روشن باشد و نیازی به سرمایه گذاری (از نظر زمانی و هزینه‌ای) برای شناسایی علت بروز رخداد نباشد و منجر به درخواست برای یک تعمیر , یک حضور فیزیکی در محل یا یک درخواست تغییر برای حذف خطا باشد.
 
جایی که یک رخداد مطرح می‌شود تا بصورت جدی و قاطعانه پیگیری شود, و یا چند پیشامد مشابه یک رخداد مشاهده می‌شود , یک مشکل می‌تواند به عنوان پاسخی برای حل همه موارد در سیستم ثبت شود (همچنین ممکن است تا چند مشکل مشابه گزارش نشد, اصلا مشکلی هم ثبت نشود). مدیریت یک مشکل از فرآیند مدیریت یک رخداد (می‌تواند) متفاوت است و معمولامعمولاً توسط کارمندان متفاوت انجام می‌شود و به همین دلیل توسط فرآیند مدیریت مشکلات کنترل می‌شود. وقتی که یک مشکل شناسایی می‌شود و محیط مشکل پیدا می‌شود , مشکل یک ‍ ٰمشکل شناخته شدهٰ می‌شود. هنگامیکه ریشه و علت بروز رخداد شناسایی می‌شود تبدیل به یک ٰخطای شناسایی شدهٰ می‌شود و نهایتا یک درخواست تغییر (Request For Change – RFC) ممکن است برای تغییر (اصلاح) سیستم با رفع خطای شناسایی شده ایجاد شود. این فرآیند توسط فرایند مدیریت تغییرات (Change Management) تحت پوشش قرار گرفته‌است.
 
توجه داشته باشید که درخواست یک سرویس اضافی به عنوان یک رخداد شناخته نمی‌شود و آن را یک درخواست تغییر (RFC) می‌نامند.