MedaNet Journal

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

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

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

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

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

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

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

  • ManageEngine چیست؟

    ManageEngine، یک شرکت هندی و بعنوان بخشی از هلدینگ بزرگ Zoho Corp. است که به سازمان‌ها کمک می‌کند تا مدیریت فناوری اطلاعات خود را به روشی ساده، یکپارچه…

    ادامه مقاله

  • ServiceDesk Plus چیست؟

    نرم‌افزار ServiceDesk Plus یک سیستم مدیریت خدمات ITSM و ESM‌ مبتنی بر ITIL است که توسط شرکت ManageEngine از هلدینگ زوهو ارایه شده؛ که به سازمان‌ها کمک می‌کند…

    ادامه مقاله

  • ServiceDesk چیست؟

    ServiceDesk یا میز خدمت، یک سیستم مرکزی است که برای مدیریت درخواست‌ها، مشکلات و پشتیبانی کاربران در سازمان‌ها طراحی شده است. این سیستم به‌ویژه در حوزه فناوری اطلاعات…

    ادامه مقاله

  • میز خدمت چیست؟ Service Desk در ITSM و ESM چه کاری انجام می‌دهد؟

    میز خدمت یا Service Desk نقطه تماس مرکزی کاربران با ارائه‌دهنده خدمت است. تفاوت Service Desk با Help Desk، نقش آن در ITSM و ESM، KPIها و اجزای…

    ادامه مقاله

  • Ulaa امن‌ترین مرورگر دنیا!

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

    ادامه مقاله

  • SOC چیست؟

    SOC یا مرکز عملیات امنیتی (Security Operations Center) یک واحد تخصصی است که وظیفه آن نظارت، تحلیل، و پاسخ به تهدیدات امنیتی در سازمان‌ها است. این مرکز از…

    ادامه مقاله

  • RCSI چیست؟

    RCSI یا Read Committed Snapshot Isolation یک حالت ایزولیشن در پایگاه داده‌های SQL Server است که مدل همزمانی خوش‌بینانه را فعال می‌کند. این قابلیت به تراکنش‌ها اجازه می‌دهد…

    ادامه مقاله

  • راز سرعت و دقت در دیتابیس با RCSI

    فرض کنید یک فروشگاه آنلاین به‌طور همزمان چندین تراکنش از کاربران دریافت می‌کند: برای این دو سناریو، دو مدل بدبینانه و خوش‌بینانه در دیتابیس‌ها لحاظ شده. که هر…

    ادامه مقاله

  • Benchmarking چیست؟

    بنچمارکینگ (Benchmarking) به فرآیند مقایسه و ارزیابی عملکرد یک سازمان با استانداردهای صنعتی یا بهترین شیوه‌های موجود در بازار گفته می‌شود. بنچمارکینگ فرآیند مقایسه عملکرد سازمان با بهترین…

    ادامه مقاله

  • PCF چیست؟

    PCF (Process Classification Framework) یک مدل استاندارد برای شناسایی، طبقه‌بندی، و بهبود فرآیندهای کسب‌وکار است که توسط APQC (American Productivity & Quality Center) توسعه یافته است. این مدل…

    ادامه مقاله

  • تحول سازمانی از APQC به ITIL4

    مدیرعامل یک شرکت بزرگ و معتبر تصمیم گرفت که مسیر جدیدی برای تحول سازمانی انتخاب کند. او به دنبال روشی بود که بتواند در همه‌ی بخش‌ها، از بخش…

    ادامه مقاله

  • PwC چیست؟

    PwC (PricewaterhouseCoopers) یکی از بزرگ‌ترین شرکت‌های مشاوره و حسابرسی در جهان است که در بیش از ۱۵۰ کشور فعالیت دارد. این شرکت در زمینه‌های حسابرسی، مشاوره استراتژیک، مالی،…

    ادامه مقاله

KEEP LEARNING

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

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

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

DLP چیست؟

دستگاه‌های جلوگیری از نشت داده‌ها (Data Loss Prevention یا DLP) مجموعه‌ای از ابزارها و رویه‌ها هستند که برای محافظت از اطلاعات حساس و جلوگیری از نشت یا دسترسی غیرمجاز به آن‌ها طراحی شده‌اند. DLP به سازمان‌ها کمک می‌کند تا داده‌های حیاتی را شناسایی کنند و از امنیت آن‌ها در برابر تهدیدات داخلی و خارجی اطمینان حاصل نمایند. با استفاده از این فناوری، می‌توان داده‌ها را در حین ذخیره‌سازی، انتقال و پردازش تحت نظر قرار داد و هرگونه نقض امنیتی را شناسایی و مدیریت کرد. یکی از ویژگی‌های کلیدی DLP، توانایی شناسایی اطلاعات حساس مانند شماره‌های شناسایی، اطلاعات مالی و داده‌های شخصی است. این سیستم‌ها با تجزیه و تحلیل الگوها و رفتارهای کاربران، می‌توانند فعالیت‌های مشکوک را شناسایی کنند و به‌سرعت به آن‌ها واکنش نشان دهند. علاوه بر این، DLP می‌تواند سیاست‌های امنیتی خاصی را به‌طور خودکار پیاده‌سازی کند، به‌طوری که در صورت نقض امنیتی، اقدامات لازم مانند مسدود کردن دسترسی یا رمزگذاری داده‌ها انجام شود. در نهایت، استفاده از DLP به سازمان‌ها این امکان را می‌دهد که به‌طور مؤثری از دارایی‌های اطلاعاتی خود محافظت کنند و با رعایت مقررات مربوط به حفظ حریم خصوصی و امنیت داده‌ها، اعتبار و اعتماد مشتریان را حفظ نمایند. با توجه به رشد روزافزون تهدیدات سایبری، پیاده‌سازی DLP به‌عنوان بخشی از استراتژی کلی امنیت اطلاعات به‌ویژه در سازمان‌های بزرگ و پیچیده، امری ضروری است. این فناوری به ایجاد یک محیط کاری امن و کارآمد کمک می‌کند و از بروز مشکلات ناشی از نشت داده‌ها جلوگیری می‌نماید.
مهر ۱۲, ۱۴۰۳

Workaround چیست؟

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

Escalation چیست؟

Escalation در ITSM یعنی ارجاع کنترل‌شده یک Incident، Request یا Problem به سطحی دیگر؛ زمانی که تیم فعلی مهارت، اختیار یا زمان کافی برای حل آن ندارد. هدف تشدید این نیست که «تیکت را پاس بدهیم»، بلکه باید شانس حل سریع‌تر و جلوگیری از نقض SLA را افزایش دهد. دو نوع اصلی Escalation Functional Escalation یعنی ارجاع موضوع به فرد یا تیمی با تخصص فنی بالاتر؛ مثلاً انتقال یک Incident شبکه از Service Desk به تیم Network. Hierarchical Escalation یعنی ورود سطح مدیریتی بالاتر به دلیل ریسک، اثر کسب‌وکار، تأخیر یا نیاز به تصمیم و اختیار بیشتر. نوع چه زمانی؟ مثال Functional کمبود دانش یا دسترسی فنی ارجاع خطای Database از L1 به DBA Hierarchical ریسک، تأخیر یا اثر تجاری بالا اطلاع به IT Manager درباره Incident بحرانی Escalation چه زمانی باید انجام شود؟ وقتی زمان پاسخ یا حل به آستانه SLA نزدیک می‌شود. وقتی تیم فعلی مهارت یا دسترسی لازم را ندارد. وقتی Incident چند سرویس یا تعداد زیادی کاربر را تحت تأثیر قرار داده است. وقتی تصمیمی مدیریتی، امنیتی یا مالی لازم است. وقتی یک مشکل تکرارشونده بدون Root Cause روشن باقی مانده است. یک سناریوی ساده فرض کنید کاربران واحد مالی به ERP دسترسی ندارند. Service Desk بررسی اولیه را انجام می‌دهد، اما مشکل به Database مربوط است؛ اینجا Functional Escalation به DBA انجام می‌شود. اگر اختلال ادامه پیدا کند و پایان ماه مالی در خطر باشد، مدیر فناوری هم وارد جریان می‌شود؛ این بخش Hierarchical Escalation است. Escalation و SLA یک فرایند Escalation خوب باید قبل از نقض SLA فعال شود، نه بعد از آن. در ابزارهایی مثل ServiceDesk Plus می‌توان Ruleهای Escalation را بر اساس Priority، زمان پاسخ، زمان حل و گروه پشتیبانی تعریف کرد. برای درک بهتر ساختار تیم نیز مقاله شرح وظایف کارشناس میز خدمت و سطوح L1/L2/L3 مفید است. اشتباه رایج اگر Escalation بیش از حد زود انجام شود، تیم‌های تخصصی غرق تیکت‌های ساده می‌شوند؛ اگر بیش از حد دیر انجام شود، SLA و تجربه کاربر آسیب می‌بیند. نقطه درست، تعریف معیارهای روشن برای زمان، Priority، Impact و Ownership است. سخن پایانی Escalation موفق یعنی رساندن مسئله به «سطح درست» در «زمان درست». هرچه مسیر ارجاع، مالکیت و آستانه‌های SLA شفاف‌تر باشند، زمان حل کمتر و تجربه کاربر بهتر خواهد بود.
مهر ۱۲, ۱۴۰۳

5Why چیست؟

5 Why یا «پنج چرا» یک تکنیک ساده برای تحلیل علت ریشه‌ای (RCA) است. در این روش، پس از مشاهده یک مشکل، چند بار پیاپی می‌پرسیم «چرا این اتفاق افتاد؟» تا از نشانه ظاهری عبور کنیم و به علت بنیادی نزدیک شویم. عدد پنج یک قانون سخت نیست؛ ممکن است در یک مسئله با سه پرسش به علت برسیم یا برای مسئله‌ای پیچیده‌تر به بررسی بیشتری نیاز باشد. مهم این است که پاسخ‌ها بر شواهد تکیه کنند، نه حدس. برای آموزش کامل، مثال مرحله‌به‌مرحله و مقایسه 5 Why با سایر روش‌های تحلیل مشکل، مقاله تکنیک پنج چرا برای شناسایی علت ریشه‌ای را بخوانید.
مهر ۱۲, ۱۴۰۳

RCA چیست؟

RCA (Root Cause Analysis) یا «تحلیل علت ریشه‌ای» روشی ساختاریافته برای فهمیدن این است که چرا یک Incident یا Problem رخ داده و چه اقداماتی می‌تواند احتمال تکرار آن را کاهش دهد. هدف RCA فقط پیدا کردن «یک مقصر» نیست؛ هدف شناخت علت‌ها و شرایطی است که وقوع مشکل را ممکن کرده‌اند. RCA چه تفاوتی با رفع Incident دارد؟ در Incident Management اولویت معمولاً بازگرداندن سریع سرویس است. ممکن است با Restart، Failover یا یک Workaround سرویس دوباره در دسترس قرار گیرد، اما این به معنی حذف علت اصلی نیست. RCA بیشتر در Problem Management کاربرد دارد تا مشخص شود چرا اختلال رخ داده و چه تغییر پایداری باید انجام شود. مراحل ساده تحلیل علت ریشه‌ای مسئله را دقیق تعریف کنید: چه سرویس یا فرایندی، از چه زمانی و با چه اثری مختل شد؟ شواهد جمع کنید: Log، Timeline، Change History، Alert، Ticket و اظهارات تیم‌های درگیر. علت‌های محتمل را بررسی کنید: به یک پاسخ سریع اکتفا نکنید؛ مشکل ممکن است چند علت فنی و سازمانی داشته باشد. فرضیه را با داده آزمایش کنید: بین همبستگی و علت واقعی تفاوت بگذارید. اقدام اصلاحی تعریف کنید: Permanent Fix، تغییر فرایند، کنترل پیشگیرانه یا Monitoring بهتر. نتیجه را پایش کنید: بررسی کنید آیا Incident واقعاً کمتر شده و اقدام جدید عارضه دیگری ایجاد نکرده است. تکنیک‌های رایج RCA 5 Why برای مسائل نسبتاً ساده و خطی مفید است؛ نمودار علت و معلول یا Fishbone می‌تواند دسته‌های مختلف علت را هم‌زمان بررسی کند؛ Timeline Analysis نیز برای Incidentهای پیچیده‌ای که چند رویداد پشت سر هم رخ داده‌اند مناسب است. در مسائل پیچیده، اصرار بر اینکه حتماً فقط «یک علت ریشه‌ای» وجود دارد می‌تواند تحلیل را بیش از حد ساده کند. مثال RCA در ITSM فرض کنید پورتال سازمان هر دوشنبه صبح کند می‌شود. Restart کردن Application Server مشکل را موقتاً رفع می‌کند، اما Incident هفته بعد تکرار می‌شود. بررسی Timeline و Metrics نشان می‌دهد یک Job گزارش‌گیری هم‌زمان با اوج ورود کاربران، Query سنگینی روی Database اجرا می‌کند. اقدام پایدار می‌تواند زمان‌بندی مجدد Job، بهینه‌سازی Query و ایجاد Alert برای زمان پاسخ Database باشد؛ نه صرفاً Restart هفتگی. RCA، Known Error و Workaround اگر Problem تحلیل شده ولی هنوز Permanent Fix آماده نباشد، می‌توان آن را به‌عنوان Known Error مدیریت کرد و Workaround مناسب را در اختیار Service Desk گذاشت. به این ترتیب تیم پشتیبانی اثر Incidentهای تکراری را سریع‌تر کاهش می‌دهد، در حالی که رفع ریشه‌ای همچنان پیگیری می‌شود. سخن پایانی RCA زمانی ارزشمند است که از «چرا خراب شد؟» به «چه چیزی در سیستم، فرایند یا تصمیم‌گیری باید تغییر کند تا دوباره تکرار نشود؟» برسد. خروجی خوب RCA باید قابل اقدام، قابل اندازه‌گیری و قابل پیگیری باشد.