Documento técnico de negócios
Tenha como alvo
as lacunas entre o
desenvolvimento
e as operações
Foco nos desafios principais para
dar início à sua jornada de DevOps
Como tudo em TI, conseguir de
fato uma iniciativa de DevOps
bem-sucedida é mais fácil falar
do que fazer.
De acordo com o Gartner, “As relações entre Desenvolvimento
e Operações são geralmente vistas como pobres, com algumas
até mesmo consideradas maléficas”.1 Essa linguagem está muito
errada. Entretanto, a sua situação não é tão terrível, e as equipes de
desenvolvimento e operações pelo menos conversam no cafezinho.
Contudo, é verdade que, na maioria das organizações de TI, essas
duas equipes são entidades separadas, e a tendência recente para
uma colaboração mais próxima entre elas, normalmente conhecida
como “DevOps”, indica uma conscientização geral por parte da TI de
que as coisas seriam melhores se as equipes de desenvolvimento de
aplicativos trabalhassem juntas de maneira mais harmoniosa.
Mas, como tudo em TI, conseguir de fato uma iniciativa de DevOps
bem-sucedida é mais fácil falar do que fazer. Parte do desafio é que
DevOps ainda está mal-definido – é mais um conjunto de princípios
do que resultados pretendidos. Todos nós concordamos que a
melhor colaboração seria uma coisa boa, mas, com qual finalidade?
Ter a capacidade de articular seu objetivo para adotar uma iniciativa
de DevOps é a primeira etapa. Isso permitirá que você foque e priorize
seus esforços para que possa colher os melhores benefícios. Para
muitos, a meta final e a agilidade completa, reduzindo o tipo de ciclo
geral desde a concepção até a entrega do resultado final nas mãos de
seus usuários. Para alcançar esse objetivo, os líderes de TI precisam
empregar todos os esforços e observar as desconexões específicas
que fazem com que a separação entre as equipes cause prejuízos.
Desenvolvemos este documento técnico para ajudá-lo a utilizar
uma abordagem direcionada para lidar com DevOps. Com base na
ampla experiência da HP em ajudar as organizações de TI a operar
de maneira mais eficiente, identificamos sete desconexões comuns
que podem ser convertidas em ações para unificar essas funções
tradicionalmente em silos. Enfocando esses desafios específicos,
você pode transformar o relacionamento potencialmente maléfico
que o Gartner menciona em colaboração eficiente que aumenta a
velocidade geral de sua organização.
Figura 1
Como você descreveria as relações entre suas
organizações de Desenvolvimento de aplicativos e Operações de TI?
Muito colaborativa
3
Colaborativa
34
Não colaborativa
47
Bastante não colaborativa
9
Maléfica
7
0
10
20
30
40
50
Porcentagem de entrevistados
3
1. A discrepância de velocidade
Possivelmente, a desconexão mais significativa hoje entre
desenvolvimento e operações é que os dois grupos têm perspectivas
muito diferentes sobre mudanças e com qual rapidez elas devem ser
introduzidas. Essa diferença aumentou nos últimos anos devido ao
surgimento das metodologias de desenvolvimento Agile voltadas
para o que o Manifesto Agile chama de “entrega antecipada e
contínua de softwares de valor”.
As equipes de desenvolvimento estão trabalhando em conjunto com
as partes interessadas de negócios para rapidamente proporcionar
a mudança necessária para se aproveitar as vantagens das novas
oportunidades e dar uma resposta às ameaças da concorrência.
Por outro lado, as equipes de operações se esforçam para controlar
as mudanças com bastante força porque elas veem isso como um
risco de baixo desempenho, paralisações e vulnerabilidades de
segurança. Conforme o desenvolvimento cria funções com mais
rapidez, a equipe de operações tem receio de que as práticas de
testes tradicionais de que dependem para reduzir esses riscos sejam
comprometidas em nome da velocidade.
A reconciliação desses diferentes pontos de vista é talvez o maior
desafio para DevOps porque isso requer não só uma mudança
de processo, mas também uma mudança cultural. Para superar
essa dificuldade, a equipe de operações deve ter a certeza de que
alterações bem rápidas não comprometerão sua missão. Dessa
forma, a qualidade se torna a primeira e mais crucial ponte entre
os dois grupos. E a forma de construir essa ponte é por meio de
uma abordagem sistemática dos testes automatizados que começa
no ponto em que a mudança é introduzida – check-in do código
pelo desenvolvedor. Com a automatização e a execução desses
testes como parte de sua estratégia de integração contínua, você
pode adotar uma prática de testes quase ininterruptos, reduzindo
bastante o ciclo de feedback para os desenvolvedores e o que
permite que defeitos sejam identificados e corrigidos assim que
forem introduzidos.
Um regime de testes contínuos pode incorporar um amplo
espectro de testes: construção, verificação, regressão, funcional,
desempenho, segurança e aceitação. Um processo rigoroso e
automatizado que verifica progressivamente cada dimensão da
qualidade garantirá à equipe de operações que a velocidade e a
qualidade podem coexistir.
Figura 2
O desenvolvimento Agile acelera a criação de novos recursos, mas a vantagem será perdida se esses recursos tiverem um gargalo no processo de liberação.
Entrega ágil
Operações de TI
Recursos e alterações
de código
4
2. Medições e incentivos diferentes
igualam comportamentos diferentes
Uma mudança direta, porém fundamental, que pode causar um
grande impacto ao modo como desenvolvimento e operações
efetivamente trabalham juntos é examinar novamente como
os dois grupos são medidos. Operar como organizações em
silos há décadas, significa que a maioria das organizações de
desenvolvimento e operações introduziu medidas que otimizam sua
parte do quebra-cabeça, mas não necessariamente funcionam bem
para se alcançar o objetivo comercial completo.
As equipes de desenvolvimento têm uma tradição de longa data de
serem medidas com base no “triângulo de ferro” de custo, tempo
e escopo. A outra dimensão da qualidade é que, frequentemente,
ela recebe pouca atenção (esse é o principal motivo do desânimo
da equipe de operações). As equipes de operações, como gerentes
dos processos comerciais que mantêm os fluxos de receitas fluindo,
enfocam e são medidas pela estabilidade e disponibilidade dos
sistemas.
Embora essas abordagens veneráveis possam fazer sentido
isoladamente, elas são limitadas quando o assunto é o cenário
geral. E como os dois grupos são medidos com base em coisas
muito diferentes, seu comportamento parecerá mais competição
do que cooperação. Ao alinhar métricas, você pode reduzir o atrito e
estimular as equipes a seguirem juntas na mesma direção.
Considere a definição de métricas de desempenho alinhadas entre
grupos que adotam uma visão holística. Os exemplos incluem
tempo de ciclo, porcentagem de lançamentos com êxito na primeira
tentativa e porcentagem de defeitos encontrados na produção.
E se for possível, use um painel para criar uma visão única entre
funções de TI, de forma que os gerentes de TI possam definir os
principais indicadores de desempenho (KPIs) em nível comercial e
propagá-los para desenvolvimento e operações, colocando as duas
equipes no mesmo patamar com uma visão de mundo compartilhada
e dando a elas métricas e incentivos mútuos.
3. Uma parede opaca entre organizações
Além do alinhamento de medidas e incentivos, as equipes de
desenvolvimento e operações se beneficiarão com a maior
percepção das prioridades, dos processos e do progresso entre
elas. Saber em que a outra equipe está trabalhando, como as coisas
estão fluindo e quando elas estarão prontas, elimina surpresas e
confusão, o que contribui para a eficiência geral.
Eliminar as barreiras organizacionais e gerar colaboração de
DevOps pode começar com algo tão simples quanto equipes de
Agile, convidando representantes de operações em sessões de
planejamento de sprint e demonstrações de fim de sprint. As
sessões de treinamento compartilhadas sobre os processos e os
pontos problemáticos comuns entre as equipes fornecem uma
apreciação maior dos desafios corriqueiros e percepção de como
cada equipe pode tornar a vida mais fácil para a outra.
Uma visão comum e integrada sobre o estado do desenvolvimento
auxiliará na transparência e funcionará para conectar funções de TI.
Isso permite que todas as partes interessadas vejam abertamente o
progresso e coisas como: qualidade, níveis de defeito e taxas fixas.
A equipe de operações estará bastante interessada nisso, visto
que com isso eles assumirão a responsabilidade pelos aplicativos.
A colaboração e a visibilidade completas também significam
uma entrega mais tranquila quando chegar a hora de a equipe de
operações efetuar as alterações.
Na outra direção, a equipe de operações deverá ter ferramentas
que se integrem ao ambiente de desenvolvimento. Por exemplo, a
equipe de suporte deve estar preparada para facilmente encaminhar
os problemas de produção de volta à equipe de desenvolvimento
para que eles possam ser rapidamente priorizados em relação a
outros itens no backlog. Isso ajuda a garantir que o desenvolvimento
trabalhe nos itens de prioridade mais alta para a empresa,
independentemente de sua origem.
Por fim, para turbinar a proposta de compartilhamento de ideias
e solução de problemas que alimenta o progresso diário, equipes
maiores ou distribuídas terão enormes benefícios com o que há de
mais recente em ferramentas de colaboração de estilo de mídia
social, que estruturam as conversas em torno de itens de trabalho
específicos. Isso resulta em discussões com foco, voltadas para o
contexto, que reúne as pessoas certas para abordar uma questão ou
problema, independentemente da afiliação ou da localidade de sua
equipe.
5
4. Requisitos funcionais versus
requisitos não funcionais
5. Ambientes diferentes,
abordagens diferentes
Outra diferença cultural importante é o fato de que os
desenvolvedores têm a tendência de adotar requisitos funcionais,
ou o que os usuários corporativos querem que os aplicativos façam,
ao passo que a equipe de operações está mais preocupada com os
requisitos não funcionais ou ao modo como os aplicativos funcionam
e se comportam quando ativos.
Na maioria das organizações, conforme uma mudança é
implementada, ela é propagada em uma série de ambientes, como
desenvolvimento, teste, preparação e produção. Cada um desses
ambientes serve para uma finalidade diferente e um conjunto
diferente de partes interessadas. Eles são geralmente gerenciados
de formas diferentes, com o uso de recursos diferentes, usualmente
mantidos por pessoas também diferentes. Seu processo de
implantação normalmente consiste em um conjunto de etapas
manuais executadas por várias pessoas em posse de listas de
verificações intermináveis, que geralmente estão desatualizadas
ou apresentam erros. Essa abordagem consagrada não é nada
ágil e aumenta as chances de erros. De fato, ela colabora bastante
para muitos dos problemas enfrentados entre as equipes de
desenvolvimento e operações e é fonte de repetições insistentes
como “o build tem falhas” ou “funciona na minha máquina”.
Se você perguntar a um desenvolvedor sobre os requisitos de um
novo recurso de caixa eletrônico, a resposta poderá ser “Ele precisa
acessar o histórico de cada cliente que usa nosso caixa eletrônico;
identificar, com base no saldo da conta do cliente e outros fatores,
os serviços bancários que o cliente não tem, mas poderia estar
interessado em ter; e exibir uma tela promocional no caixa
eletrônico enquanto a transação do cliente está sendo processada.
Se você perguntar a um engenheiro de operações sobre os requisitos
do mesmo recurso, ele poderá responder “O serviço deve ser
executado em um quarto do tempo médio de transação do caixa
eletrônico, sem exceder a largura de banda disponível e oferecer
suporte a até 10.000 clientes que acessam os caixas eletrônicos
simultaneamente.”
Preso à sua própria definição dos requisitos, o desenvolvimento
pode fornecer uma tela de apresentação bonita e elegante que
também consuma muita largura de banda e trave a transação do
caixa eletrônico. Ou a equipe de operações pode insistir em que
o aplicativo está funcionando bem porque está sendo executado
dentro dos parâmetros de velocidade e largura de banda, embora
nenhum dos clientes esteja respondendo às promoções de vendas
cruzadas na tela do caixa eletrônico.
A adoção de uma visão mais ampla é novamente a solução para
solucionar essa desconexão. Como aprenderam os desenvolvedores
especializados, a concepção do desenvolvimento deve ser expandida
para englobar não só os requisitos funcionais, mas também os
não funcionais, como desempenho e segurança. Isso significa criar
aplicativos fáceis de aprimorar e fáceis de implantar, monitorar e
reparar. Essas coisas podem não ser tão estimulantes do ponto de
vista do desenvolvimento, mas são absolutamente cruciais do ponto
de vista das operações. Os analistas na verdade estimam que, para
um aplicativo com vida útil de 15 anos, mais de 90% do custo total
de propriedade está associado ao build inicial – na execução, na
manutenção e no aprimoramento do aplicativo. Isso torna o
conceito de criado para executar uma obrigação comercial real.
Essa é uma área pronta para automação. A automação permite que
as equipes eliminem essas liberações manuais, reduzam erros e
reduzam os tempos de liberação gerais. Fundamental para isso é
a noção de portabilidade de aplicativos, um recurso que permite
que as equipes movam aplicativos de um ambiente para outro
perfeitamente. A portabilidade é conseguida por meio de modelos
de aplicativos com foco no ambiente, os quais são compartilhados
entre desenvolvimento, teste e operações. Como todos implantam
da mesma forma usando os mesmos recursos, o resultado é
consistente, com implantações precisas sempre nos vários
ambientes do ciclo de vida.
6. Pouco ou nenhum compartilhamento
de recursos
Uma das fontes mais notórias de esforço redundante é a
“propriedade” dos ativos. Com seu histórico de organizações em
silos, as equipes de desenvolvimento e operações criam e depois
parecem acumular comunicações, resoluções, scripts de teste,
informações de uso e vários outros recursos que poderiam ser
compartilhados e reutilizados para eliminar a duplicação de esforço
e eliminar inconsistências no ciclo de vida do aplicativo. Em inúmeras
organizações de TI, o compartilhamento não ocorre ou é uma questão
secundária, principalmente porque os benefícios potenciais não são
reconhecidos. Aqui estão alguns exemplos de onde a reutilização e o
compartilhamento de recursos pode aliviar a carga:
• Crie pacotes automaticamente com os scripts de teste criados
no desenvolvimento e envie-os às equipes de operações para
monitoramento de produção, de modo que a equipe de operações
não precise recriar seus próprios scripts
• Importe dados de uso de produção para criar cenários de teste
mais precisos e realistas
• Converta sessões reais do usuário automaticamente de produção
em scripts de desempenho
• Utilize uma base de conhecimento compartilhada de perguntas,
defeitos e soluções de problemas, para que você não reinvente a
roda para problemas recorrentes
6
7. Trabalhe junto, mas elimine as
dependências
HP e os três pilares de DevOps
A estreita colaboração entre desenvolvimento e operações é uma
coisa boa, mas às vezes DevOps pode significar simplesmente
um não ficar no caminho do outro. A redução de dependências
pode ajudar ambas as equipes a trabalharem juntas, eliminando
liberações e a necessidade de aguardar a outra equipe concluir suas
tarefas.
• Qualidade: a chave do relacionamento de DevOps e um prérequisito para mudanças rápidas
Comece identificando as dependências principais entre as equipes
que resultam em latência ou perda de tempo e trabalhe para
remover ou automatizar essas partes do processo. Por exemplo,
permita que as equipes de desenvolvimento gerenciem seus
próprios ambientes, usando um recurso de gerenciamento de
laboratório automatizado. A equipe de operações está envolvida
com a configuração inicial, mas os próprios desenvolvedores e
testadores estão livres para fornecer e cancelar o fornecimento
desses ambientes sob demanda. Isso resulta em velocidade e
flexibilidade para as equipes de desenvolvimento e libera a equipe
de operações para outras tarefas.
A abordagem da HP para DevOps se concentra em três pilares sólidos:
• Automação: para diminuir os tempos de liberação, eliminar
liberações manuais e reduzir erros
• Colaboração: metas comuns, visibilidade 360 graus e
compartilhamento de recursos para unificar silos de TI tradicionais
Aplicando esses elementos principais, você pode superar o maior
obstáculo na implementação de DevOps: alterar a concepção
tradicional de suas equipes. Oferecemos suporte à nossa abordagem
com um conjunto abrangente de recursos integrados que podem
superar a base para a integração de suas equipes.
“Catalysts Signal the Growth of DevOps”, pesquisa do Gartner, fevereiro de 2012.
1
Princípios por trás do Manifesto Agile.
2
Figura 3
A abordagem DevOps da HP
1
Teste de desenvolvimento com automação
de gerenciamento de laboratório
Fornecimento
de ambientes de
desenvolvimento
e teste
2
Implantação automatizada
em desenvolvimento e operações
Monitorar
Implantar
aplicativo
de teste
Execução
de casos
de teste
Resultados
do teste
Fornecer e
implantar
para
preparação
Fornecer e
implantar
para
produção
Padrões de produção, instantâneos e imagens para
desenvolvimento e teste
3
Gerenciamento, colaboração e segurança para o ciclo de vida completo
A HP pode ajudá-lo a unificar suas funções de desenvolvimento e
operações para eliminar lacunas críticas em processos tradicionais.
7
Conecte-se
hp.com/go/getconnected
Compartilhe com colegas
Veja as tendências de tecnologia,
os alertas de suporte e as soluções da HP.
© Copyright 2012 Hewlett-Packard Development Company, L.P. As informações contidas neste documento estão sujeitas a alterações sem aviso.
As únicas garantias para produtos e serviços da HP são as estabelecidas nas declarações de garantia expressa que acompanham tais produtos e
serviços. Nada aqui contido deve ser interpretado como constituindo uma garantia adicional. A HP não será responsável por omissões, erros técnicos ou
erros editoriais contidos neste documento.
4AA4-2696PTL, criado em agosto de 2012