Chaos engineering, rodando game days, e empresas que aprendem: Entrevistas na Chaos Conf

O segundo Chaos Conf aconteceu em São Francisco nos dias 25 e 26 de setembro, e o InfoQ fez alguns resumos dos pontos principais do evento. Antes da conferência, o InfoQ conversou com alguns palestrantes para discutir tópicos como a evolução e adoção do chaos engineering, os aprendizados mais importantes relacionados a pessoas e processos ao executar experimentos de chaos, e os principais obstáculos para a adoção em larga escala pelas empresas.

Os leitores que estiverem interessados em continuar suas jornadas de aprendizado sobre chaos engineering podem encontrar o resumo do recente Chaos Community Day v4.0, a eMag sobre chaos engineering, e um sumário de várias apresentações da QCon sobre sistemas resilientes.

InfoQ: Muito obrigado por participar da entrevista do pré-evento do Chaos Conf 2019. Poderia se apresentar, por favor?

Jason Yee: Oi, sou um evangelista técnico sênior na Datadog. A Datadog é uma plataforma de observabilidade SaaS que permite aos desenvolvedores, aos times de operações, e aos times de negócio que tenham uma melhor visão sobre a experiência do usuário e a performance das aplicações.

Caroline Dickey: Oi! Sou uma engenheira SRE na Mailchimp, um plataforma de marketing unificada para pequenos negócios. Construo ferramentas e configurações para dar suporte à velocidade dos engenheiros, desenvolvo SLOs para promover a saúde das aplicações, e também lidero a iniciativa de chaos engineering na Mailchimp.

Joyce Lin: Olá! Sou uma developer advocate na Postman, uma plataforma de desenvolvimento de APIs amplamente utilizadas na comunidade de desenvolvimento. Trabalho com empresas que estão liderando na melhoria das práticas de desenvolvimento de software.

Robert (Bobby) Ross: Meu nome é Robert Ross, mas as pessoas me chamam de Bobby Tables depois de uma tirinha popular da XKCD. Sou um entusiasta por tecnologia de ponta, então gosto das dores de tentar coisas novas. Sou o CEO da FireHydrant, uma ferramenta de resposta a incidentes.

Kolton Andrus: Sou CEO e co-fundador da Gremlin. Iniciei no desenvolvimento de sistemas resilientes na Amazon, onde minha equipe ficava a cargo da disponibilidade do website da loja. Construí a primeira "plataforma de chaos engineering" deles (quando ainda nem existia este termo) e ajudei outros times a fazer seus primeiros experimentos. Depois, entrei na Netflix, que tinha acabado de começar a escrever sobre o assunto. Tive a oportunidade de desenvolver a próxima geração de testes de injeção de falhas (FIT, fault-injection testing, no inglês), e trabalhei com todos times críticos de streaming para melhorar a disponibilidade, que foram de três para quatro noves de uptime (99.99%). Depois de ver o valor entregue à Amazon e Netflix, senti fortemente que todos precisariam dessa abordagem e das ferramentas para suportar tudo isso, foi aí que fundei a Gremlin.

Yury Niño: Oi, sou engenheiro de software na Universidade Nacional da Colômbia. Atualmente, estou trabalhando como engenheiro DevOps na Aval Digital Labs, uma iniciativa que lidera a transformação digital de um grupo de bancos em meu país.

Também sou um chaos engineer advocate. Amo quebrar aplicações, desenhar estratégias de resiliência, executar experimentos em produção e resolver problemas difíceis de performance. Estou estudando como erros humanos e a falta de observabilidade estão envolvidos na segurança dos sistemas de software. No momento, estou liderando a iniciativa de criar a primeira comunidade de chaos na Colômbia. Estamos construindo a Gaveta, um app mobile para dar suporte à execução dos game days.

Jose Esquivel: Oi, sou gerente de engenharia na Backcountry.com onde trabalho dentro do gerenciamento da cadeia de suprimentos para as equipes de fulfillment, marketing e conteúdo. Eles rodam 65 APIs que interagem com nossa rede, com sistemas de terceiros, e com APIs públicas. Minha responsabilidade, de uma perspectiva técnica, é garantir que essas APIs são estáveis e que novas funcionalidades sejam entregues a tempo.

Subbu Allamaraju: Sou VP na Expedia Group. Meu trabalho começou com a iniciação de uma estratégia de migração da plataforma de viagens para a nuvem. Nessa época, utilizei muito do tempo para sustentar a velocidade desta transformação e, mais importante, nos estruturar para a excelência operacional. Sinto que há muito o que aprender com os outros, então escrevo em meu blog https://subbu.org e apresento em conferências.

Dave Rensin: Olá! Sou um diretor de engenharia sênior no Google. Atualmente trabalho em projetos estratégicos para nosso CFO. Na Google, pude gerenciar o suporte a clientes, parte do SRE, e a rede global de planejamento de capacidade.

Paul Osman: Gerencio o time de SRE na Under Armour Connected Fitness. Minha equipe trabalha nos produtos MyFitnessPal, MapMyFitness e Endomondo. Antes da Under Armour, trabalhei na Pagerduty, SoundCloud, 500px, e Mozilla. Na maior parte da minha carreira naveguei entre os mundos de operações e desenvolvimento de software, então naturalmente me encontrei indo em direção ao mundo SRE. No últimos anos, tenho trabalhado com chaos engineering em muitas empresas.

InfoQ: Como o chaos engineering evoluiu no último ano? E a adoção dele? O chaos engineering já é mainstream?

Yee: Não acredito que o chaos engineering evoluiu de fato. Os conceitos ainda são os mesmos, mas o entendimento evoluiu. Os engenheiros estão começando a aprender que é uma prática baseada em princípios de experimentação e compartilhamento de informações, não um folclore de ataques completamente randômicos. À medida que o mito se desfaz e as melhores práticas são estabelecidas, a adoção se torna mais acelerada. O chaos engineering não é mainstream ainda, mas certamente já passamos do estágio de "inovação" e estamos no segmento dos "primeiros adeptos" na curva de adoção.

Dickey: A resposta e a mitigação de incidentes estão se tornando cada vez mais importantes e cada vez mais priorizados dentro das empresas. As aplicações estão se tornando mais complexas, falhas cada vez mais caras, e os consumidores cada vez menos tolerantes a falhas. É fascinante ver que a tendência nos últimos anos tem sido o afastamento em encontrar a causa raiz e a busca dos culpados, para ir em direção a um pensamento na qual incidentes são a tempestade perfeita. O chaos engineering é a contraparte ideal para esta mudança no paradigma da indústria porque permite aos engenheiros identificar e corrigir os problemas, que poderiam levar a falhas em cascata, antes mesmo que eles ocorram.

O chaos engineering é mainstream em grandes empresas e em empresas com a cultura de serem os primeiros adeptos, mas ainda está procurando o seu lugar dentro de pequenas e médias empresas. Entretanto, é uma tendência que está para ficar, pois os sistemas não estão ficando menos distribuídos, e humanos não estão ficando menos propensos a errar! Eu estou animado em ver como as práticas e a adoção do chaos engineering será nos próximos anos - é uma época divertida para fazer parte desta indústria.

Lin: Acredito que o chaos engineering ainda é uma novidade que a maioria das equipes pensam em implementar. Depois que um time cobriu todas as bases, quando é hora dos testes de pré release, então os primeiros experimentos de chaos engineering se tornam muito mais possíveis.

Ross: Um grande ponto que vejo no movimento de chaos engineering é a popularização dos game days. Não é um conceito totalmente novo, mas tenho visto e ouvido mais e mais empresas praticando. As pessoas estão percebendo que na realidade já possuem esses ambientes de staging, onde o software é testado antes do release, então porque não testar os processos de resposta a incidentes neste ambiente também? Empresas grandes tem feito isto há anos, mas empresa menores estão praticando cada vez mais.

Andrus: Há poucos anos atrás, havia frequentemente a necessidade de explicar porque o chaos engineering era importante. Agora, a maioria das equipes que estão em operações sérias entendem o valor e apenas necessitam de alguma ajuda para começar. Os primeiros adeptos da prática estão conseguindo muito sucesso e estão tentando escalar isso por toda a empresa. A grande maioria ainda está testando em alguns projetos ou equipes antes de adotá-lo de maneira mais holística.

Niño: Acredito que o chaos engineering tem evoluído a velocidades impressionantes em pouco espaço de tempo. Em 2016, os autores do clássico artigo "Chaos Engineering" perguntavam se seria possível construir ferramentas para a automação de injeção de falhas que poderiam ser utilizadas nas empresas. Atualmente, três anos depois, temos mais de 20 ferramentas de chaos engineering e muitas empresas estão utilizando-as para entregar sistemas mais confiáveis em produção.

De acordo com o último Technology Radar, publicado pela ThoughtWorks, o chaos engineering mudou de "uma ideia muito comentada" para uma abordagem aceita e mais utilizada para melhorar e assegurar a resiliência em sistemas distribuídos.

Esquivel: Os negócios online cresceram em questão de carga e, para os e-commerces, a maioria do tráfego é focado em apenas algumas semanas do ano. Isso significa que durante o período de tráfego alto a estabilidade é diretamente proporcional aos ganhos da empresa. A adoção de testes unitários, integrados, de segurança, de carga e, finalmente, de chaos se tornaram uma missão crítica. A adoção tem aumentado e, temos certeza que necessitamos do chaos engineering. Agora, precisamos de tempo para amadurecer essa tecnologia.

Allamaraju: Ainda não.

Embora este tópico já tenha mais ou menos uma década, o entendimento que levou à ideia do chaos engineering ainda é nova na indústria.

Isto é o que penso. Poucos de nós enxergamos o software que operamos em produção como sendo sistemas estocásticos e não lineares, e que trazem um número de suposições a nossos sistemas a cada mudança que fazemos. Consequentemente, quando as equipes adotam o chaos engineering, começam a testar sistemas de operações e rede, e falhas no nível da aplicação através de várias ferramentas, mas não o suficiente para aprender sobre segurança.

Ainda que a maioria do trabalho que entregamos em produção pareça ser benigno, às vezes esse trabalho pode levar os sistemas a zonas inseguras, nos impedindo de entregar o valor que os consumidores querem e necessitam. Então o aprendizado que tiramos dos incidentes, antes de mergulhar em chaos engineering, é realmente muito importante.

Rensin: Acredito que o chaos engineering sempre foi mainstream. Nós apenas o chamávamos por outros nomes. Se consumidores encontram um erro antes de nós, chamamos isso de "suporte ao cliente". Se nossa provedora de telecomunicações encontra um erro antes de nós, chamamos isso de "má sorte". Isso, acredito, é a maior mudança no último ano. À medida que mais pessoas descobrem o que é o chaos engineering, mais estão descobrindo que já o praticam, ou precisam praticar.

Osman: O interesse no assunto tem aumentado muito mas muitas empresas ainda sofrem ao tentar iniciar esse processo. Acredito que seja porque não há bala de prata. O chaos engineering existe dentro de uma matriz de capacidades que juntas podem ser realmente efetivas, mas sem ferramentas como a observalidade, um bom processo de resposta a incidentes, e postmortems blameless, não conseguiremos bons resultados.

Basicamente, se não estamos em uma empresa que aprende, não há razão em realizar experimentos e, então, o chaos engineering não irá nos ajudar. O lado bom é que mais e mais pessoas estão percebendo que os sistemas modernos são complexos e que não podemos prever todas as falhas. Apenas os testes das equipes de QA nos ambientes de staging não é o suficiente, por isso o interesse em chaos engineering. Acredito que tudo isso significa que sim, o chaos engineering já é mainstream.

InfoQ: Qual o maior obstáculo ao adotar as práticas do chaos engineering?

Yee: O maior obstáculo, como a maioria das mudanças tecnológicas, são as pessoas. Obter a aprovação dos líderes para intencionalmente quebrar os sistemas em produção é algo muito difícil de se vender, especialmente sem um claro entendimento dos riscos e benefícios ao negócio. Criar uma estratégia sólida para gerenciar o impacto dos testes, garantir que os pontos fracos encontrados sejam melhorados e que exista a comunicação dos valores ao negócio, são pontos chave para ganhar o apoio dos líderes.

Dickey: A mudança cultural. Fazer com que os engenheiros priorizem e valorizem testes destrutivos, que adicionam mais trabalho aos seus backlogs, tem sido a parte mais desafiadora na adoção de chaos engineering na Mailchimp. Planejar um game day ou implementar a automatização de chaos engineering requer, no mínimo, várias horas de pré-trabalho e, sem ter um time dedicado para isso, fazer com que uma equipe planeje os cenários pode parecer que estamos indo no sentido contrário ao movimento natural do time.

Então é importante lembrar que cada norma de engenharia necessitou de uma mudança cultural, seja a adoção de testes unitários, code reviews, daily stand ups, ou home office. Desde que o programa de chaos engineering na Mailchimp foi amplamente iniciado pela equipe de SRE, tivemos que utilizar tech talks, newsletters internos, conversar com as equipes diretamente, e fazer os game days divertidos, recomendamos trazer cupcakes. Tudo isto para possibilitar o engajamento do departamento de engenharia.

Lin: Um problema comum é a falta de comunicação clara sobre as razões pelas quais o chaos engineering está sendo adotado. Quando o resto da empresa ainda não entende ou não acredita nos benefícios, haverá medo e confusão. Pior ainda, há frequentemente a percepção que as coisas estão sendo quebradas de forma aleatória e sem uma hipótese legítima.

Ross: É necessário um incentivador do processo. É fácil continuar fazendo o que estamos fazendo, simplesmente porque isso é o que sempre fizemos. É necessário um defensor do chaos engineering. De certo modo, acredito que o termo "chaos engineering" pode assustar algumas pessoas e afastá-las de ao menos tentar, por isso, é necessário um indivíduo, ou alguns, para realmente explicar o valor para o resto da equipe e ter todos no mesmo barco. Fazer com que comprem a ideia pode ser bem difícil.

Andrus: Acredito que muitas pessoas entendem o conceito geral, mas subestimam o valor que pode prover aos negócios. Elas enxergam como uma atividade a mais a se fazer, ao invés de uma maneira de ganhar tempo nos projetos atuais, seja na migração para a nuvem ou adotando um novo serviço como o Kubernetes. Frequentemente, a confiabilidade dos sistemas é algo que sempre fica para depois, por isso estamos colocando o esforço em educar o mercado e explicar o valor de pensar nisso logo nos esforços iniciais dos projetos.

Niño: Tenho passado por muitos obstáculos. Entender como construir sistemas resilientes passa por software, infraestrutura, rede e dados. Entretanto, acredito que o maior desafio é a mudança cultural.

Na minha experiência, obter a aprovação dos clientes para experimentar em seus sistemas é algo difícil. Quando falamos sobre chaos engineering, ficam animados no princípio. Por exemplo, ouvimos expressões como "se as principais empresas estão fazendo isso, deveríamos fazer também". Entretanto, quando os conceitos fundamentais são compreendidos, dizem coisas como: "Não vamos causar falhas em nossa produção".

Por outro lado, acredito que seja importante mencionar que também existem limitações. É necessário deixar claro que o chaos engineering por si só não vai fazer com que os sistemas sejam mais maduros, e que isto é uma missão para as pessoas que estão desenvolvendo os sistemas. O chaos engineering nos permite conhecer como os sistemas reagem em condições turbulentas em produção e aumenta a confiança na sua capacidade, mas desenvolver as estratégias é nossa responsabilidade. A disciplina não é uma caixa mágica que gera soluções para nossas fraquezas.

David Woods tem um excelente argumento sobre isso: "Expandir a habilidade do sistema em suportar alguma perturbação a mais, aumenta a vulnerabilidade em outros tipos de eventos de outras maneiras. Isto é um tradeoff fundamental nos sistemas adaptativos complexos".

Esquivel: As empresas devem ter um bom conhecimento de TI para superar os maiores obstáculos em adotar o chaos engineering, que é a falta de cultura em dar alta prioridade à estabilidade. A alta gerência deve entender de tecnologia e saber que, investir em qualidade se traduz em entregar soluções efetivas de longo prazo. Entregar as funcionalidades não é o suficiente, devemos garantir também que os seguintes requisitos não funcionais são parte da solução: Manutenibilidade e consistência através de testes unitários e integrados, performance através de testes de carga, e estabilidade através de testes de chaos engineering, por exemplo.

Allamaraju: Os principais desafios, na minha opinião, é entender o racional por trás das práticas de chaos engineering, desenvolver uma cultura de operar sistemas de forma segura e articular qual o valor relativo de tais práticas contra todo o resto do trabalho. Não é possível alcançar o sucesso com chaos engineering se não conseguimos articular e criar hipóteses para demonstrar o valor que esta metodologia pode trazer.

Uma vez que esses obstáculos são ultrapassados, a prática do chaos engineering acontece naturalmente.

Rensin: Abrir mão da perfeição. Muitas pessoas acreditam que o principal ponto em desenvolver sistemas é não cometer erros. Uma vez que a ideia de que um grande sistema é resiliente, e não perfeito, então o chaos engineering acontece naturalmente.

Osman: Acredito que a confiança é o principal obstáculo. Temos que ter uma cultura na qual os times confiam uns nos outros e os stakeholders que não fazem parte da engenharia confiam que as equipes de engenharia têm o interesse do cliente em mente. Esta confiança é extremamente importante, pois se os times temerem o que possa acontecer se as coisas não ocorrerem bem durante experimentos de chaos engineering, eles serão hesitantes, o que é totalmente compreensível.

O chaos engineering revela uma das mais inconvenientes verdades sobre os sistemas complexos: Não estamos totalmente em controle e não podemos prever o que vai acontecer na produção. Infelizmente, algumas empresas serão relutantes ao encarar esta realidade. Esta é a razão pela qual é importante ter práticas como blameless postmortems e um bom processo de resposta a incidentes antes de introduzir o chaos engineering. Estas práticas impactam a cultura de uma empresa e criam discussões sobre a possibilidade de implementar o chaos engineering.

InfoQ: Qual a importância do fator pessoas no chaos engineering? Poderia prover algumas referências a líderes tentando melhorar a resiliência em uma empresa?

Dickey: A adoção do chaos-engineering é tanto um esforço de marketing como um esforço técnico. A compra da ideia pelas lideranças é crucial para que um programa de chaos engineering obtenha sucesso no longo prazo. O Awesome Chaos Engineering é uma lista de recursos ampla que encontrei que ajuda muito como ponto de partida.

Lin: A maioria das empresas tem a necessidade de entregar o software cada vez mais rápido e mitigam essa necessidade com muitos testes de pré release. Uma vez que uma empresa começa a confiar no seu tempo médio de reparo, há a vontade em aprender mais sobre o alto impacto proporcionado pelos experimentos de chaos engineering.

Ross: É possível descobrir alguns problemas sérios no design do código e infraestrutura quando testamos algo com o chaos engineering. Algo que pode fazer a gente pensar: "como isso aconteceu?". É importante manter em mente que as empresas causaram problemas, não indivíduos. É possível descobrir um problema que algum código causou e mesmo que a gente não fale o nome da pessoa, aquele indivíduo que escreveu o código sabe que foi o causador do problema. Dependendo da pessoa, ela pode se sentir mal e talvez até se fechar por causa disso. É necessário garantir que ela sinta que tenha suporte e que está habilitada, porque todos iremos cometer erros (de fato, se você tem algum código em produção, já cometeu algum erro). Evite apontar os dedos a todo custo. Se não conseguimos evitar isto, não estamos pronto para o chaos engineering.

Andrus: Uma das coisas que mais me irritam em nossa indústria é a falta de investimentos em treinamentos das equipes antes que sejam colocadas de plantão. Há uma razão para os treinamentos de incêndio existirem: É para que tenhamos a oportunidade de praticar e obter alguma memória muscular, para que as pessoas não fiquem correndo de um lado para o outro com os cabelos pegando fogo quando algo de errado acontece. De forma similar, uma grande parte na gerência dos incidentes é a coordenação entre as equipes, onde normalmente os times nunca interagiram antes, criando espaço para que estas relações sejam construídas fora de uma situação de urgência, permitindo uma preparação e resultados melhores.

Niño: Acredito que o chaos engineering é uma disciplina criada por pessoas, para pessoas. Nós, seres humanos, nossas atitudes, e os tradeoffs que fazemos sob pressão, são todos contribuidores de como os sistemas rodam e se comportam. Em chaos engineering nós desenvolvemos falhas, executamos experimentos em produção, analisamos os resultados e geramos estratégias de resiliência.

Sobre referências, acredito que algumas pessoas e empresas incríveis têm melhorado as resiliências utilizando os benefícios do chaos engineering. A equipe da Gremlin está fazendo um grande trabalho na liderança deste espaço. A ferramenta e a documentação são ótimas referências aos líderes que estão preocupados com resiliência.

Esquivel: Uma vez que as pessoas entendem que são responsáveis pelo que constróem, é fácil ganhar suporte e as pessoas irão colaborar facilmente. Na Backcountry, melhorar a resiliência é responsabilidade do VP de produtos, do diretor de engenharia, e de vários outros líderes. Neste caso, o suporte de cima para baixo tem sido crítico no progresso do chaos engineering.

Allamaraju: Pessoas estão no coração desta disciplina. Afinal, são elas que desenvolvem e operam nossos sistemas. São as pessoas que ouvem os feedbacks daqueles sistemas através das métricas operacionais. São as pessoas que podem aprender a partir dos incidentes para saber quando os sistemas funcionam e quando não funcionam.

Infelizmente, ainda estamos aprendendo sobre tudo isto através da experiência, o que demanda tempo.

Rensin: As pessoas são as partes mais importantes de qualquer sistema. Construímos e executamos esses sistemas para as pessoas. Elas são as maiores barreiras e também as aceleradoras. A melhor maneira que consigo imaginar para criar uma resiliência organizacional é periodicamente "desligar" os humanos críticos. O que quero dizer é, "Hoje, Sally não irá responder e-mail ou mensagens diretas por nenhuma razão. Sinta-se à vontade para ter interações sociais, mas ela está fora do alcance em questões de trabalho". Por que faríamos isto? Para encontrar todo conhecimento tribal que apenas a Sally tem e ter tudo por escrito, ou pelo menos descentralizado. Faça isto aleatoriamente, com pessoas suficientes, e de repente teremos um time muito mais resiliente.

Osman: Acredito que não ficarão surpresos, baseados em minhas respostas acima, que as pessoas são os aspectos mais críticos! As melhores ferramentas e processos não são nada quando as pessoas não suportam ou não confiam nelas. Em termos de referências, são sete anos agora, mas sempre indico o artigo de John Allspaw, "Fault Injection in Production", que foi publicado na ACM Queue. É uma grande introdução ao assunto. Do mesmo autor e ano, o post "Blameless PostMortems and a Just Culture". Mencionei a importância de um bom processo de resposta a incidentes algumas vezes. Se uma empresa não está satisfeita com o processo, sempre indico a excelente documentação do PagerDuty sobre resposta a incidentes. É um destes casos onde podemos apenas apontar e dizer "se você não está fazendo nada agora, apenas faça isso".

InfoQ: Poderia recomendar suas ferramentas favoritas, práticas e jogos dentro do chaos engineering?

Yee: Uma das coisas boas do chaos engineering é que não é necessário muitas ferramentas. Por exemplo, podemos utilizar o comando kill, nativo do Linux, para matar os processos e iptables para introduzir instabilidades na rede. Algumas outras ferramentas que usamos no Datadog é o Comcast, uma ferramenta para simular condições de rede instável, e o Vegeta, uma ferramenta de testes de carga HTTP.

Dickey: A Mailchimp é cliente da Gremlin há mais ou menos um ano, e estamos felizes com a flexibilidade e as funcionalidades que as ferramentas oferecem. Escolhemos utilizar essas ferramentas ao invés de construir as nossas porque acreditamos que o tempo dos desenvolvedores é melhor gasto criando produtos fantásticos para os consumidores, do que desenvolvendo ferramentas dentro de casa para testes. Também temos algumas restrições técnicas únicas (venha assistir minha apresentação para saber mais!) que nos limitou a utilizar várias ferramentas open source.

O time de SRE pratica game days todos os meses, e mais frequentemente quando requisitado por outras equipes. Utilizamos game days de simulação de incidentes, algumas vezes chamamos de jogos de guerra ou treinamento de incêndios, para ajudar nossos engenheiros a ficar mais confortáveis na resposta a incidentes.

Ross: Realmente gosto de tentar o chaos engineering sem nenhuma ferramenta no começo. Basicamente, executamos um game day onde um time de engenheiros é responsável por desestabilizar o site, sem dizer ao outro time o que irão fazer, ou quando farão, e isso pode ser bem divertido. Essa prática irá revelar todo tipo de coisas como, onde está o conhecimento sobre certo domínio, se as pessoas sabem o processo quando as coisas quebram, se existem alarmes configurados, se existem ferramentas certas para investigar, etc.

Andrus: O que mais recomendo é realmente conhecer as ferramentas de linha de comando e de observabilidade. Seja capaz de rodar comandos como o grep/sort/cut/uniq em um conjunto de logs para limitar os sintomas. Seja confortável com o TCPDump ou ferramentas de análise de rede para conseguir entender o que realmente está acontecendo. Entender como latência, agregações, percentiles e métricas são elementos chaves para o comportamento do sistema.

Também há essa ferramenta chamada Gremlin, que super recomendo. Recentemente lançamos uma versão gratuita para quem está começando, que permite executar experimentos de CPU e shutdown.

Niño: Para as indústrias que ainda tem muitas restrições para utilizar a nuvem, recomendo utilizar ferramentas como o Chaos Monkey para o Spring Boot. É uma excelente ferramenta que trabalha muito bem em conduzir experimentos que envolvem latência, exceções controladas e queda de aplicações ativas em arquiteturas on-premise.

Também tenho explorado a ChaoSlingr, uma nova ferramenta para fazer testes de chaos engineering com segurança. Ela é feita para a AWS e permite injetar falhas no sistema de uma maneira que permite identificar problemas de segurança mas também entender melhor a infraestrutura.

Esquivel: Nós fomos de ferramentas desenvolvidas em casa para softwares comerciais, e nossa recomendação é utilizar soluções comerciais, a não ser que você tenha muito tempo e dinheiro para investir nisto. Nossa arma contra a instabilidade em massa é o Jenkins. Para iniciar os testes de carga utilizamos o Gatling, e para liberar o chaos sobre uma área de impacto pré-determinada, o Gremlin, o que nos deixa confortáveis para conduzir experimentos em ambientes de produção e de desenvolvimento.

Allamaraju: Não acho que haja uma ferramenta ou prática favorita. Ao invés disso, olharia a arquitetura do sistema, as premissas que estamos tomando, as fraquezas identificadas através dos incidentes, desenvolveria hipóteses para testar por falhas e, só então, escolheria as ferramentas ou práticas que poderiam auxiliar a provar as hipóteses.

Rensin: No Google, nós utilizamos o DiRT (testes de desastre e recuperação, disaster and recovery testing, em inglês), onde vamos fisicamente a um datacenter e causamos "algo terrível às máquinas" que rodam os sistemas internos do Google, como por exemplo, desconectar o hardware. Há um pequeno time que planeja e executa as falhas de modo a não causar problemas aos consumidores, mas a maioria dos engenheiros encaram a experiência como se fosse algo real. Encontramos muitas coisas dessa forma e os postmortems do DiRT são algumas das melhores leituras do Google.

Osman: Em termos práticos, gosto bastante de planejar experimentos de chaos durante os postmortems. Quando se está analisando a linha do tempo de um incidente, anotamos as surpresas, como um banco de dados que falhou e ninguém sabe exatamente por quê, ou talvez um pico na latência de um serviço que causou erros que ninguém conseguiu antecipar, todas elas são grandes razões para continuar executando experimentos de chaos. Então, os times podem aprender mais sobre o comportamento dos sistemas sob certos tipos de estresses. Richard Cook tem falado sobre a diferença entre os "sistemas como são imaginados" comparado com "como os sistemas são de verdade", e postmortems são grandes oportunidades para estressar essas diferenças pois são combustíveis perfeitos para experimentos de grande valor.

InfoQ: Poderia dar um resumo de duas sentenças sobre sua palestra na Chaos Conf? Por que os visitantes deveriam assisti-la?

Yee: Se resiliência já não é algo opcional, mas sim um requisito obrigatório em aplicações modernas, então necessitamos mudar como desenvolvemos os nossos sistemas. Falarei sobre o desenvolvimento orientado a resiliência, um jeito de aplicar os princípios do chaos engineering logo no início do processo de desenvolvimento para garantir aplicações mais resilientes.

Dickey: Para muitas empresas, o chaos engineering significa testar dependências entre os serviços ou matar instâncias de containers. Minha apresentação fala sobre o porquê e como praticar o chaos engineering quando essas abordagens não são uma opção, como quando nossa aplicação principal é um monolito rodando em um servidor dedicado apenas ao sistema.

Lin: Quem é responsável pelo chaos em uma empresa? Em grandes organizações já estabelecidas provavelmente é o time de SRE ou DevOps. Mas e se não temos essas funções claramente definidas? Quem então faria os experimentos? Minha palestra cobrirá este tópico.

Ross: Vamos mostrar como combinar os fatores que contribuíram para os incidentes de alta severidade anteriores nos experimentos de chaos. A partir de então, vamos tentar ver se aquele incidente aconteceria de novo, baseados em todos os aprendizados que conseguimos respondendo ao incidente.

Andrus: Muito foi desenvolvido nesta área no último ano. Vimos um aumento no número de casos afetando consumidores, uma tendência que tememos que ficará ainda pior, antes de melhorar. A palestra cobrirá como as empresas podem se preparar para os problemas mais conhecidos, de forma que o público sairá da apresentação sabendo como construir uma internet mais confiável.

Niño: Hoje em dia há muitos livros, ferramentas e estudos que falam sobre o chaos engineering. Isto pode ser muita informação para quem está começando a explorar esta disciplina. Minha palestra, "Hot recipes for doing Chaos Engineering", provê instruções e experimentos para criarmos um caminho para engenheiros que estão começando com chaos engineering.

Esquivel: Gostaria de atacar um problema comum quando se está tentando iniciar com o chaos engineering: O que é um bom roadmap para o chaos engineering? Quero começar mostrando oito padrões de estabilidade, falar sobre três maneiras de implementar a observabilidade e juntar tudo fazendo um teste de chaos ao vivo.

Allamaraju: Planejo falar sobre como formular hipóteses de falhas. Baseado na minha experiência no Expedia Group, planejo compartilhar os guardrails arquiteturais que usamos para ter uma condução segura, e como criar hipóteses de valor para promover a segurança.

Rensin: Acredito que podemos, e devemos, aplicar os princípios de chaos engineering no desenvolvimento e treinamento de nossas equipes. Não há razão para limitar estas ideias somente para nosso software e hardware. Acredito que possamos convencer o público da razão pela qual estes fatores fazem as equipes e empresas melhores.

Osman: Eu e a Ana Medina vamos falar sobre maneiras de introduzir o chaos engineering na sua empresa. Vamos demonstrar a partir de exemplos práticos em empresas que trabalhamos. Descreveremos várias formas de acesso para começar com estas práticas. Você certamente deveria assistir nossa palestra se você tem que batalhar para colocar as ideias em prática em sua empresa, ou se está interessado no assunto mas não está seguro em como começar.

Por fim, o InfoQ conversou com o Adam LaGreca, diretor de comunicações na Gremlin, sobre os pensamentos sobre os objetivos da conferência. Ele relatou que o Chaos Conf 2018 focou em como discutir sobre o que é chaos engineering e porque os times deveriam praticá-lo. Em 2019, o tema foi sobre o "próximo passo", e as palestras terão pioneiros da disciplina, compartilhando os conhecimentos e as experiências conseguidas com muito suor.

Sobre os entrevistados

Jason Yee é um evangelista técnico na Datadog, onde trabalha para inspirar desenvolvedores e engenheiros de operações através do poder das métricas e do monitoramento. Anteriormente, gerenciou a comunidade de DevOps / Performance, na O'Reilly Media e foi engenheiro de software na MongoDB.

Caroline Dickey é uma engenheira SRE na Mailchimp em Atlanta, onde desenvolve ferramentas internas, trabalha com a equipe de desenvolvimento para desenvolver SLIs e SLOs, e lidera a iniciativa de chaos engineering, incluindo a coordenação mensal dos game days.

Joyce Lin é desenvolvedora líder na Postman. A Postman é utilizada por 7 milhões de desenvolvedores e mais de 300.000 empresas para acessar 130 milhões de APIs todos os meses. Frequentemente trabalha com empresas que são API-first, e tem opiniões fortes sobre o que é recomendado ou não nas práticas modernas de desenvolvimento de software.

Robert Ross (Bobby Tables) é o fundador e CEO da FireHydrant's.

Kolton Andrus é CEO e co-fundador da Gremlin. Anteriormente, trabalhou no gerenciamento de resolução de incidentes globais na Amazon e Netflix.

Yury Niño é uma engenheira de software e DevOps, e uma advocate do chaos-engineering. Niño ama desenvolvimento de software, automação, ler, escrever, e ensinar.

Jose Esquivel é principal software engineer na Backcountry.com.

Subbu Allamaraju é vice presidente na Expedia Group.

Dave Rensin trabalha com liderança de engenharia no Google. Ajuda a empresa a aplicar seu capital nas geografias, tecnologias e estratégia de investimentos corretas.

Paul Osman é um gerente de engenharia senior na Under Armour. Osman é um líder de engenharia de software experiente, com uma paixão por operações e SRE.