Operações de bate-papo: Povoando sem Pessoas

Em breve em uma rede perto de você. Apresentado a você pela Other API Economy .

Houve uma mudança ultimamente na comunidade DevOps para focar mais na cultura. Isso provavelmente ocorre porque, sem a mudança cultural para um ambiente de TI mais aberto e colaborativo, muitos dos benefícios do DevOps não podem ser totalmente realizados. O compartilhamento fechado de informações “necessárias” leva a esses silos que se erguem como torres defensivas que encerram o conhecimento tribal exclusivo de cada um dos domínios operacionais que compõem o que carinhosamente chamamos de “TI”.

Mas quebrá-los pode ser doloroso. E estranho. E extremamente difícil. Embora possamos fazer piadas sobre a natureza "antissocial" de quase todos os habitantes da TI e zombar das caricaturas, a realidade é que, como a maioria das lendas e contos de fadas, esses arquétipos surgiram de comportamentos e características reais que ainda caracterizam muitos na área.

Sou um INTJ na Meyers-Briggs. Toda vez. Sim, “O Arquiteto”. Sou um Observador Reformador no espectro Insights , que na verdade é apenas um teste junguiano hiperidealizado que alega maior precisão do que Meyers-Briggs. De qualquer forma, sou bastante introvertido. Hoje, pesquisadores estimam que quase 50% da população é introvertida. E tenho certeza de que não seria surpresa para você descobrir que muitos deles entraram na área de TI como eu, enquanto nossos colegas extrovertidos e incompreensíveis passaram para cargos de marketing e gestão.

Os introvertidos não gostam de pessoas – que é como as crianças chamam a interação com as pessoas, hoje em dia. Não é você, na verdade, somos nós. Nós simplesmente processamos informações e dados de forma diferente dos extrovertidos e achamos muita interação ativa opressiva. Podemos, pessoal, mas é exaustivo. Preferimos texto e tempo para pensar antes de responder. É por isso que realmente nos saímos muito bem na era digital, onde grande parte da nossa comunicação é apenas isso: à distância e via texto. Você pode até nos confundir com extrovertidos, se nos conhece apenas em nosso formato digital.

Se você considerar a premissa da mudança cultural necessária com o DevOps, verá que há um conflito imediatamente. Compartilhamento e comunicação são componentes essenciais do DevOps, e isso significa tentar fazer com que um grupo de introvertidos não apenas aprenda a interagir com as pessoas, mas também seja eficaz no relacionamento. Isso significa que encontrar uma maneira de “pessoas sem povoar” é como encontrar o pote de ouro no fim do arco-íris.

Acontece que o ChatOps pode ser esse pote de ouro.

Operações de bate-papo: Povoando 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, no seu nível mais básico, este é um excelente lugar para começar.

Ferramentas como HipChat e Slack não foram projetadas para comunicação individual, como os antigos sistemas de mensagens instantâneas. Você pode fazer isso, mas o verdadeiro poder dessas plataformas de comunicação modernas é permitir um ambiente de comunicação aberto, onde informações e atualizações são compartilhadas instantaneamente com qualquer pessoa na organização que esteja interessada nelas. A espreita é incentivada porque o que importa é a disponibilidade e a acessibilidade da informação, não uma conversa contínua.

Canais (como #IRC) fornecem os meios para controlar a relação sinal:ruído e, muitas vezes, um registro de auditoria claro de quem fez o quê e quando. Essas ferramentas conseguem isso sendo mais do que simples clientes de bate-papo. Elas são plataformas com a capacidade de estender a funcionalidade por meio de APIs para fornecer comunicação bidirecional não apenas com pessoas, mas também com sistemas. Isso significa que posso adicionar um canal de #alertas para o qual posso canalizar alertas de componentes de infraestrutura.

Você pode – com relativa facilidade, devo acrescentar – criar um “aplicativo” para o Slack que consulte e retorne informações por meio de suas APIs. Talvez seja o seu switch, ou seu balanceador de carga, ou o clima local. Seja o que for, você pode invocar comandos dentro dessas ferramentas que executam tarefas automaticamente. E você pode compartilhar a invocação – e os resultados – sem que todos que precisam saber ou podem se beneficiar do conhecimento. As tarefas são então documentadas pelo que você fez e deixam um rastro para que outros entendam o que está acontecendo. Atualizações de status dos sistemas de monitoramento, novos tickets do help desk, uma nota informando que um servidor caiu e não está mais disponível. Praticamente tudo o que você possa imaginar que possa ser comunicado por meio de uma API pode ser compartilhado com outras pessoas, sem realmente popularizá-las.

Esse processo abre uma riqueza de oportunidades para orientação, treinamento e liberação de conhecimento tribal que beneficia outras áreas de TI – incluindo desenvolvimento. É compartilhar em grande escala, sem aglomerar pessoas em salas cheias ou conduzir exercícios de treinamento para novos engenheiros brilhantes. É também uma das poucas ferramentas que permite a mudança cultural necessária para adotar com sucesso uma abordagem DevOps na “rede”.

E devemos adotá-lo. Se você ainda estiver desconfiado, 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 em seus dados, mas eu tenho outra – baseada em grande parte na Falácia da Composição, que nos lembra que o aplicativo lançado para implantação não é o mesmo aplicativo em produção . A inserção de serviços de aplicativos e a interação com a rede alteram a composição. A verificação desse aplicativo, a menos que seja feita em uma réplica exata do ambiente de produção, não se aplica mais completamente.

Pior ainda, para quase 1/3 das empresas, esses problemas não são descobertos até que os clientes os notifiquem sobre interrupções no serviço. Isso pode ser devido à maneira como as informações são compartilhadas entre o desenvolvimento e a TI. Vinte e nove por cento dizem que as informações são compartilhadas entre as equipes quando especificamente solicitadas. Apenas 16,8% tornam a informação “aberta a todos, fornecendo 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 discernir qual é o problema, muito menos sua origem. “Funciona na minha máquina” é um mantra defensivo nascido da frustração dos desenvolvedores por não conseguirem replicar o mau comportamento que, na maioria das vezes, decorre da falta de informação ambiental.

Mesmo que não estejamos entusiasmados para começar a automatizar todas as coisas da rede , o ChatOps é uma boa maneira de abrir as linhas de comunicação entre TI e desenvolvimento e fornecer mais insights sobre problemas que contribuem para um MTTR (Tempo Médio de Resolução) mais rápido.  É um meio de fornecer uma visão mais abrangente do que está acontecendo "na rede" sem sermos engenheiros intrusivos ou microgerenciadores. Ela oferece uma maneira para os introvertidos se aproximarem das pessoas sem se aproximarem delas, o que os incentiva a compartilhar com mais frequência e profundidade e, você pode descobrir, com entusiasmo.

Se você é novo no ChatOps, recomendo fortemente que leia o e-book de Jason Hand, “ChatOps para Leigos ”. Exige que você abra mão do seu e-mail, mas vale a pena. 

E fique ligado aqui. Haverá mais sobre ChatOps no futuro, posso garantir.