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.

 

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, receb