====== Approche ======

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.

===== Théorie =====

  - 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.
  - Ces fichiers doivent être envoyés vers des boîtes noires ((Pour moi une boîte noire est une fonction ou un ensemble de fonctions qui lit des fichiers standardisés, effectue une action précise et crée un résultat sous forme d'un nouveau fichier au format standard.)) 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.
  - 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.
  - 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.
  - 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:

{{ :en:thinking:blackboxthinking.png?600 |Workflow to manage requests, changes and incidents}}

{{ :en:thinking:blackboxthinking.dia |Source DIA}}
===== Exemple =====

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 :

==== preCheck ====

  * 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:

<csv>
Name,Login,Email,Tel
Jean Robert,jrobert,jrobert@company.com,123456
Marie Curie,mcurie,m_curie@company.com,456789
Calamity Jane,calamity,cjane@company.com,789123
</csv>

Ce fichier est très bien pour notre fonction de **preCheck**. Mais il faut se demander: //que veut-on vérifier au juste ?//
  - Pour chaque line:
      - Est-ce un vrai utilisateur actif dans l'AD ?
      - 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 [[fr:powershell:advanced|Powershell]] par exemple.


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

Voici le fichier que la fonction de **preCheck** fournit:

<csv>
Name,Login,Email,Tel,AdActiveUser,MailMatch
Jean Robert,jrobert,jrobert@company.com,123456,yes,yes
Marie Curie,mcurie,m_curie@company.com,456789,yes,no
Calamity Jane,calamity,cjane@company.com,789123,no,no
</csv>