اگر یکی از بزرگترین شرکتهای تکنولوژی دنیا دچار اختلال سرور ابری می‌شود ، پس احتمال بروز این مشکل درسایر سازمانها نیز وجود دارد. اختلال در سرور ابری گوگل یک آزمون جدی برای سازمانها و شرکتها بود و سبب شد نگرانیهای زیادی در مورد قابل اطمینان بودن سرور ابری و همچنین آسیب‌پذیر بودن ساختار این سرور ا به وجود بیاید.
این واقعه تأثیر بسیاری بر روی عملکرد و SLA ها داشت. این واقعه یک نمونهٔ عبرت‌آموز از بلایی است که اگر اپلیکیشن شما تنها متکی بر یک شرکت عرضه‌کنندهٔ سرور ابری باشد، ممکن است بر سر آن بیاید. بررسی‌ها نشان داد که با کاهش میزان دسترسی به برخی از سایتهای مطرح در زمینهٔ تجارت الکترونیک، رسانه‌ها و صنایع تولید بازی ، زمان بارگیری صفحات و پاسخگویی افزایش یافتند. این اختلال بر روی سرویسهای چندگانهٔ گوگل از جمله GSuite, Google Compute Engine, Google Nest, Snapchat, Discord و Shopify هم تأثیر گذاشت. این مشکل در ISP های مختلف و در مکانهای متفاوت به وجود آمد.
ایجاد استراتژی صحیح نظارت بر سرور ابری
پیچیدگی اینترنت سبب غیر قابل پیش بینی بودن آن شده است ، بنابراین ، وقوع حوادثی همچون اختلال سرور ابری گوگل اجتناب‌ناپذیر است. اینگونه حوادث به ما نشان می‌دهند که کدام بخش از کارهایی که تا به حال انجام می‌دادیم، نیاز به اصلاح دارد. این وقایع فرصتی برای ارزیابی مجدد فرایند‌ها و استراتژیهای موجود است تا در صورت وقوع مشکلاتی از این دست ،توان آمادگی لازم برای رویارویی با آنها را داشته باشیم. برخی از درسهایی که می‌توان از این مسئله گرفت، عبارتند از :
１. کورکورانه اعتماد نکنید
مهم نیست که عرضه‌کننده چقدر معروف، توانمند و یا فرایند- محور است، همیشه احتمال بروز خطا و اشتباه وجود دارد. اگر لازم است که سرویسهای دیجیتال شما کاملاْ( به صورت ۱۰۰٪) قابل دسترسی و قابل اعتماد باشند ، پس ساختار و استراتژی شما نیز باید در جهت رسیدن به این هدف باشد. زمانی که را برنامه‌ریزی لازم را در این زمینه کرده باشید و ساختار سازمان شما برای دستیابی به چنین سطحی از اعتماد طراحی شده باشد، سلامت اپلیکیشن شما وابسته به این خواهد بود که عملکرد و فرایندهای موجود در سازمان برای مدیریت بحرانهای مهم تا چه حد از این استراتژی تبعیت می‌کنند.
２. تنها به یک شرکت (عرضه‌کننده ) متکی نباشید.
اگر تمام سرویسها ، ابزار نظارتی / مشارکتی و پشتیبانی خود را تنها از یک شرکت عرضه‌کننده تأمین کنید و یا تنها از طریق یک ISP به سیستم متصل شوید ، زمینه را برای بروز یک فاجعه آماده کرده‌اید. به عنوان مثال، اگر اپلیکیشن شما بر روی یک سرور ابری یا سرور مجازی خاص قرار داشته باشد و ابزار نظارتی شما نیز بر روی همان سرور اجرا شود ، در صورت بروز مشکل نمی‌توانید هشدار لازم را دریافت کنید و یا مشکل ایجاد‌شده را برطرف کنید. ممکن است تیم شما پس از مواجهه با چند بار اشکال و ایراد ، دچار ترس از بروز وقفه‌های متناوب (FOMO) شوند. با تضمین این مسئله که سرویسهای اصلی، ابزارهای نظارتی و ارتباطی بر روی پلتفرمهای مختلف قرار گرفته‌اند و هیچ نقطهٔ ایراد مشترکی وجود ندارد ، اپلیکیشن خود را مقاوم و انعطاف‌پذیر کنید.
３. بر روی ابزارهای نظارتی سرمایه‌گذاری کنید.
اتکا به صفحات شرکت عرضه‌کننده در توییتر برای تشخیص اختلالات و یا میزان نارضایتی کاربران ، مثل قمار کردن بر روی وجههٔ تجاری خود و کسب رضایت کاربران است. بدون داشتن نظارت اختصاصی و یا نظارت از نوع نظارت از طریق جعبهٔ سیاه، نه می‌توانید عملکرد پایهٔ مناسبی داشته باشید و نه در صورت بروز وقفهٔ ناگهانی ، قادر به مقابله با آن خواهید بود. یک استراتژی نظارتی مناسب به شما اشراف کامل می‌دهد و می‌توانید سلامت شبکه . زیرساختهای IT خود را به خوبی پیگیری کنید.
این استراتژی به شما امکان می‌دهد که مواردی را که خدمات دیجیتال شما به آنها وابسته است، همچون عرضه‌کنندگان DNS ، CDNs ، API شرکا/ نمایندگیها ، عرضه‌کنندگان سرور ابری یا سرور اختصاصی و … را دسته‌بندی و از هم تفکیک کنید. این عملکرد و قابلیت دسترسی به اطلاعات می‌توانند دید مناسبی به شما بدهند که به بهینه‌سازی اپلیکیشن ، اینکه به کدام فروشندگان و نمایندگیها اطمینان کنید ، کمک می‌کند و خطر ایجاد آثار منفی بر رضایت کاربران نهایی را کاهش می‌دهد.
４. کار خود را به دفعات ارزیابی کنید.
بزرگترین دلیل بروز اختلال در سیستم ، اعمال تغییرات اشتباه در پیکربندی سیستم است . در بیش از ۹۰٪ موارد ، وقتی دلیل بروز اختلال را پیگیری می‌کنیم، به دستورات و یا تغییرات در پیکربندی می‌رسیم که یا به خوبی ارزیابی ( آزمایش) نشده‌اند و یا به درستی اعمال نشده‌اند.
بنابراین، ضروری است که در زمان استفاده از یک قانون جدید و یا اعمال تغییرات ، فرایند سخت‌گیرانه‌ای داشته باشید، فرایندی که وجود مراحلی برای اعتبارسنجی این تغییرات در آن لحاظ شده باشد. با استفاده از این فرایند می‌توانید بررسی کنید که آیا این تغییرات، آثار مطلوب و مورد نظر را داشته‌اند و اگر نداشته‌اند ، باید چکار کنید. هرگونه تغییر در پیکربندی را هم در محیطهای QA و هم در محیط تولید محدود با تستهای جدی و قدرتمند بسنجید تا اشتباهات و مشکلات عملکردی را بیابید. توصیه می‌کنیم که این تغییرات را در تعطیلات آخر هفته و یا اواخر شب که اپلیکیشن کمترین ترافیک دادهٔ تأثیرگذار بر کسب و کار را دارد، اعمال کنید ، بدین ترتیب کمترین تأثیر را بر روی میزان رضایت کاربران نهایی خواهد دشت.
５. SLAs را کنترل کنید و از فروشندگان / عرضه‌کنندگان بخواهید که پاسخگو باشند.
زمانی که یک فروشنده تلاش می‌کند تا اختلال ایجاد شده در سرور ابری را به سرعت برطرف کند، در حقیقت سعی می‌کند تا قبل از آنکه SLA دچار اختلال شود، راه‌حلی برای رفع این مشکل پیدا کند. نیازی نیست که در زمان از‌کار‌افتادن سیستم ، فروشندگان را عصبی کنید، آنها به خوبی می‌دانند که این وقفه به چه معنی است. با این حال، ارتباط مستمر و هماهنگی در مورد اتفاقی که رخ داده است و نحوهٔ رفع مشکل به وجودآمده ، عامل اصلی برای ایجاد اعتماد در هر دو طرف است. از عرضه‌کنندهٔ یک سرویس انتظار می‌رود که اختلالات SLA را جبران کند.
با این حال، این مسئولیت شماست که اختلال SLA را به فروشندگان اطلاع دهید. اما اگر تمام اطلاعات نظارتی از یک منبع به دست بیایند ، راهی برای سنجش صحت آنها و تشخیص دقیق کارهای جبرانی موردنیاز نخواهید داشت. نظارت از ظریق چند منبع مختلف مانند انواع شبکه و ISP اطلاعات بی‌طرفانه‌ای در اختیار شما قرار می‌دهد. بدین ترتیب شما می‌توانید از فروشنده بخواهید که برای هر لحظه و هر مسیلهٔ جزئی که بر رضایت کاربر نهایی تأثیر می‌گذارد، پاسخگو باشد.
نمایش خودتان را اجرا کنید
تحولات دیجیتال ما را مجبور کرده است که ساختار سنتی اپلیکیشنها که در آن بر عناصر اصلی زنجیرهٔ ارائهٔ محصول کنترل و نظارت انجام می‌شد ، کنار بگذاریم. سناریوهای فعلی اغلب این عناصر حیاتی را به عرضه‌کنندگان سرور ابری و سرور مجازی سپرده‌اند. این تغییر رویکرد به سوی سرور ابری منجر به کاهش نظارت و محدودیت کنترل شده است که کسب رضایت کاربر نهایی را بیشتر در معرض خطر قرار می‌دهد.
بنابراین در محیط سرور ابری، این عرضه‌کنندهٔ سرور ابری است که نمایش خود را اجرا می‌کند. شما تنها می‌توانید کناری بنشینید و امیدوار باشید که عرضه‌کننده از SLA پشتیبانی و مراقبت کند. اما آیا این بهترین روش برای مدیریت عملکرد اپلیکیشن شما است؟ قطعاْ اینطور نیست. خطرات موجود در این رویرد را نمی‌توان نادیده گرفت( این رویکرد بر تمام جوانب از میزان درآمد، کارایی و بهره‌وری شما گرفته تا وجههٔ تجاری شما تأثیر می گذارد.)
بطور متوسط تیمهای IT هر ماه ۴۶ ساعت وقت صرف ادارهٔ اختلالات و مشکلات مربوط به عملکرد می‌کنند. این امر به دلیل وجود استراتژیهای ناکارامد و نامناسب است که سبب طولانی شدن متوسط زمان لازم برای تشخیص مشکل/ تأیید سلامت سیستم (MTTD/I)و به دنبال آن سبب تأخیر در متوسط زمان لازم برای تعمیر و رفع مشکل (MTTR)می‌شوند. در زمان بروز بحران تیمهای مختلفی در سازمان از جمله تیمهای SRE ، Ops و IT ناچار به بررسی مشکل می‌شوند و قادر به حفظ MTTR در حد قابل قبول نیستند.
نتیجه
ساختار صحیح خدمات و استراتژیهای نظارتی مناسب به شما امکان می‌دهد که نمایش خودتان را اجرا کنید ، کنترل را به دست بگیرید و مجدداْ بر سیستم اشراف داشته‌باشید. به کار گیری استراتژیهای نظارتی صحیح سبب می‌شود که اپلیکیشن شما دچار نقص در عملکرد نشود. این امر به تیمهای IT و افرادی که در اداره و رفع مشکلات عملکردی نقش دارند، کمک می‌کند و هر زمان که با بحرانی از این دست مواجه می‌شوند، به آنها اعتماد به نفس می‌دهد.
