Enterarnos del fallo antes que tus clientes.
Para quién
Para empresas y administraciones con una web, un portal o una aplicación de la que dependen sus clientes o su equipo, y que hoy se enteran de los fallos cuando alguien llama.
El problema
Te enteras de que la web no funciona porque te escribe un cliente. El certificado caducó un domingo. Hay un error que solo les sale a algunos usuarios desde hace meses y nadie lo ha visto, porque nadie mira los registros.
Cómo lo resolvemos
Vigilamos desde fuera que todo responde y, desde dentro, cada error que se produce. Por cada error nuevo, un agente abre una incidencia con lo que ha pasado y prepara el arreglo. Una persona lo revisa antes de que llegue a producción. Tú recibes el aviso con lo que ya se ha hecho.
Qué incluye
Disponibilidad
Comprobamos desde fuera que tu web y tus aplicaciones responden, y cuánto tardan.
Certificados
Vigilamos su caducidad, con aviso antes de que venzan.
Errores
Cada error de la aplicación queda recogido, agrupado y con su contexto.
Una incidencia por cada error nuevo
La abre un agente, con la causa probable y los pasos para reproducirlo.
Arreglo preparado
El agente propone el cambio; lo revisa y lo aprueba una persona.
Avisos y resumen mensual
Aviso automático cuando algo falla y un informe con lo que ha pasado.
Cómo trabajamos
Al empezar acordamos qué se vigila, a quién se avisa y por dónde. Conectamos la vigilancia y limpiamos el ruido de las primeras semanas, para que un aviso signifique algo. Después, cada error nuevo sigue el mismo camino: incidencia, arreglo propuesto, revisión de una persona y despliegue. En el informe mensual ves qué ha fallado y qué se ha corregido.
Qué medimos
Disponibilidad, tiempo de respuesta, errores nuevos y errores resueltos, tiempo desde que aparece un error hasta que está corregido y días que faltan para que caduque cada certificado.
Cómo está hecho
En cada proyecto vigilamos la disponibilidad, el tiempo de respuesta y la caducidad de los certificados SSL, con aviso automático. Las comprobaciones se hacen desde fuera, como las haría un usuario.
Los errores del navegador y del servidor se recogen con GlitchTip, compatible con el protocolo de Sentry. Antes de guardarse se les quitan los datos personales: para arreglar un fallo hace falta saber qué pasó, no a quién.
Cuando aparece un error que no se había visto, un agente lo lee, busca en el código de dónde viene y abre una incidencia en GitLab con la traza, la causa probable y cómo reproducirlo. Después prepara el arreglo en una rama, con su test. No lo publica: el cambio pasa por las mismas pruebas que cualquier otro y lo aprueba una persona.
Los errores repetidos se agrupan en una sola incidencia, para no llenar el tablero de avisos iguales. El agente trabaja con permisos mínimos y sin acceso a las credenciales de producción.
Preguntas frecuentes
¿El agente arregla los errores solo?
No. Abre la incidencia y prepara el arreglo. Una persona lo revisa, lo aprueba y decide cuándo se publica.
¿Cómo me entero de un fallo?
Con un aviso automático por el canal que acordemos al empezar y con el resumen del informe mensual.
¿Qué pasa con los datos personales que aparecen en un error?
Se quitan antes de guardar el error. Lo que se conserva es lo necesario para reproducir el fallo.
¿Sirve para una aplicación que no habéis hecho vosotros?
Sí. La vigilancia de disponibilidad no necesita tocar nada. Para recoger los errores hay que añadir una pieza pequeña a la aplicación.
También en Sistemas gestionados
Copias de seguridad
Cifradas y comprobadas: restauramos de verdad, no solo copiamos.
Despliegues
Cada cambio pasa por pruebas antes de producción, con vuelta atrás.
El siguiente paso
Cuéntanos cómo trabaja hoy tu empresa y te decimos por dónde empezar.