À mesure que le monde de la technologie change, le langage change avec lui. Les nouvelles technologies introduiront toujours de nouveaux termes et descriptions pour fournir une compréhension claire. Par exemple, l’émergence du cloud a introduit un langage pour décrire la relation changeante entre les serveurs et les clients. Ensuite, bien sûr, les fournisseurs de produits dicteront également la manière dont leurs produits doivent être décrits, c’est-à-dire en décrivant les services comme « natifs du cloud ».
À d’autres occasions, le langage change par un effort délibéré pour influencer le comportement. Les leaders d’opinion inventent souvent des mots alternatifs pour décrire les idées existantes afin d’effectuer un changement culturel. Même un léger changement de diction peut affecter massivement l’engagement, l’attitude et même la vision du monde. Dans ce blog, nous verrons comment le langage colore la façon dont nous percevons nos environnements, et nous détaillerons trois exemples de la façon dont le langage a évolué dans la technologie.
Comment la langue affecte et modifie les perspectives mondiales
Nous avons tous des associations avec la langue. En raison de nos expériences passées et de notre culture, différents types de messages déclencheront différentes réponses émotionnelles. Le langage que nous utilisons influence donc notre façon de penser. Que nos associations soient positives ou négatives peut avoir un impact sur des choses telles que :
- Que nous redoutions quelque chose ou que nous soyons excités par cela
- À quel point nous percevons quelque chose comme étant important
- Si nous percevons quelque chose comme collaboratif ou combatif…
- Innovant ou hérité
- Bord de saignement ou grand public
- Sûr ou provocateur
« Post mortem » contre « Rétrospective »
Ces deux termes font référence à un document qui résume un incident passé et les mesures qui ont été prises pour le résoudre. « Postmortem » était à l’origine un terme médical datant des années 1820. L’usage métaphorique d’examiner d’autres choses après leur « mort » a été largement utilisé dans de nombreuses industries, y compris la technologie.
Ces dernières années, de nombreuses organisations différencient l’idée d’une rétrospective d’un post-mortem alors que l’état d’esprit culturel évolue vers l’apprentissage continu des événements et des échecs. Les deux pratiques sont généralement considérées comme ayant quelques petites différences, telles que le calendrier et le contenu des documents. Cependant, tout aussi importants que ces différences sont les effets psychologiques de la terminologie utilisée, en particulier lorsque ceux-ci peuvent être menés dans un environnement à haute pression.
Voici quelques-unes des raisons pour lesquelles nous utilisons « rétrospectif » au lieu de « post-mortem » :
La négativité des autopsies : la mort a une association négative dans l’esprit de la plupart des gens. Alors que les intervenants s’occupent des incidents, la connotation négative persiste. Les ingénieurs peuvent se sentir inquiets des conséquences d’un incident, et l’idée de « mort » entourant ce processus peut encourager des sentiments de culpabilité et de peur. En supprimant les associations négatives, les gens seront plus enclins à revoir et à revenir sur ce qui s’est réellement passé et à prendre le temps de le revoir en équipe.
La finalité des autopsies : wous ne considérons pas l’échec comme la fin. Nous y voyons une opportunité d’apprendre et de grandir, un point de départ pour un changement positif. Les autopsies sont très définitives ; aucun examen n’a lieu « post-mortem ». Une rétrospective implique que vous regardez en arrière quelque chose qui vient de se produire ou qui s’est produit il y a quelque temps, qui pourrait encore avoir un but dans le futur.
Le large champ des rétrospectives : une autopsie est définie par le seul moment de défaillance et fonctionne en arrière pour déterminer les causes. Une rétrospective ne s’intéresse pas seulement aux causes directes de l’échec. Au lieu de cela, il cherche à raconter l’histoire complète du service, des systèmes et des personnes, jusqu’à et au-delà de l’incident.
Nous voulons que nos rétrospectives d’incidents soient des documents auxquels nous sommes fiers de contribuer, qui servent de centres d’apprentissage et d’impulsion pour le changement à l’avenir. Nous pensons qu’en utilisant le mot « rétrospective », il traduit bien mieux cette intention que « post mortem ».
« Analyse des causes profondes » vs « Analyse des facteurs contributifs »
Pour déterminer pourquoi quelque chose a mal tourné, il existe plusieurs écoles de pensée concurrentes. L’analyse des causes profondes, ou RCA, est un outil populaire pour découvrir la raison de l’échec. L’idée d’une « cause racine » comme étant le principal facteur de défaillance remonte au début des années 1900, l’« analyse des causes profondes » étant apparue comme un concept dans les sociétés d’ingénierie dans les années 1930. Il est communément attribué à Kiichiro Toyota, fondateur de Toyota Motors Corporation, qui a développé la technique des cinq pourquoi pour trouver les causes profondes.
L’analyse factorielle contributive est un terme plus récent qui gagne en popularité. Il cherche aussi à comprendre les causes d’un incident, mais avec un état d’esprit différent. Cet état d’esprit se reflète dans la langue elle-même autant que dans toute pratique spécifique. Regardons quelques exemples de ces différences, et pourquoi nous pensons que l’analyse des facteurs contributifs est plus utile.
La singularité des RCA : la différence la plus évidente est qu’une analyse de cause racine se réfère à une cause racine singulière, où les facteurs contributifs mettent l’accent sur des facteurs multiples. C’est plus important qu’il n’y paraît. Si vous partez à la recherche d’une cause singulière, vous résisterez à l’idée de vous lancer dans d’autres domaines ayant un impact. Par exemple, si vous recherchez uniquement une cause d’ingénierie, vous ignorerez les facteurs découlant de la conception du produit ou de la culture d’équipe.
La hiérarchie des ACR : l’idée d’une cause « racine » est qu’elle est la source à partir de laquelle d’autres causes se développent et se ramifient. Comprendre quelles sont les causes les plus importantes de l’incident est nécessaire pour hiérarchiser correctement les éléments de suivi, mais ce n’est pas tout. Vous devez également considérer comment ces changements affecteront l’équipe et le système dans son ensemble. Penser à la contribution de chaque facteur sans essayer de déterminer quelle est la « racine » vous permet de rester plus ouvert d’esprit.
La neutralité de la contribution : lorsque vous examinez la cause d’un incident, vous serez enclin à trouver des échecs, des erreurs et d’autres choses négatives. Au lieu de cela, vous pouvez penser à chaque facteur qui a contribué à l’histoire de l’incident – y compris les choses qui se sont bien passées, comme des manuels utiles et une bonne communication. L’ensemble de cette analyse factorielle vous donne une image plus complète de la façon de répondre aux incidents à l’avenir.
Nous préconisons la SRE en tant que pratique holistique, qui intègre l’apprentissage de toutes les sources disponibles. L’analyse des facteurs contributifs fait appel à autant de sources que possible pour mieux comprendre les incidents.
« Reprise après sinistre » par rapport à « Réponse aux incidents »
Le processus global initié par quelque chose qui ne va pas a pris différents noms au fil des ans. Les attitudes des gens à cet égard ont changé parallèlement à l’évolution de la langue et de la terminologie. Au début, les organisations appelaient généralement cela la reprise après sinistre. Cette terminologie remonte aux années 1970, où elle se concentrait sur la façon dont les systèmes se rétabliraient si des catastrophes naturelles (ou autres) anéantissaient l’infrastructure et sa capacité à fonctionner.
À mesure que les systèmes informatiques sont devenus plus virtuels, les pannes ont commencé à être causées par un éventail beaucoup plus large d’aspects techniques autres que les catastrophes naturelles. Les organisations ont fait référence à ce processus comme une réponse à un incident pour refléter l’éventail de problèmes et de nouveaux processus et outils. De plus, les processus eux-mêmes ont évolué avec les changements technologiques. Voyons comment ces termes reflètent les attitudes de chaque époque et pourquoi nous utilisons maintenant la réponse aux incidents.
La singularité de la récupération : la réponse aux incidents, parfois appelée gestion des incidents, va bien au-delà de la simple restauration de l’environnement à son état antérieur. Une fois les services remis en ligne, vous devez toujours collecter des informations sur l’incident lui-même et créer une rétrospective, développer des éléments d’action pour faire avancer l’apprentissage et examiner l’efficacité des étapes et des procédures de réponse. La récupération n’est vraiment que la première étape vers la résolution et ne montre pas comment vous pouvez tirer le meilleur parti de l’apprentissage et de l’amélioration de chaque incident.
La gravité des catastrophes : les gens voient les catastrophes comme des événements catastrophiques majeurs. La mise en place de politiques et de procédures à déclencher uniquement en cas de « catastrophe » est une barre très haute. Cependant, votre processus de réponse aux incidents devrait fonctionner aussi efficacement pour tous les incidents. En d’autres termes, tous les incidents ne sont pas de « Sev 1 » et il est donc tout aussi important de connaître les bonnes mesures à prendre en fonction de chaque incident. Nous pensons qu’il y a un apprentissage dans chaque incident, et donc chaque incident mérite d’être traité correctement.
L’inévitabilité des incidents : les catastrophes sont également considérées comme quelque chose à éviter à tout prix.
Tout effort consacré à la réduction des risques de catastrophe serait justifié, compte tenu de la gravité des catastrophes tant pour les clients que pour les équipes d’ingénierie. Un objectif de zéro catastrophe est raisonnable. Cependant, nous savons qu’une fiabilité à 100 % est impossible. En reconnaissant le caractère inévitable des incidents, vous les acceptez et évitez de dépenser trop d’argent en infrastructure et autres ressources pour tenter de les prévenir. L’utilisation du terme « incidents » par rapport à « catastrophes » aide les membres de l’équipe à comprendre leur véritable inévitabilité et leur impact.