Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier

Pour mes besoins, j’ai créé un programme qui sert à faire des sauvegardes de fichiers et de bases de données MySQL. Ces sauvegardes sont stockées en local et peuvent être archivées sur Amazon S3 ainsi que sur Amazon Glacier.

Ce programme s’appelle Arkiv et son code source est disponible sur GitHub. Il est placé sous une licence libre très permissive.

Pourquoi avoir développé ce logiciel ?

J’utilisais depuis longtemps le programme Backup-Manager, qui me permettait de sauvegarder mes fichiers et mes bases de données en local et sur un serveur FTP, puis sur Amazon S3. Ce programme est très pratique ; il existe depuis plus de 10 ans (il me semble que je l’utilise depuis tout ce temps), il offre pas mal d’options de configuration, et il est disponible dans les paquets Ubuntu.
Mais avec le temps, mes besoins ont évolué, et certaines limites sont apparues : Il ne permet pas de faire plus d’une sauvegarde par jour, ne supporte pas tous les datacenters Amazon (les plus récents ne sont pas compatibles avec les anciennes versions de l’API), ne permet pas d’archiver sur Amazon Glacier et il manque de souplesse au niveau de la purge des sauvegardes.

Vous connaissez sûrement Amazon S3, mais Amazon Glacier est plus récent et moins connu. Ce sont deux services AWS (Amazon Web Services), l’offre de Cloud Computing d’Amazon.
Amazon S3 peut être vu comme un espace de stockage de fichiers de taille illimitée à haute disponibilité. Les données sont disponibles en temps réel. On paye suivant la quantité de données stockée, pour un coût assez faible (pour donner un ordre d’idée, stocker 500 GO de données dans le datacenter de Londres coûte environ 12$ par mois), auquel s’ajoutent des frais suivant le nombre d’échanges et la quantité de données échangées. Un très grand nombre de services stockent leurs fichiers sur Amazon S3 pour ne plus avoir à s’embarrasser de la problématique du stockage.
Amazon Glacier est lui aussi un espace de stockage de fichiers illimité. Sauf que contrairement à S3, il a été conçu spécifiquement pour les stockages à très longue durée, qui n’ont pas forcément besoin d’être lus en temps réel. Le coût est extrêmement faible (compter 2,25$ par mois pour stocker 500 GO de données à Londres), mais en contrepartie la récupération de données peut prendre entre quelques minutes et 12 heures (suivant le tarif de récupération choisi).

Mon souhait était de pouvoir fonctionner (pour mes serveurs personnels) de la manière suivante :

  • Sauvegarder tous les jours certains répertoires et certaines bases MySQL.
  • Écrire ces sauvegardes sur le disque local, mais les copier aussi sur Amazon S3 et sur Amazon Glacier.
  • Garder les sauvegardes sur le disque local pendant 3 jours avant de les effacer, pour que les versions les plus “fraîches” soient accessibles immédiatement en cas de problème.
  • Attendre 2 semaines avant d’effacer les archives stockées sur Amazon S3, pour permettre une récupération relativement facile de données assez récentes, sans pour autant payer le stockage de données périmées.
  • Garder sans limite de temps les archives stockées sur Amazon Glacier, pour avoir une trace de toutes les versions de mes fichiers.

Ça a l’air simple, vu comme ça, mais je n’ai pas trouvé d’outil me permettant de le faire simplement.
Et pour compliquer un peu les choses, mes besoins professionnels vont plus loin :

  • Sauvegarder toutes les heures certains répertoires et certaines bases MySQL.
  • Écrire ces sauvegardes en local, ainsi que sur Amazon S3 et Amazon Glacier.
  • Garder toutes les sauvegardes (donc 24 sauvegardes par jour) en local pendant 3 jours ; puis n’en garder qu’une sur six (donc 4 sauvegardes par jour) pendant 4 jours ; puis une par jour pendant une semaine.
  • Garder toutes les sauvegardes sur Amazon S3 pendant 2 semaines ; puis une sur quatre (6 sauvegardes par jour) pendant 2 semaines ; puis une par jour pendant un mois.
  • Stocker les archives sur Amazon Glacier sans limite de temps.

Donc là il faut être capable de faire une sauvegarde toutes les heures, mais aussi gérer les purges (en local et sur Amazon S3) de manière très fine.

J’ai donc pris la décision de créer mon propre script de sauvegarde et d’archivage. Les habitués de ce blog se souviennent que j’ai écrit récemment un article sur l’utilisation de mysqldump, fournissant même un script de sauvegarde de bases MySQL qui allait jusqu’à copier les sauvegardes sur Amazon S3. Je suis juste passé à l’échelle supérieure.

Pour un maximum de portabilité, j’ai développé le programme en shell Bash. C’est le shell le plus courant sur les systèmes Unix/Linux.  Ainsi, pas besoin d’interpréteur spécifique (ce qui serait le cas si je l’avais développé en PHP) et pas besoin de compilation (ce qui aurait été nécessaire si je l’avais codé en C).
Pour être le plus ergonomique possible − dans la mesure de ce qu’il est possible de faire en ligne de commande − j’ai pris le temps de faire deux choses :

  • La configuration est interactive. La génération du fichier de configuration se fait en répondant à des questions (dont une majorité proposant des réponses par défaut) et non pas en remplissant à la main un fichier vide. Et le script ajoute automatiquement (enfin, si vous le souhaitez uniquement) Arkiv en Crontab pour qu’il soit exécuté automatiquement à la fréquence que vous souhaitez.
  • J’utilise les capacités ANSI des terminaux pour faire un peu de mise-en-page des textes, avec de la couleur, des textes en gras ou en vidéo-inverse. Que ce soit pour la génération du fichier de configuration ou pour les logs d’exécution, cela facilite grandement la compréhension.

Et pour le nom du projet, j’ai choisi un mot qui veut dire “archive” dans plusieurs langues (notamment scandinaves ; un peu comme Skriv, qui veut dire “écrire” dans ces mêmes langues).

Comment installer Arkiv

La directive est assez simple, et expliquée sur la page GitHub du projet.
Pour commencer, il faut cloner le repository :

# git clone https://github.com/Amaury/Arkviv

Si vous souhaitez archiver sur Amazon S3 et Amazon Glacier : Avant de lancer le programme de configuration, il faut créer un “bucket” Amazon S3 et un “vault” Amazon Glacier (dans le même datacenter), puis créer un utilisateur IAM et lui donner les droits en lecture-écriture sur ce bucket et ce vault.

Ensuite on lance la configuration :

# cd Arkiv; ./arkiv config

Voici une copie d’écran d’un exemple d’installation :

Cliquez pour agrandir

(Dans cet exemple, vous pouvez voir que les sauvegardes sont faites toutes les heures, archivées sur Amazon S3 et Amazon Glacier, et que les purges sont configurées assez finement.)

Il est possible de faire en sorte que les sauvegardes ne se fassent pas tous les jours et toutes les heures, mais de choisir une fréquence à la carte. Et comme il est possible d’utiliser plusieurs fichiers de configuration différents (en fournissant leurs chemins en paramètre), il est possible de mettre en place des politiques de sauvegarde assez complexes, pour coller au plus près des besoins.

À la fin de ce processus, le fichier de configuration est créé, et le programme a été ajouté en Crontab pour s’exécuter automatiquement.

À l’exécution

Lorsque le programme s’exécute, il passe par plusieurs étapes :

  1. Démarrage
    1. Arkiv est lancé par la Crontab.
    2. Il crée un dossier sur le disque local, qui accueillera les fichiers sauvegardés.
  2. Sauvegarde
    1. Tous les chemins listés dans la configuration sont compressés et le résultat est enregistré dans le dossier dédié.
    2. Si la sauvegarde MySQL est activée, les bases de données sont dumpées et sauvegardées dans le même dossier.
    3. Des checksums sont calculés pour tous les fichiers sauvegardés.
  3. Archivage
    1. Si l’archivage sur Amazon Glacier a été activé, tous les fichiers de sauvegarde y sont copiés. Pour chacun d’eux, un fichier JSON est créé, contenant la réponse renvoyée par Amazon. Ces fichiers contiennent les identifiants nécessaires à la récupération des fichiers.
    2. Si l’archivage sur Amazon S3 a été activé, le dossier et tout ce qu’il contient (fichiers de sauvegarde, fichier de checksum, fichiers JSON d’Amazon Glacier) y sont copiés.
  4. Purge
    1. Effacement sur le disque local des fichiers de sauvegarde qui ont atteint l’âge défini.
    2. Si l’archivage sur Amazon S3 a été activé, les fichiers de sauvegarde qui ont atteint l’âge défini sont effacés. Les fichiers de checksum et les fichiers JSON d’Amazon Glacier ne sont pas effacés, afin de permettre la récupération des fichiers archivés sur Amazon Glacier et d’en vérifier l’intégrité.

Sauf en cas de problème, l’exécution du programme se déroule de manière silencieuse.

Voici un exemple de ce que vous pourrez trouver dans le fichier de log :

Cliquez pour agrandir

Vous pouvez voir que la « mise-en page » est là pour rendre les logs faciles à lire. Les éventuelles alertes et erreurs sont mises en avant grâce à de la couleur et des pictos.

Améliorations futures

Comme toujours, j’ai développé ce logiciel pour répondre à mes besoins, et je le rends accessible à tous sous licence libre parce qu’il pourra rendre des services à d’autres personnes que moi.
Je n’ai pas envie d’en étendre les fonctionnalités. L’archivage par FTP ou SCP, ou sur des plates-formes Cloud autres que celle d’Amazon, pourrait être pratique pour certains, mais cela complexifierait beaucoup le code. Arkiv ne se destine pas à être un outil obèse capable de tout gérer ; je préfère qu’il reste un outil avec des fonctionnalités réduites, mais qu’il adresse les bonnes fonctionnalités, et qu’il les accomplisse le mieux possible.
Donc on verra.

En attendant, n’hésitez pas à le tester et à me faire des retours. Si vous trouvez des bugs, vous pouvez utiliser la buglist fournie par GitHub.

Edit du 13 août : J’ai ajouté une fonctionnalité supplémentaire, l’encryption des fichiers (algorithme AES 256 bits par OpenSSL). Ça peut être utile pour les plus paranoïaques 😉

Edit du 29 août : J’ai ajouté le support des sauvegardes binaires de bases de données (utilisant l’outil xtrabackup), en global ou incrémental. Ainsi que l’écriture des logs dans syslog.

Mise-à-jour Ubuntu Server

Il y a un an, j’écrivais un article sur l’installation de serveur HTTP. J’expliquais qu’à l’époque j’avais utilisé un petit serveur virtuel sous Ubuntu 16.04.

Vous le savez sûrement, le cycle de sortie des versions de la distribution Ubuntu respecte un rythme qui fait qu’une version LTS (Long Term Support, support longue durée, avec des mises-à-jours pendant 5 ans) sort tous les deux ans, et des versions intermédiaires tous les six mois.
La version 16.04 était une version LTS, ce qui est plutôt bien pour un serveur. Mais si mettre à jour un serveur tous les 6 mois est assez contraignant, attendre 2 ans peut être embêtant si on a besoin de packages récents.

Donc comment faire pour mettre à jour une 16.04 en 17.04 ?

(toutes les commandes ci-dessous sont à exécuter en tant que root)
Pour commencer, on va s’assurer que le système est bien à jour :

# apt-get update
# apt-get dist-upgrade

Puis on va redémarrer le serveur (au cas où le kernel a été mis à jour, par exemple) :

# reboot

Une fois le serveur redémarré, on va s’assurer que le package “update-manager-core” est installé (il devrait l’être, mais on ne sait jamais) :

# apt-get install update-manager-core

On va ensuite éditer le fichier /etc/update-manager/release-upgrades car il contient une directive importante pour la mise-à-jour du système ; par défaut, l’option “Prompt” vaut “lts”, ce qui fait qu’on ne pourra mettre à jour notre système 16.04 que vers une prochaine LTS (ce sera la 18.04, qui sortira en avril 2018). Si on veut que le système se mette à jour vers n’importe quelle version (LTS ou intermédiaire), il faut que le fichier contienne la ligne suivante :

Prompt=normal

Avant de lancer la mise-à-jour, il faut savoir qu’en cas de problème les choses peuvent être un peu compliquées dans le cas où on met un serveur à jour à distance. Le programme de mise à jour va démarrer un second serveur SSH sur le port 1022 ; il faut donc d’abord ouvrir ce port dans votre firewall, ou bien l’ouvrir temporairement avec la commande :

# iptables -A INPUT -p tcp --dport 1022 -j ACCEPT

Je vous recommande aussi de lancer la mise-à-jour dans un terminal géré par le programme “screen” ; il sera ainsi possible de récupérer votre terminal même si vous vous faites déconnecter (à la condition de pouvoir rétablir une connexion SSH et que la machine n’a pas redémarré entretemps). Commencez par l’installer si nécessaire, puis exécutez-le :

# apt-get install screen
# screen

(il faut appuyer une deuxième fois sur la touche Entrée pour entrer dans le terminal)
On peut ensuite lancer la mise-à-jour :

# do-release-upgrade

Au fur et à mesure que les paquets logiciels seront mis à jour, on va vous demander si vous souhaitez mettre à jour les fichiers de configuration ou si vous souhaitez garder votre version locale. À vous de voir ce que vous préférez, mais si un logiciel change de version majeure, vos fichiers de configuration risquent de ne plus être compatibles ; il vaut peut-être mieux faire d’abord une copie de vos fichiers, d’accepter de les mettre à jour, puis de regarder les différences une à une.

Enfin, sachez que − pour cet exemple précis − la mise-à-jour se fait théoriquement de la version 16.04 vers la version 16.10 ; il faut donc renouveler l’opération une seconde fois. Toutefois, lors de mes tests sur plusieurs machines, une seule opération de mise-à-jour m’a amené directement en version 17.04.
Si vous n’êtes pas sûr, vous pouvez connaître la version installée de la manière suivante :

# more /etc/lsb-release

Autre méthode, qui fonctionne sur un grand nombre de distributions (toutes celles qui sont conformes aux spécifications de la Linux Standard Base) :

# lsb_release -a

 

Durée des cycles agiles

La durée des cycles est une question qui revient fréquemment quand on parle de mettre en place des méthodes agiles dans une entreprise.
Évidemment, il est impossible de donner une durée absolue ; comme pour le reste, il faut l’adapter à l’entreprise, les personnes, les besoins… La plupart du temps, plusieurs visions s’affrontent :

  • Les développeurs qui ont déjà travaillé “en agile” ou qui ont lu des articles sur le sujet, et pour qui un sprint fait 2 semaines. C’est comme ça.
  • Les “décideurs”, pour qui il est plus efficace de faire des cycles longs − entre 1 et 3 mois de développement − car cela maximise la durée de développement par rapport au reste.
  • Les clients (internes ou externes), qui oscillent entre un désir brûlant de voir l’avancement de leurs projets et de demander des modifications en temps réel d’un côté, et de l’autre un dégoût prononcé pour les tests et peu de temps à consacrer pour faire des remontées structurées.
  • Les personnes qui participent à la conception et dont l’avis peut varier énormément suivant qu’elles aient été formées à l’agilité ou non. Quand elles ne le sont pas, elles ont tendance à imaginer le produit parfait, sans vouloir le découper de manière incrémentale ; auquel cas, elles préfèrent évidemment des longs cycles. Celles qui ont été formées à l’agilité connaissent les avantages de réfléchir de manière plus itérative et n’hésitent pas à partir moins loin dans leurs conceptions.

La conception

Il est assez intéressant de voir que la plupart des informations qu’on peut trouver sur le sujet − que ce soit sur Internet ou dans les formations agiles − se concentrent uniquement sur le développement. Même en lisant des choses sur les principes agiles appliqués à la spécification (user stories, principalement), tout le monde semble penser que la création de ces spécifications est une chose hyperfacile et pour laquelle il n’y a pas vraiment besoin d’établir un process, et qu’en conséquence on peut partir du principe que tout commence une fois que l’équipe de développement reçoit les user stories (ou qu’elle n’a qu’à piocher dans un backlog bien rempli).

Mais c’est une erreur complète.

Les phases de conception sont au moins aussi importantes que celles de développement, de test et de déploiement.
Pour être menées correctement, elles doivent être faites de la bonne manière, par les bonnes personnes, avec des processus bordés.

J’ai un exemple en tête. Une entreprise qui est passée à une organisation agile (du Scrum «by the book») avec des cycles de 2 semaines, sans se préoccuper vraiment de  la manière dont les spécifications étaient réalisées. Leur idée a été de mener en parallèle les spécifications et le développement (jusque-là rien d’incohérent), en misant sur le fait que deux semaines de spécification étaient suffisantes pour alimenter deux semaines de développement. Ainsi, un “Sprint Zéro” devait alimenter le premier sprint de développement qui commençait deux semaines plus tard.
Si certains développements peuvent être spécifiés très rapidement, d’autres demandent beaucoup plus de temps. Spécification et développement sont sur des temporalités très différentes. Ce qui devait arriver arriva : Le premier sprint de développement n’a pas pu être complètement alimenté par le sprint zéro. Et surtout, il ne suffit pas de dire à des gens «Vous avez deux semaines pour spécifier, démerdez-vous» pour qu’ils réussissent à faire leur boulot ; il faut un peu de process si on ne veut pas partir dans tous les sens (et donc arriver nulle part).

Les cycles et ce qu’ils impliquent

Un cycle représente une unité de temps au bout de laquelle on va (tenter de) créer quelque chose dont le résultat sera montrable.

Se focaliser uniquement sur le travail de développement est une erreur, car cela peut entraîner de graves oublis dans les phases amont (spécification) aussi bien que dans les phases situées en aval (test, déploiement).
Il est de la responsabilité de l’ensemble de l’équipe de fournir du logiciel utile et de qualité. “Utile” implique que le client s’en serve, et donc que les spécifications soient menées correctement (en prenant en compte les besoins et en sachant changer de direction quand il le faut) ; “de qualité” veut dire que l’on se donne les moyens pour réduire les bugs, augmenter l’évolutivité, réduire les coûts inutiles, documenter ce qui doit l’être, etc.

J’ai expliqué précédemment pourquoi je pense que la manière de produire les spécifications doit être prise en considération dans la mise en place d’un cycle agile. Similairement, on ne se pose plus trop la question sur le fait de tester le logiciel avant de le déployer en production.

Avoir un cycle implique donc que ce qui en sort est testé et validé. Et il faut voir que cela a un coût, mais qu’il est difficile de mettre le curseur au bon endroit. En effet, une phase de test & déploiement a une durée incompressible ; une telle phase ne sera pas deux fois plus longue à la fin d’un cycle de 4 semaines qu’après seulement 2 semaines de développement. Par contre, attendre 3 mois avant de vouloir valider quoi que ce soit paraît suicidaire, car le risque de rencontrer des problèmes bloquants (ou juste très importants) augmente avec le temps qui passe.

Le rôle des développeurs

Si je mets en avant les lacunes des organisations qui se focalisent sur le développement au détriment de la vue d’ensemble (depuis les spécifications jusqu’au déploiement), c’est parce que tout problème a tendance à retomber sur l’équipe de développement.

Une fonctionnalité a été mal spécifiée ? Pas de problème, la demande sera précisée en cours de développement ; avec plusieurs changements en cours de route si nécessaire. C’est le meilleur moyen pour cumuler les retards et générer du code spaghetti.
Un développement n’a pas été testé correctement ? Mettons-le quand même en production. Si un bug est trouvé par la suite, on se dépêchera de faire un correctif. C’est parfait pour avoir des problèmes énormes en production (pouvant impacter le chiffre d’affaires ou la réputation à long terme, par exemple), et à faire des correctifs rapides et eux-mêmes buggués, conduisant au suraccident.

Non seulement la qualité globale du travail de l’équipe diminue, mais en plus cela fait peser une pression inutilement forte sur les développeurs, juste parce que d’autres personnes n’ont pas fait leur travail ou l’ont mal fait.

Le rôle des développeurs sur les projets est triple :

  • Accompagner les phases de conception, pour proposer des solutions techniques aux problèmes fonctionnels.
  • Réaliser le code qui implémente la demande fonctionnelle, en cherchant à trouver la bonne mesure entre le temps passé et la valeur intrinsèque de la fonctionnalité, en suivant les bonnes pratiques de l’entreprise.
  • S’assurer que son code fonctionne, que ce soit d’un point de vue technique (adéquation avec le reste de l’architecture, performance, etc.) ou fonctionnel.

À cela s’ajoutent des responsabilités parallèles en fonction des situations (propositions techniques, organisation de conférences ou de hackathons, ou autre).
Mais dans tous les cas, les développeurs ne se destinent pas à prendre sur eux les lacunes des autres…

Les cycles de deux semaines

Lorsque quelqu’un me dit qu’il travaille sur des cycles de 2 semaines, je lui réponds «Non, ça c’est la durée de votre sprint de développement». Je ne remets pas en question ce choix, deux semaines étant souvent une durée ni trop courte ni trop longue pour assurer des développements.
Mais que se passe-t-il pour ceux qui essayent vraiment de faire tenir leur cycle en deux semaines ? Pour commencer, les spécifications ne sont pas prises en considération ; c’est une erreur, je ne vais pas revenir là-dessus. Ensuite, on peut imaginer que le cycle se déroule de la manière suivante :

  • En début de cycle, une demi-journée est consacrée aux rituels de début de cycle (étude des user stories, planning poker).
  • En fin de cycle :
    • Une demi-journée est utilisée pour faire la démo des nouveaux développements aux clients.
    • Une demi-journée est consacrée aux tests fonctionnels (automatisés et/ou par les clients). Le déploiement sur un environnement de test (préprod, qualification, appelez-le comme vous voulez) conditionne cette demi-journée, qui peut être réduite si tout ne s’est pas bien passé…
    • Une demi-journée ou une journée est consacrée aux résolutions de bugs mineurs, en fonction des retours de tests. Les bugs majeurs font que le développement est sorti de la release et sera traité sur un autre cycle.
    • Une demi-journée est consacrée au déploiement en production.
    • Une demi-journée est réservée pour ce qui permet de clore le cycle : la rétrospective ou le niko-niko, l’analyse de ce qui a été écarté durant le cycle, etc.

Au final, il reste donc au mieux 7 jours de développement (ce qui n’est pas si mal en fait). Mais surtout, ce genre de cycle a deux impacts qui sont souvent oubliés un peu facilement :

  • Le moindre grain de sable peut tout enrayer. Une mise en préprod un peu longue, des tests qui démarrent un peu tard ou qui durent plus longtemps que prévu, une longue liste de bugs à corriger absolument… et c’est l’ensemble du cycle qui risque de déborder. Avec pour résultat un « intercycle » qui ne servira qu’à faire les tests, les débogages ou le déploiement qu’on n’avait pas eu le temps de faire.
  • On fait peser une contrainte forte sur l’ensemble des parties prenantes. Les clients ont une fenêtre de tir extrêmement réduite pour tester les développements qui les concernent. Les développeurs n’ont pas de temps de répit qu’ils peuvent consacrer à des refactorings.

Le sentiment d’urgence continuelle créé par la combinaison de ces deux points peut se révéler très anxiogène à la longue. Comme le dit Jason Fried au sujet des cycles utilisés chez Basecamp (j’y reviens plus bas) :

These are not sprints. I despise the word sprints. Sprints and work don’t go together. This isn’t about running all out as fast as you can, it’s about working calmly, at a nice pace, and making smart calls along the way. No brute force here, no catching our collective breath at the end.

Automatisation et déploiement continu

Sur un cycle de 2 semaines, on cherche évidemment à automatiser le plus possible les tests, pour minimiser le temps passé à tester et pour réduire les impacts possibles.

Mais il n’en reste pas moins que tout n’est pas testable automatiquement. Que ce soit dans le design (pour un site web) ou pour des questions d’infrastructure (une plate-forme de production peut légitimement avoir des différences par rapport à une plate-forme de test), il faut souvent valider à la main certains points-clés.

Le déploiement continu est quelque chose qui peut être très efficace lorsqu’il est correctement conduit. En mettant en production les développements au fur et à mesure qu’ils sont prêts, on augmente la réactivité de l’entreprise.
Sauf que lorsque cela est mal mené, on peut vite tomber dans un travers assez classique : On se dépêche de mettre en production des développements qui ne sont pas suffisamment testés (que ce soit de manière automatisée ou non), parce qu’il sera toujours facile et rapide de mettre en ligne un correctif s’il le faut. Sauf qu’en procédant de la sorte, on fait encore peser la responsabilité sur les seules épaules du développeur (s’il y a un bug, c’est de sa faute et non celle de celui qui a mal testé), et on risque de fonctionner à coups de correctifs qui s’empilent en faisant perdre toute vision d’ensemble.

Dans une entreprise que j’ai visitée il y a quelques années, un graphique était affiché sur un écran dans l’open-space. Une courbe montrait l’évolution du chiffre d’affaires, et des barres verticales symbolisaient les mises en ligne ; ainsi, lorsqu’un bug avait pour effet de faire chuter le chiffre d’affaires, il était facile d’identifier le développement responsable.
Sauf que je considère qu’on doit tout faire pour ne pas risquer d’avoir un site tellement bogué qu’il ne va générer aucun chiffre d’affaires, ne serait-ce que 5 minutes. Que ce soit pour le manque à gagner financier ou la perte d’image qui peut se révéler catastrophique à moyen terme, cela me semble trop grave. Surtout lorsque l’alternative est de différer le déploiement de seulement 2 semaines… De plus, on peut imaginer que des développements bogués passent à travers les mailles du filet, simplement parce qu’ils impliquent une faible baisse du chiffre d’affaires (mais une baisse quand même).

Pour que ça fonctionne sans accroc, il faut y mettre des moyens humains et techniques assez importants.

Les cycles de 6 semaines

Les gars de Basecamp ont mis en place des cycles de 6 semaines. Ils l’ont annoncé sur leur blog, puis sont revenus dessus pour expliquer comment cela se passait.

Je vous invite à lire les deux articles, qui sont assez longs.
En résumé, ils constituent des équipes de 2 ou 3 personnes (un ou deux développeurs et un designer), en fonction de ce sur quoi les gens ont envie de travailler pendant les 6 prochaines semaines. Chaque équipe réalise un “gros projet” (qui occupe tout le cycle) ou plusieurs “petits projets”.

Ils n’expliquent malheureusement pas clairement comment le travail se découpe au long de ces cycles. On apprend néanmoins qu’ils ont une équipe QA (Assurance qualité) de 2 personnes, qui est mise à contribution par les autres équipes pour s’assurer de la qualité des projets avant leurs mises en ligne.
(quand je parlais de moyens humains, on peut en voir un bon exemple ; ils ont 2 personnes dédiées à la qualité, pour 4 développeurs et 4 designers)

Mon expérience

J’ai déjà parlé sur ce blog (ici et ) de la manière dont j’avais mis en place les cycles chez Fine Media, continuellement améliorée pendant 6 ans.

Pour commencer, les projets étaient prédimensionnés suivant la technique des tailles de t-shirt (S, M, L, XL) − technique aussi bien utilisée dans les organisations agiles que dans de grosses entreprises. La durée de conception dépendait de cette estimation, et la partie plus classique «développement + test + déploiement» durait toujours un mois.

Si on prend l’exemple d’un projet Medium (environ 3 jours de développement), on avait une chronologie comme suit à partir de la validation de l’expression de besoin écrite par le client interne :

  • 1 semaine pour réaliser les wireframes
  • 2 semaines pour faire les maquettes
  • 1 semaine pour écrire la spécification fonctionnelle
  • 1 semaine pour écrire la spécification technique
  • 2 semaines [DEVeloppement] pour réaliser le développement
  • 1 semaine [STABilisation] pour tester le projet (par le développeur et par le client)
  • 1 semaine [Mise En Prod] pour valider en préprod puis mettre en prod

De manière un peu plus graphique, ça donne ça :

Vous pouvez imaginer que les cycles se chevauchent. Durant la semaine de MEP, la priorité des développeurs est de résoudre les bugs qui seraient trouvés en préprod (voire en prod) ; comme cela ne les occupe pas à plein temps, ils font les analyses techniques nécessaires pour les projets qu’ils auront à développer le mois suivant.

La semaine dévolue aux tests permet aux clients de s’organiser pour réaliser les validations nécessaires sans être dans la précipitation. Pour l’équipe technique, ce temps était mis à contribution pour faire des débogages, mais aussi pour réaliser des refactoring mineurs ou lancer des projets purement techniques qui sont ajoutés à la liste des projets par la suite.

À titre de comparaison, voici le cycle complet pour un projet Large (de 4 à 10 jours de développement). Vous pouvez voir que les durées de conception sont adaptées en conséquence :

Toutes ces durées sont évidemment d’ordre indicatif, certains projets ayant besoin de plus de temps pour certaines étapes, alors que d’autres projets pourront carrément se passer de certaines autres (par exemple, pas de maquettes sur des projets de back-office). Mais elles sont cohérentes face à ce qui avait pu être constaté. On peut trouver certaines durées très longues, mais elles sont aussi à mettre en perspective avec le fait que les mêmes personnes s’occupaient de plusieurs projets à la fois.

Ce workflow permettait de s’assurer qu’on était bien dans les clous, et qu’on n’essayait pas de faire tenir à tout prix un projet dans un cycle alors que les phases de conception étaient à la ramasse.
Et cela permet de voir que même avec des mises en production tous les mois, la vraie durée des cycles de développement est bien plus longue.

Et vous ?

Ça m’intéresserait de savoir comment les choses sont organisées dans votre équipe/entreprise. Est-ce que les phases de conception sont gérées ? Êtes-vous sur des cycles qui se résument à des sprints de 1, 2 ou 3 semaines ? Utilisez-vous des cycles plus longs, et si oui comment sont-ils structurés ?

Utilisation de MySQLDump

Il existe plusieurs moyens pour faire des sauvegardes de bases de données. Je ne vais pas parler ici de l’utilisation des logs binaires ni de la mise en place de réplication pour effectuer les sauvegardes sur un serveur esclave ; je vais me concentrer sur l’outil principal de sauvegarde lorsqu’on utilise MySQL : mysqldump

Je pense que tout le monde (en tout cas, une majorité des gens qui lisent cet article) sait à quoi sert cet outil. Il sert à écrire un fichier contenant toutes les directives SQL permettant de recréer une base de données à l’identique de l’état dans lequel elle se trouvait au moment de la sauvegarde.
Je ne vais pas m’étaler sur les aspects théoriques, mais plutôt vous expliquer comment je l’utilise.

Je me sers de mysqldump depuis une bonne quinzaine d’années, il me semble. À l’époque, l’utilisation par défaut (sans passer d’option particulière en ligne de commande) était assez pénible, surtout quand on voulait restaurer les données ; le code SQL généré contenait une commande INSERT pour chaque ligne de chaque table. Quand on injectait le fichier, le serveur mettait un temps infini pour exécuter toutes ces insertions et recalculer les index au fur et à mesure.
Ma vie a changé quand j’ai découvert l’option “–extended-insert”, qui regroupe plusieurs insertions dans une seule commande INSERT.

Les options à utiliser

Aujourd’hui, l’option “–opt” est activée par défaut sur les versions modernes de mysqldump. Cette option se contente d’activer par défaut les options suivantes :

  • –add-drop-table : Ajoute des directives pour effacer les tables avant de les recréer. Utile pour réinjecter un fichier en écrasant les anciennes versions des tables qui pourraient déjà traîner dans la base.
  • –add-locks : Ajoute des commandes pour verrouiller les tables pendant leur écriture ; il est alors impossible de lire ou d’écrire dedans en même temps que les données sont injectées, ce qui évite de ralentir l’injection.
  • –create-options : Ajoute les commandes de création des tables. On ne saurait s’en passer.
  • –disable-keys : Cette option accélère l’injection des données en faisant en sorte que les index sont créés qu’une fois que toutes les lignes sont injectées. Sauf que cela ne fonctionne qu’avec les index non uniques des tables MyISAM. Et comme vous êtes censés utiliser le moteur InnoDB à la place du MyISAM, on s’en moque un peu…
  • –extended-insert : Je viens d’en parler, c’est juste essentiel.
  • –lock-tables : Cette option a pour but de garantir l’intégrité des données qui sont sauvegardées, en verrouillant les tables durant la lecture. Je vais revenir sur ce point, car il est problématique.
  • –quick : Par défaut, quand mysqldump s’occupe d’une table, il tente de récupérer toutes les données en mémoire, avant d’en écrire le contenu. Sauf que si vous avez de très grosses tables, cela ne tiendra pas en RAM. L’option “–quick” empêche de tout charger en mémoire.
  • –set-charset : Demande l’ajout de la directive SET NAMES avec l’indication de l’encodage de caractères utilisés. Ça ne mange pas de pain.

Du coup, toutes ces options peuvent sembler utiles (et c’est sûrement pour ça qu’elles ont été regroupées sous l’option unique “–opt”, et que cette option est activée par défaut). Sauf qu’il y a un problème lorsqu’on exécute mysqldump en production avec ces options : Je vous ai dit que l’option “–lock-tables” verrouille les tables au moment où on les lit.

Encore une fois, la volonté derrière cela est assez simple. Si des écritures (ajouts ou modifications de données) ont lieu pendant la sauvegarde de la base de données, le fichier qui est généré n’a alors plus aucune cohérence. Vous pouvez avoir récupéré des données dont le début reflète un état différent de la fin, parce que les données ont bougé entretemps… Vous imaginez le bordel.
Sauf que si vous utilisez cette option sur votre serveur de production (et sans avoir mis en place une réplication qui vous permettrait de faire les sauvegardes sur un serveur esclave), cela veut dire que pendant toute la durée de l’exécution de mysqldump, votre application risque de vouloir manipuler les données… sans succès. Le pire, c’est que ces verrous sont posés par base ; donc si vous avez des données avec des liaisons qui se font entre des tables qui sont dans des bases différentes, cela ne sera pas suffisant de toute façon.

Continuer la lecture de « Utilisation de MySQLDump »

Création de l’entreprise Skriv

Ceux qui me connaissent, avec qui j’ai travaillé ou qui suivent ce blog depuis longtemps, ont déjà entendu parler de «Skriv». Ce mot, qui veut dire “écrire” en plusieurs langues, je l’ai utilisé pour plusieurs choses au fil du temps : langage de balisage léger, projet open-source de wiki simplifié, outil de gestion de projet utilisé dans ma précédente entreprise pendant 4 ans, etc.

Aujourd’hui, c’est un nouveau chapitre de ma vie qui s’ouvre. J’ai créé une startup qui se nomme Skriv, et dont le produit sera un logiciel de gestion de projets. Eh oui, on ne se refait pas.

Merci à Solène Tessier pour le logo

Pourquoi vouloir se lancer sur ce secteur, où il y a déjà beaucoup de concurrents ? Pour 3 raisons toutes simples :

  • C’est un sujet que j’aime.
  • C’est un sujet que je maîtrise.
  • C’est un sujet auquel je pense pouvoir apporter quelque chose de différent.

Un sujet que j’aime

Oui, la gestion de projets, c’est quelque chose que j’apprécie. Ce n’est pas nouveau. Si ce n’était pas le cas, je n’aurais sûrement pas fait ce blog 😉

Si j’aime ça, c’est sûrement parce que c’est un mélange de process et de structuration d’un côté, et de management de l’autre. Ces deux aspects sont intrinsèquement liés, il faut se sentir à l’aise avec l’ensemble si on veut être capable de faire du bon boulot.
Car souvenez-vous, la gestion de projets ça n’existe pas : on ne gère pas des projets, on gère des gens qui travaillent sur des projets.

Un sujet que je maîtrise

La gestion de projet, j’en ai appris des notions de base durant mes études d’ingénieur, que j’ai mises en pratique en étant chef de projets dans plusieurs startups.
J’ai participé à la création de la société Fine Media en tant que directeur technique. Ce rôle m’a amené à mettre en place des processus dans l’entreprise et à réfléchir à l’ensemble de la manière dont on gérait les projets de développement.
J’ai fait un Executive MBA en “Management et Entrepreneuriat”, qui m’a permis d’approfondir mes connaissances.
J’ai fait une certification de 8 mois en “Software Product Management” à l’Université d’Alberta, qui m’a conforté dans ce que je savais, et ce que je savais faire.

Concernant les logiciels de gestion de projet, j’en ai testé et évalué un assez grand nombre, que ce soit pour les besoins de ce blog ou pour ceux des entreprises dans lesquelles j’ai travaillé.
J’ai développé sur mon temps libre le logiciel de gestion de projets qui était utilisé chez Fine Media. C’était au début un wiki sous stéroïdes, puis j’y ai ajouté la gestion de tâches, puis j’y ai intégré la gestion de tout notre workflow. Ce logiciel était utilisé par des gens aux profils très différents (des chefs de projets, des informaticiens, des content managers, des commerciaux, des account managers…) et il a fallu faire en sorte qu’il soit manipulable le plus simplement possible.

Cette expérience a une grande valeur. Aujourd’hui, je ne développe pas le premier prototype de mon logiciel ; j’en suis à la cinquième version !

Les trois premières versions n’étaient pas très belles, mais elles étaient efficaces et simples d’utilisation :

La quatrième version était déjà une réécriture totale :

Soyez patients pour voir à quoi ressemblera la cinquième version 😉

Un sujet auquel je pense pouvoir apporter quelque chose de différent

Oui, il existe un certain nombre de logiciels de gestion de projets sur le marché. Certains sont assez gros ; il y a eu de belles levées de fond, des rachats et même des entrées en bourse… Est-ce que ça veut dire que ce marché est bouché ? Je ne le pense pas. Le nombre d’entreprises qui ont besoin d’outils performants est énorme, il y a toujours une place à se faire. Par contre, il faut savoir se différencier des autres.

Si on regarde à quoi ressemble le marché :

Image provenant de https://www.inflectra.com/company/article/452.aspx

Pour moi, le but est d’être là :

Ne pas être celui qui a le plus de fonctionnalités, mais celui qui apporte la meilleure plus-value.

Alors en quoi Skriv est-il différent des autres ? Eh bien là où ils sont tous orientés “tâches”, Skriv est orienté “workflow”. Pour avoir travaillé plusieurs années en utilisant cette vision (après avoir travaillé auparavant de manière plus conventionnelle), je peux vous assurer que cela permet d’être bien plus efficace. Plus de projets, mieux gérés (plus vite, avec moins d’erreurs), moins de stress…
Et cela est tellement éloigné de l’ADN des autres logiciels (souvenez-vous que JIRA a même commencé en n’étant qu’une buglist) que je pense pouvoir me faire une place.

J’ai quelques idées supplémentaires quant au positionnement et au pricing… mais il faudra attendre un peu avant que je dévoile tout ça 😉

Et la suite ?

Pour faire simple, je suis en plein développement. Les formalités administratives m’ont pris du temps et de l’énergie, mais je continue à avancer à un bon rythme.

Le but est de lancer une version bêta dans quelques mois, avec un nombre réduit d’entreprises/équipes qui accepteront de jouer le jeu (c’est-à-dire vraiment utiliser l’outil pour me faire des retours pertinents) en échange d’un accès gratuit pendant un bon bout de temps. Quelques mois plus tard, ce sera le lancement commercial, dont le succès dépendra de tant de critères (qualité de la réalisation, efficacité du marketing mis en place, etc.) que je n’ose faire le moindre pronostic pour le moment. Il faut mettre le curseur au bon endroit entre humilité et ambition 😀

Je vais évidemment continuer à parler de ma création d’entreprise sur ce blog ; on est en plein dans le sujet, que ce soit l’aspect entrepreneurial ou tout ce qui concerne la gestion de projets elle-même.

Si vous souhaitez être prévenu lors du lancement, je vous invite à entrer votre adresse email dans le formulaire sur le site skriv.com.

Combien de développeurs mettre sur un projet

Je considère la question intéressante : Combien de développeurs faut-il assigner à un projet ?

Intéressante parce que cette question revient à une fréquence relativement élevée, alors que sa réponse est simple à comprendre et qu’elle reste invariable au fil du temps.

Si cette question revient fréquemment, c’est bien parce que l’élan naturel de la plupart des décideurs (souvent des gens qui viennent du business et qui ne savent pas comment on fait du logiciel ; mais je connais des informaticiens qui ont le même tropisme) est de penser que pour aller plus vite, il faut mettre plus de ressources.

Après tout, le moyen le plus simple pour peindre un mur plus vite, c’est de faire appel à plus de peintres, non ?

Le mythe du mois-homme

Ce phénomène a été disséqué par Frederick Brooks dans son livre Le mythe du mois-homme. Paru en 1975 et réédité en 1995, c’est un classique des livres de management informatique. Eh oui, cela fait plus de 40 ans que ce problème a été analysé, et pourtant il est toujours autant d’actualité !

À défaut de le lire (l’édition française est introuvable, la seconde édition américaine est maintenant hors de prix, mais la première édition se trouve aisément en PDF − ne me demandez pas si l’auteur et l’éditeur ont donné leur accord pour sa diffusion), je vous conseille de lire l’article consacré au livre sur Wikipédia.

Pour faire un résumé très rapide, le livre présente deux concepts :

  • Le premier est que c’est une illusion de croire que le travail réalisé par un développeur en deux mois peut être fait par deux développeurs en un mois. Le parallèle archiconnu est celui des femmes enceintes (si une femme fait un enfant en neuf mois, neuf femmes ne feront pas un enfant ensemble en un mois).
  • Lorsqu’un projet est en retard, lui affecter des personnes supplémentaires ne fera qu’ajouter encore plus de retard. Chaque nouvel intervenant devra prendre le temps de monter en compétence, et devra communiquer avec tous ceux déjà en plus ; ainsi, ce n’est pas 1 canal de communication qui va s’ajouter, mais X canaux (X étant égal au nombre de personnes qui travaillent déjà sur le projet). Et cela peut aboutir à des situations ridicules, lorsque le temps de traitement des échanges d’information est supérieur au temps nécessaire à chacun pour réaliser son boulot.

Continuer la lecture de « Combien de développeurs mettre sur un projet »

Gérer sa carrière

Si ce blog s’appelle «De geek à directeur technique», c’est parce que mon but initial était de transmettre des choses pouvant aider les informaticiens à faire évoluer leurs carrières. Au fil des ans, j’ai écrit des articles variés qui pouvaient tous − d’une manière ou d’une autre − s’inscrire dans ce grand tout. Néanmoins, je n’ai jamais pris le temps de revenir sur les fondamentaux de la gestion de carrière… mais il n’est jamais trop tard.

Pourquoi penser à sa carrière ?

C’est une question qui peut paraître un peu idiote, mais elle mérite qu’on s’y attarde un instant.
Pour la plupart des gens, cela semble évident : Une carrière qui « monte », ça veut dire plus de responsabilités, un meilleur salaire, un travail plus intéressant, de nouveaux enjeux qui impliquent d’apprendre des choses nouvelles. Toutes ces choses sont positives dans le monde professionnel et ne doivent pas être vues comme des objectifs réservés aux seuls carriéristes qui ont les dents qui rayent le parquet.
Alors prenez le temps d’y réfléchir ; demandez-vous quels sont les critères qui ont de l’importance pour vous. Quand vous regarderez en arrière dans quelques années, qu’est-ce qui fera que vous serez satisfait de votre évolution professionnelle ?

Mais sommes-nous tous destinés à cela ?
Eh bien non. Pensez à Steve Wozniak ; à la fin des années 70 et au début des années 80, quand Apple devenait une grosse multinationale, il avait exprimé une crainte viscérale chez lui : il n’avait aucune envie de devenir manager. Son truc, c’était de créer des appareils électroniques, chose pour laquelle il avait du talent ; mais gérer des personnes, très peu pour lui. Pendant des années, il a réussi à garder son rôle d’ingénieur, faisant partie de l’équipe de développement de l’Apple II mais sans faire partie du management (même si on peut imaginer qu’il avait un poids plus conséquent que les autres ingénieurs de l’équipe). Quand cela n’a plus été possible (les puristes me pardonneront de simplifier un peu les choses ; je vous suggère de lire son autobiographie iWoz pour en savoir plus), il est parti créer la première télécommande universelle. Au final, c’était ce dont sa carrière avait besoin, et c’est comme ça qu’il l’a gérée.

Il existe tout un tas de raisons légitimes pour ne pas chercher à booster sa carrière. Parfois, grimper les échelons implique de faire des choses qu’on ne souhaite pas faire (comme dans l’exemple de Woz). Parfois cela nous oblige à revoir l’équilibre vie pro/vie perso d’une manière qui ne correspond pas à nos attentes. Ou encore, cela amène à identifier des zones d’ombres, des lacunes qui n’étaient pas problématiques jusque-là mais qui nécessiteraient d’être comblées avant de pouvoir progresser. Continuer la lecture de « Gérer sa carrière »

L’obsolescence programmée

Il y a maintenant plusieurs années, un reportage nommé «Prêt à jeter – Obsolescence programmée» a été diffusé sur la chaîne Arte. Si vous ne l’avez pas vu, je ne peux que vous conseiller d’y consacrer une heure, c’est vraiment très intéressant :

Ce reportage présente le concept d’obsolescence programmée, le mécanisme qui consiste à créer des produits qui vont volontairement avoir une durée de vie réduite, dans le but de pousser à la consommation.

Et il est bon de rappeler que cette pratique a été rendue illégale en France en 2015.

Les exemples du reportage

Le premier exemple présenté est celui d’un utilisateur dont l’imprimante s’arrête soudainement de fonctionner. Après quelques recherches, il s’avère qu’elle contient une puce qui compte le nombre de pages imprimées, et qui fait qu’au bout d’un certain nombre d’impressions l’imprimante arrête de fonctionner.
À chaque boutique où il s’adresse, on lui dit que ça lui coûtera moins cher d’acheter une nouvelle imprimante que de faire réparer l’ancienne. Mais il ne veut pas, son imprimante fonctionne très bien.
Il finit par trouver un petit programme qui remet à zéro la puce de comptage. Et l’imprimante se remet alors à fonctionner comme avant.

Le second exemple fourni est plus inquiétant. Pendant 15 ans, plusieurs fabricants d’ampoules électriques de la planète − regroupés en un consortium secret − se sont mis d’accord pour limiter la durée de vie de leurs produits. Alors que les ampoules fabriquées dans les années 30 duraient plusieurs milliers d’heures (le reportage commence même avec l’exemple d’une ampoule qui éclaire une caserne de pompiers depuis un siècle sans discontinuer), toutes les ampoules produites ont alors eu la même durée de vie : 1000 heures.
Le but évident était de pousser à la consommation. Si les ampoules durent moins longtemps, on en vend plus.

Continuer la lecture de « L’obsolescence programmée »

Livre : Reinventing Organizations

Le livre Reinventing Organizations est un best-seller dont une version illustrée a été éditée. J’ai acheté cette version, qui met son contenu en scène à travers des illustrations bien réalisées.

Le livre se découpe en trois parties :

  • La première est consacrée à une étude de différents types d’organisations existants, avec un focus sur l’émergence d’un nouveau type plus moderne.
  • La deuxième partie explique ce nouveau type, à travers les concepts qui se retrouvent dans les cas où ce genre de management a été mis en œuvre.
  • La troisième partie donne des outils pour aider à la mise en place de ces principes au sein d’une organisation.

Ce livre est vraiment intéressant. Que l’on soit d’accord ou non avec ce qu’il présente, tout bon manager (même les mauvais) devrait le lire pour s’ouvrir aux concepts qui y sont abordés.
Je ne vais pas détailler les trois parties du livre, mais pour vous donner envie de le lire, je vais vous résumer les différents types d’organisations qui y sont décrits. L’auteur donne une couleur à chaque type (on peut trouver ça bizarre, mais au final ça marche plutôt bien).

(Je vais paraphraser certains passages, et reproduire quelques illustrations. Encore une fois, le but est de vous faire connaître ce livre, pas d’en faire un plagiat. Je vais mettre des citations quand les mots du livre le mériteront.)

Rouge − Stade impulsif

Au début de l’humanité, il n’y avait pas d’organisation réelle. Il y a environ dix mille ans, avec l’apparition de groupes plus larges, est apparu le rôle du chef, garant de l’ordre. Le pouvoir s’exerce de manière brutale s’il le faut.

Continuer la lecture de « Livre : Reinventing Organizations »

Le cycle en cascade

Quand j’ai créé ce blog, j’ai écrit des articles sur différentes méthodes de gestion de projets (cycle en Vitératif, agile, …). Bizarrement, je n’ai jamais pris le temps d’en écrire un sur la méthode la plus simple, la gestion en cascade. Je pensais à l’époque que tout le monde connaissait cette manière de travailler, mais il se trouve que ce n’est pas le cas et que cela mérite qu’on s’y attarde un peu.

Principe

Le principe du cycle en cascade est assez naturel. L’organisation du travail est découpée en étapes qui se succèdent les unes aux autres.

Continuer la lecture de « Le cycle en cascade »