ویکی‌پدیا

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

نمایش تاریخچه به صورت تعاملی
→ تفاوت قدیمی‌ترتفاوت جدیدتر ←
محتوای حذف‌شده محتوای افزوده‌شده
دیداریویکی‌متن
FreshmanBot (بحث | مشارکت‌ها)
ربات‌ها
۱۳۳٬۲۴۲ ویرایش‌ها
جز اصلاح فاصله مجازی + اصلاح نویسه با استفاده از AWB
خط ۴:
در اوایل دهه ۸۰ میلادی [[آی‌بی‌ام]] مفهوم سیستم‌های اصلی در چهار جلد با عنوان یک سیستم مدیریت برای سامانه‌های اطلاعاتی منتشر کرد. این‌ها به عنوان نشریات زرد پذیرفته شدند و پایه‌های '''کتابخانه زیربنایی فناوری اطلاعات''' را بنا نهادند.
 
نویسنده اصلی کتاب‌های زرد آی‌بی‌ام شخصی با نام [[ادوارد فان اسخایک]] بود که آنهاآن‌ها را در کتاب یک سیستم مدیریتی برای اطلاعات تجاری جمع‌آوری نمود؛ که در سال ۲۰۰۶ توسط انتشارات رد سوان بروز رسانی شد. در کاری که فان اسخایک در سال ۱۹۸۵ انجام داد، او از کاری که ریچارد نولان ([[Richard L. Nolan]]) در سال ۱۹۷۴ در کتاب مدیریت قابلیت منابع داده‌ای منتشر کرده بود و در واقع می‌توان از آن به عنوان اولین منابع [[مدیریت فناوری اطلاعات]] در سطح کلان یاد کرد، استفاده کرده بود.
 
شمار زیادی از مفاهیم برای توسعه و ایجاد کتابخانه زیربنایی فناوری اطلاعات (ITIL) توسطUK Government’s Central Computer and Telecommunications Agency (CCTA) بوجود نیامد، بلکه توسط [[IBM]] تعریف شد.
 
== توسعه ==
آنچه که امروز نسخه یک کتابخانه زیربنایی فناوری اطلاعات (آیدل) نامیده می‌شود، با توجهات CCTA - Central Computer and Telecommunications Agency توسعه پیدا کرد و با عنوان روش شناسیروش‌شناسی مدیریت فناوری اطلاعات دولتی (Government Information Technology Infrastructure Management Methodology) یا GITMM نام گذاری گردید؛ و طی سالهاسال‌ها به ۳۱ جلد تحت رهبری Peter Skinner و John Stewart در CCTA افزایش و توسعه پیدا کرد.
 
در اواخر دهه ۸۰ میلادی CCTA از سوی شرکت‌های IT که می‌خواستند از سرویس مشاوره دولت استفاده کنند و نیز از سوی سازمان‌های دولتی که از چشم افتاده بودند مورد حملات شدیدی قرار گرفت؛ و سرانجام CCTA تسلیم شد و مفهوم central driving IT authority for the UK Government از بین رفت. این به معنای سازوار کردن راهنماهای CCTA مانند ITIL بود که به تأخیر افتاد.
خط ۳۲:
The British Educational Communications and Technology Agency – BECTA زیربنای پشتیبانی تکنیکی فناوری اطلاعات و ارتباطات، (FITS - Framework for ICT Technical Support) را که بر اساس ITIL است را توسعه داد، اما فقط برای مدارس اصلی و ثانویه انگلیس (که معمولاً دارای واحدهای IT کوچک بودند) مورد استفاده قرار گرفت. بطور مشابه The Visible OPS Handbook: Implementing ITIL in 4 Practical and Auditable Steps که بر اساس ITIL بود، بطور خاص بر روی بزرگترین المان‌های bang for the buck متمرکز شد.
 
سازمان‌هایی که لازم دارند تا بدانند که فرایند ITIL چگونه به رنج بیشتر فرایندهای IT لینک (متصل) می‌شود یا آنهاآن‌ها که نیاز سطح وظیفه (Task Level) برای راهنمایی پیاده‌سازی مدیریت سرویس دارند می‌توانند ازIBM Tivoli Unified Process – ITUP استفاده نمایند، ITUP هم مانند MOF، هم بر اسا ITIL طراحی شده اما یک فرایند یکپارچگی مدل (Integrated Process Model) کامل را معرفی می‌کند.
 
سازمان‌های کوچک که نمی‌توانند Materialها و یک برنامه کامل ITIL را بکار بگیرند می‌توانند از Microsoft Operations Framework که بر اساس ITIL و با محدودیت‌های بیشتری تعریف شده استفاده نمایند.
خط ۳۹:
 
<span style="font-size: large;">Microsoft Opration Framework(MOF)</span>:
شرکت مایکروسافت به منظور ارائه و پشتیبانی مطلوب از خدمات و محصولات خود به مشتریان، یک چارچوب عملیاتی مبتنی بر ITIL توسعه داده است. چارچوب عملیاتی مایکروسافت(MOF) شامل مجموعه‌ای از بهترین شیوه‌ها، فرایندها و رهنمودهای کاربردی به منظور کسب اطمینان از راه‌حل‌ها و خدمات IT است. این چارچوب با ارایهارائه راهنمایی‌هایی به صورت سوال و جواب، به کاربران اجازه می‌دهد تا علاوه بر تعیین نیازهای سازمان، فعالیت‌هایی که واحد IT برای افزایش بهره‌وری و اثربخشی نیاز دارد، مشخص نمایند. راهنمایی‌های موجود در MOF تمام فعالیت‌ها و فرایندهای درگیر در یک سرویس IT، شامل طرح اولیه، توسعه، به‌کارگیری، نگهداری و در نهایت از رده خارج شدن سرویس، را در برمی‌گیرد.
 
== کلیاتی از کتابخانه زیربنایی فناوری اطلاعات نسخه ۲ ==
خط ۶۰:
 
برای کمک به پیاده‌سازی تجربیات ITIL یک کتاب کمکی منتشر شد که راهنمایی‌هایی را در پیاده‌سازی (بیشتر در ارتباط با مدیریت سرویس – Service Management –) فراهم می‌کرد.
# برنامه ریزیبرنامه‌ریزی برای پیاده‌سازی مدیریت سرویس (Planning to Implement Service Management)
ودر این اواخر ضمیمه‌هایی برای راهنمایی شرکت‌های کوچک IT اضافه شده‌است، که در هشت کتاب منتشر شده اصلی موجود نیست:
# پیاده‌سازی ITIL در مقیاس کوچک (ITIL Small-Scale Implementation)
خط ۹۹:
 
=== انتقال سرویس ===
انتقال سرویس به تحویل سرویس‌هایی مربوط می‌شود که نیاز تجاری فعال / عملیاتی (Live\Operational use) دارند؛ و اغلب از بخش «پروژه» IT پیروی می‌کنند بجایبه جای تجارت مرسوم (BAU – Business as Usual). این بخش همچنین موضوعاتی از قبیل:
* مدیریت تغییرات در محیطهای تجارت مرسوم (Managing changes to the “BAU” environment)
* دارایی سرویس (Service Asset)
خط ۱۱۱:
 
=== عملیات سرویس ===
تجربه موفق در گروی نائل شدن به تحویل سطوح مورد پذیرش (agreed levels) سرویس‌ها، برای هردوی کاربران نهایی و مشتری هاست (که «مشتری» به کسی گفته می‌شود که برای دریافت یک سرویس بهایی را پرداخت کرده باشند و در مورد، توافق نامهتوافق‌نامه سطح سرویس (SLA’s - Service Level Agreement) گفتگو کرده باشند). عملیات سرویس بخشی از چرخه زندگی است، وقتی که سرویس‌ها و مقادیر (value) کاملاً تحویل شده‌اند. همچنین ردگیری (Monitoring) مشکلات (Problems) و برقراری تعادل بین سرویس اطمینان بخش (Service reliability) و هزینه و غیره قابل ذکر و توجه‌است. موضوعات شامل:
* برقراری تعادل بین اهداف برخوردی، مانند اطمینان و هزینه و … (Balancing Confilicting Goals)
* مدیریت رخدادها (Event Management)
خط ۱۲۵:
==== شرح کوتاه ====
مرتب‌سازی و مرتب‌سازی دوباره سرویس‌های IT به منظور تغییر نیازهای تجاری انجام می‌شود (به آن دلیل که ثبات، باعث رو به زوال رفتن مؤسسه یا تنزل آن می‌شود).
هدف بهبود مداوم سرویس، مرتب‌سازی و مرتب‌سازی دوباره سرویس‌های IT، برای تغییر نیازهای تجاری، بوسیله تعریف و پیاده‌سازی بهبودها در سرویس‌های IT یی است که فرایند تجاری را پشتیبانی می‌کنند. دورنمای بهبود مداوم سرویس در بهبودها، دورنمای تجاری کیفیت سرویس است، حتی با اینکه بهبود مداوم سرویس، می‌خواهد تأثیرات فرایندها، بازدهی و هزینه مؤثر فرایندهای IT را در تمامی طول چرخه حیاتشان بهبود ببخشد. بر اساس بهبود مدیریت، بهبود مداوم سرویس باید بصورتبه صورت کاملاً روشن و واضح، تعریف کند که چه چیزی باید کنترل و اندازه‌گیری شود.
 
بهبود مداوم سرویس باید مانند سایر تجربیات موفق عمل شود. آنهاآن‌ها نیازمند یک برنامه‌ریزی بالا به پیش رو (upfront)، آموزش و اطلاع‌رسانی، زمان‌بندی مداوم، ایجاد نقش‌ها، نسبت دادن به خود، و فعالیت‌ها براساس میزان موفقیت شناسایی می‌شوند. بهبود مداوم سرویس باید مانند فرایندها با فعالیت‌های تعریف شده، ورودی‌ها، خروجی‌ها، نقش‌ها و گزارش‌ها برنامه‌ریزی و زمان‌بندی شود.
FHD
 
==== شرح کامل ====
مادامی که مؤسسه در حال شناسایی سرویس‌هایش است (اینکه چه سرویس‌هایی دارد)، همچنین فرایند توسعه و پیاده‌سازی مدیریت سرویس فناوری اطلاعات (ITSM – IT Service Management) آن سرویس‌ها را قابل استفاده می‌نماید، بسیاری بر این باورند که کار مشکل انجام شده‌است. آنهاآن‌ها سخت در اشتباهند !!! کار واقعی تازه آغاز شده‌است. موسسات چگونه برای استفاده فرایند جدید درگیر می‌شوند (چگونه بر اساس فرایند جدید کار می‌کنند)؟ موسسات چگونه می‌سنجند، گزارش می‌گیرند و از اطلاعات برای بهبود نه تنها فرایندهای جدید بلکه بهبود مداوم سرویس‌های مهیا شده اقدام می‌کنند؟ این کار مستلزم یک بحث خردمندانه برای سازوار کردن بهبود مداوم سرویس با ورودی‌ها، خروجی‌ها و نقش‌های تعریف شده و مسئولیت‌ها و اهدافی است که بطور واضح تعریف شده‌اند و رویه‌هایی است که مستند شده‌اند، می‌باشد. برای موفقیت، بهبود مداوم سرویس باید با فرهنگ هر سازمان سازگار و بومی (embed) شود.
 
چرخه حیات سرویس یک معبر وسیع به مدیریت سرویس (Service Management) است: برای درک ساختار آن، ارتباط مابین تمامی اجزای آن، و اینکه چگونه تغییر در هر منطقه (یا جایی) بر روی تمامی سیستم و بخش‌های تشکیل دهنده (که از آن به بعد ایجاد می‌شوند) تأثیر گذار خواهد بود، یک زیربنا و شالوده (Framework) سازمان یافته برای کارایی بهتر و قابل تحمل طراحی شده‌است.
خط ۱۵۶:
== جزئیات کتابخانه زیربنایی فناوری اطلاعات نسخه ۲ ==
=== پشتیبانی سرویس ===
نظام پشتیبانی سرویس ITIL بر روی کاربر سرویس ICT متمرکز شده‌است و وظیفه اصلی آن تضمین دسترسی آنهاآن‌ها به سرویس‌های مورد نظر، به منظور پشتیبانی وظایف تجاری است.
 
برای یک تجارت، مشتری‌ها و کاربران نقاط ورودی به مدل فرایند (Process Model) هستند. آنهاآن‌ها (مشتری‌ها و کاربران) بوسیله:
* درخواست تغییرات (Asking for Changes)
* لزوم ارتباطات، بروز رسانی‌ها (Needing Comminucation , Updates)
خط ۱۸۴:
* Service Desk (پیش‌خوان سرویس): فقط به رخدادها، مشکلات و پرسش‌ها رسیدگی نمی‌کند، بلکه علاوه اینها یک واسط برای سایر فعالیت‌ها مانند درخواست‌های تغییر، قراردادهای نگهداری، مجوزهای نرم‌افزار (Software Licenses)، مدیریت سطح سرویس (Service Level Management)، مدیریت پیکربندی (Configuration Management)، مدیریت موجودی (Availability Management)، مدیریت مالی (Financial Management) و مدیریت بهبود مداوم سرویس‌های فناوری اطلاعات (IT Services Continuity Management) فراهم می‌کند.
 
سه نوع ساختاری که برای ServiceDesk می‌توان به آنهاآن‌ها اشاره کرد عبارتند از:
* Local Service Desk (داخلی): برای برطرف کردن نیازهای تجاری محلی – فقط تا زمانی یک ابزار تمرینی است که در چندین محل درخواست سرویس داشته باشند.
* Central Service Desk (مرکزی): برای برطرف کردن نیاز موسساتی که دارای چندین محل هستند – هزینه‌های عملیاتی را پایین آورده و به کارگیریبه‌کارگیری منابع موجود را بهبود می‌بخشد.
* Virtual Service Desk (مجازی): برای برطرف کردن نیاز سازمان‌هایی که در چند کشور قرار گرفته‌اند – می‌تواند با بهره‌گیری از مزایای بهبود شبکه و مخابرات، از هر نقطه‌ای در جهان مورد دسترسی قرار بگیرد؛ و منجر به کاهش هزینه‌های عملیاتی و بهبود بکارگیری منابع موجود شود.
 
خط ۲۱۰:
رخدادها نتایج مشکلات و خطاهای زیربناهای فناوری اطلاعات هستند. علت بروز رخداد ممکن است پیدا و روشن باشد و نیازی به سرمایه‌گذاری (از نظر زمانی و هزینه‌ای) برای شناسایی علت بروز رخداد نباشد و منجر به درخواست برای یک تعمیر، یک حضور فیزیکی در محل یا یک درخواست تغییر برای حذف خطا باشد.
 
جایی که یک رخداد مطرح می‌شود تا بصورتبه صورت جدی و قاطعانه پیگیری شود، یا چند پیشامد مشابه یک رخداد مشاهده می‌شود، یک مشکل می‌تواند به عنوان پاسخی برای حل همه موارد در سیستم ثبت شود (همچنین ممکن است تا چند مشکل مشابه گزارش نشد، اصلاً مشکلی هم ثبت نشود). مدیریت یک مشکل از فرایند مدیریت یک رخداد (می‌تواند) متفاوت است و معمولاً توسط کارمندان متفاوت انجام می‌شود و به همین دلیل توسط فرایند مدیریت مشکلات کنترل می‌شود. وقتی که یک مشکل شناسایی می‌شود و محیط مشکل پیدا می‌شود، مشکل یک ‍ ٰمشکل شناخته شدهٰ می‌شود. هنگامیکه ریشه و علت بروز رخداد شناسایی می‌شود تبدیل به یکٰ خطای شناسایی شدهٰ می‌شود و نهایتاً یک درخواست تغییر (Request For Change – RFC) ممکن است برای تغییر (اصلاح) سیستم با رفع خطای شناسایی شده ایجاد شود. این فرایند توسط فرایند مدیریت تغییرات (Change Management) تحت پوشش قرار گرفته‌است.
 
توجه داشته باشید که درخواست یک سرویس اضافی به عنوان یک رخداد شناخته نمی‌شود و آن را یک درخواست تغییر (RFC) می‌نامند.
برگرفته از «https://fa.wikipedia.org/wiki/کتابخانه_زیربنایی_فناوری_اطلاعات»