Evidencias operativas diseñadas para verificarse
Este centro de preproducción muestra cómo VPSEverywhere.com puede publicar endpoints Looking Glass, benchmarks reproducibles, latencias medidas, identidad de red, estado de los componentes, historial de incidentes y un changelog de despliegue. Todas las cifras mostradas actualmente son DATOS DE EJEMPLO ficticios, NO VERIFICADOS, claramente identificados y excluidos de la indexación hasta que se sustituyan y se comprueben.
Datos clave
- Estado actual de publicación
- DATOS DE EJEMPLO — no constituyen evidencia de un servicio activo
- Direcciones Looking Glass
- Rangos de documentación de IANA que no pueden representar endpoints de producción
- Regla de benchmark
- Publicar el comando, la duración, el tamaño de la muestra, la mediana y la fecha de la prueba
- Protección de indexación
- Noindex y exclusión del sitemap hasta verificar el archivo de evidencias
SUSTITUIR todos los valores antes de publicar
Estos valores son solo una plantilla visual: no son mediciones, historial de disponibilidad, incidentes ni afirmaciones reales sobre instalaciones, carriers o redes. Se utilizan deliberadamente rangos IP reservados para documentación y ASN privados.
Looking Glass
La versión de producción debe ofrecer direcciones de prueba accesibles y un endpoint controlado por el proveedor sin conceder acceso administrativo.
https://lg.example.invalid192.0.2.102001:db8::10Comandos reproducibles
- ICMP IPv4
ping -c 5 192.0.2.10 - ICMP IPv6
ping -6 -c 5 2001:db8::10 - Route IPv4
traceroute 192.0.2.10 - Route IPv6
traceroute -6 2001:db8::10
Resultados de los benchmarks
Los DATOS DE EJEMPLO NO VERIFICADOS muestran únicamente el diseño comparativo previsto. Publica medianas obtenidas en pruebas repetidas y conserva disponibles los resultados sin procesar.
Metodología publicada
sysbench cpu --threads=4 --time=60 runfio --name=vpse-4k --rw=randrw --rwmixread=70 --bs=4k --direct=1 --size=4G --numjobs=8 --runtime=60 --time_basediperf3 -c TARGET -P 4 -t 30ping -c 20 TARGETLatencia medida
La matriz de ejemplo utiliza valores ficticios y NO VERIFICADOS de mediana, p95 y pérdida de paquetes. Las mediciones reales deben indicar el origen, el destino, el periodo y el método de sondeo.
| Origen | Destino | Mediana | p95 | Pérdida de paquetes | |
|---|---|---|---|---|---|
| HEL-1 | BUH-1 | 39,4 ms | 44,8 ms | 0,1% | DATOS DE EJEMPLO — NO VERIFICADOS |
| HEL-1 | RKV-1 | 42,8 ms | 48,1 ms | 0% | DATOS DE EJEMPLO — NO VERIFICADOS |
| HEL-1 | AMS-1 | 24,7 ms | 28,9 ms | 0% | DATOS DE EJEMPLO — NO VERIFICADOS |
| HEL-1 | ZRH-1 | 31,8 ms | 36,6 ms | 0,1% | DATOS DE EJEMPLO — NO VERIFICADOS |
| BUH-1 | RKV-1 | 67,2 ms | 74,5 ms | 0,2% | DATOS DE EJEMPLO — NO VERIFICADOS |
| BUH-1 | AMS-1 | 34,2 ms | 38,8 ms | 0% | DATOS DE EJEMPLO — NO VERIFICADOS |
| BUH-1 | ZRH-1 | 27,5 ms | 31,7 ms | 0,1% | DATOS DE EJEMPLO — NO VERIFICADOS |
| RKV-1 | AMS-1 | 34,9 ms | 40,2 ms | 0% | DATOS DE EJEMPLO — NO VERIFICADOS |
| RKV-1 | ZRH-1 | 45,6 ms | 51,9 ms | 0,1% | DATOS DE EJEMPLO — NO VERIFICADOS |
| AMS-1 | ZRH-1 | 11,7 ms | 14,3 ms | 0% | DATOS DE EJEMPLO — NO VERIFICADOS |
Información de red
El nombre de una ciudad no es una prueba. Publica la instalación, el ASN de origen, los prefijos anunciados, las redes upstream y una sonda enrutable para cada región activa.
- Instalación
- Ejemplo — sustituir
- ASN de origen
AS64512- Prefijos publicados
192.0.2.0/242001:db8:10::/48- Redes upstream
- Ejemplo — sustituir
- Instalación
- Ejemplo — sustituir
- ASN de origen
AS64513- Prefijos publicados
192.0.2.0/242001:db8:20::/48- Redes upstream
- Ejemplo — sustituir
- Instalación
- Ejemplo — sustituir
- ASN de origen
AS64514- Prefijos publicados
198.51.100.0/242001:db8:30::/48- Redes upstream
- Ejemplo — sustituir
- Instalación
- Ejemplo — sustituir
- ASN de origen
AS64515- Prefijos publicados
198.51.100.0/242001:db8:40::/48- Redes upstream
- Ejemplo — sustituir
- Instalación
- Ejemplo — sustituir
- ASN de origen
AS64516- Prefijos publicados
203.0.113.0/242001:db8:50::/48- Redes upstream
- Ejemplo — sustituir
Estado público de los componentes
Los porcentajes de disponibilidad son DATOS DE EJEMPLO NO VERIFICADOS hasta que estén respaldados por monitorización externa y una ventana de cálculo documentada.
| Componente | Estado | Disponibilidad de 30 días | |
|---|---|---|---|
| Sitio web público | Ejemplo — sustituir | 99,98% | DATOS DE EJEMPLO — NO VERIFICADOS |
| Panel de control | Ejemplo — sustituir | 99,94% | DATOS DE EJEMPLO — NO VERIFICADOS |
| API | Ejemplo — sustituir | 99,91% | DATOS DE EJEMPLO — NO VERIFICADOS |
| Red regional | Ejemplo — sustituir | 99,97% | DATOS DE EJEMPLO — NO VERIFICADOS |
| Pasarela de pago | Ejemplo — sustituir | 99,88% | DATOS DE EJEMPLO — NO VERIFICADOS |
Historial de incidentes
Las entradas siguientes solo muestran la cronología y el nivel de detalle esperados; ninguno de estos incidentes ficticios ocurrió.
DEMO-INC-2026-002DATOS DE EJEMPLO — NO VERIFICADOSDEMO — Pérdida elevada de paquetes en el edge AMS
Impacto: Impacto ficticio: latencia intermitente en un subconjunto de rutas
Solo DATOS DE EJEMPLO: el tráfico se habría desviado a una ruta secundaria mientras se investigaba un problema upstream simulado.
- Inicio
- Resolución
DEMO-INC-2026-001DATOS DE EJEMPLO — NO VERIFICADOSDEMO — Retraso en el procesamiento de webhooks de pago
Impacto: Impacto ficticio: cola de aprovisionamiento retrasada tras confirmar el pago
Solo DATOS DE EJEMPLO: los callbacks en cola se habrían reproducido después de la recuperación simulada del worker.
- Inicio
- Resolución
Changelog de despliegues
Utiliza esta cronología para cambios reales y fechados en producción. No antedates versiones ni insinúes un historial que no existió.
| Versión | Fecha | Cambio | |
|---|---|---|---|
0.3.0-demo | DEMO — Se añadió el diseño de evidencias operativas y el modelo de datos JSON editable. | DATOS DE EJEMPLO — NO VERIFICADOS | |
0.2.0-demo | DEMO — Se añadieron tarjetas de ejemplo de latencia y metodología de benchmark. | DATOS DE EJEMPLO — NO VERIFICADOS | |
0.1.0-demo | DEMO — Se creó el primer prototipo del centro de transparencia. | DATOS DE EJEMPLO — NO VERIFICADOS |
Por qué la demostración no puede confundirse con una prueba
Las cifras inventadas pueden explicar un diseño, pero nunca deben presentarse como evidencia de disponibilidad, latencia, capacidad, incidentes, instalaciones o red. Por ello, esta versión utiliza rangos IP reservados, ASN privados, marcadores de sustitución, una advertencia destacada y un indicador de verificación específico. La ruta de transparencia permanece en noindex y fuera del sitemap mientras quede cualquier marcador de demostración.
El estado verificado es una decisión de lanzamiento, no un cambio cosmético. Una persona competente debe comprobar las mediciones de origen, el periodo, los comandos, la cobertura de monitorización, la propiedad de la infraestructura y la redacción antes de marcar el archivo de datos como verificado. Si un dato no puede demostrarse, elimina el campo en lugar de estimarlo.
- No sustituyas la advertencia por un aviso menos explícito.
- No utilices direcciones privadas o de documentación como endpoints de clientes.
- Conserva los archivos de mediciones sin procesar y los comandos exactos utilizados.
Un Looking Glass útil ofrece pruebas delimitadas
Un Looking Glass de producción debe permitir a un posible cliente probar la conectividad sin exponer una interfaz de administración. Publica direcciones estables de sonda IPv4 e IPv6, opciones de DNS, ping y traceroute, un objeto pequeño de descarga cuando corresponda, el ASN de origen y un límite de uso resistente a abusos. Indica qué región representa cada sonda.
El endpoint de ejemplo utiliza el dominio reservado .invalid y prefijos de documentación de IANA, por lo que no puede confundirse con un servicio funcional. Cuando se conecten endpoints reales, pruébalos desde varias redes independientes y mantén la página útil sin exigir una cuenta.
- Separa los endpoints públicos de diagnóstico de las redes de clientes y administración.
- Registra lo mínimo, limita el uso de forma predecible e informa de la retención.
- Vuelve a probar cada dirección después de cambios de routing o datacenter.
Los benchmarks necesitan un método, no una cifra llamativa
Un resultado reproducible identifica la configuración del VPS, la imagen del sistema operativo, el kernel, la versión del benchmark, el comando, la duración, la concurrencia, el número de muestras, la regla de agregación, la fecha y la región. Las medianas de varias ejecuciones son más informativas que un único mejor resultado. Las salidas sin procesar deben poder descargarse para que el resumen sea verificable.
Las pruebas de CPU, almacenamiento y red responden a preguntas diferentes y pueden afectar a cargas vecinas. Utiliza pruebas acotadas, respeta los límites del proveedor y explica que el rendimiento de un host compartido puede variar. La tabla de ejemplo es deliberadamente plausible para mostrar la interfaz, pero carece de valor probatorio.
- Publica tanto el comando como los datos pertinentes del entorno.
- Utiliza la misma configuración y duración de prueba en todas las regiones.
- Conserva las ejecuciones lentas o fallidas en el registro bruto en vez de elegir solo las mejores.
La latencia y la identidad de red deben poder medirse
La latencia depende de ambos endpoints, del routing, la congestión, la hora y el protocolo. Una matriz rigurosa indica el origen y el destino, el periodo de muestreo, el número de sondas, la mediana, el p95 y la pérdida de paquetes. Las mediciones realizadas solo desde la red del proveedor no deben generalizarse a todas las redes de acceso de los clientes.
La información de red debe distinguir al proveedor contratante, al operador de la instalación, al titular de las IP, al ASN de origen, a los carriers de tránsito y a los prefijos anunciados. Estos roles pueden diferir. Publica datos actuales de cada región activa y actualízalos cuando cambien el routing o los proveedores.
- Mide desde redes similares a las de la audiencia prevista.
- Muestra un percentil y la pérdida, no solo una media.
- Vincula las afirmaciones sobre instalaciones y ASN con registros verificables de forma independiente.
El historial de estado debe explicar el impacto y la recuperación
Una página pública de estado es creíble cuando los estados de los componentes proceden de la monitorización, se define la ventana de cálculo, se distingue el mantenimiento de los incidentes y un servicio degradado no queda oculto tras un indicador general verde. Cada incidente debe registrar la detección, el impacto al cliente, las actualizaciones, la mitigación, la resolución y, cuando corresponda, el seguimiento.
Los dos incidentes de esta demostración son ficticios y llevan identificadores DEMO. Sustitúyelos únicamente por eventos reales; un historial vacío es más honesto que una trayectoria inventada. Los porcentajes de disponibilidad deben calcularse a partir del historial de eventos subyacente, no escribirse directamente en una página comercial.
- Utiliza sondas externas además de comprobaciones internas de salud.
- Publica las marcas de tiempo con una zona horaria clara.
- Corrige abiertamente las entradas de incidentes cuando nuevas evidencias cambien el diagnóstico.
Un changelog es un registro factual de despliegues
Registra los cambios de producto, red, políticas, seguridad y fiabilidad visibles para los clientes con la fecha en la que realmente llegaron a producción. Un changelog debe ayudar a evaluar cambios y compatibilidad, no crear la apariencia de una empresa más antigua. Agrupa los cambios relacionados y enlaza notas de migración o incidentes más detalladas cuando resulte útil.
Las versiones de demostración terminan en -demo y no son historial de producto. Elimínalas cuando exista el primer registro de despliegue real. No rellenes versiones inventadas con fechas pasadas, no presentes prototipos como hitos de producción ni publiques una fecha que no esté respaldada por registros de despliegue.
- Utiliza la fecha real del despliegue en producción.
- Separa el trabajo planificado del trabajo entregado.
- Conserva las correcciones y respeta los límites de divulgación relacionados con la seguridad.
Preguntas frecuentes
¿Son reales los valores actuales de benchmark y latencia?
No. Todos los valores actuales son DATOS DE EJEMPLO ficticios y NO VERIFICADOS. Las direcciones reservadas, los ASN privados, los avisos visibles, noindex y la exclusión del sitemap impiden que se presenten como evidencias de un servicio activo.
¿Qué debe ocurrir antes de que esta página pueda indexarse?
Sustituye cada ejemplo por datos medidos y comprobados de forma independiente, elimina todos los marcadores de demostración, valida el JSON, cambia su estado a verificado, obtén una aprobación humana y solo entonces activa el indicador de verificación en producción.
¿Debe un operador publicar un historial de incidentes vacío?
Sí, si no se produjo ningún incidente que cumpla la definición durante el periodo indicado. Publica el inicio del periodo de medición y la definición de incidente; nunca inventes eventos ni un historial de disponibilidad para que el servicio parezca consolidado.