John Allspaw, co-fondateur, Adaptive Capacity Labs

Comment vos systèmes continuent à fonctionner jour après jour

Tout d’abord, quelques mots sur John Allspaw, cofondateur d’Adaptive Capacity Labs et ancien directeur de la technologie chez Etsy.

Chef de file en ingénierie et chercheur avec plus de 20 ans d’expérience dans la construction et la direction d’équipes engagées dans l’ingénierie des logiciels et des systèmes, Allspaw a passé les dix dernières années à mettre en commun ses connaissances des facteurs humains, de l’ingénierie des systèmes cognitifs et de l’ingénierie de la résilience. opérations.

Également auteur de deux ouvrages intitulés «L’art de la planification des capacités: mise à l’échelle des ressources Web» et «Opérations Web» (O’Reilly Media), Allspaw continue de contribuer aux communautés informatique et DevOps en prenant la parole et en collaborant à de nouvelles recherches intéressantes.

Nous avons eu la chance d’accueillir John au DevOps Enterprise Summit à San Francisco, où il est intervenu pour parler de «Comment les systèmes continuent de fonctionner jour après jour». Vous trouverez ci-dessous la transcription des points à retenir et des points saillants de sa présentation. .

John Allspaw à DOES17 San Francisco

John Allspaw

Comment vos systèmes continuent à fonctionner jour après jour

Ce dont je veux parler est nouveau. C'est différent et cela me tient vraiment à coeur.

Pour aider à préparer le terrain, ma thèse de maîtrise en facteurs humains et sécurité des systèmes était «Les compromis sous pression: heuristiques et observations des équipes chargées de résoudre les pannes de service Internet».

Certains d’entre vous ont peut-être entendu parler de cela, ce qu’on appelle le rapport Stella.

À un haut niveau, ce rapport est le résultat d’un projet d’un consortium de partenaires industriels d’une durée d’un an. IBM, Etsy et IEX, société de négoce, bourse de négoce à Manhattan. Au cours de l'année, David Woods, Richard Cook, du laboratoire d'ingénierie des systèmes cognitifs de l'université d'État de l'Ohio, ont examiné de manière approfondie un incident survenu dans chacune de ces organisations.

Ils ont trouvé ces six thèmes et étaient communs à tous.

Les résultats sont certainement très importants. C’est la façon dont cette recherche a été effectuée et que je souhaite que vous examiniez tous.

Voici mes principales conclusions du rapport:

  1. Nous devons commencer à prendre au sérieux la performance humaine dans cette industrie. Si nous ne le faisons pas, nous continuerons à voir des systèmes fragiles ayant des impacts sans cesse croissants sur nos entreprises et sur la société.
  2. Nous pouvons le faire en examinant des incidents allant au-delà de ce que nous faisons actuellement après les examens post-mortem ou après-incident ou après-action.
  3. Il existe des méthodes et des approches issues de l’étude de la résilience dans d’autres domaines, mais elles nécessitent un réel engagement. Cela est à la fois nécessaire et difficile, mais cela constituera un avantage concurrentiel pour les entreprises qui le font bien.

Tout d’abord, je voudrais commencer par un peu de base, un vocabulaire qui va être important pour vous guider un peu plus loin dans cette partie. Je vais décrire une sorte d’image, une représentation, à la manière d’un modèle mental de vos organisations, avec une région au-dessus de la ligne et une au-dessous de la ligne.

Si vous imaginez ce que nous avons décrit ici, il s’agit de votre produit, de votre service, de votre API ou de tout ce que votre entreprise tire de la valeur et donne aux clients. D'accord? À l'intérieur, ce que vous voyez est votre code. Vous voyez votre pile technologique. Vous voyez les données et diverses manières de fournir ceci, non? Vraisemblablement sur Internet ou d'une autre manière. Mais si nous restons ici, personne ne me croira que c’est ce que nous appelons le système, car c’est bien, mais ce n’est pas vraiment complet.

Ce qui est vraiment connecté, et dont beaucoup de gens ont parlé ici dans la communauté DevOps Enterprise Summit, c’est tout ce que nous faisons pour manipuler ce qui se passe là-bas. Nous avons donc des outils de test. Nous avons des outils de surveillance. Nous avons des outils de déploiement et tout le matériel qui est en quelque sorte câblé. Ce sont les choses que nous utilisons. On pourrait dire que c’est le système car beaucoup d’entre nous consacrons notre temps à des choses qui ne se trouvent pas à l’intérieur de la petite bulle, mais à tout ce qui les entoure, mais si nous restons juste avec cela, nous ne sera pas capable de voir où le vrai travail se passe.

Nous allons faire ici, nous allons tracer une ligne que nous appelons la ligne de représentation, puis creuser un peu plus profondément. Ce que nous voyons ici, c'est vous. Toutes les personnes qui préparent des éléments à ajouter au système, à changer de système. Vous faites le cadrage architectural. Vous faites de la surveillance. Vous surveillez ce qui se passe, comment vous le faites et ce qui se passe.

Vous remarquerez que chacune de ces personnes a une sorte de représentation mentale de ce qu'est ce système. Si vous regardez de plus près, vous verrez qu’aucune d’entre elles n’est la même. Soit dit en passant, c’est très caractéristique de ces types de rôles. Personne n'a la même représentation de ce qui est en dessous de la ligne.

Pour résumer, c’est notre modèle de monde et il ne comprend pas seulement ce qui se passe là-bas, mais vous tous, le type d’activités que vous effectuez, le travail cognitif que vous effectuez pour que ce monde continue de fonctionner. . Si on joue un peu plus avec cela, on se retrouve avec ce genre de modèle. Ce modèle comporte une ligne de représentation passant par le milieu et vous interagissez avec le monde situé au-dessous de la ligne via un ensemble de représentations.

Vos interactions ne sont jamais avec les choses elles-mêmes. Vous ne changez pas réellement les systèmes.

Ce que vous faites, c’est que vous interagissez avec la représentation et que cette représentation est ce qui se passe ci-dessous. Vous pouvez penser à ces choses vertes comme aux écrans que vous regardez pendant la journée, mais la seule information que vous avez sur le système provient de ces représentations. Ils sont juste un petit trou de serrure. Droite?

Ce qui est important, c’est que toutes vos activités, observer, déduire, anticiper, planifier, corriger, etc., doivent être réalisées via ces représentations. Il existe donc un monde au-dessus de la ligne et un monde au-dessous de la ligne, et bien que vous et nous parlions principalement du monde au-dessous de la ligne comme si c'était très réel, comme si c'était très concret, comme si c'était quelque chose qui était la chose, voici la surprise.

Voici le gros problème - vous ne le verrez jamais.

Ça n'existe pas. En réalité, il n’ya pas de limite en dessous de la ligne que vous pouvez réellement toucher. Vous ne voyez jamais, jamais le code courir. Vous ne voyez jamais, jamais le système fonctionne réellement. Vous ne touchez jamais ces choses.

Ce que vous faites, c’est manipuler un monde que vous ne pouvez pas voir à travers un ensemble de représentations et c’est pourquoi vous devez construire ces modèles mentaux, ces conceptions, ces compréhensions de ce qui se passe. Ce sont les choses qui alimentent cette manipulation. Ce n’est pas le monde en dessous de la ligne qui le fait. C’est votre capacité conceptuelle à comprendre ce qui est arrivé dans le passé, ce que vous faites maintenant et pourquoi vous le faites, ce qui compte et ce qui importe réellement.

Une fois que vous avez adopté cette perspective, une fois que vous vous rendez compte que l’idée que vous travaillez au-dessous de la ligne est au-dessous de la ligne et que vous comprenez que vous travaillez vraiment au-dessus de la ligne, toutes sortes de choses changent.

Ce que vous voyez dans le rapport Stella et dans ce projet, ainsi que dans d’autres projets dans lesquels nous avons été engagés, prend ce point de vue en compte et comprend ce que cela signifie réellement de prendre au sérieux le monde hors-la-ligne. C’est un grand départ de ce que vous avez tous vu dans le passé, mais je pense que c’est une direction fructueuse que nous devons prendre.

En d'autres termes, ces activités cognitives (voir ci-dessous) chez les individus et collectivement dans les équipes de haut en bas de l'organisation sont ce qui fait que l'entreprise fonctionne réellement. Maintenant, j'étudie cela en détail depuis un certain temps et je peux vous le dire. Cela ne fonctionne pas comme nous le pensons.

Enfin, pour définir ce cadre, la partie la plus importante de cette idée est que tout cela change avec le temps. C’est un processus dynamique en cours. C'est l'unité d'analyse. Une fois que nous avons pris ce cadre, nous pouvons poser quelques questions. Nous pouvons poser quelques questions au-dessus de la ligne comme celle-ci.

«Comment notre logiciel fonctionne-t-il réellement, par rapport à la manière dont il est décrit dans le wiki, dans la documentation et dans les diagrammes? Nous savons que ceux-ci ne sont pas exhaustifs, ils ne sont pas globalement exacts. "

«Comment notre logiciel fonctionne-t-il réellement par rapport à la manière dont nous pensions qu'il se briserait lorsque nous avons conçu les protections, les disjoncteurs et les glissières de sécurité?»

"Que faisons-nous pour que tout fonctionne correctement?"

Question: Imaginez votre organisation. Que se passerait-il si, à six heures du matin, toutes vos entreprises se retiraient du clavier? Ils ne répondent à aucune page. Ils ne regardent aucune alerte. Ils ne touchent aucune partie de celui-ci, ni le code d'application, ni les réseaux, ni aucun de ceux-ci. Êtes-vous confiant que votre service sera opérationnel après une journée?

La question est alors de savoir comment découvrir ce qui se passe au-dessus de la ligne. Eh bien, il y a deux choses. Nous pouvons tirer des enseignements de l’étude d’autres domaines dans lesquels le rythme est élevé et les conséquences importantes, et si nous le faisons, nous pouvons voir que nous pouvons étudier les incidents. (Remarque: lorsque je parle d’incidents, j’entends des pannes, des dégradations, des violations, des accidents, des quasi-accidents et des problèmes, essentiellement des événements fâcheux ou inattendus).

Qu'est-ce qui rend les incidents intéressants? L’évidence est la perte de revenus et les répercussions sur la réputation d’une entreprise donnée. Je tiens à affirmer quelques autres raisons pour lesquelles les incidents sont intéressants. Le premier est que les incidents façonnent la conception de nouveaux sous-systèmes et architectures de composants. En d'autres termes, des incidents d'hier informent les architectures de demain. C'est-à-dire que les incidents aident notre imagination à améliorer nos systèmes et, par conséquent, ce que je veux dire, ce sont des incidents en dessous de la ligne qui changent au-dessus de la ligne.

C'est ca le truc. Cela peut coûter de l'argent réel. Les incidents peuvent avoir parfois des effets presque tacites ou invisibles, parfois importants. À l'heure actuelle, beaucoup de gens divisent un monolithe en micro-services. Beaucoup de gens le font parce que cela procure une certaine robustesse que vous n’avez pas. Où as tu obtenu ça?

Vous êtes informé par des incidents.

Une autre raison de considérer les incidents est qu’ils ont tendance à donner naissance à de nouvelles formes de réglementations, de politiques, de normes, de conformité, d’audit, de contraintes, etc. Une autre façon de le dire est que les incidents d’hier influent sur les règles de demain, qui influencent la dotation en personnel. , budgets, planification, feuilles de route et plus. Permettez-moi de vous donner un exemple: dans le domaine des opérations financières, la SEC a mis en place la réglementation SCI. SCI est probablement le document de conformité le plus complet et le plus détaillé de l’ère des logiciels modernes. La SEC est partie et a été très explicite. Nous avons cela en réaction au crash flash de 2010 de Knight Capital, introduction en bourse de BATS, introduction en bourse de Facebook. C'est une réaction aux incidents.

Même si vous remontez un peu plus en arrière, on dit souvent que les normes PCI DSS sont apparues lorsque MasterCard et Visa ont comparé leurs billets, se sont rendus compte qu'ils avaient perdu environ 750 millions de dollars sur 10 ans. Les incidents ont donc un impact significatif et, soit dit en passant, je peux ancien directeur technique d'une entreprise publique, je peux vous assurer qu'il s'agit d'un albatros très coûteux, gênant et inévitablement pesant pour toutes vos organisations. Les incidents sont également significatifs de cette façon, mais si nous considérons les incidents comme des opportunités, si nous considérons les incidents comme des messages, les messages codés sous la ligne sont envoyés au-dessus de la ligne et votre travail consiste à les décoder, si vous envisagez des incidents. Il s’agit là de choses qui essaient activement d’attirer votre attention sur des parties du système que vous pensiez avoir une compréhension suffisante mais que vous ne compreniez pas, ce sont des rappels qui vous obligent à reconsidérer continuellement votre confiance en la façon dont tout cela fonctionne.

Maintenant, si vous prenez ce point de vue, tout un tas de choses s’ouvrent. Il existe une opportunité pour de nouvelles formations, de nouveaux outils, de nouvelles structures organisationnelles, une nouvelle dynamique de financement et éventuellement des informations que vos concurrents n’ont pas.

Les incidents nous aident à mesurer le delta entre le fonctionnement de votre système et la manière dont nous pensons qu'il fonctionne, et ce delta est presque toujours supérieur à ce que nous imaginons. Je veux affirmer peut-être une prise différente à laquelle vous êtes peut-être habitué, et c’est cela. Les incidents sont des investissements imprévus dans l’entreprise, dans la survie de votre entreprise. Ce sont des occasions extrêmement précieuses de comprendre le fonctionnement de votre système, les vulnérabilités en matière d’attention et les avantages concurrentiels que vous ne recherchez pas.

Si vous pensez à des incidents, ils perdent de l'argent, leur temps, leur réputation, leur personnel, etc. Ce sont des coûts irrécupérables inévitables. Ce type d’investissement a quelque chose d’intéressant. Vous ne contrôlez pas la taille de l’investissement. La question qui reste est donc de savoir comment optimiser le retour sur investissement de cet investissement.

Lorsque nous examinons les incidents, c’est le type de questions que nous entendons et cela correspond tout à fait à ce que les chercheurs trouvent dans d’autres systèmes et domaines complexes. Que fait-il? Pourquoi fait-il cela? Que fera-t-il ensuite? Comment est-il entré dans cet état? Qu'est-ce qui se passe? Si nous faisons Y, cela nous aidera-t-il à savoir quoi faire? Est-ce que ça empire? On dirait que c’est réparé, mais est-ce vrai? Si nous faisons X, cela va-t-il empêcher l'aggravation ou l'empirer? Qui d'autre devrions-nous appeler qui peut nous aider? Est-ce notre problème ou sommes-nous attaqués? Ceci est cohérent avec de nombreux autres domaines. Aviation, contrôle du trafic aérien, en particulier dans les domaines riches en automatisation.

Une autre chose notable est que, au début de tout incident, il est souvent incertain ou ambigu de savoir s’il s’agit ou non de celui-là. Au début d’un incident, nous ne le savons tout simplement pas, surtout s’il contient une énorme incertitude et une grande ambiguïté. Si cela est incertain et ambigu, cela signifie que nous avons épuisé nos modèles mentaux. Ils ne correspondent pas à ce que nous voyons et ces questions se posent. Seul le recul nous dira si c’est l’événement qui a abattu la société ou si c’est un mardi après-midi difficile.

Les incidents fournissent un étalonnage sur la manière dont les décisions sont focalisées, sur la focalisation de l'attention, sur la coordination, sur la coordination, sur la progressivité. L'impact de la pression du temps, l'impact de l'incertitude, l'impact de l'ambiguïté et les conséquences des conséquences. La recherche valide ces opportunités.

«Nous devrions examiner de manière approfondie les incidents en tant que« événements difficiles non courants, car ces cas difficiles ont le plus grand potentiel pour découvrir des éléments d’expertise et des phénomènes cognitifs connexes ».
- Gary Klein, l'initiateur de la recherche décisionnelle naturaliste.

Il existe une famille de méthodes, d’approches et de techniques bien utilisées. Analyse de tâche cognitive. Traçage de processus. Analyse conversationnelle. La méthode de décision critique. Voici comment nous pensons que postmortems a de la valeur:

Un incident se produit. Peut-être que quelqu'un va établir un calendrier. Nous avons un peu d'une réunion. Vous avez peut-être un modèle et vous le remplissez, puis quelqu'un peut faire un rapport ou non, et puis vous avez, oui, des actions, enfin. Nous pensons que la plus grande valeur, peut-être peut-être la plus précieuse, réside dans le débriefing et l’analyse de la chronologie, et vous vous dites: «Oh, mon Dieu. Nous savons tout cela. "

Ce n'est pas ce que la recherche confirme. La recherche montre que si nous recueillons des données subjectives et objectives provenant de multiples lieux, des données comportementales, ce que les gens ont dit, ce que les gens ont fait, où ils ont regardé, quelles voies de diagnostic ont-ils suivies et n’ont pas été fructueuses? Des débriefings bien animés amènent les gens à confronter et à comparer leurs modèles mentaux nécessairement défectueux. Vous pouvez produire différents résultats, y compris des éléments tels que le bootcamp, l’intégration de matériel, la formation de nouveaux employés. Vous pouvez obtenir des commentaires sur la facilitation si vous créez un programme pour former des facilitateurs. Vous pouvez apporter des modifications à la feuille de route, des modifications très importantes en fonction de ce que vous apprenez.

Je peux vous le dire par expérience. Rien de plus perspicace pour un nouvel ingénieur ou un ingénieur débutant dans sa carrière que d’être dans une pièce avec un ingénieur vétéran qui connaît tous les coins et recoins pour expliquer des choses qu’ils n’ont peut-être jamais dites à haute voix. Ils ont des connaissances. Ils peuvent dessiner des images et des diagrammes qu’ils n’ont jamais dessinés auparavant, car ils pensent que tout le monde le sait. Devine quoi? Ils ne le font pas. La valeur la plus importante est en réalité ici, car la qualité de ces résultats dépend de la qualité de ce recalibrage. C'est une ouverture pour recalibrer les modèles mentaux.

D'après le rapport Stella, il "informe et recalibre les modèles des gens sur le fonctionnement du système, leur compréhension de la vulnérabilité et les possibilités d'exploration".

Dans beaucoup de recherches, dans toutes les recherches contenues dans le rapport Stella, et cela correspond également à mon expérience chez Etsy, l'une des plus fortes est celle des personnes qui le font d'une manière facilitée. contrasté. "Je ne savais pas que cela fonctionnait de cette façon." Ensuite, il y a toujours un autre "Comment cela a-t-il fonctionné?" Ce qui est amusant jusqu'à ce que vous réalisiez que c'est grave. Ce que cela signifie, c’est que non seulement je pensais que cela fonctionnait différemment. Maintenant, je ne peux même pas imaginer, je ne peux même pas dessiner dans mon esprit comment cela aurait pu fonctionner. Cela devrait être plus troublant. En passant, je tiens à dire que ce n'est pas l'alignement. Comme je l'ai dit, via des représentations, nous avons nécessairement des modèles mentaux incomplets. L’idée n’est pas d’avoir les mêmes modèles mentaux, parce qu’ils sont toujours incomplets, parce que les choses changent constamment et qu’elles vont être imparfaites. Nous ne voulons pas que tout le monde ait le même modèle mental, car alors tout le monde aura les mêmes angles morts.

Blameless - pour revenir au billet de blog que j'ai écrit en 2012

"Sans reproche" est un enjeu de table. C’est nécessaire, mais ce n’est pas suffisant. Vous pouvez créer un environnement, une culture, une sorte d’organisation accueillante qui encourage et permet aux gens de raconter des histoires dans tous les détails brouillés, parfois gênants, sans craindre de représailles, pour que vous puissiez réellement progresser. en comprenant ce qui se passe, vous pouvez configurer cette condition sans toujours apprendre beaucoup. Ce n'est pas suffisant. C’est nécessaire, mais pas suffisant. Ce dont je parle, c’est beaucoup plus d’efforts que les examens typiques après un incident. Droite? C'est à cet endroit qu'un analyste, un facilitateur peut préparer, compiler, organiser, analyser des données comportementales. Ce que les gens disent, ce que les gens font. Il leur est possible de puiser dans une foule de données pour préparer des débriefings, un debriefing en groupe ou un debriefing individuel, au-delà… Les accidents post-mortem font allusion à la richesse des incidents. Suivre cela demande beaucoup de travail.

En passant, tout le monde est tellement épuisé après une panne, un incident ou un événement stressant que tout devient parfois limpide. C’est le pouvoir du recul, et comme cela semble si clair, cela ne semble pas productif d’avoir un débriefing, parce que vous pensez déjà tout savoir. L'autre problème est que les briefings post-mortem sont également limités par le temps. Vous avez seulement la salle de conférence pour une heure ou deux. Tout le monde est très occupé et le temps presse, il est donc difficile de bien le faire, même avec ces méthodes de recherche.

L’autre problème, en particulier si vous créez un programme de formation au débriefing, comme je l’ai fait chez Etsy, reste à relever des défis. Ce que j’aime appeler cela, c’est: «Chacun a son propre mystère à résoudre» ou «Ne perdez pas mon temps sur des détails que je connais déjà». De manière caricaturale, vous pouvez le penser comme suit:

Comme vous ne disposez que d’une heure, vous devez extraire le plus d’apprentissage possible. Tout le travail est contextuel. Votre travail pour maximiser le retour sur investissement consiste à découvrir, explorer et reconstruire le contexte dans lequel le travail est effectué dans un incident, comment il fonctionne et comment les gens pensent au-dessus de la ligne.

Les évaluations sont des compromis et elles sont contextuelles.

En conclusion, tous les incidents peuvent être pires. Une vue superficielle consiste à demander: «Qu'est-ce qui s'est mal passé? Comment ça s'est cassé? Que réparons-nous? »Ce sont des questions très raisonnables. Si nous devions prendre un niveau plus profond, et nous pourrions demander: «Quels sont les éléments qui ont contribué à rendre le processus moins aussi difficile qu'il aurait pu l'être?" Parce que nous ne faisons pas attention à ces éléments et ne les identifions pas ces choses, nous pourrions cesser de soutenir ces choses.

La raison pour laquelle la situation n’a pas empiré est peut-être parce que quelqu'un a appelé Lisa et que Lisa connaît son métier. La recherche a notamment permis aux experts de voir ce qui n’existait pas. Si vous n’appuyez pas Lisa et que vous n’indiquez même pas que la raison pour laquelle la situation n’a pas empiré est que Lisa était là. Oubliez les actions à entreprendre pour réparer quelque chose un instant. Imaginez un monde où Lisa va chercher un nouvel emploi.

Utile au niveau stratégique est une meilleure question. «Comment pouvons-nous soutenir, encourager, défendre et financer le processus continu de compréhension dans nos systèmes? Et vraiment prendre «au-dessus de la ligne» de manière soutenue?

Où allons-nous à partir d'ici? J'ai des défis pour vous:

  1. Faites circuler le rapport Stella dans votre entreprise et entamez un dialogue. Même si vous êtes trop occupé ou que vous n'êtes pas en mesure de le lire vous-même, donnez-le à ceux qui le font. Demandez-leur ce qui résonne. Demandez-leur ce qui n’a pas de sens. Demandez-leur de commencer un dialogue.
  2. Examinez attentivement la manière dont vous gérez les critiques post-événement. Plus important encore, allez chercher les personnes qui connaissent le mieux les détails compliqués du travail accompli et posez-leur la question suivante: «Quelle valeur pensez-vous que nos analyses actuelles après un incident ont réellement?» Et écoutez.
  3. Prenez la responsabilité d'apprendre plus rapidement des incidents que vos concurrents. Vous construisez une organisation d’apprentissage ou vous perdez au profit d’une autre.
  4. Nous devons prendre au sérieux la performance humaine. Cette discussion est en cours. Cela se passe dans le nucléaire. Cela se passe en médecine. Cela se passe dans l’aviation, le contrôle du trafic aérien, dans la lutte contre les incendies.

L’importance croissante de nos systèmes, le potentiel croissant de dommages économiques, politiques et humains quand ils ne fonctionnent pas correctement, ainsi que la multiplication des dépendances et de l’incertitude qui en découle, m’inquiètent énormément. Si vous examinez votre propre système et ses problèmes, je pense que vous conviendrez que nous devons faire beaucoup plus que reconnaître ce problème. Nous devons l'accepter. Ce que vous pouvez m'aider, veuillez diffuser ces informations, ces idées et ma présentation de DevOps Enterprise Summit San Francisco 2017.

Donne moi de tes nouvelles. Qu'est-ce qui a résonné avec vous à ce sujet? Qu'est-ce qui ne s'est pas passé? Quels défis rencontrez-vous dans votre organisation dans ce sens? Viens me le dire. Je suis sur Twitter.

Publié à l'origine sur itrevolution.com le 30 avril 2018.