Quando os indivíduos estão considerando se envolver em SRE e as equipes estão pensando em trazer práticas de SRE, uma pergunta comum que surge é "Você precisa saber como codificar?"
A resposta curta: sim.
Mas a resposta completa é um pouco mais matizada. Vamos examinar três lugares onde a codificação entra em jogo na engenharia de confiabilidade do site, juntamente com o nível de conhecimento de codificação necessário para cada um. Esta lista não está completa, mas esses cenários são alguns dos casos de uso mais comuns.
Cenário 1: Remoção da labuta através da automação
Os engenheiros de confiabilidade do local e outros que usam práticas SRE tentam, sempre que possível, remover o trabalho. "Trabalho" significa uma coisa específica em SRE. A labuta refere-se ao trabalho de operações que está sendo feito por um ser humano que tem certas características. As “tarefas enfadonhas” não possuem um valor compensatório a longo prazo. Não fazem progredir o serviço de forma significativa. São, muitas vezes, repetitivas e extremamente manuais (ainda que possam ser automatizadas). À medida que o serviço ou os sistemas ficam maiores, o número de pedidos desse sistema provavelmente também aumentará de forma proporcional e exigirá ainda mais trabalho manual.
Por exemplo, se um serviço exigir que a equipe SRE redefina algo todas as semanas, ou provisione novas contas e espaço em disco manualmente, ou reinicie-o repetidamente manualmente - essa é a carga operacional que está pendente. Concluir essas ações não melhorou o serviço de forma persistente a longo prazo. Estas ações terão, provavelmente, de ser repetidas várias vezes.
As equipas de SRE odeiam este tipo de tarefas. Trabalham para eliminá-las sempre que possível e apropriado. Esta é uma das áreas em que a automatização entra em cena na SRE. Se essas solicitações puderem ser tratadas automaticamente, isso libera a equipe para trabalhar em coisas mais gratificantes e impactantes.
Experiência em codificação: a automação requer algum conhecimento de codificação, mas não precisa exigir habilidades completas de engenharia de software. Se você puder escrever pequenos scripts (talvez no PowerShell ou no shell Bourne) ou mesmo se criar um aplicativo lógico do Azure com quase nenhum código, esse aplicativo ainda pode ajudar a eliminar o trabalho.
Cenário 2: Controle por meio de APIs/linguagens específicas de domínio (DSLs)/modelos
Embora não seja estritamente necessário para o trabalho de SRE, ser capaz de controlar ambientes por meio de APIs, DSLs e modelos (especialmente ambientes de nuvem) permite que os SREs escalem seu trabalho. A infraestrutura de provisionamento/desprovisionamento, a configuração do monitoramento e a integração de vários serviços tornam-se muito mais eficientes por meio da codificação.
Experiência em codificação: como no cenário anterior, isso requer alguns conhecimentos de codificação, mas não precisa exigir habilidades completas de engenharia de software. Além dos scripts e aplicativos lógicos mencionados anteriormente, os modelos do Azure Resource Manager também podem ser usados com experiência mínima de codificação.
Cenário 3: Corrigindo o código
Os engenheiros de confiabilidade do local procuram melhorar a confiabilidade de um sistema. Esse objetivo às vezes requer cavar o código-fonte de um sistema, determinar o problema e, muitas vezes, contribuir com uma correção de volta para a base de código. Embora o nível de sofisticação deste trabalho possa variar amplamente com base na situação, a perícia em codificação é um requisito definitivo nesses casos.
Experiência em codificação: experiência completa em engenharia de software é frequentemente necessária neste cenário.
Próximos passos
Interessado em saber mais sobre engenharia de confiabilidade de site e trabalho low-code? Confira nosso hub de engenharia de confiabilidade do site, a documentação do produto vinculada acima.