John Allspaw, cofundador do Adaptive Capacity Labs

Como seus sistemas continuam funcionando dia após dia

Primeiro, um pouco sobre John Allspaw, co-fundador do Adaptive Capacity Labs e ex-diretor de tecnologia da Etsy.

Como líder de engenharia e pesquisadora com mais de 20 anos de experiência na construção e liderança de equipes envolvidas em engenharia de software e sistemas, a Allspaw passou a última década unindo idéias de fatores humanos, engenharia de sistemas cognitivos e engenharia de resiliência ao domínio da engenharia de software e operações.

Também autor de dois livros, “A Arte do Planejamento de Capacidade: Escalando Recursos da Web” e “Operações da Web” (O'Reilly Media), a Allspaw continua contribuindo para as comunidades de TI e DevOps, falando e colaborando em novas e empolgantes pesquisas.

Tivemos a sorte de hospedar John no DevOps Enterprise Summit em San Francisco, onde ele subiu ao palco para falar sobre “Como os sistemas continuam funcionando dia após dia”. Abaixo, transcrevemos os principais tópicos e principais destaques de sua apresentação .

John Allspaw no DOES17 San Francisco

John Allspaw

Como seus sistemas continuam funcionando dia após dia

O que eu quero falar é novo. É diferente, e eu me sinto muito, muito fortemente sobre isso.

Para ajudar a preparar o cenário, minha tese para minha graduação em Fatores Humanos e Segurança de Sistemas foi “Compromissos sob Pressão: Heurísticas e Observações de Equipes que Resolvem Interrupções de Serviço na Internet”.

Alguns de vocês já devem ter ouvido falar disso, o que é chamado de Relatório Stella.

Em um nível alto, este relatório é o resultado de um projeto de um consórcio de parceiros do setor, que durou um ano. IBM, Etsy e IEX, empresa comercial, uma bolsa comercial em Manhattan. Ao longo deste ano, pessoas do Laboratório de Engenharia de Sistemas Cognitivos da Universidade Estadual de Ohio, David Woods, Richard Cook e várias outras pessoas analisaram profundamente um incidente em cada uma dessas organizações.

Eles encontraram esses seis temas e eram comuns em todos eles.

Certamente os resultados são bastante importantes. É como essa pesquisa foi realizada e quero que todos vocês dêem uma olhada.

Aqui estão minhas principais conclusões do relatório:

  1. Temos que começar a levar a sério o desempenho humano nesta indústria. Caso contrário, continuaremos a ver sistemas quebradiços com impactos cada vez maiores em nossos negócios e na sociedade.
  2. Podemos fazer isso observando incidentes que vão além do que fazemos atualmente em post-mortems, revisões pós-incidentes ou revisões pós-ação.
  3. Existem métodos e abordagens a partir do estudo da resiliência em outros domínios, mas eles exigem um compromisso real para prosseguir. Fazer isso é necessário e difícil, mas provará ser uma vantagem competitiva para as empresas que o fazem bem.

Primeiro, quero começar com um pouco de uma linha de base, um pouco de um vocabulário que será importante, à medida que passo a passo por você. Vou descrever uma espécie de imagem, uma representação, como um modelo mental de suas organizações, e ela terá uma região acima da linha e uma região abaixo da linha.

Se você imaginar o que descrevemos aqui, este é o seu produto, serviço, API ou o que a sua empresa obtém valor e fornece aos clientes. OK? Lá dentro, o que você vê é o seu código. Você vê sua pilha de tecnologia. Você vê os dados e várias maneiras de entregar isso, certo? Presumivelmente pela internet ou por outro meio. Mas se ficarmos aqui, ninguém vai acreditar em mim que é isso que chamamos de sistema, porque está tudo bem, mas não está realmente completo.

O que está realmente conectado e o que muita gente tem falado aqui na comunidade do DevOps Enterprise Summit são tudo o que fazemos para manipular o que acontece lá e, portanto, temos ferramentas de teste. Temos ferramentas de monitoramento. Temos ferramentas de implantação e todas as coisas que estão conectadas. Essas são as coisas que usamos. Você poderia dizer que esse é o sistema, porque muitos de nós gastamos nosso tempo focados naquelas coisas que não estão dentro da pequena bolha lá, mas em todas as coisas que a rodeiam, mas se fôssemos ficar com isso, não será capaz de ver onde o trabalho real acontece.

O que vamos fazer aqui é desenhar uma linha que chamamos de linha de representação e depois aprofundar um pouco mais. O que vemos aqui é você. Todas as pessoas que estão preparando coisas para adicionar ao sistema, para mudar o sistema. Você está fazendo o enquadramento arquitetônico. Você está monitorando. Você acompanha o que está fazendo, como está fazendo e o que está acontecendo com eles.

Agora, você notará que cada uma dessas pessoas tem algum tipo de representação mental sobre o que é esse sistema. Se você olhar um pouco mais de perto, verá que nenhum deles é o mesmo. A propósito, isso é muito característico desses tipos de papéis. Ninguém tem a mesma representação do que está abaixo da linha.

Para resumir, este é o nosso modelo de mundo, e inclui não apenas as coisas que estão sendo executadas lá, mas todos vocês, os tipos de atividades que estão realizando, o trabalho cognitivo que estão fazendo para manter o mundo funcionando . Se jogarmos um pouco mais com isso, acabamos com esse tipo de modelo. Este modelo tem uma linha de representação passando pelo meio e você interage com o mundo abaixo da linha por meio de um conjunto de representações.

Suas interações nunca são com as próprias coisas. Você realmente não muda os sistemas.

O que você faz é que você interage com a representação e essa representação é algo sobre o que está acontecendo abaixo. Você pode pensar nessas coisas verdes como as telas que você vê durante o dia, mas as únicas informações que você tem sobre o sistema vêm dessas representações. Eles são apenas um pequeno buraco da fechadura. Direito?

O que é significativo nisso é que todas as atividades que você realiza, todas as observações, inferências, antecipações, planejamentos, correções, todo esse tipo de coisa precisam ser feitas por meio dessas representações, para que haja um mundo acima da linha e um mundo abaixo da linha, e embora você e nós conversemos principalmente sobre o mundo abaixo da linha como se fosse muito real, como se fosse muito concreto, como se fosse algo assim, aqui está a surpresa.

Aqui está o grande negócio - você nunca consegue vê-lo.

Isso não existe. Em um sentido real, não há abaixo da linha que você possa tocar. Você nunca vê o código sendo executado. Você nunca vê o sistema realmente funcionar. Você nunca toca nessas coisas.

O que você faz é manipular um mundo que não pode ver por meio de um conjunto de representações, e é por isso que você precisa construir esses modelos mentais, essas concepções, esses entendimentos sobre o que está acontecendo. Essas são as coisas que estão dirigindo essa manipulação. Não é o mundo abaixo da linha que está fazendo isso. É sua capacidade conceitual de entender as coisas que aconteceram no passado, as coisas que você está fazendo agora e por que você está fazendo essas coisas, o que importa e por que o que importa realmente importa.

Depois de adotar essa perspectiva, você se afasta de que a ideia de que está abaixo da linha é a coisa com a qual está lidando e entende que realmente está trabalhando acima da linha, todo tipo de coisa muda.

O que você vê no Relatório Stella e o projeto e outros projetos com os quais nos envolvemos é levar essa visão e entender o que realmente significa levar o mundo acima da linha a sério. Esta é uma grande partida de muito do que vocês já viram no passado, mas acho que é uma direção proveitosa que precisamos tomar.

Em outras palavras, essas atividades cognitivas (veja abaixo) em indivíduos e coletivamente em equipes de alto a baixo da organização são o que faz o negócio realmente funcionar. Agora, estou estudando isso em detalhes há um bom tempo, e posso lhe dizer isso. Não funciona da maneira que pensamos.

Por fim, para configurar esse quadro, a parte mais importante dessa idéia é que tudo isso muda com o tempo. É um processo dinâmico que está em andamento. Esta é a unidade de análise. Depois de entendermos esse quadro, podemos fazer algumas perguntas. Podemos fazer algumas perguntas acima da linha como esta.

"Como nosso software realmente funciona, em comparação com o descrito no wiki, na documentação e nos diagramas? Sabemos que eles não são abrangentes, não são totalmente precisos. "

"Como nosso software realmente se quebra, contra o que pensávamos que seria quebrado quando projetamos salvaguardas, disjuntores e grades de proteção?"

"O que fazemos para manter tudo funcionando?"

Pergunta: Imagine sua organização. O que aconteceria se hoje às seis horas todas as suas empresas tirassem as mãos do teclado? Eles não respondem a nenhuma página. Eles não olham para nenhum alerta. Eles não tocam em nenhuma parte dele, no código ou nas redes de aplicativos ou em nada. Você tem certeza de que seu serviço estará em funcionamento após um dia?

A questão então é como descobrir o que acontece acima da linha. Bem, há algumas coisas. Podemos aprender com o estudo de outros domínios de alto andamento e consequências, e, se o fizermos, podemos ver que podemos estudar incidentes. (Observação: quando digo "incidentes", quero dizer interrupções, degradações, violações, acidentes, quase acidentes e falhas - basicamente eventos indesejáveis ​​ou inesperados).

O que torna os incidentes interessantes? Bem, o óbvio é a perda de receita e impacto na reputação de um negócio em particular. Quero afirmar algumas outras razões pelas quais os incidentes são interessantes. O primeiro é que os incidentes moldam o design de novos subsistemas e arquiteturas de componentes. Em outras palavras, os incidentes de ontem informam as arquiteturas de amanhã. Ou seja, os incidentes ajudam a alimentar nossa imaginação sobre como melhorar nossos sistemas e, portanto, o que quero dizer é que os incidentes abaixo da linha geram mudanças acima da linha.

Essa e a coisa. Isso pode custar dinheiro real. Os incidentes podem ter efeitos quase tácitos ou invisíveis, às vezes significativos. No momento, muitas pessoas estão dividindo um monólito em microsserviços. Muitas pessoas fazem isso porque fornece uma certa robustez que você não tem. De onde você tira isso?

Você é informado por incidentes.

Outro motivo para observar os incidentes é que eles tendem a dar origem a novas formas de regulamentos, políticas, normas, conformidade, auditoria, restrições etc. Outra maneira de dizer isso é que os incidentes de ontem informam as regras de amanhã, que influenciam o pessoal , orçamentos, planejamento, roteiros e muito mais. Deixe-me dar um exemplo: nas negociações financeiras, a SEC implementou o Regulamento SCI. A SCI é provavelmente a parte mais abrangente e detalhada da conformidade na era moderna do software. A SEC se foi e foi muito explícita. Temos isso como uma reação ao flash crash de 2010 para Knight Capital, BATS IPO, Facebook IPO. É uma reação a incidentes.

Mesmo se você voltar um pouco mais longe, muitas vezes é citado que o PCI DSS surgiu quando a MasterCard e a Visa compararam notas, perceberam que perderam cerca de US $ 750 milhões em dez anos, para que os incidentes tenham um impacto significativo e, a propósito, como ex-CTO de uma empresa pública, posso garantir que esse é um albatroz muito caro, perturbador e inevitavelmente pesado para todas as suas organizações. Os incidentes também são significativos dessa maneira, mas se pensarmos em incidentes como oportunidades, se pensarmos em incidentes como mensagens, mensagens codificadas que estão abaixo da linha que estão sendo enviadas acima da linha e seu trabalho é decodificá-las, se você pensar em incidentes como coisas que ativamente tentam chamar sua atenção para partes do sistema que você pensava ter um entendimento suficiente, mas não sabia, esses são lembretes de que você deve reconsiderar continuamente a confiança que tem sobre como tudo funciona.

Agora, se você adota essa visão, um monte de coisas se abre. Há uma oportunidade para novos treinamentos, novas ferramentas, novas estruturas organizacionais, novas dinâmicas de financiamento e possivelmente insights que seus concorrentes não possuem.

Os incidentes nos ajudam a avaliar o delta entre como o sistema funciona e como achamos que o sistema funciona, e esse delta é quase sempre maior do que imaginamos. Quero afirmar talvez uma abordagem diferente à qual você esteja acostumado, e é isso. Incidentes são investimentos não planejados na empresa, na sobrevivência da sua empresa. São oportunidades imensamente valiosas para entender como o sistema funciona, quais vulnerabilidades existem e quais vantagens competitivas você não está buscando.

Se você pensar em incidentes, eles gastam dinheiro, tempo, reputação, funcionários etc. Esses são custos irreversíveis inevitáveis. Algo interessante sobre esse tipo de investimento, no entanto. Você não controla o tamanho do investimento, portanto, a pergunta permanece: como você maximizará o ROI desse investimento?

Quando analisamos os incidentes, esse é o tipo de pergunta que ouvimos e é bastante consistente com o que os pesquisadores encontram em outros sistemas complexos, domínios. O que esta fazendo? Por que ele está fazendo isso? O que vai fazer a seguir? Como chegou a esse estado? O que está acontecendo? Se fizermos Y, isso nos ajudará a descobrir o que fazer? Está piorando? Parece que está consertado, mas não é? Se fizermos X, isso impedirá que piore ou piore? Quem mais devemos chamar que pode nos ajudar? Esse é o nosso problema ou estamos sendo atacados? Isso é consistente com muitos outros campos. Aviação, controle de tráfego aéreo, especialmente em domínios ricos em automação.

Outra coisa que é notável é que, no início de qualquer incidente, muitas vezes é incerto ou ambíguo se esse é o que nos afunda ou não. No início de um incidente, simplesmente não sabemos, especialmente se ele contém grandes quantidades de incerteza e grandes quantidades de ambiguidade. Se é incerto e ambíguo, significa que esgotamos nossos modelos mentais. Eles não se encaixam no que estamos vendo, e essas perguntas surgem. Só a retrospectiva nos dirá se foi esse o evento que derrubou a empresa ou se foi uma tarde difícil de terça-feira.

Os incidentes fornecem calibração sobre como as decisões são focadas, sobre como a atenção é focada, sobre como a coordenação é focada, sobre como a escalada é focada. O impacto da pressão do tempo, o impacto da incerteza, o impacto da ambiguidade e as consequências das consequências. A pesquisa valida essas oportunidades.

"Devemos considerar profundamente os incidentes como" eventos desafiadores não rotineiros, porque esses casos difíceis têm o maior potencial para descobrir elementos de especialização e fenômenos cognitivos relacionados ".
- Gary Klein, o criador da pesquisa naturalista sobre tomada de decisão.

Há uma família de métodos, abordagens e técnicas usadas. Análise de tarefas cognitivas. Rastreamento de processo. Análise conversacional. O método de decisão crítica. Como achamos que os postmortems têm valor se parece um pouco com isso:

Um incidente acontece. Talvez alguém crie uma linha do tempo. Temos um pouco de reunião. Talvez você tenha um modelo e o preencha, e então alguém possa fazer um relatório ou não, e então você tem, sim, itens de ação, finalmente. Achamos que o maior valor, talvez o menor valor, é onde você está em um interrogatório e as pessoas estão andando na linha do tempo e você fica tipo: "Oh, meu Deus. Nós sabemos tudo isso.

Não é isso que a pesquisa confirma. A pesquisa confirma que, se coletarmos dados subjetivos e objetivos de vários lugares, dados comportamentais, o que as pessoas disseram, o que as pessoas fizeram, para onde procuraram, que avenidas no diagnóstico elas seguiram e não foram proveitosas? Discussões bem facilitadas levam as pessoas a contrastar e comparar seus modelos mentais que são necessariamente falhos. Você pode produzir resultados diferentes, incluindo itens como bootcamp, materiais de integração e treinamento para novos contratados. Você pode obter feedback de facilitação se criar um programa para treinar facilitadores. Você pode fazer alterações no roteiro, alterações realmente significativas com base no que aprendeu.

Eu posso lhe dizer isso com alguma experiência. Não há nada mais perspicaz para um novo engenheiro ou um engenheiro que está começando na carreira do que estar em uma sala com um engenheiro veterano que conhece todos os cantos e recantos explicando coisas que eles talvez nunca tenham dito em voz alta. Eles têm conhecimento. Eles podem desenhar figuras e diagramas que nunca fizeram antes, porque acham que todo mundo sabe disso. Adivinha? Eles não. O maior valor está realmente aqui, porque a qualidade desses resultados depende da qualidade disso, da recalibração. Esta é uma abertura para recalibrar modelos mentais.

A partir do Relatório Stella, "informa e recalibra os modelos das pessoas sobre como o sistema funciona, seus entendimentos de como é vulnerável e quais oportunidades estão disponíveis para exploração".

Em muitas pesquisas, em todas as pesquisas contidas no Relatório Stella, e isso se encaixa com a minha experiência no Etsy, uma das mais fortes da reflexão de pessoas que fazem isso de maneira facilitada para fazer isso, comparando e contrastante. "Eu não sabia que funcionava dessa maneira". Depois, há sempre outro: "Como isso funcionou?" O que é engraçado até você perceber que é sério. O que isso significa é que, não só pensei que funcionava de maneira diferente. Agora, eu nem consigo imaginar, nem consigo desenhar em minha mente como isso poderia ter funcionado. Isso deveria ser mais perturbador. A propósito, quero dizer que isso não é alinhamento. Como eu disse, por meio de representações, temos necessariamente modelos mentais incompletos. A idéia é não ter os mesmos modelos mentais, porque eles estão sempre incompletos, porque as coisas estão sempre mudando e porque serão falhas. Não queremos que todos tenham o mesmo modelo mental, porque todos têm os mesmos pontos cegos.

Sem culpa - voltando ao post que escrevi em 2012

"Irrepreensível" são apostas em mesa. É necessário, mas não é suficiente. Você pode criar um ambiente, uma cultura, uma organização acolhedora, que suporte e permita que as pessoas contem histórias com todos os detalhes confusos, às vezes detalhes embaraçosos, sem medo de retribuição, para que você possa realmente progredir e para entender o que está acontecendo, você pode configurar essa condição e ainda não aprender muito. Não é suficiente. É necessário, mas não suficiente. O que estou falando é muito mais esforço do que as revisões típicas pós-incidentes. Direito? É aqui que um analista, um facilitador pode preparar, agrupar, organizar e analisar dados comportamentais. O que as pessoas dizem, o que as pessoas fazem. Há uma grande quantidade de dados que eles podem filtrar para preparar interrogatórios, interrogatórios em grupo ou de um para um, indo além ... Pós-morte sugerem a riqueza dos incidentes. O acompanhamento disso exige muito trabalho.

A propósito, todos geralmente ficam tão exaustos após uma interrupção, incidente ou evento realmente estressante que, às vezes, tudo se torna claro. Esse é o poder da retrospectiva e, porque parece tão claro como cristal, não parece produtivo ter um interrogatório, porque você acha que já sabe tudo. A outra questão é que os briefings post-mortem também são limitados pelo tempo. Você só tem a sala de conferências por uma ou duas horas. Todo mundo está realmente ocupado e o tempo está passando, então esse é um desafio para fazer isso muito bem, mesmo considerando esses métodos de pesquisa.

A outra questão, especialmente se você criar um programa de treinamento de facilitação de perguntas, como eu fiz no Etsy, ainda existem desafios que aparecem. O que eu gosto de chamar é: "Todo mundo tem seu próprio mistério a resolver" ou "Não desperdice meu tempo com detalhes que eu já conheço". De uma maneira caricatural, você pode pensar assim:

Como você pode ter apenas uma hora, precisa extrair o máximo de aprendizado possível. Todo o trabalho é contextual. Seu trabalho para maximizar o ROI é descobrir, explorar e reconstruir o contexto em que o trabalho é realizado em um incidente, como funciona e como as pessoas pensam acima da linha.

As avaliações são compensações e são contextuais.

No fechamento, todos os incidentes podem ser piores. Uma visão superficial é perguntar: “O que deu errado? Como isso quebrou? O que consertamos? ”Essas são perguntas muito razoáveis. Se tivéssemos um nível mais profundo, e pudéssemos perguntar: "Quais são as coisas que levaram a torná-lo não tão ruim quanto poderia ter sido?" Porque não prestamos atenção a essas coisas e não identificamos essas coisas, podemos parar de apoiar essas coisas.

Talvez a razão pela qual não tenha piorado seja porque alguém ligou para Lisa, e Lisa conhece as coisas dela. Algo da pesquisa é que os especialistas podem ver o que não existe. Se você não apoia Lisa e nem identifica que a razão pela qual não piorou é porque Lisa estava lá. Esqueça os itens de ação para consertar algo por um momento. Imagine um mundo onde Lisa vá para um novo emprego.

Útil em nível estratégico é uma pergunta melhor. “Como podemos apoiar, incentivar, advogar e financiar o processo contínuo de entendimento em nossos sistemas? E realmente assumir "acima da linha" de forma sustentada?

Para onde vamos daqui? Eu tenho alguns desafios para você:

  1. Circule o Relatório Stella na sua empresa e inicie um diálogo. Mesmo se você estiver muito ocupado ou não estiver em condições de lê-lo, dê para as pessoas que o fazem. Pergunte a eles o que ressoa. Pergunte a eles o que não faz sentido. Pergunte a eles, inicie um diálogo.
  2. Veja profundamente como você está lidando com as análises pós-evento. Mais importante, encontre as pessoas que estão mais familiarizadas com os detalhes confusos de como o trabalho é realizado e pergunte-lhes o seguinte: “Qual é o valor que você acha que as nossas atuais avaliações pós-incidentes realmente têm?” E ouça.
  3. Assuma a responsabilidade de aprender mais e mais rapidamente com os incidentes do que seus concorrentes. Você está construindo uma organização de aprendizagem ou está perdendo para quem é.
  4. Precisamos levar o desempenho humano a sério. Esta discussão está acontecendo. Está acontecendo na energia nuclear. Está acontecendo na medicina. Está acontecendo na aviação, controle de tráfego aéreo e combate a incêndios.

A crescente importância de nossos sistemas, o crescente potencial de danos econômicos, políticos e humanos quando eles não funcionam corretamente e a proliferação de dependências e incertezas associadas me deixam muito preocupado. Se você olhar para o seu próprio sistema e seus problemas, acho que concorda que precisamos fazer muito mais do que reconhecer esse problema. Temos que abraçar isso. Com o que você pode me ajudar, espalhe essas informações, essas idéias e minha apresentação do DevOps Enterprise Summit San Francisco 2017.

Eu quero ouvir de você. O que ressoou com você sobre isso? O que não aconteceu? Que desafios você enfrenta em sua organização nesse sentido? Venha me dizer. Estou no twitter

Publicado originalmente em itrevolution.com em 30 de abril de 2018.