MedaNet Journal

دانش عملی برای مدیریت فناوری اطلاعات

از ITSM و ITIL تا دارایی، عملیات، امنیت، هویت و محصولات ManageEngine؛ موضوع را پیدا کنید، سناریو را بخوانید و به اجرا برسید.

مسیرهای مطالعه

بر اساس مسئله بخوانید، نه فقط بر اساس تاریخ

تازه‌های مدانت

جدیدترین مقالات

با انتشار مطالب جدید، این بخش خودکار به‌روز می‌شود.

KEEP LEARNING

موضوعی در ذهن دارید؟ از جست‌وجوی مدانت شروع کنید

میان صدها مقاله، راهنما، محصول و صفحه تخصصی، سریع‌تر به پاسخ مناسب برسید.

جست‌وجو در کل مدانت
مهر ۱۰, ۱۴۰۳

Known Error چیست؟

Known Error یا «خطای شناخته‌شده» در ITIL به Problemی گفته می‌شود که تحلیل شده، اما هنوز به‌طور کامل برطرف نشده است. ممکن است برای آن Workaround وجود داشته باشد، اما وجود Workaround شرط تعریف Known Error نیست. Known Error چه زمانی ایجاد می‌شود؟ وقتی تیم Problem Management علت، الگو یا شرایط یک مشکل را به اندازه کافی تحلیل کرده باشد و بتواند اطلاعات مفیدی برای تیم‌های پشتیبانی ثبت کند، آن Problem می‌تواند به‌عنوان Known Error مدیریت شود؛ حتی اگر Permanent Fix هنوز آماده نباشد. تفاوت Known Error و Workaround مفهوم تعریف Known Error Problem تحلیل‌شده‌ای که هنوز حل نهایی نشده است Workaround راهی برای کاهش یا حذف موقت اثر Incident یا Problem بدون حل علت اصلی یک مثال ساده فرض کنید یک سرویس هر بار پس از افزایش بار دچار قطع ارتباط می‌شود. تیم فنی متوجه می‌شود علت به Memory Leak در یک Component مربوط است، اما Patch نهایی هنوز آماده نشده. Restart دوره‌ای سرویس می‌تواند Workaround باشد و خود Problem نیز به‌عنوان Known Error ثبت شود تا Service Desk در رخدادهای بعدی سریع‌تر عمل کند. برای درک بهتر ارتباط Incident، Problem و Root Cause Analysis، مقاله RCA چیست؟ را هم ببینید.
مهر ۱۰, ۱۴۰۳

SVS چیست؟

SVS مخفف Service Value System یا «سیستم ارزش خدمات» است؛ مدلی در ITIL 4 که نشان می‌دهد اجزای مختلف سازمان چگونه باید کنار هم کار کنند تا از تقاضا و فرصت، ارزش برای مشتری، کاربر و خود سازمان ساخته شود. SVS فقط یک فرایند یا دیاگرام نیست. این مدل یک نگاه کل‌نگر به مدیریت خدمات است و حاکمیت، اصول راهنما، زنجیره ارزش خدمات، Practices و بهبود مستمر را در یک سیستم واحد کنار هم قرار می‌دهد. اجزای اصلی SVS در ITIL 4 Guiding Principles: اصول راهنما برای تصمیم‌گیری و بهبود. Governance: هدایت، ارزیابی و نظارت سازمان. Service Value Chain: فعالیت‌هایی که تقاضا و فرصت را به ارزش تبدیل می‌کنند. Practices: قابلیت‌ها و روش‌های لازم برای مدیریت خدمات. Continual Improvement: بهبود مستمر در تمام اجزای سیستم. برای بررسی دقیق‌تر این پنج جزء، مقاله ساختار و اجزای SVS در ITIL 4 را ببینید. تفاوت SVS با Service Value Chain چیست؟ SVS کل سیستم مدیریت ارزش است؛ اما Service Value Chain فقط یکی از اجزای آن است. زنجیره ارزش خدمات فعالیت‌های Plan، Improve، Engage، Design & Transition، Obtain/Build و Deliver & Support را به هم متصل می‌کند. Value Stream نیز مسیر مشخصی از همین فعالیت‌ها برای تحقق یک نتیجه واقعی است. برای درک این بخش، Value Stream در ITIL 4 را مطالعه کنید. یک مثال ساده از SVS فرض کنید کاربران از کندی یک سرویس سازمانی شکایت دارند. در نگاه SVS فقط تیم فنی مسئول نیست. نیاز کاربر باید دریافت شود، اولویت کسب‌وکار مشخص شود، تغییرات لازم تحت حاکمیت انجام شوند، تیم‌های مختلف هماهنگ شوند و نتیجه نهایی اندازه‌گیری شود. اگر این چرخه به بهبود واقعی تجربه کاربر منجر شود، سازمان از اجزای SVS برای خلق ارزش استفاده کرده است. چرا SVS مهم است؟ از مدیریت جزیره‌ای فرایندها جلوگیری می‌کند. IT را به اهداف و اولویت‌های کسب‌وکار متصل می‌کند. به سازمان کمک می‌کند خروجی فنی را با ارزش واقعی اشتباه نگیرد. حاکمیت، اجرا و بهبود را در یک مدل یکپارچه قرار می‌دهد. برای مرور اصطلاحات مرتبط نیز واژه‌نامه ITIL 4 و برای درک عمیق‌تر مفهوم ارزش، مقاله قلب ITIL 4 و مفهوم ارزش مفید است. سخن پایانی SVS یادآوری می‌کند که مدیریت خدمات فقط اجرای چند فرایند نیست؛ همه اجزای سازمان باید در یک سیستم هماهنگ کار کنند تا نتیجه‌ای ایجاد شود که واقعاً برای ذی‌نفعان ارزش داشته باشد.
مهر ۱۰, ۱۴۰۳

BCP چیست؟

BCP (Business Continuity Plan) یا «برنامه تداوم کسب‌وکار» مجموعه‌ای از تصمیم‌ها، نقش‌ها، راهکارها و رویه‌هاست که کمک می‌کند سازمان در زمان بحران، فعالیت‌های حیاتی خود را ادامه دهد یا در زمان قابل‌قبول بازیابی کند. BCP چه مسئله‌ای را حل می‌کند؟ هدف BCP فقط بازیابی سرور نیست. یک بحران می‌تواند کارکنان، ساختمان، تأمین‌کننده، ارتباطات، داده، نرم‌افزار یا زنجیره تأمین را مختل کند. برنامه تداوم کسب‌وکار باید مشخص کند کدام فرایندها حیاتی‌اند، چه مدت توقف قابل تحمل است و با چه راهکار جایگزینی می‌توان خدمت را ادامه داد. اجزای اصلی یک BCP BIA یا Business Impact Analysis برای تعیین فرایندهای حیاتی و اولویت بازیابی ارزیابی ریسک و سناریوهای اختلال تعیین RTO و RPO استراتژی‌های جایگزین برای نیروی انسانی، محل کار، ارتباطات و فناوری نقش‌ها، مسیر تماس و تصمیم‌گیری در بحران Runbookها و دستورالعمل‌های عملیاتی آزمون، بازنگری و به‌روزرسانی دوره‌ای برنامه تفاوت BCP و DRP چیست؟ BCP دامنه‌ای گسترده‌تر دارد و روی ادامه فعالیت کسب‌وکار تمرکز می‌کند؛ اما DRP یا Disaster Recovery Plan بیشتر روی بازیابی فناوری، داده و سرویس‌های IT پس از بحران متمرکز است. در یک برنامه بالغ، DRP یکی از اجزای تداوم کسب‌وکار است، نه جایگزین آن. سایت بازیابی چه نقشی دارد؟ بسته به RTO، RPO و بودجه، سازمان ممکن است از Hot Site، Warm Site یا Cold Site استفاده کند. انتخاب میان این مدل‌ها باید از نیاز کسب‌وکار و خروجی BIA آغاز شود، نه صرفاً از فناوری موجود. BCP باید آزمایش شود برنامه‌ای که فقط در فایل Word باقی مانده باشد، در بحران قابل اتکا نیست. Tabletop Exercise، آزمون تماس و Escalation، Restore Test، Failover و سناریوی عملیاتی باید به‌صورت دوره‌ای اجرا شوند تا فرضیات، وابستگی‌ها و زمان‌های واقعی بازیابی مشخص شوند. سخن پایانی BCP خوب قرار نیست بحران را حذف کند؛ قرار است وقتی بحران رخ داد، سازمان بداند چه چیزی را اول حفظ کند، چه کسی تصمیم بگیرد و چگونه خدمت حیاتی را در زمان قابل‌قبول ادامه دهد. برای طراحی سازمانی این حوزه، صفحه تداوم کسب‌وکار و Disaster Recovery مدانت را نیز ببینید.
مهر ۱۰, ۱۴۰۳

RTO چیست؟

RTO مخفف Recovery Time Objective یا «هدف زمان بازیابی» است؛ یعنی حداکثر زمانی که یک سرویس یا فرایند حیاتی می‌تواند پس از اختلال از دسترس خارج باشد تا پیش از عبور از سطح قابل‌قبول کسب‌وکار بازیابی شود. RTO پاسخ این سؤال است: «بعد از بحران، حداکثر تا چه زمانی باید سرویس برگردد؟» این عدد باید از نیاز کسب‌وکار و تحلیل اثر تعیین شود، نه صرفاً از توان فنی تیم IT. یک مثال ساده از RTO اگر RTO سامانه فروش ۲ ساعت باشد، برنامه بازیابی باید طوری طراحی شود که از لحظه اختلال تا بازگشت سرویس بیش از دو ساعت طول نکشد. این زمان می‌تواند شامل تشخیص حادثه، تصمیم Failover، راه‌اندازی زیرساخت جایگزین، Restore، تست و بازگشت کاربران باشد. تفاوت RTO و RPO RTO درباره زمان توقف سرویس است؛ اما RPO درباره میزان قابل‌قبول از دست‌رفتن داده است. ممکن است یک سیستم RTO دو ساعته داشته باشد اما RPO آن فقط ۱۵ دقیقه باشد؛ یعنی باید سریع برگردد و نسخه بازیابی نیز حداکثر ۱۵ دقیقه از داده‌های قبل از حادثه عقب باشد. RTO چگونه تعیین می‌شود؟ اثر توقف سرویس بر درآمد، عملیات و مشتریان الزامات قانونی و قراردادی وابستگی سرویس به سیستم‌های دیگر هزینه زیرساخت بازیابی سریع‌تر نتایج Business Impact Analysis برای طراحی دقیق‌تر، RTO باید داخل DRP ثبت و در تست‌های بازیابی اندازه‌گیری شود. صفحه نقش RTO و RPO در تاب‌آوری خدمات فناوری اطلاعات نیز مقایسه کامل‌تری ارائه می‌کند. سخن پایانی RTO یک آرزو برای «سریع برگشتن» نیست؛ یک هدف قابل‌اندازه‌گیری است که باید با معماری، بودجه، Runbook و تست واقعی سازمان پشتیبانی شود.
مهر ۱۰, ۱۴۰۳

RPO چیست؟

RPO مخفف Recovery Point Objective یا «هدف نقطه بازیابی» است؛ یعنی حداکثر مقدار داده‌ای که سازمان حاضر است در یک بحران از دست بدهد. RPO معمولاً به‌صورت یک بازه زمانی بیان می‌شود. RPO پاسخ این سؤال است: «اگر سیستم از کار افتاد، داده‌ها حداکثر تا چه زمانی قبل از حادثه می‌توانند برگردند؟» یک مثال ساده از RPO اگر RPO یک سامانه مالی ۱۵ دقیقه باشد، راهکار Backup یا Replication باید طوری طراحی شود که در بدترین حالت بیش از ۱۵ دقیقه داده از دست نرود. اگر آخرین Backup چهار ساعت قبل باشد، این معماری با RPO پانزده‌دقیقه‌ای سازگار نیست. تفاوت RPO و RTO RPO میزان از دست‌رفتن داده را محدود می‌کند؛ در حالی که RTO حداکثر زمان قابل‌قبول برای بازگرداندن سرویس است. مثلاً ممکن است RPO برابر ۱۵ دقیقه و RTO برابر ۲ ساعت باشد. RPO چه اثری بر Backup و Replication دارد؟ RPO چندساعته ممکن است با Backup دوره‌ای قابل دستیابی باشد. RPO کوتاه‌تر معمولاً به Backupهای پرتکرار، Snapshot یا Replication نیاز دارد. RPO نزدیک به صفر می‌تواند معماری پیچیده‌تر و هزینه بیشتری ایجاد کند. صرف داشتن Backup کافی نیست؛ بازیابی و صحت داده نیز باید تست شود. RPO را چگونه تعیین کنیم؟ RPO باید بر اساس ارزش و نرخ تغییر داده، اثر از دست‌رفتن اطلاعات، الزامات قانونی و هزینه بازیابی تعیین شود. خروجی Business Impact Analysis کمک می‌کند برای هر سرویس RPO واقع‌بینانه تعریف شود. RPO و RTO باید داخل Disaster Recovery Plan ثبت شوند و با تست‌های دوره‌ای اثبات شوند. برای مقایسه عمیق‌تر نیز مقاله نقش RTO و RPO در تاب‌آوری خدمات فناوری اطلاعات را ببینید. سخن پایانی RPO عددی برای تیم Backup نیست؛ یک تصمیم کسب‌وکاری درباره میزان داده‌ای است که سازمان توان از دست‌دادنش را دارد و معماری فنی باید برای تحقق آن طراحی شود.