Si hay algo que tienen en común todas las empresas tecnológicas, son los usuarios.
Ya seas el motor de búsqueda de Google, atiendas a mil millones de usuarios activos mensuales que interactúan con tu servicio de forma gratuita o seas Salesforce, con 3,75 millones de suscriptores de pago, el diseño de un producto tecnológico implica ponerte al servicio de las personas.
Además, en el mundo actual, siempre conectado, las expectativas de la gente son muy altas, tanto con los servicios gratuitos como con los de pago. Rapidez. Tiempo de actividad. Experiencia de usuario útil. La base de usuarios de hoy en día espera que todo alcance unos elevados estándares.
Looker confía en Opsgenie para ayudar a prestar su servicio a 200000usuarios a diario.
Por ello, es importante que las empresas entiendan y mantengan unos SLA, SLO y SLI, tres siglas que representan las promesas que hacemos a nuestros usuarios, los objetivos internos que nos ayudan a cumplir esas promesas y las mediciones trazables que nos indican cómo nos va.
El objetivo de estos tres elementos es conseguir que todos, tanto el proveedor como el cliente, estén en sintonía con respecto al rendimiento del sistema. ¿Con qué frecuencia estarán disponibles los sistemas? ¿Con qué rapidez responderá el equipo si el sistema se cae? ¿Qué tipo de promesas se hacen sobre la velocidad y la funcionalidad? Los usuarios quieren saberlo todo; por eso son necesarios los SLA, los SLO y los SLI.
SLA: acuerdos de nivel de servicio
¿Qué es un SLA?
Un SLA (acuerdo de nivel de servicio) es un acuerdo entre el proveedor y el cliente sobre los parámetros cuantificables, como el tiempo de actividad, la capacidad de respuesta y las responsabilidades.
Estos acuerdos suelen redactarlos los equipos jurídicos y de nuevos negocios de la empresa, y representan las promesas que se hacen a los clientes y las consecuencias de no cumplirlas. Por lo general, entre las consecuencias se incluyen sanciones económicas, créditos de servicio o ampliaciones de las licencias.
El reto de los SLA
Los SLA son notablemente difíciles de cuantificar y cumplir, y resulta muy complicado informar sobre ellos. En estos acuerdos, que generalmente redactan personas que no conocen a fondo los entresijos de la tecnología, se suelen hacer promesas que a los equipos les es difícil cuantificar, no se tienen en cuenta los matices y no siempre se está en línea con las prioridades actuales y en constante evolución de la empresa.
Por ejemplo, en un SLA se puede prometer que los equipos resolverán las incidencias notificadas con el producto X en 24 horas. Sin embargo, en ese mismo SLA no se especifica qué ocurre si el cliente tarda 24 horas en responder o enviar capturas de pantalla para ayudar al equipo a identificar el problema. ¿Significa eso que el plazo de 24 horas del equipo se ha consumido debido a la lentitud del cliente o que el reloj se inicia y se detiene en función del momento en que responde el cliente? En los SLA, se debe dar respuesta a estas preguntas, pero a menudo no es así, algo que ha provocado que los responsables de TI sientan una gran aversión hacia ellos.
Para muchos expertos, la respuesta a este reto es, ante todo, que la tecnología debe tener cabida en la creación de los SLA. Cuanto más colaboren los equipos de TI y DevOps con los equipos jurídicos y de desarrollo empresarial para elaborar SLA que aborden situaciones reales, más empezarán a reflejar los SLA las realidades clave, como los retrasos provocados por los clientes en la resolución de sus propias incidencias.
¿Quién necesita un SLA?
Un SLA es un acuerdo entre un proveedor y un cliente de pago. Es poco probable que las empresas que prestan un servicio gratis a los usuarios quieran o necesiten un SLA para esos usuarios gratuitos.
SLO: objetivos de nivel de servicio
¿Qué es un SLO?
Un SLO (objetivo de nivel de servicio) es un acuerdo enmarcado en un SLA sobre una métrica específica, como el tiempo de actividad o el tiempo de respuesta. Así, si el SLA es el acuerdo formal entre tú y el cliente, los SLO son cada una de las promesas que le haces a ese cliente. Los SLO son los que establecen las expectativas de los clientes e indican a los equipos de TI y DevOps qué objetivos deben alcanzar y cuantificar.
Los retos de los SLO
Los SLO tienen menos detractores que los SLA, pero pueden dar lugar a los mismos problemas si son poco precisos, demasiado complicados o imposibles de cuantificar. La clave para que los SLO no hagan que los ingenieros se tiren de los pelos es la simplicidad y la claridad. Solo las métricas más importantes deberían considerarse SLO, los objetivos deberían exponerse con un lenguaje sencillo y, al igual que con los SLA, siempre deberían dar cuenta de incidencias tales como los retrasos provocados por los clientes.
¿Quién necesita los SLO?
Mientras que los SLA solo son relevantes en el caso de los clientes de pago, los SLO pueden ser útiles para las cuentas tanto de pago como gratuitas, así como para los clientes internos y externos.
Los sistemas internos, como los CRM, los repositorios de datos de los clientes y la intranet, pueden ser igual de importantes que los sistemas orientados a los usuarios externos. Además, disponer de SLO para esos sistemas internos es fundamental no solo para cumplir los objetivos empresariales, sino también para que los equipos internos puedan cumplir sus propios objetivos de cara al cliente.
SLI: indicadores de nivel de servicio
¿Qué es un SLI?
Un SLI (indicador de nivel de servicio) evalúa el cumplimiento de un SLO (objetivo de nivel de servicio). Por ejemplo, si en tu SLA se especifica que tus sistemas estarán disponibles el 99,95 % del tiempo, el SLO es probablemente el 99,95 % de tiempo de actividad y el SLI es la medida real del tiempo de actividad. Tal vez sea el 99,96 % o quizás el 99,99 %. Para mantener el cumplimiento de tu SLA, el SLI tendrá que cumplir o superar las promesas hechas en ese documento.
Los retos de los SLI
Al igual que con los SLO, el reto de los SLI radica en conseguir que sean simples, elegir las métricas adecuadas para el seguimiento y no complicar demasiado el trabajo del departamento de TI al tener que llevar un registro de demasiadas métricas que, en realidad, no importan a los clientes.
Crea un plan detallado de recuperación ante desastres
¿Qué harás en caso de que se produzca tiempo de inactividad? Si aún no tienes respuesta a esa pregunta, lo habitual será que pierdas un valioso tiempo para determinar qué hacer.
Cuanto mejor sea tu plan de respuesta ante incidentes, más rápida y eficaz será la gestión de los incidentes por parte de los equipos. Por eso, el primer paso de cualquier nuevo programa de gestión de incidentes debería ser el proceso y la planificación.
¿Quién necesita los SLI?
Cualquier empresa que mida su rendimiento con respecto a los SLO necesita los SLI para poder realizar esas evaluaciones. Realmente, no se pueden tener SLO sin SLI.
Prácticas recomendadas de los SLA, los SLO y los SLI
Elabora los SLA en torno a las expectativas de los clientes
Cada parte de tu acuerdo con el cliente debería elaborarse en torno a lo que le importa al usuario. En el back-end, un incidente puede significar que se tengan que abordar 10 componentes diferentes. Pero para el cliente, lo único importante es que el sistema funcione según lo previsto.
Tus SLA y SLO deben reflejar esta realidad. No compliques en exceso las cosas entrando en demasiados detalles y haciendo promesas individuales en relación con cada uno de esos 10 componentes. Limita tus promesas a la funcionalidad general orientada al usuario. De este modo, los clientes se sentirán más satisfechos y menos confusos, y harás la vida más fácil a los profesionales de TI responsables de cumplir tus promesas del SLA.
Usa un lenguaje sencillo en los SLA
Los clientes no siempre piden aclaraciones, así que, si el lenguaje de tu SLA es complicado, posiblemente des pie a que se produzcan algunos desagradables malentendidos más adelante. Cuanto más sencillas sean las palabras que utilices, menos probabilidades habrá de que se den conflictos con los clientes en el futuro.
Con los SLO, menos es más
No todas las métricas son esenciales para el éxito del cliente, es decir, no todas ellas deben ser un SLO. Márcate el menor número posible de SLO y céntrate en los que más importen a los clientes.
No todas las métricas trazables deberían ser un SLI
De manera similar, realizar el seguimiento del rendimiento de 10 componentes con respecto a cada uno de los 10 SLO puede resultar difícil muy rápidamente. En su lugar, elige de forma estratégica qué métricas son realmente relevantes para tus SLO principales y dedica tu energía a llevar un registro eficaz de ellas.
Incluye factores que queden fuera del control del equipo de TI
¿Qué ocurre cuando es el cliente el que ralentiza el tiempo de resolución? Si no dejas esto claro en tu SLA, el equipo puede verse obligado a resolver las incidencias del cliente sin que este se involucre.
Incorpora un presupuesto de errores
Contemplar la posibilidad de que se produzcan fallos no solo protege a la empresa frente a las infracciones del SLA y las graves consecuencias, sino que también posibilita una mayor agilidad para que el equipo pueda hacer cambios rápidamente y tenga espacio para probar nuevas soluciones innovadoras que podrían dar lugar a errores.
De hecho, Google recomienda utilizar el presupuesto de errores que sobre para los tiempos de inactividad planificados, lo que puede ayudarte a identificar las incidencias imprevistas (por ejemplo, servicios que utilizan servidores de forma inapropiada) y a mantener unas expectativas adecuadas de los clientes.
No te vengas demasiado arriba
El hecho de que tu equipo probablemente pueda mantener un 99,99 % de tiempo de actividad no significa que ese 99,99 % tenga que ser tu SLO. Siempre es mejor prometer menos de lo que eres capaz de ofrecer. Esto cobra especial relevancia en el caso de los equipos ágiles que quieren lanzar productos pronto y con frecuencia, y necesitan un presupuesto de errores para mantener ese rápido ritmo.
¿Cómo afecta esto a los equipos de SRE?
Para aquellos que sigan el modelo de Google y utilicen equipos de ingeniería de fiabilidad del sitio (SRE) con el objetivo de salvar la distancia entre el desarrollo y las operaciones, los SLA, los SLO y los SLI son fundamentales para que todo vaya a la perfección. Los SLA ayudan a los equipos a establecer límites y presupuestos de errores. Los SLO ayudan a definir las prioridades del trabajo. Y los SLI indican a los equipos de SRE cuándo deben congelar todos los lanzamientos para salvar un presupuesto de errores en peligro y cuándo pueden aflojar las riendas.
Mantente al tanto de los SLA para resolver las solicitudes en función de las prioridades y usa reglas de escalación automatizadas para notificar a los miembros adecuados del equipo y evitar incumplimientos de SLA con Jira Service Management.
Prueba Jira Service Management de forma gratuita
FAQs
What is the difference between SLI SLO and SLA? ›
An SLI (service level indicator) measures compliance with an SLO (service level objective). So, for example, if your SLA specifies that your systems will be available 99.95% of the time, your SLO is likely 99.95% uptime and your SLI is the actual measurement of your uptime.
What is the difference between service level objectives and service level indicators? ›What is the difference between Service Level Objectives (SLOs) and Service Level Indicators (SLIs)? Service Level Objectives (SLOs) define targets for certain metrics, while Service Level Indicators (SLIs) reflect ongoing measurements of those metrics. Since the two terms are closely related, they are often confused.
What is an example of SLI in SRE? ›What is SLI in SRE? In Site Reliability Engineering, SLI refers to the service level indicator which is a numerical indicator that can be measured to gauge the reliability of an application service. An example would be the “Application latency” for a web application.
Which definition best describes a service level indicator SLI? ›A service level indicator (SLI) is a metric that indicates what measure of performance a customer is receiving at a given time. The term is used by DevOps engineers when discussing quality of service (QoS).
What are the 2 types of SLA? ›There are three basic types of SLAs: customer, internal and multilevel service-level agreements.
What is the difference between SL and SLA? ›Any student of 3D printing history understands SLA as the abbreviation for StereoLithography Apparatus, similar to PCA as the commonly used abbreviation for Post-Cure Apparatus. SL is an easily understood and generic' abbreviation for stereolithography as a process, distinct from any particular equipment.
What is the difference between SLI and KPI? ›SLI´s are used in combination with a service and its SLA´s (Service Level Agreements). KPI´s are used to evaluate the effectivness of a company (a team, a group, ...) When you break it down, in both cases you choose indicators which give you an insight, to evaluate how good something is.
What is an example of a service level objective? ›Common examples of metrics that can be associated with SLOs are disaster recovery time, application availability, live communication response time, first call resolution rate and application maintenance.
What are the different service levels? ›- Unsatisfactory. Unsatisfactory customer service means that a company isn't meeting customer expectations. ...
- Meeting customer expectations. ...
- Exceptional customer service. ...
- Exceeding customer expectations.
What is a Service Level Objective (SLO)? An SLO, or Service Level Objective, is the promise that a company makes to users regarding a specific metric such as incident response or uptime. SLOs exist within an SLA as individual promises contained within the full user agreement.
What are the four golden signals of SRE? ›
The answer is with the four Golden Signals: latency, traffic, error rate, and resource saturation. In this blog, we explain what the Golden Signals are, how they work, and how they can make monitoring complex distributed systems easier.
What is the response time for SLO? ›An SLO requirement is the agreed-upon threshold for the metric and equates to some amount of acceptable downtime. The SLO target is made up of a target and warning. An example of an SLO requirement can be “95% of service requests will respond in less than 4 seconds”. The target will be 95%.
What best describes an SLO? ›Which best describes an SLO? - It is a measurable, time bound key performance indicator for your application.
What are the different types of SLI? ›Common SLIs include latency, throughput, availability, and error rate; others include durability (in storage systems), end-to-end latency (for complex data processing systems, especially pipelines), and correctness.
What are the consequences of missing SLOs? ›Failure to hit an SLO must have consequences. If, for example, more than 1000 web requests fail in a particular month, then some remediation work must take place. This is an example of an error budget policy.
What are SLA rules? ›SLA rules are automation rules that are executed when certain conditions are met. These rules can streamline agent workflow and override other existing rules if needed.
Why is SLA used? ›Service-level agreements (SLAs) are important because they establish clear commitments between a service provider and a customer. Service-level agreements are common in the telecommunications industry and provide corporations with a guarantee that certain standards will be upheld.
How do you define SLA? ›What is a service level agreement (SLA)? As a service provider, a service level agreement is a plain-language agreement between you and your customer (whether internal or external) that defines the services you will deliver, the responsiveness that can be expected, and how you will measure performance.
Can you have an SLO without an SLA? ›Service-Level Agreement (SLA)
The concept is that going out of SLO is going to hurt the service team, so they will push hard to stay within SLO. If you're charging your customers money, you will probably need an SLA.
ITIL focuses on three types of options for structuring SLA: Service-based, Customer-based, and Multi-level or Hierarchical SLAs.
What is the difference between SLA and SLS? ›
SLS (selective laser sintering) is a 3D printing technique that uses a laser to fuse together small particles of plastic, metal, glass, or ceramic powder into a solid object. SLA (stereolithography) uses an ultraviolet (UV) laser to cure (harden) photosensitive resin into the desired shape.
What is KPI versus SLO? ›A KPI is a metric you track, an SLA is something you promise, and an SLO is a range for those KPIs to live in. One KPI for the human body is heart rate, the SLA is “don't die unexpectedly”, and the SLO is keep that KPI between 40–176 bpm (for me).
What is an example of a SLA metric? ›SLA metrics are criteria negotiated between a customer and their service provider that define a quantitative target that has to be achieved for the service provided. For example, the rate of incidents resolved on time on a weekly basis is 90% or more.
What is SLA performance? ›A service-level agreement (SLA) defines the level of service expected by a customer from a supplier, laying out the metrics by which that service is measured, and the remedies or penalties, if any, should the agreed-on service levels not be achieved.
What is an example of an SLO? ›Students will appreciate the benefits of exercise science. Students will appreciate exercise as a stress reduction tool. Students will explain how the science of exercise affects stress.
What is an example of a SLO service? ›An example SLO for a service is 95% availability in a rolling 28-day window. You might feel tempted to set the objective at 100%, but that's too good to be true. Change brings instability, which will inevitably lead to failure.
What is SLO management? ›Service Level Objective (SLO) management involves setting and maintaining the target levels of service, as well as monitoring and measuring the actual system performance to ensure that it meets target levels. Management can involve setting targets for uptime, response time, error rates, and other performance metrics.
What are the 3 basic types of service? ›Services are diversified in three groups; Business services, social services and personal services.
How do you measure service levels? ›The easiest way to calculate service level is to look at the number of calls the agents can answer within a certain time frame after the phone begins to ring. This set time can be anywhere from 10 seconds to a full minute. Divide that number by the number of calls coming in and multiply the result by 100.
What is Type 1 and Type 2 service level? ›Type- I service level simply measures the number of stock-outs in each period without accounting for the exact number of units short in an order. Though more relevant, Type-II service level is less widely used in research due the the complex form of backorder quantity term which makes it hard to model it.
What is SLO status? ›
SLO status: The current evaluation result of the SLO, expressed as a percentage. The semantics of this percentage (for example, 99.3% of all service requests are successful, or 99.99% of all website users are “satisfied” in terms of Apdex rating) and the target defined for this percentage are up to the SRE team.
What is SLA priority level? ›Priority is the importance or attention given to a ticket based on the SLA. By default, there are four types of priority: Low, Medium, High and Urgent. Tickets with low priority are the least important and do not need to be solved immediately, while urgent tickets should be dealt with as soon as possible.
What does the SLO stand for? ›SLO (Service-Level Objective)
What are SRE principles? ›SRE Principles: The 7 Fundamental Rules – Final Thoughts
The SRE role focuses on building, delivering, and maintaining reliable systems and services at scale. These seven core principles of help define the practices for SREs that help drive alignment within DevOps practices and support the goals of the business.
These strategies include Production Readiness Reviews (PRRs), early engagement, and continuous improvement. Simply put, SRE principles aim to maximize the engineering velocity of developer teams while keeping products reliable. This two-fold goal is good for the product users and good for the company.
What are SRE skills? ›- Understanding of development and operations.
- Familiarity with production monitoring systems.
- Attention to detail.
- Analytical and problem-solving skills.
- Ability to collaborate across multi-functional teams.
- Coding in Java, Python, Perl, or Ruby.
- Technical writing skills.
The SLO process involves interpreting data, setting goals, using data to assess progress and adjusting instruction based on data collected.
Do parents go to slo days? ›Parents and supporters of Cal Poly students are strongly encouraged (but not required) to attend SLO Days.
What is SLO compliance? ›Compliance is the ratio of good events to total events, measured over the compliance period. The type of SLO determines what constitutes an “event”. If your SLO is 99.9%, then you're meeting it if your compliance is at least 99.9%. The max value is 100%.
What are some good tactics for setting SLO expectations? ›- List out critical user journeys and order them by business impact.
- Determine which metrics to use as service-level indicators (SLIs) to most accurately track the user experience.
- Determine SLO target goals and the SLO measurement period.
- Create SLI, SLO, and error budget consoles.
- Create SLO alerts.
What are the four golden signals quizlet? ›
What are Google's 4 Golden Signals? Latency, errors, traffic, and saturation.
Which definition best describes a service level indicator SLI quizlet? ›Which definition best describes a service level indicator (SLI)? A time-bound measurable attribute of a service.
What do I need for SLI? ›SLI requires a motherboard with multiple PCI-Express (PCI-E) slots, as well as a power supply with enough connectors for multiple graphics cards. You will want a power supply that outputs at least 650 watts. Certain cards allow up to four simultaneous cards running in SLI. Most cards are made for two-card setups.
Is SLI still used? ›Nvidia stopped providing SLI drivers in 2020, instead pushing the weight down to developers who have to specifically support it.
What does SLI mean in texting? ›"Scalable Link Interface" is the most common definition for SLI on Snapchat, WhatsApp, Facebook, Twitter, Instagram, and TikTok.
What are the benefits of SLOs? ›Help with decision making. SLOs can be a great way for DevOps and infrastructure teams to use data and performance expectations to make decisions, such as whether to release, and where engineers should focus their time. Promote automation.
What is SLOs and SLIs? ›Service level objectives (SLOs) are the goals set for the availability expected out of a system. Service level indicators (SLIs) are the key measurements and metrics to determine the availability of a system.
What is the difference between an SLI and an SLO and how are these used in the context of error budgets? ›Error Budgets
"the amount of error that your service can accumulate over a certain period before your users start being unhappy.” SLI is expressed as a percentage, and the objectives derived from SLIs are the SLOs. Now, Error budget is the remainder value of the SLOs mentioned.
KPIs, SLAs, and SLOs. A KPI is a metric you track, an SLA is something you promise, and an SLO is a range for those KPIs to live in. One KPI for the human body is heart rate, the SLA is “don't die unexpectedly”, and the SLO is keep that KPI between 40–176 bpm (for me).
What happens if SLA is not met? ›An applied and matched SLA on a ticket or work order sets target dates that are based on the SLA commitments. When a target date is exceeded, the SLA commitment is breached. A penalty or credit fee can be issued to compensate for the commitment breach.
What are the benefits of SLO and SLI? ›
Service level objectives (SLO) and service level indicators (SLI) allow you to set internal objectives for reaching SLA goals and track them. Together, the service level agreement, objectives, and indicators form a clear framework for communication between you and your clients.
What is an example of SLI implementation? ›Some example SLI implementations: Run a periodic query across the league table, counting the total number of fresh records and the total number of records. This will treat each stale record as equally important, regardless of how many users saw the data.
What are the different types of SLIs? ›- Request-based SLIs. Request-based SLIs measure the number of good or complete requests in the service versus the total number of requests for the system. ...
- Window-based SLIs. ...
- SLO. ...
- SLA. ...
- SLI. ...
- Define your SLOs. ...
- Determine your metrics for each SLI. ...
- Update your SLIs for changes.
A service level agreement SLA is an agreement between an IT Service provider and a customer. For instance, you are a customer of a bank and the bank provides services to you. A service level agreement between you and the bank describes the services provided and the service levels at which they will be provided.
What are the 5 phases of SLA management? ›Generally, SLA lifecycle management includes five major stages: Service development, Negotiation and marketing, Development, Implementation, and Evaluation.