اگر یک نکته مشترک در هر شرکت فناوری وجود داشته باشد، این است: کاربران. خواه موتور جستجوی گوگل باشید و ماهانه به یک میلیارد کاربر فعال که با سرویس شما به طور رایگان ارتباط برقرار می‌کنند خدمت کنید یا Salesforce (یک شرکت رایانش ابری که نرم‌افزار CRM توسعه داده است) با 3.75 میلیون کاربر. در واقع ساخت یک محصول فناوری، به معنای خدمت به مردم است.

گامادسک

در دنیای همیشه روشن امروز، انتظارات مردم از خدمات رایگان و پولی بالاست. سرعت، UX مفید، UI زیبا، پایگاه‌داده و… از جمله مواردی هستند که کاربران انتظار دارند همه‌ی این موارد، از استاندارد بالایی برخوردار باشند.

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

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

SLA: توافق‌نامه‌های سطح خدمات

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

چالش SLAها

اندازه‌گیری، گزارش دادن و دیدن SLA‌ها بسیار دشوار است. این توافق نامه‌ها که عموماً توسط افرادی نوشته می‌شوند که خود در بخش‌های فنی نیستند، غالباً قول‌هایی می‌دهند که اندازه‌گیری آنها برای تیم‌ها دشوار است.

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

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

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

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

مقاله مرتبط را بخوانید: SLA چیست؟

SLO: اهداف سطح خدمات

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

چالش‌های SLOها

SLOها نسبت به SLA ساده‌تر هستند. اما اگر مبهم یا بیش از حد پیچیده یا اندازه‌گیری آنها غیرممکن باشد، می‌توانند به همان اندازه مشکلات ایجاد کنند. نکته کلیدی در SLOها سادگی و شفافیت است. فقط مهمترین معیاری که باید در نظر گرفته شود، اهداف باید به زبان ساده بیان شوند و مانند SLAها، همیشه باید مواردی مانند تأخیر در سمت مشتری را در نظر بگیرید.

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

در مواردی که SLAها فقط در صورت پرداخت به مشتریان مرتبط هستند، SLOها می‌توانند برای هر دو حساب پرداخت شده و پرداخت نشده و همچنین برای مشتریان داخلی و خارجی مفید باشند.

سیستم‌های داخلی مانند CRMها، پایگاه داده‌های مشتری و اینترانت، می‌توانند به اندازه سیستم‌های رو به خارجی مهم باشند. داشتن SLO برای آن سیستم‌های داخلی، ویژگی مهمی است که نه تنها اهداف کسب و کار را برآورده می‌کند بلکه تیم‌های داخلی را قادر می‌سازد تا اهداف مشتری مدار خود را برآورده کنند.

SLI: شاخص سطح خدمات

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

چالش‌های SLI

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

  • یک طرح دقیق برای بهبودی در برابر خطرات ایجاد کنید

هنگام شروع خرابی چه خواهید کرد؟ اگر پاسخ این سئوالات را از قبل نمی‌دانید، پاسخ پیش فرض “اتلاف وقت ارزشمند برای فهمیدن اینکه چه کاری انجام دهید” خواهد بود. هرچه برنامه پاسخگویی به حوادث شما بهتر باشد، تیم‌های شما سریعتر و به طور موثرتری حوادث را کنترل می‌کنند. به همین دلیل اولین قدم در هر برنامه جدید مدیریت حوادث باید فرآیند و برنامه‌ریزی باشد.

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

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

نکات مهم SLA ،SLO و SLI

  • هر قسمت از قرارداد مشتری شما باید پیرامون آنچه برای مشتری مهم است تنظیم شود. در قسمت انتهایی، ممکن است یک حادثه شامل پرداختن به 10 مورد مختلف باشد. اما از نظر مشتری مهم این است که سیستم مطابق انتظار عمل کند.
  • SLAها و SLOهای شما باید این واقعیت را منعکس کنند. با دادن قول‌های فردی برای هر یک از این 10 مورد مختلف، کارها را بیش از حد پیچیده نکنید. وعده‌های خود را محدود به عملکرد سطح بالا و پیش روی کاربر قرار دهید. با این کار مشتریان شادتر می‌شوند و زندگی متخصصان فناوری اطلاعات را که مسئول انجام وعده‌های SLA شما هستند، ساده می‌کند.
یادتان باشد به این دلیل که تیم شما احتمالاً می‌تواند 99.99٪ uptime را حفظ کند، به این معنی نیست که 99.99٪ باید میزان SLO شما باشد.
  • در SLAها از زبان ساده استفاده کنید. مشتریان همیشه درخواست توضیح نمی‌کنند. بنابراین اگر زبان SLA شما پیچیده است، احتمالاً خود را برای برخی سوءتفاهمات دردناک آماده می‌کنید. هر چه زبان شما ساده‌تر باشد، احتمال درگیری مشتری در آینده با شما کمتر است.
  • هر معیار برای موفقیت مشتری حیاتی نیست. به این معنی که هر معیار نباید SLO باشد. تا حد ممکن به SLOها متعهد باشید و بر مواردی که بیشترین اهمیت را برای مشتریان دارند تمرکز کنید.
  • هر معیار قابل پیگیری نباید یک SLI باشد. به همین ترتیب، ردیابی عملکرد بر روی آن 10 مورد مختلف برای هر SLO می‌تواند خیلی سریع پیچیده شود. در عوض، از نظر استراتژیک انتخاب کنید که کدام معیارها برای SLOهای اصلی شما مهم هستند و انرژی خود را برای ردیابی آنها بگذارید.
  • فاکتورهایی که شامل از کنترل خارج شدن تیم IT می‌شود. چه اتفاقی می‌افتد هنگامی که مشتری سرعت شما را کاهش می‌دهد؟ اگر در SLA خود در این مورد صریح نیستید، ممکن است تیم شما بدون نظر خواهی از مشتری، اقدامات لازم را انجام دهد.
  • بودجه خطا را در نظر بگیرید. جا برای شکست‌ها نه تنها کسب و کار شما را از نقض SLA و عواقب سنگین محافظت می‌کند، بلکه چابکی را نیز برای تیم می‌گذارد. تیم سریع می‌تواند تغییرات را ایجاد کند و فضا را برای آزمودن راه‌حل‌های ابتکاری جدید که ممکن است شکست بخورد، داشته باشد.

این چگونه بر SRE تأثیر می‌گذارد؟

برای کسانی که مدل Google را دنبال می‌کنند و به دنبال پر کردن شکاف بین توسعه و عملیات هستند، SLAها، SLOها و SLI موفقیت اساسی هستند. SLAها به تیم‌ها کمک می‌کنند تا بودجه‌ها و بودجه‌هایی که برای خطا و آزمون کنار گذاشته می‌شوند را تعیین کنند. SLOها به اولویت‌بندی کار کمک می‌کنند و SLIها به SREها می‌گویند که برای صرفه‌جویی در بودجه‌های خطا، چه کارهایی را باید انجام دهند.

مطالب بیشتر