قبل از اینکه بریم سراغ مچگیری از دیتاسنتر، بیاید اول با یک اصطلاح خفن مهندسی آشنا بشیم: ترابلشوتینگ (Troubleshooting) که تو تیمهای فنی بهش میگن «تیشوت» (T-Shoot) کردن.
تیشوت کردن یعنی چی؟
تیشوت کردن یعنی پیدا کردنِ ریشهی یک مشکل (Root Cause) به صورت سیستماتیک و علمی، به جای حدس زدن و چشمبسته عمل کردن.
خیلی وقتها وقتی سرور یا اپلیکیشن میخوابه، برنامهنویسهای تازهکار شروع میکنن به حدس زدن: "شاید رم پر شده؟ شاید کد من باگ داره؟ شاید دیتابیس قفل کرده؟" و الکی سرور رو ریاستارت میکنن. به این کار میگن Trial and Error (آزمون و خطا).
اما یک مهندس ارشد (Senior) وقتی با قطعی مواجه میشه، تیشوت میکنه. یعنی مثل یک کارآگاه جنایی وارد صحنه جرم میشه و میگه:
«من حدس نمیزنم، من لاگها رو میخونم.»
در واقع، تیشوت کردن هنره تبدیل شدن به یک وکیل مدافع برای کدهای خودتونه! شما با بررسی لاگهای سیستمعامل، دیتابیس و کانتینرها، پازلها رو کنار هم میچینید تا دقیقاً بفهمید تو ثانیه صفرِ اون اتفاق چه بلایی سر سیستم اومده.
@codehalics | کدهالیک
تیشوت کردن یعنی چی؟
تیشوت کردن یعنی پیدا کردنِ ریشهی یک مشکل (Root Cause) به صورت سیستماتیک و علمی، به جای حدس زدن و چشمبسته عمل کردن.
خیلی وقتها وقتی سرور یا اپلیکیشن میخوابه، برنامهنویسهای تازهکار شروع میکنن به حدس زدن: "شاید رم پر شده؟ شاید کد من باگ داره؟ شاید دیتابیس قفل کرده؟" و الکی سرور رو ریاستارت میکنن. به این کار میگن Trial and Error (آزمون و خطا).
اما یک مهندس ارشد (Senior) وقتی با قطعی مواجه میشه، تیشوت میکنه. یعنی مثل یک کارآگاه جنایی وارد صحنه جرم میشه و میگه:
«من حدس نمیزنم، من لاگها رو میخونم.»
در واقع، تیشوت کردن هنره تبدیل شدن به یک وکیل مدافع برای کدهای خودتونه! شما با بررسی لاگهای سیستمعامل، دیتابیس و کانتینرها، پازلها رو کنار هم میچینید تا دقیقاً بفهمید تو ثانیه صفرِ اون اتفاق چه بلایی سر سیستم اومده.
@codehalics | کدهالیک
❤5
سناریویی که اتفاق افتاد این بود
داستان از این قرار بود که سرور لینوکس شما که میزبان سرویسهای حساسی مثل دیتابیس پستگرس روی داکر بود، ناگهان خاموش شده و از دسترس خارج میشه. وقتی سرور دوباره روشن میشه و شما از پشتیبانی دیتاسنتر (یا شخصی که سرور رو ازش خریدی) پیگیری میکنی، در جواب میگن: "ما کاری نکردیم، سرور از سمت ما مشکلی نداشته، احتمالاً خودتون از داخل لینوکس دستور خاموشی دادید یا سرورتون کرش کرده!"
در این لحظه، به جای اینکه حرفشون رو بپذیریم یا شروع کنیم به حدس زدن، تصمیم گرفتیم مثل یک مهندس ارشد وارد فاز T-Shoot (ترابلشوتینگ) بشیم و از خود سیستمعامل به عنوان شاهد استفاده کنیم.
@codehalics | کدهالیک
داستان از این قرار بود که سرور لینوکس شما که میزبان سرویسهای حساسی مثل دیتابیس پستگرس روی داکر بود، ناگهان خاموش شده و از دسترس خارج میشه. وقتی سرور دوباره روشن میشه و شما از پشتیبانی دیتاسنتر (یا شخصی که سرور رو ازش خریدی) پیگیری میکنی، در جواب میگن: "ما کاری نکردیم، سرور از سمت ما مشکلی نداشته، احتمالاً خودتون از داخل لینوکس دستور خاموشی دادید یا سرورتون کرش کرده!"
در این لحظه، به جای اینکه حرفشون رو بپذیریم یا شروع کنیم به حدس زدن، تصمیم گرفتیم مثل یک مهندس ارشد وارد فاز T-Shoot (ترابلشوتینگ) بشیم و از خود سیستمعامل به عنوان شاهد استفاده کنیم.
@codehalics | کدهالیک
❤2👍1
کدهالیک | codehalic
سناریویی که اتفاق افتاد این بود داستان از این قرار بود که سرور لینوکس شما که میزبان سرویسهای حساسی مثل دیتابیس پستگرس روی داکر بود، ناگهان خاموش شده و از دسترس خارج میشه. وقتی سرور دوباره روشن میشه و شما از پشتیبانی دیتاسنتر (یا شخصی که سرور رو ازش خریدی)…
۱. بررسی تاریخچه لاگینها و خاموشیها (last -x)
اولین قدم این بود که ببینیم آیا کسی دکمه خاموشی رو زده؟
خروجی دستور last نشون داد که آخرین باری که سرور به صورت نرمال shutdown شده، مربوط به ماهها پیش بوده.
۲. مدرک سختافزاری: وحشتِ سیستمفایل (recovering journal)
وقتی لینوکس نرمال خاموش میشه، درایوها رو با احترام میبنده (Unmount). ما رفتیم سراغ لاگهای لحظه روشن شدن سرور با دستور:
journalctl -b | grep -i "recovering journal"
چی پیدا کردیم؟ دیدیم سرویس systemd-fsck به شدت درگیر ریکاوری کردن پارتیشنهای sda2، lv_var و lv_home شده! این یعنی درایوها در حالت کثیف (Dirty) رها شده بودن و برقشون یهو قطع شده بوده. این اولین "تیر خلاص" به ادعای پشتیبانی بود.
۳. مدرک اپلیکیشنی: اعترافِ پستگرس (PostgreSQL)
دیتابیسها به شدت روی دادهها حساسن. ما رفتیم سراغ لاگ کانتینر دیتابیس:
docker logs <container_id>
چی پیدا کردیم؟ این شاهبیتِ ماجرا بود! پستگرس لاگ انداخته بود که:
database system was not properly shut down; automatic recovery in progress
یعنی دیتابیس وسط کار خفه شده بود! تازه پستگرس زمان دقیق قطعی رو هم لو داد: ۱۴ ژوئن ساعت ۲۱:۳۱. اینجا دیگه ۱۰۰٪ مطمئن شدیم که سرور به صورت Hard Power Cut خاموش شده.
۴. مدرک پلتفرمی: تقلای انجین داکر (Docker Daemon)
برای اینکه نشون بدیم حتی داکر هم غافلگیر شده، لاگهای سرویس داکر رو چک کردیم:
journalctl -u docker.service -b
چی پیدا کردیم؟ دهها خط ارور با عنوان Removing stale sandbox. این نشون داد که داکر نتونسته در زمان قطعی، سیگنال SIGTERM رو به کانتینرها بفرسته و محیطهای شبکهای (Sandboxes) رو به درستی پاک کنه. در نتیجه موقع روشن شدن، مجبور شده زبالههای بهجا مونده از دفعه قبل رو دستی پاک کنه.
۵. اثبات بیگناهی لینوکس (رد کردن ادعای کِرَش)
برای اینکه پشتیبانی نتونه بگه "لینوکس خودتون باگ خورده و هنگ کرده":
پوشه کرشهای هسته لینوکس (/var/crash/) رو چک کردیم و دیدیم total 0 (کاملاً خالی) است. یعنی کرنل لینوکس در کمال سلامت بوده.
تاریخچه دستورات ترمینال رو هم چک کردیم (history) و هیچ دستور خاموشیای در زمان قطعی پیدا نشد.
با کنار هم گذاشتن این پازلها (لایه سختافزار + لایه سیستمعامل + لایه پلتفرم + لایه اپلیکیشن)، ما یک پرونده قطعی ساختیم.
نتیجه این T-Shoot:
به جای اینکه با پشتیبانی سرِ اینکه "کی مقصره" دعوا کنیم، مدارک فنی رو کوبیدیم روی میز! بهشون ثابت کردیم که سیستمعامل، داکر و دیتابیس ما همگی گزارش یک قطعی ناگهانی برق یا Force Stop از سمت هایپروایزرِ اونها رو دادن.
@codehalics | کدهالیک
اولین قدم این بود که ببینیم آیا کسی دکمه خاموشی رو زده؟
خروجی دستور last نشون داد که آخرین باری که سرور به صورت نرمال shutdown شده، مربوط به ماهها پیش بوده.
۲. مدرک سختافزاری: وحشتِ سیستمفایل (recovering journal)
وقتی لینوکس نرمال خاموش میشه، درایوها رو با احترام میبنده (Unmount). ما رفتیم سراغ لاگهای لحظه روشن شدن سرور با دستور:
journalctl -b | grep -i "recovering journal"
چی پیدا کردیم؟ دیدیم سرویس systemd-fsck به شدت درگیر ریکاوری کردن پارتیشنهای sda2، lv_var و lv_home شده! این یعنی درایوها در حالت کثیف (Dirty) رها شده بودن و برقشون یهو قطع شده بوده. این اولین "تیر خلاص" به ادعای پشتیبانی بود.
۳. مدرک اپلیکیشنی: اعترافِ پستگرس (PostgreSQL)
دیتابیسها به شدت روی دادهها حساسن. ما رفتیم سراغ لاگ کانتینر دیتابیس:
docker logs <container_id>
چی پیدا کردیم؟ این شاهبیتِ ماجرا بود! پستگرس لاگ انداخته بود که:
database system was not properly shut down; automatic recovery in progress
یعنی دیتابیس وسط کار خفه شده بود! تازه پستگرس زمان دقیق قطعی رو هم لو داد: ۱۴ ژوئن ساعت ۲۱:۳۱. اینجا دیگه ۱۰۰٪ مطمئن شدیم که سرور به صورت Hard Power Cut خاموش شده.
۴. مدرک پلتفرمی: تقلای انجین داکر (Docker Daemon)
برای اینکه نشون بدیم حتی داکر هم غافلگیر شده، لاگهای سرویس داکر رو چک کردیم:
journalctl -u docker.service -b
چی پیدا کردیم؟ دهها خط ارور با عنوان Removing stale sandbox. این نشون داد که داکر نتونسته در زمان قطعی، سیگنال SIGTERM رو به کانتینرها بفرسته و محیطهای شبکهای (Sandboxes) رو به درستی پاک کنه. در نتیجه موقع روشن شدن، مجبور شده زبالههای بهجا مونده از دفعه قبل رو دستی پاک کنه.
۵. اثبات بیگناهی لینوکس (رد کردن ادعای کِرَش)
برای اینکه پشتیبانی نتونه بگه "لینوکس خودتون باگ خورده و هنگ کرده":
پوشه کرشهای هسته لینوکس (/var/crash/) رو چک کردیم و دیدیم total 0 (کاملاً خالی) است. یعنی کرنل لینوکس در کمال سلامت بوده.
تاریخچه دستورات ترمینال رو هم چک کردیم (history) و هیچ دستور خاموشیای در زمان قطعی پیدا نشد.
با کنار هم گذاشتن این پازلها (لایه سختافزار + لایه سیستمعامل + لایه پلتفرم + لایه اپلیکیشن)، ما یک پرونده قطعی ساختیم.
نتیجه این T-Shoot:
به جای اینکه با پشتیبانی سرِ اینکه "کی مقصره" دعوا کنیم، مدارک فنی رو کوبیدیم روی میز! بهشون ثابت کردیم که سیستمعامل، داکر و دیتابیس ما همگی گزارش یک قطعی ناگهانی برق یا Force Stop از سمت هایپروایزرِ اونها رو دادن.
@codehalics | کدهالیک
❤12👍3