MedaNet Journal

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

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

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

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

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

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

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

  • CI چیست؟

    CI مخفف Configuration Item یا «قلم پیکربندی» است. در ITIL، هر جزء مهمی که برای ارائه یک خدمت باید مدیریت، کنترل یا ردیابی شود می‌تواند یک CI باشد؛…

    ادامه مقاله

  • EULA چیست؟

    توافق‌نامه مجوز کاربر نهایی (End User License Agreement یا EULA) یک قرارداد قانونی است که شرایط و مقررات استفاده از نرم‌افزار یا محصول دیجیتال را مشخص می‌کند. این…

    ادامه مقاله

  • BYOD چیست؟

    مفهوم «Bring Your Own Device» (BYOD) به سیاستی اشاره دارد که به کارکنان اجازه می‌دهد از دستگاه‌های شخصی خود، مانند تلفن‌های هوشمند، تبلت‌ها و لپ‌تاپ‌ها، برای انجام کارهای…

    ادامه مقاله

  • CAB چیست؟ نقش Change Advisory Board در مدیریت تغییر ITIL

    CAB (Change Advisory Board) یا هیئت مشورتی تغییر، گروهی از افراد کلیدی سازمان است که تغییرات مهم در سرویس‌ها و زیرساخت‌های IT را بررسی می‌کند تا تصمیم‌گیری فقط…

    ادامه مقاله

  • MTTR چیست؟

    MTTR در ITSM معمولاً برای سنجش سرعت بازگرداندن خدمت پس از Incident یا خرابی استفاده می‌شود. نکته مهم این است که این اختصار بسته به سازمان می‌تواند به…

    ادامه مقاله

  • AIOps چیست؟

    AIOps (Artificial Intelligence for IT Operations) به کاربرد تکنولوژی‌های هوش مصنوعی در عملیات فناوری اطلاعات اشاره دارد. این رویکرد به سازمان‌ها کمک می‌کند تا با تجزیه و تحلیل…

    ادامه مقاله

  • MFA چیست؟

    احراز هویت چندعاملی (Multi-Factor Authentication یا MFA) یک روش امنیتی است که برای تأمین امنیت دسترسی به سیستم‌ها و اطلاعات حساس طراحی شده است. این روش به کاربران…

    ادامه مقاله

  • CSF چیست؟

    CSF مخفف Critical Success Factor یا «عامل حیاتی موفقیت» است؛ یعنی شرط، قابلیت یا حوزه‌ای که اگر در آن موفق نباشیم، رسیدن به یک هدف مهم سازمانی یا…

    ادامه مقاله

  • SLO چیست؟

    SLO (Service Level Objective) یا «هدف سطح خدمت» یک هدف کمی و قابل‌اندازه‌گیری برای کیفیت یک سرویس است. SLO مشخص می‌کند یک شاخص خدمت باید در یک بازه…

    ادامه مقاله

  • SVC چیست؟

    SVC یا Service Value Chain یکی از اجزای اصلی Service Value System (SVS) در ITIL 4 است. SVC مدلی عملیاتی برای تبدیل تقاضا و فرصت به ارزش است…

    ادامه مقاله

  • ISMS چیست؟

    مدیریت امنیت اطلاعات (ISMS) یک چارچوب نظام‌مند برای مدیریت و حفاظت از اطلاعات سازمان‌هاست. این سیستم به شناسایی، ارزیابی و مدیریت ریسک‌های مرتبط با اطلاعات کمک می‌کند و…

    ادامه مقاله

  • SIEM چیست؟

    SIEM (Security Information and Event Management) پلتفرمی برای جمع‌آوری، متمرکزسازی، همبستگی و تحلیل لاگ‌ها و رویدادهای امنیتی از منابع مختلف است. هدف SIEM ایجاد دید یکپارچه برای کشف…

    ادامه مقاله

KEEP LEARNING

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

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

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

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 نیست؛ یک تصمیم کسب‌وکاری درباره میزان داده‌ای است که سازمان توان از دست‌دادنش را دارد و معماری فنی باید برای تحقق آن طراحی شود.
مهر ۱۰, ۱۴۰۳

OLA چیست؟

OLA (Operational Level Agreement) یا «توافق‌نامه سطح عملیاتی» توافقی داخلی میان تیم‌ها و واحدهای یک سازمان است که مشخص می‌کند برای پشتیبانی از یک خدمت، هر تیم چه مسئولیتی دارد، در چه زمانی باید اقدام کند و چه خروجی‌ای تحویل دهد. تفاوت OLA و SLA چیست؟ SLA معمولاً تعهد میان ارائه‌دهنده خدمت و مشتری را تعریف می‌کند؛ اما OLA توافقی درون‌سازمانی است که کمک می‌کند تیم‌های داخلی بتوانند همان SLA را محقق کنند. موضوع SLA OLA طرف‌های اصلی ارائه‌دهنده خدمت و مشتری تیم‌ها و واحدهای داخلی تمرکز تعهد سطح خدمت هماهنگی عملیاتی برای تحقق خدمت نمونه حل P1 حداکثر در 2 ساعت شبکه ظرف 15 دقیقه بررسی را آغاز کند OLA چه چیزهایی باید مشخص کند؟ دامنه خدمت و تیم‌های درگیر مالکیت هر فعالیت و مسئولیت‌ها زمان پاسخ و زمان تحویل داخلی مسیر Escalation در صورت تأخیر روش اندازه‌گیری و گزارش عملکرد نحوه بازنگری توافق در صورت تغییر سرویس مثال OLA در Service Desk فرض کنید SLA با واحد مالی می‌گوید Incident بحرانی باید حداکثر طی دو ساعت حل شود. برای تحقق این تعهد، OLA می‌تواند تعیین کند Service Desk ظرف 10 دقیقه تیکت را ثبت و دسته‌بندی کند، تیم Network ظرف 15 دقیقه بررسی را آغاز کند و DBA در صورت ارجاع حداکثر ظرف 20 دقیقه پاسخ دهد. OLA چه تفاوتی با Underpinning Contract دارد؟ OLA میان تیم‌های داخلی تنظیم می‌شود؛ اما Underpinning Contract (UC) به تعهد یک تأمین‌کننده یا پیمانکار بیرونی اشاره دارد که از ارائه خدمت پشتیبانی می‌کند. هر دو باید طوری طراحی شوند که SLO و SLA اصلی قابل دستیابی باشند. سخن پایانی OLA خوب مرز بین تیم‌ها را به دیوار تبدیل نمی‌کند؛ دقیقاً مشخص می‌کند چه کسی، چه کاری را، تا چه زمانی انجام می‌دهد تا تجربه مشتری قربانی ابهام داخلی نشود.
مهر ۹, ۱۴۰۳

مدل‌سازی تمرینات ITIL‌ با BPMN

مدل‌سازی تمرینات ITIL‌ با BPMN مدل‌سازی فرآیندها مانند نقاشی یک تابلو است؛ با هر جزئیات کوچک، تصویر کلی بهتر و واضح‌تر می‌شود. در دنیای امروز، جایی که سازمان‌ها با چالش‌های پیچیده و تغییرات سریع مواجه هستند، بهینه‌سازی فرآیندهای کسب‌وکار به یک ضرورت بدل شده است. در این راستا، ITIL (کتابخانه زیرساخت فناوری اطلاعات) به عنوان یک چارچوب معتبر برای مدیریت خدمات فناوری اطلاعات شناخته می‌شود. این چارچوب به سازمان‌ها کمک می‌کند تا خدمات خود را بهبود بخشند، کیفیت را افزایش دهند و تجربه مشتری را ارتقا دهند. از سوی دیگر، BPMN (مدل‌سازی و نشانه‌گذاری فرآیندهای کسب‌وکار) به عنوان ابزاری قدرتمند برای طراحی و مستندسازی فرآیندها به کار می‌رود. با استفاده از BPMN، سازمان‌ها می‌توانند فرآیندهای پیچیده خود را به شکل بصری و قابل فهمی مدل‌سازی کنند، که این کار به تحلیل، بهینه‌سازی و حتی اتوماسیون فرآیندها کمک می‌کند. ارتباط این دو مفهوم در این است که BPMN به عنوان یک زبان استاندارد و گرافیکی، ابزاری ایده‌آل برای پیاده‌سازی و مستندسازی فرآیندهای ITIL فراهم می‌کند. با ترکیب این دو، سازمان‌ها قادر خواهند بود تا نه‌تنها فرآیندهای خود را به شکل مؤثری مدیریت کنند، بلکه از طریق شبیه‌سازی و تجزیه و تحلیل بصری، به بهبود مستمر و تصمیم‌گیری‌های بهتر دست یابند. این هم‌افزایی بین ITIL و BPMN نه تنها می‌تواند به سازمان‌ها در بهینه‌سازی فرآیندها کمک کند، بلکه موجب تسهیل ارتباط بین تیم‌ها و ذینفعان مختلف می‌شود و در نهایت به خلق ارزش بیشتر برای مشتریان و ذینفعان می‌انجامد. ادامه مطلب در صفحه بعدی…