Bêta-testeur recherché : Debian / Prestashop / Magento


Dernière modification le 28/03/2020 par Vincent G.
NB : il y a parfois des choses que l'on préfère ignorer, un certain nombre d'informations possiblement (très) anxiogènes sont dévoilées sur cette page. Elle va vous plonger dans l'envers du décor de l'ingénierie système et logicielle ainsi que du chaos qui y règne (bien que très organisé).

S'il est nécessaire que nos clients pilotes ainsi que les éventuels postulants à ce statut les entendent par souci de transparence, cela n'est pas forcément nécessaire pour nos clients non pilotes.

Nos clients pilotes (bêta-testeurs) bénéficient de remises commerciales allant de -20% à -70% suivant le risque d'instabilité plus ou moins sévère de leurs environnement pouvant inclure suivant le niveau de remise des "facilités" (maintenance applicative forfaitaire offerte, migration gratuite, accompagnement de refonte pris totalement en charge incluant des remaniements complets d'infrastructure, etc)

Cependant nos clients pilotes acceptent SANS RESERVE une décharge totale de responsabilité incluant un risque de perte irrémédiable de données sur 48h (au lieu de 24h) ce qui rend mécaniquement assez peu de projets éligibles à ce programme.

Malgré ces réserves, si vous souhaitez tout de même continuer à lire cette page, nous vous invitons à prendre en considération ceci :

Si nos propos rentrent en conflit avec d'éventuelles vérités que vous avez pu entendre ailleurs, nous vous invitons à considérer que compte tenu du parc que l'on gère (+250 serveurs), sur un secteur d'activité à haut risque avec bientôt 10 ans de présence : il est probable à hautement probable que nous ayons une légitimité et donc une autorité à énoncer d'éventuelles contre-vérités à ce que vous avez pu entendre. Il est important si vous souhaitez devenir pilote que vous les entendiez et les compreniez.

Il est aussi important d'avoir en tête que protéger les projets fait partie intégrante de notre ADN. C'est un prérequis indispensable pour exercer le métier d'infogérance. Nous mettons donc un point d'honneur à préserver le plus possible nos clients pilotes malgré les clauses fort probablement inaudibles des contrats qui les accompagnent (décharge / risque de perte de données).


Lexique (pour éviter les incompréhensions)

Pour la suite de cette page, nous allons employer des termes qui peuvent sembler excessif si on ne les mets pas en perspective et/ou s'ils souffrent d'une mauvaise compréhension, il est donc nécessaire de détailler 2 mots / expressions :

Le chaos : fait écho à la théorie du chaos - La théorie du chaos est une théorie mathématique et physique destinée à l'étude des systèmes dynamiques. (Source wikipedia)
Cela n'est pas nécessairement à connotation négative, beaucoup de choses sont organisées de manière pseudo-chaotique sans que cela ne soit nécessairement un problème. Cependant il est important d'en prendre la mesure et de mettre en place des outils avancés de contrôle.

Le désastre absolu : d'un point de vue technique, c'est l'itération d'une catastrophe. Si vous travailliez avec OVH en Novembre 2017, vous avez vécu (avec nous ?) une itération de cette gravité (la première en 20 ans), un double arrêt de service des deux plus gros centres de données d'Europe, des centaines de milliers de serveurs hors ligne.

De manière plus générale, il s'agit d'une itération d'un événement dramatique aux conséquences possiblement épouvantables pouvant engendrer des préjudices forts à extrêmes d'un point de vue financier. En Septembre 2019, nous avons frôlé ce type d'itération (bien que capturé à temps - nous y reviendrons ci-dessous)


Que se cache t'il derrière la création de programme informatique et le métier de "développeur" ?

Vous avez tous déjà rédigé des textes dans votre vie, plus ou moins longs, allant d'un devoir à l'école, d'un courrier à une administration ou encore d'une lettre à un tiers.

Hors relecture, l'humain étant imparfait, il est probable que vous ayez un taux d'erreur oscillant entre 0.1% et 2%.

Cela signifie que si vous écrivez 5 000 mots, vous allez faire entre 5 et 100 fautes.

Vous êtes susceptible de penser que cela n'est pas très grave, à juste titre, la langue Française et les usages tolérés en la matière ont une bonne probabilité ni de dégrader ni de transformer le sens de votre propos.

Votre histoire, votre vécu vous ont habitué à ces tolérances élevées, il est cependant important de comprendre que tout cela n'existe pas quand on exerce le métier de développeur.

Nous nous exerçons à la même tâche que vous, à savoir assembler des caractères les uns à côté des autres, formant un tout cohérent (une phrase pour vous, un algorithme pour nous) à ceci près que chaque caractère, autant que les gestes d'un chirurgien quand il vous opère à cœur ouvert, possède une probabilité non nulle de désastre absolu.

Nous vous déconseillons de voir ce propos comme excessif. Un point virgule manquant dans 49 milliards de caractères assemblés nous a tous coûté en tant que citoyen Européen des centaines de millions d'euro (crash d'une fusée Ariane 5).

Plus récemment, un bug dans une mise à jour d'un logiciel qui propulse un élément clé de vos applications Web (MariaDB - incident de Septembre 2019) a mis à mal toutes les mécaniques de sauvegarde, exposant tous les projets à une perte irrémédiable de données.

Il est fondamental de comprendre que les dizaines de milliers de bénévoles qui travaillent sur les logiciels libres (et très souvent gratuits) dont vous dépendez absolument tous ainsi que notre pool devops à TOUCHWEB avons un taux d'erreur non nul et que la constante augmentation de la complexité des systèmes ainsi que la densification des interdépendances logicielles engendrent de plus en plus de défis pour la détection des anomalies et la mise en place d'actions curatives.


L'informatique : comment imposer l'ordre dans le chaos pour minimiser le plus possible le risque de désastre absolu ?

Le logiciel (le superviseur) que nous qualifions depuis peu d'IA du fait sa capacité à analyser des situations complexes et à décider par lui-même de solutions adaptées possède plusieurs millions de caractères, il est le fruit de plus de 8 ans de travaux et subit en permanence des mises à jour (plus de 4 000 soumissions d'évolution par an - "commits" pour les plus techniques d'entre vous).

Comment fait-on en sorte que notre superviseur, assemblage de plusieurs millions de caractères, soit le plus stable possible ?

Grâce à des méthodes, très (nous insistons : TRÈS) rigoureusement respectées, incluant des préproductions multiples à zoosphères logicielles identiques (ou à défaut, le plus semblable possible) aux différents gabarits en production sur les différents systèmes d'exploitation, des phases de temporisation et d'observation, ainsi ... que des clients pilotes !

Notre métier en tant qu'infogérance et par extension DSI consiste à organiser et gérer ce chaos.


Un staging avancé et des phases d'observation sont indispensables pour garantir une stabilité qui se veut perfectible

Nous qualifions souvent le projet Debian (le système d'exploitation déployé sur vos serveurs) comme étant l'un des systèmes les plus fiables au monde. Pourquoi ?

Grâce à leurs méthodes de validation des évolutions des zoosphères logicielles imposant entre autres choses des environnements de test multiples dont les zoosphères logicielles (l'ensemble des daemons - petit nom des logiciels sous GNU/Linux) sont rigoureusement identiques et dont les configurations strictement conformes à celles des environnements de productions finaux où l'évolution sera déployée.

Debian impose aussi des phases de temporisation et d'observation (période de "gel") pour constater sur la durée que l'évolution n'engendre aucun dysfonctionnement.

Grâce à ce staging et ces temporisations, la quasi-totalité des dysfonctionnements sont détectés et corrigés limitant ainsi le plus possible le risque de désastre absolu (bien que l'histoire nous rappelle ponctuellement qu'il est impossible de neutraliser complètement cette probabilité qui est et restera toujours non nulle)

Nous nous sommes inspirés de l'ensemble de ces méthodes pour vous garantir une qualité de service qui se veut la plus irréprochable possible.

Si d'aventure certains ""techniciens"" ont pu vous dire que le maintien à jour d'un système se traduisait par un simple "apt-get update && apt-get upgrade", nous vous invitons à considérer ceci : aucun technicien de niveau confirmé à senior ne vous dira jamais cela, nous insistons : aucun. Il y a une raison à cela : tous les confirmés à seniors ont déjà vécu des désastres. Aucune mise à jour n'est anodine et absolument toutes présentent un risque non nul de désastre.

NB : Nous n'aborderons pas ici l'arbitrage des antagonismes générés par les mises à jour critiques de sécurité qui nécessitent des compressions drastiques de la durée des périodes de temporisation du fait de l'urgence de l'application en production des mises à jour, ce qui peut ponctuellement engendrer des difficultés.


Infrastructure de préproduction TOUCHWEB et clients pilotes - Processus détaillé

Notre infrastructure de préproduction est composée de 5 serveurs dont 2 unités physique et représente une charge annuelle d'environ 100 000€ HT (dont environ 1800€ de charge purement INFRA en partie cofinancé avec l'un de nos partenaires de confiance : CAD - Charly - sur la partie bare-metal), elle constitue un premier rempart au chaos (stage 1).

Elle engage avec les évolutions des applications système et du superviseur entre 130 à 170 heures par mois, c'est donc le centre de coût le plus important de notre agence d'infogérance et la clé de voute de la stabilité des infrastructures que nous supervisons.

Vous pouvez trouver hors de propos le fait de détailler les coûts de cette infrastructure et des temps qu'elle engage (consolidés avec les temps alloués aux évolutions du superviseur) cependant il est important de les avoir en tête car c'est grâce à cela que l'on vend un service qui se veut haut de gamme et en constante évolution via un process d'intégration continu bien rôdé.

C'est cette infrastructure de préproduction qui encaisse donc en priorité toutes les mises à jour à venir.

Suivant le niveau de risque et/ou l'urgence de l'application de la mise à jour, la durée d'observation sera variable sur cette infrastructure stage 1, entre quelques jours et pour certains développement plusieurs semaines.

Une fois la validation passée, ce sont les infrastructures des clients pilotes qui encaissent le stage 2, cette fois ci la temporisation est toujours de l'ordre d'une à deux semaines (hors cas particulier des mises à jour critiques de sécurité)

Il est très rare que l'on communique à nos pilotes la mise en place d'évolutions pour une raison qui nous espérons s'entendra : limiter au maximum le bruit relatif aux faux positifs.

Nous n'avons pas encore assez de clients et donc de clients pilotes pour mettre en place ce qui se fait assez couramment dans l'industrie pharmaceutique, à savoir : toujours bénéficier de deux groupes de tests, l'un qui prend un placebo sans effet, et l'autre qui prend le principe actif. Cela fait partie des évolutions à venir dans les deux prochaines années.

Pour l'heure, si nous ne constatons aucune anomalie et que nous n'avons aucun retour de nos pilotes, nous considérons l'évolution stable, et elle est donc appliquée sur l'ensemble de l'infrastructure (stage 3 - final)


Bêta-testeurs recherchés

La liste qui va suivre est en constante évolution en fonction des arrivées/départs des bêta-testeurs, nous nous efforçons de la tenir à jour avec le plus d'assiduité possible mais si vous souhaitez avoir un état réel à date, nous vous suggérons de nous appeler à ce propos.

Voici l'état des "places disponibles" de bêta-testeurs :

Sur la partie système d'exploitation :

Debian 8 : un bêta-testeur (plus de place possible pour cause d'obsolescence du système)
Debian 9 : quatre bêta-testeurs (aucune place disponible)
Debian 10 : deux bêta-testeurs recherchés (niveau de risque d'instabilité faible à moyen - infogérance offerte donc remise de -70% pendant deux ans garantis - obligation d'avoir une application Web sous l'un des CMS suivants : Wordpress, Magento ou Prestashop, 100% compatible avec PHP 7.3 à minima)


Sur la partie application Web :

Prestashop (1.6) : trois bêta-testeurs (aucune place disponible)
Prestashop (1.7) : un bêta-testeur (une place disponible prochainement sous Buster avec PHP 7.3)
Magento 2 : un bêta-testeur (aucune place disponible)

NodeJS 12 : un bêta-testeur (une place disponible)

Nous ne cherchons pas de bêta-testeurs sour Wordpress compte tenu de l'absence d'intérêt du fait de la faible complexité du CMS, ni sur Drupal du fait d'un volume de clients insuffisant.
Edit 19/03/2020 : Très exceptionnellement et du fait qu'aucun CMS n'est prêt pour Buster à part Wordpress à date, nous ouvrons un slot pilote pour Wordpress PHP 7.3 READY sous Debian 10.

Souhaitez-vous en discuter avec nous ?