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

مدیریت دانش کارآمد

مدیریت دانش، می تواند اطمینان حاصل کند که اطلاعات مناسب برای افرادی که به آن نیاز دارند در دسترس خواهد بود و برای آنها ارزشمند خواهد بود. این امر می تواند به بهبود مدیریت حادثه کمک کند و به شما اجازه می دهد تا برای سرویس دهی خدمات خود به اطلاعاتی دست یابید که کمک حال است و مفید! تا سریعتر به تصادفات برسید. همچنین می تواند برای پشتیبانی از یک پورتال خود خدمتی یا Self-Service Portal استفاده شود تا کاربران نهایی بتوانند حوادث خود را حل کنند.

مدیریت دانش احتمالا تعداد حوادث را کاهش نخواهد داد، اگرچه ممکن است با ارائه اطلاعات و راهکارها به کاربرانی که نیاز به استفاده از خدمات به طور موثر دارند، تأثیری داشته باشد. آنچه که مدیریت دانش در حقیقت قرار است انجام دهد:

• کاهش قابل توجهی از تاثیرات تجاری در حوادث
• و کاهش هزینه های IT برای مدیریت این حوادث.

یک رویکرد بسیار موثر در استفاده از مدیریت دانش در فناوری اطلاعات سازمان ها ، پشتیبانی دانش محور (KCSsm) است. شما به یک پروژه بزرگ نیاز ندارید تا شروع کنید به بهبود چگونگی مدیریت دانش، بنابراین ایجاد یک پروژه بزرگ بنام مستند سازی و تولید راهکار و مدیریت دانش در ابتدای کار، نفس گیر و ناکاؤامد خواهد بود.

مدیریت دانش بصورت منطقه ای است یعنی در هر حوزه و در هر بخش متفاوت خواهد بود پس با یک رویکرد هوشمندانه در مدیریت خدمات IT می تواند به خوبی کار کند. پس برای بهره مندی از مدیرت دانش کارآمد، فکر کنید که این دانش چه چیزی را بهبود می بخشد و ببیند که چگونه می توانید آن را فراهم کنید، سپس به دنبال دانش بیشتری باشید تا ارزش بیشتری را ایجاد کنید. در نهایت شما ممکن است نیاز به سرمایه گذاری در ابزار و فرآیند رسمی تر داشته باشید، اما با چیزی ساده شروع کنید.

فرهنگ مستند سازی، ارایه راهکار قدم اول در مدیریت پایگاه دانش از کلیدی ترین گامهاست بنابراین انرژی کاملی را همان ابتدای کار بر روی این موضوع نگذارد زمانیکه این فرهنگ نهادینه شد آنگاه سراغ ابزارها و راهکارهای حرفه ای برای تولید و مستندسازی راه حل ها بروید تا استاندارد کار کنید.

مدیریت تغییر کارآمد

در بسیاری از فناوری اطلاعات سازمان ها، بزرگترین علت شکست سرویس، تغییراتی است که اشتباه است. برآورد اینکه چه میزان از حوادث ناشی از تغییر است متفاوت است، اما من شخصا، بیش از ۸۰٪ کاهش در حوادث ناشی از تغییر در یک سازمان را دیده ام، بنابراین مدیریت صحیح تغییر می تواند نتایج بسیار قابل توجه ای ارایه کند.

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

فراموش نکنید بخش عظیمی از حوادث ناشی از تغییرات خودسرانه در سرویسها و زیرساخت هاست که علاوه بر پیامدهای منفی، فرکانس تکرار حوادث جدیدی را افزایش و سبب نارضایتی مشتری و در نهایت شکست تغییر می شود.

طراحی خدمات کارآمد

بهترین کاری که می توانید برای کاهش فرکانس و تاثیر حوادث انجام دهید این است که اولویت خدمات خود را طراحی کنید، اما به دلایلی، بسیاری از فناوری اطلاعات سازمان ها، تصمیم به سرمایه گذاری در برنامه ریزی برای جلوگیری از شکست نمی کنند، ترجیح می دهند که پول خود را برای به حالت عادی درآوردن وضعیت پس از وقوع حوادث نمایند!

ITIL فرآیندهایی را برای مدیریت دسترسی و مدیریت ظرفیت ارایه کرده اما تعداد کمی از سازمان ها خدمات در دسترس را فراهم می کنند و بیشتر کار مدیریت ظرفیت آنها، صرفا فنی است و داده های کسب و کار کمی برای پیش بینی واقعی نیازهای آینده فراهم می کنند.

چیزهای زیادی وجود دارد که می توان برای بهبود طرح ها انجام داد. ساده ترین طرح ها صرفا این است که مطمئن شوید که کارهای افزونگی و انعطاف پذیری که شما انجام داده اید، در واقع بطور درست کار می کنند. برای مثال دیسک ها ممکن است در مجموعه های RAID پیکربندی شوند، اما هیچ کس متوجه نشده است که یکی از دیسک از کار افتاده! یا ممکن است مرتباً از دیتابیس ها مختلف در حال گرفتن بک آپ هستید بی آنکه بدانید که این بک آپ ها کار میکنند یا خیر!، یا یک شبکه ممکن است لینک های دوگانه بین سایت ها داشته باشد، اما یکی از لینک ها دیگر کار نمی کند و تا زمانی که لینک اصلی از کار نیفتد شما متوجه خرابی لینک مازاد نخواهید شد! در این حال نیاز هست تا یک حسابرسی کارآمد داشته باشید اگر حسابرسی این اقدامات را در محیط خود انجام ندهید، نمی توانید بفهمید که کنترل های فنی شما چگونه کار می کنند – پس با ایجاد PM های منظم و حسابرسی بر تولید فرم های درخواست خدمات، ممکن است خود و مشتری و یا سازمان را از یک خرابی گران نجات دهید! بنابراین شما می توانید یک طرح در دسترس بودن را ایجاد کنید که به طور منظم از همه اقدامات شکست خورده پشتیبانی می کند، به صورت خودکار یا دستی.

یک داستان: در یکی از سازمان های دولتی، که پشتیبانی شبکه را به یک شرکت پیمانکار فناوری سپرده بود و یکی از مهمترین مفاد قرارداد فی مابین آنها، پشتیبان گیری از دیتابیس ۱۰ نرم افزار سازمانی بود که می بایست هر روز تهیه می شد و کارشناسان پشتیبانی پیمانکار هر روز بطور خودکار و منظم این پشتیبان گیری را انجام و بر روی DVD ذخیره می کردند! تا آنکه در یکی از روزها، پورتال این سازمان هک شد و تمامی اطلاعات از بین رفت سریعا پیمانکار در جریان مشکل قرار گرفت و خواست تا آخرین بک آپ را بازگرداند و وضعیت به حالت عادی برگردد غافل از اینکه فایلهای بک آپ کار نمی کند!

تصور کنید چه خرابی بزرگی به پا شده!

نوآوری اخیر در طراحی در دسترس بودن، ایده ایجاد راه حل های ضد شکست است. این یک فلسفه بسیار متفاوت برای مدیریت دسترسی سنتی است. مفهوم اصلی این است که ایجاد راه حل هایی است تا شکست نتواند هرگز موفق نشود! چراکه یک شکست موفق! در نهایت منجر به یک فاجعه با تاثیر عظیم تجاری می شود. پس طراحی یک راه حل ضد شکست همواره همراه با دانش است که همه چیز را ناکام می گذارد، بنابراین با طراحی این راه حل، بهبود بسیار سریع و با حداقل تاثیر بر روی کسب و کار اولویت بسزایی دارد که تمرکز بر زمان متوسط ​​برای بازگرداندن سرویس (MTRS) به جای زمان متوسط ​​بین شکست (MTBF) است. در حالت ایده آل، یک راه حل ضد شکننده، در هنگام وقوع یک شکست به صورت خودکار، وضعیت را  بهبود داده و قبل از اینکه کاربران حتی متوجه شوند که شکستی رخ داده اوضاع را به حالت عادی باز می گرداند.

در سناریو داستان اشاره شده، تست بک آپ های گرفته شده در هر روز ولو بصورت دستی و استفاده از راهکارهایی نظیر SAN یا NAS می توانست آبروی شرکت پیمانکار را بخرد! در حالیکه هیچکدام نبود بخصوص اینکه آن پیمانکار درک درستی از مدیریت دسترسی و طراحی خدمات نداشت!

ادامه مطلب در صفحه بعد…