Saltar al contenido
Informes impresos con gráficas y tablas, sujetos con pinzas, sobre una mesa de madera

Así es lo que recibís

Un informe mensual y un extracto de auditoría, con datos ficticios, para que sepáis qué os llega antes de contratar. Formato habitual de la documentación del ENS: portada, control de versiones, índice y paginación.

Ejemplo con datos ficticios. La empresa, las cifras y las incidencias de esta página son inventadas para enseñar el formato. No corresponden a ningún cliente.

Informe mensual

Así es un informe mensual

Lo recibís la primera semana de cada mes. Una página para leer en cinco minutos y el detalle debajo para quien lo quiera.

Ejemplo con datos ficticios

Uso interno

Informe mensual

Informe mensual del servicio SRE

Septiembre de 2026

Preparado para
Ejemplo SaaS S.L.
Preparado por
SRE responsable del servicio
Código
EJ-SRE-INF-2026-09
Versión
1.0
Fecha de la versión
03/10/2026
Clasificación
Uso interno
EJ-SRE-INF-2026-09Clasificación: Uso internoEjemplo con datos ficticiosPágina 1 de 8

Informe mensual del servicio SRESeptiembre de 2026

Versión 1.0

03/10/2026

Página 2 de 8

Control del documento

CódigoEJ-SRE-INF-2026-09
TítuloInforme mensual del servicio SRE: Septiembre de 2026
Versión1.0
Fecha de la versión03/10/2026
EstadoAprobado
ClasificaciónUso interno
Creado porSRE responsable del servicio
Revisado porResponsable técnico, Ejemplo SaaS S.L.
Aprobado porCTO, Ejemplo SaaS S.L.
ObjetivoInformar del estado del servicio en septiembre de 2026 (disponibilidad, incidencias, cambios, riesgos y vulnerabilidades) y dejar por escrito las acciones acordadas para el mes siguiente.

Historial de versiones

VersiónFechaAutorDescripción del cambio
0.101/10/2026SRE responsable del servicioBorrador para revisión
1.003/10/2026CTO, Ejemplo SaaS S.L.Versión aprobada

Lista de distribución

DestinatarioEntidad
CTOEjemplo SaaS S.L.
Equipo de desarrolloEjemplo SaaS S.L.
SRE responsable del servicioProveedor del servicio
EJ-SRE-INF-2026-09Clasificación: Uso internoEjemplo con datos ficticios

Informe mensual del servicio SRESeptiembre de 2026

Versión 1.0

03/10/2026

Página 4 de 8

1. Objeto y alcance

Cliente
Ejemplo SaaS S.L.
Periodo
Septiembre de 2026
Servicio
SRE como servicio, plan Estándar
Plataforma
Kubernetes gestionado en AWS, PostgreSQL gestionado, GitLab CI

2. Resumen del mes

  • Disponibilidad de la API: 99,95 %, por encima del objetivo del 99,9 %.
  • Una incidencia con impacto (18 minutos de errores en la API) y una menor sin impacto para usuarios.
  • Actualización del clúster a una versión con soporte y parches de seguridad de los nodos, sin cortes.
  • Riesgo nuevo: el certificado del dominio de pruebas no se renueva solo. Propuesta en la sección de riesgos.
  • Vulnerabilidades: 23 encontradas, 19 corregidas y 4 pendientes, cada una con su justificación.
  • Restauración de prueba mensual de PostgreSQL completada en 24 minutos.

3. Disponibilidad del mes

ServicioObjetivoRealTiempo sin servicioEstado
API pública99,9 %99,95 %22 minCumple
Panel web99,9 %99,97 %13 minCumple
Procesos en segundo plano99,5 %100 %0 minCumple
Entorno de pruebasSin objetivo98,8 %8 h 38 minInformativo

Medido con sondas externas cada minuto. El tiempo sin servicio de la API incluye la incidencia INC-0912 y 4 minutos de una ventana de mantenimiento avisada.

EJ-SRE-INF-2026-09Clasificación: Uso internoEjemplo con datos ficticios

Informe mensual del servicio SRESeptiembre de 2026

Versión 1.0

03/10/2026

Página 5 de 8

4. Incidencias

4.1 Errores 502 en la API durante 18 minutos

INC-0912Gravedad alta

Inicio
12 de septiembre, 10:41
Detección
10:43, alerta automática de tasa de errores
Servicio restablecido
10:59
Impacto
Alrededor del 30 % de las peticiones a la API devolvieron error durante 18 minutos

Cronología

  1. 10:41Un despliegue reduce por error el número mínimo de réplicas de la API de 3 a 1.
  2. 10:43Salta la alerta de errores 5xx. Empezamos el diagnóstico.
  3. 10:52Identificado el cambio en el chart de Helm como origen.
  4. 10:59Revertido el commit; GitOps restaura las 3 réplicas y los errores vuelven a cero.

Causa: Un valor por defecto del chart cambió entre versiones y el despliegue no lo fijaba. La revisión del cambio no lo detectó porque el diff no mostraba el valor heredado.

Acciones

  • Fijar el número mínimo de réplicas en los valores de producción (hecho, MR 418).
  • Añadir al pipeline una comprobación que falla si producción baja de 2 réplicas (tarea OPS-233, en curso).
  • Mostrar en cada merge request el diff de los valores renderizados del chart (tarea OPS-234, pendiente).
EJ-SRE-INF-2026-09Clasificación: Uso internoEjemplo con datos ficticios

Informe mensual del servicio SRESeptiembre de 2026

Versión 1.0

03/10/2026

Página 6 de 8

4. Incidencias (continuación)

4.2 Disco de los logs al 85 %

INC-0926Gravedad baja

Detección
26 de septiembre, alerta preventiva
Impacto
Ninguno para los usuarios

Causa: Un servicio nuevo enviaba logs de depuración en producción.

Acciones

  • Nivel de log corregido y retención de Loki ajustada a 30 días (hecho, MR 431).

5. Cambios realizados

FechaCambioReferenciaCorte
3 sep.Parches de seguridad de los nodos del clústerMR 402No
10 sep.Actualización del clúster a una versión con soporteMR 409No
12 sep.Réplicas mínimas de la API fijadas en producciónMR 418No
18 sep.Imagen base de los servicios actualizadaMR 423No
24 sep.Ventana de mantenimiento de PostgreSQL (versión menor)MR 4274 min, avisado
26 sep.Retención de logs ajustada a 30 díasMR 431No

6. Mejoras realizadas

TareaDescripciónEstado
OPS-221Apagar el entorno de pruebas fuera de horario laboralHecha
OPS-227Alertas de caducidad de certificados en todos los dominiosHecha
OPS-230Restauración de prueba de PostgreSQL en una cuenta aisladaHecha
OPS-233Comprobación de réplicas mínimas en el pipelineEn curso
OPS-234Diff de valores renderizados en las merge requestsPendiente
EJ-SRE-INF-2026-09Clasificación: Uso internoEjemplo con datos ficticios

Informe mensual del servicio SRESeptiembre de 2026

Versión 1.0

03/10/2026

Página 7 de 8

7. Riesgos y recomendaciones

RiesgoPrioridadRecomendaciónEsfuerzo
El certificado del dominio de pruebas se renueva a manoMediaPasarlo a renovación automática como el restoS
Una única persona del equipo tiene acceso de administración a la cuenta de AWSAltaSegundo administrador con doble factor y acceso de emergencia documentadoS
La restauración completa de producción no se ha ensayado en otra regiónMediaEnsayo anual de recuperación ante desastres en otra regiónM

Esfuerzo estimado: S = horas, M = días, L = semanas.

8. Vulnerabilidades

Encontradas este mes
23
Corregidas y verificadas
19
Pendientes
4, con justificación
Críticas expuestas a internet
0

8.1 Corregidas

  • 14 en imágenes de contenedor: imagen base actualizada y servicios reconstruidos (MR 423).
  • 3 en dependencias de la API: versiones parcheadas tras pasar los tests (MR 425).
  • 2 en los nodos del clúster: parches de seguridad del sistema (MR 402).
EJ-SRE-INF-2026-09Clasificación: Uso internoEjemplo con datos ficticios

Informe mensual del servicio SRESeptiembre de 2026

Versión 1.0

03/10/2026

Página 8 de 8

8. Vulnerabilidades (continuación)

8.2 Pendientes y por qué

VulnerabilidadDóndeRiesgo realPor qué sigue abiertaPlan
VUL-EJ-07 (CVSS 8,1)Librería de imágenes del servicio de informesBajo: la función afectada no se usa y el servicio no está expuestoEl fabricante aún no ha publicado versión corregidaActualizar en cuanto salga; revisado cada semana
VUL-EJ-11 (CVSS 6,5)Base de datos PostgreSQLBajo: solo accesible desde la red privadaLa corrección exige versión menor con reinicioVentana avisada el 8 de octubre
VUL-EJ-15 (CVSS 5,3)Herramienta de construcción del pipelineMuy bajo: solo en la fase de build, sin datos de producciónEsperando a que el equipo de desarrollo valide la versión nuevaTarea OPS-238, este mes
VUL-EJ-19 (CVSS 4,3)Imagen del entorno de pruebasMuy bajo: entorno sin datos realesSe corregirá con la imagen base de octubrePróxima actualización mensual

Escaneo continuo de imágenes, dependencias y sistemas con Trivy y Grype. La prioridad se decide por el riesgo real (exposición, explotación conocida y datos afectados), no solo por la puntuación CVSS. Identificadores ficticios. El inventario de software (SBOM) completo va en un anexo.

EJ-SRE-INF-2026-09Clasificación: Uso internoEjemplo con datos ficticios

Auditoría (extracto)

Así es una auditoría

Un extracto del informe de la auditoría de fiabilidad y seguridad: los riesgos principales, por orden, con su evidencia, y el plan de mejora priorizado.

Ejemplo con datos ficticios

Difusión limitada

Auditoría (extracto)

Auditoría de fiabilidad y seguridad

Extracto del informe de resultados

Preparado para
Ejemplo SaaS S.L.
Preparado por
SRE auditor
Código
EJ-AUD-2026-01
Versión
1.0
Fecha de la versión
09/10/2026
Clasificación
Difusión limitada
EJ-AUD-2026-01Clasificación: Difusión limitadaEjemplo con datos ficticiosPágina 1 de 6

Auditoría de fiabilidad y seguridadExtracto del informe de resultados

Versión 1.0

09/10/2026

Página 2 de 6

Control del documento

CódigoEJ-AUD-2026-01
TítuloAuditoría de fiabilidad y seguridad: Extracto del informe de resultados
Versión1.0
Fecha de la versión09/10/2026
EstadoAprobado
ClasificaciónDifusión limitada
Creado porSRE auditor
Revisado porResponsable técnico, Ejemplo SaaS S.L.
Aprobado porDirección general, Ejemplo SaaS S.L.
ObjetivoIdentificar los riesgos de fiabilidad y seguridad de la plataforma, ordenarlos por impacto y proponer un plan de mejora priorizado con el esfuerzo estimado de cada acción.

Historial de versiones

VersiónFechaAutorDescripción del cambio
0.106/10/2026SRE auditorBorrador con los resultados de la revisión
0.208/10/2026Responsable técnico, Ejemplo SaaS S.L.Comentarios del equipo incorporados
1.009/10/2026Dirección general, Ejemplo SaaS S.L.Versión aprobada

Lista de distribución

DestinatarioEntidad
Dirección generalEjemplo SaaS S.L.
Responsable técnicoEjemplo SaaS S.L.
SRE auditorProveedor del servicio
EJ-AUD-2026-01Clasificación: Difusión limitadaEjemplo con datos ficticios

Auditoría de fiabilidad y seguridadExtracto del informe de resultados

Versión 1.0

09/10/2026

Página 4 de 6

1. Objeto y alcance

Empresa
Ejemplo SaaS S.L.
Fecha
6 de octubre de 2026
Fuente
Revisión con acceso de lectura a la cuenta cloud, los servidores y el repositorio, y una entrevista con el equipo
Plataforma revisada
Dos servidores en Hetzner con Docker Compose, PostgreSQL autoalojado, GitLab.com

Equipo de cinco personas de desarrollo, sin nadie de sistemas desde que se fue la persona que montó los servidores. Unos 40 clientes de pago usan la aplicación en horario laboral. Un cliente nuevo ha enviado un cuestionario de seguridad.

2. Los 3 riesgos principales

Esfuerzo estimado: S = horas, M = días, L = semanas.

2.1 Las copias de la base de datos nunca se han restaurado

Prioridad altaEsfuerzo S
Evidencia
Hay un volcado diario de PostgreSQL en el mismo servidor y una copia semanal de los discos del proveedor. Nadie ha restaurado ninguna de las dos.
Por qué importa
Si el servidor se pierde, la copia diaria se pierde con él, y no hay forma de saber cuánto tardaríais en volver ni si la copia semanal arranca.
Recomendación
Copia diaria fuera del servidor y en otra ubicación, una de ellas inmutable, y una restauración de prueba en una máquina aislada con el tiempo anotado.
EJ-AUD-2026-01Clasificación: Difusión limitadaEjemplo con datos ficticios

Auditoría de fiabilidad y seguridadExtracto del informe de resultados

Versión 1.0

09/10/2026

Página 5 de 6

2. Los 3 riesgos principales (continuación)

2.2 Solo una persona, que ya no está, conocía el despliegue

Prioridad altaEsfuerzo M
Evidencia
El despliegue se hace por SSH con un script en el servidor. Las claves SSH de la persona que se fue siguen activas y hay una contraseña de administración compartida.
Por qué importa
Un acceso que no se ha retirado es una puerta abierta, y un despliegue que nadie entiende hace que cada cambio sea un riesgo.
Recomendación
Retirar las claves y contraseñas antiguas, accesos nominales con doble factor y un pipeline de GitLab CI que despliegue con revisión y vuelta atrás.

2.3 Las caídas las detectan los clientes

Prioridad mediaEsfuerzo S
Evidencia
No hay monitorización externa ni alertas. En el último trimestre hubo dos caídas que avisaron clientes por correo.
Por qué importa
Cada caída que descubre un cliente dura más y cuesta confianza, justo cuando un cliente nuevo os pide garantías.
Recomendación
Sondas externas de disponibilidad, métricas básicas con Prometheus y alertas de disco, certificados y errores, con un canal claro de aviso.
EJ-AUD-2026-01Clasificación: Difusión limitadaEjemplo con datos ficticios

Auditoría de fiabilidad y seguridadExtracto del informe de resultados

Versión 1.0

09/10/2026

Página 6 de 6

3. Otros puntos para revisar después

  • Versión de PostgreSQL cerca del fin de soporte.
  • Puertos de administración abiertos a internet en uno de los servidores.
  • Sin documentación de cómo reconstruir los servidores desde cero.

4. Plan de mejora priorizado

Primero las copias fuera del servidor con una restauración probada (días), después los accesos y el pipeline de despliegue (1-2 semanas) y, en paralelo, la monitorización. Podéis hacerlo con vuestro equipo o con nosotros, como proyecto o dentro de SRE como servicio.

EJ-AUD-2026-01Clasificación: Difusión limitadaEjemplo con datos ficticios

Ver la auditoría de fiabilidad y seguridad

Contadnos vuestro caso

En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.

Reservar llamada de 20 minutos
WhatsApp