Skip to content

Accueil

Ce site documente l'infrastructure de ComputableFacts.

Classement des événements

J'ai ajouté des event qui correspondent aux modifications apportées à l'infra. Soit des modifications prévues, soit des modifications dues à des incidents.

J'ai défini 4 types d'événement en fonction de leur gravité :

  • critical
    • Impact très élevé : cela affecte un grand nombre d'utilisateurs ou de services
    • Exemples :
      • un site web utilisé par nos clients ne répond plus du tout
      • un service comme Keycloak est coupé empêchant les utilisateurs de s'authentifier sur les sites dont ils ont besoin
  • significant
    • Impact significatif : cela affecte un nombre limité d'utilisateurs ou de services
    • Exemples :
      • un site web utilisé par un seul de nos client ne répond plus
      • un service comme l'envoi de mail ne fonctionne plus mais les utilisateurs peuvent utiliser le reste de l'application
  • minor
    • Impact faible : cela affecte un petit nombre d'utilisateurs ou de services
    • Exemples :
      • un problème de performance mineur sur un serveur
      • une erreur logicielle qui affecte uniquement un utilisateur
  • info
    • Impact nul : cela n'a aucun impact sur les utilisateurs ou les services
    • Exemples :
      • modification de l'infrastructure pour déployer une nouvelle application
      • un message d'erreur qui apparaît sur un serveur, mais qui n'affecte pas les utilisateurs
      • un changement de configuration mineur sur un serveur

Classement des entités

Je vais m'inspirer des entités définies par Backstage. Et faire le maximum pour avoir un YAML "compatible".

Les entités sont donc :

  • Resource
    • C'est un morceau d'infrastructure nécessaire pour faire fonctionner un system.
    • Des exemples de types pour une ressource sont : database, s3-bucket, cluster, server
    • Elle a des dépendances listées grâce à dependsOn
  • Component
    • C'est un logiciel. A priori développé avec une repo où se trouve le code
    • Les 3 types de composant les plus courants sont : service, website, library
    • Il a des dépendances listées grâce à dependsOn
    • Il expose les API listées dans providesApis et consomme les API listées dans consumesApis
    • Il peut être un sous-composants du composant dans subcomponentof
  • API
    • Elle décrit l'interface exposée par un composant
    • 4 types possibles dont OpenAPI
  • System
    • Il contient des resources et des composants (les ressources et les composants ont un champ spec.system)
    • Il peut exposer ou consommer une ou plusieurs API
  • Domain
    • Il regroupe plusieurs systèmes (les systèmes ont un champs spec.domain)

Backstage définit d'autres entités comme User, Group qui permettent de définir qui est le propriétaire des autres entités. Je pense que nous n'avons pas besoin de ça. Sauf, peut-être, pour regrouper les ressources d'un même client (en faisant un groupe pour chaque client).