Sitio web
Diseño web de runbook de servicio
El diseño del runbook de auth-service reúne en una sola referencia operativa fácil de escanear la titularidad del servicio, la respuesta a alertas, los procedimientos de despliegue y los traspasos de incidentes.
Casos de uso del sitio web de runbook
- Respuesta a incidentes de guardiaEncuentra rápido la severidad, la primera respuesta y la guía de escalado.
- Documentación de titularidad del servicioExplica el alcance, las dependencias y el impacto del servicio de cara al cliente.
- Flujos de recuperación tras desplieguesReúne los procedimientos de lanzamiento, rollback y rotación de claves.
- Diseño de runbooks operativosEstructura guías técnicas densas para un uso rápido y repetido.
Aspectos destacados de la referencia operativa
- Contexto del servicioLa titularidad, la versión, la fecha de revisión y el nivel de producción aparecen juntos.
- Tabla de respuesta a alertasLos umbrales conectan severidad, significado y primera acción.
- Bloques de procedimientosLos comandos y las precauciones operativas comparten una secuencia legible.
- Cronología del incidenteCinco pasos de respuesta organizan los primeros treinta minutos.
Del contexto del servicio al traspaso del incidente
1 / 5
Diseño del runbook de auth-service
Este ejemplo web oficial de OpenDesign presenta un runbook del servicio de identidad de Northwind como una única referencia operativa. El encabezado creado es «auth-service», seguido de la titularidad, la versión, la fecha de revisión y el estado «TIER 0 · PRODUCTION-CRITICAL». Esa apertura establece la responsabilidad del servicio antes de que el lector llegue a las alertas o los comandos.
El resumen del servicio nombra la emisión, validación y revocación de tokens de sesión en web, móvil y la API pública. También identifica el almacén de contraseñas, las inscripciones TOTP/WebAuthn y el componente de escritura del registro de auditoría. Esto hace que la página sirva para orientarse: quien responde puede ver qué responsabilidades de cara al cliente y de seguridad corresponden al servicio antes de elegir un procedimiento.
Tareas operativas que apoya
El diseño atiende varias tareas relacionadas sin dividirlas en páginas separadas. Su orden va del alcance del servicio a las dependencias, y de ahí a las alertas, los procedimientos, la cobertura de guardia y la respuesta a incidentes. Esa secuencia reduce la necesidad de interpretar una alerta de forma aislada: primero se aprende qué le corresponde al servicio y después cómo responder cuando una parte falla.
La lista de dependencias repite un patrón de nombre y estado para Postgres, Redis, KMS, SES y Pager. Cuatro entradas están marcadas como healthy, mientras que SES · transactional figura como degraded. Los estados alineados a la derecha facilitan el escaneo, pero son una instantánea del diseño de ejemplo, no comprobaciones de estado en vivo demostradas.
| Sección | Contenido visible | Uso del lector |
|---|---|---|
| Resumen del servicio | Titularidad, alcance, comportamiento de las sesiones y dependencias | Establecer el impacto y los límites del sistema |
| Alertas que podrían despertarte | Umbral, severidad, significado y primera respuesta | Elegir una ruta de investigación inicial |
| Procedimientos habituales | Comandos de despliegue, rollback, rotación de claves y backlog | Seguir un flujo operativo con nombre |
| Respuesta a incidentes | Cinco acciones numeradas para los primeros 30 minutos | Coordinar el acuse de recibo, la mitigación y el traspaso |
De la alerta al procedimiento
La sección de alertas está concebida como una superficie de decisión de cuatro columnas: alerta, severidad, qué significa y primera respuesta. Por ejemplo, «auth.login_5xx_rate greater than 1%» se empareja con «SEV-1», una explicación de bloqueo de clientes y la indicación de revisar los paneles de Postgres y Redis. El umbral explícito da a quien responde un disparador, mientras que la prosa aporta la interpretación; la contrapartida es que, en un runbook real, los valores de ejemplo seguirían necesitando una fuente de monitorización verificada.
La sección de procedimientos cambia el ritmo de filas compactas a bloques grandes con un encabezado, una nota de uso, una frase explicativa y un panel de comandos. «Deploy a new version» indica que el flujo es blue/green y que espera dos healthchecks consecutivos antes de la promoción. La secuencia de tráfico visible, «10% / 50% / 100%», comunica un despliegue escalonado, mientras que el bloque más grande consume más espacio vertical a cambio de una lectura más segura a nivel de comando.
Comandos y restricciones
Los bloques de procedimientos mantienen la acción y la precaución juntas. El rollback se etiqueta para usarse cuando la tasa de errores posterior al despliegue supera el 1 %, mientras que la rotación de claves de firma dice «Schedule with security; never solo». El procedimiento del registro de auditoría está vinculado explícitamente a la alerta de backlog. Estos emparejamientos muestran una buena decisión de diseño de información: el comando no se presenta como suficiente por sí solo, y la condición que lo rodea define cuándo corresponde al flujo.
Secuencia del incidente y límite de capacidades
La sección final de respuesta a incidentes convierte los primeros treinta minutos en cinco tarjetas numeradas. La secuencia comienza con el acuse de recibo en cinco minutos, abre un canal de incidente dedicado, exige un resumen del estado cada diez minutos, prioriza la mitigación y termina con el traspaso o el cierre. La numeración hace visible el orden previsto; la disposición a dos columnas mantiene compactas las cuatro primeras acciones, mientras que la quinta tarjeta ocupa solo el espacio de su propio contenido.
Este es un ejemplo web solo de diseño. La página capturada presenta visiblemente comandos, estados, nombres y resultados de ejemplo como «rolled back to v4.7.2 in 38 s», pero no demuestra que esos comandos se ejecuten, que los servicios estén conectados ni que los resultados operativos mostrados se hayan medido. Las adaptaciones deben conservar la distinción entre la guía documentada y los datos de ejecución verificados.
Acusar recibo de la alerta
El diseño empieza con /ack y una ventana de respuesta de cinco minutos, que establece la primera obligación de coordinación.
Abrir el canal del incidente
La segunda tarjeta nombra el servicio y el patrón de título corto usado para crear un espacio de respuesta dedicado.
Publicar un resumen del estado
La tercera tarjeta condensa el impacto en los clientes, lo que se sabe hasta el momento y las próximas comprobaciones en una actualización repetible.
Mitigar y traspasar
Las dos últimas tarjetas priorizan el rollback o el escalado de seguridad, y después definen el traspaso y el cierre.
Cómo crear un diseño web de runbook de servicio en OpenDesign
Define los límites del servicio
Empieza con el nombre del servicio, la titularidad, la versión, la fecha de revisión, el nivel de producción, la responsabilidad de cara al cliente y el estado de las dependencias. Mantén el resumen lo bastante específico para distinguir el impacto del detalle de implementación.
Prompt sugeridoCrea un sitio web de runbook de servicio para auth-service, en una plataforma de identidad de Northwind, con tema oscuro y enfoque desktop-first. Usa una página ancha y centrada con una cabecera de servicio, una insignia de nivel, un resumen a dos columnas con un panel de dependencias, una tabla de alertas, bloques de procedimientos, cobertura de guardia y cinco tarjetas numeradas de respuesta a incidentes. Usa solo datos de ejemplo; no insinúes monitorización en vivo, ejecución de comandos, servicios conectados ni resultados medidos.
Conecta las alertas con las acciones
Usa una tabla con nombre de la alerta, severidad, significado y primera respuesta. Conserva la relación entre umbrales como auth.login_5xx_rate mayor que 1 % y la acción que sigue, y etiqueta los valores como ilustrativos hasta que se verifiquen.
Refina la legibilidad de los procedimientos
Da a cada procedimiento una condición, una advertencia o una nota de tiempo antes de su panel de comandos. Comprueba que la promoción blue/green, el rollback, la rotación de claves de firma y el vaciado del registro de auditoría sigan siendo flujos distintos y no un único bloque de código indiferenciado.
Comprueba el orden del incidente
Revisa las cinco tarjetas de respuesta como una secuencia temporizada: acusar recibo, abrir el canal, publicar un resumen del estado, mitigar y luego traspasar o dar por cerrado. Confirma que el diseño sigue siendo legible cuando las tarjetas se apilan en pantallas más pequeñas.
Exportar y obtener un enlace para compartir
Exporta tu diseño terminado y luego usa Compartir en OpenDesign para obtener un enlace. Abre el enlace en una ventana del navegador independiente y comprueba que la versión prevista y sus recursos estén disponibles antes de enviarlo.
Diseño web para estudios de diseño de IA
El diseño web para estudios de diseño de IA de OpenDesign convierte el concepto de un estudio local-first en una landing page editorial que facilita consultar habilidades, experimentos y método.
Sitio web
Diseño de sitios web de infraestructura de IA
Un concepto de landing page de infraestructura de IA de estilo suave, con métricas de ejecución de ejemplo, tarjetas de funciones anidadas, movimiento sutil y una única invitación comercial.
Sitio web
Diseño de sitio web para recorridos nocturnos por Bianjing
Un recorrido nocturno interactivo por una Bianjing imaginada de la era Song, que combina una ciudad fluvial persistente, poesía, faroles y un ritmo de capítulos multilingüe.
Sitio web
Diseño de sitio web de revista brutalista
Diseño de sitio web de revista brutalista convierte una edición con forma de publicación impresa en un sistema web de lectura legible, combinando tipografía contundente con una estructura editorial medida.
Sitio web