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:

Imagine, today is Monday and you start your on shift week. Your favorite IT ticketing system (ServiceNow, Jira, Octopus etc.) is waiting for you. The first ticket you opened requests you to modify AD users because some names are misspelled.

Action plan :

• Our first black box needs at least one input file which summarizes the request. Luckily, there is one CSV file into the ticket with all modifications the client requested. It looks like this :

This is a perfect input file for a preCheck function. Now we must wonder : what do we want to check ?

1. For each line:
   1. Is a real active AD User ?
   2. Are we sure that the AD User is the good one ?

Since we detected two checks, we are going to add two new columns to our output file: AdActiveUser and MailMatch.

Let's do it in Powershell for example.

This first function provides us a new file that we are going to use for the implementation step.

PreCheck provides us this new file.