SolrCloud setup, quelques notions importantes pour débuter

Solr (prononcé comme le mot solar en anglais) est un moteur de recherche s’appuyant sur la bibliothèque de recherche Lucene, créée par la Fondation Apache et distribuée et conçue sous licence libre. Je vous présente dans cet article quelques notions de la version SolrCloud, annoncée fault tolerant and high availability.

Solr Standalone

Dans sa version standard standalone, on définit un solr_node « master » et n solr_nodes « slave ». A l’aide d’une configuration dans solrconfig.xml, on déclare le master, les slaves et la stratégie de réplication. C’est alors Solr qui prendra en charge lui-même la synchronisation.

Sur le master

<requestHandler name="/replication" class="solr.ReplicationHandler">
  <lst name="master">
    <str name="replicateAfter">optimize</str>
    <str name="backupAfter">optimize</str>
    <str name="confFiles">schema.xml,stopwords.txt,elevate.xml</str>
    <str name="commitReserveDuration">00:00:10</str>
  </lst>
  <int name="maxNumberOfBackups">2</int>
  <lst name="invariants">
    <str name="maxWriteMBPerSec">16</str>
  </lst>
</requestHandler>

Sur les slaves

<requestHandler name="/replication" class="solr.ReplicationHandler">
  <lst name="slave">
    <str name="masterUrl">http://remote_host:port/solr/core_name/replication</str>
    <str name="pollInterval">00:00:20</str>
    <str name="compression">internal</str>
    <str name="httpConnTimeout">5000</str>
    <str name="httpReadTimeout">10000</str>
    <str name="httpBasicAuthUser">username</str>
    <str name="httpBasicAuthPassword">password</str>
  </lst>
</requestHandler>

Plus de détails ici : https://lucene.apache.org/solr/guide/6_6/index-replication.html#IndexReplication-SettingUpaRepeaterwiththeReplicationHandler

Avantages / Inconvénients

Solution native simple à mettre en place
Les slaves se synchronisent eux-mêmes en réplicant le master.
Avec les écritures sur le master et un load-balancer sur les slaves, on obtient une haute-disponibilité en lecture tant qu’il reste au-moins un slave en fonctionnement.
En revanche, pas de haute-dispo pour l’écriture.
Si un slave down est remis en service, il sera en retard par rapport au master et aux autres slaves. Il faudra alors le mettre à jour manuellement.

SolrCloud

Avec SolrCloud, on change de stratégie pour viser la haute-dispo en lecture et en écriture. SolrCloud est disponible nativement dans une installation standard Solr. Un nouveau composant, Zookeeper, entre en jeu. Nous en parlerons plus en détails dans un autre article.

Quelques concepts à définir

cluster : c’est le groupe de serveurs (nodes) sur lequel tourne le service SolrCloud
node : un node est un serveur qui héberge le service Solr. Un groupe de nodes composent un cluster.
collection : elle représente un index logique dans son intégralité, fourni par le cluster SolrCloud
shard : c’est une subdivision de la collection
replica : c’est un index physique détenu par un node du cluster

Exemple 1 : SolrCloud avec 3 shards

1 cluster de 3 nodes
1 collection
3 shards (on découpe l’index en 3 parties)
2 replicas (= 2 cores par node)

Dans cette configuration, l’index (la collection) découpé en 3 parties (les shards) sera répliqué 1 fois (2 replicas). En conséquence, on obtient la répartition ci-dessous :

solr_node_1
- shard1_replica1
- shard3_replica2
solr_node_2
- shard2_replica2
- shard3_replica1
solr_node_3
- shard1_replica2
- shard2_replica1

Pour finir d’illustrer la mécanique de répartition de SolrCloud, si on déploie une telle configuration sur un seul solr_node, il détiendra alors les 6 replicas dans 6 cores.

Avantages / Inconvénients

Une telle configuration est haute-disponibilité en lecture et en écriture. Si on perd un solr_node, les 2 autres possèdent encore la totalité de l’index (shards 1 2 3).
Elle assure aussi une répartition de charge car chaque solr_node a la responsabilité de seulement 1/3 de l’index, en lecture (requêtes) et en écriture (indexation).
Il n’y a plus ni master ni slave. Tous les solr_nodes ont le même rôle et c’est Zookeeper qui se charge de gérer le cluster en fonction de l’état des solr_nodes (leader, active, down, recovering…).
Complexité de mise en œuvre et de compréhension
Nécessite au-moins 3 nodes

Exemple 2 : SolrCloud avec 1 shard

Avec SolrCloud, on peut mettre en place une architecture sur 2 solr_nodes, comme en mode standalone, mais avec les bénéfices de la haute-dispo en écriture.

1 cluster de 2 nodes
1 collection
1 shard (l’index n’est pas découpé)
2 replicas (= 1 core par node)

Dans cette configuration, on obtient la répartition ci-dessous :

solr_node_1
- shard1_replica1
solr_node_2
- shard1_replica2

Avantages / Inconvénients

Haute-disponibilité en lecture et en écriture. Si on perd un solr_node, l’autre possède encore la totalité de l’index.
Plus « standard » et plus facile à appréhender que la version 3 nodes / 3 shards
Il n’y a plus ni master ni slave. Tous les solr_nodes ont le même rôle et c’est Zookeeper qui se charge de gérer le cluster en fonction de l’état des solr_nodes (leader, active, down, recovering…).
On peut sécuriser d’avantage cette installation en ajoutant des nodes.
Pas de répartition de la charge (un seul leader). L’unique core leader doit gérer la totalité de l’index (requête + indexation).

Conclusion

SolrCloud offre un niveau de service supérieur à un Solr standalone master/slave. Si votre application en dépend fortement, SolrCloud est clairement à privilégier. De plus, si la version 3 nodes / 3 shards vous paraît complexe à mettre en œuvre, vous pouvez vous reposer sur la version avec 1 seul shard, plus simple. Vous pouvez tester SolrCloud facilement avec les images Docker officielles : https://github.com/docker-solr. Je vous parlerai de Zookeeper dans un futur article.

Sources

https://github.com/docker-solr
https://stackoverflow.com/a/31773632/243996
https://lucene.apache.org/solr/guide/8_8/
https://lucene.apache.org/solr/guide/8_8/solrcloud.html

Scrum guide 2020 : mon décryptage des changements

L’année 2020 aura été une année très spéciale à de nombreux titres. Ken Schwaber et Jeff Sutherland nous gratifient d’une nouvelle version du Scrum Guide. Décryptage des changements.

Encore moins normatif

Au fil du temps, le Guide Scrum a commencé à devenir un peu plus normatif. La version 2020 visait à ramener Scrum à un cadre minimalement suffisant en supprimant ou en adoucissant le langage prescriptif. Par exemple, la suppression des questions Daily Scrum, l’adoucissement du langage autour des attributs PBI (Product Backlog Items – les éléments du Backlog Produit), l’adoucissement du langage autour des éléments rétro dans un Sprint Backlog, le raccourcissement de la section d’annulation de Sprint, etc.
© 2020 Ken Schwaber and Jeff Sutherland, traduction française par Kamel Kaouech

Le Scrum guide 2020 réajuste le tir. Scrum est bien un cadre de fonctionnement et pas une méthodologie. A l’intérieure de ce cadre, les pratiques sont libres. La suppression des trois questions du Daily Scrum en est un bon exemple. Peu importe comment l’équipe le mène, c’est son objectif et sa timebox qui comptent : inspecter et adapter le plan en vue de l’objectif du sprint.

Une seule équipe, focalisée sur un seul produit

L’objectif était d’éliminer le concept d’une équipe distincte au sein d’une équipe qui a conduit à un comportement « proxy » ou « nous et eux » entre le PO et l’équipe de développement. Il n’y a maintenant qu’une seule équipe Scrum concentrée sur le même objectif, avec trois différents ensembles de responsabilités : PO, SM et développeurs.
© 2020 Ken Schwaber and Jeff Sutherland, traduction française par Kamel Kaouech

Là-aussi, on revient à l’essence même de Scrum. C’est carrément littéral. « Scrum » en anglais, c’est la mêlée. Un pack qui pousse comme un seul groupe. Donc tout le monde, PO, Scrum master et développeurs sont désormais dans une seule et même équipe.

Introduction de l’Objectif de Produit

Le Guide Scrum 2020 introduit le concept de l’Objectif de Produit pour permettre à la Scrum Team de se focaliser sur un objectif plus important. Chaque Sprint devrait rapprocher le produit de son objectif global.
© 2020 Ken Schwaber and Jeff Sutherland, traduction française par Kamel Kaouech

Ça aussi c’est bien vu. En plus, c’est très facile à mettre en place. Chaque sprint est un sous-ensemble de travail visant à atteindre un objectif plus grand. Définir l’objectif du produit va renforcer et partager la vision produit qui manque parfois cruellement, surtout pour les développeurs.

Un sens pour l’Objectif de Sprint, la Definition of Done et l’Objectif de Produit

Les précédents guides Scrum décrivaient l’Objectif de Sprint et la Definition of Done sans vraiment les donner une identité. Ils n’étaient pas tout à fait des artefacts, mais étaient quelque peu attachés à des artefacts. Avec l’ajout du concept de l’Objectif de Produit, la version 2020 apporte plus de clarté à ce sujet. Chacun des trois artefacts contient désormais des «engagements» à leur égard. Pour le Product Backlog, il s’agit de l’Objectif de Produit, le Sprint Backlog a un Objectif de Sprint et l’Increment a une Definition of Done (maintenant sans les guillemets). Ils existent pour apporter de la transparence et se focaliser sur la progression de chaque artefact.
© 2020 Ken Schwaber and Jeff Sutherland, traduction française par Kamel Kaouech

C’est la suite logique du point précédent sur l’introduction de l’objectif de produit. Le Scrum guide 2020 réaffecte ces 3 notions (objectif de produit, objectif de sprint et definition of done) a trois artefacts de Scrum :

product backlog => objectif de produit
sprint backlog => objectif de sprint
incrément => definition of done

Personnellement, j’aime bien l’idée d’une definition of done associée directement à l’incrément plutôt qu’à chaque user story. Claude Aubry en parlait déjà dans son livre « Scrum » dès la 4è édition en 2015. Je trouve qu’une definition of done trop contraignante sur les stories allonge les temps de développement et j’ai souvent du mal à la faire respecter par les équipes. Alors qu’une definition of done sur l’incrément peut être inspectée en sprint review et permettra de déterminer les dernières actions à mener pour éventuellement sortir une release.

Auto-gérée plutôt qu’auto‐organisée

Les guides Scrum précédents appelaient les équipes de développement auto‐organisées, choisissant qui et comment travailler. En se focalisant d’avantage sur la Scrum Team, la version 2020 met l’accent sur une Scrum Team autogérée, en choisissant qui, comment et sur quoi travailler.
© 2020 Ken Schwaber and Jeff Sutherland, traduction française par Kamel Kaouech

Auparavant, la Dev team s’auto-organisait pour définir qui allait réaliser le travail et comment il serait réalisé. Et c’était plutôt la Scrum team, sous l’impulsion du PO, qui définissait sur quoi la dev team allait travailler. Désormais, la seule et unique Scrum team décide quoi, qui et comment.

Simplification globale de la langue pour un public plus large

Le Guide Scrum 2020 a mis l’accent sur l’élimination des déclarations redondantes et complexes ainsi que la suppression de toute déduction éventuelle au travail informatique (par exemple, les tests, le système, la conception, les exigences, etc.). Le Guide Scrum compte désormais moins de 13 pages.
© 2020 Ken Schwaber and Jeff Sutherland, traduction française par Kamel Kaouech

Encore une bonne chose. Scrum est très largement utilisé dans le monde informatique mais il n’a pas été créé en ce sens. On peut appliquer Scrum à n’importe quel secteur d’activité. Il était donc important de nettoyer le Scrum Guide de toutes notions connotées « informatique ».

Rôle du Scrum master

J’ai lu et entendu quelques analyses qui disaient que le Scrum Guide 2020 modifie le rôle du Scrum Master. Je ne suis pas tout à fait d’accord. La traduction française ne l’évoque pas d’ailleurs (liste des changements 2018-2020 en page 15 de la version française).

2017

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

2020

The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.

C’est le terme « accountable » (responsable qui rend des comptes) qui semble faire peur à certains. Personnellement, en tant que Scrum Master, je me suis toujours senti investi de cette responsabilité. Aujourd’hui, le Scrum guide 2020 a peut-être introduit ce changement pour rendre cette responsabilité visible et explicite. Et je pense que c’est une bonne chose pour la pénétration de Scrum dans certaines organisations où l’on craint la dilution des responsabilités.

Sources et références

https://www.scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf
https://www.scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-French.pdf
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf

Scrum et le « lâcher prise »

Lorsqu’on devient Scrum master et qu’on a, comme moi, un background technique de chef de projet classique, il est nécessaire de changer de « mindset » pour devenir réellement agile.

Le chef de projet : une contrainte dans le système

La gestion de projet classique positionne une personne en tête de file : le chef de projet.

Cette personne est l’unique point d’entrée pour les parties prenantes (les managers, les clients, l’équipe de développement). Il sait tout, il voit tout, il a réponse à tout, il peut tout, il doit tout (vous pouvez compléter la liste…). Il paraît alors assez évident que ce rôle pose problème :

qu’est-ce qui se passe si cette personne quitte l’organisation ? (départ, maladie, accident, mutation…)
qu’est-ce qui se passe pour le produit si cette personne est (ou devient) insuffisamment performante (fonctionnellement, techniquement, manque de dispo…) ?
qu’est-ce qui se passe si les relations avec les parties prenantes se dégradent ?

Là-aussi, on peut facilement compléter la liste.

Il est donc dangereux pour un projet ou un produit d’être confié à une seule personne. Les managers qui gèrent le staffing des équipes doivent veiller à ce que ça n’arrive pas. C’est de leur responsabilité.

Mon expérience personnelle m’a aussi fait entrevoir un autre problème avec le chef de projet. Il est un goulot d’étranglement qui ralentit les travaux et limite les solutions. Une demande métier ne doit pas être bloquée chez le chef de projet. Elle doit arriver directement à l’équipe qui connaît bien le produit, qui a les compétences techniques et la richesse créative pour imaginer une solution pertinente. Pour que ce soit efficace, l’équipe doit évoluer dans un cadre propice à la prise en charge rapide des demandes et à l’émergence de solutions concertées.

Scrum et Kanban offrent un tel cadre.

Confier les clés à l’équipe

Lâcher prise, c’est donner les clés à l’équipe Scrum.

Ses membres doivent « faire ». Ils doivent se confronter aux problématiques afin qu’il en résulte une émulation, une intelligence collective et un enrichissement des solutions proposées.

Scrum est un cadre prévu pour traiter des problématiques complexes. Les membres de l’équipe de développement sont des techniciens compétents, motivés et pluridisciplinaires qui vont embrasser cette complexité pour enrichir le produit. Si une personne fait des choix en amont pour réduire cette complexité, il court-circuite en quelque-sorte les bénéfices de Scrum. Pour éviter cet écueil, il suffit de respecter Scrum ! C’est le Product Owner qui transmet directement ses demandes à l’équipe sans intermédiaire à travers le backlog.

Le manque de confiance

Le principal frein à la mise en place de Scrum et à son succès est le manque de confiance.

On lâche prise lorsqu’on accepte le niveau de productivité et de qualité actuel de son équipe. Il est inutile de décréter unilatéralement un haut niveau de performances. L’équipe doit faire son cheminement pour progresser. L’amélioration doit être continue et recherchée en permanence. L’exigence de transparence prônée par Scrum permet cette inspection. Au final, avec la pratique et la répétition, l’équipe va améliorer ses capacités au fil du temps.

C’est aussi ce manque de confiance qui amène les managers à migrer leurs organisations vers du faux Scrum. Le symptôme le plus courant étant la conservation du rôle de chef de projet, souvent renommé et déguisé en Scrum Master.

Lâcher prise, c’est donc faire confiance !

Scrum : de l’usure des rituels

Le cadre Scrum est jalonné de rituels indispensables au bon fonctionnement d’une équipe. Le Scrum Master est responsable de leur bonne tenue mais aussi de leur efficacité. D’expérience, on remarque que lorsque l’équipe itère depuis plusieurs mois, l’efficacité des rituels diminue.

Le daily meeting

Quotidien, il est le plus fréquent des rituels Scrum. Il est aussi le plus normé car il doit être rapide (max 15min) et toujours se dérouler à la même heure et au même endroit pour réduire la complexité et faciliter sa tenue. Son importance est capitale et son efficacité doit être réelle.

Le Scrum master doit donc veiller à ce qu’il conserve son utilité en évitant les mauvaises habitudes des participants :

ponctualité
Le matin c’est bien ! C’est le top départ de la journée Scrum. Les participants doivent impérativement être à l’heure. Le Scrum master doit rappeler à l’ordre les retardataires.
écoute
Ce doit être un vrai moment d’échange. Il doit y avoir un dialogue réel entre les membres de l’équipe. J’ai remarqué que la proximité physique (attention Covid-19…) joue énormément sur les discussions. En obligeant les participants à se rapprocher physiquement, à resserrer le cercle, on améliore le dialogue.
implication et transparence
L’équipe doit faire preuve de transparence afin que l’inspection réalisée soit efficace. Pour cela, les participants ne doivent rien dissimuler. Le management visuel est d’une redoutable efficacité car il montre à tout le monde et à un seul et unique endroit l’état d’avancement des tâches de chacun. Le bâton de parole marche aussi plutôt bien pour impliquer chaque participant et leur attribuer un créneau de parole.
On doit aussi demander à chaque participant d’intervenir lui-même sur le management visuel pour déplacer ses tâches ou s’en attribuer une nouvelle. Cela l’impliquera d’avantage.
timebox
15 minutes max ! La timebox oblige les participants à aller à l’essentiel et surtout à envisager un autre cadre (réunion, discussion, pair-programming…) pour la résolution de leurs problèmes.

J’adapte aussi parfois sa fréquence. Ce n’est pas tout à fait conforme à la théorie Scrum et cela réduit les opportunités d’inspection et d’adaptation. Mais, lorsque les stories sont encore un peu grosses et que l’avancement du travail n’est pas significatif d’un jour à l’autre, la réduction de la fréquence permet d’éviter les meetings « creux ». C’est nécessaire lorsque les participants disent : « pour moi, comme hier… ».

L’erreur la plus courante du Scrum master est de prendre le lead pendant les daily meetings. Cela empêche les participants de s’impliquer et d’échanger. Il faut rester en retrait et laisser l’équipe mener le meeting. Ce n’est pas une séance de rapport au Scrum Master ou au Product Owner (perso, je trouve bien qu’il soit présent), c’est un rituel qui doit permettre à l’équipe d’inspecter son avancement et d’adapter son plan vers l’objectif du sprint.

Sprint-review et sprint-planning

Ces deux rituels sont très normés. On inspecte le résultat du sprint, on fait une démo de ce qui est terminé et on envisage la suite pour le prochain sprint.

En review, pour éviter la routine, il faut faire tourner les personnes qui réalisent la démo. Cela permet d’impliquer tout le monde.

Pendant le sprint-planning, le Product Owner doit expliquer à l’équipe les stories qu’il a retenues pour le nouveau sprint. Là encore, le Scrum Master doit laisser le lead pour obtenir une implication de l’équipe. J’aime bien aussi donner la parole, sur chaque story, au membre de l’équipe qui connaît le périmètre technique impliqué. C’est une sorte d’essaimage (cf. « Scrum, Claude Aubry, Editions Dunod ») qui permet l’engagement de chacun.

Le sprint-planning est fastidieux et le plus long des rituels Scrum. Il est exigeant mentalement, demande beaucoup de concentration et de réflexion. Je crois que le plus important pendant ce rituel est de faire des pauses. Son importance est capitale pour la réussite du futur sprint, tout le monde doit donc être totalement concentré.

La rétrospective

C’est certainement le rituel qui nécessite le plus de variété. Il est nécessaire de changer fréquemment le support et la formule pour obtenir des retours francs et transparents des membres de l’équipe. Sans cette transparence, l’inspection ne sera pas bonne.
On doit chercher à libérer la parole. Sans langue de bois, les membres de l’équipe doivent se dire les choses. Le Scrum Master veillera à ce que les conditions soient réunies pour que cela se fasse dans une atmosphère bienveillante. Le bon point de départ est de se dire que tout le monde a fait de son mieux pendant le sprint écoulé.

D’expérience, j’ai l’habitude de faire en sorte que les retours ne soient jamais nominatifs afin que personne ne soit ciblé. Ma règle : on ne cite aucun nom en rétro !

Pas mal de gens ont expérimenté de nombreuses formules de rétrospective. Une sélection ici https://pablopernot.fr/2015/03/festival-de-retrospectives/ .

Si on veut creuser un peu plus du côté émotionnel, je vous conseille la rétro Dixit : https://blog.myagilepartner.fr/index.php/2019/11/08/retrospective-dixit/ . Elle favorise l’empathie et oriente les retours sur un support annexe au projet et au travail quotidien (les illustrations Dixit).