کتابخانه زیربنایی فناوری اطلاعات: تفاوت میان نسخه‌ها
محتوای حذف‌شده محتوای افزوده‌شده
جز ربات ردهٔ همسنگ (۳۰) +املا+تمیز (۱۴.۹ core): + رده:کتابخانه زیربنایی فناوری اطلاعات |
LetsDoItBot (بحث | مشارکت‌ها) تمیزکاری، + ویرایش با ماژول ابرابزار با استفاده از AWB |
||
خط ۴:
در اوایل دهه ۸۰ میلادی [[آی‌بی‌ام]] مفهوم سیستم‌های اصلی در چهار جلد با عنوان یک سیستم مدیریت برای سامانه‌های اطلاعاتی منتشر کرد. اینها به عنوان نشریات زرد پذیرفته شدند و پایه‌های '''کتابخانه زیربنایی فناوری اطلاعات''' را بنا نهادند.
نویسنده اصلی کتاب‌های زرد آی‌بی‌ام شخصی با نام [[ادوارد فان اسخایک]] بود که آنها را در کتاب یک سیستم مدیریتی برای اطلاعات تجاری جمع‌آوری
شمار زیادی از مفاهیم برای توسعه و ایجاد کتابخانه زیربنایی فناوری اطلاعات (ITIL) توسطUK Government’s Central Computer and Telecommunications Agency (CCTA)
== توسعه ==
آنچه که امروز نسخه یک کتابخانه زیربنایی فناوری اطلاعات (آیدل) نامیده می‌شود، با توجهات CCTA - Central Computer and Telecommunications Agency
در اواخر دهه ۸۰ میلادی CCTA از سوی شرکت‌های IT که می‌خواستند از سرویس مشاوره دولت استفاده کنند و نیز از سوی سازمان‌های دولتی که از چشم افتاده بودند مورد حملات شدیدی قرار
▲آنچه که امروز نسخه یک کتابخانه زیربنایی فناوری اطلاعات (آیدل) نامیده می‌شود، با توجهات 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 بود که به تأخیر افتاد.
در برخی موارد راهنماها به کلی از بین رفتند. 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 قرار
در ماه دسامبر (آذر) ۲۰۰۵ میلادی OGC یک بازنگری در ITIL انجام داد که به ITIL v۳ یا نسخه سوم ITIL مشهور شده‌است و در ماه May (خرداد) ۲۰۰۷ در دسترس عموم قرار گرفت. نسخه سوم ITIL پنج نقطه مرکزی دارد:
# Service Strategy
# Service Design
# Service Transition
# Service Operation
# Continual Service Improvement
این پنج اصل بسیاری از نشرهای نسخه دو، ITIL v۲ – را بروز رسانی (update) کرد و محدوده و حوزه فعالیت‌های ITIL
== موارد مشابه کتابخانه زیربنایی فناوری اطلاعات ==
ITSM – IT Service Management در جایگاه مفهوم مرتبط است اما با ITIL در نسخه دو که دربرگیرنده یک زیربخش با نام IT Service Management می‌باشد، برابر نیست. (پنج جلد از نسخه سوم
خارج از ITIL دیدگاه‌های دیگر IT Service Management و زیربناها (Frameworks) وجود دارند که شامل کتابخانه
The British Educational Communications and Technology Agency – BECTA زیربنای پشتیبانی تکنیکی فناوری اطلاعات و ارتباطات، (FITS - Framework for ICT Technical Support) را که بر اساس ITIL است را توسعه داد، اما فقط برای مدارس اصلی و ثانویه انگلیس (که معمولاً دارای واحدهای IT کوچک بودند) مورد استفاده قرار گرفت. بطور مشابه The Visible OPS Handbook: Implementing ITIL in
سازمان‌هایی که لازم دارند تا بدانند که فرایند ITIL چگونه به رنج بیشتر فرایندهای IT لینک (متصل) می‌شود و یا آنها که نیاز سطح وظیفه (Task Level) برای راهنمایی پیاده‌سازی
سازمان‌های کوچک که نمی‌توانند Materialها و
The enhanced Telecom Operations Map eTOM که بوسیله TeleManagement Forum منتشر شد یک زیربنا (Framework) را پیشنهاد می‌کند که هدف آن فراهم کنندگان سرویس‌های مخابراتی (telecomminucations service providers)
<span style="font-size: large;">Microsoft Opration Framework(MOF)</span>:
سطر ۶۰ ⟵ ۵۹:
# مدیریت دارایی‌های برنامه (Software Asset Management)
برای کمک به پیاده‌سازی تجربیات ITIL یک کتاب کمکی منتشر شد که راهنمایی‌هایی را در پیاده‌سازی (بیشتر در ارتباط با مدیریت سرویس – Service Management –)
# برنامه ریزی برای پیاده‌سازی مدیریت سرویس (Planning to Implement Service Management)
ودر این اواخر ضمیمه‌هایی برای راهنمایی شرکت‌های کوچک IT اضافه شده‌است، که در هشت کتاب منتشر شده اصلی موجود نیست:
# پیاده‌سازی ITIL در مقیاس کوچک
ITIL در یک فرایند-مدل (Process-Model) بر اساس دید کنترلی و مدیریت عملیات ایجاد شده، و اغلب به W. Edwards Deming
یکی از مهمترین مزایای این امر در رابطه با ITIL در حوزه IT Community تهیه کردن فرهنگ لغات
== کلیاتی از کتابخانه زیربنایی فناوری اطلاعات نسخه ۳ ==
ITIL v۳ در ماه may (خرداد) ۲۰۰۷ منتشر شد و شامل پنج جلد کلیدی (key volumes)
* استراتژی سرویس (Service Strategy)
* طراحی سرویس (Service Design)
سطر ۷۷ ⟵ ۷۶:
=== راهبرد سرویس ===
استراتژی سرویس در مرکز (هسته) چرخه زندگی ITIL v۳٫۱ قرار گرفته اما نمی‌تواند به تنهایی و بدون سایر بخش‌های ساختار IT
▲استراتژی سرویس در مرکز (هسته) چرخه زندگی ITIL v۳٫۱ قرار گرفته اما نمی‌تواند به تنهایی و بدون سایر بخش‌های ساختار IT ایجاد شود. این بخش دربرگیرنده یک framework (زیربنا) برای ایجاد تجربیات موفق (best practices) در اثر توسعه بلند مدت استراتژی سرویس است. این بخش شامل موضوعات مختلفی مانند:
* استراتژی عمومی (General Strategy)
* رقابت و فضای بازار (Competition and Market Space)
سطر ۸۷ ⟵ ۸۵:
* مدیریت مالی (Financial Management)
* مدیریت سرویس سهام (Service Portfolio Management)
* و نقش‌های کلیدی و مسئولیت‌های کارکنان درگیر در استراتژی سرویس (Key Roles and Responsibilities of Staff engaging in Service Strategy)
=== طراحی سرویس ===
طراحی سرویس IT از تجربیات موفق (Best Practice) تبعیت می‌کند و شامل طراحی معماری (Design of Architecture)، فرایندها، قوانین (Policies)، مستندات و درنظر گرفتن نیازمندی‌های تجاری آینده‌است. این بخش همچنین شامل موضوعاتی مانند،
* بسته طراحی سرویس (SDP – Service Design Package)
سطر ۹۹ ⟵ ۹۶:
* امنیت اطلاعات (Information Security)
* مدیریت ملزومات (Supplier management)
* و نقش‌های کلیدی و مسئولیت کارکنان درگیر در طراحی سرویس (key roles and responsibilities for staff engaging in service design)
=== انتقال سرویس ===
انتقال سرویس به تحویل سرویس‌هایی مربوط می‌شود که نیاز تجاری فعال / عملیاتی (Live\Operational use)
▲انتقال سرویس به تحویل سرویس‌هایی مربوط می‌شود که نیاز تجاری فعال / عملیاتی (Live\Operational use) دارند. و اغلب از بخش “پروژه” IT پیروی می‌کنند بجای تجارت مرسوم (BAU – Business as Usual). این بخش همچنین موضوعاتی از قبیل:
* مدیریت تغییرات در محیطهای تجارت مرسوم (Managing changes to the “BAU” environment)
* دارایی سرویس (Service Asset)
* مدیریت پیکربندی (Configuration Management)
*
* مدیریت توسعه و نسخه (Release and Deployment Management)
* مدیریت تغییرات (Change Management)
سطر ۱۱۵ ⟵ ۱۱۱:
=== عملیات سرویس ===
تجربه موفق در گروی نائل شدن به تحویل سطوح مورد پذیرش (agreed levels) سرویس‌ها، برای هردوی کاربران نهایی و مشتری هاست (که
▲تجربه موفق در گروی نائل شدن به تحویل سطوح مورد پذیرش (agreed levels) سرویس‌ها، برای هردوی کاربران نهایی و مشتری هاست (که “مشتری” به کسی گفته می‌شود که برای دریافت یک سرویس بهایی را پرداخت کرده باشند و در مورد، توافق نامه سطح سرویس (SLA’s - Service Level Agreement) گفتگو کرده باشند). عملیات سرویس بخشی از چرخه زندگی است، وقتی که سرویس‌ها و مقادیر (value) کاملاً تحویل شده‌اند. همچنین ردگیری (Monitoring) مشکلات (Problems) و برقراری تعادل بین سرویس اطمینان بخش (Service reliability) و هزینه و غیره قابل ذکر و توجه‌است. موضوعات شامل:
* برقراری تعادل بین اهداف برخوردی، مانند اطمینان و هزینه و … (Balancing Confilicting Goals)
* مدیریت رخدادها (Event Management)
سطر ۱۲۵ ⟵ ۱۲۰:
* میز خدمات (Service Desk)
* مدیریت برنامه و تکنیکی (Technical and Application Management)
* نقش‌های کلیدی و مسئولیت کارکنان درگیر در عملیات سرویس (key roles and responsibilities for staff engaging in Service Operation)
=== بهبود مداوم سرویس ===
==== شرح کوتاه ====
مرتب‌سازی
هدف بهبود مداوم سرویس، مرتب‌سازی و مرتب‌سازی دوباره سرویس‌های IT، برای تغییر نیازهای تجاری، بوسیله تعریف و پیاده‌سازی بهبودها در سرویس‌های IT یی است که فرایند تجاری را پشتیبانی می‌کنند. دورنمای
بهبود مداوم سرویس باید مانند سایر تجربیات موفق عمل شود. آنها نیازمند یک
▲مرتب‌سازی و مرتب‌سازی دوباره سرویس‌های IT به منظور تغییر نیازهای تجاری انجام می‌شود (به آن دلیل که ثبات، باعث رو به زوال رفتن موسسه و یا تنزل آن می‌شود).
▲هدف بهبود مداوم سرویس، مرتب‌سازی و مرتب‌سازی دوباره سرویس‌های IT، برای تغییر نیازهای تجاری، بوسیله تعریف و پیاده‌سازی بهبودها در سرویس‌های IT یی است که فرایند تجاری را پشتیبانی می‌کنند. دورنمای بهبود مداوم سرویس در بهبودها، دورنمای تجاری کیفیت سرویس است، حتی با اینکه بهبود مداوم سرویس، می‌خواهد تاثیرات فرایندها، بازدهی و هزینه مؤثر فرایندهای IT را در تمامی طول چرخه حیاتشان بهبود ببخشد. بر اساس بهبود مدیریت، بهبود مداوم سرویس باید بصورت کاملاً روشن و واضح، تعریف کند که چه چیزی باید کنترل و اندازه‌گیری شود.
▲بهبود مداوم سرویس باید مانند سایر تجربیات موفق عمل شود. آنها نیازمند یک برنامه ریزی بالا به پیش رو (upfront)، آموزش و اطلاع رسانی، زمان بندی مداوم، ایجاد نقش‌ها، نسبت دادن به خود، و فعالیت‌ها براساس میزان موفقیت شناسایی می‌شوند. بهبود مداوم سرویس باید مانند فرایندها با فعالیت‌های تعریف شده، ورودی‌ها، خروجی‌ها، نقش‌ها و گزارش‌ها برنامه ریزی و زمان بندی شود.
FHD
==== شرح کامل ====
مادامی که
چرخه حیات سرویس یک معبر وسیع به مدیریت سرویس (Service Management) است: برای درک ساختار آن، ارتباط مابین تمامی اجزای آن، و اینکه چگونه تغییر در هر منطقه (یا جایی) بر روی تمامی سیستم و بخش‌های تشکیل دهنده (که از آن به بعد ایجاد می‌شوند)
▲مادامی که موسسه در حال شناسایی سرویس‌هایش است (اینکه چه سرویس‌هایی دارد)، همچنین فرایند توسعه و پیاده‌سازی مدیریت سرویس فناوری اطلاعات (ITSM – IT Service Management) آن سرویس‌ها را قابل استفاده می‌نماید، بسیاری بر این باورند که کار مشکل انجام شده‌است. آنها سخت در اشتباهند !!! کار واقعی تازه آغاز شده‌است. موسسات چگونه برای استفاده فرایند جدید درگیر می‌شوند (چگونه بر اساس فرایند جدید کار می‌کنند)؟ موسسات چگونه می‌سنجند، گزارش می‌گیرند و از اطلاعات برای بهبود نه تنها فرایندهای جدید بلکه بهبود مداوم سرویس‌های مهیا شده اقدام می‌کنند؟ این کار مستلزم یک بحث خردمندانه برای سازوار کردن بهبود مداوم سرویس با ورودی‌ها، خروجی‌ها و نقش‌های تعریف شده و مسئولیت‌ها و اهدافی است که بطور واضح تعریف شده‌اند و رویه‌هایی است که مستند شده‌اند، می‌باشد. برای موفقیت، بهبود مداوم سرویس باید با فرهنگ هر سازمان سازگار و بومی (embed) شود.
▲چرخه حیات سرویس یک معبر وسیع به مدیریت سرویس (Service Management) است: برای درک ساختار آن، ارتباط مابین تمامی اجزای آن، و اینکه چگونه تغییر در هر منطقه (یا جایی) بر روی تمامی سیستم و بخش‌های تشکیل دهنده (که از آن به بعد ایجاد می‌شوند) تاثیر گذار خواهد بود، یک زیربنا و شالوده (Framework) سازمان یافته برای کارایی بهتر و قابل تحمل طراحی شده‌است.
چرخه حیات سرویس می‌تواند در یک قالب گرافیکی نمایش داده شود، که در این حالت مقادیر را به راحتی می‌توان در دو شکل ” همکاری تجاری (Business Contribution) ” و ” سود و منافع (Profit) ” نشان داد. همکاری تجاری، بیانگر توانایی یک سازمان IT برای پشتیبانی از یک فرایند تجاری و مدیریت سرویس‌های IT با میزان کارایی درخواست شده‌است. سود و منافع، بیانگر توانایی مدیریت هزینه‌های سرویس در ارتباط با درآمدهای تجاری است.
چرخه حیات سرویس را می‌توان مانند یک چرخه حیات فازبندی شده نمایش داد، که این فازها عبارتند از:
* تعریف استراتژی برای مدیریت سرویس IT
* طراحی سرویس‌ها برای پشتیبانی از استراتژی (که به آن طراحی سرویس (Service Design)
* پیاده‌سازی سرویس‌ها بر اساس نیازمندی‌های طراحی شده (که به آن انتقال سرویس (Service Transition) یا ST)
* پشتیبانی از سرویس‌های مدیریتی فعالیت‌های عملیاتی (Support the Services Managing the Operational Activities) یا (که به آن عملیات سرویس (Service Operation) یا SO)
ارتباط بین فازها براساس بهبود مداوم سرویس‌ها
فاز بهبود مداوم سرویس در تمام فازهای چرخه حیات سرویس درگیر
با تکامل بازه‌های سرویس، ” سود و منافع ” برای هر فاز نگرانی استراتژیک و فازهای تاکتیکی (استراتژی سرویس (SS)، طراحی سرویس (SD) و انتقال سرویس (ST) را کاهش خواهد داد. در اینجا فاز عملیات سرویس (SO) بهینه‌سازی شده و نقش اصلی را برعهده می‌گیرد. در هر چرخه سرویس (بازه سرویس) سرویس با نتایج افزایش ارزش (value) تجاری و به حداکثر رساندن منافع بهبود خواهد یافت.
سطر ۱۵۸ ⟵ ۱۵۰:
برطبق اصول همکاری تجاری، سرویس‌های IT وقتی با ارزش می‌شوند، که در قدم اول مرحله انتقال سرویس (ST) آغاز شود.
برطبق اصول سود و منافع، در سرویس‌های IT
پس از چند بازه (بسته به پیچیدگی سرویس و انعطاف‌پذیری تجارت) همکاری تجاری و سود و منافع ثابت می‌شوند، که این بدان معناست که موسسات IT، به سطح صحیحی از سنجش در مدیریت فرایندها، و سرویس به سطح صحیحی از کارایی در ملاقات نیازمندی‌های سطح سرویس (performance in meeting the service level requirements)
== جزئیات کتابخانه زیربنایی فناوری اطلاعات نسخه ۲ ==
=== پشتیبانی سرویس ===
نظام پشتیبانی سرویس ITIL بر روی کاربر سرویس ICT متمرکز شده‌است و وظیفه اصلی آن تضمین دسترسی آنها به سرویس‌های مورد نظر، به منظور پشتیبانی وظایف تجاری است.
سطر ۱۷۳ ⟵ ۱۶۴:
* انتقال واقعی فرایند (Real process delivery)
درگیر پشتیبانی سرویس می‌شوند. برنامه Service desk تنها نقطه ارتباطی مشتریان برای مطرح کردن مشکلاتشان
=== مدیریت درخواست سرویس ===
وظایف ServiceDesk، رسیدگی به رخدادها و درخواست‌ها می‌باشد و یک واسط برای سایر فرایندهای مدیریت سرویس فناوری اطلاعات (ITSM) فراهم می‌کند.
* تنها نقطه ارتباط
* تنها یک نقطه ارتباطی ورود و خروج وجود دارد
* سهولت استفاده برای مشتری‌ها
سطر ۱۹۰ ⟵ ۱۸۰:
کارکرد Servicedesk تحت عناوین مختلفی شناخته می‌شود:
* Call Center (مرکز تماس):
* Help Desk (پیش‌خوان کمک و یاری [ برنامه پشتیبانی ]): مدیریت، هماهنگی، رسیدگی و رفع مشکلات مربوط به رخدادها در سریع‌ترین زمان ممکن.
* 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 (مجازی): برای برطرف کردن نیاز سازمان‌هایی که در چند کشور قرار گرفته‌اند – می‌تواند با بهره‌گیری از مزایای بهبود شبکه و مخابرات، از هر نقطه‌ای در جهان مورد دسترسی قرار
=== مدیریت رخداد ===
هدف مدیریت رخداد، بازگرداندن عملیات سرویس دهی به شکل معمول و نرمال، در کمترین زمان ممکن و به حداقل رساندن اثرگذاری مضرات (ناسازگاری‌ها) در عملیات تجاری
به زبان دیگر مدیریت رخداد (IcM) یک بخش فرایند
مشکل رخدادهایی که توسط برنامه سریعاً رفع نمی‌شوند، به یک گروه پشتیبانی مخصوص، جهت رفع مشکل، نسبت داده می‌شود. به منظور بازگرداندن سریع سرویس دهی نرمال، مشکل باید سریعاً توسط این گروه برطرف شود.
سطر ۲۱۱ ⟵ ۲۰۱:
هر رخدادی که جزیی از یک عملیات استاندارد سرویس نیست و به بروز وقفه یا کاهش کیفیت سرویس دهی منجر شده یا می‌شود.
هدف ITIL رسیدن به عملیات عادی و طبیعی در کمترین و کوتاه‌ترین زمان ممکن، با کمترین میزان
در جایی که محیط پیرامون کارِ از پیش تعریف شده، توسعه پیدا کرده‌است، پیشنهاد می‌شود که
در جایی که یک رخداد نتیجه یک مشکل شناخته شده و یا خطای شناخته شده نباشد، می‌تواند یک محیط ایزوله شده یا یک پیش آمد منحصر بفرد یا ممکن است که مشکل ریشه‌ای مشخص شده باشد، نیاز است که مدیریت مشکلات درگیر شود، در صورت امکان باید یک مشکل جدید، با مشخصات رخداد ایجاد شود.
سطر ۲۲۰ ⟵ ۲۱۰:
رخدادها نتایج مشکلات و خطاهای زیربناهای فناوری اطلاعات هستند. علت بروز رخداد ممکن است پیدا و روشن باشد و نیازی به سرمایه‌گذاری (از نظر زمانی و هزینه‌ای) برای شناسایی علت بروز رخداد نباشد و منجر به درخواست برای یک تعمیر، یک حضور فیزیکی در محل یا یک درخواست تغییر برای حذف خطا باشد.
جایی که یک رخداد مطرح می‌شود تا بصورت جدی و قاطعانه پیگیری شود، و یا چند پیشامد مشابه یک رخداد مشاهده می‌شود، یک مشکل می‌تواند به عنوان پاسخی برای حل همه موارد در سیستم ثبت شود (همچنین ممکن است تا چند مشکل مشابه گزارش نشد، اصلاً مشکلی هم ثبت نشود). مدیریت یک مشکل از فرایند مدیریت یک رخداد (می‌تواند) متفاوت است و معمولاً توسط کارمندان متفاوت انجام می‌شود و به همین دلیل توسط فرایند مدیریت مشکلات کنترل می‌شود. وقتی که یک مشکل شناسایی می‌شود و محیط مشکل پیدا می‌شود، مشکل یک ٰمشکل شناخته شدهٰ می‌شود. هنگامیکه ریشه و علت بروز رخداد شناسایی می‌شود تبدیل به
توجه داشته باشید که درخواست یک سرویس اضافی به عنوان یک رخداد شناخته نمی‌شود و آن را یک درخواست تغییر (RFC) می‌نامند.
سطر ۲۲۷ ⟵ ۲۱۷:
فرایندهای اصلی مدیریت رخداد در زیر آورده شده‌اند:
* شناسایی و ثبت رخداد – Incident detection and recording
*
* تحقیق و تشخیص – Investigation and diagnosis
* رفع مشکل و بازیابی – Resolution and recovery
* بستن رخداد – Incident closure
* مالکیت رخداد، بازدید، پیگیری و ارتباطات –
==== مثال و نمونه ====
رخدادها باید
Application
سطر ۲۴۶ ⟵ ۲۳۶:
== پانویس ==
# {{پاورقی|
# {{پاورقی|
# {{پاورقی|
# {{پاورقی|
# {{پاورقی|
# {{پاورقی|
[[رده:کتابخانه زیربنایی فناوری اطلاعات]]
| |||