a practical path to DevOps maturity

Any agile methodology is fútil without real DevOps practices. A palavra-chave foi mal usada em muitas organizações. Se você diz que amadureceu equipes ágeis e você tem um engenheiro DevOps ou equipe DevOps, que provavelmente não estão indo na direção certa. DevOps é uma cultura ao invés de um nome de equipe ou designação. Tomando uma sugestão de CMM (Capability Maturity Model) esta tentativa é ajudar uma organização a saber onde eles estão em uma jornada DevOps e caminho a seguir. Com algum brainstorm entre as equipes de desenvolvimento e Operações isso pode ser expandido e personalizado de acordo com as necessidades da organização.

nenhum número é mau como para como ele ajuda um indivíduo ou organização a crescer.

Cliente Feliz

ao contrário do CMM, este não é um modelo que você precisa provar para qualquer organização de certificação. O único certificado que você recebe é de seus clientes felizes ou parceiros de negócios. É um modelo para refletir e ajudar os negócios a crescer. O próprio objetivo de qualquer equipe de TI é criar valor fazendo entrega sustentável e previsível com qualidade.

este é um modelo simples que do desenvolvedor ao CxO pode entender e relacionar.

Antes de discutir sobre o modelo. Temos de compreender a necessidade deste modelo. Há muitos anos, Melvin Conway em seu artigo ” Como os comitês inventam?”surgiu com tese que se tornou famosa como a lei de Conway.

qualquer organização que conceba um sistema (definido em termos gerais) produzirá um desenho cuja estrutura é uma cópia da estrutura de comunicação da organização.

a lei é baseada no raciocínio de que para que os módulos de software funcionem, múltiplas pessoas devem se comunicar frequentemente entre si. Portanto, a estrutura de interface de software de um sistema irá refletir as fronteiras sociais da Organização(s) que o produziu, através das quais a comunicação é mais difícil.

vamos ver como isso funciona no desenvolvimento de software com um cenário real. Radha está construindo uma tela front-end que mostra atributos detalhados de um produto. Digamos que este produto é um telemóvel. Poucos detalhes comuns do produto são Cor, preço, dimensões, classificações etc. Um novo Regulamento veio para mostrar o valor SAR do aparelho. O ecrã que ela desenhou funciona com uma chamada de micro-serviço. Ela falou com o Sunil que trabalha na equipa de dados. Ele disse que eles só podem enviar dados em Arquivo plano. Há uma clara desconexão entre dois módulos. Este é um cenário que cada equipe de TI se depara se não todas as 100% vezes, mas a maioria das vezes. Isto é apenas uma questão de design. O problema é mais vasto. E se as prioridades da outra equipa forem muito diferentes do que a tua equipa está a fazer? Seus requisitos podem ser a MENOR prioridade para eles, enquanto seus stakeholders estão correndo atrás de você.

o primeiro passo para uma implementação bem sucedida DevOps é ser aberto com mudanças de organização.

mudanças de Organização

Deixe-me discutir os 5 níveis de maturidade:

  1. Inicial: nesta fase, as equipes trabalham em silos e existe apenas, a necessidade de colaboração. Em uma reunião com todas as equipes juntas, se você perguntar Quem é o dono do” produto ” você não terá mãos levantadas. O tempo para o mercado é tipicamente mais longo, indo a Meses e às vezes anos. As prioridades são estabelecidas ao nível da equipa, mas não ao nível do produto. Isso levará a que cada equipe tenha suas próprias prioridades. Como não há processo definido, cada tentativa é como reinventar a roda. Isto conduzirá a questões de qualidade e a prazos mais longos. A equipe faz principalmente desdobramentos manuais e intervenções manuais. Bem.. este não é um mau estado. É assim que a maior parte do desenvolvimento começaria.

2. Repito: as equipas ainda trabalham em silos. Há algum nível de automação dentro da equipe. Quando uma crise atinge, a equipe define seu próprio processo e segue até o fim da crise. Só uma boa notícia é que alguns destes podem tornar-se processos repetíveis quando a crise voltar a atacar.

3. Definido: este é um bom ponto de partida para semear a cultura DevOps com uma equipe centralizada. Esta equipe compreende várias tecnologias que as equipes Dev estão usando e ferramentas é baseada na necessidade atual. Sendo uma equipe centralizada, não é fácil monitorar o que cada equipe está fazendo e assim algumas decisões são deixadas para as equipes experimentarem. A equipe Central normalmente consiste de especialistas e equipes dev terão algumas pessoas com compreensão básica e conhecimento.

4. Gerenciado: como a equipe Central DevOps entende a paisagem de ferramentas de organização, vários ambientes e ferramentas são testados. Processos consistentes e repetíveis são seguidos por várias equipes. A cadeia de ferramentas é selecionada com base em casos de uso ao invés de escolhas pessoais. Ferramentas de monitoramento para todos os processos são introduzidas e fortemente utilizadas pelas equipes para tomar decisões.

5. Optimizar:

o sucesso de um bom líder é definido não tendo seguidores, mas pela capacidade de criar grandes líderes.

a fase Final de maturidade dos DevOps é fazer com que a equipa dos DevOps desapareça. Isto pode parecer contra intuitivo. Nesta fase, DevOps faz parte da equipe de desenvolvimento de produtos ao invés de uma entidade separada. Utilização da infra-estrutura como código, contentores, orquestração, etc. a colocação do toque zero é alcançada. Agora, se você ligar para todos os que estão trabalhando em um produto e perguntar Quem é o dono do produto, você terá algumas mãos confiantes levantando sem qualquer hesitação. Os dados das ferramentas de monitoramento são usados para selecionar novos conjuntos de ferramentas (incluindo infraestrutura, linguagens de programação, técnicas). As decisões baseiam-se em dados e não em preferências pessoais. A equipe de produtos está pronta para implantar o código a qualquer dia e a qualquer hora. Adoram o “valor comercial” e tratam-no como um animal de estimação. Tudo o resto é tratado como gado.

DevOps Modelo De Maturidade.

Deixe uma resposta

O seu endereço de email não será publicado.