Como uma cultura de confiabilidade ajuda as equipes a construir sistemas e processos mais confiáveis.
Quando pensamos em confiabilidade, normalmente pensamos na confiabilidade dos sistemas. A realidade é que a confiabilidade começa com as pessoas. Ao incentivar os engenheiros de confiabilidade, equipe de gestão de incidentes, desenvolvedores de aplicativos e outros membros da equipe a pensar de forma proativa sobre confiabilidade, podemos estar mais bem preparados para identificar e corrigir as falhas.
Nesta seção, explicaremos o que é uma cultura de confiabilidade, como promover e desenvolver e como ela ajuda a melhorar nossos processos e sistemas.
Uma cultura de confiabilidade é aquela em que cada membro de uma organização trabalha para o objetivo comum de maximizar a disponibilidade de seus serviços, processos e pessoas . Os membros da equipe estão focados em melhorar a disponibilidade e o desempenho de seus serviços, reduzindo o risco de interrupções e respondendo a incidentes o mais rápido possível para reduzir o tempo de inatividade.
Tradicionalmente, as equipes de engenharia de software tratavam a confiabilidade da mesma forma que tratavam os testes: como um estágio distinto no ciclo de vida do desenvolvimento. Isso fez com que a confiabilidade se tornasse responsabilidade exclusiva das equipes de garantia de qualidade (QA) e de operações. À medida que os sistemas se tornaram mais complexos e a velocidade de desenvolvimento aumentou, a confiabilidade tornou-se uma responsabilidade compartilhada não apenas entre testadores e equipes de operações, mas também entre os desenvolvedores que criam aplicativos, os gerentes que lideram essas equipes, os gerentes de produto resolvendo os pontos problemáticos do cliente e até os executivos responsáveis pelo orçamento e lançamento de iniciativas em toda a empresa. Todas essas equipes devem estar alinhadas com o objetivo de tornar os serviços da organização mais confiáveis para melhor atender seus clientes, e chamamos esse foco em toda a organização de “cultura de confiabilidade”.
Mas por que precisamos de toda uma cultura focada na confiabilidade? Não poderíamos simplesmente escrever mais casos de teste automatizados ou conectar uma ferramenta ao nosso pipeline de CI/CD para testar nossos aplicativos? Por um lado, a confiabilidade é afetada por todos os estágios do ciclo de vida de desenvolvimento de software (CVDS) , desde o design até a implantação. Falhas são mais caras para serem corrigidos posteriormente no CVDS , principalmente se acabarem causando incidentes de produção.
Em segundo lugar, os aplicativos e sistemas modernos são mais complexos e têm mais partes interconectadas. Embora o teste tradicional seja bom para testar componentes individuais, é inadequado para testar todo um sistema de forma holística. Melhorar a confiabilidade significa testar e fortalecer essas interações complexas para evitar que falhas em um componente destruam todo o sistema.
Por fim, as organizações tendem a priorizar outras iniciativas em vez da confiabilidade, como encurtar os ciclos de desenvolvimento e lançar rapidamente novos recursos. Isso não ocorre porque a confiabilidade não é importante, mas sim porque não é uma prioridade para muitas equipes. Sem um forte incentivo vindo da organização, os esforços e iniciativas para melhorar a confiabilidade são menos propensos a ter sucesso. O desenvolvimento mais rápido de recursos pode até dificultar os esforços de confiabilidade, tornando os sistemas menos confiáveis.
Em última análise, a cultura de confiabilidade se concentra em um único objetivo: fornecer a melhor experiência possível ao cliente. Esse foco singular nos clientes orienta todos os outros aspectos da confiabilidade, desde o desenvolvimento de aplicativos e sistemas mais resilientes até o treinamento de engenheiros de confiabilidade para responder a incidentes com mais eficácia. Quando há uma correlação clara entre a satisfação do cliente e a confiabilidade, as organizações ficam mais motivadas a investir o tempo, a energia e o orçamento necessários para tornar os sistemas e processos mais confiáveis. Também vincula diretamente o trabalho de confiabilidade à missão principal da empresa, consolidando-o ainda mais como uma prática importante.
A quantidade de tempo e esforço necessários para construir uma cultura de confiabilidade escala com o tamanho da organização. Mesmo em startups, onde os indivíduos estão acostumados a mudar rapidamente, garantir que todos estejam alinhados com os mesmos objetivos é um desafio. Ao construir uma cultura de confiabilidade, precisamos considerar nosso objetivo.
O principal objetivo de melhorar a confiabilidade é manter nossos sistemas e serviços disponíveis. Interrupções frequentes resultam em perda de receita, perda de confiança do cliente e tempo de engenharia gasto respondendo a incidentes em vez de melhorar nosso produto ou serviço. Mas, embora esse seja um objetivo vital em todas as organizações, nem sempre é um argumento convincente. Então, o que é?
A resposta a esta pergunta deve estar intimamente ligada à declaração de missão da organização. Se não tivermos uma declaração de missão ou objetivo, devemos começar focando em nossos clientes. Como podemos fornecer a melhor experiência possível ao cliente e como isso se traduz no trabalho diário realizado por nossa organização?
Essa pergunta deve estar em primeiro lugar em toda a organização, especialmente em equipes de produtos, equipes de engenharia, equipes de suporte ao cliente e equipes de executivos. Cada equipe deve estar ciente de como seu papel e responsabilidades contribuem para a experiência do cliente. Por exemplo, se um desenvolvedor escreve um código fora das melhores práticas, isso pode resultar em desempenho mais lento e latência aumentada que faz com que o cliente abandone o produto. Ao enquadrar a confiabilidade em torno dos clientes, podemos mais facilmente começar a pensar em como diferentes equipes podem afetar as metas de confiabilidade.
Para alinhar as equipes, devemos repetir nossa declaração de missão com frequência. Destaque-o durante reuniões, integração de funcionários e ao planejar novas iniciativas. Se surgirem dúvidas sobre quais são nossos objetivos ou metas de confiabilidade, devemos sempre relacioná-los com os do cliente.
É comum que as mudanças organizacionais enfrentem resistência. Você pode ouvir argumentos de que o teste de confiabilidade é muito complicado, que levaria um tempo valioso do desenvolvimento de recursos ou que você já está muito ocupado com o gerenciamento de incidentes. Embora o investimento em confiabilidade exija um investimento inicial, os benefícios que ele traz superam em muito os custos. Esses incluem:
As equipes geralmente não pensam em confiabilidade até o final do ciclo de vida de desenvolvimento de software (CVDS). Com a complexidade e o rápido desenvolvimento dos aplicativos modernos, esse processo não é mais escalável ou totalmente eficaz. Ele não apenas cria um obstáculo para a produção e diminui os ciclos de lançamento, mas também não consegue encontrar falhas inesperados presentes nos sistemas modernos.
A solução é fazer o shift left para que o teste de confiabilidade seja feito em todo o CVDS pelo time de controle de qualidade, não apenas no final. Ao planejar um novo recurso ou serviço, começamos a planejar a experiência do cliente que queremos fornecer já na fase de levantamento de requisitos. Os gerentes de produto definem as expectativas para a qualidade do serviço antes do início do desenvolvimento, os engenheiros de disponibilidade, testadores e os desenvolvedores de software definem métricas para medir e rastrear a conformidade com esses requisitos e, em seguida, testamos continuamente nossa capacidade de atender a esses requisitos durante todo o desenvolvimento.
Ao priorizar a confiabilidade desde o início, o foco em melhorar a confiabilidade naturalmente se estende a cada equipe envolvida no processo de desenvolvimento. Isso nos dá um início antecipado para encontrar e resolver defeitos, incentiva boas práticas de desenvolvimento e reduz o risco de problemas chegarem à produção. Isso também traz benefícios financeiros, pois os bugs são mais caros para serem corrigidos posteriormente no CVDS.
A cultura é um passo importante, mas também precisamos de ferramentas que nos ajudem a colocar a cultura em prática. Precisamos de uma maneira de garantir que nossas equipes de resposta estejam preparadas para lidar com incidentes, nossos sistemas sejam resilientes a falhas técnicas e nosso foco em práticas de confiabilidade tenham um claro retorno sobre o investimento (ROI) para o negócio. A forma como fazemos isso é com a Engenharia do Caos.
A Engenharia do Caos é a prática de injetar deliberadamente falhas em um sistema, observando como o sistema responde, usando essas observações para melhorar sua confiabilidade e validando que nossos mecanismos de resiliência funcionam. Podemos usar a Engenharia do Caos para validar sistemas e processos organizacionais. Isso inclui gerenciamento e resposta a incidentes, recuperação de desastres e processos de solução de problemas.
A Engenharia do Caos ajuda as equipes a testar proativamente as ameaças à confiabilidade e abordá-las no início do processo de desenvolvimento, reduzindo o risco de incidentes ou interrupções. Isso inclui testar planos de resposta a incidentes, validar se os sistemas são tolerantes a falhas para um redundância ou de backup e muitos outros cenários.
Como a Engenharia do Caos ajuda a construir uma cultura de confiabilidade? A resposta é ajudar as equipes a testar suas suposições sobre seus sistemas, buscar ativamente maneiras de melhorar a confiabilidade e garantir que os sistemas sejam resilientes às condições de produção. Uma estratégia comum para fazer isso é com os GameDays (recurso da ferramenta Gremlin), que são incidentes deliberadamente planejados em que uma equipe de engenheiros que possui um aplicativo ou serviço (junto com outras partes interessadas, como líderes de equipe e gerentes de produto) se reúne para executar um experimento de caos no serviço. A equipe executa o experimento, observa o serviço para ver como ele responde e usa seus insights para melhorar a sua resiliência. Eles então automatizam o experimento, adicionam-no à sua biblioteca de experimentos e executam esses experimentos continuamente para verificar se seus sistemas permanecem resilientes.
Um GameDay típico dura entre 2 e 4 horas e envolve os seguintes membros da equipe:
Para ajudar a construir uma prática de confiabilidade, execute o GameDays regularmente. Equipes com alta disponibilidade tendem a realizar experimentos semanalmente, mensalmente ou trimestralmente. Em geral, a execução de GameDays mais frequentes pode ajudá-lo a atingir suas metas de confiabilidade mais rapidamente, portanto, considere agendar GameDays semanais ou quinzenais.
Quando suas equipes estiverem confortáveis com a execução de incidentes planejados, considere adicionar incidentes não planejados. Estes são chamados de FireDrills. Como um GameDay, um FireDrill envolve o uso de Engenharia do Caos para simular falhas em um sistema. A diferença é que as equipes que respondem a um FireDrill não sabem que é um exercício. Isso faz com que eles reajam de maneira mais realista, como se fosse um incidente real, mas mantém a capacidade de parar e reverter o incidente, se necessário.
Os FireDrills são eficazes para ajudar as equipes:
Recomendamos executar FireDrills semanalmente ou quinzenalmente, mas somente depois que sua equipe tiver praticado a execução de GameDays. Designe um líder que possa coordenar o FireDrill, de preferência um líder de equipe que entenda os sistemas que estão sendo atacados. Isso garante que alguém esteja sempre disponível para responder rapidamente se algo inesperado acontecer ou se o FireDrill precisar ser cancelado.
Incidentes vão acontecer, e tudo bem. Nenhum sistema é perfeito. Quando algo der errado, tome medidas corretivas e resolva a causa raiz o mais rápido possível. Então, quando seus sistemas estiverem operacionais, faça uma investigação e avaliação profunda de sua resposta. Investigue a causa raíz do problema, as etapas que a equipe executou para resolvê-lo, as métricas e outros dados de observabilidade que ajudaram a resolver o problema e o que a equipe fez para evitar que o problema se repetisse.
Falhas acontecem: O caos vai acontecer, e nós devemos buscar as falhas apenas para aprender. Fora da zona de conforto é onde mais aprendemos.
Site Reliability Engineering (SRE) é o resultado da combinação de responsabilidades de operações de TI com desenvolvimento de software. Com o SRE, há uma expectativa inerente de responsabilidade para atender aos objetivos de nível de serviço (SLOs) definidos para o serviço que eles gerenciam e os acordos de nível de serviço (SLAs) que prometemos em nossos contratos.
O que significa observabilidade, como definir objetivos de nível de serviço (SLOs), como a observabilidade ajuda a tornar os sistemas mais confiáveis e como validar sua prática de observabilidade.
O que significa observabilidade, como definir objetivos de nível de serviço (SLOs), como a observabilidade ajuda a tornar os sistemas mais confiáveis e como validar sua prática de observabilidade.
Os incidentes são um momento emocionalmente estressante para os analistas, especialmente se eles sentem que foram eles que os causaram. Ao executar uma auto crítica, não se concentre em atribuir culpa. Em vez disso, concentre-se nos processos que permitiram que o incidente ocorresse em primeiro lugar. Isso é chamado de auto crítica sem culpa. Por exemplo, se um membro da equipe enviou um código ruim para a produção, talvez a solução seja um pipeline de implantação mais controlado, testes automatizados mais completos ou revisões de pares mais rigorosas. “Apontar dedos” apenas desencoraja os analistas de compartilhar suas experiências e insights por medo de punições.
Os incidentes são uma oportunidade de aprender e crescer. À medida que você resolve as causas-raiz dos incidentes, use a Engenharia do Caos para validar se suas correções estão funcionando. Automatize esse processo para garantir que seus sistemas permaneçam resilientes à falha. Pratique isso não apenas com suas próprias interrupções, mas também com incidentes experimentados e documentados por outras equipes e organizações.
Somos parceiros Gremlin – Saiba mais sobre como manter a gestão de confiabilidade de seus ambientes e produtos de software.
Nossos squads multidisciplinares também entregam tudo pronto ! Desde desde a concepção, design, arquitetura até a execução dentro do prazo e budget.
O Sizify® por observabilidade e monitoramento ativos, reduz o GAP entre:
a) experiência do usuário durante o uso;
b) gestão de confiabilidade de software e ambientes;
c) exigências de qualidade do produto.
