Risque lié à l'infrastructure
Mercury Cloud
Mercury Cloud est une de nos solutions d'hébergement. Ce service est l'hébergeur des machines :
Topaze
Saphire
Opal
Ces 3 machines sont des serveurs de production cruciale pour le fonctionnement du reste de l'infrastructure. Car elles contiennent le VPN, le load-balancer et le Gitlab
Risques
Si l'hébergeur Mercury cloud vient à être totalement indisponible, il nous est impossible de fonctionner.
Sans vpn toutes les zones, c'est-à-dire Plutonium, Titanium et Uranium sont inaccessibles. Et elles ne seront plus joignable entre elles. Et depuis l'extérieur.
C'est un risque peu probable, car MercuryCloud est un hébergeur en ligne cela veut dire que l'hébergeur possède multiple redondance.
Risque lié à Topaze
Topaze est la machine qui contient le VPN. Si topaze est une machine indisponible, cela provoquera des conséquences très importantes Cela provoquerait une indisponibilité totale de l'infrastructure. Tous les clients seraient déconnecté et ne pourrait plus travailler. Et tous les serveurs de production seraient inaccessibles.
Si le temps d'inaccessibilité est trop long ou que la machine ne plus être remise en service. La solution serait de restaurer une sauvegarde de la machine vers une nouvelle machine. Cette manipulation doit être faite par un responsable pour s'assurer que toutes les interconnexions fonctionne correctement.
Si la base de donnée de Netbird ou une autre fonctionnalité de Netbird ne fonctionne pas correctement, il faut contacter le support de Netbird. Cela peut entrainer une indisponibilité de l'infrastructure. Le risque est faible.
Si la machine TOPAZE ce voit subir un déni de service, cela ne provoquera pas nécessairement une indisponibilité totale de l'infrastructure. Car Netbird reliant les hôtes en peer à peer. Cela devrait simplement ralentir le réseau. Néanmoins, les nouvelles connexions à Netbird seront impossible, puisque l'authentifieur ne pourra plus traiter les authentications.
Risque lié à Opal
Opal est la machine qui contient le Xen Orchestra, les docker registry et le Gitlab. Si Opal est une machine indisponible, cela provoquera des conséquences importantes pour les développeurs Car il sera impossible de créer de nouvelles machines virtuelles. Ou de télécharger des images docker. Tout déploiement sera impossible. Ou modification de configuration sur les machines virtuelles ou le cluster Kubernetes. Cela provoquera une indisponibilité partielle de l'infrastructure.
Gitlab
Risque de faire un push erroné
Nos branches de développement sont protégées. Cela veut dire que si un développeur veut faire des modifications, il est obligé de faire une merge request qui doit être approuvé. Pour qu'une merge request soit approuvé la CI doit validé le code. Et le responsable assigné à la merge request doit l'approuver. Cela permet de réduire les risques liés des érreurs de configuration mise en production. Néanmoins, la gravité peut être importante si la merge request est approuvé par erreur. Cela pourrait causer de la perte de données ou une indisponibilité de l'infrastructure. Si cela arrive le responsable de la merge request doit faire un rollback de la merge request.
Risque d'une érreur non détecté par la CI
La CI est configuré pour détecter les erreurs de configuration. Néanmoins, il est possible qu'une erreur de configuration ne soit pas détecté par la CI. Cela pourrait causer une indisponibilité de l'infrastructure. Si cela arrive, il faut faire un rollback de la merge request.
Docker registry
Le docker registry est un service de stockage d'image docker. Il est possible que le docker registry soit corrompu ou qu'il y ait une érreur de configuration. Cela pourrait causer un ralentissement le temps de l'indisponibilité du docker registry.
Risque lié à Saphire
Saphire est la machine qui contient le load balancer. Si Saphire est indisponible tous les services exposés sur le cluster Kubernetes ne seront plus accessible. Le cluster garage ne sera plus accéssible depuis le load-balancer, mais restera accéssible depuis chaque nœud. Cela aura une forte gravité, car énormément de services seront non disponible.
La solution serait de redéployer le load-balancer sur une autre machine.
Labo infra
Le LaboInfra est notre seconde solution d'hébergement. Pour ne pas dépendre de Mercury Cloud, nous utilisons le labo infra comme cloud secondaire.
Si nous perdons les vms sur le LaboInfra, cela n'aura pas d'impact sur l'infrastructure. Car ce sont juste des builders et des machines annexes qui sont redondé à d'autre endroit