Identifier instantanément les impacts d'une régression !

 

  •  

    Supprimer les régressions entre environnements IT
    Identifier instantanément les impacts d'une régression !
  •  
     
    les environnements multiples, la norme 
     
    Pour sécuriser les développements et par extension les systèmes d'information, les entreprises répliquent leurs systèmes d'information dans divers environnements :
    dev, test, UAT, QA, Int, pré prod, prod, et autres !
     
    Le temps, un accélérateur de régression
     
    Les nuances entre environnements sont généralement initialement minimes...,
    Mais le cycle de vie de chaque information dans chaque environnement est différent, ce qui accentue mécaniquement les disparités.
     
  •  
         Les impacts de telles régressions 
     
  •  
    Des différences croissantes finissent par générer des régressions dommageables. En effet, les outils de manipulations de données répercutent ces différences massivement sur des chaînes entières, que ce soit dans les couches d’alimentation ou dans les couches de dataviz.
     
  •  

    • Un dashboard peut avoir une partie de ses réponses manquantes ou fausses s'il manque un champ dans une table,  
    • Les résultats de fonctions d’agrégations (et donc certaines analyses) peuvent être caduques s'il y a un champ en plus,
  •  
    • Si un champ n’est pas du même du même type (String, Integer, Date, etc.), une fonction de la base de données ne renverra pas le même résultat, voir ne fonctionnera pas du tout, 
    • .... 

    Les modifications de structure ne sont pas neutres, elles peuvent avoir des impacts significatifs et parfois inattendus sur le reste du Système.
         
      1.  
             Le data lineage pour identifier les impacts d'une
             régression 
         
      2.  
        1- Identifier les régressions : comparer les empreintes (les "hashs")

        • {openAudit} va scanner quotidiennement les structures des bases de données dans les différents environnements, c'est à dire les schémas, les tables, les champs, les vues.

        • Un « hash » va reprendre les champs, les types des champs, l’ordre des champs, le script normalisé (dans le cas des vues), 

        La même table devra pointer sur le même « hash » dans 2 environnements distincts. 
        Ainsi les évolutions structurelles, même extrêmement limitées, sont immédiatement identifiées. 
         

      3.  
        2- Identifier les impacts de la régression grâce au data lineage technique

        Une fois que l'on sait qu'il y a des champs qui diffèrent (entre la prod et ma pré prod par ex.), {openAudit} va permettre d'en connaître les impacts : 

        • Si {openAudit} détecte que ce champ ne produit pas de donnée utilisée dans un dashboard ou une requête, il s'agira d'une régression mineure. Ce sera l'occasion de procéder à des décommissionnements pour alléger le Système. 
         
      4.  
        •  Si a contrario {openAudit} détecte un usage dans un dashboard ou une requête à l'extrémité d'un flux, alors la régression est impactante, et il faudra opérer les correctifs qui s'imposent.


        Conclusion: 

        Les régressions sont (très, trop) nombreuses entre environnements.

        L’idée sera donc de vérifier en continue si ces régressions sont réellement dommageables.

        Pour le savoir, le data lineage technique est indispensable, dès lors qu'il est exhaustif et dynamique, i.e. qu'il est le reflet exact du Système d'Information.
           


        Commentaires

        Posts les plus consultés de ce blog

        Sur-administrer une plateforme SAP BO simplement

        Migrer de Oracle à Postgre en automatisant le processus !

        La Data Observabilité, Buzzword ou nécessité ?