Les gestionnaires de département informatique rêvent de l'équipe parfaite où tous les membres sont capables de répondre aux tickets, aux demandes de changements et aux incidents d'une manière simple et efficace à travers des scripts qui donnent une très bonne qualité de résultats auprès des clients dans un temps réduit. Malheureusement, bien trop d'équipes de support répondent encore à ces demandes avec des actions manuelles sans fournir de retours en arrière clairs et avec des risques identifiés.

J'ai l'habitude de dire à mon équipe: si vous faites la même chose deux fois, alors c'est que vous auriez dû l'automiser dès le début. La théorie est bien différente de la pratique et je sais bien que souvent on manque de temps et qu'on a rarement la connaissance requise à chaque défi technique pour tout automatiser.

Cependant, si on n'essaie jamais et qu'on ne pose jamais la première pierre, le mur ne se montera jamais.

Alors essayons de commencer ici.

1. Il faut mettre toutes les requêtes, incidents ou changements sous forme de fichier standard. Le plus simple à utiliser avec un tableur est le format CSV.
2. Ces fichiers doivent être envoyés vers des boîtes noires ¹⁾ qui créent des fichiers de sortie résumant la situation pour vérifier que la requête initiale a du sens. Je nomme cette étape preCheck et elle ne demande que des droits de lecture dans l'environnement car on ne modifie rien à cette moment du processus.
3. En revanche à l'étape suivante, que je nomme implementation, des droits de modifications vont être requis car elle consiste à prendre en entrée les fichiers provenant du preCheck pour les donner à une seconde boîte noire pour effectuer les changements nécessaires et seulement ceux-ci. Tous les cas où le preCheck aura relevé une anomalie ne seront pas traités et étiquetés en tant que tel.
4. Faire des modifications avec succès est une bonne chose, mais des contrôles de postImplementation sont toujours un bon réflexe. Qui n'a jamais entendu la phrase frustrante “Cela ne marche pas en prod? Bizarre car cela fonctionne en local sur mon poste”. On est bien embarassé à traduire ce message technique aux clients . Ainsi, il faut créer une troisième boîte noire en partant des résultats de l'implementation et identifié les cas qui n'ont pas été réglés.
5. Dernière et non des moindres même si elle est souvent oubliée: le rollback. Il est parfois possible qu'un retour arrière ne soit pas possible et dans ce cas il faut bien exprimer le risque. Cependant, si un retour arrière est possible alors il faut le prévoir et l'avoir testé (la situation parfaite, soyons réalistes ) Ainsi une dernière fois on utilise les fichiers de l'étape précédente pour effectuer notre rollback. Et là, les fichiers de sortie de cette boîte noire peuvent être réutilisés dans le preCheck. La boucle est bouclée.

Une image vaut mieux mille mots:

Source DIA

Partons de la situation d'un bon lundi matin où on est d'astreinte et de tickets. On ouvre notre système de tickets (ServiceNow, Jira, Octopus etc.) qui va nous annoncer la couleur de la semaine. Le premier ticket qu'on ouvre est une requête qui demande de mofidier les utilisateurs de l'AD car il y a des fautes dans les noms. Cette demande a bien sûr été validée par les ressources humaines et l'impact a été identifié à un niveau nul.

Plan d'actions :

• Notre première boîte noire a besoin qu'on résume la demande dans un fichier CSV. Par chance, et parce que les exemples fictifs sont bien pratiques, le client a fourni le fichier à traiter. Voilà à quoi il ressemble:

Ce fichier est très bien pour notre fonction de preCheck. Mais il faut se demander: que veut-on vérifier au juste ?

1. Pour chaque line:
   1. Est-ce un vrai utilisateur actif dans l'AD ?
   2. Si tel est le cas, peut-on se rassurer d'avoir la bonne personne ? Les homonymes et les fautes de frappe sont si fréquentes.

Comme nous allons procéder à deux contrôles, le fichier de sortie de notre preCheck aura donc deux colonnes supplémentaires: AdActiveUser et MailMatch.

Faisons cela en Powershell par exemple.

Cette première boîte noire va nous fournir le nouveau fichier CSV que l'implementation va pouvoir utiliser.

Voici le fichier que la fonction de preCheck fournit: