Como o ING Bank implantou um cultura SRE entre as equipes

Janna Brummel e Robin van Zijll, do banco ING, da Holanda, palestraram na conferência Velocity, em Londres, sobre a falta de disponibilidade de seus sistemas bancários na internet, algo que levou o banco a implementar uma cultura SRE. Uma equipe centralizada de SRE foi criada na Holanda para fornecer ferramentas, consultoria e educação sobre confiabilidade para equipes de produtos (conhecidas internamente como “esquadrões BizDevOps”).

Em meados de 2017, as métricas da ING mostravam que a disponibilidade dos sistemas de varejo bancário na internet havia baixado para 96,84%, em contraste com outros sistemas – varejo e bancário em dispositivos móveis – mais próximo da marca ideal de 99,99%. Alguns dos fatores que levaram a esse resultado incluíam: falta de monitoramento de propriedade pelas equipes de produtos; um sistema de alerta centralizado desencadeado em um nível muito alto (system down) levando muito tempo para diagnosticar e delegar o problema aos engenheiros (69 minutos, em média, para um grande incidente); comentários infrequentes pós-incidentes e compartilhamento de lições aprendidas; e ausência de insights sobre disponibilidade em nível de componente (resultados agregados em nível de serviço só contribuíram para que as equipes de produtos não se sentissem diretamente responsáveis).

A equipe centralizada de SRE exerce apenas a função de consultoria – eles não executam nem são responsáveis pelos serviços – mas atuam como uma equipe de plataforma, fornecendo ferramentas e serviços internos para ajudar as equipes de produtos a executarem e melhorarem a confiabilidade de seus sistemas. O planejamento e priorização do backlog da equipe é orientado pela hierarquia de confiabilidade do serviço, conforme definido no livro SRE do Google:

Até agora, a equipe SRE concentrou-se principalmente nas três camadas inferiores da pirâmide. Em termos de monitoramento e resposta a incidentes, eles estão construindo ferramentas compartilhadas, baseadas em Prometheus, Grafana e Mattermost (ChatOps). Eles facilitam o ‘postmortems’ pelas equipes de produtos e fornecem consultoria sobre como identificar e corrigir problemas de confiabilidade. Brummel e Van Zijll mencionaram como passaram por muito tempo e esforços conjuntos para eliminar a cultura de culpa existente em torno de grandes incidentes. Eles aconselham a investir tempo criando conscientização e configurando a cena antes de realmente aumentar a frequência das revisões de incidentes, caso contrário os mesmos podem produzir efeitos [bem] negativos.

Todas essas mudanças foram lançadas sob demanda, não como uma iniciativa de “big bang“, permitindo que as equipes de produtos decidissem se mudar para as ferramentas e práticas propostas pela equipe SRE. Este último também está em processo de escala de uma equipe com alguns engenheiros para uma comunidade de prática maior (com várias equipes de SRE em diferentes países – atualmente três equipes na Holanda, uma na Espanha e uma na Austrália). Demonstrações e discussões internas sobre temas de SRE ajudam a construir a comunidade.

Todas essas mudanças foram lançadas sob demanda, possibilitando às equipes de produtos decidirem se alternariam para ferramentas e práticas propostas pela equipe de SRE. Esta último também está em processo de escala de uma equipe com alguns engenheiros para uma comunidade bem maior – ou seja, com várias equipes SRE em diferentes países – atualmente três equipes na Holanda, uma na Espanha e uma na Austrália). Demonstrações e discussões internas sobre temas de SRE ajudam a construir e fortalecer as comunidades.

Os aprendizados e dicas de Brummel e Van Zijll até agora em suas jornadas SRE incluem:

• Valorização do mindset SRE em habilidades específicas ao contratar;
• A equipe SRE precisa de um product owner para proteger o time de prioridades conflitantes;
• Esteja pronto para gastar muito tempo explicando e promovendo o SRE para equipes de produtos;
• As ferramentas fornecidas precisam ser de qualidade comercial em termos de usabilidade e precisam aliviar pontos de dor reais de seus usuários;
• Considere escalabilidade e propriedade em sua estratégia de ferramentas.

 
Fonte: InfoQ

Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.