همه شرکت های فناوری دارای یک چیز مشترک هستند:‌مشتری!

و در دنیای Always-On امروزی، انتظارات مشتری - برای خدمات رایگان و پولی - بالاست. سرعت. آپتایم. UX مفید. مشتری امروزی انتظار دارد همه چیز از استاندارد بالایی برخوردار باشد.

به همین دلیل است که برای شرکت‌ها مهم است که SLA، SLO و SLI را درک کرده و حفظ کنند. سه عبارت اولیه که بیانگر وعده‌هایی است که به کاربرانمان می‌دهیم، اهداف داخلی که به ما کمک می‌کنند به این وعده‌ها عمل کنیم، و اندازه‌گیری‌های قابل ردیابی که به ما می‌گویند چگونه هستیم یا در چه وضعیتی قرار داریم!

هدف هر سه مورد این است که فروشنده و مشتری در مورد عملکرد سیستم دارای نظر یکسانی باشند. سیستم های شما چقدر در دسترس خواهند بود؟ اگر سیستم از کار بیفتد، تیم شما چقدر سریع پاسخ خواهد داد؟ چه وعده هایی در مورد سرعت و عملکرد می دهید؟ کاربران می‌خواهند این موارد را بدانند و بنابراین شما به SLA، SLO و SLI نیاز دارید.

توافق نامه سطح خدمات SLA - Service Level Agreements

‏SLA (توافق نامه سطح خدمات) توافقی است بین سرویس دهنده و مشتری در مورد معیارهای قابل اندازه گیری مانند آپتایم، پاسخگویی و مسئولیت ها.

این توافق‌نامه‌ها معمولاً توسط تیم‌های حقوقی و تجاری یک شرکت تنظیم می‌شوند و نشان‌دهنده وعده‌هایی هستند که به مشتریان می‌دهید و عواقب آن در صورت عدم تحقق آن وعده‌ها.

به طور معمول، عواقب آن شامل جریمه های مالی، اعتبار خدمات یا تمدید مجوز می شود.

چالش SLA ها

اندازه گیری، گزارش دهی و رسیدن به SLA ها بسیار دشوار است. این توافق‌ها - عموماً توسط افرادی نوشته می‌شوند که خودشان در زمینه‌های فناوری نیستند و اغلب وعده‌هایی را می‌دهند که اندازه‌گیری آن برای تیم‌ها دشوار است، همیشه با اولویت‌های تجاری فعلی و در حال تغییر همسو نیستند و تفاوت‌های ظریف را در نظر نمی‌گیرند. به عنوان مثال، یک SLA ممکن است قول دهد که تیم ها مشکلات گزارش شده در محصول X را ظرف 24 ساعت حل خواهند کرد. اما همان SLA توضیح نمی دهد که اگر مشتری 24 ساعت طول بکشد تا پاسخ ها یا اسکرین شات ها را برای کمک به تیم شما در تشخیص مشکل ارسال کند، چه اتفاقی می افتد. آیا این بدان معناست که فرصت 24 ساعته تیم به دلیل تاخیر پاسخ مشتری از بین رفته است یا اینکه ساعت بر اساس زمانی که مشتریان پاسخ می دهند شروع و متوقف می شود؟ SLA ها باید به این سؤالات پاسخ دهند، اما اغلب در انجام این کار شکست می خورند.

برای بسیاری از کارشناسان، پاسخ به این چالش، قبل از هر چیز این است که بخش فناوری باید در ایجاد SLA ها دخالت داشته باشد. هرچه IT و DevOps بیشتر با تیم توسعه حقوقی و تجاری برای SLAهایی که سناریوهای دنیای واقعی را بررسی می کنند همکاری کنند، SLA ها بیشتر شروع به انعکاس واقعیت های کلیدی می کنند، مانند همین که مشتریان حل مشکل خود را به تاخیر می اندازند!

چه کسی به SLA نیاز دارد؟

‏SLA توافقی بین فروشنده و مشتری است. شرکت هایی که خدماتی را به صورت رایگان به کاربران ارائه می کنند، بعید است که برای آن کاربران رایگان SLA بخواهند یا نیاز داشته باشند.

اهداف سطح خدمات یا SLO - Service Level Objectives

یک SLO (هدف سطح خدمات) توافقی است در یک SLA در مورد یک معیار خاص مانند زمان کار یا زمان پاسخ. بنابراین، اگر SLA قرارداد رسمی بین شما و مشتری باشد، SLOها وعده هایی هستند که به آن مشتری می دهید. SLO ها چیزی هستند که انتظارات مشتری را تعیین می کنند و به تیم های IT و DevOps می گویند که باید به چه اهدافی دست یابند و خود را بر اساس آن ارزیابی کنند.

چالش های SLO ها

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

اهداف باید واضح باشند و به زبان ساده بیان شوند

چه کسی به SLOها نیاز دارد؟

در جایی که SLA ها فقط در مورد مشتریان پولی هستند، SLO ها می توانند هم برای حساب های پولی و بدون پرداخت و هم برای مشتریان داخلی و خارجی مفید باشند.
سیستم های داخلی مانند CRM ها، Data Repository های مشتری و اینترانت می توانند به اندازه سیستم های خارجی مهم باشند. و داشتن SLO برای آن سیستم‌های داخلی بخش مهمی است که نه تنها به اهداف تجاری دست می‌یابد، بلکه تیم‌های داخلی را قادر می‌سازد تا به اهداف مشتریان خود برسند.

شاخص سطح خدمات SLI - Service Level Indicator

یک SLI (شاخص سطح خدمات) انطباق با SLO (هدف سطح خدمات) را اندازه گیری می کند. بنابراین، برای مثال، اگر SLA شما مشخص می‌کند که سیستم‌های شما در 99.95% مواقع در دسترس خواهند بود، SLO شما احتمالاً 99.95% uptime است و SLI شما اندازه‌گیری واقعی uptime شما است. شاید 99.96٪ باشد. شاید 99.99 درصد. برای اینکه SLA شما مطابقت داشته باشد، SLI باید به وعده های داده شده در آن سند عمل کند یا از آن فراتر رود.

چالش SLI ها

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

یک طرح دقیق برای ترمیم فاجعه ایجاد کنید

در صورت بروز downtime چه خواهید کرد؟ اگر از قبل پاسخ آن سوال را نمی‌دانید، پاسخ پیش‌فرض «هدر دادن وقت گرانبها در زمان بحران برای فهمیدن اینکه چه کاری انجام دهید» خواهد بود.

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

چه کسی به SLI نیاز دارد؟

هر شرکتی که عملکرد خود را با SLO ها اندازه گیری می کند، برای انجام این اندازه گیری ها به SLI نیاز دارد. شما واقعا نمی توانید SLO بدون SLI داشته باشید.

بهترین پیشنهادهای SLA، SLO و SLI

‏SLA ها را حول انتظارات مشتری بسازید.

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

‏SLAها و SLOهای شما باید این واقعیت را منعکس کنند. با ریز شدن در موارد و دادن وعده های جداگانه برای هر یک از آن 10 جزء، کار را بیش از حد پیچیده نکنید. وعده های خود را محدود به عملکرد high-level سیستم نگه دارید. این کار مشتریان را راضی‌ترنگه می‌دارد و کمتر سردرگم می شوند و زندگی متخصصان فناوری اطلاعات را که مسئول اجرای وعده‌های SLA شما هستند، ساده‌تر می‌کند.

از زبان ساده در SLA ها استفاده کنید

مشتریان همیشه توضیح نمی خواهند، بنابراین اگر زبان SLA شما پیچیده است، احتمالاً خود را برای برخی سوء تفاهمات دردناک آماده می کنید. هرچه زبان شما ساده تر باشد، احتمال تضاد مشتری در آینده شما کمتر خواهد بود.

با SLO ها، کمتر، بیشتر است (Less is More)

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

هر معیار قابل پیگیری نباید SLI باشد

به طور مشابه، ردیابی عملکرد در 10 مؤلفه برای هر یک از 10 SLO می تواند خیلی سریع سخت شود. در عوض، به طور استراتژیک انتخاب کنید که کدام معیارها واقعاً برای SLOهای اصلی شما مهم هستند و انرژی خود را برای ردیابی مؤثر آنها صرف کنید.

عوامل خارج از کنترل تیم IT را اضافه کنید.

چه اتفاقی می‌افتد وقتی مشتری همان کسی است که زمان را برای حل کردن مشکل کاهش می‌دهد؟ اگر در SLA خود در این مورد واضح نیستید، تیم شما ممکن است با استاندارد غیرممکن حل و فصل مسائل مشتری بدون دخالت مشتری درگیر شوند.

تولید در بودجه خطا

جا گذاشتن(فرصت) برای شکست‌ها نه تنها از کسب‌وکار در برابر نقض SLA و عواقب سنگین محافظت می‌کند، بلکه فضایی را برای چابکی ایجاد می‌کند - برای تیم که سریعاً تغییرات را انجام دهد و فضای لازم برای امتحان راه‌حل‌های جدید نوآورانه را داشته باشد که ممکن است شکست بخورند.

از ظرفیت میزان خطای قابل قبول (بودجه خطا) به عنوان یک فرصت استفاده کنید.

گوگل در واقع استفاده از بودجه خطای باقیمانده را برای downtime برنامه ریزی شده توصیه می کند، که می تواند به شما کمک کند مسائل پیش بینی نشده را شناسایی کنید (مانند سرویس هایی که به طور نامناسب از سرورها استفاده می کنند) و انتظارات مناسب از مشتریان خود را حفظ کنید.

به ماه شلیک نکنید

فقط به این دلیل که تیم شما احتمالاً می‌تواند 99.99٪ آپتایم را حفظ کند، به این معنی نیست که 99.99٪ باید عدد SLO شما باشد. همیشه بهتر است کم وعده کنید و بیشتر تحویل دهید.

برای کسانی که از مدل Google پیروی می‌کنند و از تیم‌های Site Reliability Engineering (SRE) برای پر کردن شکاف بین توسعه و عملیات استفاده می‌کنند، SLAs، SLOs و SLI‌ها برای موفقیت اساسی هستند.SLA به تیم ها کمک می کند تا مرزها و بودجه های خطا را تعیین کنند. SLO ها به اولویت بندی کار کمک می کنند. و SLI ها به SRE ها می گویند که چه زمانی باید همه راه اندازی ها را متوقف کنند تا در بودجه خطای در معرض خطر صرفه جویی کنند – و چه زمانی می توانند سر کیسه را شُل کنند :)

جمع بندی

اگر از این مطلب استفاده کردید با یک کامنت منو خوشحال کنید.