MedaNet Journal

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

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

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

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

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

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

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

KEEP LEARNING

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

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

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

CI چیست؟

CI مخفف Configuration Item یا «قلم پیکربندی» است. در ITIL، هر جزء مهمی که برای ارائه یک خدمت باید مدیریت، کنترل یا ردیابی شود می‌تواند یک CI باشد؛ از سرور و نرم‌افزار گرفته تا سرویس کسب‌وکار، قرارداد، مستندات یا حتی ارتباط میان اجزا. CI صرفاً یک دارایی نیست. ممکن است یک دارایی ارزش مالی داشته باشد اما برای مدیریت پیکربندی اهمیت عملیاتی نداشته باشد؛ برعکس، یک سرویس یا Relationship ممکن است دارایی مالی محسوب نشود اما برای تحلیل اثر تغییر و رخداد حیاتی باشد. مثال‌های CI در فناوری اطلاعات سرور، لپ‌تاپ، سوئیچ، روتر و تجهیزات زیرساختی سیستم‌عامل، Database، Middleware و نرم‌افزارهای سازمانی Application، Business Service و سرویس‌های حیاتی مستندات، قراردادها و برخی اقلام کنترلی مرتبط با خدمت Relationship میان CIها؛ مثلاً وابستگی یک Application به Database و Server CI چه ارتباطی با CMDB دارد؟ CMDB پایگاهی برای نگهداری اطلاعات CIها و رابطه میان آن‌هاست. ارزش CMDB فقط در تعداد رکوردها نیست؛ مهم این است که بدانیم هر CI به چه سرویس، کاربر، تیم یا CI دیگری وابسته است. همین Relationshipها هستند که در Incident، Problem و Change به تحلیل اثر کمک می‌کنند. تفاوت CI و Asset چیست؟ Asset بیشتر از زاویه مالکیت، هزینه، قرارداد، Lifecycle و ارزش مالی دیده می‌شود؛ اما CI از زاویه کنترل پیکربندی و اثر آن بر خدمت اهمیت دارد. یک لپ‌تاپ می‌تواند هم Asset باشد و هم CI، ولی یک Business Service یا Relationship معمولاً CI است بدون اینکه Asset مالی محسوب شود. CI در مدیریت تغییر چه نقشی دارد؟ هنگام ثبت Change، مشخص‌کردن CIهای تحت تأثیر کمک می‌کند Blast Radius تغییر قبل از اجرا دیده شود. اگر یک Database به چند سرویس حیاتی وابسته باشد، تغییر روی آن باید با دقت بیشتری ارزیابی شود. برای همین CI و Relationshipها در تصمیم‌گیری CAB و تحلیل ریسک تغییر اهمیت مستقیم دارند. در ابزارهایی مانند ServiceDesk Plus، CIها می‌توانند به رخداد، مشکل، تغییر و سرویس مرتبط شوند تا تیم IT به‌جای نگاه جزیره‌ای، اثر هر اختلال یا تغییر را در سطح سرویس ببیند. سخن پایانی CI واحد پایه مدیریت پیکربندی است. اگر CIها، ویژگی‌هایشان و Relationship میان آن‌ها دقیق نباشد، CMDB فقط یک فهرست بزرگ خواهد بود؛ اما وقتی داده درست باشد، CI به یکی از مهم‌ترین ورودی‌های Incident، Problem، Change و Service Impact Analysis تبدیل می‌شود.
مهر ۱۲, ۱۴۰۳

EULA چیست؟

توافق‌نامه مجوز کاربر نهایی (End User License Agreement یا EULA) یک قرارداد قانونی است که شرایط و مقررات استفاده از نرم‌افزار یا محصول دیجیتال را مشخص می‌کند. این توافق‌نامه معمولاً بین تولیدکننده یا توزیع‌کننده نرم‌افزار و کاربر نهایی منعقد می‌شود و به کاربر این حق را می‌دهد که نرم‌افزار را در شرایط خاصی استفاده کند. EULA شامل جزئیاتی مانند محدودیت‌های استفاده، حقوق مالکیت معنوی، و شرایط پایان استفاده از نرم‌افزار می‌باشد. EULA به تولیدکنندگان نرم‌افزار این امکان را می‌دهد که حقوق خود را حفظ کرده و از سوءاستفاده از محصولات خود جلوگیری کنند. این توافق‌نامه ممکن است شامل بندهایی درباره مسئولیت‌پذیری، شرایط لغو، و نحوه مدیریت مشکلات یا حوادث نیز باشد. همچنین، با توجه به قوانین حقوقی مختلف در کشورها، EULA ممکن است به‌طور خاص طراحی شود تا از سازگاری با قوانین محلی اطمینان حاصل کند. در نهایت، EULA به کاربر نهایی اطلاعات مهمی درباره نحوه استفاده مجاز از نرم‌افزار ارائه می‌دهد و مسئولیت‌های کاربر را مشخص می‌کند.
مهر ۱۲, ۱۴۰۳

BYOD چیست؟

مفهوم «Bring Your Own Device» (BYOD) به سیاستی اشاره دارد که به کارکنان اجازه می‌دهد از دستگاه‌های شخصی خود، مانند تلفن‌های هوشمند، تبلت‌ها و لپ‌تاپ‌ها، برای انجام کارهای مرتبط با سازمان استفاده کنند. این رویکرد به‌ویژه با پیشرفت تکنولوژی و افزایش قابلیت‌های دستگاه‌های شخصی، در محیط‌های کاری رایج شده است. BYOD می‌تواند به افزایش بهره‌وری و رضایت شغلی کارکنان منجر شود، زیرا آن‌ها می‌توانند از ابزارهایی که با آن‌ها راحت‌تر هستند، استفاده کنند. استفاده از سیاست BYOD مزایای زیادی دارد، از جمله کاهش هزینه‌های سخت‌افزاری برای سازمان و امکان دسترسی به اطلاعات و خدمات سازمانی در هر زمان و مکان. با این حال، BYOD همچنین چالش‌هایی را در زمینه امنیت اطلاعات ایجاد می‌کند. هنگامی که دستگاه‌های شخصی به شبکه سازمان متصل می‌شوند، خطر نشت اطلاعات و تهدیدات امنیتی افزایش می‌یابد. بنابراین، سازمان‌ها باید سیاست‌ها و رویه‌های امنیتی مناسبی را برای مدیریت دسترسی و حفاظت از داده‌های حساس توسعه دهند.
مهر ۱۲, ۱۴۰۳

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

CAB (Change Advisory Board) یا هیئت مشورتی تغییر، گروهی از افراد کلیدی سازمان است که تغییرات مهم در سرویس‌ها و زیرساخت‌های IT را بررسی می‌کند تا تصمیم‌گیری فقط بر اساس نظر یک تیم فنی انجام نشود. CAB به سازمان کمک می‌کند قبل از اجرای تغییر، اثر آن بر سرویس، امنیت، کاربران، هزینه و ریسک عملیاتی دیده شود. در عمل، CAB معمولاً با درخواست‌های تغییر یا RFC سروکار دارد. یک تغییر ممکن است از ارتقای نسخه نرم‌افزار تا تغییر تنظیمات شبکه، جابه‌جایی سرور، اصلاح Rule امنیتی یا تغییر در یک سرویس حیاتی باشد. هرچه اثر تغییر بیشتر باشد، نیاز به بررسی بین‌تیمی هم بیشتر می‌شود. CAB دقیقاً چه کاری انجام می‌دهد؟ بررسی RFC: هدف، دامنه، زمان‌بندی و دلیل تغییر بررسی می‌شود. ارزیابی ریسک: احتمال اختلال، شکست، اثر امنیتی و پیامدهای کسب‌وکار سنجیده می‌شود. بررسی وابستگی‌ها: مشخص می‌شود تغییر روی چه سرویس‌ها، CIها، تیم‌ها یا کاربران دیگری اثر دارد. بررسی Rollback: اگر تغییر شکست خورد، مسیر بازگشت باید روشن باشد. هماهنگی زمان اجرا: تغییر در بازه‌ای انجام می‌شود که کمترین اثر را روی سرویس‌های حیاتی داشته باشد. ارائه توصیه: CAB می‌تواند اجرای تغییر را توصیه کند، اصلاح بخواهد یا اجرای آن را به زمان دیگری موکول کند. چه کسانی عضو CAB هستند؟ ترکیب CAB ثابت نیست و به نوع تغییر بستگی دارد. معمولاً Change Manager، نماینده Service Desk، تیم زیرساخت، امنیت، مالک سرویس، نماینده کسب‌وکار و در صورت نیاز تیم توسعه یا تأمین‌کننده در جلسه حضور دارند. نکته مهم این است که CAB نباید به جلسه‌ای با ده‌ها عضو ثابت تبدیل شود؛ افراد باید بر اساس ریسک و موضوع تغییر انتخاب شوند. CAB در ITIL چه جایگاهی دارد؟ در چارچوب ITIL، هدف مدیریت تغییر این نیست که هر تغییر حتماً از یک جلسه رسمی عبور کند؛ هدف این است که تغییرات با سطح مناسبی از کنترل و ریسک مدیریت شوند. بنابراین تغییرهای استاندارد و کم‌ریسک می‌توانند مسیر از پیش‌تأییدشده داشته باشند، درحالی‌که تغییرهای پرریسک یا دارای اثر گسترده نیازمند بررسی جدی‌تر هستند. اگر در حال بازنگری فرآیندهای مدیریت خدمات هستید، مقاله ITIL 5 چیست؟ هم تصویر جدیدتری از ارتباط Service Desk، عملیات، امنیت و Governance ارائه می‌دهد. تفاوت CAB با Emergency CAB یا ECAB چیست؟ ECAB برای شرایطی است که تغییر اضطراری باید سریع‌تر بررسی شود؛ مثلاً زمانی که یک آسیب‌پذیری بحرانی، اختلال گسترده یا مشکل جدی امنیتی وجود دارد. در این حالت هم کنترل حذف نمی‌شود، بلکه فرآیند تصمیم‌گیری فشرده‌تر و اعضای درگیر محدودتر می‌شوند. یک CAB خوب چه ویژگی‌هایی دارد؟ جلسه فقط برای تغییرهایی برگزار می‌شود که واقعاً به بررسی نیاز دارند. اطلاعات RFC قبل از جلسه کامل است. اثر روی سرویس و کسب‌وکار مشخص است. Plan اجرا، Test Plan و Rollback Plan وجود دارد. تصمیم‌ها و دلایل آن‌ها ثبت می‌شوند. بعد از تغییرهای مهم، نتیجه و میزان موفقیت بررسی می‌شود. اشتباه رایج درباره CAB یکی از اشتباهات رایج این است که CAB به گلوگاه تبدیل شود و هر تغییر کوچک برای تأیید به جلسه برود. نتیجه چنین مدلی معمولاً کندی، صف تغییر و دور زدن فرآیند است. CAB زمانی ارزش دارد که سطح کنترل متناسب با ریسک باشد؛ نه اینکه برای همه تغییرها یک نسخه واحد اجرا شود. سخن پایانی CAB قرار نیست صرفاً یک جلسه تأیید باشد. وظیفه اصلی آن این است که سازمان قبل از اجرای تغییرهای مهم، تصویر کامل‌تری از ریسک، وابستگی‌ها و اثر کسب‌وکاری داشته باشد. هرچه اطلاعات CMDB، مالکیت سرویس و فرآیند Change Management دقیق‌تر باشد، تصمیم‌های CAB هم سریع‌تر و قابل‌دفاع‌تر می‌شوند.
مهر ۱۲, ۱۴۰۳

MTTR چیست؟

MTTR در ITSM معمولاً برای سنجش سرعت بازگرداندن خدمت پس از Incident یا خرابی استفاده می‌شود. نکته مهم این است که این اختصار بسته به سازمان می‌تواند به Mean Time to Repair، Mean Time to Restore یا Mean Time to Resolve اشاره کند؛ بنابراین قبل از مقایسه KPIها باید تعریف دقیق آن مشخص باشد. فرمول MTTR MTTR = مجموع زمان صرف‌شده برای بازیابی یا حل / تعداد رخدادهای بررسی‌شده اگر چهار Incident در مجموع ۸ ساعت زمان تا بازیابی داشته باشند، MTTR برابر ۲ ساعت است. اما این عدد فقط زمانی قابل مقایسه است که دامنه اندازه‌گیری، Priority و نقطه شروع و پایان در همه رخدادها یکسان تعریف شده باشد. Repair، Restore و Resolve چه تفاوتی دارند؟ تعریف تمرکز Mean Time to Repair زمان تعمیر مؤلفه خراب Mean Time to Restore زمان بازگرداندن خدمت به وضعیت قابل استفاده Mean Time to Resolve زمان تا حل کامل Incident چطور MTTR را کاهش دهیم؟ بهبود Monitoring و تشخیص سریع‌تر Incident تعریف Assignment و Escalation روشن استفاده از Runbook و Knowledge Base خودکارسازی کارهای تکراری Recovery تحلیل Incidentهای پرتکرار و اتصال آن‌ها به Problem Management برای کاربرد MTTR در نگهداری تجهیزات، صفحه MTTR در نگهداری و تعمیرات را ببینید. سخن پایانی MTTR زمانی معنا دارد که تعریفش ثابت باشد. اگر یک تیم «Restore» و تیم دیگر «Resolve» را اندازه بگیرد، مقایسه عددها بیشتر گمراه‌کننده است تا مدیریتی.