وقتی یک اشتباه کوچک روی سیستم‌های Mainframe یک هفته کار و گزارش‌های مالی را نابود کرد

در عصر طلایی سیستم‌های مین‌فریم و کارت‌های پانچ، پردازش‌های حجیم دفتری و انبارداری چندین روز به طول می‌انجامیدند و عدم وجود مانیتور، وابستگی کاملی به چاپگرهای زنجیره‌ای ایجاد می‌کرد. در این مقاله تحلیلی، داستان واقعی یکی از اپراتورهای شرکت تاریخی Sperry Univac را بررسی می‌کنیم که چطور لغو یک پردازش چاپ ساده برای صرفه‌جویی در کاغذ، موجب از دست رفتن داده‌های حاصل از ۶ روز پردازش سنگین مین‌فریم و معطل ماندن مدیران ارشد شد.

معماری رایانش در دوران کارت‌های پانچ و حافظه‌های مجزا

در دهه ۱۹۷۰ و ۱۹۸۰ میلادی، زیرساخت‌های رایانشی تفاوت بنیادی با سیستم‌های توزیع‌شده و ابری امروزی داشتند. در آن زمان، سیستم‌های مین‌فریم شرکت Sperry Univac از واحدهای ذخیره‌سازی نواری (Tape)، دیسک‌های مغناطیسی بزرگ (Disk Platters) و کارت‌های پانچ برای ورودی داده‌ها استفاده می‌کردند. در این معماری، خروجی نرم‌افزارها به‌جای نمایش روی صفحه مانیتور، مستقیماً به صف چاپ (Print Queue) هدایت می‌شد و نتایج نهایی روی کاغذهای پیوسته چاپ می‌گردید.

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

رویداد؛ لغو یک پردازش و توقف اشتباه چاپگر

عملیات انبارداری هفتگی یکی از حیاتی‌ترین پردازش‌های سازمان بود که اجرای کامل آن همراه با چاپ گزارش‌ها حدود ۵ الی ۶ روز به طول می‌انجامید. در یکی از این دوره‌ها، سه مدیر ارشد از ایالات متحده به دفتر بریتانیا پرواز کرده بودند تا خروجی این پردازش کلیدی را مشاهده کنند. پس از ۵ روز پردازش مداوم، بخش محاسباتی به پایان رسید و مرحله چاپ نهایی روی یکی از دو چاپگر اختصاصی شروع شد؛ عملیاتی که نیازمند تغذیه مداوم بیش از ۲۰ باکس کاغذ بزرگ بود.

در همین حین، یکی از برنامه‌های کوچک‌تر که در حافظه اشتراکی اجرا می‌شد، دچار خطا شد و شروع به تولید حجم بسیار زیادی خروجی متنی متناقض کرد. سیستم از اپراتور (با نام مستعار مارک) سؤال کرد که آیا تمایل به چاپ این حجم عظیم از کاغذ دارد یا خیر. اپراتور برای جلوگیری از هدر رفتن کاغذ، با برنامه‌نویس مربوطه مشورت کرد و تأییدیه لغو دستور چاپ (Cancel Print Stage) را دریافت نمود.

اما به دلیل تداخل در تخصیص شناسه خروجی‌ها (Spool IDs) یا اشتباه در انتخاب چاپگر فعال در کنسول مدیریت، دستور لغو به‌جای برنامه کوچک، به چاپگر اصلی مربوط به پردازش انبارداری ارسال شد.

// شبیه‌سازی منطقی خطای دستور لغو در کنسول اپراتور
CANCEL PRINT_JOB --PRINTER=PRT01  // به جای PRT02
STATUS: PRINT JOB TERMINATED.
SPOOL DATA DELETED FROM BUFFER.
// نتیجه: از دست رفتن کامل ۶ روز داده پردازش شده بدون امکان بازیابی

تبعات فنی و عدم وجود مکانیزم‌های Recovery

در سیستم‌های رایانشی آن era، مفاهیمی مانند Auto-save، Transaction Logs یا Persistent Spooling به شکل امروزی وجود نداشت. زمانی که دستور لغو چاپ روی چاپگر اصلی اعمال شد، بفر خروجی و فایل‌های موقت بافر به‌سرعت پاکسازی شدند. حتی صفحات خلاصه مدیریتی (Summary Pages) نیز از بین رفتند و به دلیل آزاد شدن منابع حافظه، هیچ راهی برای بازیابی خروجی‌ها وجود نداشت مگر اینکه کل پردازش سنگین ۶ روزه دوباره از ابتدا (From Scratch) اجرا شود.

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

درس‌های مهندسی برای زیرساخت‌های مدرن

اگرچه امروز دیگر از مین‌فریم‌های پایه و کاغذهای پیوسته برای دریافت خروجی استفاده نمی‌شود، اما اصول مدیریت خطا در سیستم‌های توزیع‌شده و خطوط لوله داده (Data Pipelines) همچنان یکسان است:

• جداسازی دقیق صف‌ها (Queue Isolation): پردازش‌های حیاتی (Critical Jobs) باید صف‌ها و سرویس‌دهنده‌های خروجی کاملاً ایزوله داشته باشند تا دستورات مدیریتی خطوط دیگر روی آن‌ها تأثیر نگذارد.
• پایداری داده‌ها پیش از ارسال به خروجی (Persistence): نتایج محاسبات سنگین باید همواره در یک لایه ذخیره‌سازی پایدار (مانند Object Storage یا پایگاه‌داده) ثبت شوند و مرحله خروجی (چاپ، نمایش یا ارسال) تنها یک لایه خواندن بدون تخریب باشد.
• طراحی رابط‌های مدیریتی ایمن: در دستورات مخرب مانند `Kill` یا `Cancel`، ارائه جزئیات کامل پردازش هدف و دریافت تأییدیه صریح از اپراتور ضروری است.