Plaidoyer pour les configurations par défaut

J’aime les systèmes d'exploitation (OS) neufs, sans bricolages, sans rien. Juste standards, avec tout ou presque par défaut. Ils ont plein d’avantages, peu de défauts.

Googlable par défaut

Dans nos métiers, la quantité astronomique d’outils et de technos sur le tapis nous oblige à développer une compétence spécifique : la recherche Google.

Un OS avec ses configurations par défaut nous aidera à trouver la bonne réponse sur StackOverflow, à tomber sur la bonne page de doc sans avoir à prendre en compte un contexte dément, à plus facilement tirer partie des formations.

Dans le monde éditeur, c’est également la garantie d’un support dans ses petits souliers.

Les OS sont bien testés dans les cas nominaux

Un OS par définition est un ensemble de choix techniques : telle libC, telle version du kernel, telle version de Nginx, telle configuration par défaut. Celui-ci est testé principalement dans sa version par défaut, avec quelques faibles variations.

Vous pourrez bien sûr vous en éloigner, mais faites-le en connaissance de cause : plus vous vous éloignez du standard, plus vous risquez de tomber dans une combinaison malheureuse.

Les écarts se payeront une fois, deux fois… cent fois

Un OS est de nos jours rarement un différenciant, quelque chose dont on attendrait monts et merveilles. N’essayez pas de transformer une bonne vielle ubuntu 16.04 en avantage concurrentiel…

On attend d’un OS qu’il ne nous surprenne pas chaque matin.

Si on décide d’installer tous nos applicatifs dans /monentreprise/app, pourquoi pas, je suis capable de le retenir assez facilement. Par contre à chaque nouvel employé, à chaque nouveau prestataire qui viendra et utilisera vos serveurs, ça sera un souvenir de votre entreprise, un élément de plus à retenir qui n’apporte rien.

Autre exemple, une policy SELinux fournie avec le package MySQL de votre distrib fonctionnera sans avoir à s’y plonger : si vous touchez les chemins, il va falloir prendre le temps et apprendre à debugger. En soi, ça n’est pas une mauvaise chose que de maitriser SELinux, mais l’objectif d’utiliser un OS du marché c’est de gagner du temps et de ne pas réinventer la roue.

C’est le prix pour s’asseoir sur les standards.

Jardiner des configurations noyau un peu obscures, c’est l’assurance d’une belle surprise pour celui, qui sans en avoir entendu parler au préalable, découvrira en production un effet de bord malheureux au beau milieu d’une astreinte. Ces configurations existent pour des raisons probablement justifiées et documentées dans un document planqué dans un SharePoint, mais comment lui reprocher de ne pas avoir absorbé celui-ci en entier ? Comme le disait Donald Knuth, “Premature optimization is the root of all evil (or at least most of it) in programming”.

Petite histoire sur le sujet, chez un de nos clients, les configurations des hyperviseurs ESX avaient été "sécurisées" et "optimisées". Ils avaient des problèmes de performance récurrents avec leurs disques. Plus personne ne savait vraiment le pourquoi du comment de ces options et n'osait donc les remettre en cause dans leur ensemble. Après quelques semaines d'essais/erreurs, ils se sont résolus à demander de l'aide à VMWare. Le consultant a remis les configurations par défaut, et en 1h d'intervention tout était résolu...

Pour continuer dans cette veine : si vous êtes sur du RedHat 7, mais que vous :

• packagez MySQL dans un .tar.gz au lieu de prendre le RPM des repos officiels,
• le mettez dans /maboutique/db,
• et que vous le gerez avec Supervisord parce que Systemd a mauvaise presse

vous allez laisser de belles surprises à vos successeurs et collègues.

En résumé, une modification dans une équipe centrale vous prendra 10 min, 1h, 1 journée grand maximum documentation comprise. Par contre, elle se payera en surprise pour tout les autres utilisateurs : une anecdote au mieux, un incident de prod au pire.

Ne me faites pas dire …

Il y a de multiples raisons valides pour diverger des valeurs par défaut, je pense notamment à des éléments de durcissement à des fins de sécurité, à des optimisations de performances génériques à certaines catégories de serveurs. Mais soyez conscient de ce coût, vous venez de commencer un fork de votre OS préféré.

Voulez vous vraiment vous payer le luxe de maintenir et communiquer tout cela ? Privilégiez toujours la connaissance de votre SI, des équipes autours de vous, de vos utilisateurs, à celui de votre OS maison.