۷ قانون نانوشته مهندسی نرمافزار که همه یه بار شکستشون
خلاصهٔ کاملتر
یه مهندس نرمافزار باتجربه، فراتر از قوانین معروف مثل قانون کانوی یا هایرام، ۷ قانون نانوشته رو جمع کرده که هر مهندسی حداقل یه بار بهشون خورده. اینا چیزایی نیستن که توی مستندات پیدا کنی — با خراب کردن چیزا یاد میگیریشون.
اول رولبک کن، بعد دیباگ. وقتی پروداکشن بعد از یه دپلوی خراب میشه، اولین غریزه اینه که بگی «به من ربط نداره». ولی تقریباً همیشه ربط داره. به جای اینکه یه ساعت وقت بذاری ثابت کنی تغییرت بیگناهه، باید فوری رولبک کنی، سیستم رو پایدار کنی، و بعد دنبال علت بگردی.
بکآپ واقعی نیست تا وقتی که ریستورش نکردی. خیلی از تیمها میدونن بکآپ دارن، ولی هیچوقت فرایند ریستور رو امتحان نکردن. سوالهای مهم اینان: فاصلهی بین بکآپها چقدره؟ چه کسی اجازهی ریستور داره؟ چقدر طول میکشه؟ اگه اینها رو نمیدونی، وسط یه اوتیج برای اولین بار باهاشون روبرو میشی.
هر دپندنسی خارجی یه روز خراب میشه. اضافه کردن یه API شخص ثالث خیلی سادهست — یه API key میگیری و کار میکنه. ولی اگه سیستمت SLA 99.9% داره و به یه سرویس دیگه با همین SLA وابسته باشی، دانتایمت از ۸ ساعت در سال به ۱۷ ساعت دو برابر میشه. باید از اول بپرسی: اگه این API کلاً در دسترس نبود چی میشد؟ آیا یه فیچر خراب میشه یا کل اپ میافته؟
قانون چهار چشم برای هر کار پرریسک. اگه کوچیکترین شکی داری که کاری که میخوای بکنی صد در صد امنه، از یه نفر بخواه باهات نگاه کنه. نصف وقتها خودت اشتباه رو موقع توضیح دادن پیدا میکنی. یه سیگنال مهم: اگه شب یا آخر هفتهست و نمیخوای مزاحم کسی بشی — این قویترین نشونهست که نباید اون کار رو انجام بدی.
نکات کلیدی:
- وقتی پروداکشن خراب میشه، اول رولبک کن بعد دیباگ — تقریباً همیشه به آخرین تغییر ربط داره
- بکآپ فقط زمانی واقعیه که فرایند ریستور رو تست کرده باشی
- برای هر مایگریشن دیتابیس، یه پلن رولبک تستشده داشته باش
- لاگنویسی خوب سخته: نه خیلی کم، نه خیلی زیاد، و حتماً با یه request ID مشترک بین سرویسها
- وابستگیهای خارجی رو با سناریوی «اگه کاملاً از دسترس خارج بشن» ارزیابی کن
- برای کارهای پرریسک حتماً یه نفر دیگه رو بیار — چهار چشم بهتر از دوتاست
- هیچ چیزی مثل یه راهحل موقت، دائمی نمیشه
