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 serveurs, 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 terme 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 un 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.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 media, 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 un 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 500Mo. Ç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 alors que les logiciels propriétaires ne nous permettent qu'une simple bigamie, voire une nue monogamie, dont le divorce peut être exclus 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 personnelle :

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 terme 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 viennent 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 :

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 :

Auteur

Jérôme Fenal - <jfenal@free.fr>

Jérôme Fenal est utilisateur de GNU/Linux depuis 1994, de divers Unix ou Unix-like depuis un peu plus longtemps.

Consultant (avant-vente, conseil et réalisation) LogicaCMG dans le domaine des infrastructures systèmes, qu'elles soient à base de logiciels et systèmes propriétaires Unix et/ou de logiciel libre (de plus en plus).

Merci aux Mongueurs Lyonnais et Parisiens qui ont assuré la relecture de cet article.