Steve Smith - You Build It You Run It sounds great but it won’t work here (EN)

[00:00:06] Bonjour à tous. Arrêtez. Arrêtez. Non. Non, on n'applaudit pas ça. Non.
[00:00:13] La technologie a mal tourné. On n'applaudit pas quand la technologie tourne mal. On soupire et on dit, beurk. Puis-je avoir un haussement d'épaules gaulois de la part de tous les Français dans le public ? Un vrai comme ça Ah, pas mal de monde. Merci. Quelqu'un d'autre est britannique ici ? Un. Mmm. Je soupçonne que vous êtes probablement belge, pas britannique. Personne n'est assez stupide pour venir en Europe depuis la Grande-Bretagne. Euh, donc oui, bonjour à tous, bonjour. Euh, merci à Sébastien, Yannick et à toute l'équipe de Flowcon de m'avoir invité ici. Mon nom est Steve Smith. Euh, mettons quelques choses de côté. Euh, oui, c'est vrai. Je suis un roast beef. Je suis désolé pour le Brexit. Euh, nous sommes devenus fous. Euh, j'aimerais, euh, que la seule personne britannique dans le public suive l'actualité en direct et fasse un signe si notre Premier ministre change encore dans l'heure qui vient. Il y a quelques jours, j'ai une fille de 10 ans qui m'a dit : qui sera, selon toi, notre prochain Premier ministre la semaine prochaine ? Et j'ai dit : 'Oh, quand j'étais enfant, nous ne posions pas cette question', mais maintenant c'est une très, euh, euh, euh, bonne idée. Très bien, j'espère donc une réception vraiment positive. Ici en France, le genre d'accueil positif que chaque Britannique reçoit lorsqu'il traverse la Manche. Euh, mon sens de l'humour est très britannique, très sec. Il est possible que je ne pense rien de ce que je dis aujourd'hui. Alors je vais parler de, euh, vous le construisez, vous le gérez. Ça a l'air génial. Mais ça ne marchera pas ici. Parce que nous sommes spéciaux, Steve. Notre entreprise est différente, Steve. Nous avons toutes sortes de problèmes, Steve, que nous ne voulons pas essayer de résoudre car ils seraient difficiles à résoudre. D'accord, donc. Je suis le responsable du service Scale chez Equal Experts. Euh, nous sommes un réseau mondial de consultants experts en technologie. Nous avons un bureau en Europe. Donc si vous êtes un entrepreneur indépendant, euh, nous avons en fait un modèle similaire à Showdo, je veux parler à ces gars-là. Euh, mais si vous êtes un entrepreneur indépendant à la recherche de quelque chose de nouveau, venez me parler après. En tant que responsable de l'échelle, je passe mes journées à parler à nos clients et à nos consultants de notre réseau de ce que signifie réussir à l'échelle. Et c'est très similaire au manifeste de Flowcon, qui parle d'équipes autonomes, de flux, de projets de services produits, tout ça. Euh, voici quelques-unes de mes expériences de travail à l'échelle. Euh, si j'en choisis un, voyons voir. Euh, le troisième, passant d'une équipe à un microservice à 40 équipes, 120 microservices en deux ans et demi. Euh, ce fut deux ans et demi très excitants. C'était avant la pandémie, alors chaque fois que les choses devenaient vraiment stressantes, j'allais me cacher dans les toilettes du bureau pendant une heure et je, vous savez, c'était comme une pièce calme, je suppose. Un peu comme cette conférence a une salle de repos. Bien sûr, de nos jours, euh, je n'ai pas de pièce calme à la maison parce que je travaille à domicile tous les jours. Si ma femme me trouve dans la salle de bain, elle lève les yeux au ciel et me dit : 'Pourquoi es-tu encore là-dedans ?'
[00:03:11] Euh, je suis sur Twitter sous le nom de Steve Smith Tech et sur LinkedIn, c'est pareil. Euh, je ne veux pas parler de mes pseudonymes, il s'avère qu'il y a beaucoup de Steve Smith et ils ne veulent pas les céder. Euh, j'ai aussi écrit quelques livres que vous avez peut-être lus sur Leanpub, Mesurer la livraison continue et Construire la qualité. Euh, s'il vous plaît, achetez-les, mes enfants ont besoin de chaussures et l'économie britannique est ruinée.
[00:03:34] Donc. Euh, pourquoi sommes-nous ici ? Nous sommes ici pour atteindre une nouvelle référence de succès. Euh, le monde devient plus rapide et plus désordonné chaque jour.
[00:03:47] Euh, nous devons fournir des résultats clients plus rapidement que jamais. Et la façon d'y parvenir est d'atteindre trois choses à la fois. Vous devez embaucher un débit plus élevé, une plus grande fiabilité et une culture d'apprentissage. Par un débit plus élevé, j'entends des déploiements hebdomadaires, peut-être quotidiens. Par une plus grande fiabilité, j'entends atteindre systématiquement deux neuf de disponibilité et un temps de réparation en minutes, pas en heures. Et par culture d'apprentissage, j'entends la création d'un environnement dans lequel les gens peuvent générer des idées, mettre en œuvre des actions post-incident et partager des connaissances au sein de votre organisation. Ne pas se contenter de garder ces connaissances piégées au sein d'une équipe particulière.
[00:04:32] Et il y a un problème ici, n'est-ce pas ? Vous tous, vous utilisez tous une équipe d'opérations centrale pour gérer vos systèmes fondamentaux et vos services numériques. Combien de personnes ici appliquent le principe 'vous le construisez, vous le gérez' aujourd'hui, où une équipe de livraison est réellement d'astreinte pour ce qu'elle construit ? Baissez la main, vous mentez. Il y a une personne de Spotify ici, il dit peut-être la vérité, mais la dernière fois que j'ai parlé à Spotify, ils avaient jusqu'à 700 équipes et personne ne sait vraiment ce que chacun fait là-bas. Tout le monde tourne en rond, puis ils se retrouvent tous dans la forêt en Suède et racontent à quel point leur entreprise est géniale. Euh, c'est bon, je ne veux pas travailler pour Spotify, ils n'allaient pas appeler de toute façon. Alors. L'appel ne vient jamais, les années passent.
[00:05:15] Donc, euh, par système fondamental, j'entends une application COTS auto-hébergée, achetée sur étagère, que vous gérez vous-même sur site ou dans le cloud, peut-être quelques intégrations personnalisées que vous avez développées pour assembler les choses. Et une équipe d'opérations est tout à fait bien
[00:05:35] pour s'occuper d'un système fondamental parce que vous avez besoin d'un niveau élevé de fiabilité, mais il n'a pas besoin d'être déployé si souvent, il ne change pas si souvent, il n'y a pas beaucoup de demande du marché pour qu'il change très souvent. Mais ce modèle ne fonctionne pas pour les services numériques. Pour atteindre un débit plus élevé, une plus grande fiabilité et une culture d'apprentissage, tout en même temps sur le long terme, une équipe d'exploitation ne peut pas le faire. Et non parce qu'ils sont mauvais, non parce qu'ils sont incompétents. Je suis prêt à parier que votre équipe d'opérations est hautement qualifiée et un groupe de personnes adorables, mais ils travaillent dans un mauvais système. Et c'est ce qu'est Flowcon et les autres conférences, nous aider à trouver des moyens de surmonter ce mauvais système.
[00:06:16] D'accord, donc. Nous devons adopter le principe « vous le construisez, vous le gérez ». C'est un modèle opérationnel dans lequel les équipes produit construisent, déploient, opèrent et supportent leurs propres services. Du moins, c'est comme ça que ma collègue Beth et Timmons et moi le décrivons.
[00:06:33] Il a une histoire intéressante, vous en êtes peut-être conscient. Euh, en 2006, le CTO d'Amazon a inventé le terme lors d'une interview pour l'ACMQ. Il n'avait pas l'intention de l'appeler 'vous le construisez, vous le gérez'. Euh, c'était juste la façon dont les équipes d'Amazon décrivaient ce qu'elles faisaient à ce moment-là. Et vous savez, c'était il y a longtemps maintenant, en 2006. Il y a environ 10 Premiers ministres au Royaume-Uni, je crois. Tout est un peu flou. Euh, je ne connais pas le nombre exact, j'ai inventé 10, ça semble à peu près juste.
[00:07:02] Au début des années 2010, nous avions le culte du cargo DevOps, n'est-ce pas ? Tout le monde disait : 'Vous devez avoir une équipe DevOps.' Vous devez avoir une équipe DevOps. Je suis dans une équipe DevOps. Bien sûr, personne ne savait ce que DevOps signifiait et c'était une perte de temps complète d'essayer de comprendre ce que le mot DevOps signifiait. Mais j'aime à penser que ce dont les gens parlaient, c'était qu'il fallait avoir des équipes produit autonomes, capables de construire, déployer, opérer et supporter leurs propres services numériques. Et bien sûr, à la fin des années 2010, nous avons eu le culte du cargo SRE, n'est-ce pas ? Vous devez avoir une équipe SRE. Vous devez avoir une équipe SRE. J'ai travaillé chez Google. Eh bien, vous n'avez pas besoin de SRE et chaque fois que quelqu'un dit : 'J'ai travaillé chez Google', il n'a probablement pas travaillé chez Google ou il a juste, je ne sais pas, sorti les poubelles ou quelque chose comme ça là-bas. Euh, j'aime à penser que quand les gens parlaient de SRE, ce qu'ils voulaient vraiment dire, c'est que vous avez besoin d'équipes produit qui construisent, déploient, opèrent et supportent leurs propres services numériques à l'échelle. Et peut-être que si vous aviez vraiment des besoins de fiabilité extrêmes, vous pourriez avoir une équipe pour le faire pour vous parce qu'ils en sont spécialistes.
[00:08:10] D'accord, donc. Euh, ma collègue Beth et moi avons écrit un livre sur, euh, « vous le construisez, vous le gérez ». Il est disponible sur le site Equal Experts.com à cette URL vraiment étrange. Euh, si vous venez me parler après, je serai heureux de le partager avec vous. Euh, je mettrai également le lien sur Twitter et sur LinkedIn. Nous essayons d'offrir une véritable plongée en profondeur dans tous les principes et pratiques qui le sous-tendent et de partager certaines des expériences que les gens d'Equal Experts ont eues en l'adoptant partout dans le monde. Je veux dire,
[00:08:42] C'est un nom imparfait pour quelque chose de vraiment important, nous avons cherché d'autres noms pour cela, mais c'est le nom autour duquel la plupart des gens semblent se rallier. Je ne peux pas penser à un meilleur nom, donc je pense que nous sommes tous bloqués avec celui-ci.
[00:08:55] Euh, il y a quelques années, un collègue m'a dit, vous êtes-vous rendu compte que 'vous le construisez, vous le gérez' allait être l'une des batailles pour lesquelles vous vous battriez jusqu'au bout, Steve ? Et pour ceux qui me connaissent ici aujourd'hui, ils sauront que j'ai énormément de collines. Euh, mais « vous le construisez, vous le gérez » est sans aucun doute l'une de mes principales préoccupations. Je pense que c'est une chose super importante à adopter, je ne pense pas que vous puissiez réussir à l'échelle sans cela.
[00:09:18] C'est probablement l'une de mes trois principales difficultés, au même titre que de nommer vos équipes d'après les choses qu'elles construisent. J'ai récemment visité une entreprise où une équipe construisait une plateforme de données. Et ils ont dit : « Nous pensons nous appeler l'équipe de la plateforme de données ». Et j'étais comme, 'Oui.' C'est ce que vous devriez faire. Ne vous nommez pas d'après un dieu grec, un groupe de musique pop ou un fromage. Et oui, j'ai travaillé une fois dans une entreprise où nous avons nommé nos équipes d'après du fromage, vous regardez l'ancien chef d'équipe de l'équipe Mascarpone. Euh, le nom de l'équipe n'était plus de mon ressort, mais l'équipe de la plateforme de données allait s'appeler l'équipe de la plateforme de données. Je suis retourné le lendemain et ils ont dit : 'Bonne nouvelle, Steve.' Nous nous sommes appelés les Backstreet Boys. Donc, c'était euh, assez décevant. D'accord. Comment savoir quand adopter le principe 'vous le construisez, vous le gérez' ? Et aussi, de manière cruciale, comment savoir quand ne pas le faire ?
[00:10:13] Dans notre playbook, Beth et moi avons conçu un
[00:10:18] sélecteur de modèle opérationnel pour essayer d'aider les chefs de produit à décider quel est le bon modèle opérationnel pour ce qu'ils construisent. Alors, allons-y doucement car il est tôt et je n'ai pas encore bu. Donc sur l'axe des Y, nous avons l'exposition financière à l'échec. C'est la somme d'argent que vous pouvez perdre sur une période de temps si les choses tournent mal. Et c'est, euh, nous avons des niveaux relatifs de cela, faible, moyen, élevé, très élevé. Et ils correspondent à des objectifs de disponibilité de 1,5 neuf jusqu'à 4 neuf. Et, euh, un temps de restauration de 9 heures à 1 minute. Euh, par semaine, devrais-je dire. Et sur notre axe X, nous avons la demande de fonctionnalités produit. C'est la fréquence à laquelle vous devez présenter de nouvelles fonctionnalités à vos clients pour satisfaire la demande du marché. Et encore une fois, nous avons des niveaux relatifs, bas, moyen, élevé, très élevé. Et cela correspond aux déploiements mensuels, hebdomadaires, euh, qu'est-ce que c'était ? Mensuel, bimensuel, hebdomadaire et quotidien. Et le jaune, c'est quand vous avez une équipe d'opérations centrale. Et le bleu, c'est quand vous appliquez le principe : « vous le construisez, vous le gérez ».
[00:11:32] Ce que nous disons ici, ce sont trois choses différentes. Premièrement, si vous avez réellement un besoin réel de quatre neuf de disponibilité, comme une fiabilité vraiment extrême, euh, alors utilisez « vous le construisez, vous le gérez », que ce soit un système fondamental ou un service numérique. S'il s'agit d'un service numérique, si vous devez atteindre cette nouvelle référence de débit élevé, de fiabilité élevée et de culture d'apprentissage, vous le construisez, vous le gérez, c'est pourquoi vous poussez vers le côté droit de ce modèle. Si vous avez juste besoin d'un niveau élevé de fiabilité, alors gardez votre système fondamental avec votre équipe d'exploitation. Une chose que nous essayons vraiment de faire comprendre à propos de 'vous le construisez, vous le gérez', c'est que cela ne signifie pas se débarrasser de votre équipe d'opérations. De la même manière que la livraison continue ne consiste pas à se débarrasser de votre équipe de gestion des changements. Le principe « vous le construisez, vous le gérez » consiste à libérer votre équipe d'opérations pour qu'elle fasse ce qu'elle fait de mieux, qui est de surveiller et de prendre soin de vos systèmes fondamentaux, de réduire la charge cognitive sur eux et de réduire leur travail en cours. Et non pas simplement leur jeter des tas de choses par-dessus un mur de confusion.
[00:12:37] D'accord. À quoi ressemble le principe « vous le construisez, vous le gérez » pour le débit de déploiement ? Ici, nous avons les services numériques en haut et les systèmes fondamentaux en bas. Nous avons au-dessus une équipe produit qui construit, teste, déploie, lance et rapporte sur son propre service numérique. Et par reporting, j'entends un mécanisme automatisé pour notifier votre équipe de gestion des changements qu'un déploiement a eu lieu. Un pipeline de déploiement est une excellente piste d'audit automatisée. Vous faites probablement quelque chose comme ça.
[00:13:14] Et avec cette configuration, vous êtes capable d'obtenir des approbations de changements rapides, des déploiements rapides, un accent sur les résultats plutôt que sur les produits. Et vous avez des coûts de synchronisation des connaissances très faibles, vous n'avez rien à transférer entre les équipes, vous transférez juste entre les individus de votre équipe. Au pire.
[00:13:32] Avec vos systèmes fondamentaux, vous avez toujours votre équipe d'opérations, votre équipe de livraison exactement comme avant. Votre équipe de livraison construira ou configurera, puis testera vos COTS, vos intégrations personnalisées. Ils transmettront ensuite le mur de la confusion à l'équipe de gestion du changement. Et ils seront confus et puis quand ils ne seront plus confus, ils transmettront un autre mur de confusion à l'équipe de support applicatif, qui sera également confuse, puis ils le déploieront. Et pour les systèmes fondamentaux, c'est tout à fait bien.
[00:14:05] D'accord. Alors, à quoi ressemble le principe « vous le construisez, vous le gérez » pour la réponse aux incidents ?
[00:14:11] Encore une fois, nous avons une équipe produit au sommet.
[00:14:15] surveillant et supportant leurs propres services numériques, ils sont en astreinte de niveau 1, ce qui signifie qu'ils sont constamment d'astreinte pour leur propre service, pendant et en dehors des heures de travail. Il n'y a pas d'équipe d'opérations d'astreinte.
[00:14:27] Et en dessous, il y a une équipe d'opérations appelée pour les systèmes fondamentaux. Si vous faites le maximum d'ITIL, ce qui est très bien pour vous, vous savez, c'est votre choix. Euh, vous aurez une équipe de pont d'opérations qui effectuera la surveillance. Et ensuite, ils transféreront tous les problèmes via un autre mur de confusion à une équipe de support applicatif qui assure une astreinte de niveau 2. Alternativement, vous pourriez fusionner ces deux équipes en une seule, vous savez, je ne peux pas vous empêcher de le faire si vous le souhaitez, allez-y. Et bien sûr, lorsque l'équipe des opérations tente de restaurer le service avec un système fondamental, si cela devient vraiment difficile, vraiment compliqué, elle fera appel à une équipe de livraison pour le faire en dehors des heures de bureau. Cela devient vraiment compliqué et il faut essayer de trouver un développeur qui réponde au téléphone. Et pour qu'un développeur aide dans cette situation, on parle de meilleurs efforts ou de meilleurs tentatives, ou comme je préfère l'appeler, du travail non rémunéré. Et entre-temps, on pourrait croire qu'en France, ça ferait rire, on vient d'avoir quelqu'un qui parlait de solidarité avec les travailleurs. Mais non, je parle de travail non rémunéré et tout le monde dit : 'Oui.' Le travail non rémunéré est bien en France. D'accord, donc, euh, les gens m'ont menti sur la France, clairement. Entre l'équipe produit qui applique le principe « vous le construisez, vous le gérez » et l'équipe d'opérations qui s'occupe de vos systèmes fondamentaux, vous avez un tas de ce que j'aime appeler des facilitateurs opérationnels. Ce sont vos administrateurs réseau, vos DBA, votre gestion des incidents. Vos équipes produit les utilisent, s'appuient sur elles, en dépendent de la même manière que les autres équipes d'exploitation. J'aime beaucoup ces équipes, elles ne bougeront pas.
[00:16:01] D'accord.
[00:16:04] Alors, j'ai parlé avec un tas d'entreprises du monde entier à propos de « vous le construisez, vous le gérez ». Et j'aimerais partager avec vous certaines, pas toutes, mais certaines des objections que les gens me donnent. Et ce qui est vraiment étonnant, c'est que les gens me donnent ces objections juste après m'avoir dit à quel point la chose est incroyable. Ce qu'ils vont faire, c'est dire : 'Steve, nous aimons le principe de construire et gérer.'
[00:16:29] Et j'ai appris au fil des ans que chaque fois que quelqu'un me dit : 'Je t'apprécie, Steve, en principe', ce qu'il est sur le point de dire, c'est à quel point il me déteste et tout ce que je représente. Alors, « vous le construisez, vous le gérez », ça a l'air génial. Mais ça ne marchera pas ici. Parce que les développeurs ne voudront pas le faire. Quelqu'un a déjà entendu ça, 'Les développeurs ne voudront pas faire d'astreinte' ? Bien sûr que vous avez entendu ça. Ça ne va pas scaler. Quelqu'un a entendu ça ? « Vous le construisez, vous le gérez, ça ne scalera pas, Steve ». Tout doit être mis à l'échelle maintenant. Vous êtes le chef de l'échelle. Tout doit être mis à l'échelle. Le principe « vous le construisez, vous le gérez » ne fonctionnera pas car personne ne serait responsable. Quelqu'un a entendu celle-là ? Oui, tout le monde a entendu ça, 'Il nous faut quelqu'un de responsable.' Euh, mince, je m'énerve. Euh, tôt dans la discussion aussi pour s'énerver. Il n'y aurait pas de gestion des incidents. Quelqu'un a déjà entendu ça : « Vous ne pouvez pas avoir le principe ‘vous le construisez, vous le gérez’ car qui ferait la gestion des incidents ? »
[00:17:25] Euh, les développeurs seront des pompiers. Quelqu'un a déjà entendu ça : « Vous ne pouvez pas avoir 'vous le construisez, vous le gérez', oui, oui ». Cela se passe très bien maintenant. Ils éteindraient des incendies, au lieu de produire des fonctionnalités dans une sorte d'usine à fonctionnalités sans esprit. Et mon préféré que j'adore toujours entendre : « On ne peut pas faire 'vous le construisez, vous le gérez', Steve ». Parce que nous ne pouvons pas embaucher un DBA pour chaque équipe. Quelqu'un a déjà entendu ça ? Oui. Personne ne vous a demandé d'embaucher un DBA pour chaque équipe, et pourtant vous essayez de le faire. Genre, s'il vous plaît, arrêtez.
[00:17:54] D'accord.
[00:17:57] Le premier de six, vous le construisez, vous le gérez, ça a l'air génial, mais seulement en principe, Steve. Parce que les développeurs ne voudront pas le faire. Maintenant. À quoi ça ressemble ?
[00:18:11] Ça ressemble à, les développeurs sont des divas, Steve. Ils veulent juste coder. Ils sont payés pour coder uniquement. Ils doivent être laissés dans leur placard, à coder. Je ne leur ai jamais parlé. Je ne connais pas leurs noms. Mais ils ne voudront pas le faire. Chaque fois que j'entends cela d'un chef de développement ou d'un chef des opérations ou d'un chef des TI, ce que ça me semble, c'est que, vous n'avez pas donné à vos développeurs ce dont ils ont besoin pour réussir. Avez-vous réellement expliqué à vos développeurs qu'il y a une urgence autour de cela, que c'est une question de survie si vous n'atteignez pas ce nouveau niveau de référence pour le succès, vous allez perdre face à vos concurrents sur le marché ?
[00:18:59] Avez-vous demandé à vos développeurs ce qui ne va pas avec l'astreinte et écouté ce qu'ils disent ? Et je ne veux pas dire entendre de la même manière que mes enfants m'entendent quand je dis : « Arrêtez de manger le chocolat dans la cuisine », et qu'ensuite ils recommencent. Je veux dire, entendre ce qu'ils disent, clarifier votre compréhension jusqu'à ce que vous appréciiez vraiment profondément leurs préoccupations. Et je suis assez confiant, je sais quelle est la principale préoccupation, nous y reviendrons dans un instant et ce n'est pas l'argent. D'accord.
[00:19:33] Et vous êtes-vous engagé à corriger les choses ? Il y aura des changements organisationnels vraiment délicats à résoudre si vous voulez adopter le principe 'vous le construisez, vous le gérez', et il est important d'y consacrer un effort maximal et une transparence maximale.
[00:19:46] J'aime beaucoup que Sébastien partage les dépenses de la conférence, comme la lumière du soleil est vraiment le meilleur désinfectant, d'accord, cela encourage toutes sortes de bons comportements lorsque vous faites preuve d'une transparence maximale.
[00:19:57] D'accord. arrêter de manger le chocolat dans la cuisine et ensuite ils vont encore le faire. Je veux dire, écouter ce qu'ils disent, clarifier votre compréhension de la situation jusqu'à ce que vous appréciiez vraiment profondément leurs préoccupations. Et je suis assez confiant de savoir quelle est la préoccupation numéro un. Nous y reviendrons dans un instant et ce n'est pas l'argent.
[00:19:32] Et vous êtes-vous engagé à remettre les choses en ordre? Il y aura des changements organisationnels vraiment délicats à régler si vous voulez adopter le modèle 'vous le construisez, vous l'exécutez'. Et il est important d'y consacrer un effort maximal et une transparence maximale. J'aime beaucoup le partage de Sebastian. La conférence passe comme la lumière du soleil est vraiment le meilleur désinfectant. D'accord, cela engendre toutes sortes de bons comportements lorsque vous faites preuve d'une transparence maximale.
[00:19:58] D'accord. Comment donnez-vous à vos développeurs ce dont vous avez besoin ? Eh bien, j'espère qu'il y a beaucoup d'indices maintenant. Il y a un tas d'enquêtes que nous n'avions pas auparavant sur le modèle 'vous le construisez, vous l'exécutez'. En 2022, Atlassian a mené une enquête auprès de 2 000 développeurs dans quatre pays différents, je crois, montrant que 59 % des développeurs sont d'astreinte. Et il existe une forte corrélation entre le modèle 'vous le construisez, vous l'exécutez' et la satisfaction au travail, malgré les changements de contexte supplémentaires. Il y a eu une enquête instant.io en 2022 qui a de nouveau montré un grand nombre de développeurs d'astreinte. Et elle a identifié la principale préoccupation des personnes qui prennent l'astreinte. Et c'est la même préoccupation que j'entends lorsque je parle à nos clients maintes et maintes fois, et c'est l'impact sur votre vie personnelle. L'astreinte est un sacrifice social et c'est quelque chose que vous devez respecter, d'accord ? Il y a une excellente citation dans l'enquête. Ne pas pouvoir vivre sa vie normalement, pas d'alcool, pas de longues balades à vélo, devoir transporter un ordinateur partout. Combien de personnes ici ont été d'astreinte et peuvent comprendre ce problème ? Oui.
[00:21:11] Alors, j'ai déjà été d'astreinte, et je me souviens du stress, comme de conduire sur une autoroute, en pensant, que se passe-t-il si on m'appelle maintenant, je n'ai nulle part où me garer. De réorganiser des vacances parce que je sais que je serai d'astreinte un week-end particulier. D'aller au cinéma avec ma femme et il n'y a pas de réception 4G et de stresser que je pourrais être appelé sans le savoir. En fait, c'est la grande préoccupation des gens. Et surprise, c'est la même préoccupation que vos équipes d'opérations ont eu concernant l'astreinte. Donc, cela vaut la peine de discuter avec eux de la manière dont ils ont surmonté ce problème particulier. Pour moi, il y a quelques choses que vous devez faire. La première chose est vraiment de reconnaître l'impact de l'astreinte sur la vie personnelle et de partager des données. Vous savez, encore une fois, il s'agit d'être transparent, n'est-ce pas ? Vous voulez partager la fréquence des incidents, leur durée et leur fréquence. Peut-être qu'un pourcentage élevé d'incidents se produisent pendant la journée plutôt que la nuit, ce qui rassurerait les gens s'ils le savaient.
[00:22:11] Vous devez créer du temps et de l'espace pour l'intégration à l'astreinte et la formation à l'astreinte. Vous voulez vous mettre en position où, lorsque quelqu'un prend l'astreinte, il se sent confiant, qu'il a l'impression d'avoir une mine de connaissances organisationnelles à portée de main. Par exemple, vous voulez que vos développeurs front-end se sentent confiants pour résoudre les problèmes back-end via un cahier des charges et vice versa. C'est un très bon test à avoir. Et vous devez compenser les gens pour être d'astreinte. Et je ne parle pas de les payer pour des interventions. Je veux dire les payer pour être en veille. Payez-les chaque nuit où ils sont d'astreinte. Payez-les chaque soir où ils sont d'astreinte, payez-les chaque, euh, week-end, chaque jour férié. Comme si vous ne compensez pas les gens pour avoir changé leur vie personnelle pour s'adapter au travail, quelqu'un d'autre le fera. Je l'ai vu se produire. Cela peut souvent être la goutte d'eau qui fait déborder le vase et affecter la rétention des employés.
[00:23:13] Il y a eu une enquête sur la rémunération de l'astreinte en 2019, menée par notre groupe communautaire, disponible en ligne. Et elle contient de très bonnes informations sur le montant payé aux gens et sur la façon dont les entreprises rémunèrent l'astreinte. Et il y a beaucoup de variations. La plupart des entreprises appliquent un tarif forfaitaire, mais ce n'est pas simple. Il n'y a donc pas de chiffre magique ici. Vous devez trouver une structure de rémunération qui fonctionne bien pour votre entreprise. Il serait malhonnête de ma part de dire, vous savez, voici un chiffre magique.
[00:23:46] D'accord. Cela semble génial, des développeurs d'astreinte. Mais cela ne fonctionnera pas ici car cela ne sera pas évolutif. Tout doit être évolutif. À quoi cela ressemble-t-il ? Cela ressemble à : 'Nous avons 20 équipes, Steve. Comment pouvons-nous avoir 20 développeurs d'astreinte ?' Comment cela pourrait-il être moins cher que d'avoir une seule personne des opérations d'astreinte pour les 20 équipes ? Je peux externaliser cette personne, Steve. Je peux les envoyer à Sainte-Hélène, Steve, c'est là que les Britanniques ont exilé Napoléon, c'est une île vraiment pourrie, c'est vraiment pas cher. Quand j'entends ça, je pense, vous savez, beaucoup à Napoléon, et puis je pense, vous n'avez pas encore équilibré l'exposition financière avec les coûts d'astreinte.
[00:24:36] Vous pouvez considérer un modèle opérationnel comme une police d'assurance, comme une police d'assurance multi-coûts. Vous savez, il y a un coût de fonctionnement et en retour, euh, vous savez, il y a un coût d'opportunité que vous pouvez atténuer. Et vraiment, il s'agit de protéger vos revenus, n'est-ce pas ? Il s'agit de minimiser les coûts opérationnels. Il y a une bonne analogie avec l'assurance habitation. Plus le contenu de votre maison est précieux, plus vous payez une prime élevée pour protéger le contenu de votre maison, car si quelque chose arrive, vous voulez que votre contenu soit remplacé rapidement. Et vous voulez qu'ils soient, vous savez, d'une qualité similaire.
[00:25:15] Qu'est-ce que cela signifie ? Cela signifie, oui, que 'vous le construisez, vous l'exécutez' sera un peu, un peu plus cher en termes de coûts de fonctionnement qu'une équipe d'opérations centrale. Mais quand vous regardez les coûts d'opportunité, quand vous regardez la protection des revenus, vous verrez que pour les services numériques, c'est supérieur à avoir une équipe d'opérations. Hmm.
[00:25:40] Avez-vous prévu comment l'argent circule à travers vos équipes et à travers vos services ? Ce n'est pas aussi difficile que ça en a l'air. Il y aura des études de cas disponibles, il y aura des estimations de revenus et des estimations de coûts disponibles. Vous pouvez estimer globalement quels de vos services génèrent le plus d'argent et à quels moments de la journée. Et ensuite, vous pouvez valider ces informations au fil du temps avec des incidents réels, tant que vous suivez leur impact financier. Et aussi avec les jours de chaos.
[00:26:14] Et cela vous aidera à comprendre que tous les services ne sont pas identiques et de la même importance.
[00:26:22] Et avez-vous abandonné cette absurdité absolue selon laquelle tout doit toujours être activé partout ? Vous aurez quelques services numériques avec beaucoup d'argent circulant le jour et beaucoup d'argent circulant la nuit. Alors ayez toujours quelqu'un qui surveille ceux-là.
[00:26:42] Vous aurez la majorité des services numériques, je suis prêt à parier. qui génèrent beaucoup d'argent le jour, mais moins la nuit. Alors ayez quelqu'un qui surveille, mais vous n'êtes pas obligé d'avoir une personne pour chaque service.
[00:26:56] Et vous aurez quelques services qui ne génèrent pas beaucoup d'argent le jour et très peu la nuit. Alors ne laissez personne les surveiller. Ça ira.
[00:27:11] D'accord. Comment pouvons-nous équilibrer l'exposition financière et les coûts d'astreinte ? Maintenant, rappelez-vous, je vous avais prévenu de mon humour sec, donc personne ne pourra venir me voir après en pleurant qu'ils n'ont pas compris ce que je faisais. Je vais maintenant vous montrer quelques expériences réelles de différentes organisations à travers le monde. Mais ce que je vais faire, c'est les anonymiser en les transformant en, chacun sera comme un pays différent, d'accord ? Comme des pays très lointains dont personne n'a jamais entendu parler. Et de cette façon, je serai en sécurité, et je ne serai pas poursuivi en justice, d'accord ? Alors, voici un exemple d'un détaillant de rénovation domiciliaire en France. Ce n'était pas vraiment la France, mais j'aime la France. Je suis venu à Paris avec ma femme une fois, et dans l'Eurostar je lui ai dit : 'N'oublie pas, chérie, quand nous allons dans un magasin, tu dois commencer chaque conversation par bonjour'. Sinon, nous ne serons pas servis, et elle a dit : 'Tu es un idiot, ce ne sera pas vrai dans la capitale'. Alors nous sommes allés à une boulangerie, l'homme est venu et nous a regardés avec curiosité. Et puis ma femme a dit 'Bonjour', et après 20 minutes, elle a dit 'Pourquoi n'avons-nous pas encore été servis ?' Et j'ai dit, 'Voulez-vous que je vous fasse un tableau' ? D'accord, ce détaillant particulier qui n'est certainement pas en France, avait 25 équipes et voulait un modèle 'vous le construisez, vous l'exécutez' qui minimisait les coûts de fonctionnement sans affaiblir les incitations à la fiabilité pour les développeurs. Parce que c'est de cela qu'il s'agit dans 'vous le construisez, vous l'exécutez'.
[00:28:46] Vous voulez vous assurer que les chefs de produit sont incités à prioriser les fonctionnalités opérationnelles en même temps que les fonctionnalités produit. Vous voulez vous assurer que les développeurs sont incités à construire un service qui peut se dégrader gracieusement en cas de défaillance. Parce que s'ils font une erreur, ce sont eux qui seront réveillés à 3 heures du matin.
[00:29:07] Donc, c'est le modèle que j'ai construit pour équilibrer l'exposition et les coûts d'astreinte. Il ne montre pas toutes les équipes, mais quelques-unes d'entre elles juste pour vous donner un aperçu. Sur l'axe Y, nous avons l'exposition financière en cas de défaillance, tout comme notre sélecteur de modèle opérationnel. Et encore une fois, nous avons une exposition relative, faible, moyenne, élevée, et elles correspondent à différents objectifs de disponibilité. Sur l'axe X, nous avons l'heure de la journée, à gauche c'est pendant les heures de travail, et à droite c'est en dehors des heures. Et c'est ce passage des heures de bureau aux heures non ouvrées où l'on voit un changement spectaculaire dans la façon dont vous construisez et gérez votre système. Nous avons cinq équipes ici.
[00:29:50] L'équipe en charge du service critique est l'équipe Cloud Search. Ensuite, au niveau de disponibilité moyen, qui, je pense, est de deux virgule cinq neuf pour cette entreprise.
[00:30:02] Il y a euh, qu'est-ce qu'ils sont ? Il y a l'équipe Plein Air. Vous voyez, quand vous déguisez des exemples, vous finissez par penser au vrai dans votre tête, et je ne dois pas dire le vrai. Euh, il y a une équipe Plein Air, une équipe Peinture et une équipe Meubles, et ils ont quatre services répartis entre trois équipes là-bas. Et ils appartiennent tous au même domaine produit, qui s'appelle 'parcours client'.
[00:30:21] Et puis, tout en bas, il y a le service d'exploitation de magasin mal-aimé, et cela appartient au domaine des opérations de magasin.
[00:30:31] Pendant la journée, toutes ces équipes sont d'astreinte pour leur propre service. Elles sont toutes configurées et vous appellent aussi. Il y a une personne d'astreinte à tout moment pendant les heures de bureau.
[00:30:47] Donc, cinq équipes, cinq personnes d'astreinte.
[00:30:51] Mais en dehors des heures de bureau, cela change de bas en haut.
[00:30:55] Le service des opérations de magasin a un objectif de faible disponibilité. Il a une faible exposition financière. En dehors des heures de bureau, personne ne s'en occupe. S'il y a un problème avec cela au milieu de la nuit, cela reste ainsi jusqu'au matin, lorsque l'équipe de développement commence le travail. Et quand je dis que personne ne s'en occupe, je veux dire personne. Il a été conçu de telle manière que l'équipe des opérations ne peut pas se voir confier cela, elle ne peut pas s'en occuper. Et cela est fait pour protéger les incitations à la fiabilité pour l'équipe de développement, même s'ils ne sont pas d'astreinte la nuit. Ils savent qu'ils sont d'astreinte pendant la journée, et ils savent que s'il y a un problème la nuit, ils devront le réparer quand ils arriveront le matin.
[00:31:39] D'accord, passons à. le domaine des parcours clients, en dehors des heures de bureau, il y a un roulement entre les trois équipes. Une personne des trois équipes est d'astreinte chaque nuit. Alors, ce soir, quelqu'un de l'équipe Plein Air, de l'équipe Peinture ou de l'équipe Ameublement sera d'astreinte pour tous les services de toutes ces équipes. Ces équipes ont une pile technologique similaire, elles collaborent assez étroitement.
[00:32:05] Et travailler avec un roulement basé sur les domaines de produits crée une affinité naturelle autour des résultats clients. Vous pouvez faire d'autres regroupements d'affinité comme la pile technologique ou la géographie des lieux, mais le plus efficace que j'ai trouvé est d'utiliser les domaines de produits.
[00:32:24] Et ce n'est pas parfait, comme les gens sont un peu nerveux à l'idée que quelqu'un d'une autre équipe s'occupe de leur service, mais c'est une équipe sœur, c'est une équipe avec laquelle ils passent du temps, et les gens comprennent la mission d'atteindre 'vous le construisez, vous l'exécutez' sans avoir, vous savez, des coûts de fonctionnement fous. Et tout en haut, l'équipe Cloud Search, leur service peut perdre beaucoup d'argent à tout moment. Si la recherche tombe en panne, le commerce chute car les gens ne chercheent pas d'articles à acheter, évidemment. Donc cette équipe a toujours quelqu'un d'astreinte à toute heure.
[00:32:56] Donc, comme je l'ai dit, ce modèle n'est pas parfait, mais il fonctionne. Cinq équipes pendant la journée, cinq personnes d'astreinte. La nuit, deux personnes d'astreinte. C'est une façon, et il y en a d'autres, de faire évoluer le modèle 'vous le construisez, vous l'exécutez'. Il y a beaucoup plus d'informations sur ce modèle de mise à l'échelle dans notre guide de jeu.
[00:33:21] D'accord. Ça a l'air super. Mais cela ne fonctionnera pas ici car personne ne serait responsable. Il doit y avoir une personne responsable. À quoi cela ressemble-t-il ?
[00:33:37] Nous devons avoir une seule personne à blâmer, Steve. Nous devons avoir une personne responsable.
[00:33:46] Ce serait le Far West si les développeurs étaient en charge des choses eux-mêmes.
[00:33:52] Quand j'entends ça, ce que je me dis, c'est que vous n'avez pas essayé de faire confiance à vos gens pour faire ce qu'il faut.
[00:34:02] Avez-vous expliqué à votre direction générale, à vos managers, à vos chefs d'équipe que ces changements de gouvernance sont une partie essentielle de la mission, que vous ne pouvez pas faire 'vous le construisez, vous l'exécutez' sans changer le fonctionnement de la gouvernance ? Que sans essayer le modèle 'vous le construisez, vous l'exécutez', sans lui donner une bonne chance, vous ne pourrez pas atteindre ce nouveau seuil de réussite.
[00:34:24] Avez-vous informé votre direction générale de l'importance que les chefs de produit fassent correspondre les résultats clients aux objectifs opérationnels ainsi qu'aux fonctionnalités ? C'est super important parce que lorsqu'un chef de produit priorise la fiabilité en plus de la fonctionnalité, de bonnes choses se produisent. Les équipes ne sont pas des usines à fonctionnalités, les équipes commencent réellement à réfléchir à la manière d'intégrer une dégradation gracieuse. Parce que le chef de produit leur donne le temps et l'espace pour le faire.
[00:34:57] Et avez-vous décrit à vos équipes comment ces responsabilités dévolues fonctionneront réellement ? Avez-vous encouragé vos responsables techniques à passer du temps avec vos chefs de produit, à leur apporter leur savoir-faire technique, à les aider à estimer l'exposition financière, à les aider à estimer la demande de fonctionnalités ?
[00:35:17] Très bien, comment faites-vous confiance à vos gens pour faire ce qu'il faut ?
[00:35:25] C'est un modèle RACI pour un site d'enchères en ligne en France. Mais pas vraiment en France. Bien que j'aime la France. Euh, ma famille et moi sommes allés une fois à un festival du vin dans la campagne française, et c'était vraiment excitant, la fin de la saison des vins, ils avaient toutes les tables de tréteaux, et tout le monde était assis à des tables. Et il y a un gars avec un microphone, et il dit : 'Qui est d'ici, de France ?' et de nombreuses tables se lèvent et tout le monde fait 'Ouais'. Et puis il dit : 'Quelqu'un d'ici est-il du Canada ?' et un groupe genre, 'Ouais, nous sommes du Canada', a fait 'Ouais'.
[00:35:59] Et puis juste pour rire, pensant que personne ne dirait oui, il dit : 'Quelqu'un d'ici est-il de Grande-Bretagne ?' et ma famille se lève, et tout le monde fait 'Boo'.
[00:36:10] C'est réellement arrivé en France.
[00:36:15] Alors. Qu'est-ce qu'un modèle RACI ? Il s'agit de savoir qui est responsable, qui est imputable, qui est consulté et qui est informé lorsque vous apportez un changement particulier ou que vous avez ce problème particulier dans votre entreprise.
[00:36:28] Je suis prêt à parier que votre entreprise a un modèle RACI quelque part. Les personnes chargées de la gouvernance adorent parler des modèles RACI. Alors pourquoi ne pas utiliser des outils que les gens connaissent, pourquoi ne pas utiliser le langage que les gens connaissent pour parler des changements que vous voulez apporter, pour rendre ce changement plus facile à apprécier pour eux. Donc, ce modèle RACI avait une catégorie pour la fiabilité. Et il couvrait des sujets comme la disponibilité, le support, la télémétrie et le budget d'astreinte. L'entreprise a un responsable des opérations, un responsable produit, et le département IT est entièrement séparé des produits, il y a un responsable de la livraison au sein de l'IT.
[00:37:10] Ce que j'ai fait, c'est diviser le modèle RACI, de sorte qu'il y a une catégorie pour les services numériques et une catégorie pour les systèmes fondamentaux.
[00:37:19] Alors si nous faisons la première ligne du bas, les systèmes fondamentaux.
[00:37:23] Nous n'avons pas changé cela. Le responsable des opérations est toujours responsable de la fiabilité de tous les systèmes fondamentaux de l'entreprise, 'une seule gorge à étrangler', comme disent parfois les Britanniques, ce qui est vraiment étrange. Et ce responsable des opérations délègue la responsabilité de la fiabilité à son équipe de support applicatif. Et le responsable produit, le responsable de la livraison, et les équipes produit, ils sont informés lorsque des changements ont eu lieu. Je suis assez confiant que tout le monde ici est familier avec cette façon de travailler. Avec les services numériques, c'est différent. Et c'est un peu compliqué car il y a un responsable produit et un responsable livraison.
[00:38:09] Donc, si une équipe produit travaille sur une nouvelle proposition client, elle est financée par le responsable produit, ils sont donc responsables de la fiabilité.
[00:38:19] Si l'équipe est en train de euh, re-plateformer ou de transformer un service existant, alors cela serait financé par le responsable de la livraison hors de l'IT, donc ils seraient responsables de la fiabilité du service numérique.
[00:38:35] Et ce que nous faisons ici, c'est que nous sommes très clairs sur le fait que c'est le détenteur du budget qui est responsable de la fiabilité, d'accord ?
[00:38:45] Dans les deux cas, vous transférez la responsabilité de la fiabilité aux équipes produit. D'accord, et ensuite le responsable des opérations et l'équipe de support applicatif, ils sont informés lorsqu'il y a eu un problème.
[00:39:01] Cela présente un certain nombre d'avantages. Le plus important est que les équipes examinent attentivement la tolérance au risque par rapport à l'effort d'ingénierie lorsqu'elles choisissent un objectif de disponibilité.
[00:39:13] Lorsque vous faites partie d'une équipe de livraison et qu'une équipe d'opérations va prendre en charge votre service numérique.
[00:39:21] Si on vous demande, et ce n'est probablement pas le cas, quel objectif de disponibilité souhaiteriez-vous ? Votre réponse est une disponibilité de 5,9 nines, car ce n'est pas vous qui devez le prendre en charge, alors pourquoi ne pas demander à 12 terminators dorés de s'occuper de votre affaire pendant que vous dormez ? Mais quand c'est vous qui devez payer l'effort d'ingénierie, et c'est vous qui devez faire l'astreinte, quelque chose d'intéressant se produit. Les gens commencent à se demander : 'Combien de temps d'arrêt pouvons-nous réellement avoir avec cette chose ? Combien d'argent perdrions-nous ? Combien d'argent voulons-nous payer pour protéger ce revenu ?'
[00:40:00] Un autre grand avantage ici est que les équipes commencent à prioriser la conception de la défaillance en même temps que les fonctionnalités du produit. Et c'est bon avec leur chef de produit, ils commenceront à faire des choses comme des files d'attente de contre-pression, de la mise en cache, des disjoncteurs, des cloisons, tout ce genre de bonnes choses, car maintenant du temps et de l'espace leur seront accordés pour réellement travailler sur ces choses.
[00:40:22] Maintenant, en toute honnêteté, c'est vraiment difficile à faire. Je ne vais pas faire semblant. C'est vraiment difficile de déplacer les responsabilités entre différents chefs de. C'est vraiment difficile de diviser un poste de dépenses opérationnelles (OPEX) d'astreinte en deux postes de dépenses d'investissement (CAPEX) différents provenant de l'astreinte.
[00:40:44] C'est difficile, et c'est la bonne chose à faire, d'accord ? Ce n'est pas parce que quelque chose est difficile que vous ne devriez pas essayer. et c'est bon avec leur chef de produit, ils commenceront à faire des choses comme les files d'attente à contre-pression, la mise en cache, les disjoncteurs, les cloisons, toutes ces bonnes choses. parce que maintenant, le temps et l'espace seront accordés pour réellement travailler sur ces choses. Maintenant, en toute transparence, c'est vraiment difficile à faire. Je ne vais pas faire semblant. C'est vraiment difficile de déplacer les responsabilités entre les différentes têtes. C'est vraiment difficile de diviser un élément de ligne d'astreinte OPEX en deux éléments de ligne CAPEX différents pour l'astreinte. C'est difficile et c'est la bonne chose à faire. D'accord ? Ce n'est pas parce que quelque chose est difficile que vous ne devriez pas essayer. D'accord, numéro quatre. Cela semble génial, mais ça ne marchera pas ici car il n'y aurait pas de gestion des incidents. À quoi cela ressemble-t-il ? Les développeurs abandonneraient les incidents, Steve. Ils seraient réveillés, ils regarderaient un problème et diraient : 'Je ne peux pas réparer ça', puis ils retourneraient se coucher. Nous nous ruinerions pendant que nous dormons, Steve. Eh bien, cela me semble un peu comme si vous n'aviez pas encore rendu la gestion des incidents en libre-service. Avez-vous mis en relation vos gestionnaires d'incidents avec vos développeurs ? Apprécient-ils leur dépendance au code ? Les gestionnaires d'incidents ne peuvent pas avoir une vie tranquille sans développeurs. Les développeurs ne peuvent pas avoir une vie tranquille sans gestionnaires d'incidents. Les gestionnaires d'incidents, ou la personne de votre entreprise responsable de la conformité de la gestion des incidents, qui pense qu'elle n'est pas un gestionnaire d'incidents, mais quand les auditeurs arrivent, vous dites que c'est le gestionnaire d'incidents. Ils sont super utiles, n'est-ce pas ? Ils ont des compétences organisationnelles, des voies de communication, des compétences en gestion des parties prenantes qui sont super utiles et, vous savez, vraiment pratiques pour les développeurs quand vous perdez beaucoup d'argent rapidement et que les gens sautent partout en disant : 'Qu'est-ce qui se passe ?' Vous voulez que vos gestionnaires d'incidents fassent confiance à vos développeurs pour les appeler quand ils sont dans une situation difficile. Vous voulez que vos développeurs fassent confiance à vos gestionnaires d'incidents pour intervenir et les aider quand ils sont dans une situation difficile. Avez-vous cartographié la façon dont votre processus de gestion des incidents fonctionne tel quel et tel qu'il est prévu ? Traitez-le simplement comme une cartographie de la chaîne de valeur, comme n'importe quoi d'autre, n'est-ce pas ? Déterminez les activités manuelles, semi-automatisées que vous avez, toutes ces feuilles de calcul sales que vous aimez prétendre qu'elles n'existent pas, et planifiez simplement d'automatiser le tout. D'accord ? Supprimez tous les transferts, toute la confusion, toutes les actions répétitives. Et avez-vous organisé des journées du chaos ? Vous n'avez pas besoin de faire comme Netflix et de construire une sorte de singe automatisé fou qui démolit une région AWS chaque fois que vous claquez des doigts. Vous pouvez organiser des journées du chaos dans un environnement de test. Vous pouvez les exécuter dans le style des tests exploratoires, trouvez simplement le membre le plus compétent de l'équipe, faites-en l'agent du chaos. et fixez des règles de base et un rayon d'action, et laissez-les faire des ravages, et vous apprendrez énormément sur votre processus de gestion des incidents. Vous apprendrez beaucoup sur la façon dont les gens peuvent travailler ensemble lorsqu'il y a un problème. Vous pouvez progressivement développer la confiance en intégrant la gestion des incidents dans le concept "vous le construisez, vous le gérez". D'accord. Comment pouvez-vous rendre la gestion des incidents en libre-service ? J'ai passé du temps avec un fournisseur de services de télécommunications à large bande une fois en France. Ce n'était pas vraiment la France, mais j'aime la France. J'ai enregistré à mon hôtel hier et la réceptionniste m'a dit : 'Le petit-déjeuner sera à 6h30 du matin'. Et j'ai dit : '6h30 ? C'est une heure maintenant ?' Plus personne en Grande-Bretagne ne se lève à 6h30 après la pandémie, nous sommes tous au lit à 6h30. Et elle m'a lancé ce regard dégoûté et m'a dit : 'Quelqu'un va manger votre petit-déjeuner à 6h30'. Alors, j'ai vraiment faim. Euh, ça s'est réellement passé hier matin. Non, hier soir, excusez-moi. Euh, chez ce Telco haut débit, ils avaient l'habitude d'avoir une équipe de pont d'opérations qui recevait des alertes pour des services qu'ils ne pouvaient absolument pas comprendre. Et puis ils avaient une feuille de calcul de numéros de téléphone qu'ils pouvaient appeler en cas de problème. Et bien sûr, la feuille de calcul était périmée. Il manquait des numéros de téléphone, certains numéros étaient incorrects, et ils paniquaient à l'aveuglette en composant des numéros jusqu'à ce que quelqu'un réponde au téléphone et dise : 'Je prends note de l'incident et je vais essayer de le réparer'. Ils avaient souvent des incidents qui duraient une heure ou plus, et jusqu'à 15 minutes de l'incident, un analyste essayait simplement de trouver quelqu'un qui répondrait au téléphone et travaillerait réellement sur le problème. Alors, j'ai été appelé avec d'autres personnes d'Equal Experts pour automatiser leur flux de travail de gestion des incidents, et nous avons persuadé l'entreprise d'investir dans PagerDuty, qui est un très bon outil. J'aime beaucoup PagerDuty. Euh, c'est assez souvent, il est rare que je recommande des outils, mais, euh, ça marche bien. Donc, ce qui se passe maintenant, c'est qu'il y a une alerte automatisée, elle va dans PagerDuty, qui crée automatiquement une instance dans Service Now, et il y a une synchronisation bidirectionnelle, donc les changements dans PagerDuty sont reflétés dans Service Now et vice versa. Euh, il y a un canal d'incident créé automatiquement dans Slack, et un développeur est appelé par euh PagerDuty. Maintenant, tout cela est assez standard, mais ce qui est vraiment bien, c'est que les gestionnaires d'incidents sont modélisés comme une équipe dans PagerDuty. Donc, si les développeurs ont des problèmes, si l'incident les dépasse, ils ajoutent simplement l'équipe de gestion des incidents à l'incident. Les gestionnaires d'incidents sont appelés, ils se réveillent, ils peuvent consulter dans Service Now, avec lequel ils sont très familiers, un ticket contenant toutes les informations nécessaires, le nom du développeur, le numéro de téléphone du développeur. Et ils peuvent appeler le développeur et dire : 'Salut, comment puis-je aider ?' Ce n'est pas difficile à implémenter, l'astuce est de persuader les développeurs et les gestionnaires d'incidents de travailler ensemble et aussi de dégager un budget OPEX pour PagerDuty lui-même. D'accord. Cela semble génial, mais ça ne marchera pas ici car les développeurs seraient des pompiers. Cela ressemble à des développeurs qui passeraient tout leur temps sur le BAU, Steve, BAU, BAU, BAU, ils ne travailleraient jamais sur des fonctionnalités, ils ne produiraient jamais de nouvelles fonctionnalités. Nous devons produire des fonctionnalités chaque jour, Steve, matin, midi et soir. Fonctionnalités, fonctionnalités, fonctionnalités, fonctionnalités, fonctionnalités. Cela me semble... comme si vous ne mesuriez pas ou n'éliminiez pas le travail de maintenance habituel. On dirait que vous avez peur de la chose. Alors pourquoi ne pas le mesurer et ensuite vous en débarrasser ? Avez-vous appris à gérer le travail imprévu ? Suivez-vous les éléments de travail BAU dans votre système de billetterie ? C'est très simple. D'accord ? Si une tâche BAU apparaît, comme corriger un défaut ou réparer une compilation cassée ou ajouter de la capacité d'infrastructure, cloud ou sur site, je m'en fiche. Si cela prend moins d'une demi-journée, faites-le. Si cela prend plus d'une demi-journée, créez un ticket, mettez-le dans Jira, donnez-lui une petite étiquette comme BAU ou quelque chose, puis laissez votre chef de produit le prioriser avec vous le lendemain matin. Avez-vous visualisé votre taux de retravaillent par équipe ? C'est tiré du livre « Accelerate », le taux de retravail est le pourcentage de temps qu'une équipe consacre au travail de maintenance imprévu. Et c'est facile à calculer si vous stockez les tickets dans Jira avec une petite étiquette BAU, il suffit de compter le nombre de tickets chaque mois qui sont terminés avec cette étiquette BAU. Et ensuite, vous pouvez représenter graphiquement pour chaque équipe si leur quantité de travail BAU augmente ou diminue. Et avez-vous construit des routes pavées ? C'est le terme de Netflix pour un parcours utilisateur entièrement automatisé et en libre-service. Le terme de Spotify est chemin doré. Et chez Equal Experts, nous appelons cela euh, des routes pavées aussi. Et ce sont des tueurs de BAU, c'est-à-dire qu'ils éliminent tellement de souffrance de la vie des développeurs parce qu'ils rendent tellement de parcours utilisateur sans défaut, sans friction, comme si c'était absolument la bonne chose à faire. D'accord. Comment pouvez-vous mesurer et éliminer le travail BAU ? Voici un exemple tiré d'une chaîne de télévision commerciale que j'ai visitée il y a quelque temps en France. Ce n'était pas vraiment la France, mais j'aime la France. Une fois, je suis venu ici et j'ai énervé un serveur en demandant un burger très bien cuit. Il est ensuite bien sûr arrivé à point, ce qui était exactement mon intention. Le serveur était dégoûté, il pensait presque que, vous savez, le rôti de bœuf est bien cuit, le burger est bleu, il devrait saigner. C'est un pays étrange, étrange. Euh, alors, euh, qu'avons-nous ici ? Nous avons quelques graphiques de ce réseau de télévision qui n'est absolument pas en France. Et en jaune, il y a une plateforme réseau héritée construite sur site, un système cot avec une équipe de livraison et une équipe d'opérations qui s'en occupent ensemble. Et en bleu, c'est un service de planification construit par une équipe qui fait, 'vous le construisez, vous l'exécutez'. Nous allons d'abord regarder le graphique de gauche. C'est l'intervalle de déploiement, le nombre de jours entre les mises en production. Vous pouvez voir une ligne plate pour l'équipe de planification, c'est très bien. Ils ont fait en moyenne un déploiement par jour pendant deux ans, ce qui est exceptionnel. L'équipe de la plateforme réseau, leur intervalle de déploiement moyen variait de deux semaines à quatre semaines à six semaines. Et vous pouvez voir des lacunes entre les déploiements. Quelles en étaient les causes ? Les gels de changements, c'est exact. Tout le monde aime les gels de changements, l'ancien temps où nous en avions plus me manque, ils me manquent. Et le graphique de droite, nous allons y passer ensuite. C'est le temps de restauration, deux ans de données restaurées, d'accord ? Je dépasse les cinq minutes. Vous n'allez pas venir ici, je suis grand. Euh, donc, l'axe Y est euh jusqu'à quatre heures. Vous verrez en jaune un tas de petits points qui signifient qu'il y a eu un grand nombre d'incidents au sein de leur plateforme réseau et qu'ils ont pris, vous savez, des heures à restaurer. Les points bleus montrent qu'il y avait moins d'incidents pour le service de planification et qu'ils étaient plus rapides à restaurer. Et le graphique du milieu montre le BAU en pourcentage. Et vous verrez qu'il est vraiment élevé pour l'équipe de la plateforme réseau héritée. Jusqu'à 75% de leur temps était consacré à la réparation de choses. Seulement 25% de leur temps était consacré à la construction de nouvelles choses. Pour l'équipe de planification, seulement 10% de leur temps était consacré au travail BAU. Et la plus grande différence entre ces deux équipes était que l'équipe de planification était habilitée à faire quelque chose concernant le BAU. Ils étaient capables d'apporter des changements comme bon leur semblait pour réduire le travail BAU au fur et à mesure qu'il arrivait. L'équipe de la plateforme réseau héritée voulait faire quelque chose à ce sujet, mais ils n'étaient pas en mesure de le faire. Bon, la dernière. Ma préférée. « Vous le construisez, vous le gérez » sonne bien, mais ça ne marchera pas ici car vous ne pouvez pas embaucher un DBA pour chaque équipe. Personne ne vous l'a demandé. Bon, cela ressemble à des DBA tellement chers. Ils sont si difficiles à trouver, Steve. Nous ne pouvons pas les intégrer dans les équipes, ils n'auraient personne à qui parler, ils se sentiraient seuls. Nous ne pouvons pas laisser les développeurs interroger la base de données, la dernière fois que cela s'est produit, ça a planté. Je ne sais pas comment s'appellent mes DBA, l'une d'elles, je pense, s'appelle Katie, c'est comme ça que je l'appelle. Euh, cela me semble que vous devez mieux connaître vos DBA. Mais cela semble aussi que vous n'avez pas rendu les tâches spécialisées répétables en libre-service. Avez-vous compris qu'embaucher un DBA pour chaque équipe n'est pas "vous le construisez, vous le gérez" ? C'est un extrême inutile. D'accord ? Le principe "vous le construisez, vous le gérez" concerne les équipes produit interfonctionnelles qui résolvent leurs propres problèmes, mais vous pouvez toujours avoir vos DBA comme facilitateurs opérationnels, comme une équipe centrale. Il n'y a rien de mal à cela. Avez-vous rejeté cette idée d'intégrer des spécialistes dans les équipes ? Vous n'avez pas à forcer les gens du DevOps dans les équipes produit, ils ne sauraient de toute façon pas ce qu'est le DevOps. Vous n'avez pas à pousser les DBA dans les équipes. Je sais que si vous ajoutez plus d'équipes de produits, une équipe DBA centrale sera surchargée de travail et pourrait commencer à s'épuiser et à avoir une charge cognitive élevée. Je sais aussi que si vous entassez un DBA dans chaque équipe, ils ne se sentiront pas comme faisant partie d'une tribu. Leur charge de travail variera d'énorme à nulle et ils finiront par être répartis entre plusieurs équipes, ce n'est pas une bonne chose. Et avez-vous automatisé les tâches spécialisées répétables ? Ce que vous voulez faire, c'est suivre le principe général de la livraison continue, c'est-à-dire faire faire le travail pénible aux machines afin que les humains puissent faire les choses difficiles de plus haut niveau pour lesquelles les machines sont vraiment mauvaises. Alors, construisez simplement des pipelines de déploiement, construisez davantage de routes pavées. D'accord, comment pouvez-vous rendre les tâches spécialisées répétables en libre-service ? Voici une cartographie de tâches que j'ai aidée une entreprise de services financiers à réaliser en France. Ce n'était pas vraiment la France, mais hier à la Gare du Nord, je suis entré dans un magasin et j'ai dit : 'Bonjour', parce que je sais qu'il faut dire 'Bonjour' d'abord. J'ai dit : 'Bonjour, avez-vous des adaptateurs de prise Royaume-Uni vers Euro ? J'ai oublié le mien'. Et la dame m'a regardé très sympathiquement, et j'ai cru qu'elle allait dire : 'Nous là-bas.' Mais elle n'a pas dit ça. Elle a dit : 'Non, pas depuis le Brexit'. Et j'ai dit, 'Je suis désolé pour le Brexit, nous sommes devenus fous.' Et elle a dit, 'Dis-le-toi à toi-même'. Euh, ça va. Elle semblait gentille. Alors, voici, euh, la manière dont j'ai aidé cette entreprise de services financiers à décomposer ce que faisaient leurs DBA et ce qu'ils devraient faire, d'accord ? Le tel quel versus le tel qu'il est prévu, encore une fois, d'accord ? Donc, nous avons différentes catégories de tâches ici, de haut en bas. Tout d'abord, les tâches répétables à faible valeur. D'accord ? Déléguez-les à votre fournisseur de cloud. D'accord ? Autant que votre conscience vous le permettra, ne réfléchissez pas trop, faites-le simplement. Donc, dans le cas de cette entreprise, ils avaient une base de données relationnelle PostgreSQL sur site qu'un DBA devait surveiller tous les jours. Et ils l'ont migrée vers AWS Aurora. Donc, d'un coup, vous n'avez plus à faire de récupération après sinistre. Vous n'avez plus à faire de sauvegardes, vous n'avez plus à faire de capacité d'infra. Il y a eu de la résistance à faire cela, les gens s'inquiétaient du coût de la migration, cela a pris beaucoup de temps pour que cela se produise. Mais comparé au coût d'embauche de plus de DBA, comparé au coût du départ des DBA parce que leur charge de travail devient trop élevée, cela se rentabilise. Il faut juste avoir une vision à plus long terme. D'accord, ensuite, les tâches répétables à forte valeur. D'accord, des choses que les équipes de développement, vous savez, ont vraiment besoin de faire, mais qui ne cessent de surgir. Vous pouvez construire des routes pavées pour cela, n'est-ce pas ? Vous pouvez construire des pipelines de déploiement en libre-service. Euh, un exemple facile ici est comme la création d'un schéma de base de données. Cela n'a pas besoin d'un DBA, n'est-ce pas ? Il a besoin des permissions d'un DBA, que les développeurs ne devraient pas avoir. Alors construisez un pipeline pour cela et verrouillez-le, mettez-y de la surveillance. Et après que les développeurs aient exécuté le pipeline pour créer un schéma de base de données, envoyez simplement un petit e-mail au DBA en disant : 'Bonjour, un nouveau schéma a été créé'. Et enfin, le travail ad hoc de grande valeur. C'est là que vos DBA excellent vraiment. C'est là que vous voulez qu'ils aident les développeurs à comprendre les problèmes de performance d'indexation, les problèmes avec les données utilisateur en direct, les choses pour lesquelles les développeurs sont vraiment mauvais. Cela peut très bien fonctionner, mais encore une fois, cela va entraîner des changements organisationnels vraiment délicats. Vos DBA vont un peu paniquer à cause de cela. Ils vont paniquer de ne plus s'occuper de la base de données. Ils vont paniquer de ne plus créer de schémas, parce que c'est ce qu'ils ont toujours fait. Mais l'important est de les asseoir et de les aider à comprendre que ce que vous voulez est dans leur cerveau, pas de la saisie. D'accord, et demandez à votre fournisseur de cloud de faire le plus possible de saisie pour que vous puissiez réellement accéder à leur cerveau. D'accord. Pour conclure, toutes ces objections à 'vous le construisez, vous le gérez', elles se résument toutes à la même chose, n'est-ce pas ? Elles se résument à : 'Nous n'avons jamais fait cela auparavant.' Et je, je comprends tout à fait cela, le changement est difficile, d'accord ? Il est vraiment important que vous partagiez la mission avec les gens, que vous y injectiez une certaine urgence et que vous leur disiez que c'est une question de survie pour votre entreprise, de fournir des résultats aux clients plus rapidement que jamais. Vous devez choisir une équipe pilote, comme une équipe Boucle d'or, vous savez, pas trop chaude, pas trop froide, juste comme il faut. Alors trouvez une équipe avec quelques dépendances, mais pas trop de dépendances. Trouvez une équipe importante, mais pas trop importante. Et aidez-les à devenir un exemple pour vos autres équipes. Ne commencez pas par faire en sorte que chaque équipe essaie de le construire, de le faire fonctionner, donnez trois mois à une équipe pour voir comment elle s'en sort. Et vous devez changer l'état d'esprit de votre entreprise. Vous devez aider les gens à comprendre qu'il est normal de faire des erreurs. Il est normal d'apprendre de ses erreurs, que vous ne savez pas nécessairement comment vous allez atteindre votre destination, vous avez juste une idée approximative de ce à quoi cela va ressembler. Bon, enfin, "vous le construisez, vous le gérez", c'est génial. Ça peut marcher ici, où que ce soit. Possiblement en France. Vous devez donner à vos développeurs ce dont ils ont besoin. Vous devez équilibrer l'exposition financière sur les coûts d'astreinte. Vous devez faire confiance à vos collaborateurs pour faire ce qu'il faut. Vous devez rendre la gestion des incidents en libre-service. Vous devez mesurer et éliminer le travail BAU. Et vous devez rendre les tâches spécialisées répétables en libre-service. Merci beaucoup de m'avoir invité, et s'il y a des questions, je suis heureux d'y répondre. Merci.

Transcription (Traduit)