Ex Snapp! Senior Software Engineer
فوق لیسانس هوش مصنوعی از دانشگاه تهران
اشتراک محتوا در مورد مهندسی نرم افزار، هوش مصنوعی، گولنگ
https://gocasts.ir
پروفایل
https://www.linkedin.com/in/gohossein
ارتباط
@lifography
Ai for Software
@aicasts_ir
Post #822
2.74K
این بهترین تجربهای بود که تا حالا با یه agent داشتم.
دیشب با تاخیر چند ساعته ایمیل هاستینگ رو خوندم که نوشته بود «فردا ۸ صبح سرورتون رو با اسنپشات میبریم روی زیرساخت جدید، IP عوض میشه، از دیتاتون بکاپ بگیرید، مسئولیتش با خودتونه.» سرور، تنها سرور پروداکشن یه سازمانه که تو پنج سال گذشته هر چیزی که لازم بوده روش نصب شده: چند تا استک داکر (Nuxt، دو تا Laravel، MySQL های جدا)، وردپرس روی php-fpm و MariaDB خود هاست، یه رجیستری خصوصی داکر، ۱۹ تا دیتابیس که نصفشون legacyان، بیش از ۱۵ گیگ فایل و مدارک مهم سازمان، درگاههای بانکی که IP سرور رو whitelist کردن، و CentOS 7 که دو ساله EOL شده. دیسک ۹۹٪ پر بود و روش قدیمی بکاپ (tar بگیر، با HTTP دانلود کن) عملاً غیرممکن. کار ما عملاً ۱۲ شب شروع شد، یعنی ۸ ساعت تا مهاجرت.
ابزار Claude Code با مدل Fable رو باز کردم و اول نقشهی سرور رو کشید: کدوم سرویس کجاست، دیتا کجاست، چی به IP وابستهست. بعد فهمید پهنای باند سرور به لپتاپ من ۱۵۰ کیلوبایت بر ثانیهست و ۱۵ گیگ عمراً تا صبح نمیرسه؛ رفت سراغ object storage داخلی که کلیدش از قبل روی سرور بود، rclone رو بدون sudo نصب کرد، آپلود رو تو tmux راه انداخت و با ۶ مگابایت بر ثانیه تو ۴۰ دقیقه تموم شد. dump دیتابیسها رو گرفت و قبل از اینکه بگه «بکاپ داریم» روی لپتاپ من restore کرد و ردیفها رو شمرد. docker save ایمیجهایی که هیچجای دیگه وجود نداشتن، کانفیگها، docker inspect همهی کانتینرها، همه رفت. همزمان یه runbook زنده نوشت: وضعیت، ریسکها، پلن بکاپ با وضعیت هر آیتم، چکلیست تغییر IP، تستهای بعد از انتقال، و دستور بازسازی از صفر اگه اسنپشات خراب میشد. تو همین مسیر چند تا چیز پیدا کرد که خودم نمیدونستم: یه فایل nginx که روی IP قدیم listen میکرد و روی سرور جدید کل nginx رو زمین میزد (قبل از مهاجرت درستش کردیم)، اینکه کل زون DNS پشت CDN بود و TTL اصلاً مهم نبود، و گواهیهای TLS مبدأ که شش هفته بود منقضی شده بودن و CDN قایمشون کرده بود.
چیزی که این تجربه رو با هر ابزار دیگهای فرق داد، همیشهآنلاین بودنش بود. من وسطاش رفتم خوابیدم؛ Fable بیدار موند. هر ۵ دقیقه پیشرفت آپلود و تعداد خطاها رو چک میکرد، بعد از هر مرحله rclone check میزد و فایلها رو با دیسک مقایسه میکرد، بعد که تصمیم گرفتم بهخاطر تعویق احتمالی مهاجرت هیچ سرویسی رو stop نکنم، یه dump تکرارشوندهی ۵ دقیقهای گذاشت که تا لحظهی قطع سرور کار کرد و هر دور رو همون لحظه به storage میفرستاد. صبح که مهاجرت شروع شد، مانیتورش هر دقیقه IP قدیم و جدید رو میزد؛ لحظهی قطع رو ثبت کرد، لحظهی بالا اومدن سرور جدید رو گرفت، همون دقیقه SSH زد، شبکه و ۱۵ کانتینر و crash recovery هر دو MySQL و تعداد ردیف پرداختها و تعداد فایلها رو با شب قبل مقایسه کرد، بعد یه مانیتور روی CDN گذاشت که تکتک دامنهها کی ۲۰۰ برمیگردن، و بعد از اون هم تا یه ساعت، هر ۱۰ دقیقه پرداختهای موفق رو با همون ساعت دیروز و هفتهی قبل مقایسه کرد و نتیجه رو تو runbook نوشت تا مطمئن بشیم درآمد سازمان واقعاً برگشته. من صبح فقط ریویو میکردم، sudo میزدم و تصمیم میگرفتم؛ بقیهش چشم و دست اون بود.
نتیجه: حدود ۴۰ دقیقه downtime، که ۳۰ دقیقهش زمان خود اسنپشات و بوت سرور جدید توسط هاستینگ بود و ۱۰ دقیقهی بعدش عوض کردن origin تو CDN به دست خودم. صفر داده از دست رفت؛ آخرین پرداخت قبل از قطع و اولین پرداخت بعدش با شمارش ردیف تأیید شد. بعدش هم یه hotfix فرانت داد که فقط درگاهی که IP جدید رو تأیید کرده بود فعال بمونه (با env، بدون rebuild برای برگردوندن بقیه) و تو همون مسیر یه باگ چندساله پیدا شد: هر فرم پرداختی که کاربر دست به رادیوباتنها نمیزد به یه درگاه هاردکد میرفت. اغراق نمیکنم: اشتباه هم داشت (اولین نسخهی fix ای که برای flush کش نوشت یه باگ quoting داشت و خودش تو دور بعد درستش کرد). واقعا لذت بردم از همراهیش به عنوان یه همکار on-call که خسته نمیشه، همه چیز رو مستند میکنه و قبل از ادعا تست میکنه.
آخراش روم نمیشد ازش کار بخوام میخواستم پرامپت بنویسم ناخودآگاه جلمه رو با «بیزحمت» شروع میکردم 😅.
بدون اغراق احتمالا این بهترین تجربهای بود که تا حالا با یه agent داشتم.
@gocasts
دیشب با تاخیر چند ساعته ایمیل هاستینگ رو خوندم که نوشته بود «فردا ۸ صبح سرورتون رو با اسنپشات میبریم روی زیرساخت جدید، IP عوض میشه، از دیتاتون بکاپ بگیرید، مسئولیتش با خودتونه.» سرور، تنها سرور پروداکشن یه سازمانه که تو پنج سال گذشته هر چیزی که لازم بوده روش نصب شده: چند تا استک داکر (Nuxt، دو تا Laravel، MySQL های جدا)، وردپرس روی php-fpm و MariaDB خود هاست، یه رجیستری خصوصی داکر، ۱۹ تا دیتابیس که نصفشون legacyان، بیش از ۱۵ گیگ فایل و مدارک مهم سازمان، درگاههای بانکی که IP سرور رو whitelist کردن، و CentOS 7 که دو ساله EOL شده. دیسک ۹۹٪ پر بود و روش قدیمی بکاپ (tar بگیر، با HTTP دانلود کن) عملاً غیرممکن. کار ما عملاً ۱۲ شب شروع شد، یعنی ۸ ساعت تا مهاجرت.
ابزار Claude Code با مدل Fable رو باز کردم و اول نقشهی سرور رو کشید: کدوم سرویس کجاست، دیتا کجاست، چی به IP وابستهست. بعد فهمید پهنای باند سرور به لپتاپ من ۱۵۰ کیلوبایت بر ثانیهست و ۱۵ گیگ عمراً تا صبح نمیرسه؛ رفت سراغ object storage داخلی که کلیدش از قبل روی سرور بود، rclone رو بدون sudo نصب کرد، آپلود رو تو tmux راه انداخت و با ۶ مگابایت بر ثانیه تو ۴۰ دقیقه تموم شد. dump دیتابیسها رو گرفت و قبل از اینکه بگه «بکاپ داریم» روی لپتاپ من restore کرد و ردیفها رو شمرد. docker save ایمیجهایی که هیچجای دیگه وجود نداشتن، کانفیگها، docker inspect همهی کانتینرها، همه رفت. همزمان یه runbook زنده نوشت: وضعیت، ریسکها، پلن بکاپ با وضعیت هر آیتم، چکلیست تغییر IP، تستهای بعد از انتقال، و دستور بازسازی از صفر اگه اسنپشات خراب میشد. تو همین مسیر چند تا چیز پیدا کرد که خودم نمیدونستم: یه فایل nginx که روی IP قدیم listen میکرد و روی سرور جدید کل nginx رو زمین میزد (قبل از مهاجرت درستش کردیم)، اینکه کل زون DNS پشت CDN بود و TTL اصلاً مهم نبود، و گواهیهای TLS مبدأ که شش هفته بود منقضی شده بودن و CDN قایمشون کرده بود.
چیزی که این تجربه رو با هر ابزار دیگهای فرق داد، همیشهآنلاین بودنش بود. من وسطاش رفتم خوابیدم؛ Fable بیدار موند. هر ۵ دقیقه پیشرفت آپلود و تعداد خطاها رو چک میکرد، بعد از هر مرحله rclone check میزد و فایلها رو با دیسک مقایسه میکرد، بعد که تصمیم گرفتم بهخاطر تعویق احتمالی مهاجرت هیچ سرویسی رو stop نکنم، یه dump تکرارشوندهی ۵ دقیقهای گذاشت که تا لحظهی قطع سرور کار کرد و هر دور رو همون لحظه به storage میفرستاد. صبح که مهاجرت شروع شد، مانیتورش هر دقیقه IP قدیم و جدید رو میزد؛ لحظهی قطع رو ثبت کرد، لحظهی بالا اومدن سرور جدید رو گرفت، همون دقیقه SSH زد، شبکه و ۱۵ کانتینر و crash recovery هر دو MySQL و تعداد ردیف پرداختها و تعداد فایلها رو با شب قبل مقایسه کرد، بعد یه مانیتور روی CDN گذاشت که تکتک دامنهها کی ۲۰۰ برمیگردن، و بعد از اون هم تا یه ساعت، هر ۱۰ دقیقه پرداختهای موفق رو با همون ساعت دیروز و هفتهی قبل مقایسه کرد و نتیجه رو تو runbook نوشت تا مطمئن بشیم درآمد سازمان واقعاً برگشته. من صبح فقط ریویو میکردم، sudo میزدم و تصمیم میگرفتم؛ بقیهش چشم و دست اون بود.
نتیجه: حدود ۴۰ دقیقه downtime، که ۳۰ دقیقهش زمان خود اسنپشات و بوت سرور جدید توسط هاستینگ بود و ۱۰ دقیقهی بعدش عوض کردن origin تو CDN به دست خودم. صفر داده از دست رفت؛ آخرین پرداخت قبل از قطع و اولین پرداخت بعدش با شمارش ردیف تأیید شد. بعدش هم یه hotfix فرانت داد که فقط درگاهی که IP جدید رو تأیید کرده بود فعال بمونه (با env، بدون rebuild برای برگردوندن بقیه) و تو همون مسیر یه باگ چندساله پیدا شد: هر فرم پرداختی که کاربر دست به رادیوباتنها نمیزد به یه درگاه هاردکد میرفت. اغراق نمیکنم: اشتباه هم داشت (اولین نسخهی fix ای که برای flush کش نوشت یه باگ quoting داشت و خودش تو دور بعد درستش کرد). واقعا لذت بردم از همراهیش به عنوان یه همکار on-call که خسته نمیشه، همه چیز رو مستند میکنه و قبل از ادعا تست میکنه.
آخراش روم نمیشد ازش کار بخوام میخواستم پرامپت بنویسم ناخودآگاه جلمه رو با «بیزحمت» شروع میکردم 😅.
بدون اغراق احتمالا این بهترین تجربهای بود که تا حالا با یه agent داشتم.
@gocasts
- 🔥 74
- ❤ 16
- 👍 10
- 👏 2
- 🎉 2
