# Fiabilidad, estado e incidentes

> Dónde se ejecuta Anpheros, qué se monitoriza, copias de seguridad diarias y recuperación en un punto específico en el tiempo, cómo se comunican los incidentes, exportación y eliminación de datos, y qué no está implementado aún (sin SLA, sin página de estado pública).

Source: https://developers.anpheros.com/es/guides/reliability

**Lo que Anpheros hace hoy para mantener la API disponible y sus datos recuperables, cómo se entera de los problemas y lo que
aún no está implementado.** Anpheros Platform está en beta privada; esta página describe la configuración actual, no los objetivos presentados como garantías.

## Alojamiento

| | Hoy |
|---|---|
| Región | Solo Unión Europea: Google Cloud `europe-west4` (Países Bajos), detrás de un borde de Cloudflare |
| API | Cloud Run, escalado automático hasta 3 instancias; FHIR R4 en `/fhir/R4`, REST en `/v1` |
| Base de datos | PostgreSQL administrada en una **única zona**, sin conmutación por error automática: una interrupción de zona es una interrupción total |
| Sandbox | una base de datos separada; las claves de sandbox (`sk_test_`) no pueden acceder a datos de producción |
| Nivel de servicio | mejor esfuerzo; **sin SLA contractual** durante la beta |

## Monitorización

- Las **comprobaciones de tiempo de actividad** (uptime checks) llaman al endpoint de salud de la plataforma desde tres regiones; cuando deja de responder, el equipo es alertado por correo electrónico.
- Las **alertas** también se activan ante errores de servidor por encima del 5 %, respuestas lentas (p95 por encima de 2 segundos durante 10 minutos), una alta proporción de respuestas 4xx, agotamiento del pool de la base de datos, fallos al escribir el registro de auditoría, una cadena de auditoría rota, reutilización de un token de actualización OAuth y endpoints de webhook que fueron deshabilitados tras fallos repetidos.
- **Todavía no hay una página de estado pública.** Las comprobaciones anteriores son internas. Una página de estado solo se publicará cuando pueda mostrar mediciones reales de estas comprobaciones, no un "todos los sistemas operativos" escrito a mano.

## Copias de seguridad y recuperación

- **Base de datos:** copia de seguridad automatizada todos los días a las 02:00 UTC, se conservan 7 copias, además de **recuperación a nivel de punto en el tiempo** para los últimos 7 días; la protección contra eliminación está activada.
- **Documentos:** versionado de objetos y eliminación lógica de 7 días en el bucket de almacenamiento, cifrado con una clave gestionada por el cliente.
- **Registro de auditoría:** una copia solo de adición fuera de la base de datos, verificada diariamente para detectar lagunas y manipulaciones.
- **Simulacro de restauración:** el 20 de septiembre de 2026, la base de datos de producción se clonó a un punto de tres minutos en el pasado; el clon estuvo utilizable después de unos 10 minutos y sus recuentos de registros coincidieron con la fuente. Una restauración completa también requiere una reimplantación, unos 5 minutos adicionales.

## Cuando algo sale mal

1. La alerta llega al equipo; las solicitudes afectadas se rastrean por su **ID de solicitud** (cada respuesta lleva una
   cabecera `Anpheros-Request-Id`; cítela cuando nos escriba).
2. Se revoca primero una credencial filtrada; si la integridad de los datos está en duda, se detienen las escrituras y la base de datos se restaura
   a un punto anterior al evento.
3. **Se informa directamente a las organizaciones cuyos datos se vieron afectados**, dentro del plazo de su acuerdo de procesamiento de datos;
   para una violación de datos personales, dentro de las 72 horas posteriores a su conocimiento, según lo exige el GDPR.
4. Se realiza un post-mortem dentro de los 5 días hábiles siguientes.

Los cambios en la API, incluido el endurecimiento relacionado con la seguridad, se anuncian en el [registro de cambios](https://developers.anpheros.com/es/guides/versioning).

## Tus datos: exportación, retención y eliminación

- **Exportación:** los registros son HL7 FHIR R4 estándar; `Patient/$everything` devuelve el registro completo de un paciente como un FHIR bundle,
  y `$summary` un International Patient Summary. Nada está en un formato propietario.
- **Eliminación:** una organización puede eliminar los recursos que escribió (FHIR `DELETE`, o `DELETE` en recursos `/v1`); las versiones
  anteriores permanecen en el historial del recurso. Lo que sucede con los datos de producción cuando finaliza un plan se detalla en los [términos de precios](https://developers.anpheros.com/es/guides/pricing).
- **Auditoría:** cada lectura y escritura se registra y es visible para el paciente. Las filas de auditoría se conservan actualmente indefinidamente; un
  período de retención por tipo de registro es una decisión legal pendiente.

## Aún no implementado

- conmutación por error automática entre zonas y un SLA contractual;
- una página de estado pública con tiempo de actividad medido;
- certificaciones formales (por ejemplo, ISO 27001 o SOC 2): no se reclama ninguna.

Estos se enumeran para que pueda planificar en consecuencia. Preguntas: contact@anpheros.com.

## Relacionado

- [Seguridad, privacidad y residencia de datos](https://developers.anpheros.com/es/guides/security)
- [Límites y límites de tasa](https://developers.anpheros.com/es/guides/limits)
- [Versionado y registro de cambios](https://developers.anpheros.com/es/guides/versioning)
- [Precios](https://developers.anpheros.com/es/guides/pricing)