Quando as pessoas consideram participar da SRE e as equipes consideram usar as práticas de SRE, uma pergunta comum é “É necessário saber codificação?”
A resposta simples é: sim.
Mas a resposta mais completa é um pouco mais complexa. Vamos examinar três cenários em que a codificação entra na engenharia de confiabilidade de sites, juntamente com o nível de experiência de codificação necessário para cada um. Esta não é a lista completa, mas mostram alguns dos casos de uso mais comuns.
Cenário 1: Removendo a labuta por meio da automação
Os engenheiros de confiabilidade de sites e outros que usam as práticas de SRE tentam sempre que possível remover o trabalho árduo. “Trabalho árduo” significa algo específico em SRE. O trabalho árduo refere-se ao trabalho de operações feito por uma pessoa que tem determinadas características. O trabalho árduo não tem nenhum valor de resgate a longo prazo. Ele não promove o serviço de maneira significativa. Geralmente, ele é repetitivo e principalmente manual (mesmo que possa ser automatizado). Conforme o serviço ou os sistemas aumentarem ao longo do tempo, o número de solicitações para o sistema provavelmente também aumentará em quantidade em uma taxa proporcional e exigirá mais trabalho manual.
Por exemplo, se um serviço precisar que a equipe de SRE redefina algo a cada semana ou provisione novas contas e espaço em disco manualmente, ou reiniciar repetidamente de maneira manual, essa é a carga operacional do trabalho árduo. A conclusão dessas ações não tornou o serviço melhor de nenhuma forma persistente e de longo prazo. Essas ações provavelmente precisarão ser repetidas várias vezes.
As SREs odeiam trabalho árduo. Elas funcionam para eliminá-lo sempre que possível e de forma adequada. Esse é um dos aspectos na qual a automação entra em cena na SRE. Se essas solicitações podem ser resolvidas automaticamente, a equipe fica liberada para trabalhar em coisas mais gratificantes e de maior impacto.
Experiência em codificação: a automação requer certa experiência em codificação, mas não exige todas as habilidades de engenharia de software. Se você souber escrever scripts pequenos (talvez no PowerShell ou no shell do Bourne) ou mesmo se você criar um Aplicativo Lógico do Azure com qualquer código que seja, esse aplicativo ainda poderá ajudar a eliminar o trabalho árduo.
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 o SRE escale verticalmente o trabalho. O provisionamento/desprovisionamento da infraestrutura, a configuração do monitoramento e a integração de vários serviços, tudo isso se torna muito mais eficiente por meio de codificação.
Experiência em codificação: como no cenário anterior, requer certa experiência em codificação, mas não exige todas as habilidades de engenharia de software. Além dos scripts e dos aplicativos lógicos mencionados antes, os modelos do Azure Resource Manager também pode ser usado com uma experiência de codificação mínima.
Cenário 3: Corrigindo o código
Os engenheiros de confiabilidade de sites procuram melhorar a confiabilidade de um sistema. Às vezes, essa meta requer o aprofundamento do código-fonte de um sistema, a determinação do problema e, muitas vezes, a contribuição com uma correção de volta para a base de código. Embora o nível de sofisticação desse trabalho possa variar amplamente com base na situação, a experiência de codificação é um requisito fundamental nesses casos.
Experiência em codificação: a experiência de engenharia de software completa geralmente é necessária neste cenário.
Próximas etapas
Tem interesse em aprender mais sobre SRE (engenharia de confiabilidade de sites) e trabalho de pouco código? Veja nosso hub de engenharia de confiabilidade de sites, com a documentação do produto vinculada acima.