Vous êtes sur la page 1sur 4

Documentation astreinte Intégration :

L’équipe d’exploitation désignent les flux, implémentent l’ordonnancement des tâches

Dans VTOM : les traitements se lisent à l’envers. C’est-à-dire qu’un job à l’autre côté de la flèche ne
s’exécute que si le job d’en haut est exécuté.

La couleur des flèches est importante, cela a un rapport avec les contraintes d’exécution

On peut définir l’horaire d’exécution de chaque job (jours de la semaine), les contraintes, les
paramètres (scripts à exécuter, commentaire...), la famille (criticité des jobs, équipes qui vont être
alertées en cas de plantage) Exemple : les jobs de la famille BI sont critiques et restent en erreur
jusqu’à l’intervention de l’équipe BI, en plus d’un appel d’astreinte (week-end, jours fériés…).
L’intervention se fait directement sur la PROD.

En cas de plantage, on reçoit un mail automatique avec le nom de l’environnement, nom de


l’application et traitement, le statut, horaire du plantage (PAS DE MSG D’ERREUR)

Causes probables des KO : Timeouts de connexion, problèmes de données (types de données par ex)

Pour les jobs sans famille, l’équipe d’intégration intervient.

Famille NCXXX : Non critique (1er chiffre : EXPLOITATION, 2ème chiffre : INTEGRATION, 3ème chiffre :
BI)

Famille SCXXX : Semi-critique, ne génère pas d’appel d’astreinte, l’intervention n’est pas urgente

En cas de traitements non critiques, il va être considéré comme exécuté et fini et le traitement
suivant se lance. Personne n’intervient, mais il y a une investigation.

Environnements :

Exploitation : jobs de journée


ADMIN : Reboot de machines, backups…

PROD : traitements de nuit

TEST : tests

Au cas où il y aurait un blocage, il suffit de chercher le job dans VTOM et de checker les logs

Les incidents sont loggés dans JIRA.

Ils existent des jobs qui sont indépendants et qui ne sont exécutés que s’il y a d’autres jobs qui le
demandent.

Les jobs dans VTOM :

Losanges = ODI

Ronds = cycliques

Jobs avec icônes stambia = jobs STAMBIA

Exemple d’un job ODI : startcmd-odi.sh avec paramètres : OdiStartScen – nom du scenario – version
du scenario (-1 = scénario récent) – contexte d’exécution – l’agent – niveau de log (3)

[ ! ] sur un job = job désactivé

L’équipe d’exploitation est chargée de désactiver les jobs à la demande.

Une flèche multi colore signifie qu’il y a des traitements dans d’autres applications qui dépendent du
job marqué par la flèche, il autorisera les jobs dépendants lorsqu’il aura fini (liens avals)
Les ressources sont des contraintes supplémentaires sur les traitements en plus de l’heure, des
dépendances…

Il y a des jobs de reboot, ils sont concernés par les équipes d’exploitation et de l’infrastructure.

Flux ODI :

Il existe 2 types de flux :

FF : Passage du flux entre la source vers la base ODI

SF : Passage du flux entre la base ODI vers la cible

En cas d’erreur, il faut checker l’opérateur, le log d’erreur n’est pas affiché sur VTOM.

Flux Stambia :

p_IN : Flux entrant de la source vers le datastage.

p_Extract : Flux entre le datastage et le datacore.

p_OUT: flux sortant, du datacore vers la cible.

Contrairement à ODI on peut voir les erreurs sur le log d’erreur de VTOM.

Note importante : il ne faut jamais mettre un job à terminer.

Erreurs fréquentes :

Connection reset : mettre le job à venir

Rejects: il faut partir sur le schéma SAS et renommer la table indiquer sur l’erreur, normalement on
ajoute un suffixe de sysdate, et puis mettre les jobs à terminer.

Dans le cas où il y a plusieurs jobs qui sont en erreur : il faut checker l’agent d’exécution (sur ODI) ou
le runtime (sur Stambia) et il faut tester la connection de cet agent, s’ils ne répondent pas ça veut
dire que c’est un problème physique, donc il faut appeler l’astreinte INFRA.

Même chose dans le cas où il y a un problème TableSpace/Serveurs BD ou FTP, il faut appeler


l’astreinte INFRA

Problème de données :

Il faut analyser le job en erreur et voir la source de ce fichier, dans la plupart des cas les fichiers sont
sur le serveur ftp PRODODI sur le chemin /mnt/FTP_ODE1FTP1/Prod (on peut toujours checker
Toplogie pour en être sûr),

Par exemple: AROMA_IN_SAVE =>/mnt/FTP_ODE1FTP1/Prod/AROMA/IN/SAVE


Sinon si ça vient d’un FTP externe, il faut checker les tables : FTP_PARAMS (pour les autres
applications) ou FTP_SHOP_PARTNER_PARAMS (pour les ftp des partenaires) base de données ODI.

Vous aimerez peut-être aussi