Insights

Noticias, novedades e información sobre el mundo Hard Tech

Aprenda cómo administrar plataformas de misión crítica con las prácticas de Google.

por: Inmetrics em

| 10.04.2019

Usted ya debe preguntarse cuál es el secreto de empresas como Netflix, Google, Amazon, AWS, AirBnb, para conseguir entregar excelencia y calidad en la experiencia de usuario de sus servicios, ¿cierto? 

Para contestar esta pregunta es necesario entender cuál es la feature más importante de un producto. Imagínese que usted es usuario de Netflix, e hipotéticamente, alguien le proporciona acceso a dos versiones diferentes del producto, como se muestra a continuación. ¿Cuál de ellos preferirías? 

¿Netflix del año 2016? 

 

O Netflix en 2019, pero con el error abajo? 

 Si tuviera que apostar, diría que usted elegiría el Netflix 2016, ¿correcto? Este pequeño ejercicio muestra que, para el cliente, la característica más importante de un producto es que funcione. Sin embargo, no se equivoca, por más que ésta sea la principal funcionalidad de un producto, es común que las personas se olviden y sólo presten atención a ella cuando las cosas comiencen a fallar. 

Antes de entrar en el tema en cuestión, creo importante dejar claro la diferencia entre Disponibilidad y Confiabilidad. La primera trata el tiempo que su servicio está en el aire, listo para atender eventuales requisiciones. La segunda, se refiere a la calidad de las interacciones de los usuarios con su sistema. 

En vista de eso, usted puede entonces concluir que se debe buscar el 100% de confiabilidad y disponibilidad, ¿verdad? Mal! 

Para quien ya ha estudiado un poco sobre el tema, la tabla abajo es muy familiar y muestra el tiempo que su servicio puede quedar no disponible dentro del tiempo analizado. 

 

Nivel de disponibilidad 

Si buscamos una disponibilidad de tres 9 (99,9%), por ejemplo, dentro de un mes, podemos quedar inaccesibles unos 43 minutos. Para cada “9” la más deseada, existe también un costo exponencial de recursos asociados. Este costo es financiero ($$$) y también de personas. 

Por más que puedas alcanzar estos hipotéticos 100% de disponibilidad, tus usuarios no sentirán esa experiencia en la totalidad, después de todo, ¿cuántas veces has intentado utilizar un servicio, y tu móvil, tu computadora o tu internet no estaba funcionando? 

Las posibilidades son que, si realmente su objetivo es alcanzar el 100% de disponibilidad, usted nunca va a lanzar nuevas funcionalidades o mejorar su servicio. La tendencia dice que su producto quedará estancado. 

“¡La búsqueda de la disponibilidad perfecta mata la innovación!” 

Encontrar el equilibrio en medio del caos 

CIOs, VPs y dueños de productos críticos con experiencia entienden el cansancio emocional y los daños financieros resultantes de las decisiones críticas operativas. Este día a día es difícil, cansado, impreciso y principalmente conflictivo. 

Es necesario encontrar el equilibrio correcto entre invertir en funcionalidades que van a ganar nuevos clientes o mantener los actuales, frente a invertir en la confiabilidad y escalabilidad que mantendrán los mismos clientes satisfechos. 

 

Más experimentos x Más Confiabilidad 

¿Imagínate que este desafío puede resolverse a partir de un problema de matemáticas? ¿Imagínese que usted puede tener una métrica que pueda alinear los intereses entre los equipos de operación, de desarrollo e incluso el equipo de productos? 

Service Level Objective (SLO) define un objetivo de confiabilidad que una aplicación necesita alcanzar para satisfacer las necesidades de sus usuarios en el negocio. Es una medida de cuán bien atendidos están sus usuarios y cómo su producto está funcionando correctamente. Algunos ejemplos de SLO se muestran a continuación: 

  • 99.9% del total de solicitudes HTTP responden con éxito 
  • 80% del total de peticiones HTTP devuelven en menos de 700ms 
  • 95% de las ejecuciones del trabajo crítico ABC de la malla batch procesa en hasta 4 horas 
  • Disponibilidad del 99,5% (3,6 horas de indisponibilidad) 

Idealmente usted debe establecer objetivos de los cuales sus clientes realmente se preocupan, o mejor, trabaje con objetivos que estén directamente ligados a (buena) experiencia del usuario. Por ejemplo, nunca debe utilizar el consumo de CPU como métrica de SLO, sino considerar el tiempo de sistema que el usuario tarda en ejecutar determinada acción. 

“SLO es sobre mantener a sus usuarios felices” 

 Usted puede implementar SLO hoy para su aplicación, pero eso es sólo la base que le permite responder a las emergencias de verdad. 

Por lo tanto, hay que avanzar más para encontrar el equilibrio en la toma de decisiones. Es necesario que haya consecuencia cuando no se alcanza el SLO objetivo, y esta consecuencia no es en el sentido de castigo (por ejemplo, en encontrar culpables o incluso financieros), sino como una oportunidad para mejorar su servicio y capacitar a su equipo a moverse lo más rápido posible, sin perder la calidad. 

Es aquí donde entra el concepto de Error Budget que es básicamente la diferencia entre la confiabilidad perfecta y el SLO acordado durante un período definido: 

Error budget = (1 – SLO) 

Por lo tanto, si tengo un SLO del 99,9%, hay un porcentaje del 0,1% de error de presupuesto. Trayendo para un ejemplo más real, para un servicio que realiza 1B solicitudes / mes, usted tiene una cuota de 1M errores / mes. 

Implantar el concepto de Error Budget muestra que hay una cantidad pequeña, pero no nula, aceptable de fallas. Sus decisiones de negocio serán orientadas por datos y con una métrica que alinea los intereses de todas las áreas involucradas en el negocio y especialmente colocan al cliente (y la experiencia de uso de él) en el centro. 

Adoptando el enfoque SLO / Error Budget, es posible resolver buena parte de los conflictos entre nuevos releases de la aplicación y la estabilidad esperada por los ejecutivos. 

Este método de trabajo fue creado por Google, y sirve de base para todo el framework SRESite Reliability Engineering. Es una verdadera revolución en el modo de operar y gestionar su operación. 

Si desea entender un poco más sobre SRE o incluso empezar a practicar e implementar SLO / Error Budget en su negocio, hable con nosotros. 

 

Escrito por: 

Thiago Maciel
Tech specialist Inmetrics