DevOps

Il y a quelques mois, j'ai envisagé de créer plusieurs profils sur Malt pour me présenter sous différentes "casquettes". Par exemple :

• CTO as a Service
• CPTO
• DevOps
• Expert en Web Scraping
• Développeur Frontend
• Développeur Backend
• Développeur Fullstack
• …

Cette idée m'est venue en 2022, lorsque j'étais CTO chez Spacefill et que je recrutais des freelances pour des missions très spécifiques.

Je m'étais alors rendu compte que la sélection des profils était fastidieuse et que je passais à côté de candidats intéressants simplement à cause de problèmes liés aux mots-clés.

C'est à ce moment-là que je me suis dit que si un jour je m'inscrivais sur une place de marché de freelances, il serait judicieux de créer plusieurs types de profils pour contourner ces limitations de filtres.

En août dernier, j'ai fait quelques recherches sur la possibilité de créer plusieurs profils sur Malt et je suis tombé sur cette page (webarchive):

Créer plusieurs profils dans Malt ?

Vous pouvez créer plusieurs profils dans Malt. Chaque compte doit être associé à une adresse e-mail différente.

Chez Malt, nous déconseillons de créer deux profils différents sur la marketplace sauf si vous avez deux activités très différentes, par exemple si vous êtes développeur et graphiste.

Vos filleuls et gains cumulés seront alors répartis entre plusieurs profils.

Si vous exercez deux activités indépendantes très différentes, nous vous conseillons de créer deux comptes distincts en prenant soin de télécharger les documents liés à votre(vos) activité(s).

Nous ne pourrons pas fusionner vos notes et projets entre vos deux profils.

Création de mon compte Malt

Je me suis ensuite dit qu'avant de mettre en place une stratégie complexe, qu'il serait plus judicieux de commencer par créer et publier un simple profil.

En remplissant ce profil, j'ai constaté que je pouvais renseigner une longue liste de compétences. J'ai alors pensé que l'idée de créer plusieurs profils n'était finalement plus nécessaire.

Premier point de difficulté, le choix de la catégorie :

J'ai opté pour une catégorie générique, celle de "Ingénieur logiciel".

Cependant, je doute fortement que ce soit le premier choix d'une personne que utilise le recherche de Malt 🤔 :

'ai fait un test en choisissant l'intitulé "Développeur". Après avoir filtré par mon tarif journalier exact et mon niveau d'expérience, je suis présent en page 6 des résultats.

Si je sélectionne la catégorie "Développeur Web Back-end" ou "Développeur Web Front-end" je ne suis plus présente dans la liste des résultats 😟.

Bilan Malt après 25 jours

Mon bilan Malt après 25 jours ? Pour le moment, personne ne m'a contacté. J'observe que mes statistiques sont plutôt mauvaises. De plus, je pense que les 3 personnes qui ont vu mon profil sont des amis.

Un ami freelance m'a confié qu'il n'avait reçu qu'une seule proposition de mission sur Malt en plus de trois ans.

Un autre ami freelance m'a confié avoir eu, sur un an, sur Malt, environ 40 propositions de mission, 5 échanges constructifs et signé deux missions.

Suite de stratégie Malt ?

Il est clair que mon profil Malt n'est pas optimisé.

J'ai visé trop large en listant mes compétences, et je pense que ce n'est pas la meilleure stratégie.

Le problème, c'est que si je veux rendre mon profil plus spécialisé, je vais devoir faire des choix et retirer des compétences que je ne souhaite pas supprimer 😞.

Pour éviter cela, je vois deux stratégies :

• Modifier mon profil chaque semaine, en ajustant les technologies, les catégories et le tarif journalier ;
• Créer plusieurs profils.

#JeMeDemande si l'étape de vérification des documents d'entreprise va m'empêcher de créer plusieurs profils 🤔.

#JeMeDemande s'il est préférable que je consacre prioritairement du temps à l'optimisation de mon profil Malt ou alors de travailler sur ma Stratégie de promotion de mon activité freelance sur LinkedIn 🤔.

#JaiDécidé de reporter l'optimisation de mon profil Malt.

Dans cette note, je souhaite présenter ma doctrine de mise à jour d'OS de serveurs.

Je ne traiterai pas ici de la stratégie d'upgrade pour un Cluster Kubernetes.

La mise à jour d'un serveur, par exemple, sous un OS Ubuntu LTS, peut être effectuée avec les commandes suivantes :

• sudo apt upgrade -y
• ou sudo apt dist-upgrade -y (plus risqué)
• ou sudo do-release-upgrade (encore plus risqué)

L'exécution d'un sudo apt upgrade -y peut :

• Installer une mise à jour de docker, entraînant une interruption des services sur ce serveur de quelques secondes à quelques minutes.
• Installer une mise à jour de sécurité du kernel, nécessitant alors un redémarrage du serveur, ce qui entraînera une coupure de quelques minutes.

Une montée de version de l'OS via sudo do-release-upgrade peut prendre encore plus de temps et impliquer des ajustements supplémentaires.

Bien que ces opérations se déroulent généralement sans encombre, il n'y a jamais de certitude totale, comme l'illustre l'exemple de la Panne informatique mondiale de juillet 2024.

Sachant cela, avant d'effectuer la mise à jour d'un serveur, j'essaie de déterminer quelles seraient les conséquences d'une coupure d'une journée de ce serveur.

Si je considère que ce risque de coupure est inacceptable ou ne serait pas accepté, j'applique alors la méthode suivante pour réaliser mon upgrade.

Je n'effectue pas la mise à jour le serveur existant. À la place, je déploie un nouveau serveur en utilisant mes scripts automatisés d'Infrastructure as code / GitOps.

C'est pourquoi je préfère éviter de nommer les serveurs d'après le service spécifique qu'ils hébergent (voir aussi Pets vs Cattle). Par exemple, au lieu de nommer un serveur gitlab.servers.example.com, je vais le nommer server1.servers.example.com et configurer gitlab.servers.example.com pour pointer vers server1.servers.example.com.

Ainsi, en cas de mise à jour de server1.servers.example.com, je crée un nouveau serveur nommé server(n+1).servers.example.com.

Ensuite, je lance les scripts de déploiement des services qui étaient présents sur server1.servers.example.com.

Idéalement, j'utilise mes scripts de restauration des données depuis les sauvegardes des services de server1.servers.example.com, ce qui me permet de vérifier leur bon fonctionnement. Ensuite, je prépare des scripts rsync pour synchroniser rapidement les volumes entre server1.servers.example.com et server(n+1).servers.example.com.

Je teste que tout fonctionne bien sur server(n+1).servers.example.com.

Si tout fonctionne correctement, alors :

• J'arrête les services sur server(n+1).servers.example.com ;
• J'exécute le script de synchronisation rsync de server1.servers.example.com vers server(n+1).servers.example.com ;
• Je relance les services sur server(n+1).servers.example.com
• Je modifie la configuration DNS pour faire pointer les services de server1.servers.example.com vers server(n+1).servers.example.com
• Quelques jours après cette intervention, je décommissionne server1.servers.example.com.

Cette méthode est plus longue et plus complexe qu'une mise à jour directe de l'OS sur le server1.servers.example.com, mais elle présente plusieurs avantages :

• Une grande sécurité ;
• L'opération peut être faite tranquillement, sans stress, avec de la qualité ;
• Une durée de coupure limitée et maîtrisée ;
• La possibilité de confier la tâche en toute sécurité à un nouveau DevOps ;
• La garantie du bon fonctionnement des scripts de déploiement automatisé ;
• La vérification de l'efficacité des scripts de restauration des sauvegardes ;
• Un test concret des scripts et de la documentation du Plan de reprise d'activité.

Si le serveur à mettre à jour fonctionne sur une Virtual instance, il est également possible de cloner la VM et de tester la mise à niveau. Cependant, je préfère éviter cette méthode, car elle ne permet pas de valider l'efficacité des scripts de déploiement.