Estado
Todos los sistemas operativos.
Una página de estado solo vale algo si está dispuesta a decir algo malo. Esta se actualiza durante la incidencia, no después, lo que significa que a veces verás la palabra investigando junto a un componente mientras todavía no sabemos por qué.
Componentes
| Componente | Estado | Objetivo | Ahora mismo |
|---|---|---|---|
| API | Operativo | 99,9 por ciento de disponibilidad | Sin errores por encima de la línea base en las últimas 24 horas |
| Aprovisionamiento | Operativo | El 99,5 por ciento de los pedidos pagados llegan a un perfil funcionando | La última hora móvil está por encima del objetivo, instalación mediana de 41 segundos |
| Pagos | Operativo | Autorización y reembolso automático en menos de 60 segundos | La pasarela informa de normalidad y los reembolsos salen a tiempo |
| Datos de cobertura | Operativo | Cifras publicadas actualizadas a diario, con el mínimo de 25 muestras respetado | La última actualización terminó y ningún país está oculto por datos antiguos |
| Soporte | Operativo | Primera respuesta en menos de 60 segundos, 24 horas al día | La cola está dentro del objetivo en todos los idiomas atendidos |
Operativo significa que el componente cumple su objetivo en la última hora móvil. No es una promesa sobre la hora siguiente.
99,5%
objetivo de éxito del aprovisionamiento
60 s
reembolso automático cuando falla el aprovisionamiento
30 min
duración de incidencia que obliga a un post mortem público
72 h
plazo para publicar ese post mortem
Qué significa cada estado
| Estado | Qué significa | Qué hacemos |
|---|---|---|
| Operativo | El componente cumple su objetivo en la última hora móvil | Nada. Es el estado normal y no es una promesa sobre el futuro |
| Rendimiento degradado | Funciona, pero más lento o menos fiable que el objetivo | Lo nombramos en esta página, avisamos a los clientes afectados y aplicamos los abonos sin que nadie los pida |
| Interrupción parcial | Falla para un grupo identificable, como un operador o una región | Nombramos el grupo, bloqueamos las compras donde fallarían y los reembolsos salen automáticamente |
| Interrupción grave | Falla de forma generalizada | Se nombra a un coordinador de incidencias y publicamos actualizaciones al menos cada 30 minutos hasta resolverlo |
| Mantenimiento | Trabajo planificado con una ventana conocida | Lo anunciamos con al menos 72 horas de antelación y lo programamos en la hora de menos tráfico |
No hay ningún estado que signifique bien, seguramente. O el componente cumple su objetivo o aparece nombrado en esta página.
La política de incidencias
Dos compromisos sostienen todo esto, y los dos son incómodos a propósito. El primero es que avisamos a los clientes afectados antes de que lo noten. El segundo es que todo lo que pase de 30 minutos lleva un post mortem escrito y publicado en 72 horas.
El post mortem nombra sistemas y decisiones, no empleados concretos, y lo escribe quien estaba de guardia, no un jefe describiendo a otra persona.
Si vamos a incumplir el plazo de 72 horas, publicamos el retraso y el motivo dentro de esas 72 horas, porque un plazo incumplido y anunciado tarde son dos fallos.
- La detección es automática a partir de las tasas de éxito del aprovisionamiento y de autorización de pagos, así que una incidencia empieza cuando se mueven los números, no cuando alguien se queja
- El estado del componente en esta página cambia en los cinco minutos siguientes a la declaración, antes de conocer la causa
- Un coordinador de incidencias dirige la respuesta y otra persona distinta lleva la comunicación, para que ninguna de las dos tareas ahogue a la otra
- Identificamos y avisamos a los clientes afectados, con el abono ya aplicado donde el servicio se degradó, en lugar de ofrecerlo solo a quien lo pida
- Bloqueamos las compras en cualquier ruta donde sabemos que fallarían, porque cobrar un dinero que tendremos que devolver es peor que perder la venta
- Durante una interrupción grave publicamos una actualización al menos cada 30 minutos, aunque la actualización sea que seguimos sin saberlo
- En las 72 horas siguientes a la resolución publicamos un post mortem con la cronología, el impacto en clientes en cifras, la causa y cada arreglo con responsable y fecha
Por qué el objetivo no es el cien por cien
Porque hay una red de por medio y el cien por cien sería mentira. Un objetivo de aprovisionamiento del 99,5 por ciento dice en voz alta que unos cinco pedidos de cada mil fallarán en algún punto entre el pago y el perfil funcionando.
Lo que importa es que el camino de esos cinco esté diseñado. El reembolso salta en menos de 60 segundos sin abrir un ticket, el mensaje explica qué ha pasado y qué probar en su lugar, y nadie tiene que decidir si el cliente se lo merece.
La misma lógica vale para la cobertura. Cuando una red asociada está congestionada en un territorio que cubrimos con más de un operador, te cambiamos de red en vez de abrir una incidencia, y la nota dice qué cambio se hizo.
Cuando solo hay una red y está teniendo un mal día, lo decimos en la página del país. Nuestras páginas de cobertura publican la mediana, el décimo más lento y el número de muestras exactamente por esto.
Historial de incidencias
No se ha declarado ninguna incidencia de más de 30 minutos en el periodo del que informamos.
Esa frase vale exactamente lo que valga nuestra disposición a cambiarla, y por eso la política de arriba está escrita con este nivel de detalle. Todos los post mortem antiguos siguen publicados de forma permanente en vez de caducar a los noventa días.