اگر یک نقطه اشتراک بین همه شرکت های فناوری وجود داشته باشد، این است: کاربران.

این که آیا شما موتور جستجوی گوگل هستید، با سرویس به یک میلیارد کاربر فعال ماهانه که با خدمات شما به صورت رایگان ارتباط برقرار می کنند، یا Salesforce، با ۳.۷۵ میلیون مشترک پولی، ساخت یک محصول فناوری به معنای خدمت به مردم است.

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

به همین دلیل برای شرکت ها مهم است که SLA ها، SLO ها و SLI ها را درک و حفظ کنند. سه نام اولیه که نشان دهنده :

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

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

 توافق نامه های سطح خدمات:  ( Service Level Agreements) 

SLA  چیست؟

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

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

چالشهای  SLAها

معمولا اندازه گیری، گزارش دادن و برآورده کردن SLAها  سخت است. این توافقات – که به طور کلی توسط افرادی که خودشان در حوزه فناوری فعالیت نمی کنند نوشته شده اند – اغلب وعده هایی را می دهند که انجام آن برای تیم ها سخت است. اکثرا با اولویت های کنونی و در حال تکامل کسب و کار همخوانی ندارند و به جزئیات توجه نمی کنند.

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

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

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

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

اهداف سطح سرویس : (Service Level Objectives) 

SLO  چیست؟

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

چالش های SLO ها

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

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

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

سیستم های داخلی مانندCRM ، مرکز  ذخیره سازی داده های مشتری و اینترانت(شبکه داخلی) می توانند به اندازه سیستم های خارجی مهم باشند. داشتن SLO برای این سیستم های داخلی نه تنها بخش مهمی از اهداف تجاری است، بلکه تیم های داخلی را قادر می سازد تا اهداف مشتری خود را برآورده کنند.

شاخص سطح خدمات : (Service Level Indicator)

SLI  چیست؟

SLI  انطباق با SLO  را اندازه گیری می کند. بنابراین، به عنوان مثال، اگر SLA شما مشخص کند که سیستم های شما در ۹۹.۹۵٪ از زمان در دسترس خواهد بود، SLO  شما احتمالا ۹۹.۹۵٪ زمان آماده به کار است و SLI شما اندازه گیری واقعی زمان آماده به کار شما است. شاید ۹۹.۹۶ درصد باشد و شاید ۹۹.۹۹ درصد. برای رعایت SLA خود، SLI باید وعده های داده شده در آن سند را برآورده کند یا از آن فراتر رود.

چالش های  SLIها

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

ایجاد یک طرح دقیق برای مواجه با بحران

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

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

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

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

SLA:  وعده هایی به مشتریان

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

خلاقیت SLAها  حول انتظارات مشتری

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

SLAها و SLOهای شما باید این واقعیت را منعکس کنند. با پیچیده کردن موارد و پیگیری معیارهای زیادی برای هر یک از این ۱۰ مؤلفه، کار را پیچیده نکنید. وعده های خود را به عملکرد بالا و کاربر محور محدود کنید. این کار مشتری ها را خوشحال تر و کمتر گیج می کند و زندگی متخصصین IT  را که مسئول  تحقق وعده های SLA شما هستند، ساده تر می کند.

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

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

با SLOها کمتر، بیشتر است

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

همه معیارهای قابل ردگیری نباید به عنوان SLI در نظر گرفته شوند. به طور مشابه، ردگیری عملکرد ۱۰ مولفه برای هر یک از ۱۰ SLO می‌تواند بسیار پیچیده شود. به جای آن، با استراتژی انتخاب کنید که کدام معیارها در واقع برای SLOهای اصلی شما مهم هستند و انرژی خود را برای ردگیری آن‌ها به طور موثر صرف کنید.

عوامل خارج از کنترل تیم IT

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

یک بودجه خطا ایجاد کنید

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

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

بلند پروازی نکنید

فقط به این دلیل که تیم شما احتمالا می تواند ۹۹.۹۹٪ زمان پایداری را حفظ کند، به این معنی نیست که ۹۹.۹۹٪ باید شماره SLO شما باشد. همیشه بهتر است کمتر وعده داده و بیش از انتظار ارائه شود. این امر به ویژه برای تیم های چابک که می خواهند اغلب مواقع سریع راه اندازی شوند و نیاز به بودجه خطا برای حفظ این سرعت دارند، درست است.

این موضوع چه تاثیری بر SREها دارد؟

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

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