NetOps toma nota del enfoque de SRE en el MTTR para lograr la disponibilidad
El ingeniero de confiabilidad del sitio (SRE) es un rol relativamente nuevo, generalmente dentro de ingeniería u operaciones, enfocado en mantener, como era de esperar, la confiabilidad del sitio. Esto generalmente significa disponibilidad de aplicações, pero también incluye el rendimiento. Esto tiene sentido, ya que hoy en día la mayoría de los usuarios finales consideran que las aplicaciones que no responden no están disponibles.
Al revisar el Informe SRE 2018 de Catchpoint , me llamaron la atención los gráficos que comparan los indicadores de nivel de servicio y las métricas de SRE. Generalmente, cuando se ve la “disponibilidad” como un indicador de nivel de servicio de nivel superior, también se ve el “tiempo de actividad” o el “tiempo de inactividad” como una métrica. No ocurre lo mismo con los SRE en esta encuesta.
Cuando se preguntó qué indicadores de nivel de servicio eran los más importantes para sus servicios, el 84% declaró abrumadoramente que la “disponibilidad para el usuario final” era el número uno. La latencia quedó en segundo lugar con un 61% y la tasa de error en un cercano tercer lugar con un 60%. El rendimiento, descrito como el tiempo de respuesta del usuario final en el informe, obtuvo un impresionante 58% de respuestas.
Ahora observe las métricas utilizadas para definir el éxito. En el mundo de la infraestructura y las operaciones, estamos más acostumbrados a ver métricas como "tiempo de actividad" y frases pegadizas como "5 9".
Los SRE tienden a ver el éxito en términos de tasas de incidentes y MTTR. Dado que el mismo informe señaló que el 41% de los SRE tenían un rol de “Ingeniero de DevOps” antes de convertirse en SRE, esto no debería sorprender. DevOps en sí está más preocupado por el MTTR que por calcular el tiempo de actividad porque supone que habrá tiempo de inactividad . La clave es minimizarlo resolviéndolo rápidamente en lugar de perder tiempo intentando evitarlo.
Aun así, los lectores astutos notarán que al minimizar el MTTR se minimiza el tiempo de inactividad. Resolución más rápida, menos tiempo de inactividad.
La sutil diferencia entre ambos es que los seres humanos tienden a optimizar aquello que se mide en función de ellos. Si te miden por líneas de código, vas a escribir muchas líneas de código, ya sea que las necesites o no. Si te evalúan los incidentes de seguridad, bloquearás todo y gritarás NO a cualquier cambio que pueda incentivar una vulneración. Si se mide a las personas en función del tiempo de actividad, las operaciones se centrarán en mantener los sistemas en funcionamiento y disponibles, pero no en diseñar e instrumentar sistemas y aplicações que reduzcan el MTTR.
Este es uno de esos aspectos “culturales” de DevOps (un cambio en la forma en que abordamos las operaciones) que debe trasladarse a NetOps. Si seguimos optimizando el tiempo de actividad, perdemos la oportunidad de implementar alertas y capacidad de observación (como monitoreo y registro sólido) que reducen el tiempo promedio de resolución y logran nuestro objetivo de minimizar el tiempo de inactividad.
Revisar registros, incluso los centralizados, no es un medio eficiente para llegar al corazón de un problema y resolverlo. El monitoreo y las alertas en tiempo real sobre variables clave que impactan la disponibilidad, como capacidad, conectividad y rendimiento en toda la ruta de datos (red, infraestructura, aplicação) invariablemente reducirán el tiempo que lleva resolver problemas si usted sabe que hay sistemas o servicios que se están degradando o han fallado abruptamente.
NetOps debe adoptar este enfoque con respecto a la confiabilidad en el flujo de producción porque es un enfoque general mejor para lidiar con fallas inevitables y se alinea con sus contrapartes de DevOps. Después de todo, hay una razón por la que sólo utilizamos 5 9, ¿no es así? Porque reconocimos que el fracaso ocurre sin importar cuánto lo intentemos y la perfección es imposible.
Pasar del tiempo de actividad/inactividad al MTTR como métrica de éxito fomenta la colaboración entre equipos y el uso de herramientas de observación en todo el proceso de producción. Hay una razón por la que las herramientas de monitoreo y alerta estuvieron entre las principales “herramientas imprescindibles” para los SRE en la encuesta. La observabilidad (con el objetivo de alertar sobre errores o incidentes) más la colaboración es una mejor fórmula para garantizar que todos (NetOps, DevOps y App Dev también) puedan cumplir su objetivo de mantener las aplicaciones rápidas y disponibles.