> A mon sens, c'est débile de dire "cette distro vient de sortir, elle est donc pas assez testée".
Oui et non. J'adore utiliser une Fedora fraichement sortie même pour mon (petit) site web. D'ailleurs, j'aime encore mieux prendre avant la date de sortie.
Donc une distribution toute fraiche peut marcher même pour un serveur critique hypra chargé. Pas de doute.
Mais c'est débile de raisonner comme ça même si c'est vrai. Pour un système critique tu ne cherches pas un "ça peu marcher" mais un "je dois avoir le maximum de chance de marcher". On est ici dans l'assurance qualité dont le domaine est très large. Par exemple pouvoir trouver des personnes qualifiées pour régler un problème est important pour l'assurance qualité.
D'où l'importance des formations, les logiciels certifiés pour un OS (ici ce n'est pas qu'un label, ça veut dire que l'éditeur a des compétances pour régler un problème de son logiciel avec cet OS), du hardware certfié (ce qui veut dire que la prochaine mise à jour du noyau a été contrôlé sur ce hardware), etc.
Il faudrait aussi s'entendre sur ce qu'est un système critique.
Comme je le disais plus haut, on peut aussi dire qu'un câble réseau est critique.
Mais le câble tu le branche et basta. Et si ça ne marche pas tu changes de câble et ça te coûte 10 € (plus le désagrément durant 20 minutes).
> mettons par exemple un serveur postfix
Si le serveur tombe en panne, quel est l'inconvéniant ? Combien de temps il faut pour retourner à la normal ?
Un serveur de messagerie n'est pas forcément très critique (sauf les serveurs imap/exchange).
Par contre une base de donnée que toute l'enprise utilise, qui est le centre du "workflow" de l'entreprise, qui a des tonnes d'informations sur l'entreprise, qui fait le suivi des ventes, a une brouette de procédures métiers amoureuses élaborées, etc est un système critique. S'il tombe en panne, plus personne ne travaille, si des données sont perdues c'est une catastrophe, etc. La valeur du serveur est énorme. Pas à cause de l'informatique, mais à cause des informations qu'il contient et du rôle qu'il a dans l'entreprise. La valeur d'un serveur postfix est beaucoup plus faible.
Certes pour les deux il faut de la disponibilité. Mais il beaucoup plus facile d'avoir un bon niveau de disponibilité pour un serveur postfix que pour une base de donnée entreprise. Si y a un problème avec la base de donnée (par exemple erreur d'un utilisateur avec privilège de la base de donnée), rétablir la situation peut être très délicat. On peut restaurer le backup, mais on perd les dernières données (s'il y a un log il faut tout rentrer à la main en vérifiant) et cette restauration prend 24 heures à faire...
Notons bien ici que pour restaurer la situation il faut des compétances et tout de suite. On ne va pas attendre que l'utilisateur qui a fait la connerie prennent des cours de base de données.
Sur ce type de système les problèmes peuvent venir de beaucoup d'entroit. Entre autres car ces systèmes sont souvent interdépendants (les frondend, le backend, etc). Que ça peut "planter" à cause d'une erreur utilisateur ("admin" de la base), d'une mise à jour de java, d'un des 20 disques dures, le SAN, le répartiteur de charge, etc Pour que l'ensemble est un niveau de disponibilité satisfaisant, il faut un niveau de qualité très élevé sur chaque composant. Qualité au sens large et pas seulement fiabilité.
> et ce n'est pas parce que la distro a un temps de support plus élevé ou qu'elle a été testée plus longtemps avant que ça va y changer grand chose.
Si ça marche... c'est cool. Tout n'est pas "critique" (dans le sens que j'utilise).
[^] # Re: Les "études"
Posté par IsNotGood . En réponse à la dépêche Revue de presse de l'April pour la semaine 6. Évalué à 3.
Oui et non. J'adore utiliser une Fedora fraichement sortie même pour mon (petit) site web. D'ailleurs, j'aime encore mieux prendre avant la date de sortie.
Donc une distribution toute fraiche peut marcher même pour un serveur critique hypra chargé. Pas de doute.
Mais c'est débile de raisonner comme ça même si c'est vrai. Pour un système critique tu ne cherches pas un "ça peu marcher" mais un "je dois avoir le maximum de chance de marcher". On est ici dans l'assurance qualité dont le domaine est très large. Par exemple pouvoir trouver des personnes qualifiées pour régler un problème est important pour l'assurance qualité.
D'où l'importance des formations, les logiciels certifiés pour un OS (ici ce n'est pas qu'un label, ça veut dire que l'éditeur a des compétances pour régler un problème de son logiciel avec cet OS), du hardware certfié (ce qui veut dire que la prochaine mise à jour du noyau a été contrôlé sur ce hardware), etc.
Il faudrait aussi s'entendre sur ce qu'est un système critique.
Comme je le disais plus haut, on peut aussi dire qu'un câble réseau est critique.
Mais le câble tu le branche et basta. Et si ça ne marche pas tu changes de câble et ça te coûte 10 € (plus le désagrément durant 20 minutes).
> mettons par exemple un serveur postfix
Si le serveur tombe en panne, quel est l'inconvéniant ? Combien de temps il faut pour retourner à la normal ?
Un serveur de messagerie n'est pas forcément très critique (sauf les serveurs imap/exchange).
Par contre une base de donnée que toute l'enprise utilise, qui est le centre du "workflow" de l'entreprise, qui a des tonnes d'informations sur l'entreprise, qui fait le suivi des ventes, a une brouette de procédures métiers amoureuses élaborées, etc est un système critique. S'il tombe en panne, plus personne ne travaille, si des données sont perdues c'est une catastrophe, etc. La valeur du serveur est énorme. Pas à cause de l'informatique, mais à cause des informations qu'il contient et du rôle qu'il a dans l'entreprise. La valeur d'un serveur postfix est beaucoup plus faible.
Certes pour les deux il faut de la disponibilité. Mais il beaucoup plus facile d'avoir un bon niveau de disponibilité pour un serveur postfix que pour une base de donnée entreprise. Si y a un problème avec la base de donnée (par exemple erreur d'un utilisateur avec privilège de la base de donnée), rétablir la situation peut être très délicat. On peut restaurer le backup, mais on perd les dernières données (s'il y a un log il faut tout rentrer à la main en vérifiant) et cette restauration prend 24 heures à faire...
Notons bien ici que pour restaurer la situation il faut des compétances et tout de suite. On ne va pas attendre que l'utilisateur qui a fait la connerie prennent des cours de base de données.
Sur ce type de système les problèmes peuvent venir de beaucoup d'entroit. Entre autres car ces systèmes sont souvent interdépendants (les frondend, le backend, etc). Que ça peut "planter" à cause d'une erreur utilisateur ("admin" de la base), d'une mise à jour de java, d'un des 20 disques dures, le SAN, le répartiteur de charge, etc Pour que l'ensemble est un niveau de disponibilité satisfaisant, il faut un niveau de qualité très élevé sur chaque composant. Qualité au sens large et pas seulement fiabilité.
> et ce n'est pas parce que la distro a un temps de support plus élevé ou qu'elle a été testée plus longtemps avant que ça va y changer grand chose.
Si ça marche... c'est cool. Tout n'est pas "critique" (dans le sens que j'utilise).