Escrito por Dave O’Connor
Editado por Diane Bates
“Carga operacional”, quando aplicada a sistemas complexos, é o trabalho que deve ser feito para manter o sistema num estado funcional. Por exemplo, se for proprietário de um carro, você (ou alguém que pague) sempre acaba fazendo manutenção nele, colocando gasolina nele ou fazendo outras manutenções regulares para mantê-lo desempenhando sua função.
Qualquer sistema complexo é tão imperfeito como os seus criadores. Ao gerir a carga operacional criada por estes sistemas, lembre-se que os seus criadores são também máquinas imperfeitas.
Carga operacional, quando aplicada ao gerenciamento de sistemas complexos, assume muitas formas, algumas mais óbvias do que outras. A terminologia pode mudar, mas a carga operacional divide-se em três categorias gerais: notificações de alertas, tickets e responsabilidades operacionais em curso.
Alertas, dizem respeito a alertas de produção e às suas consequências, e são desencadeadas em resposta a emergências de produção. Podem por vezes ser monótonas e recorrentes, requerendo pouca reflexão. Podem também ser envolventes e envolver uma reflexão tática aprofundada. As páginas têm sempre um tempo de resposta esperado (SLO), que por vezes é medido em minutos.
Tickets, dizem respeito a solicitações de clientes que exigem que você execute uma ação. Tal como os alertas, os tickets podem ser simples e chatos ou exigir uma reflexão real. Um simples ticket pode solicitar uma revisão de código para uma configuração que a equipe possui. Um ticket mais complexo pode implicar um pedido especial ou incomum de ajuda com um projeto ou plano de capacidade. Os tickets podem também ter um SLO, mas o tempo de resposta é mais provavelmente medido em horas, dias, ou semanas.
Responsabilidades operacionais em curso (também conhecidas como “chutando a lata no caminho” e “labuta”; ver Capítulo 5) incluem atividades como a implementação de códigos ou bandeiras de propriedade de equipes, ou respostas a perguntas pontuais e urgentes de clientes. Embora possam não ter um SLO definido, estas tarefas podem interrompê-lo.
Alguns tipos de carga operacional são facilmente antecipados ou planejados, mas grande parte da carga não está planejada, ou pode interromper alguém num momento não específico, exigindo que essa pessoa determine se o problema pode esperar.
Gestão da carga operacional
A Google tem vários métodos de gestão de cada tipo de carga operacional ao nível da equipe.
Os alertas são geralmente geridas por um engenheiro de plantão primário dedicado. Esta é uma única pessoa que responde aos alertas e gere os incidentes ou interrupções resultantes. O engenheiro principal de plantão pode também gerir as comunicações de apoio ao usuário, o encaminhamento para os criadores de produtos, e assim por diante. A fim de minimizar a interrupção que uma página causa a uma equipe e evitar o efeito de espectador, os turnos de plantão do Google são geridos por um único engenheiro. O engenheiro de plantão pode encaminhar as páginas para outro membro da equipe se um problema não for bem compreendido.
Tipicamente, um engenheiro secundário de plantão atua como apoio para o primário. As funções do engenheiro secundário variam. Em algumas rotações, o único dever do secundário é contactar o primário se os alertas caírem. Neste caso, o secundário pode estar noutra equipe. O engenheiro secundário pode considerar-se ou não em interrupções, dependendo das suas funções.
Os tickets são geridos de algumas maneiras diferentes, dependendo da equipe da SRE: um engenheiro primário de plantão pode trabalhar com tickets enquanto está de plantão, um engenheiro secundário pode trabalhar com tickets enquanto está de plantão, ou uma equipe pode ter uma pessoa dedicada a tickets que não esteja de plantão. Os tickets podem ser distribuídos aleatoriamente de forma automática entre os membros da equipe, ou pode esperar-se que os membros da equipe prestem serviço de tickets ad hoc.
As responsabilidades operacionais em curso são também geridas de várias maneiras. Por vezes, o engenheiro de plantão faz o trabalho (push, flag flip, etc.). Alternativamente, cada responsabilidade pode ser atribuída a membros da equipe ad hoc, ou um engenheiro de plantão pode assumir uma responsabilidade duradoura (ou seja, uma implementação de várias semanas ou ticket) que dura para além da sua semana de turnos.
Fatores na determinação da forma como as interrupções são tratadas
Para dar um passo atrás na mecânica de como a carga operacional é gerida, há uma série de métricas que influenciam a forma como cada uma destas interrupções é tratada. Algumas equipes SRE no Google descobriram que as seguintes métricas são úteis para decidir como gerir as interrupções:
- Interromper o SLO ou tempo de resposta esperado
- O número de interrupções que normalmente estão em atraso
- A gravidade das interrupções
- A frequência das interrupções
- O número de pessoas disponíveis para lidar com um certo tipo de interrupção (por exemplo, algumas equipes requerem uma certa quantidade de trabalho com tickets antes de estarem de plantão)
Poderá reparar que todas estas métricas são adequadas para satisfazer o menor tempo de resposta possível, sem ter em conta mais custos humanos. Tentar fazer um balanço dos custos humanos e de produtividade é difícil.
Máquinas Imperfeitas
Os seres humanos são máquinas imperfeitas. Aborrecem, têm processadores (e, por vezes, UIs) que não são muito bem compreendidos, e não são muito eficientes. Reconhecer o elemento humano como “Trabalhando como se pretende” e tentar trabalhar em torno ou melhorar a forma como os humanos trabalham poderia preencher um espaço muito maior do que o aqui previsto; no momento, algumas ideias básicas podem ser úteis para determinar como as interrupções devem funcionar.
Estado de Fluxo Cognitivo
O conceito de estado de fluxo é amplamente aceito e pode ser reconhecido empiricamente por praticamente todos os que trabalham em Engenharia de Software, Sysadmin, SRE, ou na maioria das outras disciplinas que requerem períodos focalizados de concentração. Estar na “zona” pode aumentar a produtividade, mas também pode aumentar a criatividade artística e científica. Atingir este estado encoraja as pessoas a realmente dominar e melhorar a tarefa ou projeto em que estão trabalhando. Estar interrompido pode expulsá-lo deste estado, se a interrupção for suficientemente perturbadora. Pretende-se maximizar a quantidade de tempo gasto neste estado.
O fluxo cognitivo pode também aplicar-se a atividades menos criativas onde o nível de habilidade requerido é menor, e os elementos essenciais do fluxo ainda são cumpridos (objetivos claros, feedback imediato, uma sensação de controle, e a distorção de tempo associada); exemplos incluem o trabalho doméstico ou a condução.
Pode-se entrar na zona trabalhando em problemas de baixa habilidade e de baixa dificuldade, como por exemplo jogar um videogame repetitivo. Também se pode chegar lá com a mesma facilidade, fazendo trabalhos de alta habilidade, problemas de alta dificuldade, tais como os que um engenheiro pode enfrentar. Os métodos para chegar a um estado de fluxo cognitivo são diferentes, mas o resultado é essencialmente o mesmo.
Estado de fluxo cognitivo: criativo e empenhado
Esta é a zona: alguém trabalha num problema durante algum tempo, está consciente e confortável com os parâmetros do problema, e sente que pode corrigi-lo ou resolvê-lo. A pessoa trabalha intensamente no problema, perdendo a noção do tempo e ignorando as interrupções, tanto quanto possível. Maximizar o tempo que uma pessoa pode passar neste estado é muito desejável – eles vão produzir resultados criativos e fazer um bom trabalho por volume. Vão ficar mais felizes no trabalho que estão fazendo.
Infelizmente, muitas pessoas em funções do tipo SRE passam muito do seu tempo tentando e falhando em entrar nesse modo e ficando frustradas quando não conseguem, ou nunca sequer tentam chegar a este modo, definhando em vez disso no estado interrompido.
Estado de fluxo cognitivo: Angry birds
As pessoas gostam de executar tarefas que sabem como fazer. De fato, a execução de tais tarefas é um dos caminhos mais claros para o fluxo cognitivo. Alguns SREs estão de plantão quando atingem um estado de fluxo cognitivo. Pode ser muito gratificante perseguir as causas dos problemas, trabalhar com outros e melhorar a saúde geral do sistema de uma forma tão tangível. Pelo contrário, para a maioria dos engenheiros de plantão estressados, o estresse é causado ou pelo volume de alertas, ou porque estão tratando o plantão como uma interrupção. Estão tentando codificar ou trabalhar em projetos ao mesmo tempo que estão de plantão ou em interrupções em tempo integral. Estes engenheiros existem num estado de interrupção constante, ou de interruptibilidade. Este ambiente de trabalho é extremamente estressante.
Por outro lado, quando uma pessoa está concentrada em tempo integral nas interrupções, as interrupções deixam de ser interrupções. A um nível muito visceral, fazer melhorias incrementais no sistema, eliminar tickets, e corrigir problemas e interrupções torna-se um conjunto claro de objetivos, limites, e feedback claro: você fecha X bugs, ou você deixa de ser alertado. Tudo o que resta são distrações. Quando se faz interrupções, os seus projetos são uma distração. Mesmo que as interrupções possam ser uma utilização satisfatória do tempo a curto prazo, num ambiente misto de projeto/de plantão, as pessoas acabam por ser mais felizes com um equilíbrio entre estes dois tipos de trabalho. O equilíbrio ideal varia de engenheiro para engenheiro. É importante estar ciente de que alguns engenheiros podem não saber qual o melhor equilíbrio que os motiva (ou podem pensar que sabem, mas podem discordar).
Fazer uma coisa bem
Você pode estar se perguntando sobre as implicações práticas do que você leu até agora.
As seguintes sugestões, baseadas no que tem funcionado para várias equipes SRE que tenho gerido no Google, são principalmente para o benefício dos gestores de equipe ou influenciadores. Este documento é agnóstico dos hábitos pessoais – as pessoas são livres para gerenciar seu próprio tempo como acharem melhor. A concentração aqui é em dirigir a estrutura de como a própria equipe gere as interrupções, de modo que as pessoas não sejam preparadas para falhar por causa da função ou estrutura da equipe.
Distração
As formas como um engenheiro pode ser distraído e, portanto, impedido de alcançar um estado de fluxo cognitivo são numerosas. Por exemplo: considere um SRE aleatório chamado Fred. Fred chega ao trabalho na segunda-feira de manhã. Fred não está de plantão ou em interrupções hoje, por isso Fred gostaria claramente de trabalhar nos seus projetos. Ele pega um café, coloca seus fones de ouvido “não perturbe” e se senta em sua mesa. Tempo da zona, certo?
Exceto, a qualquer momento, qualquer uma das seguintes coisas pode acontecer:
- A equipe de Fred utiliza um sistema automatizado de tickets para atribuir tickets à equipe de forma aleatória. Um ticket é atribuído a ele, com vencimento hoje.
- O colega de Fred está de plantão e recebe um alerta sobre um componente em que Fred é especialista, e interrompe-o para perguntar sobre ele.
- Um usuário do serviço de Fred levanta a prioridade de um ticket que lhe tem sido atribuído desde a semana passada, quando estava de plantão.
- Um lançamento de sinalizador que está sendo implementado ao longo de 3 a 4 semanas e é atribuído a Fred dá errado, forçando o Fred a largar tudo para examinar o lançamento, reverter a alteração, e assim por diante.
- Um usuário do serviço de Fred o contacta para fazer uma pergunta, porque Fred é um sujeito muito útil.
- E assim por diante.
O resultado final é que, embora Fred tenha todo o dia de calendário livre para trabalhar em projetos, ele continua a ser extremamente distraído. Algumas destas distrações ele próprio pode gerir fechando o e-mail, desligando o IM, ou tomando outras medidas semelhantes. Algumas distrações são causadas pela política, ou por suposições em torno de interrupções e responsabilidades contínuas.
Você pode afirmar que algum nível de distração é inevitável e intencional. Esta suposição é correta: as pessoas agarram-se a bugs para os quais são o principal contato, e as pessoas também acumulam outras responsabilidades e obrigações. No entanto, há formas de uma equipe poder gerir a resposta de interrupção para que mais pessoas (em média) possam entrar no trabalho pela manhã e sentir-se imperturbáveis.
Tempo de polarização
A fim de limitar a sua distração, deve tentar minimizar as mudanças de contexto. Algumas interrupções são inevitáveis. No entanto, ver um engenheiro como uma unidade de trabalho que pode ser interrompida, cujas interrupções de contexto são livres, não é ideal se você deseja que as pessoas sejam felizes e produtivas. Atribua um custo às trocas de contexto. Uma interrupção de 20 minutos enquanto se trabalha num projeto implica duas interrupções de contexto; realisticamente, esta interrupção resulta na perda de algumas horas de trabalho verdadeiramente produtivo. Para evitar ocorrências constantes de perda de produtividade, visar um tempo polarizado entre estilos de trabalho, com cada período de trabalho o mais longo possível. Idealmente, este período de tempo é de uma semana, mas um dia ou mesmo um meio dia pode ser mais prático. Esta estratégia também se enquadra no conceito complementar de fazer tempo.
O tempo de polarização significa que quando uma pessoa chega ao trabalho todos os dias, ela deve saber se está fazendo apenas um trabalho de projeto ou apenas interrompendo. Polarizar seu tempo dessa maneira significa que eles se concentram por períodos mais longos na tarefa em questão. Não ficam estressados porque estão sendo amarrados a tarefas que os afastam do trabalho que deveriam estar fazendo.
Sério, me diga o que fazer
Se o modelo geral apresentado neste capítulo não funcionar para você, aqui estão algumas sugestões específicas de componentes que pode implementar aos poucos.
Sugestões gerais
Para uma determinada classe de interrupção, se o volume de interrupções for muito alto para uma pessoa, adicione outra pessoa. Este conceito aplica-se mais obviamente aos tickets, mas também pode se aplicar a páginas – o plantão pode começar a transferir coisas para suas páginas secundárias ou fazer downgrade para tickets.
De plantão
O engenheiro de plantão primário deve se concentrar apenas no trabalho de plantão. Se a página for silenciosa para o seu serviço, tickets ou outro trabalho baseado em interrupções que podem ser abandonados rapidamente devem fazer parte das tarefas de plantão. Quando um engenheiro está de plantão durante uma semana, essa semana deve ser anulada no que diz respeito ao trabalho do projeto. Se um projeto for demasiado importante para ser abandonado por uma semana, essa pessoa não deve estar de plantão. Escale para designar outra pessoa para o turno de plantão. Nunca se deve esperar que uma pessoa esteja de plantão e também faça progressos em projetos (ou qualquer outra coisa com um custo elevado de mudança de contexto).
Os deveres secundários dependem de quão onerosos são esses deveres. Se a função do secundário é apoiar o primário no caso de uma falha, então talvez se possa assumir com segurança que o secundário também pode realizar o trabalho de projeto. Se alguém que não seja o secundário for designado para tratar dos tickets, considere a fusão dos papéis. Se se espera que o secundário ajude realmente o primário no caso de um volume elevado de alertas, ele também deve interromper o trabalho.
(Além disso: Nunca se fica sem trabalho de limpeza. A sua contagem de tickets pode estar em zero, mas há sempre documentação que precisa ser atualizada, configurações que precisam de limpeza, etc. Os seus futuros engenheiros de plantão lhe agradecerão, e isso significa que é menos provável que eles o interrompam durante o seu precioso tempo de espera).
Tickets
Se atualmente atribui tickets aleatoriamente às vítimas da sua equipe, pare. Fazer isso é extremamente desrespeitoso com o tempo de sua equipe e funciona completamente contra o princípio de não ser o mais interrompível possível.
Os tickets devem ser uma função em tempo integral, durante um período de tempo que seja gerenciável para uma pessoa. Se você estiver na posição nada invejável de ter mais tickets do que os que podem ser fechados pelos engenheiros de plantão primários e secundários combinados, então estruture a sua rotação de tickets para ter duas pessoas lidando com tickets num determinado momento. Não espalhe a carga por toda a equipe. As pessoas não são máquinas e você está apenas causando mudanças de contexto que afetam o valioso tempo de fluxo.
Responsabilidades em curso
Na medida do possível, defina papéis que permitam a qualquer pessoa da equipe assumir a responsabilidade. Se houver um procedimento bem definido para executar e verificar pushs ou flag flips, então não há razão para que uma pessoa tenha que conduzir essa mudança durante toda a sua vida, mesmo depois de deixar de estar de plantão ou em interrupções. Defina uma função de gerente de push que possa fazer malabarismos com push durante seu tempo de plantão ou em interrupções. Formalize o processo de entrega – é um pequeno preço a pagar para que as pessoas que não estão de plantão disponham de tempo sem interrupções.
Estar em interrupções, ou não estar
Por vezes, quando uma pessoa não está em interrupções, a equipe recebe uma interrupção que a pessoa está excepcionalmente qualificada para tratar. Embora idealmente este cenário nunca deva acontecer, às vezes acontece. Deve-se trabalhar para que tais ocorrências sejam raras.
Por vezes, as pessoas trabalham com tickets quando não são designadas para lidar com tickets, porque é uma forma fácil de parecer ocupado. Tal comportamento não é útil. Significa que a pessoa é menos eficaz do que deveria ser. Eles distorcem os números em termos de quão gerenciável é a carga de tickets. Se uma pessoa for designada para os tickets, mas duas ou três outras pessoas também tentarem a fila de tickets, você ainda poderá ter uma fila de tickets incontrolável, mesmo que não perceba.
Interrupções redutoras
A carga de interrupção de sua equipe pode ser incontrolável se exigir que muitos membros da equipe façam interrupções de equipe simultaneamente a qualquer momento. Há uma série de técnicas que pode utilizar para reduzir a sua carga de tickets em geral.
Analisar de fato os tickets
Muitas rotações de tickets ou rotações de plantão funcionam como uma luva. Isso é especialmente verdadeiro para rotações em equipes maiores. Se estiver apenas em interrupções de dois em dois meses, é fácil enfrentar o desafio,144 dar um suspiro de alívio e depois retornar às suas tarefas normais. O seu sucessor faz então o mesmo, e as causas raiz dos tickets nunca são investigadas. Em vez de conseguir avançar, a sua equipe fica atolada por uma sucessão de pessoas que se aborrecem com as mesmas questões.
Deve haver uma transferência para tickets, bem como para trabalho de plantão. Um processo de transferência mantém um estado partilhado entre os responsáveis pelos tickets, à medida que a responsabilidade muda. Mesmo alguma introspecção básica nas causas de raiz das interrupções pode fornecer boas soluções para reduzir a taxa global. Muitas equipes realizam transferências de plantão e revisões de alertas. Muito poucas equipes fazem o mesmo para os tickets.
A sua equipe deve realizar uma limpeza regular para tickets e alertas, na qual você examina classes de interrupções para ver se consegue identificar uma causa raiz. Se você acha que a causa raiz pode ser corrigida em um período de tempo razoável, silencie as interrupções até que se espere que a causa raiz seja corrigida. Fazer isso fornece alívio para a pessoa que está lidando com interrupções e cria uma aplicação de prazo útil para a pessoa que está corrigindo a causa raiz.
Respeite-se a si próprio, bem como aos seus clientes
Esta máxima aplica-se mais às interrupções do usuário do que às interrupções automáticas, embora os princípios representem ambos os cenários. Se os tickets forem particularmente incômodos ou onerosos de resolver, é possível utilizar eficazmente a política para mitigar a carga.
Lembre-se:
- A sua equipe define o nível de serviço prestado pelo seu serviço.
- Não há problema em empurrar parte do esforço para seus clientes.
Se a sua equipe for responsável por lidar com tickets ou interrupções para clientes, pode frequentemente utilizar a política para tornar a sua carga de trabalho mais controlável. Uma política pode ser temporária ou permanente, dependendo do que faz sentido. Essa correção deve encontrar um bom equilíbrio entre respeito pelo cliente e respeito por si mesmo. A política pode ser uma ferramenta tão poderosa como o código.
Por exemplo, se apoia uma ferramenta particularmente frágil que não tem muitos recursos de desenvolvimento, e um pequeno número de clientes necessitados a utilizam, considere outras opções. Pense no valor do tempo que gasta fazendo interrupções para este sistema, e se gasta este tempo de forma sensata. Em algum momento, se você não conseguir a atenção necessária para corrigir a causa raiz dos problemas que causam interrupções, talvez o componente que você está dando suporte não seja tão importante. Deve considerar devolver o alerta, depreciando-o, substituindo-o, ou outra estratégia nesse sentido que possa fazer sentido.
Se houver passos particulares para uma interrupção que sejam demorados ou complicados, mas que não exijam que os seus privilégios sejam cumpridos, considere a utilização de uma política para empurrar o pedido de volta para o solicitante. Por exemplo, se as pessoas precisarem doar recursos de computação, prepare uma alteração de código ou configuração ou alguma etapa semelhante e instrua o cliente a executar essa etapa e enviá-la para sua revisão. Lembre-se que se o cliente quiser que uma determinada tarefa seja realizada, deve estar preparado para gastar algum esforço para obter o que deseja.
Uma ressalva para as soluções anteriores é que é necessário encontrar um equilíbrio entre o respeito pelo cliente e por si próprio. O seu princípio orientador na construção de uma estratégia para lidar com os pedidos dos clientes é que o pedido deve ser significativo, ser racional, e forneça todas as informações e todo o trabalho necessário para atender à solicitação. Em troca, a sua resposta deve ser útil e oportuna.
Fonte: Google SRE Book
