Remarque préliminaire

Cet article et ceux qui vont suivre dans cette série ne sont pas (directement voire du tout) du Perl. Seulement, il se trouve que les Mongueurs de Perl sont aussi pour certains des administrateurs système, responsables de centres serveur, consultants infrastructure, etc. Bref, de beaux endroits pour faire du Perl, mais aussi pour utiliser d’autres Logiciels libres, et ce, dans un cadre de production informatique. De quoi retirer des expériences que nous nous proposons de partager avec vous.

Définitions

Tout d’abord commençons par une définition : qu’entend-on par " production " ? Dans le cycle de vie d’un système d’information, on observe souvent plusieurs étapes :

La phase de spécification ;
Le développement ;
L’intégration (éventuellement précédée d’une phase d’architecture) ;
La recette (fonctionnelle et/ou technique) ;
La mise en production (ou exploitation) ;
La maintenance ou MCO (maintien en condition opérationnelle) ;
La fin de vie, qui peut amener du travail pour désengager les données ou les équipements.

Je vous passe les détails sur les phases de spécification (ou analyse) et de développement (voir les pages suivantes et précédentes du magazine). La phase d’intégration permet de vérifier que le logiciel inséré dans le système d’information fonctionne conformément aux attentes techniques, que les procédures d’exploitation sont conformes aux standards établis par l’équipe de production, etc. Une fois la recette effectuée, à savoir, le procès-verbal de recette signé ou approuvé (l’application est ainsi jugée bonne pour le service), l’application part en production ou exploitation. J’utiliserai par la suite indifféremment les deux termes. Pour conclure, la phase de production pour une application, c’est quand l’arrêt de cette application implique une perte d’exploitation (au sens comptable du terme) pour l’entreprise ou un manquement à ses missions pour un organisme public. Par exemple, lorsqu’un système de facturation est en panne. On peut même parler de production pour des systèmes dédiés au développement : imaginez le coût d’un développeur qui perd sa journée à attendre que le serveur de base de données qu’il utilise redémarre. Imaginez quand il n’est plus seul, mais que ces développeurs sont 50 ou 100...

De quoi a-t-on besoin, et pour faire quoi ?

Une application, c’est a minima un serveur pour l’héberger. Les applications étant maintenant souvent communicantes, nous verrons d’autres serveurs venir se greffer sur l’environnement d’exploitation. Ces serveurs hébergeront des applications dites " périphériques " ou " de servitude ", afin d’assurer certaines fonctions communes (comme un serveur d’échange de fichiers, les miroirs de CPAN et des patches de votre distribution Linux) à toutes les applications ou serveurs de la plate-forme. GNU/Linux a un gros rôle à jouer sur ces serveurs car, dans les faits, les serveurs de servitudes seront nombreux, plus nombreux que ceux des applications, au moins au début. De plus, si l’on se place dans une optique de segmentation des accès aux applications, de par leur criticité, la confidentialité des données, ou tout simplement les recommandations de l’éditeur de progiciel, il va nous falloir mettre très fortement l’accent sur la sécurité. Cela va induire une multiplication des serveurs due à la spécialisation de ceux-ci (une tâche par serveur), pour limiter les effets de bord en termes de sécurité. Ces systèmes, il va falloir les gérer. Il va falloir aussi prendre en compte leur environnement : on risque de ne pas les avoir à côté de soi, mais plutôt dans une salle blanche distante et sécurisée. Cela exclut quasiment d’office les serveurs qui ont besoin d’une interface graphique pour être administrés. Disons que dans l’idéal, il va falloir limiter leur présence, nos clients voyant un intérêt au clickodrome : pas besoin de connaître des commandes en ligne pour l’administrer. C’est malheureusement une vue à court terme, qui permet de démarrer rapidement un projet (pas besoin d’un administrateur système lors du développement, pas d’étude d’architecture à faire), mais qui déplace le problème après la recette, lors de l’exploitation. D’autant que certains fournisseurs ont le même raisonnement : leurs produits ne sont disponibles que pour le système de Microsoft. C’est ainsi qu’à ce premier argument (la capacité de gestion des systèmes, impliquant un Unix), on ajoute un second : le budget. Car nous sommes dans une entreprise, avec la pression commerciale et ses réductions de budget. Pas besoin non plus de payer des matériels propriétaires (même si certains sont très intéressants ou l’ont été) lorsqu’une architecture Intel offre un même niveau de disponibilité (on parle bien ici de serveurs, et non de PC trouvés chez l’assembleur du coin), de meilleures performances, le tout pour un coût moindre. L’avantage de ces serveurs est, en plus de leur prix abordable, la débauche de fonctionnalités qui vont nous simplifier la vie (RAID matériel, déport de la console graphique vers un port série ou un port Ethernet, diode et énergie pilotable à distance pour repérer le serveur dans une baie, etc.) Leur inconvénient est donc leur prix qui, s’il est réduit, peut tout de même grimper avec les options. Cependant, gardez à l’esprit que ces serveurs sont souvent sous garantie pièces et main d’œuvre pendant 3 ans, et qu’on peut réduire le délai d’intervention en payant une redevance supplémentaire. Mais franchement, vu le coût de ces serveurs et des pièces détachées, il est souvent plus avantageux d’acheter un serveur supplémentaire par modèle sur site pour pièces de rechange que de prendre une maintenance 24h/24. Cela dit, " votre kilométrage peut varier ". Les Unix propriétaires seront donc limités eux aussi à ce qu’on leur demande : faire tourner des applications propriétaires. Et ces applications tout comme le constructeur des matériels sur lesquels elles tournent rassurent un client. Cela nous amène à un constat : nos clients sont encore frileux à mettre en place du Logiciel libre en production. Mais quand nous leur aurons démontré que ce Logiciel libre permet de moindres coûts, de meilleures performances, alors peut-être nous demanderont-ils un jour de passer sur un système libre. Et quand les applications de gestion commerciales seront mûres, dans quelques années, alors, pourquoi pas ? Mais revenons au présent (ou plutôt au passé proche). Nous allons donc avoir à gérer :

De la sécurité (pare-feu, et autres empêcheurs de pirater en rond) ;
Des systèmes ouverts libres et non libres ;
Des systèmes fermés ;
Des applications libres et non libres.

Et pour finir, nous allons être mesurés à l’aune d’un contrat de niveau de service, en anglais un SLA (Service Level Agreement). Voici quels vont donc être nos critères pour toutes les applications de servitude qui vont permettre le choix d’une solution libre ou propriétaire :

Fonctionnalités ;
Qualité du logiciel ;
Coût d’acquisition et de maintenance (il n’est pas rare de voir des logiciels propriétaires coûter annuellement en maintenance de 15 à 20% du coût initial d’acquisition) ;
Coût d’administration (jours et hommes nécessaires à son bon fonctionnement chaque mois) ;
Rapidité de mise en œuvre : pas besoin d’avoir la commande, la faire valider, attendre le chèque, l’envoyer, puis attendre la réception des médias, puis des clés d’activation des logiciels pour commencer à travailler ;
Présence, qualité voire traduction française de la documentation ;
Possibilités d’extension ;
Et dans une certaine mesure, capacité de montée en charge.

La notion de coût et de budget va aussi impliquer une méthode de travail particulière. En effet, si les coûts de licence du libre sont moindres qu’avec le logiciel propriétaire, il n’en va pas forcément de même avec le coût humain de mise en œuvre (on parle de la charge de travail, parce que personne ne fait encore de dépression :-). L’offre pléthorique du Logiciel libre ne va pas sans problème : il existe non seulement énormément de logiciels qui font plus ou moins la même chose (TIMTOWTDI), mais pour ceux qui sont complémentaires, il va falloir les intégrer les uns aux autres. Il va aussi nous falloir faire beaucoup avec le Libre, sans pour autant perdre du temps en développements très longs, sauf en cas de besoin spécifique. Nous allons donc mettre aussi l’accent sur la facilité d’utilisation, la qualité de la documentation, et les technologies employées, essentiellement en ce qui concerne les interfaces graphiques (du web partout).

Choix du logiciel adapté

Le choix commence avec l’identification de nos besoins. Besoins actuels, mais aussi besoins futurs. Car il va nous falloir garder nombre de portes ouvertes en cas de fausse route.

Recherche des solutions possibles, mais de façon rapide : notion de temps importante car charge de travail énorme. Mieux vaut partir sur un logiciel qui remplit 90% des besoins, quitte à en changer ou à le développer par la suite, que de chercher pendant 3 semaines voire plus celui qui remplira tous nos besoins, mais qui nous aura fait perdre énormément de temps. Un des avantages du Logiciel libre est son évolution rapide, et on peut souvent parier que nos besoins sont identiques ou similaires à ceux des développeurs d’un Logiciel libre ;
Choix du produit, montage d’une maquette rapide, prise en main de l’outil, diffusion de la connaissance : pas plus de 2 jours, car, encore une fois, il ne s’agit pas de perdre de temps. Prendre toutefois le soin de noter : la façon de mettre en œuvre (on travaille dans un environnement pas encore complètement structuré et très évolutif, on aura donc à réinstaller ou migrer la solution), le minimum pour administrer correctement la solution retenue (sauvegarde, gestion des accès). Ce dernier point est très important, car il nous est arrivé de retrouver 4 mois après la mise en œuvre d’un logiciel (Cacti) un fichier de log (toutes les prises de mesure) de plus de 500 Mo. Ça s’est résolu rapidement, mais vérifier la présence de ce genre de surprise ;
Pérennité du logiciel. En effet, même si nous avons les compétences pour maintenir le produit, nous n’en avons pas toujours le temps, les moyens ou la volonté. Il vaut donc mieux partir sur un logiciel qui est maintenu, et auquel nous pouvons apporter des choses, que de supporter à nous seuls la maintenance d’un Logiciel libre. Pour une SSII dite " classique " (pas une SSLL), cela signifie faire du propriétaire...

Ce sont donc tous ces critères qui nous ont fait adopter trois logiciels propriétaires pour les servitudes :

La supervision et surtout cartographie du réseau (je sais, cette cartographie ne sert à rien, mais ça en jette quand même auprès d’un client. Oui, il existe quelques solutions libres pour ça, tels Cheops ou un Nagios bien paramétré) ;
Les sauvegardes : nous avons d’énormes quantités de données à sauvegarder, et un futur proche nous fait entrevoir le besoin de sauvegardes à chaud de notre progiciel. Nous avons donc pris un logiciel de sauvegarde pour lequel il existe des agents à chaud, donc propriétaires ;
Le moniteur de transferts de fichiers : pas de solution directement libre, surtout lorsqu’on va commencer à communiquer avec des banques, sur des protocoles pas rencontrés sur des Logiciels libres, tels PeSIT, ETEBAC3/5 ou encore Odette.

Tout le reste est basé sur du Libre. Pour notre plus grand bonheur. Et le choix du libre n’est pas un choix par défaut, en raison de problèmes de crédits ou non, mais tout simplement parce que ces Logiciels libres rendaient le service attendu. Le jour où ils ne le rendront plus ou que les attentes auront évolué, trois possibilités s’offriront à nous : attendre que le logiciel évolue, éventuellement avec nos encouragements, étendre le logiciel nous-mêmes ou éteindre le logiciel et le remplacer par un autre, de préférence libre. C’est ce qu’on pourrait appeler une polyandrie vis-à-vis du Logiciel libre. Et ce alors que les logiciels propriétaires ne nous permettent qu’une simple bigamie, voire une monogamie, dont le divorce peut être exclu du fait de la rareté des éditeurs ou de l’ouverture des formats d’échanges (fichiers et protocoles).

Méthodologie

Une des premières choses qui s’apprennent dans la douleur sur une production est l’erreur humaine. Combien ont pu passer des nuits entières à essayer de corriger des problèmes qui ne seraient pas survenus avec un peu plus de méthode ou si l’impétrant s’était accordé le temps de la réflexion ? La méthodologie est donc essentielle, et d’autant plus nécessaire que l’équipe de production s’agrandit. Nous distinguerons trois types de méthodologies, complémentaires :

La méthodologie personn elle :

De même qu’on nous apprenait étant petits à tourner sept fois la langue dans notre bouche avant de parler, il faudra nous (ré-)apprendre à réfléchir à ce que l’on fait, et pourquoi on le fait. Je ne reprendrai pas l’exemple de celui qui redémarre un serveur pour résoudre un problème en espérant que cela résoudra le plantage. C’est typique d’un enfant qui comprend rapidement que sa console de jeu est plantée, et qui n’a pour seule issue que de l’éteindre et de la rallumer. Idem pour une certaine catégorie de systèmes d’exploitation pour serveurs qui sont suffisamment robustes pour supporter plusieurs redémarrages hebdomadaires. Mais ce n’est pas de la faute de leurs administrateurs, ils n’ont pas (toujours) les moyens techniques de faire l’analyse des problèmes rencontrés. Rebooter un serveur Unix n’a jamais résolu un problème. Que ce soit dit ! De plus, toujours en termes de méthodologie personnelle, il faut s’astreindre à plusieurs comportements :

1. Pas de modifications de configuration d’un serveur critique sans avoir au préalable testé sur un serveur du même type, mais non critique ;
2. Pas de modifications ou d’opérations sur des serveurs avant un week-end, sans avoir prévu de surveiller les effets de bord ce même week-end. Sinon, il y a de fortes chances que le lundi suivant soit un lundi noir... ;
3. Toujours faire une copie de sauvegarde des fichiers de configuration qui vont être modifiés. Soit par cp, soit par d’autres biais tels que des gestions de configuration logicielle (GCL en français, SCCS, RCS, CVS, SVK, Subversion et bien d’autres étant des outils tombant (!) dans cette catégorie). Idéalement, tout cela sera bien évidemment centralisé ;
4. Enfin, et c’est du vécu, on ne modifie pas un fichier de configuration influant sur le redémarrage d’un serveur sans vérifier ce redémarrage dans la foulée. Ça permet d’éviter qu’un serveur reboote tout seul suite à une panne de courant, et perde sa configuration réseau parce qu’une erreur de syntaxe a été commise là où il ne fallait pas. Ou encore de découvrir 3 mois plus tard qu’un serveur ne reboote pas sans qu’on se souvienne ce qui avait été fait et qui peut être à l’origine du problème. Ça m’est arrivé, et dans l’urgence, avec une gateway SSH dont j’avais changé quelques jours auparavant de boot-loader (LiLo vers GRUB). Et de découvrir de la pire façon que le GRUB fourni ne supportait pas les noms de devices autres que ~~/dev/[sh]d[a-h][0-9]~~... Dommage lorsqu’on travaille avec des cartes RAID matérielles...
5. Et j’oubliais ce conseil-ci, corollaire du précédent : ayez TOUJOURS (je n’aime pas hurler, mais il le faut bien de temps en temps) les CD bootables à proximité de vos serveurs. Car charger une image ISO d’un serveur sur le PC où il y a le graveur (jamais les mêmes, sinon c’est pas drôle ;-)) prend du temps, et graver aussi. Et tester des CD bootables d’autres distributions peut aussi faire perdre du temps. Autant aller droit à la cible...

Méthodologie de travail en équipe

Bah non, on n’est pas seul au monde. Et bosser en équipe demande une sacrée coordination, d’autant plus que les gens n’ont pas tous les mêmes compétences, et donc ne bossent pas forcément ensemble sur le même sujet. Imaginez par exemple qu’un décorateur vienne poser du papier peint dans votre maison en construction alors que les fenêtres ne sont pas posées. La première pluie ajoutera une note, disons, artistique... Le problème est ici le même. Un autre problème à résoudre dans une équipe est le passage de compétences. Que ce soit pour permettre à un nouvel arrivant de se mettre rapidement dans le bain (en évitant de devoir toujours refaire le même discours), que ce soit pour fixer les procédures (et il y en aura) ou pour préparer les départs des plus anciens qui vont changer de mission. Ces deux problèmes vont trouver des débuts de solutions, plus ou moins satisfaisantes (il n’en existe pas de parfaite), dans la mise en place de quelques outils, pour assurer le suivi des plannings, des incidents, et pour mettre en place la capitalisation des connaissances. Du point de vue coordination, les logiciels ne manquent pas :

Suivi des demandes :

Mon préféré, et aussi le premier à avoir été installé, j’ai nommé : Request Tracker ;

Gestion de planning :

Un corollaire du précédent, à une échelle plus macroscopique. Une feuille de calcul – ou chiffrier pour mes amis de l’autre côté de la grande baignoire – peut suffire, voire un calendrier électronique partagé peut suffire pendant un bout de temps) : nous n’avons pas encore utilisé de libre ici. Remarquez que Request Tracker peut aussi être utilisé dans ce cadre.

Capitalisation des connaissances :

Là, j’ai détourné un outil fort sympathique car conjuguant le meilleur de la forme et du fond : SPIP. À la base logiciel de publication web simplifié (ne veut pas dire simplet), à la portée de tous en termes de facilité d’utilisation. Si vous préférez le POD, pas de souci, ça peut aussi se faire (cet article est tapé, sur mon temps libre, dans un éditeur texte en POD, transformé puis d’abord publié sur un de nos SPIP en intranet). J’ai donc détourné SPIP de son rôle de facilitateur de webmestre pour en faire la " killer-application " des bases de connaissances. En fait, je n’ai pas fait grand-chose. J’ai juste commencé à écrire dedans ce que je faisais, et l’ai montré à mes collègues. Comme souvent avec les outils groupware, l’émulation a joué et c’est maintenant à qui aura le plus grand nombre d’articles publiés (je tiens encore la corde, mais j’ai commencé avant les autres, gniark, gniark). Ces articles font maintenant partie de notre fond de commerce en termes de service, et pourront profiter à tous.

Gestion d’équipe :

Comme le logiciel TUTOS, qui peut aller jusqu’au calcul des temps réalisés sur différents clients, facilitant la facturation. TUTOS est un couteau suisse qui peut cependant marcher sur les pieds d’autres outils comme RT ou un CRM. Il existe d’irréductibles récalcitrants à ce genre d’outil, mais surtout à ce genre d’exercices. Du type de ceux qui ont de l’or dans les doigts et dans la tête, mais qui le gardent pour eux. J’en ai eu l’expérience il y a quelques temps, où nous avons dû refaire intégralement une installation SAP (ce qui prend du temps, croyez-moi) parce que celui qui l’avait fait l’avait fait à la va-vite. Cela peut se comprendre, il avait commis quelques erreurs, ce qui encore peut se comprendre, mais surtout n’a rien documenté. Même pas le résultat de la commande ~~script(1)~~, même pas ne serait-ce que deux/trois lignes sur ses principes d’installation. Le seul problème avec ça, c’est qu’il était censé faire cette installation, mais aussi la rendre reproductible. Au total, en voulant (consciemment ou non) gagner une heure (ce qui suffit à faire un copier/coller en nettoyant le résultat de script et en ajoutant deux commentaires de-ci de-là), tout son travail est perdu. Et comme il n’était pas là, quelqu’un d’autre a recommencé, remettant en cause les choix techniques ou ne les comprenant pas (tout le monde ne réfléchit pas de la même façon), perdant du temps, etc. Au bout du compte, cette installation aura pris trois fois le temps qui aurait dû lui être imparti, choix d’architecture et documentation compris. Et ce genre d’exemples, j’en ai à la pelle. Donc certes, oui, la documentation prend du temps, oui, tout le monde n’a pas envie d’écrire de la littérature, mais ce n’est pas non plus l’exercice demandé. Ce qui est demandé, c’est une vue synthétique des choix, et quelques précisions sur les points de détails techniques sortant de l’ordinaire. Pas de discuter sur 10 lignes du fait qu’on préfère ls à echo *.

La méthodologie institutionnalisée

Ce type de méthodologie a l’avantage d’être souvent exhaustive, mais tout aussi souvent sclérosante. ITIL (Information Technology Information Library) est un exemple de méthodologie en passe de devenir un standard, au moins de fait. Ces méthodologies permettent de définir un cadre systématique complet autour de la production informatique. Cela va de la mise en œuvre d’un service à sa mort, avec le suivi et la gestion de toutes les phases, dont le changement, en alliant les visions risque et stratégique du service.

À suivre

Cet article se finit ainsi sur une petite liste de ce dont nous aurons besoin pour mener à bien notre production, dans un ordre qui n’a rien de celui dans lequel nous aborderons ces sujets par la suite :