Différences

Ci-dessous, les différences entre deux révisions de la page.

--- fr:thinking:start [2021/04/06 22:27] – créée lonclegr
+++ fr:thinking:start [2021/04/25 23:01] (Version actuelle) – [Théorie] lonclegr
@@ Ligne 1: / Ligne 1: @@
-FIXME **Cette page n'est pas encore traduite entièrement. Merci de terminer la traduction**\\ //(supprimez ce paragraphe une fois la traduction terminée)//
 ====== Approche ======
@@ Ligne 13: / Ligne 11: @@
 ===== Théorie =====
-  - All requests, incidents or changes should be translated to standard input files.
+  - 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.
-  - These files should be used into a black box ((To me, a black box is a function or a set of functions which reads standard input files to create standard output files. Inputs and outputs are identified and may be used into scripts.)) to create output files summarizing the situation and testing if the request, incident or change makes sense. I call this step **preCheck** and it requires readOnly right because no modification occurs.
+  - 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.
-  - Next step consists of giving output files from **preCheck** to a second black box to execute requests or changes where **preCheck** results are accurate else they must be ignored and labelled as such. All actions applied into this **implementation** step require modification right.
+  - 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.
-  - Successful modifications are great, **postImplementation** checks are even better. How much frustrated it is to hear the sentence "//it should have worked, it did on my computer//" whereas the client has answered that it did not. It is even worse when you announced to your manager that the incident is closed whereas it is not. :-\ So, **implementation** files must be sent to a new black box to prove that all modifications have produced the expected behavior on your environment. And if some did not, then they must be identified.
+  - 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.
-  - Finally the **rollback** black box! Some people think it is optional, some others reckon it is mandatory. I would say: //without it, risk is very high//. I guess you get the workflow using input files from previous step to create new ones with results. Pay attention that if you had to rollback some modifications or even all of them, output files from **rollback** can be used as new input files for you **preCheck** step and now begin a circle! Plan makes sense.
+  - 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:
-A picture is worth a thousand words
 {{ :en:thinking:blackboxthinking.png?600 |Workflow to manage requests, changes and incidents}}
-===== Example =====
+{{ :en:thinking:blackboxthinking.dia |Source DIA}}
+===== Exemple =====
-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.
+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.
-Action plan :
-==== preCheck ====
+Plan d'actions :
+==== preCheck ====
-  * 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 :
+  * 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>
@@ Ligne 42: / Ligne 40: @@
 </csv>
-This is a perfect input file for a preCheck function. Now we must wonder : what do we want to check ?
+Ce fichier est très bien pour notre fonction de **preCheck**. Mais il faut se demander: //que veut-on vérifier au juste ?//
-  - For each line:
+  - Pour chaque line:
-    - Is a real active AD User ?
+      - Est-ce un vrai utilisateur actif dans l'AD ?
-    - Are we sure that the AD User is the good one ?
+      - 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.
-Since we detected two checks, we are going to add two new columns to our output file: **AdActiveUser** and **MailMatch**.
+Comme nous allons procéder à deux contrôles, le fichier de sortie de notre **preCheck** aura donc deux colonnes supplémentaires: **AdActiveUser** et **MailMatch**.
-Let's do it in [[en:powershell:advanced|Powershell]] for example.
+Faisons cela en [[fr:powershell:advanced|Powershell]] par exemple.
-This first function provides us a new file that we are going to use for the **implementation** step.
+Cette première boîte noire va nous fournir le nouveau fichier CSV que l'**implementation** va pouvoir utiliser.
 ==== Implementation ====
-PreCheck provides us this new file.
+Voici le fichier que la fonction de **preCheck** fournit:
 <csv>