Te ofrecemos esta traducción automática para facilitar la lectura.
En caso de que haya discrepancias entre la versión en inglés y la versión traducida, se entiende que prevalece la versión en inglés. Visita esta página para obtener más información.
Administración a nivel de servicio es la práctica de estandarizar datos en un lenguaje universal. Dentro de una organización, la comunicación entre las partes interesadas a menudo puede resultar más difícil de lo necesario. Los departamentos de TI generalmente no hablan en términos que las partes de una organización centradas en el negocio puedan entender y, a su vez, normalmente no se comunican en términos que los equipos de TI encuentren útiles. Para mejorar la confiabilidad, resolver esta barrera del idioma ayuda a prevenir problemas. La administración a nivel de servicio, o la práctica de estandarizar los datos en un lenguaje universal que todas las partes puedan entender, ayuda a lograr precisamente eso.
Administración a nivel de servicio se aplica mejor a las prácticas de tiempo de actividad, rendimiento y confiabilidad, pero también se aplica a otras prácticas de experiencia del cliente, innovación y crecimiento, y eficiencia operativa (obtenga más información sobre estas prácticas). Independientemente del área que desee mejorar, el uso de SLM tiene dos áreas principales de impacto: resultados comerciales y resultados operativos.
Los resultados comerciales requeridos en términos de confiabilidad se enfocan en reducir el número de incidentes que impactan en el negocio, su duración y el número de personas involucradas.
Reducir el número de incidentes que perturban el negocio.
Reducir el tiempo medio de resolución (MTTR).
Reducir el número promedio de personas involucradas (ETC) por incidente grave.
El resultado operativo requerido en términos de confiabilidad se centra en la salud de su producto digital.
Mida el éxito operativo según el porcentaje de aplicaciones críticas del producto que cubre con su nivel de servicio estándar.
Examine el porcentaje de adopción de políticas por parte de sus principales partes interesadas.
Centrarse en lo que es importante para las partes interesadas, garantizar la simplicidad y demostrar la eficacia de la administración a nivel de servicio.
¿Por qué utilizar administración a nivel de servicio?
Mejorar el nivel de servicio y la confiabilidad requiere la adopción de la práctica por parte de todas las partes interesadas del servicio. Esto incluye gestión de ingeniería, gestión de productos y gestión ejecutiva para mostrar rápidamente el poder y el valor del nivel de servicio e iniciar discusiones sobre lo que le importa a cada grupo. Los pasos de esta guía le permitirán generar debates significativos muy rápidamente.
Un método común establece primero el nivel de servicio del rendimiento de salida y el rendimiento de entrada para un producto digital y sus capacidades críticas. Esto generalmente implica un nivel de servicio deentrada y salida general para cada aplicación extremo (generalmente una o dos), y luego aproximadamente 4 a 7 niveles de servicio de rendimiento de salida para las capacidades críticas asumidas medidas en la transacción extremo.
Este método no encuesta a cada parte interesada para determinar qué se debe medir y qué no, ya que las encuestas a menudo toman demasiado tiempo y tienen demasiadas partes en escenarios como este. Lo importante es comenzar con línea de base y clave de transacción como "capacidades".
Las implementaciones exitosas del nivel de servicio demuestran la capacidad de medir y comunicar fácilmente el estado general del sistema. Esa demostración inicial mostrará el valor de invertir más tiempo para refinar lo que mide su nivel de servicio. ¡Cuanto antes proporcione esa demostración completa, antes podrá lograr una adopción amplia y comenzar el proceso de mejora de la confiabilidad en colaboración con todas las partes interesadas!
Echemos un vistazo a algunos de los términos comunes y definamos nuestros KPI antes de continuar.
Terminología
Un nivel de servicio mide el rendimiento de un sistema. Usted mide el nivel de servicio utilizando indicadores y comparándolos con un conjunto de objetivos para el rendimiento y los resultados esperados.
Definimos administración a nivel de servicio como la práctica de informar, mantener y gestionar el cumplimiento del nivel de servicio.
Un indicador de nivel de servicio (SLI) mide un nivel de servicio. Un SLI identifica algo que desea medir y mide un punto de datos o una combinación de puntos de datos. Un SLI comúnmente representa un porcentaje (%) de transacción o evento exitoso. Mide el número total de eventos buenos sobre el número total de eventos válidos calculados durante un período de tiempo específico, como 1 hora, 1 día o 1 semana.
Ejemplos de SLI:
Porcentaje de transacciones API de inicio de sesión que se completan en 500 milisegundos.
Porcentaje de transacciones API de inicio de sesión que se completan sin un error interno del servidor.
Porcentaje de transacciones API de inicio de sesión que se completan en 500 milisegundos y sin un error interno del servidor.
Porcentaje de comprobaciones de Pings sintéticos contra la API de inicio de sesión que tienen éxito.
Porcentaje de inicios de sesión browser que pasan a la página de destino en 3 segundos.
Porcentaje de métricas ingeridas que están disponibles para consulta en 3 segundos.
Algunos o todos los anteriores agregados en un solo SLI.
Un objetivo de nivel de servicio (SLO) describe el nivel de servicio esperado de un sistema, trabajo o capacidad. Generalmente indica el porcentaje requerido de éxito de uno o más SLI dentro de un período de tiempo determinado.
Ejemplos de SLO:
La API de inicio de sesión responderá en 500 milisegundos y sin errores el 99,99% del tiempo cada semana.
La capacidad de inicio de sesión móvil pasará a la página de destino en 3 segundos el 99,99% del tiempo cada semana.
La ingesta de datos de métrica estará disponible para consulta dentro de los 3 segundos posteriores al consumo desde la API el 99,99% del tiempo cada día.
Un límite de servicio es a menudo el punto en un sistema donde el consumidor realiza una solicitud a través de un cliente, también conocido como API externa o extremo. Los límites del servicio también pueden ser internos entre dos sistemas distintos, donde un conjunto de aplicaciones atiende las solicitudes de otro conjunto de aplicaciones. Por ejemplo, un sistema de gestión de identidad puede servir tanto para solicitudes de inicio de sesión del cliente como para autorización de permisos para diferentes características.
Tipos de límites:
Límite del servicio de cara al cliente: la API GraphQL de cara al cliente. Este límite le brinda la suma total del tiempo de respuesta y la métrica de éxito requerida para medir el estado del desempeño, sin la necesidad de medir cada dependencia.
Límite del servicio interno: dependencia del middleware detrás de la API GraphQL orientada al cliente. Cada API de dependencia que responde al nivel GraphQL cuenta como su propio límite de servicio interno. Los límites del servicio interno no representan el estado general del rendimiento de la salida en una proporción de 1:1. Por ejemplo, la solicitud de un cliente a la API GraphQL podría alcanzar siete dependencias internas. Una dependencia lenta no afecta la suma total del tiempo de respuesta de la solicitud original.
Un presupuesto de errores mide y comunica el cumplimiento de sus objetivos de nivel de servicio. Tenemos información más detallada sobre este método avanzado en nuestros documentos de administración a nivel de servicio.
Un presupuesto de errores rastrea cuánto puede fallar su servicio antes de "no cumplir". Puede utilizar algunos métodos diferentes para definir y medir presupuestos de errores. La palabra "error" en "presupuesto de errores" no significa errores de solicitud HTTP o errores de aplicación, sino que se refiere a "cualquier solicitud o evento incorrecto" según se define en sus objetivos de nivel de servicio.
Nota: Le recomendamos que primero aprenda cómo definir, calcular y comunicar el cumplimiento de su nivel de servicio antes de implementar presupuestos de errores. Es muy importante que pueda establecer un objetivo para sus SLI para medir el éxito de qué tan bien su SLI cumple con sus objetivos. Por ejemplo, puede realizar un seguimiento de si se encuentra dentro de los 500 milisegundos y sin errores en un 99,99 % cada uno durante un período de 24 horas de sus solicitudes de inicio de sesión. Si su resultado de cumplimiento del SLI de 24 horas alcanza el 99,99%, entonces puede considerar cumplido su objetivo.
"Un presupuesto de error es la cantidad máxima de tiempo que un sistema técnico puede fallar sin consecuencias contractuales. Por ejemplo, si su acuerdo de nivel de servicio (SLA) especifica que los sistemas funcionarán el 99,99% del tiempo antes de que la empresa tenga que compensar a los clientes por la interrupción, eso significa que su presupuesto de errores (o el tiempo que sus sistemas pueden dejar de funcionar sin consecuencias) es 52 minutos y 35 segundos por año." -- Atlassian - ¿Qué es un presupuesto de error y por qué es importante?
Requisitos previos
Tenga datos para monitor y establecer SLI, por ejemplo, a través de la instrumentación APM de su aplicación principal.
También puedes utilizar la prueba sintética de tu aplicación para generar datos para monitor sin depender de los clientes.
Si bien no es obligatorio, le recomendamos encarecidamente que adquiera habilidades básicas con el panel de New Relic y NRQL.