Treinamento escrito de DevOps

Como estruturar sua organização DevOps e projetar sua arquitetura de software?

Segundo a lei de Conway, organizações que projetam sistemas tendem a produzir sistemas que reproduzem suas próprias estruturas de comunicação. Em outras palavras, a qualidade do software depende da eficiência com que suas equipes se comunicam e interagem. Assim, a forma de estruturar as equipes afeta a arquitetura do software, o desempenho da TI e, por fim, o desempenho do negócio.

A estrutura da sua organização determina o tipo de software que você obtém

A maioria das empresas, provavelmente inclusive a sua, divide a organização de entrega de software em várias equipes e acaba produzindo software cuja arquitetura tem o mesmo número de camadas. Experimentos controlados também demonstraram que, ao pedir a uma organização com 6 equipes que construísse um software, as equipes chegaram a uma arquitetura de 6 camadas. Quando outra organização com 3 equipes recebeu a tarefa de construir o mesmo software, criou uma arquitetura de 3 camadas. Há muitos exemplos semelhantes.

Uma seguradora renomada com 86.000 funcionários no mundo tinha, por coincidência, duas grandes equipes funcionais em uma de suas organizações de TI. Essa área entregava o back-end para gerenciar clientes, contratos, faturas e serviços. Uma equipe se especializava em Java e a outra em procedimentos armazenados em PL/SQL. As equipes dependiam ainda dos serviços centralizados de operações de TI, administração de bancos de dados, infraestrutura, redes, segurança e garantia da qualidade, o que tornava mais difícil entregar software com segurança.

Havia outro desafio. Apesar de trabalharem em equipes separadas, os profissionais não conseguiam separar adequadamente a lógica de orquestração do negócio em Java da lógica de acesso a dados em PL/SQL. Entregaram centenas de funcionalidades, cada uma com código Java e PL/SQL emaranhado. Assim, cada solicitação de mudança ou de nova funcionalidade exigia dezenas de transferências entre equipes, gerando longas filas e prazos mesmo para mudanças pequenas. Além disso, como era difícil prever o impacto geral até das menores mudanças nesse ambiente complexo, elas continuamente comprometiam funcionalidades existentes em produção e causavam indisponibilidade, que exigia prazos longos, retrabalho, encaminhamento a instâncias superiores e estresse para resolver.

Para mudar essa forma de trabalhar, as duas equipes funcionais se uniram em uma única equipe de produto. Elas redesenharam o software aos poucos, convertendo a camada de acesso a dados em um conjunto de funções de API. Também criaram um novo sistema de negócio totalmente desacoplado do funcionamento interno dessa API. Logo no início, a iniciativa melhorou o ânimo da equipe, pois os especialistas em Java e PL/SQL passaram a trabalhar pelo sucesso do produto em comum, deixando de lado os interesses dos antigos silos. Com a arquitetura de baixo acoplamento, ficou mais fácil identificar o impacto das mudanças, implementá-las com rapidez e localizar e corrigir defeitos. Com isso, o tempo médio de entrega de novas funcionalidades caiu de 4 meses para 3 semanas, e a fila de incidentes quase zerou. A equipe usa a capacidade liberada para revisar, refatorar e melhorar sua base de código.

Organizações matriciais, equipes funcionais e a ilusão da otimização de custos

As empresas se organizam em equipes funcionais por especialidade, como bancos de dados, redes, operações, segurança da informação, garantia da qualidade, gestão de liberações, gerenciamento de projetos e gestão de produtos. As equipes de projeto reúnem pessoas de diferentes silos funcionais. Nessas organizações matriciais de projetos, que buscam entregar produtos e serviços, os gerentes de projetos costumam ser responsáveis por garantir a entrega, e os gerentes de produtos, por garantir que se entregue o que é necessário.

O problema dessa estrutura é que as equipes funcionais conhecem pouco ou nada do alcance do trabalho para o qual contribuem. Em casos extremos, mas comuns, elas não se preocupam com o contexto geral nem com o desempenho de TI e de negócio do produto ou serviço. O que lhes importa é se proteger quando os projetos dão errado e todos começam a procurar culpados.

Como as equipes funcionais geralmente gerenciam longas filas de chamados, costumam demorar a atender seu projeto. Como os projetos disputam os mesmos recursos, recorrer a instâncias superiores se torna a única maneira de obter atenção rápida. Repetir esse tipo de encaminhamento prejudica o ambiente de trabalho e a confiança entre as equipes.

Transferências repetidas entre equipes, atrasos, problemas de qualidade, retrabalho, gargalos e estresse passam a fazer parte do dia a dia. Enquanto se concentrarem em uma ilusão pouco transparente de otimização de custos, as organizações matriciais dificilmente terão um resultado melhor. Devido aos problemas de qualidade, ao retrabalho e aos atrasos, as organizações funcionais provavelmente custam mais do que qualquer outra reorganização que se possa imaginar. Se a organização já terceirizou competências funcionais essenciais, como garantia da qualidade e operações de TI, para locais distantes, sua área de TI provavelmente mal consegue entregar com segurança e atender às demandas críticas para a continuidade do negócio.

É um grande problema. Como o DevOps resolve isso? Com equipes orientadas a produtos e serviços

Para resolver o problema, o DevOps propõe trocar a suposta otimização de custos das equipes funcionais por uma melhoria comprovada na velocidade. Quando bem aplicado, o DevOps também permite reduzir custos enquanto sua equipe entrega com rapidez e de forma contínua.

O DevOps propõe equipes orientadas a produtos e serviços. São equipes independentes, multifuncionais, autônomas, autossuficientes e geralmente pequenas, capazes de cuidar de todas as fases do ciclo de vida de engenharia de um produto ou serviço que vai além de um projeto temporário. Elas definem a arquitetura, projetam, programam, testam, experimentam, implantam, operam e mantêm o software. Isso mesmo. Quem pode operar e manter um software melhor do que quem o criou? Ninguém. Por isso, as equipes DevOps mais bem-sucedidas da Amazon e da Netflix continuam responsáveis pelos produtos e serviços após a liberação. Também operam e mantêm o software nos próprios sistemas de produção.

Sua organização passa a financiar produtos e serviços em vez de projetos temporários

Para melhorar seu desempenho, sua organização deixa de financiar projetos temporários cujos resultados concretos de negócio são difíceis de avaliar no longo prazo. Com DevOps, ela financia a própria missão, seu propósito e os produtos e serviços associados. O sucesso das equipes passa a ser avaliado pelo desempenho de TI e de negócio e pelo retorno sobre o investimento nas áreas em que oferecem produtos, serviços e microsserviços a clientes internos e/ou externos. As equipes agem como responsáveis pelos produtos e serviços que criam e oferecem, indo além do papel de integrantes de silos funcionais pouco atentos aos resultados de negócio.

Como formar suas equipes DevOps e projetar sua arquitetura de software?

O DevOps não sugere interromper e reorganizar de uma vez todos os projetos em andamento. Uma forma de adaptar as equipes com impacto e pouca interrupção é integrar especialistas funcionais às equipes de projeto. Quando contam com especialistas nas áreas de que precisam, como garantia da qualidade, segurança da informação, bancos de dados, redes, servidores e operações, as equipes podem projetar, implantar e manter produtos e serviços de software de forma independente e autossuficiente.

Nessas equipes DevOps orientadas a produtos e serviços, disponibilidade, qualidade, desempenho, segurança da informação e conformidade fazem parte do trabalho diário de todos. Como criar aplicações seguras, de alta disponibilidade e qualidade, capazes de suportar a carga exigida pelos clientes, se os requisitos não funcionais só recebem atenção depois que o projeto e o desenvolvimento terminam? Como especialistas externos podem avaliar e validar a segurança e a qualidade das aplicações sem participar de nenhuma etapa da engenharia dos produtos e serviços? Por isso, equipes DevOps de alto desempenho recorrem a especialistas externos para obter orientação e continuam plenamente responsáveis pelos requisitos não funcionais em todas as etapas do ciclo de vida.

Uma alternativa que você pode considerar

O Google é uma organização DevOps especialmente bem-sucedida que ainda usa muitas equipes funcionais ao lado de equipes DevOps orientadas a produtos e serviços. No Google, ambas veem a missão da organização e os produtos e serviços como um objetivo comum. As equipes funcionais criam modelos, como templates, listas de verificação e estruturas iniciais de aplicações, e sistemas de autosserviço, por exemplo para provisionar e configurar servidores e redes de forma independente. Assim, evitam se tornar gargalos para as equipes DevOps de produtos e serviços. As equipes funcionais colaboram e dão apoio nas primeiras fases do ciclo de vida da engenharia de software, revisam projetos, códigos e testes de forma construtiva e prestam consultoria continuamente.

Qual deve ser o tamanho da equipe DevOps?

O tamanho ideal de uma equipe DevOps é de 5 a 10 pessoas. Esse limite reduz a complexidade da comunicação e do alinhamento. Além disso, líderes e integrantes gastam menos tempo com tarefas acessórias e custos administrativos. O limite também restringe o tamanho do produto ou serviço pelo qual a equipe responde, reduzindo a complexidade e a dificuldade de manutenção e operação. Em equipes pequenas, todos entendem o contexto e ganham um pouco de experiência de liderança ao participar de uma missão importante. O líder trabalha com a alta gerência para entender as metas e transmiti-las à equipe.

E se uma equipe de até 10 pessoas não der mais conta do seu produto ou serviço?

Crie um novo produto ou serviço e forme outra equipe DevOps para assumi-lo. Produtos e serviços não precisam ser apenas ofertas para clientes externos que pagam por eles. Você também pode criar produtos, serviços ou APIs de microsserviços internos e formar equipes DevOps para atender clientes internos. Por exemplo, se o sistema de faturamento ficar grande demais para uma equipe de até 10 pessoas, forme outra equipe para assumir a API de acesso a dados. Talvez outra possa cuidar da API de pagamentos on-line e mais uma dos processos em lote. Todas devem usar um repositório de código comum e um pipeline de implantação compartilhado para garantir integração contínua, entrega rápida e sucesso da organização.

Em uma arquitetura com alto acoplamento, pequenas mudanças em uma aplicação podem provocar efeitos adversos em vários fluxos de trabalho. Por isso, seus produtos, serviços e APIs de microsserviços devem ter baixo acoplamento. Cada equipe DevOps deve ser responsável por uma parte dessa arquitetura. Assim, cada equipe pode projetar, desenvolver e implantar seu software com independência. Um mecanismo de alerta antecipado no pipeline deve informar rapidamente e de forma automática as equipes sobre possíveis efeitos adversos causados por qualquer envio de código.

Como equipes de até 10 pessoas podem cuidar de forma autônoma de todas as fases do ciclo de vida da engenharia de software, da arquitetura às operações?

Incentive todos os integrantes da equipe a se tornarem generalistas. Estimule e facilite o desenvolvimento contínuo de novas habilidades.

Contrate apenas profissionais dispostos a aprender e crescer, independentemente do nível atual de conhecimento e experiência. Evite pessoas que esperam ser avaliadas com base em um conjunto fixo de funções e responsabilidades. A organização e seus produtos e serviços mudam.

A demanda vai mudar amanhã, se já não tiver mudado hoje.

CONCLUSÃO

Neste capítulo, mostramos os resultados insatisfatórios das organizações matriciais, os silos funcionais associados a elas e a solução proposta pelo DevOps.

O DevOps sugere formar equipes pequenas, de até 10 pessoas, orientadas a produtos, serviços ou APIs de microsserviços.

Essas equipes DevOps devem reunir engenheiros de software generalistas e full-stack, capazes de cuidar de forma autônoma de todas as fases do ciclo de vida, do projeto à manutenção.

O DevOps se apoia em uma arquitetura orientada a serviços (SOA) com baixo acoplamento, na qual cada equipe é responsável por uma parte da arquitetura e a opera.