چه زمانی باید دسترسی بالا را در نظر بگیریم؟

«دسترسی بالا چیزی نیست که بخرید، بلکه چیزی است که انجام می‌دهید.» – John Nicholson

کمتر چیزی در IT به اندازه راه‌حل‌های دسترسی بالا (HA) به طور جهانی مطلوب است. واقعاً، این کلمات را بگویید و هر متخصص IT فوراً می‌گوید که آن را می‌خواهد. HA برای سرورها، اپلیکیشن‌ها، ذخیره‌سازی و البته حتی دسکتاپ‌هایشان. اگر یک چک‌باکس کنار هر سیستم بود که فقط «HA» نوشته بود، چرا آن را نمی‌زدیم؟ البته می‌زدیم. هیچ‌کس داوطلبانه نمی‌خواهد سیستمی داشته باشد که زیاد خراب می‌شود. خرابی بد است، موفقیت خوب.

اما ابتدا باید HA را تعریف کنیم. HA می‌تواند معانی زیادی داشته باشد. حداقل، HA باید به این معنا باشد که دسترسی سیستم مورد نظر باید بالاتر از «معمولی» باشد. معمولی چیست؟ این به تنهایی به اندازه کافی سخت است که تعریف شود. HA در بهترین حالت یک اصطلاح کلی است. در زمینه رایج‌ترین استفاده‌اش، که اپلیکیشن‌های معمول روی سخت‌افزار معمولی سازمانی هستند، این نقطه شروع را برای بحث‌های HA پیشنهاد می‌دهم:

دسترسی معمولی یا استاندارد (SA) به عنوان دسترسی از یک سرور معمولی خط اصلی که یک سیستم‌عامل سازمانی معمولی اجرا می‌کند که یک اپلیکیشن سازمانی معمولی را در یک محیط بهترین شیوه‌ها با پشتیبانی سازمانی اجرا می‌کند تعریف می‌شود. مثال‌های خوب این می‌تواند شامل Exchange روی Windows Server روی HP Proliant DL380 (رایج‌ترین سرور معمولی کالایی) باشد. یا BIND (سرور DNS) روی Red Hat Enterprise Linux روی Dell PowerEdge R730. اینها فقط مثال‌هایی هستند که برای ایجاد یک خط پایه تقریبی استفاده می‌شوند. هیچ راه عالی برای اندازه‌گیری این وجود ندارد، اما با یک قرارداد پشتیبانی خوب و تعمیر یا جایگزینی سریع در دنیای واقعی، قابلیت اطمینان یک سیستم از این ماهیت بین چهار و پنج نه‌تایی از قابلیت اطمینان (آپ‌تایم ۹۹.۹۹٪ یا بالاتر) تصور می‌شود وقتی خرابی انسانی در نظر گرفته نشود.

دسترسی بالا (HA) باید به طور معمول به عنوان داشتن دسترسی به طور قابل توجهی بالاتر از دسترسی استاندارد تعریف شود. به طور قابل توجهی بالاتر باید حداقل یک مرتبه بزرگی افزایش باشد. پس حداقل پنج نه‌تایی از قابلیت اطمینان و احتمالاً شش نه‌تایی. (آپ‌تایم ۹۹.۹۹۹۹٪.)

دسترسی پایین (LA) به طور معمول به عنوان داشتن دسترسی به طور قابل توجهی پایین‌تر از دسترسی استاندارد تعریف می‌شود، که به طور قابل توجهی مجدداً به معنای حداقل یک مرتبه بزرگی است. پس LA معمولاً حدود ۹۹٪ تا ۹۹.۹٪ یا دسترسی پایین‌تر فرض می‌شود.

اندازه‌گیری در اینجا بسیار دشوار است زیرا عوامل انسانی، محیطی و غیره نقش اساسی در تعیین آپ‌تایم پیکربندی‌های مختلف دارند. همان تجهیزات در یک نقش ممکن است پنج نه‌تایی به دست آورد در حالی که در نقش دیگری حتی یک نه‌تایی هم نرسد. کیفیت مرکز داده، مهارت کارکنان پشتیبانی، سرعت جایگزینی قطعات، دقت نظارت و عوامل بسیاری دیگر قابلیت اطمینان کلی را به طور قابل توجهی تحت تأثیر قرار خواهند داد. با این حال، این لزوماً برای ما مشکلی نیست. در اکثر موارد می‌توانیم بخش‌هایی از طراحی سیستم که کنترل می‌کنیم را به گونه‌ای ارزیابی کنیم که قابلیت اطمینان نسبی بتواند تعیین شود تا حداقل بتوانیم نشان دهیم که یک رویکرد نسبت به دیگری برتر خواهد بود تا بتوانیم از تصمیم‌گیری آگاهانه استفاده کنیم حتی اگر مدل‌های دقیق نرخ خرابی نتوانند به راحتی ساخته شوند.

مهم است توجه داشته باشید که جدای از ارائه یک مجموعه نمونه خط پایه برای کار کردن، هیچ چیز در تعاریف دسترسی بالا یا دسترسی پایین در مورد چگونه این سطوح باید دستیابی شوند وجود ندارد - این معنای اصطلاحات نیست. اصطلاحات نتایج قابلیت اطمینان در ارتباط با خط پایه هستند و چیز دیگری نیستند. راه‌های زیادی برای دستیابی به دسترسی بالا بدون استفاده از رویکردهای معمولاً فرض شده وجود دارد و روش‌های عملاً نامحدودی برای دستیابی به دسترسی پایین وجود دارد.

البته HA می‌تواند در هر لایه‌ای تعریف شود. می‌توانیم پلتفرم‌ها یا سیستم‌عامل HA داشته باشیم اما اپلیکیشن‌های شکننده در بالای آن. پس بسیار مهم است که بفهمیم در هر زمانی در چه سطحی صحبت می‌کنیم. در نهایت، یک کسب‌وکار فقط به دسترسی بالای ارائه خدمات اهمیت می‌دهد صرف‌نظر از اینکه چگونه دستیابی شده یا کجا. نتیجه نهایی اهمیت دارد نه جزئیات «زیر کاپوت» نحوه دستیابی، یا همیشه، هدف وسیله را توجیه می‌کند.

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

در دنیای واقعی، HA همیشه گزینه‌ای نیست و وقتی هست، با هزینه همراه است. این هزینه تقریباً همیشه پولی است و معمولاً با پیچیدگی اضافه هم همراه است. و همانطور که به خوبی می‌دانیم، هر پیچیدگی ریسک اضافه‌ای هم به همراه می‌آورد و آن ریسک می‌تواند، اگر مراقب نباشیم، تلاش برای دستیابی به HA را در واقع شکست دهد و ممکن است حتی ما را با LA یا دسترسی پایین رها کند.

وقتی این زبان ضروری برای توصیف منظورمان را درک کردیم، می‌توانیم شروع به صحبت درباره زمانی کنیم که دسترسی بالا، دسترسی استاندارد و حتی دسترسی پایین ممکن است برای ما مناسب باشد. ما از این سطح بالای دقت استفاده می‌کنیم زیرا اندازه‌گیری قابلیت اطمینان سیستم به قدری دشوار است که خیلی جزئی شدن بی‌ارزش می‌شود.

از نظر مفهومی، همه سیستم‌ها با ریسک خرابی همراه هستند و هیچ چیز نمی‌تواند همیشه در دسترس باشد، این غیرممکن است. قابلیت اطمینان معمولاً با همه چیزهای برابر دیگر هزینه دارد. پس برای تعیین اینکه چه سطح از دسترسی برای یک بار کاری مناسب‌ترین است، باید هزینه کاهش ریسک (میزان پولی که برای تغییر میانگین زمان خرابی لازم است) را تعیین کنیم و با هزینه خود خرابی مقایسه کنیم.

این پیچیده و مشکل می‌شود زیرا تعیین هزینه خرابی به اندازه کافی دشوار است، سپس تعیین ریسک خرابی حتی دشوارتر است. در بسیاری از موارد، خرابی عدد ثابتی نیست، اما ممکن است باشد. این هزینه می‌تواند به صورت ۵ دلار در دقیقه یا ۲۰,۰۰۰ دلار در روز یا مشابه بیان شود. اما ابزار بهتری استفاده از «منحنی تأثیر خسارت» است که نشان می‌دهد چگونه پول در طول زمان از دست می‌رود (در یک بازه زمانی معقول).

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

گاهی به مردمی که در شرکت کار می‌کنند برمی‌گردد. آیا همه آنها با کمال میل در زمان خرابی سیستم به دستشویی، قهوه، میان‌وعده یا حتی ناهار می‌روند تا بتوانند وقتی سیستم درست شد به کار برگردند؟ آیا مردم زودتر به خانه می‌روند و فردا زودتر می‌آیند تا خرابی بزرگ را جبران کنند؟ آیا ماشین‌آلاتی وجود دارند که بیکار بمانند؟ آیا توانایی پاسخ به مشتریان تحت تأثیر قرار می‌گیرد؟ آیا سیستم‌های پشتیبانی از زندگی از کار می‌افتند؟ تأثیرات بالقوه و روش‌های بالقوه کاهش انواع مختلف خرابی‌ها بی‌شمار هستند. همه اینها باید در نظر گرفته شود. هزینه خرابی ممکن است کسری از درآمد شرکت بر اساس دقیق دقیقه‌ای باشد یا خرابی ممکن است باعث از دست دادن مشتریان یا اعتمادی شود که تأثیرگذارتر از درآمد دقیقه‌ای تولید شده است.

وقتی برخی اعداد تقریبی خسارت داریم، حداقل یک نقطه شروع داریم. حتی اگر فقط بدانیم که درآمد حدود ۱۰ دلار در دقیقه است و خسارات حدود ۵ دلار در دقیقه انتظار می‌رود، نقطه شروعی داریم. اگر یک منحنی کامل یا مطالعه‌ای با اعداد تفصیلی‌تر انجام شده داشته باشیم، بهتر است. اکنون باید تقریباً بفهمیم خط پایه ما چه خواهد بود. یک سرور به خوبی نگهداری شده، در محل، با یک قرارداد پشتیبانی خوب و رویه‌های خوب پشتیبان‌گیری و بازیابی می‌تواند به راحتی چهار نه‌تایی از قابلیت اطمینان به دست آورد. این یعنی حدود پنج ساعت خرابی هر پنج سال تجربه می‌کنیم. این در واقع کمتر از خرابی معمولاً انتظار داشته از SA در اکثر محیط‌ها است و احتمالاً بسیار کمتر از سطوح مورد انتظار در محیط‌های عالی مانند مراکز داده با کیفیت بالا با قطعات و خدمات نزدیک است.

پس بر اساس مثال خط پایه ما از حدود پنج ساعت هر پنج سال می‌توانیم ریسک بالقوه را محاسبه کنیم. اگر حدود ۵ دلار در دقیقه از دست بدهیم و حدود ۳۰۰ دقیقه خرابی در هر پنج سال انتظار داشته باشیم، به خسارت بالقوه ۱,۵۰۰ دلار هر نیم دهه نگاه می‌کنیم.

این یعنی در بدترین حالت هرگز نمی‌توانستیم ۱,۵۰۰ دلار برای کاهش آن ریسک خرج کنیم، این از نظر مالی احمقانه بود. این به دلایل چندی اتفاق می‌افتد. یکی از بزرگ‌ترین دلایل این است که این فقط یک ریسک است، خرج کردن ۱,۵۰۰ دلار برای محافظت در برابر از دست دادن ۱,۵۰۰ دلار منطقی نیست، اما اشتباه بسیار رایجی است که وقتی مردم این اعداد را با دقت تجزیه‌وتحلیل نمی‌کنند اتفاق می‌افتد.

بزرگ‌ترین عامل این است که هیچ تکنیک کاهشی کاملاً مؤثر نیست. اگر بتوانیم سیستم چهار نه‌تایی خود را به سیستم پنج نه‌تایی تبدیل کنیم، فقط ۹۰٪ از میانگین خرابی را کاهش می‌دهیم و از ۱,۵۰۰ دلار خسارت به ۱۵۰ دلار خسارت می‌رویم. اگر ۱,۵۰۰ دلار برای آن کاهش خرج کنیم، مجموع «خسارت» هنوز ۱,۶۵۰ دلار خواهد بود (هزینه محافظت یک نوع خسارت مالی است). هزینه کاهش ریسک همراه با تأثیر باقی‌مانده پیش‌بینی شده وقتی با هم در نظر گرفته شوند هنوز باید کمتر از هزینه پیش‌بینی شده ریسک بدون کاهش باشد وگرنه کاهش خود بی‌معنی یا فعالانه مضر است.

ممکن است بسیاری بپرسند چرا هزینه کل کاهش ریسک باید کمتر باشد و نه صرفاً برابر زیرا مطمئناً این یعنی ما در «نقطه شکست ریسک» هستیم؟ این در ظاهر درست به نظر می‌رسد، اما چون با ریسک سروکار داریم اینطور نیست. کاهش ریسک یک هزینه قطعی است - آسیب مالی که امروز تحمل می‌کنیم به امید کاهش خسارات فردا. اما ریسک فردا یک حدس است، امیدوارم یک حدس به خوبی آموزش‌دیده، اما فقط یک حدس. هزینه امروز قطعی است. تحمل آسیب قطعی امروز به امید کاهش آسیب ممکن فردا فقط وقتی منطقی است که آسیب امروز کوچک باشد و آسیب مورد انتظار یا ممکن فردا بسیار بزرگ باشد و اثربخشی کاهش قابل توجه باشد.

در ایده «هزینه قطعی از پیش» برای کاهش «هزینه ممکن فردا» ایده ارزش زمانی پول گنجانده شده است. حتی اگر خرابی از اندازه و زمان معلومی بود، هم اکنون همان پول را خرج نمی‌کردیم تا آن را فردا کاهش دهیم زیرا پول ما امروز ارزشمندتر است.

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

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

رایج است که دستگاه‌های ذخیره‌سازی به «کنترلرهای دوتایی» مجهز شوند که تأثیر قوی از قابلیت اطمینان بالا می‌گذارند، اما به طور کلی این کنترلرها داخل یک شاسی واحد با اجزای مشترک هستند و حتی اگر اجزا مشترک نباشند، اغلب فریم‌ور مشترک است و ارتباطات بین اجزا پیچیده است؛ اغلب منجر به خرابی‌هایی می‌شود که خرابی یک جزء خرابی جزء دیگر را راه‌اندازی می‌کند - آنها را اغلب به دستگاه‌های LA تبدیل می‌کند نه SA یا HA که مردم هنگام خرید انتظار داشتند. پس بسیار مهم است که بررسی شود آیا استراتژی کاهش ریسک کدام ریسک‌ها را کاهش می‌دهد و آیا تکنیک کاهش احتمالاً مؤثر خواهد بود یا نه. هیچ تکنیکی کاملاً مؤثر نیست، همیشه احتمال خرابی وجود دارد، اما برخی استراتژی‌ها و تکنیک‌ها به طور گسترده‌تری مؤثر هستند و برخی صرفاً گمراه‌کننده یا واقعاً ضدتولیدی هستند. اگر مراقب نباشیم، ممکن است محصولات یا تکنیک‌های پرهزینه‌ای اجرا کنیم که فعالانه اهداف ما را تضعیف می‌کنند.

برخی تکنیک‌ها و محصولات مورد استفاده در دنبال کردن دسترسی بالا نسبتاً گران‌قیمت هستند، که ممکن است شامل خرید سخت‌افزار افزونه، اجاره ساختمان دیگر، نصب مولدهای گران‌قیمت یا مجوز نرم‌افزار خاص باشد. تکنیک‌ها و نرم‌افزارهای کم‌هزینه هم وجود دارند، اما در اکثر موارد هر حرکتی به سمت دسترسی بالا منجر به سرمایه‌گذاری اولیه بزرگی برای دستیابی به آن خواهد شد. کاملاً مهم است که به یاد داشته باشید که دسترسی بالا یک فرایند است، هیچ راهی برای صرفاً خریدن دسترسی بالا وجود ندارد. دستیابی به HA نیاز به مستندسازی خوب، رویه‌ها، برنامه‌ریزی، پشتیبانی، تجهیزات، مهندسی و موارد دیگر دارد. در دنیای سیستم‌ها، HA معمولاً اول از منظر محیطی با مولدهای برق اضطراری، سیستم‌های تهویه افزونه، تنظیم برق، فیلتراسیون هوا، سیستم‌های مهار آتش و موارد دیگر برای اطمینان از اینکه محیط دسترسی وجود دارد مورد توجه قرار می‌گیرد. این به تنهایی اغلب می‌تواند سرمایه‌گذاری بیشتر را غیرضروری کند زیرا می‌تواند نتایج فوق‌العاده‌ای ارائه دهد. سپس طراحی سیستم HA می‌آید که اطمینان می‌دهد نه فقط یک لایه از پشته فناوری دارای دسترسی بالا است بلکه کل پشته اجازه می‌دهد اپلیکیشن‌ها، داده‌ها یا خدمات حیاتی در بیشترین زمان ممکن عملکرد داشته باشند. سپس نگاه به افزونگی سایت به سایت برای توانایی تحمل سیل، طوفان، کولاک و غیره. البته تکنیک‌های کاملاً متفاوتی مانند استفاده از خدمات رایانش ابری که به نمایندگی از ما از راه دور میزبانی شده‌اند وجود دارند. آنچه اهمیت دارد این است که دسترسی بالا نیاز به تفکر و برنامه‌ریزی گسترده دارد، نمی‌تواند صرفاً به عنوان یک آیتم خط خریداری شود و بر اساس توانایی برگشت دادن یک عامل ریسک که آپ‌تایم یا احتمال آپ‌تایم بسیار بالاتری از یک طراحی سیستم «استاندارد» ارائه می‌دهد ارزیابی می‌شود.

آنچه اغلب برای بسیاری از کسب‌وکارها و به ویژه برای متخصصان IT شگفت‌انگیز، تقریباً شوکه‌کننده است، که به ندرت تحلیل ریسک مالی انجام می‌دهند و مداوماً به آنها گفته می‌شود که HA برای هر کسب‌وکاری ضرورت است و خرید آخرین محصولات HA به طور بی‌چون‌وچرا نحوه صرف بودجه‌هایشان است، این است که وقتی اعداد محاسبه می‌شوند و واقعیت هزینه‌ها و اثربخشی استراتژی‌های کاهش ریسک در نظر گرفته می‌شود که دسترسی بالا جای بسیار کمی در هر سازمان دارد، به ویژه آنهایی که کوچک هستند یا بارهای کاری بسیار متفاوتی دارند. در بازار کسب‌وکارهای کوچک و متوسط تقریباً جهانی است که هزینه و پیچیدگی (که به نوبه خود ریسک می‌آورد، عمدتاً در قالب کمبود تجربه در مورد تکنیک‌ها و ارزیابی ریسک) رویکردهای دسترسی بالا برای جبران خسارت بالقوه خرابی از آن محافظت امیدوار است خیلی گران است. البته استثناهایی وجود دارند و کسب‌وکارهای زیادی هستند که راه‌حل‌های دسترسی بالا برایشان کاملاً منطقی است، اما اینها استثنا هستند و به هیچ وجه هنجار نیستند.

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

نمونه‌هایی از بارهای کاری که ممکن است حیاتی باشند و می‌توان به طور مؤثر با دسترسی بالا به آنها پرداخت ممکن است یک سیستم سفارش آنلاین باشد که تأخیر ایجاد شده توسط تکرار چند منطقه‌ای تأثیر کمی بر سیستم کلی دارد اما از دست دادن سفارشات می‌تواند از نظر مالی در صورت خرابی سیستم بسیار تأثیرگذار باشد. نمونه‌ای از بار کاری که دسترسی بالا ممکن است پیاده‌سازی آسانی داشته باشد اما بی‌اثر باشد یک سایت اینترانت داخلی خواهد بود که به سوالات رایج HR پاسخ می‌دهد؛ صرفاً از نظر مالی کارآمد نخواهد بود که از مقادیر کمی خرابی گاه‌به‌گاه برای چنین سیستمی جلوگیری کنیم. نمونه‌ای از سیستمی که ریسک بالا است اما هزینه یا اثربخشی کاهش ریسک آن را غیرعملی یا حتی غیرممکن می‌کند ممکن است یک پایگاه داده مالی «تیک» باشد که نیاز به مقادیر عظیمی از داده با تأخیر کم برای جذب دارد و توانایی نگه داشتن یک کپی نه تنها بسیار پرهزینه بلکه می‌توانست تأخیری ایجاد کند که توانایی سیستم برای عملکرد کافی را تضعیف کند. هر کسب‌وکار و بار کاری منحصربه‌فرد است و باید با دقت ارزیابی شود.

البته تکنیک‌های دسترسی بالا می‌توانند در مراحل اجرا شوند؛ این همه یا هیچ نیست. ممکن است عملی باشد که ریسک خرابی سطح سیستم را با داشتن تحمل خطای لایه اپلیکیشن برای محافظت در برابر خرابی سخت‌افزار سیستم، پلتفرم مجازی‌سازی یا ذخیره‌سازی کاهش دهیم. اما برای همان بار کاری ممکن است ارزش نداشته باشد که در برابر از دست دادن یک سایت محافظت کنیم. اگر یک بار کاری فقط یک سایت خاص را سرویس می‌دهد یا به سادگی برای سرمایه‌گذاری بزرگی که برای از کار افتادن بین سایت‌ها نیاز است به اندازه کافی ارزشمند نیست، می‌توانست به راحتی «در وسط» باشد. بسیار رایج است که بارهای کاری فقط راه‌حل‌های دسترسی بالا جزئی پیاده‌سازی کنند، اغلب به این دلیل که یک دپارتمان IT ممکن است فقط مسئول بخشی از آنها باشد و هیچ نظری در مورد چیزهایی مانند پشتیبانی برق و تهویه نداشته باشد، اما احتمالاً رایج‌ترین دلیل این است که برخی تکنیک‌های دسترسی بالا به عنوان پربیننده و به راحتی قابل فروش به مدیریت دیده می‌شوند در حالی که دیگران مانند برق و تهویه با کیفیت بالا، اغلب حتی نیستند گرچه ممکن است به راحتی بهترین بازدهی را ارائه دهند. دلایل خوبی وجود دارند که چرا تکنیک‌های خاصی ممکن است انتخاب شوند و دیگری نه زیرا آنها اجزای مختلف ریسک را تحت تأثیر قرار می‌دهند و برخی ریسک‌ها ممکن است تأثیر متفاوتی بر یک کسب‌وکار یا بار کاری فردی داشته باشند.

دسترسی بالا نیاز به تفکر دقیق در مورد اینکه آیا ارزش در نظر گرفتن را دارد و تفکر حتی دقیق‌تر در مورد اجرا دارد. ساختن سیستم‌های واقعی HA نیاز به مقدار قابل توجهی تلاش و تخصص و به طور کلی هزینه قابل توجهی دارد. فهمیدن اینکه کدام اجزا از HA ارزشمند هستند و کدام نیستند نه فقط نیاز به تخصص فنی گسترده بلکه مهارت‌های مالی و مدیریتی هم دارد. دپارتمان‌ها باید به طور گسترده با هم همکاری کنند تا واقعاً بفهمند که HA چگونه یک سازمان را تحت تأثیر قرار خواهد داد و چه زمانی ارزش سرمایه‌گذاری را خواهد داشت. مهم است که به یاد داشته باشید که نیاز به دسترسی بالا در یک سازمان یا برای یک بار کاری به هیچ وجه نتیجه‌گیری از پیش تعیین‌شده نیست و نباید اصلاً تعجب‌آور باشد اگر متوجه شویم که دسترسی بالای گسترده یا حتی شیوه‌های معمول دسترسی بالا از نظر اقتصادی غیرعملی هستند.

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

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

به عنوان متخصصان IT، ارزیابی مزایا، ریسک‌ها و هزینه‌های راه‌حل‌های فناوری در هسته آنچه انجام می‌دهیم است. مانند هر چیز دیگری در زیرساخت کسب‌وکار، تعیین نوع کاهش ریسک، ارزش محافظت و میزان مناسب مالی مسئولیت اصلی ما است و نمی‌توان از آن غافل شد یا نادیده گرفت. هرگز نمی‌توانیم صرفاً فرض کنیم که دسترسی بالا لازم است، نه اینکه می‌توان صرفاً از آن صرف‌نظر کرد. در تحلیل‌هایی از این نوع است که IT بیشترین ارزش را برای سازمان‌ها به ارمغان می‌آورد. اینجاست که بیشترین پتانسیل را داریم تا بدرخشیم.