4 سوالی که مشتریان SaaS بعد از یک خانم SLA می پرسند

در یک نگاه

• چهل و هشت ساعت پس از یک شکست SLA، شما برای اطمینان خاطر نمی‌خواهید — شما در حال ایجاد پرونده برای تمدید یا عدم تمدید آن هستید.

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

• اگر نظارت زیرساخت آنها عملکرد برنامه را پوشش دهد اما چیزی کمتر از آن نباشد، این شکاف در رویداد بعدی قبل از اینکه در پاسخ آنها نشان داده شود نشان داده می شود.

• بیشتر حذف‌های SaaS SLA شرایط را در لایه مجازی‌سازی ایجاد می‌کنند – که اغلب دقیقاً جایی است که حادثه شروع شده است.

گفتگوی تمدید 48 ساعت پس از حادثه آغاز می شود

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

در صورتی که پاسخ آنها یک وضعیت است page ورود و پس از مرگ که می گوید “ما وضعیت را زیر نظر داریم”، شما در حال مذاکره هستید.

در اینجا چیزی است که شما در واقع به پاسخ نیاز دارید.

“آیا می توانید ما را از طریق آن راهنمایی کنید root علت حادثه هفته گذشته؟

شما برای اطمینان خاطر نمی خواهید. شما به سندی نیاز دارید که تیم مهندسی یا حامی اجرایی شما بتواند آن را بخواند تا بفهمد چرا گردش کار شما تحت تأثیر قرار گرفته است و برای چه مدت.

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

آنها می توانند آنچه را که مشاهده کرده اند و آنچه را که تلاش کرده اند مستند کنند. آنها نمی توانند آنچه را که نمی توانستند ببینند، مستند کنند، که اغلب از همان جایی است که حادثه در واقع شروع شده است.

“چه تغییراتی ایجاد کرده اید تا اطمینان حاصل کنید که این اتفاق در زمان اوج ما نمی افتد؟”

این یک سوال تعهد است، نه یک سوال طرح. “ما به X نگاه می کنیم” یک طرح است. “ما Y را تغییر دادیم و این شواهد است” یک تعهد است.

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

اگر چند مورد از این موارد را گذرانده باشید، تفاوت را می دانید. وقتی پاسخ آنها در لایه برنامه متوقف شد، بپرسید که در زیر آن چه اتفاقی می افتد.

“چه نظارتی دارید تا قبل از اینکه به دست کاربران ما برسد، این موضوع را شناسایی کنید؟”

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

پیگیری ارزش پرسیدن دارد: چه دیدی در آنجا دارید؟

“آیا می توانید مدارک کامل SLA، از جمله موارد استثنا را برای ما ارسال کنید؟”

چیزی که برای آن می خوانید درصد آپتایم نیست. این بخش استثناها است، به ویژه اینکه آیا آنچه اخیراً رخ داده است به عنوان یک نقض پوشش داده شده یا یک رویداد مستثنی واجد شرایط است.

اکثر SLAهای SaaS شامل موارد زیرساختی استاندارد هستند: فورس ماژور، اختلالات خدمات شخص ثالث و تعمیر و نگهداری برنامه ریزی شده. این حکاکی ها منعکس کننده محدودیت های چیزی است که فروشنده می تواند در محیط خود ببیند و کنترل کند. شرایط در لایه مجازی سازی یا شبکه زیربنایی یک ارائه دهنده اغلب در دسته حذف شده قرار می گیرند، به این معنی که از دست دادن ممکن است راه حلی را که شما انتظار داشتید ایجاد نکند.

ارزش دانستن آن را قبل از شروع مکالمه تمدید دارد، نه در حین آن.