User Tools

Site Tools


en:thinking:start

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
en:thinking:start [2021/03/27 22:20] – [preCheck] lonclegren:thinking:start [2021/04/25 23:00] (current) – [Theory] lonclegr
Line 12: Line 12:
  
   - All requests, incidents or changes should be translated to standard input files.   - All requests, incidents or changes should be translated to standard input files.
-  - These files should be used into a black box ((a black box to me is a function or a set of functions which read 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.+  - 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.
   - 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.   - 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.
-  - Successful modifications are great, **postImplementation** checks are even better. How much frustrated is to hear the sentence "//it should have worked, it did on my computer//" whereas the client has answered you 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.+  - 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.
   - 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.   - 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.
  
Line 21: Line 21:
  
 {{ :en:thinking:blackboxthinking.png?600 |Workflow to manage requests, changes and incidents}} {{ :en:thinking:blackboxthinking.png?600 |Workflow to manage requests, changes and incidents}}
 +
 +{{ :en:thinking:blackboxthinking.dia |Source DIA}}
  
 ===== Example ===== ===== Example =====
Line 40: Line 42:
 </csv> </csv>
  
-This is a perfect input file for a preCheck function. Now we must ask ourselves : what do we want to check ?+This is a perfect input file for a preCheck function. Now we must wonder : what do we want to check ?
   - For each line:   - For each line:
     - Is a real active AD User ?     - Is a real active AD User ?
     - Are we sure that the AD User is the good one ?     - 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: **AdUser** and **identityStatus**.+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 [[en:powershell:advanced|Powershell]] for example. Let's do it in [[en:powershell:advanced|Powershell]] for example.
  
 This first function provides us a new file that we are going to use for the **implementation** step. This first function provides us a new file that we are going to use for the **implementation** step.
 +
 +==== Implementation ====
 +
 +PreCheck provides us this new file.
 +
 +<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>
 +
en/thinking/start.1616898029.txt.gz · Last modified: 2021/03/27 22:20 by lonclegr