Loading...

راهنمای CDN.com.tr

بازکردن یک تیکت پشتیبانی با تشخیص

یک تیکت متمرکز با جزئیات حساب، دامنه، عملیات و وضعیت ارسال کنید.

بازکردن یک تیکت پشتیبانی با تشخیص

یک تیکت متمرکز با جزئیات حساب، دامنه، عملیات و وضعیت ارسال کنید.

مسیر در پنل

  1. Management Panel
  2. Support
  3. Create ticket
  4. Diagnostics attachment

پیش‌نیازها

  • تیکت نباید شامل توکن، رمز عبور، کلید خصوصی یا کلید دسترسی باشد.
  • داده دامنه/حساب فقط در کمترین سطح لازم همراه با اسکرین‌شات به اشتراک گذاشته می‌شود.
  • برچسب زمانی/وضعیت عملیات زمینه شروع کافی برای پشتیبانی است.

راهنمای گام‌به‌گام

1

بازکردن تیکت با دسته‌بندی درست

درخواست پشتیبانی باید شامل زمینه محصول، حساب و وضعیت قابل مشاهده باشد.

  • Support را باز کنید.
  • دسته‌بندی و توضیح کوتاه را انتخاب کنید.
  • پیش از پیوست، اسکرین‌شات را از نظر رازها بررسی کنید.

نتیجه مورد انتظار: پشتیبانی با محصول/زمینه درست آغاز می‌شود.

معادل cdnctl
# Support ticket is opened in the panel.
2

پیوست ایمن تشخیص

اسکرین‌شات‌هایی که وضعیت Operation، DNS یا SSL را توضیح می‌دهند از ماسک‌های داده باریک استفاده می‌کنند.

  • وضعیت و برچسب زمانی عملیات را بگنجانید.
  • رازهایی مانند توکن/رمز عبور را حذف کنید.
  • نتیجه آزمایش URL عمومی را ذکر کنید.

نتیجه مورد انتظار: تیکت اطلاعات مفید کافی بدون داده حساس دارد.

راستی‌آزمایی

  • تیکت هیچ رازی ندارد.
  • عملیات/وضعیت برای مشتری قابل مشاهده است.
  • اسکرین‌شات فقط فیلدهای داده را ماسک می‌کند.

موارد کاربرد

یک مشتری SSL در انتظار یا شکست تأیید DNS دارد و به کمک نیاز دارد.

جریان کاری سریع

  1. بازکردن Support.
  2. ساخت تیکت.
  3. افزودن دامنه، نام مستعار حساب، UUID عملیات در صورت نمایان بودن، بازه زمانی و اسکرین‌شات.
  4. پیگیری وضعیت تیکت.

بررسی‌ها

  • هیچ راز/توکنی گنجانده نمی‌شود.
  • دسته‌بندی مشکل روشن است.
  • وضعیت قابل مشاهده برای مشتری گنجانده می‌شود.

صفحات مرتبط

تاریخچه فعالیت: چه کسی چه چیزی را تغییر داد

هر تغییر عملیاتی روی یک حساب همراه با فرد پشت آن، زمان، و مقادیر قبل و بعد ثبت می‌شود. تاریخچه فعالیت بدون نیاز به پرسیدن از پشتیبانی به «چه کسی آن مسیر را purge کرد» و «این رکورد کی تغییر کرد» پاسخ می‌دهد.

نقش‌های تیم: viewer، editor و owner

به هر همکار ورود جداگانه خودش و کوچک‌ترین نقشی که کارش را ممکن می‌کند بدهید. همان نقش روی API هم اعمال می‌شود، پس یک bearer token هرگز نمی‌تواند بیش از فردی که به او تعلق دارد کاری انجام دهد.