MedaNet Journal

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

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

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

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

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

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

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

  • DLP چیست؟

    دستگاه‌های جلوگیری از نشت داده‌ها (Data Loss Prevention یا DLP) مجموعه‌ای از ابزارها و رویه‌ها هستند که برای محافظت از اطلاعات حساس و جلوگیری از نشت یا دسترسی…

    ادامه مقاله

  • Workaround چیست؟

    Workaround یا «راه‌حل موقت» روشی است که اثر یک Incident یا Problem را کاهش می‌دهد یا موقتاً حذف می‌کند، بدون اینکه علت اصلی الزاماً برطرف شده باشد. Workaround…

    ادامه مقاله

  • Escalation چیست؟

    Escalation در ITSM یعنی ارجاع کنترل‌شده یک Incident، Request یا Problem به سطحی دیگر؛ زمانی که تیم فعلی مهارت، اختیار یا زمان کافی برای حل آن ندارد. هدف…

    ادامه مقاله

  • 5Why چیست؟

    5 Why یا «پنج چرا» یک تکنیک ساده برای تحلیل علت ریشه‌ای (RCA) است. در این روش، پس از مشاهده یک مشکل، چند بار پیاپی می‌پرسیم «چرا این…

    ادامه مقاله

  • RCA چیست؟

    RCA (Root Cause Analysis) یا «تحلیل علت ریشه‌ای» روشی ساختاریافته برای فهمیدن این است که چرا یک Incident یا Problem رخ داده و چه اقداماتی می‌تواند احتمال تکرار…

    ادامه مقاله

  • Kubernetes چیست؟

    Kubernetes یک سیستم متن‌باز برای مدیریت و ارکستراسیون کانتینرها است که به‌طور گسترده در دنیای فناوری اطلاعات استفاده می‌شود. این پلتفرم توسط گوگل توسعه یافته و به توسعه‌دهندگان…

    ادامه مقاله

  • Docker چیست؟

    Docker یک پلتفرم محفظه‌سازی است که به توسعه‌دهندگان و مدیران سیستم اجازه می‌دهد تا نرم‌افزارها را در محیط‌های ایزوله و مستقل از سیستم‌عامل اجرا کنند. این پلتفرم با…

    ادامه مقاله

  • هر خدمتی، سرویس نیست!

    هر خدمتی، سرویس نیست! سرویس یا خدمت مبحث بسیار مهمی است چیستی و چرایی‌اش تمام فنداسیون فعالیت ماست. تعریف “سرویس” به طور کلی به معنای ارائه خدمات یا…

    ادامه مقاله

  • پیشنهاد نگار چالاک!

    پیشنهاد نگار چالاک! #نگار_چالاک، مدیر خلاق و پرانرژی تیم توسعه نرم‌افزار در شرکت #آرمان‌‌_خواه_پرتلاش، به‌تازگی متوجه شد که یکی از قابلیت‌های قدیمی برنامه، یعنی امکان چاپ اطلاعات سازمان…

    ادامه مقاله

  • سیستم ارزش خدمات (Service Value System – SVS) در ITIL 4

    سیستم ارزش خدمات (Service Value System – SVS) در ITIL 4 سیستم ارزش خدمات (SVS) قلب چارچوب ITIL4 است و به عنوان یک مدل جامع برای مدیریت خدمات…

    ادامه مقاله

  • SLA چیست؟

    SLA (Service Level Agreement) یا توافق‌نامه سطح خدمات، سندی رسمی میان ارائه‌دهنده و دریافت‌کننده خدمت است که انتظارات، مسئولیت‌ها و شاخص‌های قابل‌اندازه‌گیری سرویس را مشخص می‌کند. معیارهایی مانند…

    ادامه مقاله

  • Known Error چیست؟

    Known Error یا «خطای شناخته‌شده» در ITIL به Problemی گفته می‌شود که تحلیل شده، اما هنوز به‌طور کامل برطرف نشده است. ممکن است برای آن Workaround وجود داشته…

    ادامه مقاله

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 نه تنها می‌تواند به سازمان‌ها در بهینه‌سازی فرآیندها کمک کند، بلکه موجب تسهیل ارتباط بین تیم‌ها و ذینفعان مختلف می‌شود و در نهایت به خلق ارزش بیشتر برای مشتریان و ذینفعان می‌انجامد. ادامه مطلب در صفحه بعدی…