Avaliação de Maturidade DevOps

Descubra o que está a atrasar as suas releases, do pipeline à produção.

Experimente esta avaliação de saúde ao vivo

O que é a Avaliação de Maturidade DevOps?

A Avaliação de Maturidade DevOps abrange o percurso do commit até à produção em cinco grupos: Pipeline de CI/CD, Release e Implementação, Fiabilidade e Operações, Automação de Segurança e Conformidade, e Plataforma e Infraestrutura. A sua equipa avalia 15 capacidades, como a frequência de integração, a redução do risco de implementação, a sustentabilidade do on-call e a conformidade como código, numa escala de cinco níveis que vai de Ad Hoc a Otimizado. As equipas que raramente fazem entregas costumam conhecer bem os sintomas: passos manuais em cada release e uma escala de on-call que desgasta as pessoas. As avaliações mostram qual é a capacidade que constitui o verdadeiro estrangulamento. Como cada nível tem uma descrição escrita, programadores, SREs e pessoas de produto avaliam a mesma capacidade com a mesma referência, e as diferenças entre as suas perspetivas mostram por onde começar.

Dimensões

Pipeline de CI/CD

Até que ponto a equipa compila, integra e obtém feedback de forma eficaz através de pipelines automatizados.

  • Automação de builds

    Com que fiabilidade e automatismo os builds de software são gerados e validados.

    1. Ad HocOs builds são manuais, lentos e propensos a erros.
    2. EmergenteExiste automação básica, mas é frágil ou incompleta.
    3. DefinidoOs builds correm de forma fiável com um nível moderado de automação.
    4. GeridoOs builds estão altamente automatizados, com feedback rápido e fiável.
    5. OtimizadoA automação de builds é fluida, estável e otimizada continuamente, com falhas quase nulas.

  • Frequência de integração

    Com que frequência os programadores integram alterações na base de código partilhada.

    1. Ad HocA integração é pouco frequente, o que leva a merges grandes e arriscados.
    2. EmergenteA equipa tenta integrar com mais frequência, mas persistem inconsistências.
    3. DefinidoA integração diária é comum e reduz os conflitos de merge.
    4. GeridoA integração é contínua e estável em toda a equipa.
    5. OtimizadoIntegração quase em tempo real, com conjuntos de alterações pequenos e seguros que permitem um fluxo rápido.

  • Feedback do pipeline

    Rapidez e clareza da informação que o pipeline devolve aos programadores.

    1. Ad HocO feedback é lento, pouco claro ou pouco fiável.
    2. EmergenteExiste feedback, mas chega muitas vezes com atraso ou com ruído.
    3. DefinidoO feedback do pipeline é razoavelmente atempado e acionável.
    4. GeridoO feedback é rápido, claro e permite aos programadores iterar com rapidez.
    5. OtimizadoO feedback é imediato e preciso, permitindo uma velocidade de engenharia de excelência.

Release e Implementação

Com que segurança, previsibilidade e frequência a equipa entrega alterações aos utilizadores.

  • Automação de implementações

    Nível de automação e repetibilidade das implementações.

    1. Ad HocAs implementações são manuais, arriscadas e propensas a erros.
    2. EmergenteFoi introduzida alguma automação, mas é aplicada de forma inconsistente.
    3. DefinidoAs implementações são maioritariamente automatizadas e previsíveis.
    4. GeridoImplementações totalmente automatizadas, com baixas taxas de falha.
    5. OtimizadoImplementação contínua, com releases seguras, rápidas e reversíveis.

  • Redução do risco de implementação

    Até que ponto a equipa minimiza o risco durante as releases.

    1. Ad HocAs releases são eventos "big bang" de alto risco.
    2. EmergenteExiste alguma mitigação de risco, mas é limitada.
    3. DefinidoFeature flags e rollouts faseados são usados regularmente.
    4. GeridoAs releases são de baixo risco, com salvaguardas e monitorização sólidas.
    5. OtimizadoEstratégias de release avançadas evitam interrupções e permitem rollback imediato.

  • Frequência de entrega

    Com que frequência se entrega valor aos utilizadores.

    1. Ad HocAs releases são raras, imprevisíveis e muito variáveis.
    2. EmergenteA cadência de releases melhora, mas continua inconsistente.
    3. DefinidoA equipa faz releases segundo um calendário previsível.
    4. GeridoCiclos de release frequentes e fiáveis.
    5. OtimizadoA entrega contínua garante um fluxo de valor rápido e seguro.

Fiabilidade e Operações

Até que ponto a equipa observa, responde e mantém a saúde dos sistemas em funcionamento.

  • Monitorização e observabilidade

    Até que ponto a equipa compreende a saúde e o comportamento do sistema.

    1. Ad HocMonitorização limitada ou reativa; os problemas são detetados tarde demais.
    2. EmergenteExistem dashboards básicos, mas a visibilidade tem lacunas importantes.
    3. DefinidoA monitorização oferece visibilidade adequada sobre a maioria dos componentes.
    4. GeridoObservabilidade sólida com logs, métricas e traces que permitem um diagnóstico rápido.
    5. OtimizadoObservabilidade abrangente, com insights preditivos e deteção automatizada.

  • Resposta a incidentes

    Com que eficiência a equipa responde a incidentes e os resolve.

    1. Ad HocOs incidentes são caóticos e a responsabilidade não é clara.
    2. EmergenteA estrutura vai crescendo, mas a resolução continua inconsistente.
    3. DefinidoOs incidentes são tratados de forma metódica, com eficiência moderada.
    4. GeridoResposta rápida e coordenada, com MTTR baixo.
    5. OtimizadoGestão de incidentes muito madura, com postmortems focados na aprendizagem.

  • Sustentabilidade do on-call

    Equidade e eficácia dos processos de on-call.

    1. Ad HocO on-call é pesado, imprevisível ou injusto.
    2. EmergenteA carga de trabalho torna-se mais gerível, mas os problemas continuam.
    3. DefinidoA rotação é justa e o volume de alertas é razoável.
    4. GeridoBoas práticas de on-call, com alertas bem afinados e boas ferramentas.
    5. OtimizadoAlertas fora de horas mínimos; a automação resolve a maioria dos problemas.

Automação de Segurança e Conformidade

Até que ponto a segurança e a conformidade estão automatizadas e integradas em todo o pipeline de entrega.

  • Integração da segurança

    Até que ponto as práticas de segurança estão integradas nos fluxos de desenvolvimento.

    1. Ad HocAs verificações de segurança são manuais ou acontecem tarde no processo.
    2. EmergenteExistem análises automáticas básicas, mas com pouca abrangência.
    3. DefinidoSegurança integrada no CI/CD, com análises consistentes.
    4. GeridoVerificações de segurança automatizadas e abrangentes em todo o pipeline.
    5. OtimizadoSegurança contínua e inteligente que previne vulnerabilidades desde cedo.

  • Gestão de vulnerabilidades

    Com que rapidez e eficácia as vulnerabilidades são detetadas e tratadas.

    1. Ad HocAs vulnerabilidades são detetadas tarde e a correção é lenta.
    2. EmergenteOs processos estão a melhorar, mas continuam inconsistentes.
    3. DefinidoA resposta a vulnerabilidades é previsível e ponderada.
    4. GeridoCorreção rápida e eficiente, com prevenção proativa.
    5. OtimizadoIdentificação, priorização e correção automatizadas em escala.

  • Conformidade como código

    Uso da automação para garantir requisitos regulamentares, de segurança e de políticas.

    1. Ad HocAs tarefas de conformidade são manuais e reativas.
    2. EmergenteForam introduzidas algumas verificações automáticas.
    3. DefinidoAs políticas críticas estão integradas nos fluxos de automação.
    4. GeridoA conformidade é verificada regularmente através de verificações automáticas.
    5. OtimizadoConformidade contínua, com aplicação em tempo real.

Plataforma e Infraestrutura

Até que ponto a plataforma e a infraestrutura subjacentes são automatizadas, consistentes e resilientes.

  • Automação da infraestrutura

    Como a infraestrutura é aprovisionada, gerida e escalada.

    1. Ad HocA infraestrutura é aprovisionada manualmente, com elevado risco de desvio de configuração.
    2. EmergenteAutomação parcial com scripts ou ferramentas.
    3. DefinidoInfraestrutura como código implementada nas áreas principais.
    4. GeridoInfraestrutura totalmente automatizada, com ambientes consistentes e reproduzíveis.
    5. OtimizadoInfraestrutura com autorrecuperação, totalmente orquestrada e com escalonamento inteligente.

  • Consistência dos ambientes

    Até que ponto os ambientes de desenvolvimento, staging e produção são consistentes.

    1. Ad HocOs ambientes diferem bastante; os problemas são muitas vezes específicos de um ambiente.
    2. EmergenteAlguma padronização, mas persistem inconsistências.
    3. DefinidoAmbientes maioritariamente alinhados, com comportamento previsível.
    4. GeridoAmbientes muito consistentes, geridos através de automação.
    5. OtimizadoAmbientes totalmente reproduzíveis, em contentores e estáveis em todo o lado.

  • Fiabilidade da plataforma

    Disponibilidade, resiliência e tolerância a falhas do sistema.

    1. Ad HocInterrupções frequentes e práticas de fiabilidade limitadas.
    2. EmergenteA fiabilidade melhora ligeiramente, mas os problemas persistem.
    3. DefinidoFiabilidade aceitável, com melhorias em curso.
    4. GeridoElevada fiabilidade, com medidas preventivas sólidas.
    5. OtimizadoResiliência excecional, com recuperação automatizada e arquiteturas tolerantes a falhas.

Quando utilizar essa avaliação de saúde

  • Para estabelecer uma base de referência das capacidades de DevOps e entrega contínua da sua equipa.
  • No planeamento de engenharia, para decidir se a próxima prioridade é a automação, a fiabilidade ou a segurança.
  • Para acompanhar a evolução da maturidade DevOps ao longo do tempo, entre squads ou em toda a organização.
  • Quando está a criar ou a escalar práticas de engenharia de plataforma e SRE.
  • Durante uma transformação DevOps, para dar às equipas um roteiro de melhoria comum.

Dicas e truques

  • Peça a engenheiros, SREs e stakeholders de produto que avaliem individualmente, para que surjam diferentes visões da maturidade.
  • Comece pelas dimensões com maior dispersão de pontuações. Muitas vezes apontam para estrangulamentos que ninguém identificou.
  • Para cada dimensão com pontuação baixa, combinem um passo rumo ao nível seguinte. Não tentem chegar a Otimizado em tudo de uma vez.
  • Repita a avaliação todos os trimestres para que os pequenos progressos fiquem visíveis.
  • Leiam juntos as descrições dos níveis antes de discutir as pontuações, para que todos concordem sobre o que é um bom resultado.

Perguntas frequentes

O que é um modelo de maturidade DevOps?
É uma forma estruturada de avaliar o nível de evolução das práticas de DevOps e entrega contínua da sua equipa. As capacidades são avaliadas em níveis progressivos, de Ad Hoc a Otimizado, para que possa ver as lacunas e planear o que melhorar.
Quem deve participar nesta avaliação?
Todas as pessoas que desenvolvem, entregam ou operam software: programadores, SREs, engenheiros de plataforma, especialistas em segurança e líderes de engenharia. Cada um vê uma parte diferente do percurso de entrega.
Como são avaliadas as dimensões?
Cada dimensão é pontuada numa escala de cinco níveis, de Ad Hoc a Otimizado, com uma descrição para cada nível. Isto mantém as avaliações consistentes e dá à equipa algo concreto para discutir.
Com que frequência devemos fazê-la?
Trimestralmente é adequado para a maioria das equipas. Dá tempo para que as melhorias produzam efeito e mostra o progresso de uma avaliação para a seguinte.
Podemos personalizar as dimensões?
Sim. Os administradores de conta e de equipa podem criar modelos de health check personalizados no TeamRetro, para que possa adicionar, remover ou reformular dimensões de acordo com as suas ferramentas e prioridades.

Exames médicos relacionados