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

محتوای حذف‌شده محتوای افزوده‌شده
Amirobot (بحث | مشارکت‌ها)
جز ربات: تصحیح جایگذاری کاما، شمارگان هزارگان
Amirobot (بحث | مشارکت‌ها)
جز ربات: تصحیح کاما، شمارگان هزارگان
خط ۲۷:
ITSM – IT Service Management در جایگاه مفهوم مرتبط است اما با ITIL در نسخه دو که دربرگیرنده یک زیربخش با نام IT Service Management می‌باشد، برابر (یکی) نیست. (پنج جلد از نسخه سوم زیربخش مربوطه دارای محدوده مشخصی نیست). ترکیب جلدهای پشتیبانی سرویس (Service Support) و تحویل سرویس (Service Delivery) با محدوده استاندارد ISO / IEC ۲۰۰۰۰ (قبلی BS ۱۵۰۰۰) برابر هستند.
 
خارج از 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 در مقیاس کوچک ( ITIL Small-Scale Implementation )
ITIL در یک فرآیند-مدل (Process-Model ) بر اساس دید کنترلی و مدیریت عملیات ایجاد شده، و اغلب به W. Edwards Deming نسبت داده می‌شود. توصیه‌های ITIL دردهه ۱۹۸۰ بوسیله سازمان دولتی CCTA انگلستان، برای پاسخ دهی به وابستگی رو به رشد در IT و شناسایی استانداردهای بدون تجربه، آژانس‌های دولتی و قراردادهای محرمانه‌ای (Private Sector Contract ) که بطور مستقل تجارب مدیریت ITمی ساختند و تلاش دوباره در پروژه‌های Information and Communications Technology (ICT) که منجر به بروز خطاهای عمومی و افزایش هزینه‌ها می‌شد، توسعه پیدا کرد. در آوریل (اردیبهشت) ۲۰۰۱، CCTA با Office of Government Commerce – OGC,OGC، که یک دفتر (اداره) در UK Treasury بود ادغام شد.
 
یکی از مهمترین مزایای این امر در رابطه با ITIL در حوزه IT Community تهیه کردن فرهنگ لغات بود. که دربرگیرنده موارد (terms) تعریف شده دقیق و با مقبولیت عمومی گسترده بود. یک واژه نامه جدید و اضافه هم، مانند یک کلید قابل حمل برای ITIL v۳ (که با نام پروژه بازنگری مجدد ITIL یا ITIL Refresh Project شناخته می‌شود ) توسعه پیدا کرد.
خط ۱۷۹:
* انتقال واقعی فرآیند (Real process delivery)
 
درگیر پشتیبانی سرویس می‌شوند. برنامه Service desk تنها نقطه ارتباطی مشتریان برای مطرح کردن مشکلاتشان می‌باشد. که درصورت وجود پاسخ، مشکل برطرف می‌شود و در غیر این صورت یک رخداد (Incident) ثبت می‌شود. رخداد باعث بوجود آمدن یک سری فرآیند می‌شود : مدیریت رخداد (Incident Management),، مدیریت مشکلات (Problem Management),، مدیریت تغییرات ( Change Management),، مدیریت نسخه‌های منتشر شده و مدیریت پیکربندی (Release Management and Configuration Management). این سری فرآیندها توسط پایگاه داده مدیریت پیکربندی (Configuration Management Database - CMDB) پیگیری و ثبت می‌شود. که هر فرآیند را ذخیره می‌کند و مستنداتی را برای امکان پذیر کردن پیگیری تولید می‌کند (مدیریت کیفیت – Quality Management )‌.
 
=== مدیریت درخواست سرویس ===
خط ۲۲۳:
هدف ITIL رسیدن به عملیات عادی و طبیعی در کمترین و کوتاه‌ترین زمان ممکن، با کمترین میزان تاثیر در تجارت یا کاربر، با صرف یک هزینه مقرون به صرفه‌است. رخدادها ممکن است به دلایل مشخص و یا نامشخصی به وقوع بپیوندند ونهایتا به منظور کنترل کردن مدیریت مشکلات (problem management) در Known Error Database – KeDB ثبت می‌شوند.
 
در جایی که محیط ‍پیرامون کارِ از پیش تعریف شده,شده، توسعه پیدا کرده‌است,کرده‌است، پیشنهاد می‌شود که service desk یک محیط سریع را برای برطرف کردن مشکل,مشکل، در اولین مرحله فراهم کند.
 
در جایی که یک رخداد نتیجه یک مشکل شناخته شده و یا خطای شناخته شده نباشد,نباشد، می‌تواند یک محیط ایزوله شده یا یک پیش آمد منحصر بفرد یا ممکن است که مشکل ریشه‌ای مشخص شده باشد,باشد، نیاز است که مدیریت مشکلات درگیر شود,شود، در صورت امکان باید یک مشکل جدید,جدید، با مشخصات رخداد ایجاد شود.
 
==== رخدادها و تغییرات ====
رخدادها نتایج مشکلات و خطاهای زیربناهای فن‌آوری اطلاعات هستند. علت بروز رخداد ممکن است پیدا و روشن باشد و نیازی به سرمایه گذاری (از نظر زمانی و هزینه‌ای) برای شناسایی علت بروز رخداد نباشد و منجر به درخواست برای یک تعمیر,تعمیر، یک حضور فیزیکی در محل یا یک درخواست تغییر برای حذف خطا باشد.
 
جایی که یک رخداد مطرح می‌شود تا بصورت جدی و قاطعانه پیگیری شود,شود، و یا چند پیشامد مشابه یک رخداد مشاهده می‌شود,می‌شود، یک مشکل می‌تواند به عنوان پاسخی برای حل همه موارد در سیستم ثبت شود (همچنین ممکن است تا چند مشکل مشابه گزارش نشد,نشد، اصلا مشکلی هم ثبت نشود). مدیریت یک مشکل از فرآیند مدیریت یک رخداد (می‌تواند) متفاوت است و معمولاً توسط کارمندان متفاوت انجام می‌شود و به همین دلیل توسط فرآیند مدیریت مشکلات کنترل می‌شود. وقتی که یک مشکل شناسایی می‌شود و محیط مشکل پیدا می‌شود,می‌شود، مشکل یک ‍ ٰمشکل شناخته شدهٰ می‌شود. هنگامیکه ریشه و علت بروز رخداد شناسایی می‌شود تبدیل به یک ٰخطای شناسایی شدهٰ می‌شود و نهایتا یک درخواست تغییر (Request For Change – RFC) ممکن است برای تغییر (اصلاح) سیستم با رفع خطای شناسایی شده ایجاد شود. این فرآیند توسط فرایند مدیریت تغییرات (Change Management) تحت پوشش قرار گرفته‌است.
 
توجه داشته باشید که درخواست یک سرویس اضافی به عنوان یک رخداد شناخته نمی‌شود و آن را یک درخواست تغییر (RFC) می‌نامند.
خط ۲۴۲:
* رفع مشکل و بازیابی – Resolution and recovery
* بستن رخداد – Incident closure
* مالکیت رخداد,رخداد، بازدید,بازدید، پیگیری و ارتباطات – Incident ownership, monitoring, tracking and communication
 
==== مثال و نمونه ====
رخدادها باید طبقه بندی بشوند همانطور که ثبت می‌شوند,می‌شوند، نمونه‌های برای طبقه بندی رخدادها در زیر آورده شده‌است :
 
Application