31-05-2012, 09:45 AM
(30-05-2012, 02:17 PM)Sephi-Chan a écrit : Ça ne doit pas être si simple, sinon il le feraient.
Pas sur ... des fois les choses les plus simples nous échappent ... tout simplement parce que les systèmes sont gérés par différentes entités de travail qui ne travaillent pas toujours de concert, ou à cause de responsabilité non gérées.
Je suis confronté à ce type de problème tous les jours au travail, et je peux t'assurer que le bon sens n'est pas toujours au rendez-vous.
Globalement, on se dirige vers un mur... y'a juste à dire au type qui conduit de tourner le volant mais, entre le moment où on réalise que le mur se rapproche, et le temps où l'information remonte ... on estime qu'il vaut mieux passer son énergie à amortir le choc.
kéké
PS : je peux te sortir un exemple tout con ... on a des traitements $U qui se lancent tous les jours (pas moins de 400 noeuds, chaqu'un lancant plusieurs milliers de taches/jours).
Parmis ces traitements, y'en a un en particulier qui plante 10 fois tous les jours depuis le mois de mars. Une équipe (le CC) est là, 10 fois par jour à corriger ce traitement.
En fait au mois de mars, une évolution (MEP) a simplement remplacé un répertoire par un autre. Un fichier est donc copié dans un répertoire inexistant ... l'action de notre niveau consiste donc à se connecter au serveur, identifier le fichier et le déplacer dans le bon répertoire.
Il aurait suffit de faire modifier le traitement pour pointer vers le bon répertoire et ça aurait suffit ... mais cette action aurait du être identifiée par une équipe (BT) pendant la MEP, qui conteste et rejette la faute à la Maitrise d'oeuvre (ME). La maitrise d'oeuvre se défend car il s'agit d'une modif d'infra relative au BT. Comme y'a un impact financier derrière, aucune des 2 équipes ne souhaitent céder (et donc devoir payer les pots cassés). Bilan, tant que c'est pas tranché qui doit initier la correction du problème, l'incident revient régulièrement, et c'est une équipe qui n'a pas la responsabilité de corriger le problème qui doit régler l'incident, encore et encore.
Ca semble compliqué, improbable, mais c'est globalement 60 à 70% de nos problèmes. Souvent c'est même plus compliqué, suffit d'imaginer des problèmes d'accès disques d'une Base de donnée Oracle monté sur un VM unix dont la zone est sur un OS Windows ... on se retrouve avec 4 entités (stockage, DBA, expert UNIX, expert Windows) qui se bataillent des jours entiers à savoir qui doit payer ET corriger.
Bref, mon idée est donc que, si c'est évident et que ça ne marche pas, c'est souvent un problème d'ordre organisationnel.
PS : j'adore faire des PS plus long que le message originel ^^