نسخه‌ای که با کمک ابزارهای AI ساخته‌اید روی لپ‌تاپ اجرا می‌شود؛ ثبت‌نام کار میکند و صفحه محصول آماده نمایش است. حالا قرار است کاربران واقعی وارد شوند، فایل بفرستند و شاید پرداخت کنند. باید بدانید اگر انتشار خراب شد، چطور برمی‌گردید؛ اگر داده پاک شد، چه چیزی را بازیابی می‌کنید؛ و اگر سرویس از دسترس خارج شد، چه کسی باخبر می‌شود. این چک لیست production کمک میکند آمادگی انتشار را با شواهد بسنجید و مسئولیت‌های اپلیکیشن را از مسئولیت زیرساخت جدا کنید.
پاسخ سریع: چه زمانی آماده انتشار هستید؟
وقتی مسیر اصلی محصول را روی نسخه مشخص آزموده‌اید، دسترسی‌ها را کنترل کرده‌اید، بازیابی داده را تمرین کرده‌اید و مسئول و اقدام هنگام خرابی را مشخص کرده‌اید، می‌توانید درباره انتشار تصمیم بگیرید.
اگر اطلاعات کاربران در معرض حذف است، کنترل دسترسی آزموده نشده یا مسیر بازیابی نامعلوم است، انتشار عمومی را متوقف کنید. برای موارد باز، مسئول و مدرک پذیرش ثبت کنید. Build بسته اجرایی برنامه را آماده میکند؛ موفقیتش مجوز ورود کاربران نیست.
چک لیست production را با مدرک تکمیل کنید
برای هر مورد در go live checklist، وضعیت، مسئول و شاهد ثبت کنید. «بکاپ فعال است» کافی نیست؛ «بکاپ را در محیط جدا بازیابی کرده‌اید و داده‌های مورد انتظار خواندنی‌اند» را می‌توان ارزیابی کرد.
احتمال افشای داده یا ثبت اشتباه پرداخت، مانع انتشار است؛ برای ایراد صرفاً ظاهری، مسئول و برنامه اصلاح ثبت کنید.
حتی اگر بیشتر کارها با شماست، مسئول تصمیم انتشار و رسیدگی به خرابی را بنویسید.
پیش از تغییر دامنه، مسیر انتشار را تمرین کنید
نسخه قابل شناسایی بسازید
نسخه انتشار را با Commit، شناسه ثبت تغییرات در Git، مشخص کنید. فایل قفل وابستگی‌ها را نگه دارید و در محیط تمیز Build بگیرید. ساخت نباید به فایل یا تنظیمات پنهان لپ‌تاپ وابسته باشد.
اگر Docker Image دارید، شناسه‌اش را ثبت کنید؛ Tag ممکن است به Image دیگری اشاره کند. Digest شناسه محتواست. با ثابت‌کردن آن، برای دریافت به‌روزرسانی‌های امنیتی برنامه‌ریزی کنید. راهنمای رسمی Docker
اگر ساخت متفاوت بود، نسخه وابستگی‌ها، Image پایه و فایل‌های خارج از Repository را بررسی کنید.
دسترسی و Secret را جداگانه آزمایش کنید
Secret را، مثل رمز دیتابیس یا کلید API، از کد جدا نگه دارید؛ در Repository، لاگ یا Prompt ابزار AI نگذارید. اگر افشا شده، حذف فایل کافی نیست؛ اعتبار افشاشده را لغو یا تعویض کنید. راهنمای مدیریت Secret در OWASP
با حساب غیرمدیریتی، دسترسی به داده و عملیات دیگران را امتحان کنید؛ برنامه باید درخواست غیرمجاز را رد کند. اگر دکمه پنهان است ولی API درخواست را می‌پذیرد، کنترل دسترسی کامل نیست.
حفظ داده و بازگشت نسخه را تمرین کنید
در محیط آزمایشی جدا از Production، داده و فایل بسازید؛ سپس نمونه اپلیکیشن را جایگزین کنید. داده باید باقی بماند. فایل داخل لایه نوشتنی Container با حذف آن از بین می‌رود؛ داده ماندگار را بیرون از این لایه نگه دارید. مستندات ذخیره‌سازی Docker
بکاپ را در مقصد جدا بازیابی و رکوردها، فایل‌ها و امکان ورود را بررسی کنید. اگر نتیجه ناقص بود، پوشش بکاپ و تنظیمات بازیابی را بازبینی کنید.
Migration، تغییر ساختار دیتابیس، را هم آزمایش کنید. بازگشت کد لزوماً تغییر دیتابیس را برنمی‌گرداند. پیش از حذف ستون یا تبدیل برگشت‌ناپذیر داده، سازگاری نسخه قبلی و راه بازیابی را مشخص کنید.
برای طراحی این تمرین، از راهنمای «بکاپ و بازیابی از فاجعه (DR) برای اپلیکیشن‌های ابری» استفاده کنید.
مسیر واقعی کاربر و وابستگی‌ها را بسنجید
سناریویی از محصول انتخاب کنید: ورود، ثبت سفارش، دریافت نتیجه و مشاهده سابقه. در محیط آزمایشی با داده ساختگی اجرا کنید و نتیجه را در دیتابیس و لاگ تطبیق دهید.
برای کاربران داخل ایران، دسترسی شبکه کاربر و ارتباط محیط اجرا با سرویس‌های خارجی را جداگانه بسنجید. موفقیت درخواست از لپ‌تاپ متصل به VPN، کارکرد API از سرور را تأیید نمی‌کند.
در Health Check (بررسی خودکار سلامت سرویس)، زنده‌بودن فرایند را از آمادگی پذیرش درخواست جدا کنید. مستندات Kubernetes درباره بررسی سلامت
بار مورد انتظار محصول را در محیط آزمایشی بسنجید. اگر پاسخ‌گویی افت کرد، مصرف منابع و وابستگی کند را بررسی کنید؛ افزایش منابع را درمان پیش‌فرض ندانید.
