Souvent le parent pauvre de l’architecture et de l’analyse, la partie opérations est pourtant absolument essentielle et nécessite une vraie réflexion. En effet, la façon dont un système va être supervisé, mesuré, sauvegardé et ordonnancé va faire fortement varier sa résilience et son agilité.
Comme pour les autres chapitres, je vous propose de zoomer sur chacun des aspects en vous proposant les bonnes questions à se poser et à documenter. Ici, vous parlerez principalement avec les responsables des différents services de production.
La supervision
On va identifier les points de supervision c’est à dire les éléments à surveiller sur lesquels on va déclencher des alertes en cas de déviation. Typiquement, on va suivre la disponibilité ou les performances d’une machine virtuelle à travers un ping, un test http ou le suivi d’un journal en recherchant une entrée précise (par exemple ERROR ou WARNING).
La finalité de la supervision est double : résoudre le plus rapidement les incidents, en ayant déjà identifié ses causes potentielles et si possible, les éviter. Côté architecture, on va donc s’assurer que les principaux aspects infrastructure (perte de réseau par exemple), applicatif (réponse d’un service web) et même fonctionnel (présence d’utilisateurs) sont couverts.
Nous allons également décrire à quels systèmes de supervision notre système est raccordé. Il y en a souvent plusieurs qui répondent à des cas d’usage et surtout des domaines de responsabilité différents. Les alertes ne seront en effet pas traitées de la même manière ni par les mêmes équipes si elles sont techniques ou fonctionnelles. On pourra également décrire par quelle méthode les métriques à superviser sont collectées : communauté snmp, agent applicatif (Zabbix ou syslog par exemple)...
Selon les contextes, la réflexion autour de la supervision doit aller plus loin : pour chaque point de supervision, on définit les seuils auxquels les alarmes doivent se déclencher, les actions à entreprendre et qui devra les faire.
La métrologie
L’architecte, avec l’aide des experts des différentes couches, doit aider à identifier quelles sont les caractéristiques de ces métriques. Leur nature bien entendu (ressources mémoire allouées à un processus par exemple) mais aussi la fréquence de collecte et la durée de rétention.
Dans un monde big data où on est noyé par la quantité d’information, ces choix sont critiques pour permettre une exploitation simplifiée des données sans se perdre dans un trop plein. Ma recommandation est de partir à minima des quelques métriques pertinentes, qu’on va être sûr d’utiliser, et d’en ajouter au fur et à mesure que les besoins émergent.
A noter également, la métrologie ne sert pas que les aspects techniques : on va pouvoir mesurer les engagements de services (SLA) à travers ce service, en collectant par exemple les durées d’indisponibilités ou le temps de réponse de la page d’accueil d’un site web. Ces données mesurées serviront de base concrète et permettront de rendre objectifs des ressentis utilisateurs—« Votre application est tout le temps indisponible! ».
La sauvegarde
Rassurez vous, on approche de la fin de ce chapitre très théorique :)
Est-ce que vous vous rappelez des différentes caractéristiques qui définissent les contraintes d’une architecture ? L’une d’entre elle est la PDMA ou RPO, qui vous indique la quantité de données qui peuvent être perdues sans que ce soit désastreux pour le métier.
La donnée perdue sera par exemple celle que l’utilisateur aura entrée avant qu’une sauvegarde ait eu lieu (cas où il n’existe pas de réplication temps réel des données).
Le seul moyen de garantir une PDMA est de sauvegarder ses données, c’est à dire de physiquement les copier sur un medium externe à son système.
Il existe plusieurs façon de s’en assurer : bandes magnétiques (oui oui, encore aujourd'hui! ), baie de disque dédiée, externalisation cloud…
Cette politique de sauvegarde décrit la fréquence et la rétention des sauvegardes réalisées.
Classiquement plus la fréquence est élevée, plus la rétention est courte. Ces choix vont bien entendu avoir un impact sur les coûts et sur les fenêtres de sauvegarde à prévoir, c’est à dire des périodes où le système est peu ou pas utilisé (selon la méthode de sauvegarde choisie)
Et la réplication de données alors ?
Il est souvent rassurant de se dire que ses données sont répliquées à de multiples endroits (c’est d’ailleurs ce que propose par défaut les fournisseurs de stockage Cloud, AWS S3 gère 3 copies de données synchrones). Un défaut classique est de penser que cette copie systématique permet de protéger ses données. C’est malheureusement faux, notamment dans des cas de corruption et surtout de destruction accidentelle, par exemple la suppression d’une ligne dans une base de données ! Dans ces deux cas, seule une sauvegarde vous permettra de revenir en arrière et de respecter votre PDMA.
Un dernier mot sur la sauvegarde. Vous entendrez souvent dire que la sauvegarde n’est pas importante, seule la capacité à restaurer l’est. Derrière cette tautologie se cache un aspect fondamental : seuls des tests de restauration réguliers peuvent réellement garantir que vos données sont bel et bien protégées.
L’ordonnancement
Côté architecture, il est important de se poser la question de la dépendance de notre système avec un mécanisme d’ordonnancement. Il peut être très simple, comme une crontab ou le planificateur de tâche Windows, ou plus complexe comme ce qui peut être proposé par des applications comme IBM TWS ou $U.
En effet, ce lien peut impacter notre capacité à tenir les engagements, même si les chaînes d’ordonnancement (aussi appelée chaîne batch) peuvent parfois s'exécuter de façon autonome ou en mode dégradé. La compréhension des interdépendances fait partie du travail de l’architecte, tout comme le fait de s’assurer que les cas « classiques » bloquants sont pris en compte. Par exemple, valider avec le métier s’il est possible ou non d’ouvrir le service le matin si les sauvegardes nocturnes ne se sont pas exécutées correctement.
Parfois cela ne posera pas de problème—« En cas de problème, on restaurera à J-2 et on rejouera les traitements. », soit une PDMA = 48h. Dans d’autres cas, il faudra décaler l’ouverture du service jusqu’à ce que la sauvegarde passe effectivement—« Je ne peux pas me permettre de perdre plus d’une journée de travail en cas d’incident », PDMA = 24h.
Le déploiement, le patch management, le rafraîchissement des environnements...
L’analyse opérationnelle est aussi le moment de mettre en avant toutes les contraintes posée par l’exploitation des systèmes : mécanisme de déploiements CI/CD—Continuous Integration / Continuous Deployment, gestion des mises à jour, rechargement des bases de données, la gestion des journaux (logs), du temps (NTP)...
Par exemple, un mécanisme à la mode pour déployer du code utilise le protocole WinRM, qui impose des ouvertures de ports et l’activation de fonctionnalités particulières au niveau du système d’exploitation. Anticiper ces contraintes permet de gagner du temps lors de la mise en service et valorise le travail de l’architecte technique.
Résumons les différentes couches d'une architecture
Voilà qui conclut cette longue partie sur les 4 couches d'une architecture ! J’espère que vous m’avez suivi jusque là :)
Dans le chapitre 1, nous avons vu ensemble l’importance de prendre le temps de comprendre les enjeux fonctionnels et ce que fait l’application ou le système étudié afin de le décliner sur les trois couches applicative, infrastructure et opérationnelle.
Dans le chapitre 2, nous avons développé la couche applicative. Pour cela, nous avons évoqué les problématiques de flux et la nécessité de comprendre où sont les gisements de données et comment sont exécutés les traitements qui les exploitent. L’importance aussi des middlewares qui donnent vie à ces éléments.
Je vous ai ensuite proposé, dans le chapitre 3, d’analyser l’angle infrastructure à travers l’aspect calcul, réseau et stockage, que ce soit dans le datacenter ou sous forme de services Cloud, en mettant en avant les problématiques d’hybridation.
Enfin, dans le chapitre 4, c’est à travers l’angle opération que je vous ai proposé de regarder les différents facettes d’une architecture, en particulier sur ses aspects supervision, métrologie, sauvegarde et ordonnancement.
Dans la partie suivante, nous allons voir ensemble comment concrètement tirer partie de l’analyse en 4 couches à travers la rédaction d’un document d’architecture technique.
