مقدمه مفهومی درباره واژه خرابی (Failure) در مهندسی سیستم ها به وضعیتی اطلاق می شود که یک سیستم یا مؤلفه آن نتواند عملکرد مورد انتظار را ارائه دهد. این مفهوم در تمام حوزه های فناوری اطلاعات از سخت افزار تا نرم افزار کاربرد دارد و مطالعه آن در قالب مهندسی قابلیت اطمینان (Reliability Engineering) انجام می شود. خرابی می تواند کامل یا جزئی، موقت یا دائم باشد. کاربرد واژه در برنامه نویسی یا زیرشاخه های فناوری اطلاعات در تحلیل قابلیت اطمینان سیستم ها، در تست نرم افزار، در مدیریت زیرساخت، در سیستم های توزیع شده، و در طراحی معماری های تحمل پذیر خطا کاربرد دارد. همچنین در DevOps برای نظارت بر سلامت سیستم ها و در مهندسی قابلیت اطمینان سایت (SRE) استفاده می شود. مثال های واقعی و کاربردی در زندگی یا پروژه های IT قطع سرور وب به دلیل overload، خرابی دیسک سخت و از دست رفتن داده، قطع ارتباط بین میکروسرویس ها، از کار افتادن سرویس های ابری، خرابی ماژول های نرم افزاری به دلیل خطای برنامه نویسی، timeout شدن درخواست های شبکه. نقش واژه در توسعه نرم افزار یا معماری سیستم ها در معماری های مدرن، مدیریت خرابی یک مؤلفه کلیدی طراحی است. در سیستم های توزیع شده، الگوهایی مانند Retry و Fallback برای مقابله با خرابی ها استفاده می شوند. در میکروسرویس ها، مکانیزم های Health Check برای تشخیص سریع خرابی ها پیاده سازی می شوند. در DevOps، نظارت مستمر بر سیستم ها برای شناسایی خرابی ها ضروری است. شروع استفاده از این واژه در تاریخچه فناوری و تکامل آن در سال های مختلف مفهوم خرابی سیستم ها از ابتدای پیدایش کامپیوترها وجود داشته است. در دهه 1960 با توسعه سیستم های تجاری اهمیت یافت. در دهه 1980 با ظهور سیستم های حیاتی پیشرفت کرد. امروزه با معماری های ابری و میکروسرویس، استراتژی های پیشرفته تری برای مدیریت خرابی توسعه یافته اند. تفکیک آن از واژگان مشابه خرابی با خطا (Error) که ممکن است به خرابی منجر نشود متفاوت است. همچنین با نقص (Fault) که علت بالقوه خرابی است تفاوت دارد. با شکست (Crash) که نوع خاصی از خرابی است نیز متمایز است. شیوه پیاده سازی واژه در زبان های برنامه نویسی مختلف در تست نویسی: Assertions برای بررسی شرایط خرابی. در #C: try-catch برای مدیریت استثناها. در سیستم های توزیع شده: الگوی Circuit Breaker. در نظارت سیستم: Health Check Endpoints. در کوبرنتیز: Liveness و Readiness Probes. در Chaos Engineering: ابزارهایی مانند Chaos Monkey. چالش ها یا سوءبرداشت های رایج در مورد آن 1) تصور اینکه سیستم ها می توانند کاملاً بدون خرابی باشند 2) عدم برنامه ریزی برای خرابی های اجتناب ناپذیر 3) تشخیص دیرهنگام خرابی ها 4) بازیابی ناموفق پس از خرابی 5) عدم مستندسازی الگوهای خرابی 6) تست ناکافی شرایط خرابی. نتیجه گیری کاربردی برای استفاده در متون تخصصی و آموزشی خرابی یک واقعیت اجتناب ناپذیر در سیستم های کامپیوتری است. طراحی سیستم های resilient نیازمند درک عمیق از الگوهای خرابی و پیاده سازی مکانیزم های مناسب تشخیص، عکس العمل و بازیابی است. تست شرایط خرابی باید بخشی جدایی ناپذیر از فرآیند توسعه باشد.
