paint-brush
Engenheiro de serviço perfeitoby@alexeysutyagin
561
561

Engenheiro de serviço perfeito

Alexey Sutyagin10m2022/11/10
Read on Terminal Reader
Read this story w/o Javascript

Muitas empresas de TI adotaram a prática do plantão de plantão. As atribuições do engenheiro nessa função variam de empresa para empresa, mas há alguns pontos em comum. Para ser um bom engenheiro de plantão, se ocorrerem problemas, você precisa resolvê-los da forma mais rápida e econômica possível. Um engenheiro bem treinado sabe onde pode lidar sozinho e onde vale a pena escalar ainda mais a situação. Falaremos sobre como estar bem preparado para trabalhar como engenheiro neste artigo.

Company Mentioned

Mention Thumbnail
featured image - Engenheiro de serviço perfeito
Alexey Sutyagin HackerNoon profile picture


Introdução

Muitas empresas de TI adotaram a prática do plantão de plantão. Um engenheiro está de plantão e seu dever dura um turno. Normalmente, o turno dura um dia ou uma semana. Há casos de aumentar ou diminuir esse período, mas isso é raro. As atribuições do engenheiro nessa função variam de empresa para empresa, mas há alguns pontos em comum.

  • Você tem que responder às perguntas que vêm para a equipe.
  • É necessário monitorar o desempenho dos serviços pelos quais a equipe é responsável.
  • Para lidar com incêndios e incidentes.
  • Escale o incidente ainda mais se você não conseguir descobrir.

Falaremos sobre como estar bem preparado para trabalhar como engenheiro neste artigo.

Definição de engenheiro de serviço perfeito

Se ocorrerem incidentes ou incêndios em seu turno em um ambiente de combate, isso não significa que você seja um péssimo engenheiro. Para ser um bom engenheiro de plantão, se ocorrerem problemas, você precisa resolvê-los da forma mais rápida e econômica possível. Um engenheiro bem treinado sabe onde pode lidar sozinho e onde vale a pena escalar ainda mais a situação. Ele deve saber quando e a quem pedir ajuda. Ele não deve permitir, se possível, que os mesmos problemas se repitam.

Experiência

É útil aproveitar a sua experiência e a da equipe para se preparar melhor para o serviço.

É uma boa ideia começar verificando qual documentação já existe para lidar com incidentes. Existe documentação no nível da empresa ou da equipe? É essencial saber onde está e estar familiarizado com ele. Se não existir, você poderia tentar iniciar o processo de criação de um?

Em seguida, vale a pena verificar quais incidentes já aconteceram e como eles são registrados no armazenamento de conhecimento. Há alguma autópsia e há tarefas a serem corrigidas? Você sabe se essas tarefas estão sendo feitas? Se forem criadas tarefas para corrigir a situação, mas não implementadas, esse é um motivo para discutir isso em uma reunião com seu gerente.

Você sabe se as funções do engenheiro de plantão são registradas? Pelo que eles são responsáveis e pelo que não são? Se não houver tal documentação ou entendimento, seria útil para toda a equipe ter um.

Ferramentas

O kit de ferramentas para o engenheiro de plantão é específico e um pouco diferente do kit de ferramentas do dia a dia do desenvolvedor. As principais tarefas que surgem durante o combate a incêndios são aquelas que não podem ser resolvidas pelas consultas existentes

Vejamos essas ferramentas com mais detalhes:

  1. A principal ferramenta técnica para o dever, com a qual você pode resolver muitos problemas, é o bash. Se o conhecimento desta bela ferramenta ainda não estiver em seu arsenal - use um dos cursos intensivos (
  2. Muitas vezes, no modo de disparo, você precisa executar algumas operações com o banco de dados do produto. A habilidade de trabalhar com o banco de dados via terminal - psql para PostgreSQL https://www.postgresguide.com/utilities/psql/ ou mongosh para MongoDB https://www.mongodb.com/docs/mongodb-shell/ ajudará . Essas ferramentas são fornecidas como exemplos, você pode pesquisar em seu próprio banco de dados. Para muitos bancos de dados, existem ferramentas visuais para trabalhar, mas o terminal está disponível em qualquer lugar, requer o mínimo de internet e é muito flexível. Para o modo de fogo, pode ser muito útil.
  3. O curl é uma ferramenta que permitirá fazer um número considerável de consultas e, quando combinado com o conhecimento do bash, você se tornará quase onipotente.

Será muito útil se você tiver um conjunto de scripts prontos em mãos na hora do incêndio. Eles devem ser tão simples e diretos quanto possível. Sim, você provavelmente pode escrevê-los muito rapidamente, mas quando você tem tempo limitado, é ótimo ter um conjunto pronto que permite que você pense apenas na falha e não em como implementar a mesma vinculação. Os scripts abaixo são apenas uma representação da estrutura potencial de tais scripts. Obviamente, seu código deve ser testado antes do incidente e ser o mais simples e direto possível. É útil ter os seguintes scripts:

Um script que gera um arquivo a partir dos dados fornecidos. Estes podem ser obtidos de outros comandos ou fazendo uma solicitação independente. Um exemplo de tal script em Python é mostrado abaixo.

 import csv def modify(filename): tmpFile = "tmp.csv" # Reading file with data and creation of output file with open(filename, "r") as file, open(tmpFile, "w") as outFile: # Create reader for initial file reader = csv.reader(file, delimiter=',') # Create writer for output file writer = csv.writer(outFile, delimiter=',') # Read header line header = next(reader) # Write header line writer.writerow(header) # Process initial file line by line for row in reader: colValues = [] # Process each column of each line for col in row: # Let for example transform all columns to lowercase colValues.append(col.lower()) # Write modified line to final file writer.writerow(colValues) filename = 'sample_data.csv' modify(filename)

Um script que chamará os terminais necessários com o paralelismo especificado. Não precisa ser nada complicado. Abaixo está um exemplo de um código JavaScript simples que irá gerar um arquivo sh com o paralelismo especificado que pode te ajudar com isso. Sim, não temos tratamento de resultados aqui, mas nem sempre é necessário, e você pode modificar seu kit de ferramentas com uma versão de tratamento de resultados, se necessário. Por exemplo, temos um arquivo que lê e grava todos os dados, mas você pode criar scripts de fluxo para arquivos enormes.

 const fs = require('fs'); const initialFilePath = 'sample_data.csv'; const outputFilePath = 'sample_script.sh'; const amountOfParallelRequests = 5; // Remember about the throughput and the bandwidth of your services const delimiterForCSV = ','; // Read the initial file and split it by lines // You could transform it to an object if it's relevant to your situation let initialFile = fs.readFileSync(initialFilePath).toString().split('\n'); // Prepare boilerplate for sh script let outputString = '#!/bin/bash\n\n'; // Write data with parallel execution // Skip header for CSV // The code for parallel requests was received from https://serverfault.com/questions/456490/execute-curl-requests-in-parallel-in-bash // and you could implement your version instead for (let i = 1; i < initialFile.length; i++){ let line = initialFile[i]; if (!line) { continue; } let processedLine = line.split(delimiterForCSV); // We don't implement processing of errors here // Let's suggest that the necessary for request value lies in second column let desiredValue = processedLine[1]; if (desiredValue === undefined) { console.error('We have a trouble ' + line); } outputString += `curl -s -o foo http://example.com/file${desiredValue} && echo "done with ${desiredValue}" &\n`; if (i % amountOfParallelRequests === 0 || i === initialFile.length - 1) { outputString += '\nwait\n\n'; } } fs.writeFileSync(outputFilePath, outputString); // Indicate the success console.log('Success');

Um script que obtém algo de um banco de dados ou serviço e devolve o resultado convertido ou talvez chame outro terminal. Sugiro implementá-lo você mesmo, sem esquecer a autorização e os cenários de uso apropriados.

Conhecimento

Além de ferramentas e experiência, um certo conhecimento é útil quando você está de plantão.

Gostaria de saber sobre os logs e métricas de seus serviços. Para onde eles vão e como você chega lá? Por acaso você saberia usar essas ferramentas? Quando você recebe uma ligação à noite de um serviço de plantão informando que seu serviço está inoperante, é do seu interesse descobrir rapidamente o que está acontecendo de errado. Para fazer isso, você precisa saber exatamente onde suas métricas e logs armazenam e o que observar primeiro.

Como adiar alertas? Depois de analisar o incidente, muitas vezes descobre-se que o acidente atual pode estar esperando pela manhã, por isso é bom entender como adiar o alerta. Não para fechar, pois no caso de algumas operações você será avisado novamente, mas justamente para adiar. Você deve se lembrar de lidar e corrigir a situação ou alertar assim que iniciar seu dia normal de trabalho.

Onde estão os contatos ou como você entra em contato com colegas ou membros de outras equipes? Deve haver uma ferramenta ou conhecimento claro em sua cabeça - quem entende/deve saber sobre a situação quando ela aconteceu. Os especialistas podem ajudá-lo a resolver o incidente e as partes interessadas precisam saber que algo está errado. Você deve ter acesso aos seus contatos, de preferência ao telefone, porque muitas pessoas desativam as notificações dos chats do escritório fora do horário comercial.

Como você obtém acesso à produção/banco de dados e aumenta o acesso se existem níveis de acesso? Se você não tiver acesso, precisará saber a quem recorrer ou o que fazer para obter o acesso desejado.

Como você coloca o código em produção rapidamente? Às vezes, os problemas exigem uma alteração rápida no código do serviço em produção. Em geral, isso é considerado uma prática ruim, mas muitas vezes em uma emergência, esse não é o caso. Às vezes, você não quer esperar por longos testes E2E, mas precisa obter rapidamente o código no ambiente de produção. Gostaria que você entendesse como fazer isso.

Quais dados são armazenados no banco de dados? Existem esquemas de movimentação de dados dentro do produto e entre serviços? Se você precisa interagir com o banco de dados, é bom saber como os dados estão organizados em um determinado serviço, de onde vêm e quem os utiliza. Isso permitirá que você lide com problemas, se houver algum, mais cedo.

Além de ferramentas e experiência, um certo conhecimento é útil quando você está de plantão.

Gostaria de saber sobre os logs e métricas de seus serviços. Para onde eles vão e como você chega lá? Você sabe como usar essas ferramentas? Quando você recebe uma ligação à noite de um serviço de plantão informando que seu serviço está inoperante, é do seu interesse descobrir rapidamente o que está acontecendo de errado. Para fazer isso, você precisa saber exatamente onde suas métricas e logs armazenam e o que observar primeiro.

Como adiar alertas? Depois de analisar o incidente, muitas vezes descobre-se que o acidente recente pode estar esperando pela manhã, por isso é bom entender como adiar o alerta. Não para fechar, pois, no caso de algumas operações, você será avisado novamente, mas justamente para adiar. Seria melhor se você se lembrasse de lidar e corrigir a situação ou alertar assim que começar seu dia normal de trabalho.

Onde estão os contatos ou como você entra em contato com colegas ou membros de outras equipes? Deve haver uma ferramenta ou conhecimento preciso em sua cabeça - quem entende/deve saber sobre a situação quando ela aconteceu. Os especialistas podem ajudá-lo a resolver o incidente e as partes interessadas precisam saber que algo está errado. Você deve ter acesso aos seus contatos, de preferência ao telefone, porque muitas pessoas desativam as notificações dos chats do escritório fora do horário comercial.

Como você obtém acesso à produção/banco de dados e aumenta o acesso se existem níveis de acesso? Se precisar de acesso, você precisa saber a quem recorrer ou o que fazer para obter o acesso desejado.

Como você coloca o código em produção rapidamente? Às vezes, os problemas exigem uma alteração rápida no código do serviço em produção. Em geral, isso é considerado uma prática ruim, mas muitas vezes em uma emergência, esse não é o caso. Às vezes, você deseja obter rapidamente o código no ambiente de produção antes de longos testes E2E. Gostaria que você entendesse como fazer isso.

Quais dados são armazenados no banco de dados? Existem esquemas de movimentação de dados dentro do produto e entre serviços? Se você precisa interagir com o banco de dados, é bom saber como os dados estão organizados em um determinado serviço, de onde vêm e quem os utiliza. Isso permitirá que você lide com problemas, se houver algum, mais cedo.

Conclusão

Mesmo em empresas e equipes com uma excelente cultura de engenharia, acidentes e incêndios em serviço acontecem. Para evitar isso, a equipe deve fazer todos os esforços para melhorar os processos e produtos atuais. Ainda assim, cada engenheiro também deve estar preparado para que um acidente aconteça e tenha que lidar com isso com urgência. Para isso, vale a pena usar toda a experiência pessoal e de equipe acumulada. Vale a pena conhecer a organização e os serviços e ter confiança no seu kit de ferramentas.

Links Úteis

https://zach-gollwitzer.medium.com/the-ultimate-bash-crash-course-cb598141ad03

https://www.youtube.com/watch?v=oxuRxtrO2Ag

https://www.postgresguide.com/utilities/psql/

https://www.mongodb.com/docs/mongodb-shell/