Le plus gros de l'énervement est qu'il ne semble pas connaître le monde de la production, en production une défaillance (les dégradations de performance en font partie) ont un coût. Quand on est DBA de production on a pour objectif de rendre le service optimal le plus vite possible. On peut éventuellement donner des avis/conseilles mais ils ne seront pas entendus.
Le manager ne va pas financer une correction si le problème est résolu par des options du SGBDR. Il pensera que c'était un problème du SGBDR mais pas du code. Si le problème devient récurrent et pèse financièrement, que ma hiérarchie est convaincue par mes arguments alors une discussion devient possible. Mes boss parlent avec les autres boss, s'ils sont convaincus (et il y a de gros lourd) alors on pourra (les DBA) discuter avec les dev.
Ensuite faut pas rêver, je fais partie de la génération ou avant d'être admin de quoi que ce soit il fallait avoir été développeur, donc je peux facilement discuter et coder si je connais le langage. Beaucoup de mes jeunes collègues sont directement arrivés en production, ils ne connaissent rien au dev. Certain apprennent vite les principes fondamentaux du SQL, d'autres ne supportent même pas l'idée de devoir coder (même du ksh).
Le gros énervement vient donc du fait qu'il pense que les DBA et les dev devraient plus discuter, mais vu ces arguments j'ai l'impression qu'il n'a jamais essayé de discuter avec des DBA de productions pour connaître leurs attentes principales d'un SGBDR. J'ai l'impression qu'il développe un logiciel destiner à la production sans savoir ce qu'est une production.
[^] # Re: N'importe quoi !
Posté par Kangs . En réponse à la dépêche Interview de Dimitri Fontaine, contributeur majeur à PostgreSQL. Évalué à 1.
Le plus gros de l'énervement est qu'il ne semble pas connaître le monde de la production, en production une défaillance (les dégradations de performance en font partie) ont un coût. Quand on est DBA de production on a pour objectif de rendre le service optimal le plus vite possible. On peut éventuellement donner des avis/conseilles mais ils ne seront pas entendus.
Le manager ne va pas financer une correction si le problème est résolu par des options du SGBDR. Il pensera que c'était un problème du SGBDR mais pas du code. Si le problème devient récurrent et pèse financièrement, que ma hiérarchie est convaincue par mes arguments alors une discussion devient possible. Mes boss parlent avec les autres boss, s'ils sont convaincus (et il y a de gros lourd) alors on pourra (les DBA) discuter avec les dev.
Ensuite faut pas rêver, je fais partie de la génération ou avant d'être admin de quoi que ce soit il fallait avoir été développeur, donc je peux facilement discuter et coder si je connais le langage. Beaucoup de mes jeunes collègues sont directement arrivés en production, ils ne connaissent rien au dev. Certain apprennent vite les principes fondamentaux du SQL, d'autres ne supportent même pas l'idée de devoir coder (même du ksh).
Le gros énervement vient donc du fait qu'il pense que les DBA et les dev devraient plus discuter, mais vu ces arguments j'ai l'impression qu'il n'a jamais essayé de discuter avec des DBA de productions pour connaître leurs attentes principales d'un SGBDR. J'ai l'impression qu'il développe un logiciel destiner à la production sans savoir ce qu'est une production.