چک‌لیست آمادگی production

پیش از هدایت ترافیک واقعی، build، runtime، داده، TLS، مشاهده‌پذیری و recovery برنامه را بررسی کنید.

آخرین بازبینی:

این چک‌لیست را پیش از اتصال دامنه اصلی یا هدایت ترافیک واقعی اجرا کنید. هر مورد باید نتیجه قابل‌مشاهده داشته باشد، نه فقط یک تنظیم ذخیره‌شده.

build و artifact

  • Dockerfile یا build plan تشخیص‌داده‌شده را در جزئیات deployment بررسی کرده‌اید.
  • نسخه dependencyها lock شده و image با tag یا digest قابل‌شناسایی منتشر می‌شود.
  • credential، .env و فایل خصوصی وارد build context یا image نشده‌اند.
  • command شروع process طولانی‌مدت است و روی 0.0.0.0 و پورت App گوش می‌دهد.
  • یک deployment از commit یا image مورد نظر به Ready رسیده است.

راهنما: پیکربندی build و استقرار Docker image

پیکربندی و امنیت

  • متغیرهای لازم در App تنظیم شده و مقدار حساس در repository یا log نیست.
  • tokenهای CI کمترین دسترسی لازم را دارند و از secret store خوانده می‌شوند.
  • image در حالت restricted اجرا می‌شود؛ compatible فقط با دلیل مشخص استفاده شده است.
  • خطاهای application اطلاعات credential، query داخلی یا stack حساس را نمایش نمی‌دهند.

راهنما: متغیرهای محیطی

health و runtime

  • endpoint اصلی، نه فقط صفحه root، پاسخ معتبر می‌دهد.
  • health path سریع است و به dependency اختیاری وابستگی غیرضروری ندارد.
  • restart برنامه آزموده شده و زمان بازیابی قابل‌قبول است.
  • plan فعلی CPU، memory و storage کافی دارد.
  • رفتار stop/start و اثر هزینه storage برای تیم روشن است.

راهنما: چرخه عمر و تغییر plan

داده

  • اتصال دیتابیس از خود App با یک query واقعی تأیید شده است.
  • migrationها قبل یا هنگام release به روش کنترل‌شده اجرا می‌شوند.
  • برای داده production سیاست backup و retention دارید.
  • restore در محیط غیرproduction آزموده شده است.
  • داده persistent disk جدا از code است و export یا backup مستقل دارد.

راهنما: اتصال دیتابیس و دیسک پایدار

دامنه و TLS

  • TXT مالکیت و CNAME routing هر دو verified هستند.
  • TLS وضعیت ready دارد و تاریخ expiry/renewal قابل‌مشاهده است.
  • HTTP به HTTPS طبق انتظار redirect می‌شود.
  • CAA و دسترسی عمومی پورت 80 مانع renewal نیستند.
  • تغییر DNS با TTL و مسیر rollback برنامه‌ریزی شده است.

راهنما: دامنه اختصاصی و TLS

مشاهده‌پذیری و recovery

  • اعضای مسئول می‌دانند لاگ deployment و runtime چه تفاوتی دارند.
  • یک failure آزمایشی یا staging تشخیص داده شده است.
  • شناسه آخرین deployment سالم مشخص است.
  • rollback اجرا یا حداقل در محیط غیرproduction تمرین شده است.
  • پس از rollback، endpoint اصلی و داده بررسی می‌شوند.
abrun app deployment list <app>
abrun app logs <app> --tail 100

راهنما: مراحل، لاگ‌ها و rollback و مانیتورینگ، لاگ و Analytics

بررسی نهایی

پس از تکمیل موارد بالا:

  1. deployment مورد نظر را یک بار دیگر inspect کنید.
  2. URL پیش‌فرض و دامنه اختصاصی را آزمایش کنید.
  3. یک عملیات خواندن و نوشتن واقعی اجرا کنید.
  4. metric و log را هنگام همان عملیات ببینید.
  5. مسئول rollback و پاسخ‌گویی را مشخص کنید.

production readiness یک وضعیت دائمی نیست؛ این مرور را پس از تغییر build، plan، domain، database یا storage تکرار کنید.

این صفحه مفید بود؟

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