Introduction – billet n.34

La climatisation avait été oubliée. Elle était restée branchée sur le courant normal.

« C’est qu’on ne met pas
aussi facilement une clim sur un onduleur« , me dit l’installateur. C’est bien la peine d’avoir une salle serveurs qui tourne à plein régime, si c’est pour cramer les composants des machines en montant à 60°…

Après
moultes devis tout aussi élevés les uns que les autres, j’ai fini par
choisir de mettre deux climatisations : l’une directement branchée sur le groupe électrogène,
et capable de redémarrer toute seule en cas de coupure (il faut 3s pour que le
groupe électrogène atteigne sa puissance électrique nominale), et
l’autre sur le courant standard.

Chaque clim est
capable de maintenir la salle serveurs à une température acceptable. Et
pour éviter qu’elles ne fonctionnent en même temps (pour économiser
l’énergie et faire durer plus longtemps chaque clim), elles sont réglées
sur une température qui diffère d’un degré. Et à chaque contrôle de
maintenance des clims, on inverse la différence. Une seule clim
fonctionne, et si elle s’arrête (panne mécanique par exemple), l’autre
prendra le relais après une élévation de température d’un degré.

Si une panne générale électrique survient, les deux clims s’arrêtent, et celle branchée sur le groupe électrogène redémarrera.

Comme bien sur, en tant que responsable de tous les ennuis techniques et informatiques possibles et imaginables, je suis d’astreinte 24/7 toute l’année, j’ai mis en place un serveur Nagios (maintenant remplacé par un serveur
Centreon), et je reçois un email associé à un SMS (envoyé gratuitement par Google via un script
GMail) en cas d’alerte.

Une sonde Centreon surveille la température de la salle, et si elle monte trop haut (panne des deux clims par exemple) un processus d’arrêt en douceur des 70 serveurs virtuels, et des machines physiques hôtes, se déclenche. Je peux partir en vacances l’esprit tranquille.

Jusqu’au jour où je reçois un coup de téléphone affolé du gardien. Un truc imprévu nous tombait sur la tête. Et cette fois, c’est grave. Très grave.

Billet n.36

————–

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

Un truc imprévu (allégorie) Cliquez pour agrandir l’image Source : Golem

Introduction – billet n.33

On ne plaisante pas avec l’électricité. Toute la salle serveurs est alimentée en courant secouru, c’est-à-dire issu d’onduleurs. Le problème est que de temps en temps, en fait à chaque intervention de maintenance sur les onduleurs, tout saute, et on se retrouve sans aucun serveur, alors que le courant « normal » continue de fonctionner sur tous les postes de la startup.

Évidemment, c’est sur le service informatique que tout le mécontentement se déverse…

Je réfléchis donc à essayer d’améliorer la situation, et me plonge dans les différents types d’onduleurs, les capacités des batteries, les différents contrats de maintenance, etc. Puis, je me souviens qu’il y a une sorte de groupe électrogène vaguement utilisé dans un coin de la startup. Je mène ma petite enquête et je comprends que ce groupe sert uniquement en cas d’incendie : il alimente les moteurs des trappes d’évacuation des fumées. Comme il ne sert jamais, il a un peu été oublié dans son coin.

J’étudie la documentation, et les textes réglementaires. Rien ne s’oppose à ce que j’exploite un peu plus les capacités de cet énorme groupe électrogène. D’abord, je le fais réparer (il doit être chauffé en permanence par une résistance électrique pour le maintenir en température, et éviter une rupture en cas de démarrage et d’exploitation immédiate à pleine charge), puis je trouve une entreprise capable d’en assurer la maintenance. Ensuite, avec une entreprise électrique qualifiée, je fais mettre en place une dérivation pour alimenter tous les onduleurs de la startup. Enfin, je fais valider tout cela par la commission de sécurité qui passe tous les trois ans.

J’ai donc un groupe électrogène qui démarre en cas de coupure de courant, et met environ 3 secondes à fournir un courant de charge pour les onduleurs. Ceux-ci auront immédiatement pris le relais de la coupure, sans micro-coupure, et continueront de tenir leur rôle tant qu’il y aura du carburant dans le groupe électrogène. Au pire, si un jour la demande de courant est trop importante, la capacité des onduleurs de faire fonctionner la salle serveurs aura été passée d’un quart d’heure à plusieurs jours.

Bien sur, j’ai vérifié que les serveurs, les systèmes de stockage et les commutateurs avaient tous au moins deux alimentations, l’une sur le secouru et l’autre sur le courant standard.

A la première panne électrique de secteur, je suis allé voir si tout allait bien en salle serveurs. Tout fonctionnait parfaitement… sauf un détail. Un petit détail qui risquait de ruiner la salle serveurs.

Billet n.35

————–

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

Introduction – billet n.32

Cette même année 2009, je commence à jouer avec un logiciel quasi magique pour moi : ESXi de VMware. Il s’agit d’un hyperviseur, c’est-à-dire d’une plate-forme de virtualisation qui permet à plusieurs systèmes d’exploitation de fonctionner sur une même machine physique en même temps. 

Lors d’un salon informatique, j’ai assisté à une démonstration VMware où le technico-commercial a montré la migration à chaud d’une machine virtuelle en fonctionnement, d’un serveur à un autre, tout en « pingant » la machine, sans perte d’un seul paquet. Cela me paraissait incroyable.

A cette époque, ESXi était devenu gratuit (c’est une version simplifiée de
la version ESX commerciale, dépouillée de sa console graphique qui posait beaucoup de problèmes de sécurité). Pour tester le concept et ne pas mourir idiot, j’ai installé ESXi sur un vieux serveur. Je découvre alors, émerveillé, les concepts de machines virtuelles, de switchs virtuels, de cohabitation de plusieurs serveurs virtuels sur une seule machine physique.

C’est un choc !

(on ne se moque pas, c’est aujourd’hui banal, ça ne l’était pas pour moi en 2009)

Je monte un POC en salle serveurs, avec trois vieilles machines gonflées pour l’occasion (mémoires, disques durs, cartes réseaux), pour étudier la faisabilité de cette idée un peu folle de remplacer 15 serveurs physiques par des machines virtuelles regroupées sur 4 serveurs physiques.

Après quelques mois de tests en salle serveurs, je contacte les principaux constructeurs de matériels informatiques (à l’époque : NEC, HP, Dell et EMC), pour étudier une configuration de production adaptée à mes besoins. Je me fais prêter une config sur laquelle je mesure les I/O des disques et nous basculons tous nos serveurs vers un cluster de 4 hôtes Dell reliés à deux SAN md3000i remplis de disques durs. Je découvre vMotion, la réplique de machines virtuelles, le partage des ressources matérielles, la baisse de la consommation électrique de la salle serveurs.

De 15 serveurs physiques, nous passons à 4 sur lesquels nous installons 15 machines virtuelles, puis 20, puis 30, puis 50 et aujourd’hui 70… Tout est administré à travers une appliance vCenter. L’administration informatique prend chez nous une dimension industrielle. Nous sommes pourtant toujours 3 dans le service informatique… La pression des utilisateurs continue d’augmenter (leur nombre aussi).

Mais le géant nouvellement installé dans la salle serveurs garde un talon d’Achille : l’alimentation électrique.

Billet n.34

————–

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

Administration de machines virtuelles (allégorie)

Introduction – billet n.31

Quelques DSI d’écoles de commerces ou d’écoles d’ingénieurs (privées) commençaient à envisager l’externalisation de leurs outils de travail de groupe (on parlait beaucoup de « groupware » à l’époque), dont leurs messageries. Les offres étaient peu nombreuses, mais existaient et toutes avec des fonctionnalités et des coûts différents. Aucun n’avait encore fait le saut.

Je cherchais une solution qui puisse proposer un espace de stockage en phase avec les besoins toujours croissants des utilisateurs, et facile à installer sur tous les types d’appareils que les utilisateurs amenaient sur place : téléphones de toutes marques, de toutes versions de système d’exploitation, tablettes, ordinateurs portables, ordinateurs fixes, etc. Les modes d’emploi d’installation et de configuration devaient être toujours à jour, surtout lors de la sortie d’un nouveau type d’équipement. Les import/export des contacts devaient être simples et pratiques.

J’ai donc contacté les entreprises qui proposaient des offres
en phase avec mon cahier des charges. A l’époque, deux sociétés
sortaient du lot : Microsoft et son offre BPOS naissante bientôt renommée en Live@Edu (aujourd’hui Office 365), et Google avec son offre Google Apps for Education (aujourd’hui G Suite). Google est alors une société dynamique en pleine ascension, mais
jeune (à peine 11 ans) et le choix est risqué. Microsoft est en train d’opérer son virage vers Internet et peine à convaincre malgré sa base installée.

Les deux offres sont gratuites pour les établissements d’enseignement supérieur, ce qui était très très intéressant, sans que cela n’éveille chez moi la méfiance que j’aurais du ressentir… Je mène une enquête  (sur le principe d’externalisation vers les outils Google ou Microsoft) auprès d’un panel d’utilisateurs internes et leur retour est enthousiaste, avec une nette préférence pour les outils Google.

En étudiant bien les fonctionnalités proposées, y compris les paramétrages possibles dans les outils d’administration, et avec la bonne
réputation que Google avait à l’époque, j’ai choisi de migrer mes 2000
comptes de messagerie vers GMail et son quota de 5 Go par personne
(énorme pour l’époque). Les utilisateurs sont ravis, la bande passante aussi. La lutte contre le SPAM est externalisée et répartie sur les utilisateurs du monde entier. Pour les utilisateurs concernés, le chiffrement des emails est assuré par GPG et Thunderbird.

C’est la décision dont je suis le moins fier aujourd’hui : la pression économique, le manque de clairvoyance, l’envie de satisfaire au mieux les besoins des utilisateurs, m’ont fait franchir le Rubicon.

Mais j’ai l’habitude d’essayer de prendre mes décisions de manière réfléchie, en analysant au mieux les cartes que j’ai en main au moment où je dois prendre la décision. Quand je regarde en arrière, et que je me rends compte que j’ai pris une mauvaise décision, je ne jette pas la pierre à mon moi d’avant. Nous sommes quatre ans avant le lancement d’alerte d’Edward Snowden. Depuis, de nouvelles cartes sont apparues, entraînant une vision différente. Il m’arrive comme tout le monde de prendre de mauvaises décisions, de le reconnaître et d’essayer de les corriger ensuite. Mais dans ce cas, une fois la décision prise et les gigaoctets transférés, ces derniers sont devenus des téraoctets et aujourd’hui des centaines de téraoctets (G Suite for Education propose un quota illimité pour chaque utilisateur, gratuitement). Je n’ai jamais pu revenir en arrière. Les serveurs de stockage ont retrouvé des espaces libres, vite remplis par les utilisateurs qui, c’est bien connus, ont horreur du vide…

La seule consolation que j’ai aujourd’hui, c’est de voir que presque tous les DSI des écoles de commerce et des écoles d’ingénieurs privées ont fait le même choix d’externalisation dans le Cloud. Sauf que la plupart sont chez Microsoft avec son offre gratuite Office 365. Le diable sait tout faire, afin que le DSI devienne sa proie.

L’œil était dans la tombe, et regardait Zythom…

Malgré cette charge en moins, ma salle serveurs vieillissait et son remplacement commençait à devenir d’actualité. C’est à cette époque qu’un logiciel quasi magique est apparu sur mes radars de veille.

Billet n.33

————–

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

La Conscience, Maison de Victor Hugo [Public domain], via Wikimedia Commons

Introduction – billet n.30

En 2009, la téléphonie mobile commence à bien s’implanter dans les usages. De plus en plus de personnes disposent d’un téléphone portable et celui-ci évolue rapidement d’un simple appareil proposant uniquement la fonction téléphonique à un téléphone intelligent ressemblant de plus en plus à un ordinateur.

En quelques années, notre système de messagerie électronique basé sur un serveur web Apache et un magnifique SquirrelMail développé en PHP allait devenir un point de crispation des utilisateurs… Le nombre de messages, le volume des pièces jointes, le besoin de partage des contacts et l’accès facile via les smartphones allaient avoir raison de la solution que nous avions mis en place.

Parallèlement à cela, notre accès internet commençait à être saturé de messages, de SPAM, de transferts de fichiers… Les utilisateurs souhaitaient pouvoir stocker de plus en plus de données, et celles-ci devenaient de plus en plus volumineuses. Ils souhaitaient pouvoir les partager facilement et travailler de manière collaborative dessus.

Tout le monde voulait une solution simple et pouvoir l’utiliser depuis un ordinateur portable, une tablette ou son téléphone.

Depuis quelques années, nous avions abandonné notre fidèle sendmail pour lui préférer le plus simple Postfix. Nous déployions des trésors d’ingéniosité pour protéger nos utilisateurs contre les SPAM, avec du greylisting (PostGrey), du filtrage de contenu avec SpamAssassin, du filtrage bayésien, du filtrage par mots clefs, du filtrage heuristique… Nous blacklistions les serveurs via des bases de données RBL, nous surveillions les envois de nos serveurs pour ne pas être nous mêmes blacklistés…

Le système informatique que j’avais mis en place vieillissait, et il
m’apparaissait comme de plus en plus évident que j’arriverais difficilement à pouvoir proposer le service réclamé par
mes utilisateurs, avec
les moyens à ma disposition. Entre les utilisateurs mécontents et le service rendu de mauvaise qualité, cela craquait de toutes parts, il fallait trouver une solution, et vite…

Vous n’allez pas aimer la solution que j’ai choisie…

Billet n.32

————–

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

Par Sam Johnston [CC BY-SA 3.0], via Wikimedia Commons

Introduction – billet n.29

Quand un nombre important de problèmes vous remonte, il faut trouver une méthode de résolution qui vous permet de les surmonter en apportant à chacun une solution, si possible pérenne…

En tant que responsable informatique, j’organise ma résolution de problèmes autour d’une réflexion à long terme, formalisée par un schéma directeur informatique (SDSI) et une politique de sécurité des systèmes d’information (PSSI).

En tant que responsable technique fraîchement nommé, j’ai choisi de me focaliser sur le document unique d’évaluation des risques professionnels. Accompagné d’un consultant extérieur, j’ai rédigé ce document et j’en assure la mise à jour annuelle. C’est la clef de voûte de mes décisions à long terme.

Pour le court terme, j’ai fait confiance à toute l’équipe en place : je leur ai demandé quelles étaient les améliorations qu’ils souhaitaient voir mises en place et j’ai fait le nécessaire pour faciliter leurs interventions et mettre en valeur leurs savoir-faire : mise en place d’un logiciel de gestion des services d’assistance (OTRS, déjà utilisé par le service informatique), externalisation des tâches chronophages ou ne correspondant pas à leurs formations (entretien des espaces verts, nettoyage des abords des bâtiments…), et achat des outils indispensables à chacun.

J’ai ensuite essayé de faire ce que tout manager doit faire : mettre en valeur ses équipes auprès des utilisateurs, et assumer les erreurs humaines de son équipe : quand quelque chose de positif est fait dans le service, c’est grâce aux techniciens, mais quand quelque chose de négatif est fait dans le service, c’est à cause du responsable du service.

Pour pourvoir assumer cela, j’ai demandé à suivre moi-même toutes les
formations techniques obligatoires : CACES chariot élévateur, CACES
nacelle, habilitation électrique, formation de Sauveteur Secouriste du
Travail (SST), formation à la manipulation d’extincteurs… Et après chaque
formation, je faisais le point avec mon équipe sur les règles de sécurité, les
procédures et les équipements de protection individuel (EPI).

Comme l’Homme qui plantait des arbres (livre gratuit selon la volonté de Jean Giono, vous pouvez le lire ici par exemple), j’ai commencé à essayer de changer les choses par petites touches.

Billet 31

————–

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

Sécurité au travail, ce qu’il ne faut pas faire, exemple n.3248

Introduction – billet n.28

Je suis allé voir le Directeur Général, et je lui ai proposé de prendre la tête du service technique, en plus du service informatique. Beaucoup d’outils techniques allaient converger vers le numérique, et beaucoup d’interdépendances existaient déjà, avec quelques points de crispations. J’avais envie de progresser en management, je m’entendais bien avec les techniciens, dont je respectais depuis longtemps le savoir faire.

D’enseignant-chercheur, j’étais passé de l’autre côté de la barrière, celle des services supports, en devenant responsable informatique. Le Directeur Général était un peu surpris que je me propose pour prendre la responsabilité du service technique… Surpris, mais intéressé. Il a dit oui. Je suis devenu responsable informatique ET technique de la startup.

C’est ainsi que j’ai découvert un univers totalement différent de l’univers informatique, et dont j’ai un peu parlé dans le billet « Jargon technologique » en référence à ma formation initiale. J’ai du faire mes preuves, non pas en organisation ou en gestion de projet, mais en électricité, en chariot élévateur, en nacelle, en EPI, en SST, en SSI, en entretien des espaces verts, en sécurité des personnes, en entretien des bâtiments, en extincteurs, en climatisation, en ventilation, en réglementation des établissements recevant du public, en commission de sécurité…

Tout un nouvel univers de problèmes et de solutions s’offrait à moi. Avec deux équipes de techniciens expérimentés à encadrer, j’allais apprendre à courir partout dans la startup : avec 12 000 m2 de bâtiments, 800 personnes présentes chaque jour dans les locaux, un site distant à gérer, 300 ordinateurs fixes, une téléphonie vieillissante, du BYOD omniprésent, la tâche s’avérait passionnante.

Et effectivement, les problèmes allaient pleuvoir comme à Gravelotte…

Billet n.30

————–

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

Extrait de https://salemoment.tumblr.com/ avec l’aimable autorisation de l’auteur Olivier Ka

Introduction – billet n.27

J’adore mon métier. Je fais tout pour être heureux le matin en allant travailler, pour aimer le lundi matin plus que les autres matins. Enfin, j’essaye… J’ai vite appris à faire confiance dans les capacités des personnes de mon entourage professionnel, et à travailler en équipe avec les différents services de la startup.

Comme dans beaucoup d’entreprises, le service informatique gère un périmètre qui relève de toute évidence de sa compétence : le réseau informatique, les ordinateurs, les serveurs, l’accès internet et les imprimantes. Mais avec les années, de plus en plus d’interactions ont lieu avec un autre service de la startup : le service technique. A lui la gestion de l’électricité et des onduleurs, des climatisations, de la téléphonie, des gros photocopieurs, des télévisions, des vidéoprojecteurs, du contrôle d’accès, du système de gestion technique du bâtiment, du chauffage, et de pleins d’autres choses…

Il y a des interactions évidentes : les climatisations de la salle serveurs, l’électricité de secours… Mais beaucoup des autres équipements commencent eux aussi leurs évolutions vers le numérique : les photocopieurs multifonctions sont reliés au réseau informatique et se transforment en imprimante/scanner avec une télémaintenance associée (par ligne téléphonique analogique !), les vidéoprojecteurs se connectent au réseau informatique, le contrôle d’accès et sa base de données aussi. Bref, beaucoup des appareils gérés par le service technique s’informatisent.

Et en cette année 2007, le responsable du service technique décide de quitter la startup. C’est la surprise qui m’attendait au retour de mission en terre africaine.

Le service technique se retrouve alors sans personne à sa tête et la Direction de la startup se met à la recherche d’une solution en commençant à réfléchir au meilleur recrutement possible.

C’est là que j’ai eu une idée curieuse, qui a surpris tout le monde…

Billet n.29

————–

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

Introduction – billet n.26

Je reprends ici une partie du billet que j’ai écrit sur ce blog à l’époque.

Chronologiquement, l’installation s’est déroulée comme suit :

1) Installation d’Internet:

Plus
exactement, remplacement du modem USB fourni par Maroc Telecom par un
modem routeur Netgear autonome (ie : qui n’a pas besoin d’un PC pour
fonctionner).

2) Installation du réseau:

J’étais
venu avec cinq kilos de câbles de toutes longueurs que j’ai installés
dans les goulottes présentes dans les bureaux (avec un joyeux mélange
courants forts/courants faibles). J’ai même du percer un trou à travers
une cloison… A quatre pattes en costard, comme quoi l’informatique
mène à tout.

Les actifs du réseau sont constitués du Netgear (qui
fait switch quatre ports) secondé par deux petits switchs EUSSO huit
ports. J’avais amené un beau switch 24 ports, mais il fait réellement
trop de bruit. Finalement, c’est le secours qui est en production, et le « gros » switch qui servira de secours…

3) Installation du serveur:

Un
superbe serveur Dell tout neuf qui m’a fait une belle frayeur car
l’installation de Debian Sarge s’arrêtait sur le beau message « aucun
disque dur n’a été trouvé ». En effet, le net-install Debian ne connaît
pas les nouveaux disques SAS de Dell…

Heureusement, j’ai pu trouver
un site web proposant des images « customisées » de net-install Debian
Sarge mis à niveau avec les drivers ad hoc.

Après une petite heure de transpiration, l’installation de base du serveur était achevée. J’aurais eu l’air fin si la mission s’était arrêtée là !

L’installation de samba s’est limitée aux commandes:

# aptitude update

# aptitude install samba

# aptitude install winbind

# aptitude install swat

puis au lancement d’un navigateur sur mon portable pour configurer Samba via swat et le réseau fraîchement installé…

Configuration du serveur en contrôleur de domaine principal.

Création des comptes, des répertoires partagés…

Mise en place du DNS et du DHCP par mon équipe technique depuis la France à travers le routeur, pour me faire gagner du temps.

Vérification du bon fonctionnement de l’onduleur.

Fin de la première journée.

4) Installation de l’électricité:

C’est le plus gros problème qui a failli faire capoter cette mission, et c’est
le charme des missions hors France que de ne pas savoir complètement à
l’avance les problèmes qu’il va falloir surmonter : deux prises
électriques pour alimenter une salle de 10 ordinateurs. Et bien sûr,
aucune rallonge…

Achat de 12 rallonges « trois prises » sans interrupteur, une demi-journée de perdue…

5) Installation des logiciels sur un poste master:

Vu la quantité de logiciels à installer, cette étape me prendra le reste de la journée.

Fin de la deuxième journée.

6) Déploiement de l’image du poste master vers les autres postes:

Finalement, j’ai opté pour un boot sur le cédérom UBCD qui contient le clone de Ghost qui s’appelle « partition saving« . Attention, il faut compter deux heures pour cloner trois postes à la fois. Je découvrirai Clonezilla et son mode multicast plus tard, et enfin, encore plus tard le merveilleux projet FOG.

Je profite du clonage des derniers postes pour tester la qualité de l’image et personnaliser chaque poste.

Fin de la troisième journée.

7) Installation des serveurs de licences et tests finaux:

Tout est dans le titre. Certains logiciels nécessitent des licences gérées par serveur (LUM et FlexLM). Je
n’ai vraiment réalisé que le challenge était gagné que lorsque j’ai vu
fonctionner tous les logiciels lors de la mini formation que j’ai
réalisée en fin de journée auprès des enseignants vacataires.

Je déballe le NAS pour le brancher sur le réseau et l’onduleur, et procéder aux configurations minimales. Les processus de sauvegardes seront installés à distance, sur les postes et sur le serveur.

Fin du séjour.

Mon séjour au Maroc s’est très bien passé, sauf que je n’ai rien vu du Maroc…

Logé
dans un hôtel Ibis où je prenais mes repas, j’ai passé 13 heures chaque
jour enfermé sur mon lieu de travail que je rejoignais à pied.

De retour en France, une surprise m’attendait.

Billet n.28

————–

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.