La première étape est donc le recrutement. Il se déroule ainsi :
Trouver un sujets de stage, au moins savoir de quoi ça va parler. Ce n'est pas forcément évident car cette étape se déroule plusieurs mois avant le stage, on ne sait pas forcément sur quoi on va travailler et quels projets vont se présenter. Le sujet global que je propose est le Cloud Public Azure / AWS.
Définir une fiche de poste, qui énonce le profil recherché (stage de fin d'études pour un bac +5) et les technologies sur lesquelles l'étudiant sera amené à travailler. Une présentation de l'entreprise et de ce que fait notre équipe est également requise.
Éplucher les candidatures et les CVs.
Faire passer les entretients.
Retenir un candidat...
Je n'avais jamais fait l'exercice d'être du côté recruteur, c'est étonnant, je comprends maintenant la difficulté de cerner un candidat rien qu'en lisant son parcours sur une feuille A4. Je ne voulais pas être "le mauvais recruteur qui met injustement les CVs à la poubelle" mais je devais quand même trouver des critères objectifs et justes, tout en ayant conscience qu'un stagiaire est un stagiaire, il n'aura que très peu des compétences techniques recherchées. Accessoirement j'ai ressenti un petit "coup de vieux" en voyant les dates de naissance (1997)...
Passons maintenant à l'entretien. J'ai en fait des dizaines voire plus dans ma vie, toujours du côté candidat et je connais bien les règles du jeu. Apprendre à se présenter, à détailler son parcours, expliquer ce qui nous motive, parfois donner les réponses que le recruteur veut entendre (des défauts qui sont en fait des qualités), bla bla bla. Mais cette fois-ci j'étais de l'autre côté de la table, celui du recruteur. Et tout à coup c'était à moi de mener l'entretien, lancer les sujets, poser des questions constructives pour inciter le candidat à parler de lui. Heureusement mon chef m'a beaucoup aidé et est venu au premier entretien. J'ai retenu la formule suivante :
Demander au candidat de se présenter, noter certains mots clés.
Présenter l'entreprise, présenter notre métier, ce qui est attendu du candidat.
Phase d'échange où on réutilise les mots clés pour interroger le candidat (hm, tu as fait un stage dans une entreprise qui fait de l'hébergement web, est-ce qu'il y avait de la HA ? De la virtu ? etc...). On répond aussi aux questions de ce dernier.
On évoque les hobbies surtout les jeux vidéo ou la bidouille informatique, ça détend et parfois le candidat nous apprend des choses supplémentaires.
Évoquer les modalités (salaire, horaires, transports...).
Dans un CV étudiant, les stages passés ont des sujets très variés voir radicalement différents, donc il n'est pas facile de trouver le fil rouge. Il faut essayer de comprendre les sujets qui ont été traités, les compétences mises en jeu, et ce que le candidat a appris. Je l'interroge sur sa culture informatique, s'il bidouille sur son temps perso, etc. Et bien sûr on juge le savoir-être, notamment la manière de s'exprimer, la politesse, on cherche à savoir si le sujet l'intéresse vraiment.
Après l'entretien arrive le débriefing en interne. Le candidat ne peut pas correspondre à 100% aux attentes, on essaie donc de juger s'il sera apte et suffisamment motivé pour le stage, en se rappelant encore une fois que c'est un étudiant. Finalement, nous avons dit oui, son savoir-être a beaucoup joué même si les compétences pouvaient paraître un peu faibles.
De manière humble je dois avouer que cette expérience, qui m'a placé du côté du recruteur, m'a appris beaucoup de choses. J'ai du mettre des mots sur ce que je fais chaque jour dans mon métier, apprendre à analyser les candidatures, construire un entretien qui mette le candidat à l'aise, et essayer de concilier l'aspect humain et rationnel. Je sens peser la triple responsabilité de choisir le bon candidat pour l'entreprise, pour moi, et pour lui-même. Je suis clairement sorti de ma zone de confort, de la technique, et ce n'est que le début.
L'épisode 2 parlera des préparatifs et de l'arrivée du stagiaire.
A 32 ans, j'accueille mon premier stagiaire. J'avais cette idée en tête depuis quelques années déjà, mais je n'étais pas dans la bonne entreprise ou pas suffisamment "posé" pour me lancer dans l'aventure. C'est maintenant chose faite. Je vais essayer de tenir une série de billets dans lequel je décris cette expérience.
J'aime mon métier et j'ai envie de le transmettre, de former quelqu'un, le motiver, l'encourager si c'est la voie qu'il veut suivre. En même temps j'ai conscience des risques, un stage ou un contrat pro qui se passe mal peut casser un projet ou démotiver l'étudiant à travailler dans ce domaine. C'est ce qui m'est arrivé quand j'ai fait mon BTS, erreur de casting pour le stage, suivi de "la crise" en 2008, résultat j'ai totalement abandonné le domaine en question pour me "reconvertir" dans l'informatique mais tout en bas de l'échelle. Au final ce fut une bonne chose mais j'ai l'impression d'avoir perdu plusieurs années dans ma carrière professionnelle. Je dois maintenant faire mon maximum pour recruter la bonne personne et le faire monter en compétences, lui confier des sujets ni trop faciles ni trop difficiles, varier les domaines (architecture, réseau, projet...) juste assez pour que les 6 mois de stage le motivent à continuer !
Lorsque j'ai présenté l'idée à mon équipe et à mon chef, les réactions ont été positives mais on m'a averti qu'un stagiaire demande beaucoup de temps. J'ai compris que j'allais devoir améliorer mon organisation et potentiellement voir augmenter ma charge de travail, mais j'ai quand même envie de tenter le coup.
En tant qu'utilisateur de Linux depuis 12 ans, ancien prosélyte, ancien techos helpdesk, je pense fortement que ce n'est pas vrai et que le monsieur se trompe. Même s'il est un dictateur reconnu et probablement un bon développeur, je pense que le problème n'est pas technique.
Mauvais raisonnement
Excusez l'analogie un peu sexiste, mais on ne fait pas un enfant en 3 mois avec 3 femmes. Affirmer que mettre tous les gens sur une distribution unique et un environnement graphique unique permettrait d'atteindre une qualité supérieure reste à prouver tant il y a de facteurs en jeu.
De plus il ne faut pas oublier que la grande majorité des distributions Linux et des logiciels libres sont gratuits et faits par des gens qui s'éclatent, des contributeurs réguliers ou occasionnels, bref des gens à qui on ne peut pas donner d'ordres. Il n'y aurait aucune légitimité à rediriger ces gens là vers un projet unique, la plupart cesseraient juste de contribuer et nous devrions être content de les avoir actuellement même s'ils sont "répartis" sur différents projets.
D'autre part ce raisonnement part du principe que cet éparpillement provoque un déficit de moyens au niveau des distributions, alors que des organisations telles que Red Hat, Fedora, Suse, Debian, Ubuntu, ont déjà énormément de contributeurs et même des moyens financiers.
Et pour finir faisons une analogie avec les voitures: si demain on décide qu'il est inutile d'avoir plusieurs constructeurs automobile puisqu'au final les voitures se ressemblent toutes, est-ce que cela augmentera la qualité des véhicules ? Non, cela donnera juste un énorme monopole à quelqu'un.
Linux ou le fantasme d'un Windows gratuit
On aura beau avoir la distribution la plus peaufinée, la plus performante, la moins buguée, il y aura toujours des reproches sur l'impossibilité de trouver les mêmes logiciels que Windows, faire les mêmes manipulations, avoir la même compatibilité. En gros nous avons un espèce de fantasme d'un Linux qui serait un Windows gratuit amélioré, bien sûr cela n'est pas possible.
Par contre, plutôt que d'avoir Linux avec un environnement Windows, il est possible de faire l'inverse. Aujourd'hui on peut installer Debian 9 sur Windows 10, sans virtualisation, sans émulation, avec accès natif aux dépôts de la distribution. Et ça marche plutôt bien. Peut-être la convergence Windows/Linux est-elle déjà là et qu'au final l'intérêt de Linux sur desktop est de moins en moins pertinent.
La vente liée
Enfin on ne peut continuer la réflexion sans évoquer l'éternelle vente liée. Il est probable que l'écrasante majorité des utilisateurs ne sait pas installer un système d'exploitation, n'a pas envie d'apprendre (à juste titre), voire ne sait même pas ce qu'est un OS. Donc à partir du moment où chaque ordinateur vendu dans le monde vient avec Windows, la compétition n'est pas juste.
Conclusion
Alors qu'il a gagné sur mobile, Linux ne s'imposera jamais sur desktop, car c'est un marché bloqué, car il est trop tard pour changer les habitudes des gens, et parce qu'il est plus pragmatique de parier sur la convergence des environnement avec WSL qui permet d'avoir Linux sur Windows. Avec les efforts récents de Microsoft dans l'opensource je ne serais pas surpris de voir un rachat de Canonical prochain pour faire face à IBM.
Plutôt que de chercher à révolutionner 20 ans d'informatique grand public, s'isoler et se trouver des ennemis partout, tenter d'aller contre un courant beaucoup trop fort, le combat devrait être mené sur un autre front. On ne pourra pas déployer de Linux sur les PC grand public, en revanche on peut faire vivre son écosystème. On a des logiciels libres populaires qui marchent bien: Firefox, VLC, LibreOffice, c'est à mon sens là dessus qu'il faut investir nos efforts.
On m'a posé cette question lors d'un entretien. C'est assez bateau et il existe un tas de réponses "par cœur" et pourtant elle m'a surpris. J'ai donc répondu de manière sincère la première chose qui m'est passée par la tête: être carré, être sérieux, parce qu'on est pas dans un labo, on est responsables de la production. Sur le coup, je pensais aux astreintes, aux sueurs lorsqu'un site web commercial affiche un 403 ou une page blanche, ou quand on me dit que "plus rien ne marche" et que c'est à moi de dépanner. Et puis je sortais tout juste de cette mauvaise expérience avec Ceph, la prod ça ne rigole pas.
Mais y réfléchissant après j'ai pensé à une réponse plus pertinente: la plus grande qualité d'un sysadmin, c'est d'être bien entouré. Que ce soit les collègues qui nous aident, le chef qui nous encourage, les développeurs toujours prêt à filer un bout de code pour dépanner ou aider à l'intégration de leur application, c'est très important. Un bon sysadmin a toujours ses potes (hors entreprise) sur Telegram, Jabber ou IRC pour discuter de tout et n'importe quoi et parfois de boulot.
Les autres questions portaient sur la technique, domaine dans lequel je suis plus à l'aise avec les 8 ans d'expérience dans le dos :)
Il y a deux ans j'affirmais aimer systemd dans l'article systemd, c'est bien. Aujourd'hui je parle de Firewalld, un service et ensemble d'outils permettant de gérer le pare-feu sous Linux.
La base du firewall sous Linux c'est iptables, et quand on a compris et beaucoup pratiqué, c'est pas si compliqué. Mais il y a toujours deux points qui me gênent:
Il n'y a pas de service officiel pour charger les règles au démarrage, il faut faire son propre script ou en emprunter à droite à gauche.
Les règles sont quand même indigestes et bas niveau, ce qui n'est pas toujours nécessaire.
Firewalld implémente un système de "zones" dans lesquelles vous allez définir des paramètres, autoriser des services: internet, public, dmz... elles peuvent être définies à partir de l'interface ou de la source, c'est assez souple. Le paramétrage se fait soit en cli (firewalld-cmd) soit graphiquement (firewall-config) ou encore au travers d'une api et introduit la notion de "permanent" pour savoir si il faut conserver les modifications au démarrage.
Bien entendu, firewalld est un service système donc il n'y a pas de script à écrire pour charger ses règles au boot, il suffit de l'activer dans sytemd.
Firewalld est présent sur Fedora, CentOS, RedHat mais peut être installé sur d'autres sytèmes comme Debian car il est proposé dans les dépôts. Et moi, je migre mes serveurs sur Firewalld avec prise en charge par Ansible, parce que je gagne un temps fou et je fais les choses proprement.
Merci Red Hat ces logiciels qui terminent en "d" et qui modernisent un peu Linux :)