فاجعه جهانی کراداسترایک؛ چطور غیبت QA اقتصاد دنیا را فلج کرد؟
جمعه، ۱۹ جولای ۲۰۲۴ (۲۹ تیر ۱۴۰۳). روزی که مهندسان IT، مدیران محصول و مدیران عامل در سراسر جهان با یک کابوس مشترک از خواب بیدار شدند: صفحه آبی مرگ (BSOD). فرودگاهها تعطیل شدند، سیستمهای بانکی از کار افتادند، پخش زندهی شبکههای تلویزیونی قطع شد و حتی عملهای جراحی در بیمارستانها به تعویق افتاد. دلیل این آخرالزمان دیجیتال، حمله هکرها یا یک جنگ سایبری پیچیده نبود؛ دلیل آن فقط یک «باگ نرمافزاری» در آپدیت یکی از معتبرترین شرکتهای امنیت سایبری دنیا، یعنی CrowdStrike بود.
اما سوال اصلی که ذهن هر متخصص نرمافزار را درگیر میکند این است: چطور شرکتی با میلیاردها دلار سرمایه، آپدیتی را منتشر کرد که ۸.۵ میلیون سیستم ویندوزی را فلج کرد؟ آیا تیم تضمین کیفیت (QA) آن روز در مرخصی بود؟ در این مقاله از مگِ تستتو، این فاجعه را از لنز «تست نرمافزار» زیر ذرهبین میبریم.
آناتومی یک فاجعه: در پسزمینه کراداسترایک چه گذشت؟
نرمافزار Falcon Sensor متعلق به شرکت کراداسترایک، یک ابزار امنیتی است که دسترسیهای بسیار عمیقی (در سطح Kernel) به سیستمعامل ویندوز دارد. در آن جمعهی سیاه، کراداسترایک یک آپدیت کوچکِ پیکربندی (Configuration Update) به نام Channel File 291 را برای کلاینتهای خود ارسال کرد.
این فایل حاوی یک خطای منطقی بود که منجر به خواندن حافظه خارج از محدوده (Out-of-bounds memory read) میشد. چون این نرمافزار در سطح هستهی ویندوز اجرا میشد، ویندوز نتوانست این خطا را مدیریت کند و برای جلوگیری از آسیب به سختافزار، بلافاصله Crash کرد و صفحه آبی معروف را نمایش داد.
به نظر شما به عنوان یک توسعهدهنده/تستر، بزرگترین اشتباه تیم فنیکراداسترایک قبل از دیپلوی چه بود؟
۳ درس حیاتی QA که به قیمت ۵.۴ میلیارد دلار تمام شد!
این فاجعه به تمام تیمهای نرمافزاری، از استارتاپهای کوچک تا غولهای تکنولوژی، ثابت کرد که اهمیت تست نرمافزار، شوخیبردار نیست. اگر تیم کراداسترایک این ۳ اصل ساده QA را رعایت کرده بود، این فاجعه هرگز رخ نمیداد:
۱. فریب آپدیتهای کوچک را نخورید (اهمیت Regression Testing)
بزرگترین توجیه تیمها این است: “این فقط یک تغییر کوچک در یک فایل کانفیگ بود، نیازی به تست کامل ندارد!” این دقیقاً همان تلهای است که کراداسترایک در آن افتاد. یک تیم حرفهای QA میداند که هر تغییری، هرچند جزئی، باید توسط مجموعهای از تستهای رگرسیون اتوماتیک بررسی شود تا مطمئن شویم ویژگیهای قبلی سیستم دچار اختلال نشدهاند.
۲. فقدان تست در محیطهای شبیهسازی شده (Staging Environments)
آیا این آپدیت قبل از ارسال برای ۸.۵ میلیون کاربر، روی چند ماشین مجازی با نسخههای مختلف ویندوز تست شد؟ شواهد نشان میدهد که فرآیند تست این فایل پیکربندی به شدت ناقص بوده است. داشتن یک محیط Staging که دقیقاً مشابه محیط پروداکشن (Production) کاربر نهایی باشد، خط قرمز تیمهای QA استاندارد است.
۳. نبود انتشار مرحلهای (Phased Rollout)
دیپلوی کردن یک آپدیت حساس برای تمام کاربران دنیا در یک لحظه، مانند پریدن از هواپیما بدون چک کردن چتر نجات است. اگر آنها آپدیت را ابتدا روی ۱٪ از کاربران، سپس ۱۰٪ و در نهایت ۱۰۰٪ اعمال میکردند، فاجعه در همان دقایق اول توسط ابزارهای مانیتورینگ شناسایی و متوقف میشد.
آیا محصول شما برای روز مبادا آماده است؟
فاجعه کراداسترایک به ما یادآوری کرد که باگها تبعیض قائل نمیشوند. فرقی نمیکند یک شرکت چند میلیارد دلاری باشید یا یک فروشگاه اینترنتی در حال رشد؛ یک باگ در بخش درگاه پرداخت، یک قطعی در سرور هنگام کمپین فروش، یا یک نشت اطلاعاتی میتواند تمام اعتبار برند شما را یکشبه نابود کند.
بسیاری از تیمهای برنامهنویسی به دلیل کمبود زمان یا منابع، از انجام تستهای E2E، تست استرس و ایجاد سناریوهای استاندارد در ابزارهایی مثل Testica فرار میکنند. اینجاست که داشتن یک تیم مستقل و بیرحم برای شکار باگها حیاتی میشود.
اگر تیم توسعه شما درگیر رساندن فیچرهای جدید است و زمان کافی برای نوشتن تستهای اتوماسیون (با Cypress یا Playwright) یا انجام تستهای بارگذاری (Load Testing) ندارد، تیم متخصص تستتو (Testeto) به عنوان بازوی کنترل کیفیت در کنار شماست. ما کدهای شما را قبل از اینکه به دست کاربر نهایی برسند، به چالش میکشیم.
شما تعریف کنید: تا حالا پیش اومده یه آپدیت به ظاهر ساده بزنید رو پروداکشن و کل سیستم/سایت بخوابه؟ (بدون سانسور اعتراف کنید!) چه درسی از اون اتفاق گرفتید؟
همیشه به یاد داشته باشید: هزینه استخدام یک تیم تست نرمافزار حرفهای، هزاران بار کمتر از هزینه جبران خسارت، از دست رفتن مشتریان و نابودی اعتبار برند شماست. فاجعه کراداسترایک آخرین باگ تاریخ نخواهد بود، اما با برونسپاری خدمات QA به متخصصان، حداقل مطمئن میشوید که این باگ در محصول شما رخ نمیدهد.