آنچه که تیم های Adtech می توانند از Servers.com توسط Nexcess Support انتظار داشته باشند

در یک نگاه:

• یک تیم حساب اختصاصی از قبل از زیرساخت‌ها، نمایه ترافیک و تاریخچه رویداد شما می‌داند، بنابراین مکالمات حادثه با تشخیص شروع می‌شوند، نه ایجاد زمینه.
• کیفیت پاسخگویی پس از ساعت کاری کاهش نمی یابد. همان تیم، ردیف، و مسیر تشدید در ساعت 2 بامداد و در ساعت 2 بعد از ظهر اعمال می شود.
• مهندسان ما زیرساخت را با استفاده از RTB به عنوان نقطه مرجع بررسی می کنند، نه منطق پیشنهاد شما، و می دانند که کدام معیارها یک مشکل شبکه را از یک مشکل جدا می کند. node مشکل
• نظارت پیشگیرانه به این معناست که یک تیم حساب کاربری روندها را قبل از تبدیل شدن به یک رویداد تماشا می کند، نه داشبوردی که خودتان پیکربندی می کنید.
• این رابطه با رشد پلتفرم به جای کناره‌گیری پس از ورود به سیستم، عمیق‌تر می‌شود، بنابراین تصمیمات رویداد رشد با زمینه‌ای همراه می‌شوند که صف بلیط هرگز ایجاد نمی‌شود.

پنج فرض در مورد Servers.com توسط Nexcess پشتیبانی می کند که از تماس اول باقی نمی ماند

پس از بررسی‌های تأخیر کافی، بحث‌های مربوط به ظرفیت، و حوادث یک شبه، این سؤال از این موضوع که آیا پشتیبانی در دسترس است یا خیر، متوقف می‌شود و شروع می‌شود به روش عملکرد رابطه.

در اینجا پنج فرض وجود دارد که در طول 90 روز اول شما تغییر خواهند کرد روی Servers.com توسط Nexcess.

“پشتیبانی مانند سایر فروشندگان زیرساخت مبتنی بر بلیط خواهد بود.”

واقعیت یک تیم حساب اختصاصی است که قبلاً از پیکربندی زیرساخت پلت فرم، نمایه ترافیک و تاریخچه حادثه قبل از بروز هر مشکلی مطلع است. بلیط ثبت نام و پیگیری کار. رابط اصلی یک خط مستقیم به آن تیم است.

آنچه تغییر می کند این است که یک گفتگوی حادثه از کجا شروع می شود. با اکثر ارائه دهندگان ابر، بخش اول گفتگو صرف ایجاد زمینه می شود: پلتفرم چه کاری انجام می دهد، چه چیزی عادی است، چه چیزی تغییر کرده است. با ما، این زمینه از قبل وجود دارد. گفتگو بسیار نزدیکتر به تشخیص شروع می شود.

“زمان پاسخ در طول یک حادثه تاخیر ساعت 2 بامداد کندتر از ساعات کاری خواهد بود.”

این از روش عملکرد اکثر پشتیبانی های زیرساختی ناشی می شود. پشتیبانی زیرساخت adtech ما در ساعت 2 بامداد به همین صورت انجام می شود روی سه شنبه مانند ساعت 2 بعد از ظهر روی یک پنجشنبه: همان ردیف پشتیبانی، زمینه، و مسیر تشدید.

تفاوت در سرعت رسیدن تحقیقات به معیارهای زیرساخت مربوطه نشان می دهد. در پشتیبانی ابر همه‌منظوره، تشدید بعد از ساعت کاری معمولاً با یک زمینه ساختمان مهندس از ابتدا شروع می‌شود. با وارد شدن به یک حادثه، تیم ما از قبل نمایه تاخیر پایه، رفتار اوج تاریخی و node پیکربندی، بنابراین بررسی بیشتر ادامه می‌یابد، زیرا تیم از قبل می‌داند که «عادی» برای محیط شما چگونه به نظر می‌رسد.

مهندسان Servers.com مشکلات عملکرد خاص RTB را درک نمی کنند.

اینجاست که مرز بین زیرساخت و برنامه تار می شود. یک علامت برنامه اغلب در زیرساخت شروع می شود، و جدا کردن این دو در یک محیط مناقصه بلادرنگ نسبت به اکثر بارهای کاری دشوارتر است.

مهندسان ما زیرساخت را با استفاده از RTB به عنوان چارچوب مرجع بررسی می کنند، نه منطق پیشنهاد شما. هنگامی که تیم شما یک کاهش نرخ برد را گزارش می‌کند که با تغییر p99 مرتبط است، تیم ما می‌داند که کدام معیارهای زیرساخت را ابتدا باید انجام دهد: شاخص‌هایی که مشکل مسیر شبکه را از یک مشکل متمایز می‌کند. node مشکل پیکربندی، واریانس p99 معمولی چگونه به نظر می رسد روی گره‌های اختصاصی تحت آن نمایه بار، و اینکه آیا مشکل از زیرساخت شروع می‌شود یا در جایی بالاتر در پشته.

پشتیبانی از زیرساخت های همه منظوره این دانش را به یک حادثه adtech نمی رساند. مرز دامنه در هر صورت یکسان است: لایه برنامه، منطق مناقصه و اتصال تبادل مدیریت شده در سطح برنامه با تیم شما باقی می مانند. در محدوده زیرساخت، تحقیق حول عملکرد RTB است، نه اشکال زدایی بار کاری عمومی.

“نظارت فعال از Servers.com توسط Nexcess فقط هشدارهای خودکاری است که باید پیکربندی کنیم.”

در اکثر پلتفرم‌های زیرساخت، “نظارت فعال” به معنای هشدار مبتنی بر آستانه است که وقتی یک متریک از یک خط عبور می‌کند، به کسی صفحه می‌دهد.

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

برای تیم های عملیاتی با کارکنان ناب، این بار نظارت بر لایه زیرساخت را به سرورها منتقل می کند. مسئولیت نظارت تیم شما در جایی که به آن تعلق دارد باقی می ماند: عملکرد لایه برنامه، معیارهای خط لوله پیشنهادات، و تجزیه و تحلیل در سطح تبادل.

“مدل پشتیبانی پس از دوره اولیه ورود تغییر نخواهد کرد.”

برخلاف مدل سوار شدن-سپس تعمیر و نگهداری که اکثر فروشندگان زیرساخت اجرا می کنند، تعامل ما به جای کناره گیری پس از پیکربندی اولیه، در کنار پلت فرم توسعه می یابد.

رویدادهای رشد جایی هستند که این مهم است: پیوستن یک شریک تقاضای اصلی به پلتفرم، افزایش قابل توجه حجم پیشنهادات، یک استقرار منطقه ای جدید. هر کدام شامل تصمیمات زیرساختی است که در آن تیم حساب ما زمینه خاصی را برای حجم کاری شما ارائه می دهد. صف بلیط در طول زمان چنین زمینه ای را ایجاد نمی کند.

مرزها در طول رابطه یکسان می مانند: ما مالک زیرساخت هستیم، تیم شما مالک برنامه است. زمانی که یک تصمیم یا حادثه مهم رخ می دهد، هر دو تیم از قبل می دانند که در چه محیطی کار می کنند، و این تفاوتی است که یک صف بلیط نمی تواند تکرار کند.