داستان یه شنبه آف که خیلی هم آف نبود

خب، داستان از اون روزایی شروع شد که قرار بود فقط استراحت کنم و به کارای شخصیم برسم. گوشی کنارم بود و یهو یه Alert اومد که :
[Shared Hosts] [🔴 Down] Child inaccessible

قرار بود استراحت کنم اما کنجکاوی نذاشت نگاه کردم دیدم سرویس‌های اصلی هر ۳۰-۴۰ دقیقه یک بار به مدت ۲-۳ دقیقه از دسترس می‌رن. دقیقا به اندازه‌ای که دلت بلرزه و بوی دردسر بده و بخوای خاموش کنی بیخیال شی ولی نتونی بری 😅

اول رفتم سراغ سرویس‌ها و از روی سیستم عامل بررسی کردن . همشون سالم. لاگ‌ها تمیز. CPU و RAM اوکی.
اما توی مانیتورینگ یه چیز عجیب خیلی ریلکس در حال اتفاق بود:

نود اکتیو pfSense هی Boot میشه و HA داره سوئیچ می‌کنه به نود دوم!

pfSense با قابلیت High Availability اینجوریه که یه نود Passive داری که وقتی نود Active خاموش شه یا از دسترس خارج بشه، سریع جابه‌جا میشه و میاد بالا.

اینجا بود که تازه داشت جالب میشد.

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

رفتم لاگ نود Active رو چک کردم. آپ‌تایمش‌هم خیلی کوتاه بود.خود pfSense مشکلی نداشت. یعنی مشکلم از نرم‌افزار نبود.

پس رفتم سراغ Host روی کلاستر vSphere. به محض اینکه روی ویسنتر لاگین کردم مشکلو زد تو صورتم :)

 Memory Failure on Node 1

خب… یعنی هر چی اتفاق عجیب بود الان معنی پیدا کرد.
نود هر ۳۰-۴۰ دقیقه به خاطر مموری فیلیر ریست می‌شد و pfSense HA هم هی سوییچ می‌کرد.

هماهنگ کردم با بچه‌های دیتاسنتر برای تعویض رم.
اطلاع‌رسانی کردم برای کاربران هم که مشکل سخت‌افزاریه و داریم حلش می‌کنیم.
همه‌چی ظاهراً تحت کنترله…

اما تعویض رم طول کشید :/ و من مجبور شدم خودم برم دیتاسنتر. (بخاطر پالیسی های دیتاسنتر تیم فنی دیتاسنتر اجازه نداشت بدون حضور یکی از افراد فنی معرفی شده تغییری روی سرور اعمال کنن)
آره… دقیقا اون لحظه‌ای که می‌فهمی زندگیت اتفاق‌هاست، نه انتخاب ها 😅

در این مدت، چون ظرفیت کلاستر پر بود، نمی‌تونستم ماشین‌ها رو Move کنم.
و می‌دونستم این ریبوت‌های مداوم، یه جا یه چیزی رو نابود می‌کنه.

و خب… درست حدس زده بودم 💀

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

دم در خونه بودم، خسته و گشنه...
جاتون خالی توی راه ساندویچ بوقلمون کاپو هم زده بودم

تلفن زنگ خورد:
«سینا یکی از ماشین‌ها دیگه بوت نمیشه.»

ماشین بوت نمیشد و میره تو grub rescue.
پارتیشن بوت رو اصلاً نمی‌شناسه.

سعی کردم دستی بوت کنم.
دیدم سرور ۵ تا kernel داره و فقط یکی‌شون استفاده می‌شده 🤦‍♂️

شروع کردم یکی یکی کرنل هارو تست کردن:

grub> set prefix=(hd0,msdos1)/boot/grub
grub> linux /boot/vmlinuz-xxx root=/dev/sda1
grub> initrd /boot/initramfs-xxx
grub> boot

بعد از هزار بار تست، سرور بوت شد… ولی رفت تو linux rescue 😭
ولی خب همین هم یه پیروزی بود.

فوراً از ماشین یه snapshot گرفتم ( همیشه قبل از خراب‌تر کردن، یه بیمه بگیر :)))))) )

بعدش از داخل rescue:

chroot /mnt/sysimage
grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg

باور کن همین دستور رو پیدا کردن خودش یه boss fight بود 😅
گراب نه آپدیت میشد نه دستور هاش کار میکرد. مجبور شدم گراب و تمام متعلقاتشو از اول نصب کنم.

ولی در نهایت درست شد، ریبوت، و این بار:
هم سرور کامل بوت شد
هم سرویس ها بالا بودن
هم دیتا سرجاش بود

اما واقعیتش چیزی که بیشتر فشار آورد خود استرس نبود.
استرس جزئی از کار ماست.
توی این حوزه اگه استرس نکشی یعنی کار نمی‌کنی 😅

مشکل اصلی این بود که زیرساخت کاملاً اصولی و آماده نبود.
اون خیالِ راحتی که باید پشتت باشه… نبود.

نه اینکه ابزار یا دانش نباشه — اون‌ها بود.
اما بکاپ‌های Veeam که باید مثل سپر دوم ما می‌بودن،
مدتی بود درست در دسترس نبودن.

و وقتی بکاپ نیست یا بهش اعتماد نداری،
هر تصمیمی، هر دستور کوچیکی،
یه لایه «ترس از برگشت‌ناپذیری» با خودش میاره.

اونجاست که مغز شروع می‌کنه به زمزمه کردن:
«اگه این یکی هم بپره چی؟»
«اگه الان اشتباه کنی آخرین شانس هم می‌پره.»

و این صدا
بدترین دشمن مهندس نیست
این صدا نتیجه‌ی زیرساخت ناقصه.

و این تجربه بیشتر از هر چیزی یادآوری کرد:

زیرساخت اصولی و بکاپ سالم، فقط یه “Best Practice” نیست.
یه تکیه‌گاهه. یه امنیت روانیه.

بدونش، بهترین مهندس‌ها هم مثل راننده‌ای هستن که بدون ترمز، توی سرازیری دارن رانندگی می‌کنن.

Takeaway — خلاصه‌ی تجربه‌ی تلخ ولی واقعی

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