Les Chatons (membres du Collectif des Hébergeurs Alternatifs, Transparents, Ouverts Neutres et Solidaires) veulent sauver Internet en proposant des services décentralisés pouvant remplacer ceux des GAFAM. Cependant, ils n’invitent pas qu’à utiliser leurs services1, leur projet est aussi de vous faire devenir vous‐même un fournisseur de services, pour héberger vos propres données et, pourquoi pas, celles de vos proches.

Cependant, il est normal que vous ayez une appréhension naturelle à vous lancer dans cette activité, parce que vous pensez que vous n’en avez pas techniquement la possibilité ou que les connaissances théoriques à maîtriser sont trop importantes. Sachez qu’il n’en est rien ! La complexité de l’activité n’est qu’une légende uniquement entretenue par les salariés du domaine qui veulent pouvoir négocier un gros salaire2.

Nous verrons dans cette dépêche les quelques concepts à maîtriser pour passer pour un professionnel, et les outils dont il faut s’équiper pour garantir sa tranquillité. Aucun nom de logiciel ou d’entreprise ne sera donné, le choix est immense dans le monde du logiciel libre : les connaisseurs sont invités à indiquer leurs technologies préférées dans les commentaires3.

Sommaire

Les trois grands concepts à connaître pour passer pour un hébergeur

Les architectes de plates‐formes de services vous impressionnent ? Et pourtant, ils n’utilisent que trois concepts pour monter une telle architecture, cela est tout à fait accessible à quiconque ayant un peu étudié le sujet.

Haute disponibilité : flambants neufs



La haute disponibilité correspond à la fiabilité de la plate‐forme dans le temps. Celle‐ci s’exprime en pourcentage de temps de bon fonctionnement sur une période donnée (par exemple, si la plate‐forme a été injoignable trois jours pendant un mois de trente jours, on dira qu’elle a une disponibilité de 90 %). Pour se la raconter, les administrateurs aiment bien compter en nombre de neufs pour indiquer ce qu’ils peuvent garantir. Ce qui donne les garanties suivantes :

garantie disponibilité sur 30 jours 3 neufs 99,9 % 43 min 12 s 4 neufs 99,99 % 4 min 19 s 5 neufs 99,999 % 25,9 s 6 neufs 99,9999 % 2,6 s

En général, dans le monde professionnel, on prend un engagement entre 3 et 4 neufs, un engagement de 5 neufs est envisageable pour certaines infrastructures. Quant à l’engagement de 6 neufs, qui existe sur le marché, celui‐ci est aussi appelé « il bluffe ».

Lorsque l’on parle de la haute disponibilité d’une plate‐forme, on peut se la raconter en utilisant le vocabulaire suivant :

haute disponibilité , high availability , HD ou HA : objectif de disponibilité permis par l’architecture mise en place ;

, , ou : objectif de disponibilité permis par l’architecture mise en place ; GTI ou Garantie de Temps d’Intervention : délai maximal entre le début d’une panne et le début de l’intervention d’un technicien ;

ou : délai maximal entre le début d’une panne et le début de l’intervention d’un technicien ; GTR ou Garantie de Temps de Rétablissement : temps maximal de remise en service après le début d’une panne ;

ou : temps maximal de remise en service après le début d’une panne ; MTTR ou Mean Time To Repair : temps moyen de remise en service après le début d’une panne ;

ou : temps moyen de remise en service après le début d’une panne ; SLA ou Service Level Agreement : engagements de service, incluant pour la partie technique la HD, la GTI, le MTTR et la GTR.

Scalabilité : aller plus haut !



Lorsque l’on monte une plate‐forme, surtout si celle‐ci est destinée à des services Internet, il n’est pas toujours facile de prévoir quel sera son usage. On peut, par exemple, avoir juste quelques utilisateurs au début, puis suite à une citation à la télévision, en avoir plusieurs dizaines de milliers qui arrivent rapidement. Dans le plan de haute disponibilité, on peut avoir mis en place une limitation en nombre (lorsque le plafond est dépassé, les nouveaux utilisateurs n’ont pas accès au service ou ont accès à une version dégradée), mais si la situation doit durer, il faut adapter la plate‐forme à cette augmentation de l’usage, afin qu’un maximum d’utilisateurs potentiels puissent accéder au service. La scalabilité correspond à la capacité d’une plate‐forme à s’adapter à l’évolution de son utilisation. Il y a quatre grands types de scalabilités :

la scalabilité 0 : la plate‐forme peut accueillir un maximum d’utilisateurs, et rien n’est prévu en cas de dépassement de ce plafond, on veille simplement à garantir que la plate‐forme saura encaisser jusque celui‐ci et qu’elle refusera de façon élégante au‐delà (page d’erreur explicative, redirection vers un autre service, appel à financement…) ;

: la plate‐forme peut accueillir un maximum d’utilisateurs, et rien n’est prévu en cas de dépassement de ce plafond, on veille simplement à garantir que la plate‐forme saura encaisser jusque celui‐ci et qu’elle refusera de façon élégante au‐delà (page d’erreur explicative, redirection vers un autre service, appel à financement…) ; la scalabilité projet : la plate‐forme n’est pas prévue pour encaisser un dépassement de plafond, mais est compatible avec d’éventuels projets d’évolution qui permettraient d’ajouter de la capacité ; la durée de mise en place de cette extension de capacité peut être ou non prévue contractuellement ;

: la plate‐forme n’est pas prévue pour encaisser un dépassement de plafond, mais est compatible avec d’éventuels projets d’évolution qui permettraient d’ajouter de la capacité ; la durée de mise en place de cette extension de capacité peut être ou non prévue contractuellement ; la scalabilité préventive : la plate‐forme est conçue pour pouvoir encaisser une importante évolution des besoins de capacité ; des systèmes d’alerte préviennent quand des ressources matérielles commencent à manquer pour pouvoir continuer à encaisser les prochaines augmentations afin que le matériel supplémentaire puisse être installé avant tout dépassement ;

: la plate‐forme est conçue pour pouvoir encaisser une importante évolution des besoins de capacité ; des systèmes d’alerte préviennent quand des ressources matérielles commencent à manquer pour pouvoir continuer à encaisser les prochaines augmentations afin que le matériel supplémentaire puisse être installé avant tout dépassement ; la scalabilité dynamique : la plate‐forme est située dans un écosystème permettant une extension bien supérieure aux besoins à venir, et toute son architecture est conçue pour s’adapter aux besoins au fur et à mesure que ceux‐ci augmentent ou baissent.

Exploitabilité : veiller sur les néophytes



L’exploitabilité d’une plate‐forme consiste à offrir un même niveau d’information pour toute personne ayant à intervenir dessus. Le meilleur moyen de la mettre à l’épreuve est d’accueillir un nouvel arrivant, parce qu’il souhaitera pouvoir travailler vite et il convient de ne pas le démotiver. Pour cela on veillera à :

qu’il sache quoi lire pour se familiariser avec la plate‐forme ;

qu’il comprenne comment celle‐ci est conçue ;

qu’il soit en mesure de faire des petites tâches ;

qu’il participe rapidement à la réparation de pannes et autres problèmes ;

qu’il puisse apporter sa pierre à l’édifice sans risque.

Si la documentation remplit ces conditions, on considérera qu’elle est en mesure de répondre à tous les besoins de toute personne ayant à intervenir sur la plate‐forme. L’objectif n’est pas seulement que les personnes puissent travailler seules, une documentation simple, à jour et utile ne peut être qu’une conséquence d’un travail d‘équipe efficace.

La conception d’une plate‐forme : état de l’art

Depuis les débuts des services Internet ouverts au public, la déclinaison pratique des trois grands concepts a évolué pour suivre les évolutions technologiques et managériales apparues au cours des années. Ainsi, pour concevoir sa plate‐forme on peut s’inspirer de ce qui a existé, selon ses moyens et compétences.

Années 1990 : la pl@te‐forme

Si vous retrouvez une vieille publicité avec un nom de service contenant un « a » remplacé par « @ », vous êtes en contact avec les années 1990, glorieuse période ayant vu décliner les disquettes, au début de laquelle fut inventé le World Wide Web (qui changera l’usage d’Internet), et pendant laquelle un gnou et un manchot se sont rencontrés pour former un couple qui mènera à une démocratisation de l’activité d’hébergeur1.

Haute disponibilité de la pl@te‐forme : quand le PRA tique

Héritées des grosses infrastructures de l’informatique de gestion, les méthodes de conception de plates‐formes Internet sont structurées autour de quatre axes pour assurer leur disponibilité :



la redondance : la perte d’un élément ne doit pas causer la perte de la plate‐forme, tous les éléments faillibles doivent être présents en double ; il y a donc des disques redondés dans les serveurs, deux alimentations électriques différentes et deux circuits de refroidissement dans la salle d’hébergement, et, bien sûr, deux accès au réseau au minimum ;

: la perte d’un élément ne doit pas causer la perte de la plate‐forme, tous les éléments faillibles doivent être présents en double ; il y a donc des disques redondés dans les serveurs, deux alimentations électriques différentes et deux circuits de refroidissement dans la salle d’hébergement, et, bien sûr, deux accès au réseau au minimum ; la duplication : une plate‐forme miroir de l’existante est présente et peut prendre le relais en cas d’indisponibilité de la plate‐forme nominale ; si possible, le miroir est installé dans un autre site géographique pour éviter qu’un élément puisse rendre indisponibles les deux plates‐formes en même temps (…) ; il est aussi souvent envisagé de réduire les coûts de la seconde plate‐forme, en n’y implémentant pas de redondance ou en réduisant sa capacité (le service étant dégradé en cas d’utilisation) ;

: une plate‐forme miroir de l’existante est présente et peut prendre le relais en cas d’indisponibilité de la plate‐forme nominale ; si possible, le miroir est installé dans un autre site géographique pour éviter qu’un élément puisse rendre indisponibles les deux plates‐formes en même temps (…) ; il est aussi souvent envisagé de réduire les coûts de la seconde plate‐forme, en n’y implémentant pas de redondance ou en réduisant sa capacité (le service étant dégradé en cas d’utilisation) ; la réplication : les mêmes données et services doivent être présents dans la plate‐forme nominale et celle de secours ; pour assurer cela, les opérateurs ont comme consigne de faire systématiquement toutes leurs interventions sur les deux plates‐formes (ce qui dans les faits ne peut pas toujours être fait, et la bascule se révèle pleine de surprises) et/ou une solution logicielle permet la réplication automatique du premier site vers le miroir (ce dernier ayant toujours des données en retard à l’époque, parce que les liens réseau étaient particulièrement coûteux et peu capacitaires) ;

: les mêmes données et services doivent être présents dans la plate‐forme nominale et celle de secours ; pour assurer cela, les opérateurs ont comme consigne de faire systématiquement toutes leurs interventions sur les deux plates‐formes (ce qui dans les faits ne peut pas toujours être fait, et la bascule se révèle pleine de surprises) et/ou une solution logicielle permet la réplication automatique du premier site vers le miroir (ce dernier ayant toujours des données en retard à l’époque, parce que les liens réseau étaient particulièrement coûteux et peu capacitaires) ; le plan de reprise d’activité : le PRA est une procédure indiquant comment basculer du site nominal à celui de secours (et inversement), dans les entreprises les plus sérieuses on le teste régulièrement (cela donnant souvent lieu à une non‐satisfaction faute de procédure claire et/ou de mauvaise réplication), mais en général on attend que ça casse pour tenter une bascule et regretter de ne pas avoir fait de tests plus tôt, pour améliorer la procédure et le miroir avant qu’on en ait besoin.

Scalabilité de la pl@te‐forme : TMC, t’es bath, t’es in



Les grosses infrastructures des années 1990 étaient démesurément coûteuses et représentaient un investissement sur plusieurs années, il n’était donc souvent pas envisageable de les faire évoluer pendant la période d’amortissement de cet investissement. La scalabilité 0 (souvent cachée par une pseudo‐scalabilité projet impossible à mener) est donc de mise, et seul un nombre d’utilisateurs défini sera destiné à être accueilli par la plate‐forme. Pour définir ce nombre d’utilisateurs, on procède à des tests de montée en charge (TMC), ceux‐ci consistant à :

définir les cas d’usage : les différents scénarios d’utilisation du service sont listés (par exemple, on aura le scénario de simple lecture, le scénario de connexion, le scénario d’édition, le scénario de recherche, etc.) ; anticiper l’usage : on définit quelle part de l’usage représentera chaque scénario, grâce à une méthode pifométro‐bayésienne et/ou une étude de marché poussée (par exemple : 90 % de lecture, 0,1 % de connexion, 5 % de recherche, etc.) ; simuler l’usage : à l’aide de logiciels spécialisés ou de programmes internes, on met en place des simulateurs des différents scénarios (permettant de lancer en un clic ou une ligne de commande n’importe quel cas précédemment défini), ceux‐ci intégrant une vérification du bon fonctionnement (validant que le résultat attendu est obtenu sans erreur) ; tirer ! : le tir de TMC consiste à exécuter les scénarios selon l’usage prévu (par exemple, sur mille scénarios lancés, il y en aura neuf cents de lecture et dix de connexion) pour voir combien d’utilisateurs en simultané peut accueillir la plate‐forme (quand les scénarios commencent à remonter des erreurs, on arrête le tir et on compte combien d’utilisateurs étaient simulés) ; les donneurs d’ordres ayant le plus de budget peuvent demander plusieurs tirs de TMC selon différents réglages de l’infrastructure et/ou répartitions des usages envisagés.

Exploitabilité de la pl@te‐forme : pas de choix, le DAT

« Dossier d’architecture technique » ou DAT : sous ce nom qui évoque des moments douloureux aux moins jeunes d’entre nous se cache un monstre documentaire. Il faut envisager la conception d’une plate‐forme comme un cycle long, faisant intervenir de nombreux acteurs (architectes, installateurs, développeurs, experts système et/ou réseau, etc.). Pour s’y retrouver dans tout cela, on demande à chacun de noter tout ce qu’il fait, pourquoi il le fait et comment il le fait. Puis, pour chaque tâche d’exploitation, on écrit également le quoi/pourquoi/comment, et pendant toute la vie de la plate‐forme on doit mettre à jour le DAT, au fur et à mesure qu’on apprend (méthodes de résolution des incidents les plus courants, correction du PRA suite à un test ayant mené à un échec…), que des mises à jour sont effectuées et que des éléments sont ajoutés ou retirés.

Le problème est qu’il y a de multiples intervenants devant intervenir sur le PRA, et qu’on se retrouve souvent avec plusieurs versions en parallèle de celui‐ci, qui seront fusionnées plus ou moins bien lorsqu’on voudra obtenir un document unique. Pire, les mises à jour prennent énormément de temps (il faut vérifier dans toutes les parties qu’une modification n’en entraîne pas d’autres), et les intervenants ne disposent pas de suffisamment de temps et de volonté pour mettre à jour ce document. Ainsi, on voit fleurir sur les bureaux des montagnes de papier portant la mention « ne pas jeter », avec toutes les notes nécessaires à la mise à jour du DAT… qui, bien entendu, ne sera jamais réalisée.

Années 2000 : la plate‐forme 2.0

Les années 2000, où chaque entreprise se devait d’avoir une stratégie numérique avec un nom finissant par « 2.0 », ont plutôt mal commencé dans le domaine de l’informatique, puisque les pauvres développeurs ont eu à travailler successivement sur la gestion du bogue de l’an 2000 et le passage à l’euro. Les métiers de l’informatique en général ont souffert de la grande chute financière du secteur des nouvelles technologies. Mais les services sur Internet ont continué à croître et il n’était plus envisageable pour une structure quelle qu’elle soit de ne pas être présente en ligne.

Haute disponibilité de la plate‐forme 2.0 : et on fait tourner les serveurs

Le matériel coûtant moins cher, on peut se permettre d’avoir plusieurs serveurs qui rendent le même service. Ainsi, en cas de perte d’un serveur il en reste toujours d’autres pour prendre le relai : un équipement ou un logiciel ayant la fonction de répartiteur de charge est utilisé pour diriger le service vers les seuls serveurs en état de fonctionnement. Les coûts d’interconnexion à Internet ayant également baissé, il est possible d’avoir une infrastructure distante répliquée en continu avec l’architecture nominale, ce qui permet d’éviter les problèmes de retard de réplication lors de l’activation du PRA.

Scalabilité de la plate‐forme 2.0 : des cas denses



Puisque l’on dispose d’un répartiteur de charge qui peut envoyer le service à plusieurs serveurs identiques, la scalabilité est en général gérée de façon simple en ajoutant des serveurs au fur et à mesure que le nombre d’utilisateurs augmente. Cependant, si l’on a beaucoup de services différents, on finit par constater que tous les serveurs ne sont pas chargés en même temps (les sites pros et les sites grand public, par exemple) ou de la même façon (certains chargent surtout la mémoire, d’autres les disques, d’autres le processeur, etc.). Des moyens de mettre ces différentes applications sur les mêmes serveurs se sont développés afin de « densifier » la plate‐forme 2.0 (machines virtuelles et conteneurs) : on peut ainsi utiliser au mieux les capacités totales.

Exploitabilité de la plate‐forme 2.0 : un jeu d’enfants

Les années 2000 furent celles de la popularisation du wiki, la révolution du travail en équipe : en général, la première version saisie rappelle un DAT, mais sa mise à jour est tellement simple que c’en est fini des papiers « à traiter plus tard » qui s’entassent. Chacun peut créer de nouvelles pages hors pseudo‐DAT avec des informations plus opérationnelles qu’architecturales (comment réparer un service particulier lorsqu’il a un problème, comment vérifier un bon fonctionnement, etc.), et tous les intervenants sont en mesure de mettre à jour la documentation pendant toute la durée de vie de la plate‐forme 2.0 (ajout et suppression de serveurs, densification, modification de la méthode de répartition de charge, etc.).

Années 2010 : Cloud Agility Platform On The Enfuming

Si l’on travaille dans les services Internet dans les années 2010, il est absolument nécessaire d’utiliser des mots (pseudo‐)anglophones à la mode, surtout si c’est pour les détourner de leur sens (ici on va utiliser l’amphigouri « Cloud Agility Platform On The Enfuming », qu’on résumera par l’acronyme « CAPOTE »). Ces années voient arriver une augmentation exponentielle des usages d’Internet, avec la multiplication des téléphones mobiles intelligents et des objets connectés. Par ailleurs, ce sont les années de la centralisation des services sur Internet, ceux‐ci se retrouvant essentiellement dans les mains des GAFAM. Heureusement, cela provoque une prise de conscience qui redonne de la vigueur aux micro‐acteurs comme les CHATONS, et laisse encore un peu d’espoir pour les années 2020.

Haute disponibilité de la CAPOTE : dans ton centre

L’augmentation continue de la capacité des liens Internet permet de gérer un site distant comme un site proche, si bien que la notion de PRA n’a plus de sens. Les services et les données sont répartis entre plusieurs centres de données, et si l’un d’entre eux est perdu, ça ne pose pas de problème, puisque d’autres continuent à rendre le service. On comprend pourquoi certains opérateurs annoncent pouvoir garantir des taux de disponibilité paraissant incroyables : le principe de coupure de service n’existe théoriquement plus.

Scalabilité de la CAPOTE : Jawad Academy



Alors que dans les années 2000 on avait commencé à virtualiser les serveurs pour optimiser l’usage de nos serveurs physiques, dans les années 2010 on va un cran plus loin : les serveurs physiques et virtuels sont totalement décorrélés. Pour créer un serveur virtuel, on indique seulement au « cloud » les caractéristiques du serveur souhaité et celui‐ci est implémenté automatiquement sur un serveur physique dans un centre de données quelconque, sans que l’on ait à s’en soucier2. Le serveur virtuel ne sait pas qui l’héberge, et les serveurs physiques ne savent pas ce qu’ils hébergent, tel un propriétaire qui louerait un appartement sans se soucier de qui sera dedans.

La création de serveurs devient un simple appel à une interface de programmation applicative, gérée depuis les logiciels métier des créateurs et exploitants d’infrastructure. De nombreuses expressions en anglais sont utilisées pour vendre ce type de services, finissant souvent par « … as a service » ou « … as code ».

Exploitabilité de la CAPOTE : un outil bien en main

Comme l’infrastructure est de plus en plus gérée comme du code, les hébergeurs ont commencé à utiliser les outils des développeurs, notamment les forges logicielles, dans lesquelles on peut stocker toutes les informations permettant de :

décrire l’infrastructure, à l’aide de fichiers de description d’état cible utilisés par des logiciels pour installer et contrôler automatiquement des machines stockées dans le dépôt logiciel ;

suivre les modifications, et mettre en place des processus de validation ;

répertorier les incidents et demandes des utilisateurs avec le système de tickets ;

gérer plus finement les droits de chacun des administrateurs avec les concepts de groupe ;

documenter au fur et à mesure en remplissant le fichier de documentation associé à chaque création ou modification.

Comme dans les projets logiciels, si l’organisation humaine n’est pas pensée pour utiliser ces outils (auto‐validation des changements, absence de relecture des documentations, faible valorisation du traitement des tickets), ceux‐ci peuvent créer de nouveaux problèmes plutôt que d’en résoudre, ajoutant de la complexité par rapport aux gestions historiquement manuelles des configurations et documentations.

Fin de la conception : accouchons de notre plate‐forme

L’infrastructure est en place, celle‐ci a des conditions de disponibilité et de scalabilité connues, et bénéficie d’une exploitabilité optimale. Maintenant, il vous faut l’exploiter et, pour cela, quatre plans doivent être obligatoirement mis en place dès le premier jour :

la supervision ;

la métrologie ;

la sécurité ;

la sauvegarde (même si l’on verra que c’est sans intérêt).

Supervision : le super‐héros de la tranquillité



Le plan de supervision doit prévoir des outils qui permettent de valider en continu :

l’état du matériel (défaillance d’un disque, port réseau déconnecté…) et de son environnement (température de la salle trop élevée, intrusion dans un espace protégé…) ;

(défaillance d’un disque, port réseau déconnecté…) et de son environnement (température de la salle trop élevée, intrusion dans un espace protégé…) ; l’état du réseau (lien perdu, trafic inhabituel, répartiteur de charge défaillant…) ;

(lien perdu, trafic inhabituel, répartiteur de charge défaillant…) ; l’état du système (espace disque, utilisation processeur, mémoire, etc.) ;

(espace disque, utilisation processeur, mémoire, etc.) ; l’état des applicatifs (serveur de courriel, serveur de base de données, etc.) ;

(serveur de courriel, serveur de base de données, etc.) ; l’état du service, qui est la seule chose qui intéresse les utilisateurs, en trouvant des moyens de tester celui‐ci de bout en bout (par exemple en simulant le comportement de la plante connectée qui veut moins d’eau et plus de soleil).

Métrologie : on va prendre des mesures



La métrologie se présente en général sous forme de graphes. Ces graphes permettent de voir dans le temps les usages système, applicatifs et services de son infrastructure. Cela permet de faire de l’analyse à chaud (si un disque est plein, on n’interviendra pas de la même façon en sachant que ça a descendu progressivement pendant des mois que si c’est descendu en une fois le jour même) ou à froid (si un incident survient, on pourra trouver ce que l’on aurait dû superviser pour le détecter avant une coupure de service).

Les outils de métrologie récents permettent de faire de la corrélation de données, pour pouvoir, par exemple, surveiller ensemble l’utilisation des processeurs, le nombre de connexions à la base de données et le temps de réponse du service, cela évite de devoir utiliser des méthodes artisanales de superposition des graphes utilisées jusque dans les années 2000. Il est à noter que l’on peut utiliser le même outil pour la supervision et la métrologie, ou que l’outil de métrologie peut appeler l’outil de supervision pour alerter en cas de mesure anormale.

Sécurité du réseau : tes parents avaient raison

Une vision très fausse que l’on peut avoir en montant son infrastructure, est de constater qu’Internet concentre les méchants, et notre plate‐forme les gentils, mettons un grand mur entre les deux et on sera à l’abri… Mais de quel côté sont vos utilisateurs ? Comment savez‐vous que vos services ne sont pas utilisés pour faire le mal ?

Une autre vision est portée par les commerciaux de certaines entreprises. C’est simple : on doit arrêter les méchants et laisser passer les gentils, avec un super outil bien cher, vous pourrez dormir tranquille. Sauf que si avec un outil vous pouvez détecter les méchants sur Internet, il ne devrait plus y en avoir, non ?

Pour commencer de la sécurité réseau, mettez simplement un pare‐feu qui bloque tout, sauf ce qui est nécessaire au bon fonctionnement du service. Quel que soit le sens de passage, votre équipement doit suivre le conseil de grand‐maman : « on ne doit pas parler aux inconnus ».

Sécurité de la plate‐forme : garde à vous !

il faut faire les mises à jour de sécurité de son système, systématiquement ; le mieux pour ça est d’utiliser une distribution GNU/Linux disposant d’une équipe sécurité réactive ; il faut faire les mises à jour de sécurité de ses applicatifs, systématiquement ; on n’installera pas de logiciel non suivi par une équipe de sécurité (si vous avez fait le choix de compiler un logiciel vous‐même, vous devrez suivre les mises à jour de sécurité vous‐même), le mieux est encore d’utiliser les logiciels portés par une distribution GNU/Linux disposant d’une équipe sécurité réactive ; il faut limiter au maximum les droits des administrateurs (l’expert en courriel n’a pas à redémarrer la base de données), utilisateurs (les espaces de chacun doivent être cloisonnés) et applications (l’outil de publication de contenu ne doit pas pouvoir accéder à la métrologie) ; il faut éduquer les utilisateurs et administrateurs, en suivant par exemple une charte ; les CHATONS tiennent beaucoup à cet aspect, mais il faut aussi y veiller autant que l’on peut en milieu professionnel, même si une mauvaise relation opérateur‐client rend cela difficile ; il ne faut jamais oublier que derrière quelque chose de visiblement mignon, peut se cacher quelque chose de bien plus inquiétant : tout ce que vous ne connaissez pas est un danger.

Sauvegarde de la configuration (comme une espadrille : rien à cirer)

La sauvegarde de la configuration permet d’espérer que, si l’on a un gros crash, on sera capable de reconstruire partiellement ou totalement la plate‐forme en s’aidant des données sauvegardées. Il existe quatre solutions de sauvegarde de la configuration :

tenter de deviner tous les répertoires et fichiers contenant des éléments de configuration, et les sauvegarder… mais on est à peu près certains d’en oublier ;

sauvegarder totalement à partir de la racine chaque serveur, au moins on est sûr d’avoir les configurations dans la masse… ça peut fonctionner, mais c’est extrêmement coûteux ;

ou peut compter sur le DAT ou le wiki pour contenir toutes les configurations à jour… pour plus de sécurité, il est prudent de demander au père Noël de veiller à leur mise à jour ;

si toute la configuration est dans une forge logicielle, il suffit de sauvegarder la forge logicielle et, mieux, on peut s’attendre à ce que tous les administrateurs disposent d’au moins une copie des configurations pour pouvoir travailler… si l’on dispose d’un outil de déploiement automatique des configurations, remonter la plate‐forme peut ne nécessiter que quelques minutes.

Vous pouvez suivre ces conseils, mais de toute façon la sauvegarde de la configuration n’est d’aucune importance.

Sauvegarde des données (comme la cire chaude : ça nous fait une belle jambe)

On peut ne pas sauvegarder les données et demander aux utilisateurs de le faire. Cette méthode est la moins coûteuse, et si vous lisiez les CGU de tous les services que vous utilisez, vous sauriez que c’est un usage courant pour les services grand public.

Si l’on sauvegarde les serveurs à la racine pour la configuration, cela fera également une sauvegarde des données. Cependant la sauvegarde des fichiers de certains outils comme les bases de données ne permettront pas de reconstruire une base, parce que les données seront corrompues : il faut dans ce cas utiliser un outil spécifique qui pourra générer un format d’exportation.

Il faut donc identifier les données à sauvegarder, puis vérifier si une simple copie de fichiers suffit ou s’il faut exporter les données avec un outil spécifique. Enfin, à quoi bon faire cela ? Après tout, la sauvegarde des données n’a pas le moindre intérêt.

La sauvegarde : tout à voir avec la choucroute



On pourrait parler des différents types d’outils de sauvegarde, mais on n’en a rien à secouer. On pourrait aussi parler de l’archivage qui est destiné à stocker pendant une certaine durée des données qui ne sont pas destinées à être modifiées (archivage légal, fermeture d’un service, etc.), mais on s’en câlisse. Pourquoi donc autant de mépris pour la sauvegarde, alors qu’elle semble absolument nécessaire aux utilisateurs comme aux administrateurs ? Pour une simple raison : une donnée sauvegardée n’a de l’intérêt que si l’on sait la restaurer, autrement dit ce que les utilisateurs et administrateurs demandent, ce n’est pas de sauvegarder, mais de pouvoir restaurer le jour où on l’en a besoin ! Alors, intégrez des tests de restauration dans la supervision, et vous pourrez commencer à trouver un intérêt à la sauvegarde.

Conclusion : alors, tu montes ?

Si vous avez à peu près tout compris de ce billet, vous avez toutes les compétences théoriques pour devenir hébergeur, et vous pourriez même faire illusion devant certains recruteurs. Il ne reste plus qu’à acquérir les compétences techniques.

Monter sa propre plate‐forme

Monter sa propre plate‐forme pour héberger des services non critiques est un bon moyen pour commencer à apprendre seul comment gérer une infrastructure. Au niveau matériel, on peut faire ça sur son PC ou sur un nano‐ordinateur dédié. Et si l’on ne veut pas dépendre de sa connexion à Internet, il existe de nombreux services proposant des locations de serveurs (physiques ou virtuels). Côté logiciel, le plus simple pour commencer est d’utiliser une distribution YunoHost destinée spécifiquement aux hébergeurs débutants.

Intégrer une équipe existante



Sur le site des Chatons, on peut trouver une carte de tous les chatons existants. S’il y en a un près de chez vous, vous pouvez essayer de le contacter pour rejoindre leur équipe technique.

Autre solution, vous pouvez proposer au Chapril (chaton de l’April) de gérer un service (ou autant de services que vous voulez, mais vous pouvez n’en gérer qu’un si plus vous effraie). Il suffit pour cela de s’inscrire à la liste de discussion et de se présenter, tout le monde est bienvenu.

En faire son métier

Si vous comptez travailler dans ce domaine, sachez qu’il est fort probable que vous ayez un entretien et/ou un test technique pendant la phase de recrutement, il est donc déconseillé d’y aller au bluff. Ce qui fera la différence entre plusieurs candidats sera souvent l’expérience, même si celle‐ci est associative ou solitaire.

Toutes les images contenues dans cette dépêche peuvent, comme le texte, être distribuées sous licence CC-BY-SA. Celles‐ci sont dérivées des œuvres de Kotivalo, Hell Pé, Bibi Saint‐Pol, Bug_de_l'an_2000, Luigi Chiesa, Darby, GitLab, RRZEicons, Georges Biard, le projet Debian, Matt92300, Dark Attsios, Arnaud 25, Sinovoip, A. Lorenzo et John Markos O’Neill