ChatOps: humanizando sem pessoas

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Em breve, em uma rede perto de você. Uma iniciativa da Outra Economia de APIs.

Ultimamente, a comunidade DevOps tem passado a dar mais atenção à cultura. Isso provavelmente ocorre porque, sem uma mudança cultural rumo a um ambiente de TI mais aberto e colaborativo entre as diferentes áreas, muitos dos benefícios do DevOps não podem ser plenamente aproveitados. O compartilhamento restrito de informações, baseado no princípio de que só deve saber quem precisa, cria silos que se erguem como torres defensivas, protegendo o conhecimento tribal específico de cada um dos domínios operacionais que compõem aquilo que carinhosamente chamamos de “TI”.

Mas derrubar esses silos pode ser doloroso. E constrangedor. E extremamente difícil. Embora possamos fazer piadas sobre a natureza “antissocial” de praticamente todos os profissionais de TI e zombar das caricaturas, a realidade é que, como a maioria das lendas e dos contos de fadas, esses arquétipos surgiram de comportamentos e características reais que ainda são típicos de muitos profissionais da área.

Sou INTJ no teste Myers-Briggs. Sempre. Sim, “O Arquiteto”. Sou um Observador Reformador no espectro Insights que, na verdade, é apenas um teste junguiano extremamente idealizado que alega ser mais preciso que o Myers-Briggs. De qualquer forma, sou bastante introvertido. Hoje, pesquisadores estimam que quase 50% da população seja introvertida. E tenho certeza de que não seria nenhuma surpresa para você descobrir que muitos deles acabaram na área de TI, assim como eu, enquanto nossos incompreensíveis colegas extrovertidos foram parar em cargos de marketing e gestão.

Os introvertidos não gostam muito de socializar — que é como os jovens chamam hoje em dia o ato de interagir com outras pessoas. Não é você, de verdade; somos nós. É que processamos informações e dados de maneira diferente dos extrovertidos e achamos o excesso de interação ativa desgastante. Conseguimos socializar, mas é exaustivo. Preferimos nos comunicar por texto e ter tempo para pensar antes de responder. É por isso que, na verdade, nos saímos muito bem na era digital, em que grande parte da nossa comunicação acontece justamente assim: à distância e por texto. Você pode até nos confundir com extrovertidos se só nos conhecer em nossa forma digital.

Se você considerar a premissa da mudança cultural exigida pelo DevOps, verá de imediato que há um conflito. O compartilhamento e a comunicação são componentes essenciais do DevOps, e isso significa tentar fazer com que um grupo de introvertidos não apenas interaja com as pessoas, mas também seja eficaz nessa interação. Portanto, encontrar uma maneira de “interagir sem ter que interagir” é como encontrar o pote de ouro no fim do arco-íris.

Acontece que o ChatOps pode muito bem ser esse pote de ouro.

ChatOps: Interação humana sem pessoas

Então, o que é ChatOps? Jason Hand, um dos maiores especialistas em ChatOps, nos dá uma definição concisa: “Pense no ChatOps como uma linha de comando compartilhada.”

É mais do que isso, é claro, mas, em sua forma mais básica, esse é um excelente ponto de partida.

Ferramentas como HipChat e Slack não foram projetadas para comunicação individual, como os antigos sistemas de mensagens instantâneas. É possível usá-las dessa forma, mas o verdadeiro poder dessas plataformas modernas de comunicação está em criar um ambiente de comunicação aberto, no qual informações e atualizações são compartilhadas instantaneamente com todas as pessoas da organização que tenham interesse nelas. Acompanhar as conversas sem participar é algo incentivado, pois o importante é a disponibilidade e a acessibilidade das informações, e não manter uma conversa contínua.

Os canais (como o #IRC) permitem controlar a relação sinal-ruído e, muitas vezes, oferecem um registro de auditoria claro de quem fez o quê e quando. Essas ferramentas conseguem isso por serem mais do que clientes de chat. Elas são plataformas capazes de ampliar suas funcionalidades por meio de APIs para oferecer comunicação bidirecional não apenas com pessoas, mas também com sistemas. Isso significa que posso adicionar um canal #alerts para o qual posso encaminhar, bem, alertas de componentes da infraestrutura.

Você pode — com relativa facilidade, diga-se de passagem — criar um “aplicativo” para o Slack que consulte e retorne informações por meio das APIs da plataforma. Pode ser o seu switch, o seu balanceador de carga ou a previsão do tempo local. Seja o que for, você pode executar comandos dentro dessas ferramentas para realizar tarefas automaticamente. E pode compartilhar o comando — e os resultados — com todos que precisam saber ou que poderiam se beneficiar dessas informações. Assim, as tarefas ficam documentadas pelo que você fez e deixam um histórico para que outras pessoas entendam o que está acontecendo. Atualizações de status dos sistemas de monitoramento, novos chamados da central de suporte, um aviso de que um servidor acabou de cair e não está mais disponível. Praticamente tudo o que você imaginar que possa ser comunicado por meio de uma API pode ser compartilhado com outras pessoas — sem precisar interagir diretamente com elas.

Esse processo abre inúmeras oportunidades de mentoria, treinamento e disseminação do conhecimento restrito a determinados grupos, beneficiando outras áreas de TI — inclusive o desenvolvimento. É o compartilhamento em grande escala, sem precisar reunir muitas pessoas em salas lotadas nem realizar treinamentos para novos engenheiros cheios de entusiasmo. É também uma das poucas ferramentas que viabilizam a mudança cultural necessária para adotar com sucesso uma abordagem DevOps na “rede”.

E precisamos adotá-la. Se você ainda está receoso, considere esta pergunta feita pela Atlassian e pela xMatters em sua Pesquisa de Maturidade em DevOps de 2017:

Os autores têm suas próprias hipóteses, baseadas nos dados coletados, mas eu tenho outra — fundamentada principalmente na Falácia da Composição, que nos lembra que a aplicação liberada para implantação não é a mesma que está em produção. A inclusão de serviços de aplicação e a interação com a rede alteram essa composição. A validação dessa aplicação, a menos que seja realizada em uma réplica exata do ambiente de produção, deixa de ser totalmente válida.

Pior ainda, em quase 1/3 das empresas, esses problemas só são descobertos quando os clientes as notificam sobre interrupções no serviço. Isso pode estar relacionado à forma como as informações são compartilhadas entre as equipes de desenvolvimento e de TI. Vinte e nove por cento afirmam que as informações são compartilhadas entre as equipes quando solicitadas especificamente. Apenas 16,8% deixam as informações “abertas a todos, disponibilizando informações técnicas, metas, planos e resultados”.

Sem as informações específicas sobre o comportamento de um aplicativo em produção, muitas vezes é difícil identificar qual é o problema, quanto mais sua origem. “Na minha máquina funciona” é um mantra defensivo que nasce da frustração dos desenvolvedores por não conseguirem reproduzir um comportamento inadequado que, na maioria das vezes, decorre da falta de informações sobre o ambiente.

Mesmo que não estejamos tão empolgados para começar a automatizar tudo na rede, o ChatOps é uma boa maneira de abrir os canais de comunicação entre as equipes de TI e desenvolvimento e proporcionar maior visibilidade dos problemas, contribuindo para reduzir o MTTR (tempo médio para resolução). É uma forma de oferecer uma visão mais abrangente do que está acontecendo “na rede” sem ser invasivo nem microgerenciar os engenheiros. Ele permite que os introvertidos interajam sem precisar socializar, o que os incentiva a compartilhar informações com mais frequência, profundidade e, quem sabe, até entusiasmo.

Se você ainda não conhece o ChatOps, recomendo muito a leitura do e-book de Jason Hand, “ChatOps para Leigos”. É preciso fornecer seu e-mail, mas vale a pena.

E continue acompanhando este espaço. Posso garantir que ainda falaremos mais sobre ChatOps no futuro.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie