Hello Benoit,
Toujours fasciné par le rapport de complexité entre le matériel et le
logiciel, inversement proportionnel à leur fiabilités respectives.
Ca ne correspond pas à mon expérience passée à développer des systèmes
hardware et software de télécommunications :
Nos écosystèmes étaient probablement très différents. Ici pas mal
d'indus et surtout de coms milis
- le management plane et le control plane sont généralement beaucoup
plus complexes que le dataplane
- le management plane et le control plane évoluent généralement
beaucoup plus rapidement avec des mises à jour de code et
configuration fréquentes
- à contrario, le dataplane doit être le plus rapide possible et un
uptime infini
De plus le coût d'un bug hardware étant bien supérieur au coût d'un
bug software,
La grosse diff. entre le hard et le soft. Ça peut même couler un boite
ou un projet entier.
on investit beaucoup plus de budget sur le test et la vérification
hardware que sur le software. Et malgré ça, le hardware est tout de
même buggé et le workaround est généralement software...
Il y avait des soucis de tenue, jusque dans les années 80. Mais le
passage à une électronique essentiellement numérique a pas mal limité
les délires propres à l'analogique, aux températures, aux dispersions de
caractéristiques, tolérances, etc. Après on a eu tous les soucis de
statique, d'IEM, etc. Mais c'est réglé depuis longtemps. Après, il
restera toujours de l'analogique, (horreur :) et même (comble du mauvais
goût) de l'analogique qui doit être linéaire :)
Tout ça pour dire que les contraintes ne sont pas les mêmes entre un
dataplane limité en fonctionnalités et stable dans le temps vs un
control plane en constante évolution et intégrant toute la complexité
métier.
Tout à fait.
J'évoquais surtout la diff entre le pur hardware numérique et le
software seul. Pas été assez précis, désolé.
Pour aller dans ton sens, j'ai des souvenirs d'e2prom avec crypto
embarquée complètement bugguées... Obligé de leur mettre leur caca
devant leur nez pour qu'ils avouent. X***r, saloperie. Et il ne doit pas
y avoir un seul proc Intel sans bug non plus...
Enfin, les maigres détails du postmortem ne disent pas grand chose,
difficile de se faire une idée. "A key software component failure" ça
peut être Grok qui a halluciné la configuration des cores routers :)
Si on a des ressources pour avoir du postmortem, un moniteur intégré,
les bonnes règles de design, etc, ça aide. Si on a pas l'argent pour
anticiper et créer des ressources de debug, ça sera une belle boite
noire avec des messages à la con comme celui que tu cites. On en revient
à qui gère le projet (un gland ou pas un gland) et le budget alloué au
projet (suffisant ou pas). Enfin, pour la plupart des projets, c'est le
TTM qui compte (question d'époque) mais /le temps ne respecte pas ce qui
se fait sans lui/ (paul morand).
--
Stéphane Rivière
Ile d'Oléron - France
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
