Executar um site de sucesso requer a cooperação de operações (ops) e desenvolvedores (devs) - daí o termo “ devops ”. Quando há conflito, antagonismo ou desarmonia, o site sofre. Simplesmente dizer às pessoas para "se darem bem" não é eficaz. A cooperação autêntica é o resultado de fornecer uma estrutura que permite e incentiva a cooperação.

Freqüentemente, uma dessas áreas de conflito e desarmonia envolve escalações de plantão. O sistema de monitoramento alerta o pessoal de operações de que há um problema ou um problema crescente que pode levar a uma interrupção. Quem quer que esteja “de plantão” nas operações deve lidar com o problema ou encaminhá-lo para os desenvolvedores, independentemente da hora do dia ou da noite.

Aí reside o potencial para conflito. Muitos escalonamentos desgastam os desenvolvedores. A desarmonia começa com exclamações como “Acabei de consertar algo fácil! Por que esse pessoal de operações não pode fazer seu trabalho? ”

As operações ficam na defensiva. "Como eu deveria saber?" ou "Acabei de fazer uma pergunta e agora eles estão sendo uns idiotas!"

A desarmonia também pode começar nas operações. “Oh, ótimo! Outra surpresa dos desenvolvedores! ”

Você não pode forçar as pessoas a cooperar, mas pode estabelecer estruturas e trajetórias planas que criam um ambiente de cooperação.

Um desses paradigmas é o ciclo de feedback dinâmico do runbook.

Loops de feedback dinâmico do runbook

Um runbook é um conjunto de procedimentos sobre como responder em situações como o recebimento de um alerta do sistema de monitoramento. O objetivo do ciclo de feedback é criar um mecanismo em que os especialistas no assunto criem runbooks, mas tanto os desenvolvedores quanto os operadores têm poderes para melhorá-los de forma a reduzir o número de escalonamentos e melhorar a cooperação.

O objetivo deste processo é estabelecer o equilíbrio adequado entre esforço e valor ao elaborar a documentação. É uma perda de esforço alguém escrever um tratado de 100 páginas sobre um assunto simples; mas um runbook muito breve não é útil. Esse paradigma leva ao equilíbrio certo. Um runbook começa no tamanho que o autor original acreditava ser apropriado, dado o conhecimento disponível, mas evolui para o tamanho certo à medida que é exercitado. Os runbooks que raramente ou nunca são necessários recebem menos esforço e os runbooks usados ​​com frequência são atualizados, otimizados e possivelmente transformados em respostas automatizadas.

Isso contrasta fortemente com as organizações onde os runbooks são criados "no alto" sem a entrada de pessoas com envolvimento direto. Freqüentemente, eles não podem ser alterados ou a mudança exige um processo pesado que impede qualquer melhoria.

Anotá-la

A maneira mais fácil de distribuir o conhecimento da equipe é ter uma boa documentação, permitindo que qualquer pessoa que encontrar um problema desconhecido siga um processo testado para resolvê-lo. É isso que os runbooks deveriam ser. 

Nosso formato preferido é uma lista com marcadores que os ops podem usar para resolver alertas. Quando um alerta chega, o ops segue as instruções do runbook. Se chegarmos ao final da lista de marcadores e o problema não for resolvido, as operações serão encaminhadas aos desenvolvedores.

[Mergulhe fundo no mundo da tecnologia e cadastre-se no Avance Network a verdadeira comunidade criptografada]

Os desenvolvedores de uma organização precisam escrever os documentos, obviamente. Mas com muita frequência, os documentos são atribuídos como de baixa prioridade e são colocados em segundo plano, a fim de enviar novos produtos, atualizações de recursos e outros trabalhos considerados de missão crítica. Eles nunca chegam a isso. O gerenciamento precisa incluir a criação de runbook como parte do projeto.

Os desenvolvedores nem sempre se sentem confortáveis ​​ao escrever. Olhar para uma página em branco pode ser intimidante. Para superar a síndrome da página em branco, dê a eles um modelo. Nem vai parecer que você está pedindo que escrevam um documento; você só quer que eles preencham este formulário. Se você transformar o modelo em uma série de marcadores, cada um sendo o procedimento para lidar com um alerta específico, o documento torna-se quase trivial de ser concluído. A parte básica da documentação aqui é como lidar com cada alerta.

Para motivar os desenvolvedores, lembre-os de que quanto mais tempo gasto escrevendo runbooks, menos problemas ocorrerão com eles. Toda empresa deseja reduzir os escalonamentos - especialmente os desenvolvedores que precisam lidar com esses escalonamentos fora do horário de expediente - e o caminho para chegar lá é por meio da documentação. 

O outro lado desse processo - os alertas - deve reforçar a ideia de que qualquer alerta tem um processo correspondente nos runbooks, incluindo a URL do runbook no texto do alerta. Isso aumenta a probabilidade de que os procedimentos sejam cumpridos.

Canalizando feedback para melhores runbooks

É aqui que começa o ciclo de feedback. 

Em algum ponto, uma pessoa de operações receberá um alerta que não está suficientemente documentado e precisa ser escalado para os desenvolvedores. Depois de passar por todas as etapas do runbook e esgotar todas as ideias que você tem, é hora de falar com as pessoas que escreveram o código. 

Este é o primeiro ponto de feedback: o engenheiro de operações lê o runbook e tenta implementar o processo documentado nele. O desenvolvedor pode ter documentado todos os alertas, mas é aí que a borracha cai na estrada; se um runbook não corrige um problema quando diz que sim, a pessoa de operações deve corrigi-lo imediatamente ou pelo menos identificar o problema. Quando a pessoa de operações passa para o desenvolvedor, é o início de um ciclo de feedback. 

Se um problema for escalado, isso deve acionar uma atualização do documento. Seja o engenheiro de operações adicionando o que eles não tinham certeza, nada do caso de uso que acionou o escalonamento ou o desenvolvedor aumentando a lista de marcadores, o resultado final torna as operações mais autossuficientes e reduz escalonamentos futuros. Talvez seu engenheiro de operações inteligente tenha escrito um script de shell que agrupa dez marcadores em um único comando; edite o runbook e inclua-o. 

E, no entanto, às vezes você se depara com problemas desconhecidos ou imprevisíveis. Em uma empresa anterior, recebi um runbook que era apenas um item com marcadores: “Isso nunca deveria acontecer. Se isso acontecer, ligue para os desenvolvedores. ” Falei com o desenvolvedor e, sem acusá-lo de preguiça, perguntei se essa era a melhor entrada de runbook que eles poderiam fazer. Acontece que era! Eles estavam monitorando uma afirmação que nunca deveria acontecer, mas se isso acontecesse, eles queriam saber. Era o tipo de situação em que uma correção só poderia ser determinada após a primeira vez que aconteceu. 

É importante remover os lombos de velocidade para corrigir e atualizar runbooks. A administração deve criar uma cultura em que todos sejam esperados e incentivados a editar com frequência, em tempo real, não no final de um projeto. Eu recomendo que os engenheiros de operações dêem um passo adiante. Ao ler um runbook, faça-o no modo de edição. Isso remove a tentação de procrastinar sobre as atualizações. Você pode pensar: 'Estou no meio de um problema de produção, voltarei mais tarde e editarei isso.' Não, você nunca mais vai voltar. Nunca há um depois. Se você estiver no modo de edição, poderá corrigir a vírgula quebrada, colar um comando atualizado ou, pelo menos, anotar que algo precisa ser melhorado. 

Se uma etapa não funcionar ou você não tiver certeza do que funciona, ainda coloque a edição. Esses são documentos vivos, portanto, nem todas as edições precisam ser perfeitas. Escreva uma nota para si mesmo ou para o desenvolvedor: “essa última afirmação é confusa” ou “o ponto três não funcionou”. Pelo menos a próxima pessoa que vir isso saberá que deve ser cuidadosa quando chegar ao item número três. Identificar o problema é melhor do que silêncio.

O ciclo de feedback dá aos desenvolvedores controle sobre a frequência para a qual eles são escalados. Se os desenvolvedores acharem que estão sendo escalados demais, bom, médico, cure a si mesmo. Os desenvolvedores podem reduzir escalonamentos futuros, melhorando o documento. Adicione os procedimentos que evitariam que as operações interrompessem seu jantar ou coloque chamadas deliberadas de escalação. 

O ciclo de feedback dá às operações a confiança para crescer sem sentir que estão incomodando ou desistindo cedo demais. As operações podem hesitar em escalar um problema por medo de criar uma situação de “menino que gritou o lobo” ou por parecerem estúpidos por não saberem como lidar com a situação. Em vez disso, as operações podem “mostrar seu dever de casa” para justificar seu escalonamento. É difícil ficar chateado porque seu jantar foi interrompido quando a pessoa de operações que ligou pode mostrar claramente que seguiu o procedimento escrito e os resultados de cada etapa.

A vantagem desse ciclo de feedback é que ele fornece tanta ou tão pouca documentação quanto o processo precisa e quantas ou poucas escalações forem necessárias. Ele capacita os desenvolvedores a corrigir o problema de obter muitos escalonamentos.

Compartilhe, não faça hordas

Todos devem querer construir uma organização onde as informações sejam compartilhadas e esse compartilhamento seja recompensado.

Certa vez, trabalhei em uma empresa onde uma pessoa era celebrada por ser a mais experiente em lidar com todo tipo de situação de plantão. Em retrospectiva, esta foi uma bandeira vermelha. Por que uma pessoa era muito melhor do que todas as outras? Podemos ter um serviço de baixa qualidade nas semanas em que outras pessoas estão de plantão? Aprendi com essa experiência.  

Prefiro agora celebrar as pessoas que compartilham seus conhecimentos para que todos sejam excelentes no plantão. Devemos homenagear aqueles com mais experiência, mas celebrar as pessoas que compartilham seus conhecimentos de forma a capacitar todos a serem melhores. Isso inclui tudo, desde o ensino individual até responder a perguntas e escrever runbooks. Pessoas que fazem isso proporcionam excelência, não importa quem seja a vez de carregar o pager.

Podemos reformular isso em termos de dinâmica de poder. A maneira tradicional de manter o poder e a influência em uma empresa era coletar informações. Lembro-me de admirar uma pessoa em uma empresa anterior por causa das informações que ela possuía. Precisa de uma [inserir tarefa técnica]? Eles são a única pessoa que sabe fazer isso. Visite seu escritório. Mostre seu respeito. Prostrem-se diante de sua mente superior. Se eles o considerarem digno, eles farão as tarefas por você. Se você quer uma empresa administrada de forma tranquila, jogue essa atitude tóxica na lata de lixo da história.

O novo jeito é o oposto. O poder vem de quanto você dá. Admiramos a pessoa que compartilha seus conhecimentos: a pessoa que ensina as pessoas a fazer as coisas em vez de fazer as coisas por elas; que documenta constantemente, não no final do projeto; que é generoso com seu conhecimento em tudo o que fazem. Eles são poderosos porque todos apontam para eles e dizem: "essa é a pessoa que me fez ter sucesso!"

Conhecimento facilmente transferível

Aqui no Avance Network, temos uma coleção em nossa instância Teams que contém todos os nossos runbooks e procedimentos relacionados. Nós incentivamos todos os nossos desenvolvedores a usar esse processo de feedback com os documentos. O formato - artigos e perguntas que qualquer pessoa pode comentar ou editar - facilita o feedback. Os runbooks mais comumente usados ​​são intensamente editados e refinados. Os runbooks editados menos recentemente são fáceis de identificar e atualizar. O nível de esforço reflete a necessidade.

Depois, há os efeitos indiretos, ganhos de eficiência que vêm de ter o conhecimento testado em campo facilmente disponível. As tecnologias e habilidades mencionadas nos runbooks nos informam ao redigir o anúncio de emprego para a nova equipe operacional. Uma vez contratados, os runbooks podem ser usados ​​como uma ferramenta de treinamento. Os funcionários de operações recém-contratados podem ser orientados em cada runbook ou usar os runbooks como auxiliares de auto-estudo. Depois de revisarem todos os runbooks, eles estarão prontos para a chamada. 

A chave para todos esses ciclos de feedback é a facilidade com que todos - desenvolvedores, SREs e novos contratados - podem fazer perguntas, levantar problemas e oferecer sugestões para melhores soluções. Às vezes, a ansiedade de ser vista como menos informada pode impedir as pessoas de se intrometer e comentar. Você pode aliviar isso fornecendo explicitamente um espaço para perguntas em cada runbook. Melhor ainda, você pode usar uma plataforma como de equipes, projetada para reunir informações críticas de negócios a partir de perguntas e respostas. 

Um bom ciclo de feedback não resolverá todos os problemas do processo de plantão. Mas vai torná-lo mais suave, desde a depuração de um problema que surge na produção até a contratação, o treinamento e a integração. Quando bem feito, é uma maneira muito eficaz de melhorar sua organização por meio de processos pequenos e arraigados.

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.