Comment automatiser dans un MSP lorsqu’il n’existe pas d’environnement de validation réel

Ici, nous parlons toujours de bonnes pratiques, parce que c’est ce qu’il faut faire et que nous avons toujours été sages à l’école. Mais un immense océan sépare la théorie IT de sa pratique au quotidien… Et il est rempli de monstres. Par exemple, la plupart des MSP ne disposent pas d’un environnement de validation qui reproduise la réalité de leurs clients.
Ils n’ont pas mis en place un staging jumeau ou une réplique fiable, et ils ne possèdent pas non plus ce laboratoire immaculé où tester les automatisations avant de toucher à ce qui compte vraiment. Ils ont la production et un stagiaire fait de caféine avec le doigt sur le bouton de push. Mais la production, c’est là que vit le client qui paie, qui ne veut pas entendre d’excuses et qui appelle en crachant du feu.
L’instinct, dans ce cas, consiste généralement à renoncer à automatiser « au cas où » ou à se lancer sans filet et à prier. La première de ces portes nous condamne à continuer de faire à la main tout ce qui érode la marge et consomme l’équipe. La seconde revient à piloter à vitesse warp en aveugle, ce qui signifie que vous allez très vite… jusqu’au moment où vous n’avancez plus.
Ici, nous ouvrirons une troisième porte, car ne pas disposer d’un environnement de validation parfait n’implique pas de renoncer à l’automatisation, mais oblige à la concevoir autrement. De façon plus prudente, segmentée et, surtout, réversible.
Voyons comment.

Pourquoi il existe rarement un véritable environnement de staging dans un MSP

Pour une fois, ce problème ne vient pas de notre négligence, vraiment. Il convient donc de le normaliser parce qu’en réalité, il s’agit de la nature même du métier.
Un MSP gère des clients hétérogènes. Chacun a son système d’exploitation, sa version, son correctif en attente depuis le Crétacé, sa topologie particulière… Répliquer cela dans un environnement de test impliquerait vingt laboratoires différents et c’est dans ce genre de situations que la théorie parfaite ne rentre pas dans la réalité IT.
À cela, il faut ajouter les infrastructures héritées. Ces systèmes que personne n’ose toucher parce que l’on ne sait pas vraiment comment ils fonctionnent ni quel personnage légendaire les a montés, de sorte qu’ils peuvent rarement être clonés avec des garanties.
Mais au-dessus de tout se trouve le maître suprême, l’argent.
Répliquer des environnements représentatifs demande du matériel, des licences et des heures que presque aucun MSP ne peut consacrer à chaque client.
Pour remuer le couteau dans la plaie, de nombreuses parties de l’infrastructure gérée dépendent de services externes (API tierces, intégrations, systèmes propres au client…) qui sont tout simplement impossibles à reproduire dans un environnement isolé.
Au fond, il y a une question de contrôle, parce qu’un MSP n’est pas propriétaire de l’architecture du client. Il la gère, certes, mais il ne la possède pas, ce qui limite ce qu’il peut mettre en place comme miroir de test.
Dans cette vie réelle si différente de la théorie, le staging fiable, lorsque l’on parle d’environnements multiclients, est l’exception plutôt que la règle. Plus qu’une honte à cacher, il s’agit donc d’une contrainte de conception avec laquelle travailler.
Mais bien sûr, cela implique un danger…

Quels risques apparaissent lorsque l’on automatise directement en production

Chuck Palahniuk a écrit Fight Club et a dit que la seule façon de trouver le bonheur était de prendre le risque de se faire ouvrir en deux. Mais Palahniuk ne travaillait pas dans l’IT, et la première clé pour automatiser directement en production consiste à comprendre ces risques, sinon c’est bien nous qui finirons ouverts en deux.
Le premier, et le plus redouté, est la propagation rapide des erreurs.
Une automatisation est, par définition, quelque chose que nous exécutons de nombreuses fois et très rapidement. Merveilleux quand cela fonctionne, et désastre total quand ce n’est pas le cas, parce qu’un mauvais script casse deux cents serveurs avant même que notre mâchoire ne touche le sol en le voyant.
En deuxième lieu, il y a les changements difficiles à diagnostiquer.
Quand quelque chose est appliqué de façon massive et simultanée, il est également probable que cela commence à échouer de façon massive et simultanée.
Dans ces cas-là, il est difficile de savoir exactement ce qui a changé, dans quel ordre et où la situation a commencé à déraper.
Et lorsque ce qui dérape est critique, cela devient un défi métier pour le client à qui nous avions promis que son IT fonctionnerait sans accroc. Nous perdons sa confiance, et celle-ci est un vase en porcelaine : même si nous recollons laborieusement les morceaux, il ne redevient jamais le même.
Le reste de la facture arrive en différé, car ces risques nous rendent craintifs et inefficaces.
Ainsi, nous augmentons la supervision réactive, parce que personne n’ose vraiment faire confiance au système et que nous surveillons tout en permanence. Peu à peu, les SLA se dégradent également, et le rollback (ce retour en arrière que personne n’a conçu parce que « de toute façon, qu’est-ce qui pourrait échouer ? ») devient très coûteux précisément au moment où nous en avons le plus besoin.

Quelles automatisations sont particulièrement sensibles sans validation réelle

Après avoir identifié les risques, nous devons connaître les automatisations concrètes chez le client, parce qu’elles ne sont pas toutes identiques et que notre premier exercice de prudence consiste à distinguer celles qui mordent de celles qui ne mordent pas.
Dans le groupe de celles qu’il faut traiter comme si nous désamorcions une bombe, on trouve :

• Les changements massifs de configuration, qui appliquent la même chose à de nombreux actifs en même temps. Si le modèle est incorrect, l’erreur sera massive.
• Les remédiations automatiques sur des systèmes critiques, où le self-healing est excellent, sauf lorsque le remède est pire que le mal.
• Les automatisations qui dépendent de topologies spécifiques, lesquelles fonctionnent très bien chez le client A pour lequel elles ont été conçues, mais débarquent dans l’infrastructure du client B comme en Normandie, et Palahniuk a raison parce que l’on finit ouvert en deux.
• Les processus avec des seuils peu fiables (ou non adaptés à la réalité de chaque client) qui déclenchent des actions à partir de métriques mal calibrées et agissent au mauvais moment.
• Les actions irréversibles ou sans rollback possible : suppressions, migrations, écrasements… Ici, il n’y a pas de seconde chance.
• Les changements sur des services où une défaillance a un impact direct sur l’activité du client. Ici, une erreur se transforme en appels de CEO, d’abord celui du client, puis le nôtre qui parle d’indemnités de départ.

Nous n’identifions pas ce qui est critique pour renoncer à l’automatiser. La clé consiste à leur réserver le traitement le plus prudent parmi tous ceux que nous verrons ensuite.

Comment réduire les risques lorsque nous ne pouvons pas tester dans un environnement jumeau

Entrons dans le vif du sujet. Si nous ne pouvons pas tester dans un environnement jumeau ou similaire, la stratégie consiste à transformer la production elle-même en banc d’essai, mais de façon contrôlée, en exposant à chaque fois une petite portion récupérable de l’ensemble.
La vie dans l’IT est un casino, et il vaut mieux suivre la règle d’or pour y survivre : ne jamais miser plus que ce que nous pouvons nous permettre de perdre à chaque coup.
C’est pourquoi nous ne faisons pas comme James Bond en misant « tout sur le rouge », mais nous appliquons le déploiement progressif, en espérant le meilleur tout en étant prêts au pire.
Cet état d’esprit est fondamental et, au lieu d’appliquer ce changement suggéré par le LLM à mille actifs d’un seul coup, nous commençons par un groupe pilote réduit, nous observons en essuyant nos sueurs froides et, seulement si nos cauchemars ne deviennent pas réalité, nous étendons ledit déploiement.
Nous ne serons jamais 007 avec cette attitude, mais une activation par phases (où chacune confirme que la précédente n’a pas pris feu) fera hocher la tête au Mandalorien en disant : « This is the way ».
Ce pilotage repose sur la segmentation, et c’est là qu’un MSP possède, paradoxalement, un avantage (il était temps).
Ce MSP travaille par clients et par niveaux de criticité (ou du moins, il devrait), ce qui permet d’ordonner les déploiements en commençant par les environnements les moins critiques et les plus tolérants, en laissant pour la fin les services qui provoquent le plus d’infarctus.
Ce déploiement progressif est un cheval que nous menons avec prudence et auquel nous ajoutons une série de garde-fous de sécurité supplémentaires, tels que :

• Des fenêtres de changement définies, afin que, lorsque quelque chose dérape, cela ne nous surprenne pas endormis à trois heures du matin ou ne se produise pas pendant le pic de ventes du client.
• Des validations préalables minimales : même si nous ne pouvons pas tout simuler complètement, nous pouvons toujours vérifier les préconditions avant de nous lancer (le service existe-t-il ?, y a-t-il de l’espace ?, l’actif est-il bien là où je le pense… ?). Mieux vaut une vérification basique qu’une catastrophe toute prête.
• Une vérification automatisée après changement : après le changement, la première étape consiste à confirmer automatiquement que le système est toujours sain. Si ces checks passent, nous le révisons manuellement en profondeur, avec un niveau de dévouement proportionnel à la criticité du système.
• Un rollback conçu dès le départ et à froid. Avant de lancer quoi que ce soit, la question n’est pas « est-ce que cela fonctionnera ? », mais « comment l’annuler si cela ne fonctionne pas ? ».

Si l’on y regarde bien, aucune de ces mesures ne nécessite de staging, seulement du discernement fondé sur une mentalité de survivaliste de fin du monde et un peu de patience.
Le mauvais côté, c’est que nous automatisons souvent par effet de mode et par FOMO, ce qui nous fait courir comme des poulets sans tête parce que « nous ne voulons pas prendre de retard et la concurrence l’a sûrement déjà appliqué ».
La concurrence vit la même chose que nous, et cela rejoint les erreurs typiques lors de l’automatisation des processus dans un MSP. Spoiler : elles ont presque toutes le même père, vouloir aller trop vite.

Quel rôle joue l’observabilité de l’automatisation elle-même

L’automatisation, par définition, nous fait perdre le contrôle direct, parce que nous lâchons le volant pour nous consacrer à autre chose et que nous prions pour que la conduite automatique ne finisse pas dans un lampadaire.
Mais lâcher le volant ne signifie pas fermer les yeux.
D’où la nécessité de surveiller l’automatisation afin qu’elle ne dérive pas peu à peu vers ce lampadaire.
Spock disait : « La logique est le début de la sagesse, pas la fin ». Automatiser n’est également que le début, et la sagesse finale consiste à savoir ce que fait réellement ce que nous avons mis en marche tout seul.
Pour cela, nous avons besoin de réponses à des questions très concrètes :

• Si l’automatisation s’est exécutée correctement ou si elle est restée bloquée.
• Sur quels actifs elle a agi exactement.
• Avec quel résultat.
• Ce qui a réellement changé dans le système.
• Ce qui a échoué et où.
• Quelle exception est apparue alors que nous ne l’avions pas prévue.
• Combien de travail de supervision elle génère, car une automatisation qui t’oblige à la surveiller en permanence ne nous a libérés de rien.

La question est que la qualité de la traçabilité postérieure définit, en partie, combien de validation dans un environnement préalable (que nous n’avons pas) nous pouvons omettre.
Au final, même avec ce laboratoire préalable, les choses ne se passeront pas exactement de la même manière, et la validation qui compte est celle réalisée sur la réalité.
Mais sans visibilité, automatiser la production sans staging, c’est le « tout sur le rouge » de Bond, qui ne fonctionne que dans les films.

Ce qui change lorsqu’un MSP automatise la production avec discernement

Lorsque nous assemblons tout ce qui précède comme les Avengers (déploiement progressif, segmentation, rollback prévu et observabilité), le staging devient moins nécessaire et certains signes indiqueront que nous faisons les choses correctement.
Les voici :

• Moins d’improvisation. Parce que chaque changement suit un modèle connu, au lieu de dépendre de l’inspiration du technicien d’astreinte.
• Moins d’erreurs massives, tout simplement parce que nous ne misons plus tout sur le rouge, mais sur des paris plus petits.
• Plus de confiance pour passer à l’échelle. Parce que lorsque nous savons qu’un déploiement est progressif et réversible, nous osons exploiter davantage de clients avec la même équipe sans avoir l’estomac noué.
• Et surtout, il y a une meilleure traçabilité et un meilleur contrôle du changement. L’automatisation cesse d’être une boîte noire qui dépend des caprices du silicium et devient un processus gouverné.

Le résultat est une automatisation durable même lorsqu’il n’existe pas de véritable staging, ce qui semblait justement impossible au début.

Comment Pandora FMS aide à automatiser de manière contrôlée sans environnement de validation complet

La question la plus pratique est : avec quels outils faisons-nous tout cela sans devenir fous ?
Pandora FMS s’impose comme réponse, mais pas par magie ni par marketing, plutôt parce que nous l’avons pensée et construite pour les batailles multi-tenant.
Ainsi, la segmentation par groupes et clients est native. Organiser les déploiements par criticité ou par environnement (ces groupes pilotes dont nous parlions plus haut) cesse d’être une affaire de hacks et de bricolages pour devenir la façon naturelle de travailler avec notre outil.
Sur cette base, la monitorisation avant et après le changement nous apporte les validations qui, comme nous l’avons vu, peuvent remplacer (au moins en partie) le laboratoire préalable. Avec Pandora FMS, nous vérifions l’état avant d’agir et confirmons le résultat ensuite… de façon automatisée.
L’automatisation contrôlée permet d’exécuter des actions correctives et des réponses sans renoncer à la vérification ni à la traçabilité, qui est le point fort de Pandora FMS. Puisque nous nous lançons tête la première sans test préalable, au moins nous pouvons observer de près chaque pas que nous faisons pour corriger les défis.
Notre outil détecte, agit, vérifie et laisse une trace de ce qu’il a fait et sur quoi, ce qui transforme une automatisation aveugle en automatisation contrôlée.
Et tout cela, sous une visibilité centralisée depuis la Métaconsole, ce single pane of glass depuis lequel nous observons les effets du changement en temps réel et dans tous les environnements à la fois. Le rêve d’être le Heimdall de Marvel, capable d’entendre jusqu’au plus petit murmure dans les neuf mondes.
À cela s’ajoutent les alertes et événements consolidés, avec corrélation et filtrage pour ne pas nous noyer dans le bruit lorsque quelque chose d’étrange commence à bouger.
Et si la sécurité est globale, Pandora SIEM ajoute la visibilité de ce type d’événements à la même image. Si un changement automatisé ouvre une porte qu’il ne devrait pas à des acteurs malveillants, cela ne passera pas inaperçu pour Pandora.
Au final, ne pas disposer d’un environnement de validation parfait n’est pas la fin de l’automatisation dans un MSP, car sinon presque personne n’automatiserait.
La clé consiste à cesser de penser l’automatisation comme un interrupteur que nous activons d’un seul coup pour voir ce qui se passe. Si nous l’abordons comme un processus progressif, observable et réversible (en déployant par phases, en segmentant par criticité, en validant avant et après, et avec des rollbacks), nous atténuons les risques liés à l’absence du laboratoire parfait (qui n’arrivera probablement jamais).
Nous tromperons-nous ? Bien sûr, c’est la vraie vie dans l’IT, mais le laboratoire ne nous vaccine pas non plus contre cela et, en suivant les meilleures pratiques que nous avons vues, ces erreurs inévitables seront petites et sans drame.