نشانگر و پنجره راهنما

مهندس قابلیت اطمینان سایت

آیا شما مسئول خدمات مشتری هستید؟اگر هستید ، می دانید که وقتی این سرویس در دسترس نیست ، می تواند بر درآمد شما تأثیر بگذارد. قطع طولانی می تواند مشتریان شما را به سمت رقبا سوق دهد. چگونه می دانید مشتریان شما به طور کلی از خدمات شما راضی هستند؟اگر اصول مهندسی قابلیت اطمینان سایت (SRE) را دنبال می کنید ، می توانید تجربه مشتری را با اهداف سطح خدمات (SLO) اندازه گیری کنید. SLOS به شما امکان می دهد تا به طور کمی خوشبختی مشتری را اندازه گیری کنید ، که مستقیماً بر تجارت تأثیر می گذارد.

به جای ایجاد تعداد بالقوه بی حد و حصر معیارهای نظارت ، پیشنهاد می کنیم از تعداد کمی هشدارهای مبتنی بر درد مشتری استفاده کنید - یعنی نقض SLO. این امر به شما امکان می دهد هشدارها را روی سناریوهایی متمرکز کنید که با اطمینان می توانید ادعا کنید که مشتریان درد قابل توجهی را تجربه می کنند یا به زودی تجربه خواهند کرد.

در اینجا ما یک رویکرد دستی را برای ارائه SLOS برای یک سرویس و ایجاد داشبورد و هشدارهای واقعی طی خواهیم کرد.

تنظیم SLO برای یک سرویس مثال

ما می خواهیم SLOS را برای یک برنامه تجارت الکترونیکی مبتنی بر وب به نام "بوتیک آنلاین" ایجاد کنیم که کالاهای پرنعمت را به فروش می رساند. این برنامه از 10 سرویس دهنده تشکیل شده است ، که به زبان های مختلفی نوشته شده و در خوشه موتور Google Kubeetes (GKE) نصب شده است.

در اینجا معماری ما به نظر می رسد:

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

بررسی اجمالی فرآیند SLO

1. سفرهای مهم کاربر را لیست کنید و آنها را با تأثیر تجاری سفارش دهید.
2. تعیین کنید که از کدام معیارها به عنوان شاخص های سطح خدمات (SLI) استفاده کنید تا تجربه کاربر را با دقت بیشتر ردیابی کنید.
3. اهداف هدف SLO و دوره اندازه گیری SLO را تعیین کنید.
4. کنسول های بودجه SLI ، SLO و خطا ایجاد کنید.
5. هشدارهای SLO ایجاد کنید.

مرحله 1: سفرهای مهم کاربر را لیست کنید و با تأثیر تجاری آنها را سفارش دهید

اولین قدم در ایجاد SLO لیست سفرهای مهم کاربر برای این تجارت است. یک سفر مهم کاربر مجموعه ای از تعامل های کاربر را با یک سرویس برای دستیابی به نتیجه نهایی توصیف می کند. بنابراین بیایید به چند مورد از اقدامات مشتریان ما هنگام استفاده از این سرویس استفاده کنیم:

• مرور محصولات
• وارسی
• به سبد خرید اضافه کنید

در مرحله بعد ، بیایید این موارد را با تأثیر تجاری سفارش دهیم. در این حالت ، به عنوان یک فروشگاه تجارت الکترونیکی ، مهم است که مشتریان بتوانند خریدهای خود را انجام دهند. به سفرهای کاربر نگاه کنید که مستقیماً بر توانایی آنها در این کار تأثیر می گذارد.

بنابراین لیست اولویت بندی شده به این شکل است:

1. وارسی
2. به سبد خرید اضافه کنید
3. مرور محصولات

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

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

مرحله 2: تعیین کنید که از کدام معیارها به عنوان SLIS استفاده کنید تا تجربه کاربر را با دقت بیشتر ردیابی کنید

مرحله بعدی این است که بفهمیم از کدام معیارها به عنوان SLIS استفاده می شود که با دقت بیشتر تجربه کاربر را ردیابی می کند. SLI ها اندازه گیری های قابل اندازه گیری هستند که نشان می دهد آیا این سرویس کار می کند یا خیر. ما می توانیم طیف گسترده ای از شاخص ها را انتخاب کنیم ، مانند در دسترس بودن (یعنی ، چند درخواست موفق می شوند) ، تأخیر (یعنی چه مدت درخواست طول می کشد) ، توان ، درستی ، طراوت داده ها و غیره.

معادله SLI می تواند به کمیت SLI مناسب برای تجارت کمک کند:

معادله SLI تعداد رویدادهای خوب است که بر اساس تعداد کل رویدادهای معتبر تقسیم می شود ، که 100 برابر می شود تا درصد یکنواخت آن را حفظ کند.

بیایید به SLI هایی که می خواهیم برای سفر کاربر مهم "پرداخت" اندازه گیری کنیم ، نگاهی بیندازیم. سفری را که مشتریان خود برای خرید محصولی از فروشگاه انجام می دهند ، تصویر کنید. اول ، آنها وقت خود را صرف مرور ، تحقیق در مورد موارد ، اضافه کردن کالا به سبد خرید می کنند (شاید اجازه دهید در آنجا بنشیند تا بتوانند در مورد آن بیشتر فکر کنند) ، سپس ، در نهایت ، وقتی آماده شدند ، تصمیم می گیرند که بررسی کنند. اگر این کار را با مشتری خود دور کنید ، می توانید فرض کنید که موفق به کسب مشاغل خود شده اید ، بنابراین کاملاً بسیار مهم است که مشتریان بتوانند از این کار دیدن کنند.

در اینجا SLI ها برای این سفر کاربر در نظر گرفته شده است.

در دسترس بودن SLI

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

نسبت درخواست HTTP GET برای /checkout_service /پاسخ_ counts که دارای وضعیت 5xx (3xx و 4xx حذف) در مش سرویس ISTIO هستند.

چرا کدهای وضعیت 3xx و 4xx حذف شده اند؟ما نمی خواهیم رویدادهایی را که نشانگر عدم موفقیت در خدمات ما نیست ، حساب کنیم زیرا آنها سیگنال های SLI ما را از بین می برند ، بنابراین ما خطاهای 3xx و خطاهای مشتری 4xx را از ارزش "کل" ما حذف می کنیم.

SLI SLI

همچنین می خواهید اطمینان حاصل کنید که وقتی مشتری چک می کند ، تأیید سفارش در یک پنجره قابل قبول بازگردانده می شود. برای این کار ، یک SLI تأخیر تنظیم کنید که اندازه گیری پاسخ موفقیت آمیز چقدر طول می کشد. در اینجا ما با فرض اینکه این یک آستانه قابل قبول برای تجارت است ، ارزش 500ms را برای پاسخ به آنها تعیین خواهیم کرد. بنابراین تأخیر SLI به این شکل خواهد بود:

نسبت درخواست HTTP GET برای /checkout_service /پاسخ_ counts که دارای وضعیت 5xx نیستند (3xx و 4xx مستثنی) هستند که کل پاسخ خود را در 500 میلی ثانیه اندازه گیری شده در مش سرویس ISTIO ارسال می کنند.

مرحله 3: تعیین اهداف هدف SLO و دوره اندازه گیری SLO

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

به عنوان مثال ، اگر 10،000 درخواست HTTP در یک ماه تقویم وجود داشته باشد و فقط 9،990 نفر از این افراد پاسخ موفقیت آمیز را طبق SLI باز می گردانند ، که برای آن ماه به 9990/10،000 یا 99. 9 ٪ در دسترس بودن ترجمه می شود.

تعیین یک هدف قابل دستیابی به گونه ای مهم است که هشدارها معنی دار باشند. به طور معمول ، هنگام انتخاب SLO ، بهتر است از روندهای تاریخی شروع کنید و فرض کنید اگر افراد کافی از این سرویس راضی باشند ، احتمالاً خوب عمل می کنید. سرانجام ، ایده آل است که آن شماره ها را با اهداف مشتاق که ممکن است تجارت شما بخواهد با آنها ملاقات کنید ، همگرا شوید.

با توجه به روند داده های تاریخی ، می توان گفت که SLO ما 99. 9 ٪ خواهد بود. در مرحله بعد ، وقت آن است که این کلمات را در داشبورد و هشدارهای ملموس واقعی قرار دهیم.

مرحله 4: کنسول های بودجه SLI ، SLO و خطا ایجاد کنید

به عنوان مهندسین ، ما باید در هر زمان بتوانیم وضعیت خدمات را ببینیم ، این بدان معنی است که ما باید داشبورد نظارتی ایجاد کنیم. برای نظارت بر مشتری ، ما می خواهیم نمودارهایی را برای SLI ها ، SLO ها و بودجه خطا ببینیم.

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

• نام متریک: /checkout_service /پاسخ_ counts
• فیلتر:
  • فیلتر خوب: http_response_code = 200
  • فیلتر کل: http_response_code = 500 یا http_response_code = 200

  با چربی آرنج زیادی می توانید تعاریف مناسب مورد نیاز برای ایجاد نمودارهای SLI و SLO را محاسبه کنید. اما این فرایند می تواند بسیار خسته کننده باشد ، به خصوص هنگامی که شما چندین سرویس و SLO برای ایجاد دارید. خوشبختانه ، مؤلفه نظارت بر سرویس عملیات ابری می تواند به طور خودکار این نمودارها را تولید کند. از آنجا که ما در این مثال از ادغام مش Istio استفاده می کنیم ، مشاهده در سیستم حتی در دسترس تر است. در اینجا نحوه تنظیم داشبورد با نظارت خدمات آورده شده است:

  

  1. برو به

  3. ایجاد SLO را انتخاب کنید

  

  4- در دسترس بودن و واحد متریک مبتنی بر درخواست را انتخاب کنید.

  

  اکنون می توانید SLI ها و همچنین جزئیات مربوط به معیارهایی را که ما استفاده می کنیم مشاهده کنید.

  

  5- دوره انطباق را انتخاب کنید. در اینجا ما از یک پنجره نورد و هدف 30 روز استفاده خواهیم کرد. Windows Rolling با تجربه کاربر نزدیک تر است ، اما اگر می خواهید نظارت شما با اهداف تجاری و برنامه ریزی خود مطابقت داشته باشد ، می توانید از ویندوزهای تقویم استفاده کنید.

  6. هدف SLO قبلاً تنظیم شده 99. 9 ٪ را انتخاب کنید. نظارت بر خدمات همچنین در صورت داشتن داده های موجود ، دستاوردهای SLO تاریخی شما را نشان می دهد.

  

  خودشه! داشبورد نظارت شما آماده است.

  

  پس از اتمام کار ، ما با نمودارهای خوب برای SLI ها ، SLO ها و بودجه خطا به پایان می رسیم.

  

  سپس می توانید با استفاده از همان گردش کار ، فرآیند برای تأخیر Checkout Latency SLI را تکرار کنید.

  مرحله 5: هشدارهای SLO ایجاد کنید

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

  نظارت بر خدمات به شما امکان می دهد برای این وضعیت دقیق سیاست های هشدار دهنده ای را تعیین کنید.

  

  1. برو به

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

  4- وضعیت هشدار را ذخیره کنید.

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

  یک نکته نهایی: در حالی که ما از UI مانیتورینگ سرویس برای کمک به ما در ایجاد SLI و SLO استفاده کردیم ، در پایان روز ، SLI ها و SLO ها هنوز پیکربندی هستند. به عنوان مهندسین ، ما می خواهیم اطمینان حاصل کنیم که تنظیمات ما برای بهبود قابلیت اطمینان ، مقیاس پذیری و حفظ قابلیت کنترل منبع کنترل شده است. برای کسب اطلاعات بیشتر در مورد نحوه استفاده از پرونده های پیکربندی با نظارت بر سرویس ، قسمت دوم این سری را در تنظیم SLOS: مشاهده با معیارهای سفارشی بررسی کنید.

  ابزارهای مدیریتی

  تنظیم SLO: مشاهده با استفاده از معیارهای سفارشی

  ببینید که چگونه می توانید اهداف سطح خدمات (SLO) را برای خدمات پیچیده برای نظارت بهتر ابر تنظیم کنید. بخشی از سری نکات SRE.

  توسط Cindy Quach • 5 دقیقه خواندن

  

  • ابزارهای مدیریتی
  • ابر گوگل
  • عملیات ابری