<div dir="ltr">L'Overpass API allemande jsutement a planté aussi (à cause d'une perte d'alimentation chez l'hébergeur pourtant sensé avoir des alimentations de secours, ce qui a entrainé des pertes de donénes au redémarrage et l'absence de certains secteurs de données pour des fichiers qui pourtant étaient sensés avoir une taille supérieure: ces secteurs n'ont pas été écrits ni même marqués comme alloués alors que la taille de fichier était à jour, et cela a entrainé une erreur lors de la décompression remplissant un fichier décompressé de tas de zéros, à cause d'un autre bogue dans l'outil de décompression qui ne d'étactait pas l'erreur, puis des tonnes d'incohérences et un plantage dans le chargement des "diffs" pour la mise à jour de sa base, qui ensuite a planté).<div><br></div><div>En cause aussi le système de fichier qui n'a pas assuré la cohérence de l'ordre des écritures, ou bien des anomalies dans les pilotes qui n'ont pas assuré l'ordonnancement correct malgré le fait qu'il s'agissait d'un système de fichiers "journalisé" parait-il. Mais aussi en cause certains réglages d'optimisation des pilotes de disque (pour les performances au détriment de la cohérence) pour le réglage des caches, aussi bien ceux sur les contrôleurs des disques physiques que ceux des contrôleurs RAID ou les caches des interfaces SATA/PCI et sans doute aussi des bogues dans la gestion de l'énergie au sein des BIOS (ou pilotes de périphériques devant remplacer les fonctions du BIOS), et peut-être aussi des bogues dans la synchronisation des coeurs de processeurs récents</div><div><br></div><div>(il y a par exemple un bogue sérieux sur une ligne récente de CPU multicoeurs Intel parmi les plus chers de la gamme pour serveur, pour lequel des recherches compliquées ont été menées suite à un plantage inexplicable d'une machine virtuelle avec certaines séquences d'instructions générées par un compilateur JIT pourtant réputé: le compialteur n'est pas en cause, mais on a des cas critiques avec certaines séquences liées à certaines longueurs de "boucles" de code en fonction causé par une mauvaise synchronisation des pipelines de code suite à des états d'attente entre plusieurs niveaux de cache interne des processeurs: certains de ces processeurs ont été déclassés par Intel mais pas retirés du marché, en désactivant des coeurs et une partie des pipelines et des caches, mais en attendant certains fabricants OEM sont restés en attente de matériel et ont du revoir leurs livraisons ou changer de ligne de processeur, mais des serveurs défectueux ont déjà été livrés et Intel cherche toujours un moyen de détecter et prévenir ces bogues par un firmware... et il n'a encore rien publié car il semble qu'il n'y ait aucune façon simple de prévenir le problème autrement qu'en modifiant les logiciels utilisés et notamment en désactivant certaines optimisations de code dans les compilateurs, des optimisations pourtant éprouvées depuis longtemps)</div><div><br></div><div>(il y a un autre exemple récent ces jours-ci avec l'annonce récente par Microsoft qu'il ne supporait plus les mises à jours de Windows 10 sur certaines gammes récentes de processeurs très courants sur les tablettes et mobiles, à cause d'une fonctionnalité défaillante sur ces processeurs, pour laquelle Microsoft voulait ne plus supporter la prise en charge par logiciel via un firmware correctif)</div><div><br></div><div>(d'autres exemples comme ça il y en a des tas, les listes de bogues matériels des processeurs sont impressionnantes et notamment pour les processeurs les plus évolués devant équiper les serveurs qui en principe devraient être immunisés des problèmes liés à l'alimentation et supporter matériellement et par logiciel des systèmes de redondance permettant une reprise rapide, et de détection rapide et contournable des anomalies; certains de ces bogues existent même pour des processeurs équipant du matériel spatial, on a eu le cas avec plusieurs satellites pour la navigation qui sont hors d'usage du fait de graves anomalies sur leurs horloges qui sont tombées les unes après les autres et ne sont pas corrigeables ou réduisent considérablement leur précision au point que ces appareils se servent plus car on ne sait même corriger certaines anomalies de mesure en injectant des correctifs sur leur logiciel embarqué)</div><div><br></div><div>Conclusion: personne n'est à l'abri, des bogues il y en a partout, on doit faire avec et surtout on doit pouvoir les détecter à tout moment et tout niveau des traitements sans jamais faire confiance à ce qui est fait par une couche logicielle sensée être déjà complètement testée: en pratique il n'existe aucun système permettant de prouver qu'un code est correct et encore moins de savoir si leur conception initiale fixait toutes les contraintes vérifiables et on sait que certaines contraintes ne sont pas vérifiables en temps fini par un quelconque algorithme ou raisonnement mathématique le plus rigoureux (et il n'existe pas encore un seul langage de programmation permettant de vérifier toutes les contraintes nécessaires, même avec les langages dits "fonctionnels" qui ont tous des exceptions pour les rendre réellement utilisables et capable de répondre en un temps borné; tous les logiciels ont recours à des heuristiques pour répondre correctement à la majorité des cas mais on tombera toujorus à un moement donné ou un autre sur un cas supposé "rare" ou "exceptionnel" où la réponse donnée sera fausse pour des problèmes pourtant connus et dont la bonne réponse nous semblerait évidente, et des cas où nos supposées évidences ne sont en fait pas prouvées du tout mais juste des conjectures basées sur l'expérience qu'on connait car elle a été documentée quelquepart par quelqu'un, mais on a encore des tonnes de logiciels quji ne sont pas documentés du tout et où ceux qui l'ont écrit ne sont même plus là pour expliquer ce qu'il signifiait ou comment l'utiliser correctement et dans quelles limites).</div><div><br></div><div>Et là cela existe même en absence de tous actes de malveillance volontaire (qui sont également nombreux mais pas toujours détectés, ou sont malheureusement gardés secrets en supposant souvent à tord que cela évitera leur reproduction ailleurs et que les dommages subis par les uns sont supportables par les autres si on ne leur dit rien, à charge pour eux de découvrir et démontrer qu'ils ont été dupés ou trahis dans leur confiance): ce qui ressemble quand on le voit à un bogue inattendu (ou une cause naturelle imprédictible) peut ne pas être (et souvent n'est pas) le fruit du seul hasard et de la malchance, mais résulter d'une altération volontaire plus ou moins masquée ou le fruit d'une négligence de surveillance sur ce qui semblait ne pas être sensible ou important.</div></div><div class="gmail_extra"><br><div class="gmail_quote">Le 20 juillet 2017 à 21:40, François Lacombe <span dir="ltr"><<a href="mailto:fl.infosreseaux@gmail.com" target="_blank">fl.infosreseaux@gmail.com</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Hello Florian<div dir="auto"><br></div><div dir="auto">Niveau robustesse il n'y a pas 36 solutions, il faut un cluster avec un loadbalancer</div><div dir="auto">Avec un bon hyperviseur, tu detruit carrement une vm qui plante pour en remonter une aussi sec</div><div dir="auto"><br></div><div dir="auto">Mais ca reste couteux alors il faut deja adresser ses requêtes a différentes instances, au moins de et ru je pense</div><div dir="auto"><br></div><div dir="auto">Ce qui est sur est que ca va vite couter un peu de monnaie pour monter une infra disponible</div><div dir="auto">CDN & co ne seront efficaces que pour des requetes courantes et surtout abondamment utilisées, ce qui n'est majoritairement pas le cas</div><div dir="auto"><br></div><div dir="auto">A+</div><div dir="auto"><br></div><div dir="auto">François </div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">Le 20 juil. 2017 9:08 PM, "Florian LAINEZ" <<a href="mailto:winnerflo@free.fr" target="_blank">winnerflo@free.fr</a>> a écrit :<br type="attribution"></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div>Salut,<br></div>Aujourd'hui on a eu -encore !- une interruption de service sur l'overpass API. Cela a impacté l'appli Jungle Bus mais j'imagine tout un tas d'autres services qui se basent dessus.<br>J'ai l'impression que cela se produit souvent. Je constate dans mes projets que ce service reste le maillon faible technique et impose de mettre en place une pénible redondance.<br><br></div><div>Est-ce que vous sauriez à quoi cela est dû ? Quelles en sont les causes profondes ? <br>Y aurait-il une solution que nous pourrions mettre en place pour venir en soutien à nos amis les teutons qui gèrent le bouzin ?<br></div><div>Est-ce plutôt un besoin de dev ou d’hébergement ?<br></div><div>Bref, on résout le problème ? ;)<br></div><div><div><div><div><br>-- <br><div class="m_9086145334449602136m_-2512070747693718869gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">
<p style="margin-bottom:0cm">
</p><p style="margin-bottom:0cm"><font color="#333333"><font face="arial, helvetica, sans-serif"><font style="font-size:11pt" size="2"><b>Florian
Lainez</b></font></font><br></font></p><img src="http://twitter.com/favicon.ico"><a href="http://twitter.com/overflorian" target="_blank">@overflorian</a><br></div></div>
</div></div></div></div></div>
<br></div></div>______________________________<wbr>_________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.or<wbr>g/listinfo/talk-fr</a><br>
<br></blockquote></div></div>
<br>______________________________<wbr>_________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-fr</a><br>
<br></blockquote></div><br></div>