در دسترس بودن فناوری اطلاعات: تمام حقیقت

آبراهام لینکلن می‌گوید: «شما می‌توانید همیشه بعضی از مردم را فریب دهید، و بعضی اوقات همه مردم را، اما نمی‌توانید همیشه همه مردم را فریب دهید.»

بدون تردید در مورد صحت برخی از ارقامی که مردم برای قابلیت اطمینان سیستم‌های IT خود نقل می‌کنند، در بررسی، زمان‌های قطعی که بسیاری از مردم ادعا می‌کنند به طرز مضحکی کم به نظر می‌رسند.

اولین موضوعی که باید به آن توجه کرد، میانگین زمان تعمیر (MTTR) یک خرابی خاص است. این ممکن است کوتاه یا طولانی باشد، اما مشکل واقعی این است که چیزی در مورد زمان اضافی مورد نیاز برای “بازگرداندن نمایش به جاده” نمی گوید.

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

در بسیاری از موارد، نهادهای مالی (بانک‌ها، نمایندگی‌های سهام) عیب‌ها را تعمیر کرده‌اند، اما ساعت‌های زیادی طول کشیده تا شرایط عادی کار را بازیابی کنند. “سیستم در ساعت 11 صبح تعمیر شد و معاملات به طور معمول در ساعت 2:30 بعد از ظهر شروع شد” یک گزارش معمولی است.

این معادله ای را برای بازیابی در اختیار ما قرار می دهد: MTTR = میانگین زمان رفع خطا + میانگین زمان بازیابی به حالت کار کامل.

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

زمان بازیابی باید از تجزیه و تحلیل تأثیر کسب و کار (BIA) بیرون بیاید، که مشخص می کند چه مدت یک سرویس تجاری می تواند از عملکرد “عادی” خارج شود، قبل از اینکه وضعیت بحرانی یا غیرقابل دفاع شود.

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

این من را به نقطه ماقبل آخر هدایت می کند: تنها با درک تمام مراحل یک شکست و بازیابی آن می توانید برای به حداقل رساندن زمان های درگیر در هر مرحله برنامه ریزی کنید.

نمودار ساده زیر این موضوع را نشان می دهد:

تری کریچلیعناصر کشف و بازیابی خطا

عناصر کشف و بازیابی خطا

واژه نامه

  • MTPD: میانگین زمان برای تعیین مشکل
  • MTTR: ​​به معنای زمان تعمیر یا زمان بهبودی است. بستگی به دیدگاه شما دارد

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

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

نظر کاربر نهایی این خواهد بود که تا زمانی که او از استفاده از فناوری اطلاعات برای انجام کاری که قرار است انجام دهد منع شود، قطع برق ادامه دارد.

نظر متخصص سرور ممکن است این باشد که خرابی سخت‌افزار او فقط یک یا دو دقیقه قبل از رفع آن بوده است، در حالی که شخص شبکه خواهد گفت: “این همه سر و صدا برای چیست؟ همه چیز خوب کار می کند.”

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

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

همه چیز به دیدگاه شما بستگی دارد و من می دانم که مدیرعامل و هیئت مدیره شرکت در نهایت چه دیدگاهی خواهند داشت. آیا تو؟

دکتر تری کریچلی یک مشاور و نویسنده بازنشسته فناوری اطلاعات است که برای IBM، Oracle و Sun Microsystems با مدت کوتاهی در یک بانک بزرگ بریتانیا کار کرده است.

کتاب های تری کریچلی:

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

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

ساخت آن در فناوری اطلاعات

سئو PBN | خبر های جدید سئو و هک و سرور