تیم می‌گوید نسخهٔ جدید آماده است، ولی آدرس سرویس باز نمی‌شود. پیشنهاد اول، خرید منابع بیشتر است؛ پیشنهاد بعدی، بازگشت به نسخهٔ قبلی. هیچ‌کدام بدون تشخیص علت، تصمیم قابل دفاعی نیست. خطای دیپلوی، یعنی شکست در انتشار و راه‌اندازی نسخه، می‌تواند از تنظیمات برنامه، دسترسی شبکه، کمبود منابع یا ناسازگاری داده ناشی شود. شما برای تصمیم بودجه به نام خطا نیاز ندارید؛ باید بدانید چه چیزی تحویل را متوقف کرده، داده در چه وضعیتی است و هزینهٔ پیشنهادی کدام علت را برطرف می‌کند. راه‌حل وقتی قطعی می‌شود که شواهد، علت را تأیید کنند.
برای رفع خطای دیپلوی، اول آخرین مرحلهٔ موفق را پیدا کنید
اثر بر سرعت تحویل: تشخیص مرحلهٔ شکست، دامنهٔ بررسی را محدود می‌کند.
پیش از تأیید خرید منابع یا تغییر پلتفرم، از تیم بخواهید مشخص کند نسخه در کدام مرحله متوقف شده است: آمادهسازی، انتقال، شروع اجرا یا پاسخ‌گویی به کاربر.
برای مثال، ImagePullBackOff، یعنی محیط اجرا نتوانسته بستهٔ برنامه را دریافت کند، با CrashLoopBackOff، یعنی برنامه پس از شروع مرتب متوقف می‌شود، یک مسئله نیست. اولی ممکن است به دسترسی نیاز داشته باشد؛ دومی به اصلاح برنامه یا تنظیمات. هزینه‌کرد باید به علت مربوط باشد. دریافت بستهٔ برنامه، توقف و اجرای مجدد برنامه
برای تصمیم، این اطلاعات را بخواهید: شناسهٔ نسخه، زمان شروع مشکل، آخرین تغییر و نخستین شکست ثبت‌شده. بازگشت به نسخهٔ سالم قبلی هم باید با بررسی سازگاری دیتابیس، محل نگه‌داری داده‌های برنامه، همراه باشد.
از ساخت Image تا پاسخ وب، کدام حلقه قطع شده است؟
اثر بر هزینه: هزینهٔ اصلاح برنامه را از هزینهٔ زیرساخت جدا کنید.
Image، بستهٔ آمادهٔ اجرای برنامه، در مسیر زیر ساخته و راه‌اندازی می‌شود:
کد برنامه ← ساخت بستهٔ اجرایی ← دریافت در محیط اجرا ← شروع برنامه ← آمادگی پاسخ‌گویی ← دسترسی کاربر
موفقیت در ساخت بسته، پاسخ‌گویی سرویس را ثابت نمیکند. ممکن است ساخت تمام شده باشد، ولی برنامه تنظیم لازم را نداشته باشد یا درخواست کاربر به آن نرسد.
از تیم بخواهید دو نوع شاهد ارائه کند: گزارش اجرای برنامه و گزارش اتفاقات محیط اجرا. اولی رفتار برنامه را نشان می‌دهد؛ دومی به مشکلاتی مانند دریافت بسته یا تخصیص منابع اشاره می‌کند.
جزئیات واحد اجرای برنامه در راهنمای «Pod چیست؟ کوچک‌ترین واحد اجرا در کوبرنتیز» آمده است. برای جلسهٔ بودجه، کافی است بدانید مشکل داخل برنامه است یا در محیط اجرای آن؛ مدیریت مستقیم این محیط، مسئولیتی جداگانه است.
این ۱۰ نشانه شما را به اقدام درست می‌رسانند
برای هر مورد، یک اثر اصلی مشخص شده است. این دسته‌بندی، سایر پیامدهای خطا را حذف نمیکند؛ نقطهٔ شروع تصمیم را نشان می‌دهد.
۱. Build به فایل لازم دسترسی ندارد
Build، یعنی ساخت بستهٔ اجرایی از کد برنامه.
اثر اصلی: سرعت تحویل
-
آنچه شما می‌بینید: نسخه پیش از آماده‌شدن برای اجرا متوقف می‌شود.
-
علت‌های محتمل: فایل لازم در ورودی ساخت نیست یا تنظیمات ساخت آن را کنار گذاشته‌اند.
-
برای تشخیص از تیم بخواهید: مرحلهٔ شکست و فایل مفقود را مشخص کند و آن را با محتوای نسخه تطبیق دهد.
-
اقدام بعدی: اصلاح ورودی یا تنظیمات ساخت را پیگیری کنید. خرید حافظه، نبود فایل را برطرف نمیکند.
-
ریسک داده: دادهٔ سرویس معمولاً تغییر نمیکند؛ وجود فایل محرمانه در ورودی ساخت می‌تواند خطر افشا ایجاد کند. محدودهٔ فایل‌های قابل‌دسترسی هنگام ساخت
معیار پذیرش اصلاح، عبور از همان مرحلهٔ شکست است. اگر مرحلهٔ بعد شکست خورد، علت جدید را جدا بررسی کنید.
۲. وضعیت ImagePullBackOff دیده می‌شود
اثر اصلی: سرعت تحویل
-
آنچه شما می‌بینید: بستهٔ برنامه به محیط اجرا نمی‌رسد؛ سرویس شروع نمی‌شود.
-
علت‌های محتمل: نشانی بسته اشتباه است، بسته منتشر نشده یا محیط اجرا مجوز دریافت ندارد.
-
برای تشخیص از تیم بخواهید: دریافت را از محیط مقصد بررسی کند. موفقیت روی لپتاپ، دسترسی سرور را ثابت نمیکند.
-
اقدام بعدی: نشانی، انتشار یا مجوز را اصلاح کنید. اگر محل نگه‌داری بسته خصوصی است، روش دریافت مجاز آن باید در پلتفرم پشتیبانی شود.
-
ریسک داده: خود خطا داده را حذف نمیکند؛ عمومی‌کردن بستهٔ خصوصی برای عبور از خطا می‌تواند اطلاعات را افشا کند. علت‌های شکست دریافت بسته
پشتیبانی دریافت از محل نگه‌داری خصوصی در پاستا، پیش از انتخاب این مسیر نیازمند تأیید است.
۳. تنظیمات یا Secret لازم به برنامه نمی‌رسد
Secret، یعنی سازوکار نگه‌داری اطلاعات محرمانه مانند رمز اتصال.
اثر اصلی: ریسک
-
آنچه شما می‌بینید: برنامه شروع نمی‌شود یا هنگام دسترسی به سرویس وابسته متوقف می‌شود.
-
علت‌های محتمل: تنظیمی وجود ندارد، نام آن اشتباه است یا برنامه تنظیمات محیط دیگری را می‌خواند.
-
برای تشخیص از تیم بخواهید: وجود تنظیمات و مقصد اتصال را بررسی کند؛ مقدار رمز نباید وارد گزارش قابل‌اشتراک شود.
-
اقدام بعدی: تنظیمات را از مسیر نگه‌داری اطلاعات محرمانه اصلاح کنید و اتصال را دوباره بسنجید. پاستا از متغیر محیطی، یعنی تنظیمات بیرون از کد برنامه، و Secret پشتیبانی می‌کند.
-
ریسک داده: برنامه ممکن است به دیتابیس دیگری متصل شود. پیش از نوشتن داده، مقصد را تأیید کنید. وابستگی شروع برنامه به اطلاعات محرمانه
اطلاعات محرمانهٔ زمان ساخت با زمان اجرا تفاوت دارند. تیم نباید برای رفع مشکل، رمز را داخل فایل ساخت یا بستهٔ برنامه قرار دهد. محدودیت انتقال رمز هنگام ساخت
۴. وضعیت CrashLoopBackOff تکرار می‌شود
اثر اصلی: ریسک
-
آنچه شما می‌بینید: برنامه شروع می‌شود، متوقف می‌شود و دوباره همین چرخه را تکرار می‌کند.
-
علت‌های محتمل: اشکال برنامه، تنظیمات نامعتبر، کمبود منابع یا شکست بررسی سلامت.
-
برای تشخیص از تیم بخواهید: گزارش اجرای فعلی و قبلی را با علت آخرین توقف تطبیق دهد. تکرار راه‌اندازی، به‌تنهایی علت را روشن نمیکند.
-
اقدام بعدی: اصلاح را به علت ثبت‌شده محدود کنید. معیار پذیرش، متوقف‌شدن چرخهٔ راه‌اندازی مجدد است.
-
ریسک داده: اگر برنامه هنگام شروع، پیام ارسال می‌کند یا داده تغییر می‌دهد، اجرای تکراری آن باید کنترل شود. بررسی گزارش اجرای قبلی
برای دنبال‌کردن رخداد میان چند سرویس، راهنمای «مدیریت لاگ متمرکز برای چند سرویس» مرتبط است. لاگ یعنی گزارش اجرای برنامه؛ رویداد، گزارش اتفاقات محیط اجراست.
جایگاه CTA میانی پیشنهادی، مشروط به تأیید دامنهٔ ادعا:
۵. علت توقف OOMKilled است
OOMKilled یعنی برنامه به‌دلیل کمبود حافظه متوقف شده است.
اثر اصلی: هزینه
-
آنچه شما می‌بینید: برنامه هنگام اجرا متوقف می‌شود و تیم افزایش حافظه را پیشنهاد می‌دهد.
-
علت‌های محتمل: منابع کمتر از نیاز برنامه‌اند یا اشکال برنامه باعث رشد مصرف حافظه شده است.
-
برای تشخیص از تیم بخواهید: مصرف حافظه در زمان رخداد را با سقف تخصیص و تغییرات نسخه مقایسه کند. صرف توقف، کمبود حافظه را ثابت نمیکند.
-
اقدام بعدی: افزایش منابع را با شواهد مصرف تأیید کنید. اگر مصرف پیوسته رشد می‌کند، اصلاح برنامه را هم پیگیری کنید.
-
ریسک داده: کار جاری ممکن است نیمه‌تمام بماند؛ تیم باید سلامت عملیات ثبت داده و امکان اجرای دوبارهٔ کار را بررسی کند. رفتار برنامه هنگام کمبود حافظه
افزایش حافظه هزینهٔ تکرارشونده دارد؛ اگر علت، اشکال برنامه باشد، خرید منابع آن را درمان نمیکند.
۶. Pod در وضعیت Pending می‌ماند
Pod، واحد اجرای برنامه، در وضعیت Pending یعنی هنوز وارد اجرای موردانتظار نشده است.
اثر اصلی: سرعت تحویل
-
آنچه شما می‌بینید: درخواست اجرا ثبت شده، ولی سرویس پیش نمی‌رود.
-
علت‌های محتمل: ظرفیت مناسب وجود ندارد، محدودیت اجرا مانع شده یا فضای ذخیره‌سازی آماده نیست.
-
برای تشخیص از تیم بخواهید: مشخص کند انتظار مربوط به منابع پردازشی است یا فضای ذخیره‌سازی.
-
اقدام بعدی: اگر تنظیمات ناسازگارند، آن‌ها را اصلاح کنید؛ اگر ظرفیت یا تأمین فضای ذخیره‌سازی مسئله است، بررسی را به مسئول زیرساخت یا پشتیبانی بسپارید.
-
ریسک داده: خود انتظار معمولاً داده را تغییر نمی‌دهد؛ حذف دیسک و ساخت دوبارهٔ آن برای رفع خطا می‌تواند مخرب باشد. تشخیص توقف پیش از اجرا
پیش از تأیید هزینهٔ بیشتر، بخواهید تیم مانع را مشخص کند. خرید پردازنده، مشکل آماده‌نبودن دیسک را حل نمیکند.
۷. برنامه اجرا می‌شود، ولی Health Check موفق نیست
Health Check، یعنی بررسی آمادگی یا سلامت برنامه.
اثر اصلی: سرعت تحویل
-
آنچه شما می‌بینید: برنامه ظاهراً اجرا شده، ولی کاربر پاسخ نمی‌گیرد یا برنامه دوباره راه‌اندازی می‌شود.
-
علت‌های محتمل: نشانی بررسی اشتباه است، برنامه پاسخ موردانتظار نمی‌دهد یا فرصت کافی برای شروع ندارد.
-
برای تشخیص از تیم بخواهید: مشخص کند بررسی، آمادگی دریافت درخواست را می‌سنجد یا در صورت شکست، برنامه را دوباره راه‌اندازی می‌کند.
-
اقدام بعدی: تنظیم بررسی را با رفتار اندازه‌گیری‌شدهٔ برنامه هماهنگ کنید. وجود تنظیم مناسب در پلتفرم انتخابی را تأیید کنید.
-
ریسک داده: بررسی آمادگی به‌تنهایی برنامه را متوقف نمیکند؛ راه‌اندازی مجدد می‌تواند کار جاری را قطع کند. تفاوت بررسی آمادگی و سلامت
معیار تحویل، پاسخ‌گویی برنامه است؛ فعال‌بودن پردازش کافی نیست.
۸. برنامه داخل Container پاسخ می‌دهد، ولی آدرس وب باز نمی‌شود
Container، یعنی محیط اجرای بستهٔ برنامه.
اثر اصلی: سرعت تحویل
-
آنچه شما می‌بینید: تیم اجرای برنامه را تأیید می‌کند، ولی آدرس وب پاسخ موردانتظار را نمی‌دهد.
-
علت‌های محتمل: مسیر ورود درخواست با تنظیمات برنامه هماهنگ نیست یا درخواست به اجرای درست نمی‌رسد.
-
برای تشخیص از تیم بخواهید: پاسخ برنامه، مسیر داخلی درخواست و سپس دسترسی وب را به‌ترتیب بررسی کند.
-
اقدام بعدی: مسیر ارتباط را اصلاح کنید. اگر آدرس پلتفرم پاسخ می‌دهد ولی دامنهٔ شخصی نه، بررسی را روی اتصال دامنه و گواهی ارتباط رمزگذاری‌شده متمرکز کنید.
-
ریسک داده: مسئله معمولاً دسترس‌پذیری است؛ عمومی‌کردن مسیر اتصال دیتابیس راه‌حل نیست. بررسی مسیر رسیدن درخواست به برنامه
۹. نسخهٔ جدید با ساختار دیتابیس سازگار نیست
اثر اصلی: ریسک
-
آنچه شما می‌بینید: نسخهٔ جدید بالا نمی‌آید یا بخش‌های وابسته به داده کار نمی‌کنند.
-
علت‌های محتمل: تغییر لازم در ساختار داده اجرا نشده، ناقص مانده یا با نسخهٔ برنامه هماهنگ نیست.
-
برای تشخیص از تیم بخواهید: نسخهٔ برنامه، تغییرات انجام‌شده در دیتابیس و مقصد اتصال را تطبیق دهد.
-
اقدام بعدی: پیش از تغییر در سرویس اصلی، نتیجهٔ آزمون و مسیر بازیابی را بخواهید. بازگشت برنامه به نسخهٔ قبلی، ساختار دیتابیس را خودکار برنمی‌گرداند.
-
ریسک داده: حذف ستون، تبدیل داده یا بازگردانی نسخهٔ پشتیبان می‌تواند داده را تغییر دهد یا از دسترس خارج کند. بعضی تغییرات برگشت‌پذیر نیستند. محدودیت بازگردانی تغییرات دیتابیس
در این وضعیت، تصمیم بازگشت نسخه باید همراه با بررسی داده باشد. تأیید فنی اجرای برنامه به‌تنهایی کافی نیست.
۱۰. پس از استقرار، فایل‌های آپلودشده دیده نمی‌شوند
اثر اصلی: ریسک
-
آنچه شما می‌بینید: سرویس کار می‌کند، ولی فایل‌های قبلی نیستند؛ ممکن است پیام خطایی هم وجود نداشته باشد.
-
علت‌های محتمل: برنامه فایل را در فضای موقت نوشته یا پس از انتشار به مسیر دیگری نگاه می‌کند.
-
برای تشخیص از تیم بخواهید: مشخص کند فایل حذف شده یا فقط مسیر دسترسی تغییر کرده است.
-
اقدام بعدی: اگر اجرای قبلی هنوز در دسترس است، پیش از تغییر از دادهٔ قابل‌بازیابی نسخه بردارید. سپس مسیر ذخیره و ماندگاری فایل را آزمایش کنید. پاستا امکان استفاده از دیسک پایدار دارد.
-
ریسک داده: حذف فضای ذخیره‌سازی ممکن است داده را هم حذف کند. دیسک پایدار جای نسخهٔ پشتیبان را نمی‌گیرد. تفاوت فضای موقت و پایدار، پیامد حذف فضای ذخیره‌سازی
