Site web
Conception de site web de runbook de service
Le design du runbook d'auth-service réunit responsabilité du service, réponse aux alertes, procédures de déploiement et passations d'incident dans une seule référence opérationnelle facile à parcourir.
Cas d'usage d'un site web de runbook
- Réponse aux incidents d'astreinteTrouver rapidement la gravité, la première réponse et les consignes d'escalade.
- Documentation de responsabilité du serviceExpliquer le périmètre, les dépendances et l'impact du service côté client.
- Workflows de reprise après déploiementRéunir les procédures de mise en production, de rollback et de rotation des clés.
- Conception de runbook opérationnelStructurer des consignes techniques denses pour un usage rapide et répété.
Points forts de la référence opérationnelle
- Contexte du serviceResponsable, version, date de révision et niveau de production apparaissent ensemble.
- Tableau de réponse aux alertesLes seuils relient gravité, signification et première action.
- Blocs de procédureCommandes et mises en garde opérationnelles partagent une même séquence lisible.
- Chronologie d'incidentCinq étapes de réponse structurent les trente premières minutes.
Du contexte du service à la passation d'incident
1 / 5
Conception du runbook d'auth-service
Cet exemple officiel de site web OpenDesign présente le runbook du service d'identité Northwind comme une référence opérationnelle unique. Le titre d'origine est « auth-service », suivi du responsable, de la version, de la date de révision et du statut « TIER 0 · PRODUCTION-CRITICAL ». Cette ouverture établit la responsabilité du service avant que le lecteur n'arrive aux alertes ou aux commandes.
Le résumé du service mentionne l'émission, la validation et la révocation des jetons de session sur le web, le mobile et l'API publique. Il identifie aussi le magasin de mots de passe, les enrôlements TOTP/WebAuthn et le composant d’écriture du journal d’audit. La page est ainsi utile pour s'orienter : un intervenant voit quelles responsabilités côté client et liées à la sécurité relèvent du service avant de choisir une procédure.
Tâches opérationnelles prises en charge
Le design répond à plusieurs tâches liées sans les répartir sur des pages distinctes. Son ordre va du périmètre du service aux dépendances, puis aux alertes, aux procédures, à la couverture d'astreinte et à la réponse aux incidents. Cette séquence évite d'interpréter une alerte isolément : le lecteur apprend d'abord ce que le service gère, puis comment réagir quand une partie est dégradée.
La liste des dépendances répète un motif nom-et-état pour Postgres, Redis, KMS, SES et Pager. Quatre entrées sont marquées saines, tandis que SES · transactional est marqué dégradé. Les états alignés à droite facilitent le balayage visuel, mais ils constituent un instantané du design d'exemple, et non des contrôles de santé en direct démontrés.
| Section | Contenu visible | Usage pour le lecteur |
|---|---|---|
| Résumé du service | Responsable, périmètre, comportement des sessions et dépendances | Établir l'impact et les limites du système |
| Alertes qui peuvent vous réveiller | Seuil, gravité, signification et première réponse | Choisir une première piste d'investigation |
| Procédures courantes | Commandes de déploiement, de rollback, de rotation des clés et de traitement du retard | Suivre un workflow opérationnel nommé |
| Réponse aux incidents | Cinq actions numérotées pour les 30 premières minutes | Coordonner l'accusé de réception, l'atténuation et la passation |
De l'alerte à la procédure
La section des alertes est conçue comme une surface de décision à quatre colonnes : alerte, gravité, signification et première réponse. Par exemple, « auth.login_5xx_rate greater than 1% » est associé à « SEV-1 », à une explication de verrouillage des clients et à la consigne d'examiner les tableaux de bord Postgres et Redis. Le seuil explicite donne à l'intervenant un déclencheur, tandis que le texte apporte l'interprétation ; en contrepartie, dans un vrai runbook, les valeurs d'exemple nécessiteraient encore une source de supervision vérifiée.
La section des procédures change de rythme : des lignes compactes laissent place à de grands blocs avec un titre, une note d'usage, une phrase explicative et un panneau de commandes. « Deploy a new version » indique que le flux est blue/green et attend deux contrôles de santé consécutifs avant la promotion. La séquence de trafic visible, « 10% / 50% / 100% », traduit un déploiement progressif, tandis que le bloc plus grand occupe davantage de hauteur en échange d'une lecture des commandes plus sûre.
Commandes et contraintes
Les blocs de procédure placent l'action et la mise en garde côte à côte. Le rollback est indiqué pour le cas où le taux d'erreur après déploiement dépasse 1 %, tandis que la rotation des clés de signature précise « Schedule with security; never solo ». La procédure du journal d'audit est explicitement liée à l'alerte de retard. Ces associations illustrent un choix utile de conception de l'information : la commande n'est pas présentée comme suffisante en soi, et la condition qui l'entoure définit quand elle a sa place dans le workflow.
Séquence d'incident et limites des capacités
La dernière section, consacrée à la réponse aux incidents, transforme les trente premières minutes en cinq cartes numérotées. La séquence commence par l'accusé de réception sous cinq minutes, ouvre un canal d'incident dédié, exige un point de situation toutes les dix minutes, donne la priorité à l'atténuation et se termine par la passation ou la levée de l'alerte. La numérotation rend l'ordre voulu visible ; la disposition en deux colonnes garde les quatre premières actions compactes, tandis que la cinquième carte ne s'étend que sur son propre contenu.
Il s'agit d'un exemple de site web uniquement conçu pour le design. La page capturée présente visuellement des commandes, des statuts, des noms et des résultats d'exemple tels que « rolled back to v4.7.2 in 38 s », mais elle n'établit pas que ces commandes s'exécutent, que les services sont connectés ou que les résultats opérationnels affichés ont été mesurés. Les adaptations doivent conserver la distinction entre consignes documentées et données d'exécution vérifiées.
Accuser réception de l'alerte
Le design commence par /ack et un délai de réponse de cinq minutes, ce qui établit la première obligation de coordination.
Ouvrir le canal d'incident
La deuxième carte nomme le service et le modèle de titre court utilisés pour créer un espace de réponse dédié.
Publier un point de situation
La troisième carte condense l'impact client, l'état des connaissances et les prochaines vérifications en une mise à jour reproductible.
Atténuer et passer le relais
Les deux dernières cartes donnent la priorité au rollback ou à l'escalade de sécurité, puis définissent la passation et la clôture.
Comment créer une conception de site web de runbook de service dans OpenDesign
Définir le périmètre du service
Commencez par le nom du service, son responsable, sa version, la date de révision, son niveau de production, sa responsabilité côté client et l'état de ses dépendances. Gardez un résumé assez précis pour distinguer l'impact du détail d'implémentation.
Invite suggéréeCréez un site web de runbook de service sombre, conçu d’abord pour ordinateur, pour auth-service sur une plateforme d’identité Northwind. Utilisez une page large et centrée avec un en-tête de service, un badge de niveau, un résumé et un panneau de dépendances sur deux colonnes, un tableau d’alertes, des blocs de procédures, une couverture d’astreinte et cinq cartes numérotées de réponse aux incidents. Utilisez uniquement des données d’exemple ; ne suggérez ni supervision en direct, ni exécution de commandes, ni services connectés, ni résultats mesurés.
Relier les alertes aux actions
Utilisez un tableau avec le nom de l'alerte, la gravité, la signification et la première réponse. Conservez le lien entre des seuils comme auth.login_5xx_rate supérieur à 1 % et l'action qui en découle, tout en indiquant que les valeurs sont illustratives tant qu'elles ne sont pas vérifiées.
Améliorer la lisibilité des procédures
Donnez à chaque procédure une condition, une mise en garde ou une indication de moment d’exécution avant son bloc de commandes. Vérifiez que la promotion blue/green, le rollback, la rotation des clés de signature et le drainage des journaux d'audit restent des workflows distincts plutôt qu'un seul bloc de code indifférencié.
Vérifier l'ordre de l'incident
Relisez les cinq cartes de réponse comme une séquence chronométrée : accuser réception, ouvrir le canal, publier un point de situation, atténuer, puis passer le relais ou lever l'alerte. Vérifiez que la mise en page reste lisible quand les cartes s'empilent sur de petits écrans.
Exporter et obtenir un lien de partage
Exportez votre design finalisé, puis utilisez Partager dans OpenDesign pour obtenir un lien de partage. Ouvrez le lien dans une fenêtre de navigateur distincte et vérifiez que la version souhaitée ainsi que ses ressources sont disponibles avant de l'envoyer.
Conception de site web pour studio de design IA
La conception du site web de studio de design IA d’OpenDesign transforme le concept d’un studio local-first en landing page éditoriale, où les compétences, les expérimentations et la méthode sont faciles à parcourir.
Site web
Conception de site web d’infrastructure d’IA
Un concept de page d’accueil d’infrastructure d’IA tout en douceur, avec des exemples de métriques d’exécution, des cartes de fonctionnalités imbriquées, des animations subtiles et une unique invitation commerciale.
Site web
Conception de site web de visite nocturne de Bianjing
Un voyage nocturne interactif à travers une Bianjing imaginaire de l’époque des Song, associant une ville fluviale persistante, la poésie, les lanternes et un rythme narratif multilingue par chapitres.
Site web
Conception de site web de journal brutaliste
La conception de site web de journal brutaliste transforme un numéro en forme d’imprimé en un système de lecture web lisible, en associant une typographie audacieuse à une structure éditoriale mesurée.
Site web