No último dia 30 de maio, aconteceu, em Santa Clara, Califórnia (EUA), a primeira conferência dedicada a “Site Reliability Engineers” (SRE), ou “Production Engineers” (PE) como somos chamados no Facebook. O evento é chamado SREcon. Tive a honra de ser uma das três pessoas convidadas pela Usenix para criar o programa do evento, dedicado a ambientes de produção de larga escala.

Uma das motivações para criação da SREcon foi criar um evento focado no trabalho que esses engenheiros fazem, de Production Engineer para Production Engineer (PE), com foco no que fazemos todos os dias: criar soluções de engenharia para desafios operacionais. Acho que é interessante explicar a dinâmica desse trabalho, então resolvi dedicar essa edição a tentar esclarecer um pouco o que significa ser um “Production Engineer” ou um “Site Reliability Engineer”.

De tempos em tempos, temos Hackathons no Facebook. Nesses eventos, engenheiros passam horas trabalhando em projetos muitas vezes ambiciosos, que não necessariamente tenham relação com o que eles fazem no dia a dia. Numa reunião de PE logo em seguida de um dos eventos, estávamos compartilhando quais projetos tínhamos trabalhado na última Hackathon. Um dos engenheiros comenta: “Eu fiz nosso servidor de DNS ficar mais rápido”. Do outro lado da sala, alguém pergunta “Mais rápido quanto?”, e o cara responde “100 vezes mais rápido”.

Na minha equipe, passamos um tempo pensando em como otimizar o algoritmo que usamos para distribuição de informação nos clusters que fazem armazenamento de dados em memória. Nossa intenção era encontrar uma forma de distribuir esses dados de maneira que melhorasse a distribuição da carga. Depois de alguns testes, muita análise de dados e muitos “brainstormings”, conseguimos otimizar a eficiência em 40%. Mais análise de dados referentes ao comportamento dos objetos em memória, e descobrimos a periodicidade que precisamos refazer esse mapeamento de carga.

Quando estamos pensando em operações de larga escala, é importante que cada desafio operacional seja respondido com uma solução de engenharia. Se você tiver que fazer a mesma coisa duas vezes, manualmente, tenha certeza que existe alguma coisa errada no modo de operação da sua equipe. E o trabalho, com o passar do tempo, vai se tornando chato.

PEs são profissionais dedicados a tudo que existe em torno de cada produto que compõe infra estrutura, mas geralmente não do produto em si. Muitas vezes, grande parte dos planos das equipes de analistas que trabalham no desenvolvimento desses produtos são influenciados pelos profissionais que têm a responsabilidade de fazer com que, uma vez todas as peças estejam supostamente no lugar, tudo vai funcionar como deveria. E de forma eficiente.

Performance, eficiência, confiabilidade são parte do dia a dia desse tipo de profissional. Como otimizar o uso de CPU de um sistema? Como melhorar o desempenho de certos tipos de requisições? Como propagar mudanças de configuração para milhares de computadores?

De um ponto de vista disciplinar, o que muda de um analista de sistemas para um PE ou SRE não é a profundidade do conhecimento, mas a diversidade dele: PEs precisam entender de redes, arquitetura, sistemas, desenvolvimento e operações.

A cada dia, novos desafios se revelam, novas possibilidades para ganhos em performance, novas possibilidades para melhorar a compreensão da mudança de comportamento desses sistemas com o tempo. E o quanto mais engenharia colocamos em resolver operações, menos operações precisam ser feitas de forma manual, e mais tempo pode ser dedicado a quebra-cabeças cada vez mais complexos.

E tudo isso tem que acontecer com o sistema rodando, sem afetar o ambiente de produção. É muito mais do que pilotar um jato: é pilotar um jato e refazer o motor em pleno voo.

***

Artigo publicado na Revista iMasters. Você pode assinar a Revista e receber as edições impressas em casa, saiba mais.