آیا واقعاً به افزونگی نیاز دارید: هزینه واقعی خرابی سیستم
خرابی سیستم – این واژهای است که هیچکس نمیخواهد بشنود. ترس را به دل کسبوکارها، مدیران اجرایی و بهویژه کارکنان IT میاندازد. خرابی سیستم هزینه دارد و موجب ناامیدی میشود.
چون خرابی سیستم واکنش احساسی برمیانگیزد، کسبوکارها اغلب با آن متفاوت از عوامل سنتی تجاری برخورد میکنند. این رویکرد احساسی باعث میشود کسبوکارها – بهویژه کسبوکارهای کوچکتر که فاقد کنترلهای مالی منطقی هستند – خرابی سیستم را بسیار بدتر از آنچه هست تلقی کنند. جای تعجب نیست که بسیاری از کسبوکارهای کوچکتر در واقع با واکنش به ترس از خرابی احتمالی سیستم، خسارت مالی بیشتری به خود وارد کردهاند تا اگر آن خرابی واقعاً رخ میداد. این یک واکنش بیش از حد خطرناک است.
اولین گام تعیین هزینه خرابی سیستم است. در IT اغلب با سیستمهای نسبتاً پیچیدهای سروکار داریم و خرابی در اشکال مختلفی مانند از دست دادن دسترسی، کاهش کارایی یا از دست دادن کامل یک یا چند سیستم پدیدار میشود. تعیین هر نوع خرابی و هزینههای مرتبط با آن میتواند نسبتاً پیچیده باشد، اما نگاه کلی اغلب برای تهیه بودجههای منطقی کافی است یا حداقل نقطه شروع خوبی برای درک خطرات تجاری مرتبط با خرابی سیستم است. به یاد داشته باشید که همانطور که هزینه زیاد برای جلوگیری از خرابی بد است، هزینه زیاد برای محاسبه هزینههای خرابی هم بد است. آنقدر وقت و منابع صرف تعیین اینکه آیا ضرر میکنید نکنید که بهتر بود آن را میپذیرفتید. از هزینه بالای تصمیمگیری بپرهیزید.
میتوانیم با در نظر گرفتن تنها از دست دادن کامل سیستم شروع کنیم. هزینه خرابی سازمانی برای شما چیست – یعنی اگر مجبور بودید یک ساعت یا یک روز تمام کسبوکار را متوقف کنید چقدر پول از دست میدهید؟ در برخی موارد ضررها میتوانند چشمگیر باشند، مانند بیمارستانی که یک روز خرابی منجر به از دست دادن اعتماد و مشتریان آینده و احتمالاً شکایتهای حقوقی میشود. اما در بسیاری از موارد یک روز خرابی ممکن است تأثیر مالی اندکی داشته باشد – بسیاری از کسبوکارها میتوانند آن روز را تعطیل اعلام کنند، به کارمندان استراحت بدهند و در روزهای بعد کمی سختتر کار کنند تا کمبود آن روز را جبران کنند. همه چیز به نحوه عملکرد کسبوکار شما و میزان توانایی شما در کاهش اثر زمان از دست رفته بستگی دارد. بسیاری از کسبوکارها تنها به ارقام درآمد روزانه برای تعیین درآمد از دست رفته نگاه میکنند، اما این میتواند گمراهکننده باشد.
وقتی برآورد تقریبی از هزینه خرابی داشتیم، میتوانیم خطر خرابی را نیز بسنجیم. این کار بسیار دشوار است، زیرا اطلاعات خوب در مورد قابلیت اطمینان سیستمهای IT تقریباً وجود ندارد و سیستمهای هر سازمان آنقدر منحصربهفرد هستند که دادههای صنعتی تقریباً بیفایده است. در اینجا مجبوریم به کارکنان IT تکیه کنیم تا مروری بر خطرات و در صورت امکان ارزیابی قابل اطمینانی از احتمال خطرات فردی ارائه دهند. برای مثال، در اعداد گرد و کلی، اگر یک برنامه کاری داشتیم که روی یک سرور با تنها یک هارد دیسک اجرا میشد، انتظار داشتیم که در پنج تا ده سال آینده خرابی مرتبط با از دست دادن آن درایو رخ دهد. اگر همان سرور را با درایوهای قابل تعویض گرم در آرایهای آینهای داشتیم، احتمال خرابی مرتبط با آن سیستم ذخیرهسازی، حتی در طول ده سال، بسیار کم است. این بدان معنا نیست که درایو احتمالاً خراب نمیشود – میشود – بلکه بدان معناست که سیستم احتمالاً تا زمان بازگردانی افزونگی بدون اطلاع کاربران نهایی از هر اتفاقی تأثیر نمیپذیرد.
آخرین ابزار تخمین تقریبی ما اعمال ساعات کاری مرتبط است. بسیاری از کسبوکارها ۲۴×۷ کار نمیکنند، برخی البته کار میکنند، اما اکثر نه. آیا از دست دادن یک برنامه کاری در ساعت شش عصر معادل از دست دادن آن در ساعت ده صبح است؟ چه در مورد آخر هفته؟ آیا مردم ساعت سه بعدازظهر جمعه به طور مؤثر از آن استفاده میکنند یا از دست دادن آن تقریباً هزینهای ندارد و کارمندان خوشحالتری دارید که یک یا دو ساعت اضافه در آخر هفته دارند؟ آیا میتوان برنامهها را در صورت خرابی نزدیک به وقت ناهار تنظیم کرد؟ این عوامل در حالی که ظاهراً ناچیز هستند میتوانند قابل توجه باشند. اگر خرابی تنها به دو تا چهار ساعت محدود شود، بسیاری از کسبوکارها میتوانند تقریباً تمام تأثیر مالی را با درخواست از کارمندان برای کمی انعطافپذیری در برنامههایشان جبران کنند.
اکنون که این عوامل را داریم – هزینه خرابی، توانایی کاهش تأثیر خرابی بر اساس مدت زمان و خطر رویدادهای قطعی – میتوانیم شروع به ترسیم تصویری از آنچه یک رویداد خرابی احتمالاً به نظر میرسد کنیم. از این جا میتوانیم شروع کنیم به استخراج اینکه چقدر پول ارزش داشتن برای کاهش خطر چنین رویدادی دارد. برای برخی کسبوکارها این عدد بسیار بالا خواهد بود و برای برخی دیگر به طرز شگفتانگیزی پایین. این تمرین میتواند اطلاعات زیادی در مورد نحوه عملکرد یک کسبوکار آشکار کند که معمولاً آنقدرها هم قابل مشاهده نیست.
در این مرحله مهم است توجه کنیم که آنچه ما اینجا به آن نگاه میکنیم از دست دادن دسترسی به سیستمها است، نه از دست دادن دادهها. فرض میکنیم که پشتیبانگیری خوب انجام میشود و آن پشتیبانها دچار مشکل نیستند. افزونگی و خرابی موضوعاتی مرتبط با از دست دادن داده نیستند، بلکه تنها با از دست دادن دسترسی مرتبط هستند. سناریوهای از دست دادن داده باید با دقت مساوی یا بیشتر بررسی شوند اما موضوع جداگانهای هستند. کسبوکاری که بتواند از از دست دادن فاجعهبار داده جان سالم به در ببرد نادر است، اما بقا در برابر حتی خرابیهای قابل توجه سیستم رایج و آسان است.
راههای متعددی برای جلوگیری از خرابی وجود دارد، افزونگی بسیار قابل مشاهده است و تقریباً مانند یک کلیدواژه رایج با آن رفتار میشود و بنابراین توجه زیادی به خود جلب میکند، اما راههای دیگری نیز وجود دارد. طراحی سیستم خوب مهم است، اجتناب از پیچیدگی سیستم میتواند با حذف نقاط خطر و شکنندگی غیرضروری، خرابی را به شدت کاهش دهد. استفاده از سختافزار و نرمافزار با کیفیت نیز مهم است – زیرا سختافزار ارزانقیمت دارای افزونگی اغلب به همان اندازه سختافزار سطح سازمانی بدون افزونگی خراب میشود. داشتن زنجیره تأمین سریع قطعات یدکی میتواند عامل مهمی باشد که اغلب به شکل قراردادهای پاسخ به قطعات جایگزین چهار ساعته با فروشنده سختافزار دیده میشود. این فهرست ادامه دارد. آنچه ما بر آن تمرکز میکنیم افزونگی است که بیشترین احتمال هزینه بیش از حد را در مواجهه با ترس از خرابی دارد.
حالا که هزینههای عدم وجود افزونگی کافی را میدانیم، میتوانیم این هزینه احتمالی را با هزینه واقعی و پیشپرداخت تأمین آن افزونگی مقایسه کنیم. برخی چیزها، مانند هارد دیسکها، احتمال زیادی برای خرابی دارند و ایجاد افزونگی برای آنها نسبتاً آسان و مقرون به صرفه است – که خطر قابل توجهی را به چیزی بیاهمیت تبدیل میکند. اینها معمولاً اولین نقطه تمرکز هستند. اما حوزههای بسیاری از افزونگی وجود دارد که باید در نظر گرفته شوند، مانند منابع تغذیه، سختافزار شبکه، اتصالات اینترنت و سیستمهای کامل – که اغلب از طریق تکنیکهای مدرن مجازیسازی فراهم میشوند و راههای جدیدی برای افزونگی ارائه میدهند که قبلاً برای بسیاری از کسبوکارهای کوچکتر قابل دسترس نبود.
انواع جدید افزونگی، بهویژه آنهایی که از طریق مجازیسازی در دسترس قرار گرفتهاند، اغلب نقطهای هستند که کسبوکارها وسوسه میشوند به طرز چشمگیری بیش از حد هزینه کنند در مقایسه با خطرات خرابی. بدتر از آن، در تلاش برای کسب آخرین مُدها در افزونگی، شرکتها اغلب این تکنیکها را اشتباه پیادهسازی میکنند و در واقع خطر بیشتر و احتمال بالاتر خرابی را در مقایسه با عدم انجام هیچ کاری معرفی میکنند. به طور فزایندهای رایج است که بشنویم کسبوکارها دهها یا حتی صدها هزار دلار هزینه کردهاند تا ضرر مالی خرابی تنها چند هزار دلار را کاهش دهند – و سپس در آن تلاش شکست خوردهاند و در هر صورت خطر خود را افزایش دادهاند.
هنگام ارزیابی هزینه کاهش ریسک، بسیار مهم است که به یاد داشته باشید کاهش ریسک یک هزینه تضمین شده است، در حالی که خطر تنها یک خطر است. شبیه به بیمه خودرو که یک حق بیمه ماهانه کوچک تضمین شده میپردازید تا از هزینهای بزرگ و برنامهریزی نشده جلوگیری کنید. نظریه کاهش خطر این است که مبلغ نسبتاً کمی را اکنون خرج کنید تا خطر هزینه بزرگ بعدی را کاهش دهید، اما اگر هزینه کاهش خطر خیلی زیاد شود بهتر است خطرات را بپذیرید.
سیستمها را میتوان البته به صورت جداگانه ارزیابی کرد. حفظ حضور وب و سیستم تلفنی در تمام اوقات بسیار مهمتر از سیستم ایمیل است، جایی که حتی ساعتها خرابی بعید است توسط مشتریان خارجی قابل تشخیص باشد. پرداخت تنها برای محافظت از سیستمهایی که هزینه خرابی آنها قابل توجه است یک استراتژی مهم است.
تعجب نکنید اگر آنچه کشف میکنید این است که فراتر از برخی افزونگیهای بسیار اساسی (مانند هارد دیسکهای آینهای)، یک طراحی شبکه ساده با پشتیبانگیری خوب و برنامههای بازیابی و یک قرارداد پشتیبانی سختافزاری خوب تمام چیزی است که برای اکثر یا همه سیستمهای شما نیاز است. با کاهش پیچیدگی سیستمهای خود، آنها را به طور طبیعی پایدارتر و آسانتر برای مدیریت میکنید – که هزینه زیرساخت IT شما را بیشتر کاهش میدهد.
آگهی
