O dever é um componente importante da maioria das organizações modernas. Afinal, muitas vezes acontece que o problema chega às três da manhã. Mas quem deveria estar de plantão? E como organizar esse processo para que faça sentido?
Olhe embaixo do gato, Baruch Sadogursky (
@jbaruch ) e Leonid Igolnik (
@ligolnik ) contam uma história de horror sobre um infeliz oficial de serviço. Lembra-se de Vasya, que sempre tinha que
consertar bugs às três da manhã? Este é apenas o começo.
O material foi preparado com base no discurso de Baruch e Leonid na conferência DevOops 2017 do outono.
Tão de plantão. Como exemplo, veja o hipotético Vasya, que trabalha em uma certa empresa há pouco tempo, cerca de um ano. Hoje é sexta-feira e aconteceu que Vasya está de plantão. Tudo vai bem: Vasya está dormindo e seus sonhos são lindos.
Embora ele não suspeite de nada, seu colega de suporte técnico recebe uma ligação de um cliente. Ele diz que na segunda-feira terá que mostrar ao CEO uma demonstração muito importante, mas algo não funciona. Necessidade urgente de corrigir o problema. O suporte fez tudo o que pôde (sugeriu desligá-lo e ativá-lo) e encaminha esse problema ao atendente.
Vasya está de plantão sozinho por todo o projeto, ele terá que fazer isso. Um engenheiro de suporte técnico o acorda e tenta explicar o problema com palavras muito simples: "Algo não está funcionando lá, algo está errado".
Vasya ouve seu colega, pondera o que aconteceu e toma a única decisão certa ...
O engenheiro de suporte está ofendido, mas ainda pede ao cliente que espere até segunda-feira. O cliente não concorda com esse estado de coisas e encaminha o problema ao gerente de suporte. Agora ele liga para Vasya e diz que isso não é sério: "Ainda assim, o assunto é importante, o cliente está preocupado, é necessário". Vasya é uma pessoa responsável. Deve ser necessário: café e dança (procure algo nos registros).
Nos logs, tudo acabou longe de ser simples. Primeiro, Vasya procurava uma pessoa com acesso ao log correto por 15 minutos. Ele encontrou e conseguiu um log. Mas como Para enviar em formato .doc, é claro. Vasya é responsável, jovem e lê o logon do Word: nada é entendido. Mas há palavras-chave que você pode pesquisar na Base de Conhecimento. Vasya aguenta coisas interessantes por cerca de 20 minutos, aprende muito de tudo interessante, mas nada é necessário no momento.
O que Vasya faz a seguir? Você precisa procurar alguém, mas Vasya é um jovem engenheiro e é assustador acordar Sênior. Portanto, ele decide que você precisa chamar um colega, o mesmo júnior.
Um colega é um bom amigo, com dor ao meio ele entende qual é o problema e começa a resolvê-lo. Depois de duas a três horas de trabalho, eles encontraram uma solução. Deve ser imediatamente entregue à produção. Mas como Existe um painel de controle de mudanças, que se reúne às segundas-feiras uma vez a cada duas semanas. Mas essa opção não se encaixa, você precisa urgentemente.
Naturalmente, você não pode implantar na produção, não há raiz. Portanto, a única opção é enviar um arquivo jar com duas classes e um parágrafo de explicações por email. Esses caras entrarão em produção via ssh e colocarão esse arquivo jar no WebSphere no diretório correto. E agora, às 6-7 da manhã, você pode finalmente ir para a cama com uma sensação de realização.
Na segunda-feira, Vasya vem ao trabalho e vê uma imagem incomum. O CEO estava gritando com o vice-presidente de engenharia porque o cliente estava gritando com o CEO porque o CEO estava gritando com ele. Acontece que não foi possível resolver o problema.
As autoridades têm quatro perguntas: "O que aconteceu na sexta-feira?"; "Por que eu ouvi sobre isso do chefe na segunda-feira?"; "Por que a correção levou seis horas?" e "Quem é o culpado?" As operações são chamadas para a sala, que dizem que não é problema deles. Vasya e a outra criada são chamadas para a sala, que também diz: "Nada funcionou". Todo esse jogo de batatas continua até o almoço.
Já que é hora de jantar, a decisão "OK, está quebrada por si só, ninguém tem culpa". O fim da história.
Vamos organizar uma pequena discussão: vamos passar por esse pesadelo e tentar dar respostas a todas as perguntas.
Quem deve estar de plantão
Os administradores de sistemas (ou uma palavra mais moderna - SRE) podem estar de plantão. Eles fazem isso há vários anos, têm tudo bem definido. O DBA pode estar de serviço, aqueles que estão envolvidos em mensagens podem. Se você tiver sorte, o NOC (centro de operação da rede) está de serviço - é quando todos esses caras são colocados na mesma sala. Eles têm runbooks que dizem o que fazer em uma situação difícil.
Tudo está claro com esses caras, eles são profissionais de plantão. Mas, infelizmente, o DevOps tem a segunda parte da equação, que realmente não quer estar de serviço. Como fazer a segunda parte? Sim, e se é necessário forçar, porque os profissionais devem estar cientes da importância do dever.
Há duas razões pelas quais as pessoas não querem estar de plantão. Um é quando:
Ninguém quer estar de plantão quando tudo está ruim. A solução para este problema é bastante simples:
Você precisa escrever um bom código, tudo é simples. Mas isso também precisa ser aprendido. Surge uma nova pergunta: "Como aprender?". Você precisa colocar os dedos no soquete - #painisinstructional. A dor ajuda.
O dever por si só melhora a qualidade do código. O mesmo Vasya na segunda-feira, provavelmente, corrigirá seus erros para não ficar mais uma noite em busca de erros.
Barreiras em serviço
Quando em serviço, existem algumas barreiras que não deveriam estar lá. Vamos passar pelo fiasco de sexta-feira de Vasya. Lembra como ele leu os registros em um documento do Word?
Todos nós amamos os produtos da Microsoft, mas você não pode fazer isso no mundo moderno. Há coisas óbvias sobre logs que todos devem entender.
O ponto principal é o número de ferramentas que resolvem esses problemas: Logstash, Loggly, Sumo logic, Kibana. Eles precisam ser usados.
Voltando à questão do acesso: por que não dar acesso ao log? A resposta são dados confidenciais. Foi prometido aos clientes proteger os dados contra vazamentos. Isso significa que os logs não podem ser mostrados a ninguém ou você precisa usar sistemas com a funcionalidade de mascaramento de dados. Ele próprio oculta dados pessoais e não os mostra a uma pessoa sem o nível de acesso necessário. Todas as ferramentas de análise de log de hoje têm essa funcionalidade.
Outra vantagem dessas ferramentas é que "o monitoramento dos pobres" pode ser construído sobre elas. Por exemplo, nos logs, depois de ver um certo número de erros (a fila está cheia etc.), você pode desencadear uma alergia.
Quem determina a importância do problema
Como entender, entrar em serviço ou executar urgentemente para resolver o problema? Quem nomeia a gravidade? Quem decide o quão crítico é o problema? Resolve suporte. Porque Porque o suporte tem uma visão do problema. Ele sabe o quão ruim tudo é.
Além disso, hoje quase todas as empresas trabalham com o princípio "Entrega contínua", para que todos os clientes recebam todos os recursos ao mesmo tempo (e ao mesmo tempo bugs). Suponha que exista um erro que, para o cliente, pareça "Algo não funciona lá, está tudo bem". Ao mesmo tempo, o suporte recebe centenas de alertas sobre o problema, e isso é obviamente sério.
O cliente também está envolvido na determinação da importância do problema. Mas há um problema - o cliente nem sempre acredita que seu pequeno problema será reparado e coloca a maior importância. A severidade começa a ser usada como uma ferramenta de manipulação. Mas se a definição de gravidade for criada corretamente e o cliente entender o que é SLA, isso geralmente não acontece. Esse é um processo de aprendizado mútuo quando os clientes começam a entender o que é realmente muito importante e o que é simplesmente importante.
Os clientes precisam ter a oportunidade de mostrar importância, porque o fabricante do produto nem sempre entende o contexto do problema.
SLA - uma garantia de resposta e soluções dentro de um dia, mas pode ser mais rápido. Isso, novamente, depende do contexto.
Desafios organizacionais
Vasya não entendeu o problema até o fim. Claro, ele acabou de acordar e um colega de suporte técnico também explicou mal. É tratado de apenas uma maneira: um ticket. Um ticket é um número de referência que informa sobre o que se trata. Isso é necessário para o Vasya, porque, em vez de um telefone, o suporte poderia dizer ao Vasya "Abra nosso sistema de gerenciamento de tickets e veja o número do ticket 42". Isso é necessário por vários motivos. Primeiro, Vasya, em vez de ouvir um colega sonolento, acorda, lê um tíquete e entende como isso é importante. Em segundo lugar, pode haver mais de um problema.
Há outra dificuldade que afeta o quadro geral: Vasya precisa ser encontrado. Como o suporte sabe que Vasya está de serviço hoje? E se ele também não conhecer Vasya. É importante que você encontre a pessoa certa. A solução é extensão virtual com vários prefixos para engenheiro, produção etc. Bem, ou outros sistemas mais sofisticados. Com esta solução, você não precisa adivinhar para onde ligar no meio da noite; tudo muda automaticamente.
Ainda mais conveniente é o Chat de Escalonamento no Slack, Telegram, Skype, em qualquer lugar. O título do bate-papo é o número do mesmo ticket. Toda a comunicação neste ticket entre as pessoas certas ocorre nesta sala de bate-papo. Um dos recursos mais úteis desse chatik é que você não precisa contar nada para quem entra no trabalho depois de um tempo. Você pode simplesmente ler sobre quais decisões já foram tomadas.
Bem, uma ponte telefônica virtual, que pode ser comparada a um local de encontro em caso de incêndio: todo mundo sabe para onde ir em caso de problemas. A propósito, em sistemas modernos como o Zoom ou o Bluejeans, toda a funcionalidade necessária já está embutida.
Caminho de escalação
Vasya tinha medo de chamar o senhor, porque eles são terríveis. O que fazer com isso? Vamos falar sobre o caminho de escalação. Você sempre deve saber quem e quando acordar ou sair do trabalho. Isso deve ficar perfeitamente claro para todos: para quem acorda e para quem acorda. Você também precisa saber para onde ligar se o primeiro caminho não funcionou. Um bom caminho de escalada vai até o CEO da empresa.
Existem comunicações que devem vir do CEO. Ele deve estar ciente de questões críticas.
Gerente de recados
A próxima posição interessante é gerente de plantão. Ele não precisa ser um técnico e participar da solução de um problema. Primeiro, Vasya no meio da noite não pode dizer nada útil ao cliente. O gerente de serviço pode ajudar nessa situação. Além disso, ele pode se envolver em coordenação, gerenciamento de projetos em uma situação difícil, gerenciamento de recursos. Afinal, o trabalho deve ocorrer sem problemas.
Acesso à Produção
Devo dar à Vasya acesso à produção? Afinal, nem todos são engenheiros brilhantes, e há certas coisas que eu não gostaria de aprender; os clientes ficarão ofendidos. Isso é resolvido usando o processo de implantação. Se o processo estiver configurado corretamente, Vasya poderá clicar no botão que, como resultado, seu código de produção será desativado. Se você tiver um pipeline de entrega contínua normal, provavelmente isso poderá ser feito automaticamente (todos os testes serão aprovados). Caso contrário, em muitas empresas a decisão é tomada por um engenheiro ou gerente sênior. Ele analisa, avalia o risco do código e toma uma decisão.
E mesmo antes do hotfix aparecer, as ferramentas documentadas para solução de problemas devem estar envolvidas. Um dos problemas mais comuns em serviço: ele começa a pensar em como ativar a depuração ou alterar o nível dos logs. Ao mesmo tempo, não há problema com todo o resto. É aconselhável ter soluções documentadas para os problemas.
Mudança de dever
Agora vamos falar sobre o processo do dever, que geralmente leva uma semana. Em algum momento é necessário mudar. Para mudar com eficiência, isso deve ser feito em um determinado momento. É necessário planejar tudo claramente e é desejável poder efetivamente transferir os problemas para a próxima pessoa de plantão. Em muitas empresas, isso é feito como uma reunião padrão ou é criada uma página na qual o atendente mantém uma pequena revista.
Outros problemas
Existem vários outros problemas que precisam ser resolvidos. Um deles é a certificação de acesso à produção. É aconselhável realizar a certificação elementar para que uma pessoa mostre que entende o que é possível e o que não é.
Como traduzir?
Mas como tudo isso pode ser levado para a empresa? Você precisa entender que isso levará algum tempo.
Precisamos começar com os caras mais velhos de plantão. Eles têm experiência e sabem o que e como reparar. O senhor tem menos problemas: há acesso aos logs, etc.
É aconselhável começar em uma equipe pequena. Se a equipe já for grande, você precisará criar uma pequena dentro dela. Além disso, quando tudo começa a funcionar bem, você pode envergonhar o resto.
Conclusões
Passamos para a coisa principal. Apesar do fato de que nós técnicos somos apaixonados por tecnologia, o mais importante não são os produtos e tecnologias usados na empresa, mas o sentimento da pessoa de plantão "Estou envolvido no processo de melhoria do produto" (ou do próprio dever). Muitas pessoas entendem que você precisa estar de serviço, mas deseja ver melhorias. As pessoas devem estar cientes de que, graças a elas e a suas melhorias, as coisas estão melhorando.
PS
Queremos recomendar um livro chamado Drive. Este é um livro sobre a motivação de pessoas que trabalham em profissões como a nossa. Essa motivação consiste em três componentes principais e (spoiler) nenhum deles é dinheiro.
Já neste domingo, Baruch e Leonid entregarão um relatório "#DataDrivenDevOps" no DevOops 2018 em São Petersburgo. Venha, haverá muitas coisas interessantes: aqui estão os relatórios , aqui está John Willis , e aqui está uma festa com BoFs e karaokê . Esperando por você!