Relatório anual do DevOps do Azure

Relatório do DevOps corporativo

2020-21
Relatório do DevOps corporativo 2020-21 2

Sumário
Resumo executivo .......................................................................................................................... 3

Introdução ao DevOps corporativo .......................................................................................... 6

O Índice de Velocidade de Desenvolvedor (DVI) ................................................................. 9

Gerenciamento de produtos ...................................................................................................... 11

Equipes distribuídas e trabalho remoto .................................................................................. 17

Governança ...................................................................................................................................... 23

Qualidade ......................................................................................................................................... 30

Segurança ......................................................................................................................................... 38

Conformidade ................................................................................................................................. 45

Conclusão ......................................................................................................................................... 50

Autores .............................................................................................................................................. 52

Métodos de pesquisa, Referências adicionais ...................................................................... 53

Relatório do DevOps corporativo 2020-21
Resumo executivo
Muitas organizações empresariais que passam por
transformações digitais estão adotando o DevOps
como o novo modelo operacional da TI porque os
departamentos de TI existentes não conseguem
escalabilidade com as necessidades de negócios
e  clientes. A Microsoft define o DevOps como: "A união
de pessoas, processos e tecnologia para possibilitar
a agregação contínua de valor para os clientes".
O DevOps associa desenvolvimento de software (Dev)
e operações de TI (Ops) com equipes alinhadas às
necessidades de negócios, produtos e clientes. Isso
foge às práticas tradicionais de TI, que são baseadas em
especialistas técnicos — desenvolvedores, testadores,
administradores de banco de dados e administradores
de sistemas — que são vistos como seus próprios silos
operacionais independentes. O objetivo final do DevOps
é permitir que as organizações coloquem ideias de
produtos no mercado mais rapidamente, sem sacrificar
a estabilidade ou a segurança de sistemas de produção.
3
A prática do DevOps teve origem em organizações
centradas em tecnologia e digitais, como Netflix, Spotify
e Facebook. Essas práticas evoluíram com arquiteturas
técnicas e designs organizacionais à medida que
as empresas escalavam. No entanto, a maioria das
organizações empresariais precisa transformar pessoas,
processos e tecnologias existentes para adotar o DevOps.
Em abril de 2020, a McKinsey, buscando maneiras tangíveis
de avaliar como as principais métricas de negócios foram
aperfeiçoadas por meio da inovação de desenvolvimento
de software, criou o conceito do Índice de Velocidade de
Desenvolvedor (DVI)1. O DVI é uma métrica que "identifica
os fatores mais críticos (relacionados à tecnologia,
práticas de trabalho e capacitação organizacional) para
alcançar a velocidade do desenvolvedor." A velocidade
do desenvolvedor não se trata apenas de aumentar
a velocidade de entrega, mas sim de desencadear
a engenhosidade do desenvolvedor para resolver ideias
de negócios complexas — usando novas tecnologias
e maneiras de trabalhar para criar software que atenda
às necessidades dos clientes corporativos, ao mesmo
tempo em que cumpre metas de negócios. O DVI é uma
métrica composta de 46 fatores-chave que influenciam
a Velocidade de Desenvolvedor.
Relatório do DevOps corporativo 2020-21 4

Os principais insights do estudo de DVI são os seguintes:

• O Índice de Velocidade de Desenvolvedor (DVI) está intimamente correlacionado ao sucesso

organizacional. As empresas com pontuações de DVI de quartil elevado superam de 4 a 5 vezes as
empresas de quartil baixo.
• Ferramentas de desenvolvedor, que abrangem ferramentas de colaboração, desenvolvimento, DevOps
e planejamento, têm a maior importância relativa na condução de indicadores de performance de negócios.
• Culturas de gerenciamento de produtos que utilizam filosofias de "segurança psicológica/falha rápida e
aprendizagem", acentuadas por equipes focadas no produto, alcançam altas pontuações de DVI. Apenas
~20% dos executivos acreditam que a organização implementa essa prática cultural.
• Os recursos e a adoção de Open Source são o diferenciador mais marcante para as organizações de
melhor desempenho que tentam promover a inovação e a satisfação dos desenvolvedores.
• A qualidade está em risco nas organizações com a adoção lenta de práticas de automação de teste e
quando as empresas acreditam que a "qualidade" se refere apenas a testes.
• A segurança é uma grande preocupação, com 17% das organizações relatando que só testam
vulnerabilidades de segurança "para um lançamento importante" ou "somente ao liberar para produção".
• A conformidade nas empresas é um grande desafio, com 59% dos entrevistados relatando que pode levar
"de vários dias a vários meses" para avaliar o estado atual de conformidade regulatória.

Após a definição do DVI, a Microsoft, junto com a Sogeti, realizou um estudo de pesquisa baseado em comentários
e  entrevistas com os profissionais da Sogeti responsáveis por mais de 250 implementações de nuvem e DevOps em
organizações empresariais. Os resultados do estudo de DVI foram combinados com a pesquisa do Sogeti para identificar
seis áreas-chave de TI em escala empresarial que enfrentam desafios significativos como parte da transformação de
DevOps empresarial:

Gerenciamento de produtos Qualidade

Equipes distribuídas e
Segurança
trabalho remoto

Governança de TI Conformidade
Relatório do DevOps corporativo 2020-21 5

Nestas seis áreas de escala empresarial, os melhores desempenhos no espaço de

DevOps abordam os desafios, utilizando as seguintes práticas e soluções:

• Migrar de modelos de entrega centralizados "centrados • Os profissionais de DevOps estão criando,

no projeto" para descentralizados "focados no produto",
em que as equipes de produto de DevOps assumem
a propriedade completa do ciclo de ponta a ponta de um
produto ou serviço, implementar processos de orçamento
iterativo em vez de orçamentos anuais em grande escala.
• As equipes se baseiam nas práticas recomendadas de
projetos de Open Source e adotam uma metodologia
InnerSource. Essas equipes compartilham arquiteturas
de referência, código de aplicação e infraestrutura
e componentes comuns para simplificar e otimizar
fluxos de trabalho.
• As equipes estão sendo capacitadas para "codificar,
enviar e colaborar de qualquer lugar" adotando
plataformas de colaboração baseadas em nuvem,
cadeias de ferramentas de DevOps e sistemas de
controle de versão distribuída.
• As empresas estão migrando para modelos de
governança orientados a princípios, em que as
equipes de governança e arquitetura definem
princípios fundamentais e descrevem como esses
princípios serão avaliados. Essas empresas fazem
a coisa certa, a coisa mais fácil e cumprir a governança
torna-se um hábito.
executando e gerenciando aplicações em
plataformas de nuvem self-service e fornecem
segurança, conformidade e qualidade integradas
para todos os seus produtos.
• As organizações estão adotando um modelo "tudo
como código", em que não apenas aplicações, mas redes,
infraestrutura de computação, política de segurança,
pipelines de build e lançamento etc... são escritas
"como código" e armazenadas em um repositório de
código-fonte. Essa prática permite o aperfeiçoamento
contínuo, atualizando e melhorando o código-fonte,
promovendo uma melhor reutilização na organização
e maior transparência.
• As preocupações em escala empresarial, como
qualidade, segurança e conformidade, estão migrando
de um "modelo de auditoria" para um "modelo
contínuo", análogo a como o modelo de integração
contínua/implantação contínua (CI/CD) transformou
o desenvolvimento de software. A qualidade,
a segurança e a conformidade são continuamente
avaliadas, em comparação com padrões e linhas
de base acordados, e os desvios são corrigidos via
automação ou intervenção humana direta.

As organizações buscam evoluir para um modelo de entrega de DevOps corporativo podem usar esses padrões
e práticas de negócios como um blueprint para evolução. Este relatório se expandirá sobre cada uma dessas
práticas recomendadas e oferecerá muitos outros aprendizados e soluções importantes implementados pelos
adeptos de DevOps de alta performance.
Relatório do DevOps corporativo 2020-21
Introdução ao DevOps corporativo
A Microsoft define o DevOps como: "...a união de pessoas, processos
e tecnologia para possibilitar a agregação contínua de valor para os clientes".
É importante começar reconhecendo que as metas
do DevOps permanecem as mesmas, esteja o DevOps
sendo implementado por uma empresa tradicional ou
por uma organização nativa digital. Os dois tipos de
organização pretendem implantar a produção com mais
rapidez e frequência, além de fornecer serviços altamente
disponíveis para clientes em ambientes estáveis e seguros.
Os adeptos digitais nativos desenvolveram princípios de
DevOps por meio de um caminho evolutivo — à medida
que cresceram comercialmente até a escala em que se
encontram hoje, suas práticas de DevOps foram forçadas
a acompanhar a evolução da arquitetura de aplicações.
Em contraste, para muitas organizações empresariais
existentes, a realidade é que elas estão presas a anos, ou
décadas, de aplicações e processos herdados que lutam
para permanecer coerentes e relevantes, com retornos
cada vez menores. Essas empresas enfrentam uma
evolução de DevOps transformacional. Para ter sucesso
em um cenário tecnológico tão dinâmico e mutável,
devem começar por capacitar os departamentos de TI.
6
A evolução de DevOps tem sido inibida, em grande
parte, pela forma como as empresas enxergam os
departamentos de TI.
Para muitos, a TI não se adequa mais a um propósito.
Se os executivos desejarem que os departamentos de TI
permaneçam relevantes, oferecendo serviços rápidos
e flexíveis, deverão basicamente transformar a concepção
deles da TI como centro de custos e reconhecê-la como
um facilitador estratégico de negócios que é essencial ao
sucesso da empresa em geral.
O cenário tecnológico foi totalmente transformado
e continuará a evoluir rapidamente nos próximos anos.
O DevOps é a melhor e mais flexível solução para habilitar
as empresas a acompanhar e antecipar a TI de última
geração. Mas, como os resultados de nossa pesquisa
mostram, a adoção e a transformação do DevOps
corporativo também trazem uma série de desafios.
Relatório do DevOps corporativo 2020-21
Desafios da transformação do DevOps corporativo
Gerenciamento de produtos
Quase todas as empresas têm portfólios de produtos/
aplicações existentes, a maioria dos quais ainda hospedados
na infraestrutura local. O suporte a esses produtos
de software é disperso entre equipes fragmentadas,
unidades de negócios e organizações, levando à falta de
propriedade, à duplicação cara de sistemas e esforços e ao
suporte desarticulado ao cliente. Dentro desses portfólios
de produtos diferentes, as organizações empresariais
muitas vezes, por pura necessidade, implementaram
soluções híbridas de software comercial variado que são
incompatíveis entre si. Isso cria uma cultura que incentiva
a entrega de resultados rápidos, mas muitas vezes acaba
causando problemas catastróficos mais tarde. Essas falhas
com frequência se traduzem em gerentes de produtos
sobrecarregados, com pouco treinamento e membros da
equipe que não se sentem à vontade para correr riscos para
resolver problemas sistêmicos.
Equipes distribuídas e trabalho remoto
A capacitação de equipes distribuídas e trabalhadores
remotos tem se tornado cada vez mais importante
nos últimos anos, especialmente após a pandemia de
coronavírus 2020. No entanto, os desafios anteriores de
como habilitar os desenvolvedores a codificar, implantar
e colaborar de qualquer lugar permanecem constantes.
As equipes de DevOps precisam ser equipadas com as
ferramentas de colaboração apropriadas, acesso de rede
de alta velocidade e o equipamento de computação
certo, tudo isso mantendo ambientes seguros. Criar
e manter equipes remotas de alta performance exige uma
combinação de soluções culturais e tecnológicas.
7
Governança
Criar uma estrutura de governança que seja eficaz na
velocidade do DevOps é um grande obstáculo para as
empresas, especialmente por terem diversos portfólios
de produtos e equipes distribuídas. Os modelos de
governança existentes, com ênfase no controle de
custos e eficiência, muitas vezes são contraproducentes
quando aplicados a um modelo de DevOps, que é mais
focado na agregação de valor e no tempo de lançamento
no mercado. Instituir as culturas certas dentro de uma
organização para "fazer a coisa certa, a coisa mais fácil"
é fundamental para enfrentar muitos desses problemas,
em que as práticas culturais e os objetivos de negócios
são claramente definidos, com métricas claras para
acompanhar a integridade de ambos.
Qualidade
Garantir que a qualidade seja mantida à medida que
a frequência de lançamentos de software aumenta é uma
prioridade para as equipes do DevOps corporativo. Essa
prática requer engenharia de qualidade contínua e um
foco em como equilibrar a necessidade de velocidade
com uma demanda de qualidade. Como você migra
equipes do DevOps da mera "contagem de bugs" para
de fato melhorar a qualidade de um produto? Quais
interdependências do SDLC (Software Development
Lifecycle) você precisa conhecer para garantir a qualidade
— e como obter esse insight, especialmente no ambiente
atual de Open Source? É necessário eliminar barreiras
entre diferentes equipes de DevOps, padronizar como
elas trabalham com políticas e estruturas, criar qualidade
em pipelines CI/CD e usar a automação para liberar
profissionais de QA e testar equipes para abordar
a qualidade dentro das empresas.
Relatório do DevOps corporativo 2020-21
Segurança
A responsabilidade pela segurança não poderá ser de
uma equipe dentro da empresa se as equipes de DevOps
autônomas e distribuídas forem capacitadas para criar
e executar suas próprias aplicações e liberar alterações
em seu próprio ritmo. Muitas empresas até se esforçam
para entender as vulnerabilidades no código de Open
Source e não têm a capacidade de proteger ambientes
de nuvem. As empresas são capazes de eliminar uma
enorme quantidade de bugs em potencial antes mesmo
de confirmar código para a validação de campo, aderindo
à proteção dos princípios SDLC e automatização de
processos. Para fazer isso, as empresas precisam de
abordagens claras para a segurança e do investimento
e supervisão adequados da diretoria.
NOTA PARA O LEITOR
O relatório a seguir explica cada um dos desafios
acima em mais detalhes, oferecendo insights úteis
e estratégias implementadas por organizações de
alta performance para ajudar a combater cada um
desses obstáculos. Ao examinar minuciosamente
sua organização e implementar as melhores práticas
e tecnologias que se adequam à estrutura e às
necessidades da organização, esperamos que todas
as empresas, em diferentes estágios de adoção
do DevOps, possam ver melhorias nas principais
métricas de negócios, bem como uma maior
satisfação do cliente.
8
Conformidade
As organizações empresariais estão sujeitas à supervisão
regulatória externa de algum tipo, por exemplo,
SEC, GDPR etc., bem como suas próprias funções de
conformidade interna. Garantir que a conformidade seja
definida, mantida, aprimorada e monitorada de forma
constante e consistente é uma preocupação essencial
e um desafio para as empresas atuais.
Embora de ser aconselhável que todos os leitores
examinem o relatório inteiro, se houver áreas
de desafio flagrantes ou pertinentes que sua
organização precise abordar imediatamente,
incentivamos que procure diretamente essas seções
antes de voltar e ler outras seções. Apesar de
o documento se basear em si mesmo e as seções às
vezes terem referências cruzadas, criamos cada seção
propositalmente como independente.
Relatório do DevOps corporativo 2020-21
O Índice de Velocidade de
Desenvolvedor (DVI)
O sucesso no desenvolvimento de software requer que as
organizações capacitem os desenvolvedores, permitindo
que criem produtivamente, colaborem globalmente e com
segurança e escalem a inovação. Os líderes da indústria
recentemente se referiram a isso como a velocidade do
desenvolvedor (DV). Isso vai além da definição tradicional
de velocidade "ágil", pois não se trata apenas de velocidade,
mas de revelar a criatividade do desenvolvedor para gerar
resultados de negócios. Assim como a velocidade na física,
aqui estamos falando em velocidade com direção.
Com muitas alavancas de melhoria potencial e pouca
análise quantitativa, as organizações muitas vezes
não sabem o que priorizar e quais práticas de
desenvolvimento são as mais eficazes.
A análise de correlação entre os 46 fatores que influenciam
a velocidade do desenvolvedor (como mostrado no
diagrama abaixo) e os indicadores de performance de
negócios revelaram algumas descobertas surpreendentes
sobre os fatores críticos:
1. Apenas um grupo relativamente pequeno de fatores
críticos realmente impulsionou a velocidade do
desenvolvedor
2. Vários fatores percebidos e práticas recomendadas
acabaram tendo menos relevância do que muitos
executivos acreditavam.
AS PRINCIPAIS EMPRESAS POR VELOCIDADE DO DESENVOLVEDOR TÊM UMA VANTAGEM DE INOVAÇÃO
Correlação entre o Índice de Velocidade de Desenvolvedor (DVI) e os principais indicadores
de performance dos negócios
Geral
Inovação
Satisfação do cliente
Percepção da marca
Gerenciamento
de talentos
2
McKinsey Developer Velocity How Software Excellence Fuels Business Performance, 2020
9
Quando os pesquisadores compararam organizações
com pontuações de DVI no quartil superior para o quartil
inferior, encontraram uma melhoria de quatro a cinco vezes
na taxa de crescimento anual agravada (CAGR)2. Olhando
além do simples crescimento da receita, as empresas de
DVI do quartil superior superaram o quartil inferior em
60% no crescimento total do retorno ao acionista (TRS)
e tiveram uma margem operacional 20% maior.
Além de métricas puramente financeiras, o DVI
também está fortemente correlacionado com outros
indicadores importantes de performance dos negócios,
particularmente a inovação (veja a Figura 2). O foco
na performance dos negócios, em vez da performance
operacional, é uma distinção importante para a finalidade
deste relatório. Ele sugere que os atuantes do DVI de quartil
superior reconhecem a relação entre a combinação de
pessoas, processos e tecnologia de DevOps como principais
impulsionadores do sucesso dos negócios, em vez de focar
exclusivamente KPIs de tecnologia tradicionais, como
o custo total de propriedade (TCO), a disponibilidade
de sistemas ou a taxa de falha de alteração. Alinhar
a transformação de DevOps com resultados de negócios
bem-sucedidos é o que leva a mudanças culturais, técnicas
e organizacionais refletidas neste relatório.
FIG. 1
Índice de Velocidade do Desenvolvedor
0,6
Intensidade de inovação
0,6
0,5
0,5
0,4
Estado do DevOps corporativo 2020 10

IMPORTÂNCIA RELATIVA DO QUE LEVA A INDICADORES DE PERFORMANCE DE NEGÓCIOS FIG. 2

Impulsionadores
fundamentais
Arquitetura Arquitetura de software 1,045%
T ECNOLOG IA

Arquitetura de dados 0,586%

Infraestrutura e plataforma Adoção da nuvem pública (IaaS e PaaS) 2,533%

Infraestrutura como código 0,802%

Testes Automação de testes 1,548%

Desenvolvimento orientado a testes 0,324%

Segurança e conformidade Segurança 1,801%

Ferramentas de desenvolvedor
Conformidade 2,887%

Ferramentas Ferramentas de colaboração 5,369%

Ferramentas de desenvolvimento 5,334%

Ferramentas de DevOps 4,565%

Ferramentas de planejamento 6.167%

Pouco código / nenhum código 1,307%

Assistência de IA 1,024%

CI/CD Práticas de CI/CD 0,655%

PRÁTICAS DE TRABAL HO

Práticas de engenharia Gerenciamento de dívida tecnológica 1,73%

Diretrizes de codificação 0,857%

Revisões de código 0,671%

Fonte Open Source/interna Open source 0,693%

Fonte interna 0,432%

Práticas da equipe do Agile Gerenciamento de WIP 0,56%

Definição de pronto 0,336%

Cerimônias 0,46%

Características da equipe Escopo autônomo 1,558%

C APAC ITAÇÃO ORGANIZACIONAL

Alternância de contexto limitado 1,053%

Colocalização 0,493%

Equipe multifuncional 0,514%

Gerenciamento Recursos de PM 6,432%

de produtos (PM)
Telemetria de produto 2,777%

Estratégia de vínculos e métricas da equipe 1,217%

Visão e requisitos do produto 1,247%

Prototipagem rápida 0,559%

Agilidade organizacional Gerenciamento de dependências 1,691%

Modelo de financiamento 0,736%

Gerenciamento de portfólio 0,588%

Cultura Segurança psicológica / "falhar 7,489%

rápido e aprender"
Colaboração e compartilhamento 4,367%
Cultura

de conhecimento
Melhoria contínua
3,774%

Líder de servidor 3,69%

Obsessão do cliente 1,937%

Gerenciamento de talentos Gerenciamento de performance 4,331%

Gerenciamento de talentos

Gerenciamento de integridade da equipe 2,883%

Desenvolvimento de capacidade 3,348%

Recrutamento 2,951%

Proposta de valor de funcionários 2,442%

Planos de carreira 2,238%

0 1 2 3 4 5 6 7 8 9 10
Relatório do DevOps corporativo 2020-21 11

Gerenciamento de produtos
O Velocity Survey de 2020 da McKinsey A mudança de "projeto" para "produto" ajuda a concentrar
a atenção e o esforço de uma equipe nos objetivos do
mostrou que os recursos avançados de produto, que devem ser resultados mensuráveis voltados
gerente/proprietário de produto são um dos para agregação de valor ao cliente. Os objetivos e as listas
quatro principais fatores correlacionados a pendências de trabalho são gerenciados proativamente
para garantir que cada produto agregue valor máximo
um índice de velocidade do desenvolvedor (eficácia), mantendo o baixo custo de propriedade
(DVI) alto, como visto anteriormente. Mas (eficiência). Isso promove um espírito dinâmico
por que uma abordagem centrada no e colaborativo em que as equipes têm responsabilidade
coletiva pelo sucesso. Os desenvolvedores estarão mais
produto é importante para o sucesso propensos a garantir que o código esteja de acordo
do DevOps corporativo? com o padrão se trabalharem em estreita colaboração
com os colegas de operações que serão diretamente
O DevOps defende a formação de equipes multidisciplinares
impactados por problemas que causados por eles. Além
de longa duração que estão alinhadas à entrega de valor
disso, a eficiência é aprimorada por meio de tomadas de
para a organização (fluxos de valor). Talvez a prática mais
decisão e loops de comentários rápidos, evitando o ciclo
importante seja criar equipes alinhadas aos produtos, a fim
demorado de escalonamento testado por equipes com
de simplificar eficiências e criar responsabilidade em nível
altos níveis de dependências em outras equipes.
de produto. Essas equipes de produtos multidisciplinares,
incluindo Dev e Ops, assumem a propriedade
Com o tempo, as equipes de longa duração desenvolvem
e a responsabilidade total durante o ciclo de vida inteiro do
conhecimento profundo e contextual sobre o domínio de
produto, do início ao fim. Isso contrasta com a abordagem
produto, que podem ser usado para aperfeiçoar e otimizar
mais fragmentada e conduzida por projetos da TI
continuamente produtos em prol da organização
tradicional que exige que equipes e indivíduos assumam
e dos clientes.
responsabilidade apenas por um segmento básico
definido do ciclo de vida do produto, desde a criação até
o lançamento. Eles entregam o resultado a uma equipe
de Ops separada para o ciclo de vida operacional do
serviço. A conseqüência dessa mentalidade de projeto, em
oposição a um produto, é a falta de responsabilidade geral,
que dificulta a performance de longo prazo.
Relatório do DevOps corporativo 2020-21
Quais são os desafios?
Os resultados da pesquisa DVI fornecem uma compreensão
mais profunda dos fatores de habilitação organizacional que
promovem os KPIs. No entanto, para começar, é importante
aprofundar os resultados de gerenciamento cultural e de
talentos e o papel que as equipes alinhadas ao produto
desempenham na condução de resultados de negócios.
Confiança e segurança psicológica
Uma das principais descobertas culturais diz respeito
à  contribuição da "segurança psicológica" para
a  performance dos negócios. A professora de Harvard
Amy Edmondson define isso como "uma crença
compartilhada mantida por membros de equipe de que
a equipe está segura para assumir riscos interpessoais".
Inerente a esse conceito está a equipe. Com as equipes do
DevOps corporativo de longa duração, multiqualificadas
e alinhadas a produtos, há amplo espaço para assumir
riscos e inovar. A longevidade dessas equipes permite
que a  confiança seja cultivada e desenvolvida entre os
membros da equipe. Confiança em e entre equipes,
e a confiança em relação a um produto ajuda as pessoas
a se sentirem seguras para inovar, aperfeiçoar e otimizar
enquanto aprendem com as próprias falhas.
RECURSOS DE GERENTE/PROPRIETÁRIO DE PRODUTOS FORTES E EQUILIBRADOS SÃO ESSENCIAIS AO SUCESSO DOS NEGÓCIOS
FOR ÇA DE CORREL AÇÃO E NTRE OS RE CURSOS D O GE RE NTE /P ROPRIETÁRIO DE PRODUTOS E A PERFORMANCE DOS NEGÓCIOS
Pontuação média para todos os recursos de PM
Base de experiência do cliente
(por exemplo, mapeamento da jornada do cliente,
designer de IU/UX)
Habilidades técnicas
(por exemplo, conhecimento de pilha de tecnologia,
definição de requisitos tecnológicos)
Habilidades de software
(por exemplo, influência, formação de equipes)
Orientação do mercado
(por exemplo, tendências de mercado, concorrência)
Perspicácia de negócios
(por exemplo, estratégia de GTM, priorização de roteiro)
0,0
12
A seção de gerenciamento de cultura e desafio da
pesquisa DVI também revelou que a colaboração
e o compartilhamento de conhecimento são difíceis sem
um contexto limitado claro sobre responsabilidades dos
membros da equipe. Da mesma forma, o gerenciamento
de performance é mais complexo, a menos que a equipe
possa ver claramente as contribuições de cada membro para
os objetivos compartilhados, e os membros da equipe se
sintam vinculados e responsáveis pelo trabalho que fazem.
A lacuna do gerente de produto
Ao analisar os cinco recursos principais de um "gerente/
proprietário de produto forte e equilibrado", como
mostrado nos resultados da pesquisa, vemos que ser
um ótimo gerente de produto não é uma tarefa fácil.
Isso requer um equilíbrio de inteligência emocional
e habilidades de software, como a criação de equipes
e uma forte centricidade no cliente. Isso deve ser
complementado com boas habilidades técnicas para
ser capaz de definir os requisitos técnicos, bem como
a perspicácia dos negócios e a orientação de mercado
necessárias para criar os produtos certos para o sucesso
no mercado.
FIG. 3
0,7
0,5
0,5
0,5
0,4
0,4
0,2 0,4 0,6 0,8 1,0
Relatório do DevOps corporativo 2020-21
Assim, com as características de um bom gerente
de produto definidas, certamente deve ser fácil criar
uma equipe centrada em produtos visando o forte
gerenciamento de produtos? Infelizmente, esse não
é o caso. Um dos maiores desafios do DevOps corporativo
é que a quantidade de ótimos gerentes de produto
seja insuficiente. Na verdade, "os CEOs e os líderes de
tecnologia costumam identificam o papel do gerente de
produto como uma das prioridades dos maiores talentos".3
Como não há ótimos gerentes de produto suficientes
para conduzir a criação de soluções internas de software
inovadoras, muitos adotaram o software comercial
pronto para uso (COTS) para preencher essa lacuna.
Novamente, infelizmente, apesar de a implementação de
soluções COTS poder criar uma base sólida para atender
às necessidades de negócios corporativos, elas costumam
exigir personalização e desenvolvimento sob medida
para torná-las adequadas aos requisitos e necessidades
organizacionais. Assim começa o ciclo vicioso, pois
esse desafio de integração e personalização aumenta
a necessidade de um ótimo gerenciamento de produtos.
3
McKinsey, Insights- The Product Management Talent Dilemma, 2020
4
Martin Fowler, Microservices Guide, 2020
13
Lidar com a dívida técnica
Um dos pontos problemáticos mais citados nas entrevistas
com a Sogeti foi o conceito de "dívida técnica". Este
é o acúmulo de decisões técnicas abaixo do ideal tomadas
ao longo da vida útil de uma aplicação de TI, o que cria
situações em que é mais difícil fazer uma mudança
significativa e, em geral, o "acúmulo de imprevistos"
é o que acaba bloqueando iniciativas de TI. Muitas
organizações empresariais acumularam grandes volumes
de dívida técnica, em que o custo de reembolso dessa
dívida pode ser executado em dezenas ou centenas de
milhões de dólares. As equipes centradas em produtos,
como parte da adoção do DevOps corporativo,
juntamente com a migração para a nuvem, são forçadas
a enfrentar esse acúmulo e o subsequente reembolso da
dívida técnica.
Em especial, a tentativa de destrinchar a arquitetura de
aplicação herdada, o padrão de aplicação monolítico, é um
dos principais obstáculos ao tentar criar pequenas equipes
de produtos. Isso levou ao aumento da popularidade das
arquiteturas de microsserviço4 para decompor aplicações
colossais em componentes menores e mais gerenciáveis,
mais alinhados com uma abordagem de equipe de
produto. É importante observar que, embora a dívida
técnica seja um tormento em aplicações, ela também
afeta processos e procedimentos. A transformação do
DevOps corporativo e a adoção de modelos centrados em
produtos dão às organizações a oportunidade de redefinir
fluxos de trabalho para simplificar e acelerar a prestação
de serviços.
Relatório do DevOps corporativo 2020-21
Lidar com os desafios
Crie um portfólio de produtos
A primeira etapa ao implementar o gerenciamento
de produtos de nível empresarial como parte de uma
transformação do DevOps é avaliar minuciosamente
o portfólio de aplicações existente e identificar bons
candidatos para adoção antecipada da abordagem centrada
no produto. Ao fazer isso, aqueles com a melhor performance
em geral escolhem produtos menos dependentes de outros
produtos. Eles também costumam iniciar com produtos
menores para depois avançar. Limitar o tamanho da equipe
de produto será importante para começar. Pesquisas sobre
a performance da equipe recomendam uma equipe em
torno de 7 membros. Em segundo lugar, começar pequeno
permite que líderes de transformação ignorem uma grande
parte da complexidade organizacional e ajuda a definir
expectativas para equipes e funções.
Ao optar por criar uma nova equipe de produtos, escolha
produtos que tenham valor de produto mensurável.
Visualize o valor do produto (eficácia) e os custos
(eficiência) para o ciclo de vida do produto escolhido e crie
uma matriz de valor comercial para priorizar onde sua
equipe dedica tempo. Vale ressaltar que você não precisa
avaliar todas as aplicações e serviços no portfólio de TI
antes de iniciar a transição para um modelo centrado em
produto. Em geral, é possível identificar rapidamente os
alinhamentos de produtos/equipes existentes que podem
criar ganhos rápidos para dar impulso à medida que você
expande de forma iterativa o portfólio de produtos.
Financie seu portfólio de produtos
Em muitas organizações, a forma como os orçamentos
de TI são alocados inerentemente reforça as divisões
entre Dev e Ops. Muitas vezes, o primeiro passo é dividir
o dinheiro em um orçamento de "alteração", alocado para
projetos e um orçamento de "execução", alocado para
o suporte e a manutenção de serviços existentes, licenças
de software e outras despesas operacionais recorrentes.
Os orçamentos de execução tradicionalmente recebem
cerca de dois terços das despesas anuais de TI, deixando
os produtos subfinanciados e com apoio insuficiente.
14
Além disso, o orçamento é geralmente um processo
anual, com o financiamento alocado previamente
para os próximos 12 meses. Isso muitas vezes deixa
pouco espaço para a inovação e inibe a resposta de
forma ágil às necessidades emergentes dos clientes.
Algumas organizações, lideradas pelo movimento
Beyond Budgeting, chegaram ao ponto de largar
o processo orçamentário anual inteiramente em favor de
métodos de orçamento mais flexíveis e adaptáveis.
Os modelos de financiamento que focam o produto
e a equipe de produtos estão aumentando a popularidade.
Nesses casos, o financiamento é alocado a um produto
e, por sua vez, o proprietário do produto decide como
alocar esse financiamento para dar suporte às equipes de
produto na criação e na operação do produto.
Outras organizações adotaram modelos de financiamento
de portfólio alternativo com base no financiamento
de capital de risco (VC). No modelo de financiamento
de VC, o investimento é alinhado a etapas-chave no
desenvolvimento do produto — o financiamento de
sementes para criar um protótipo e avaliar o ajuste inicial do
produto/mercado, o financiamento da série A para escalar
a ideia etc... Assim como em uma empresa típica de VC,
um comitê de investimento deve reunir-se regularmente,
em geral a cada quinze dias, para revisar novas propostas
de investimento de gerentes de produto e avaliar
a performance dos produtos existentes no portfólio.
Ofereça suporte a produtos com plataformas self-service
Assim que uma empresa ultrapassa um pequeno grupo
de equipes de produto, é benéfico começar a apresentar
plataformas self-service com recursos principais.
Com várias equipes autônomas, é fácil reinventar
desnecessariamente sistemas principais, como as cadeias
de ferramentas CI/CD, levando ao desperdício de um
tempo valioso que poderia ter sido empregado em
inovação. O trabalho dessas equipes de plataforma
é impedir que equipes de produtos separadas se esforcem
em vão e fornecer recursos que as ajudem a fazer o melhor
trabalho possível.
Relatório do DevOps corporativo 2020-21
De acordo com suas necessidades, você pode ter equipes
de plataforma com mandatos que abranjam: entrega
contínua, monitoramento e capacidade de observação,
segurança e conformidade, infraestrutura de nuvem,
automação de testes e dados.
Na verdade, as equipes de plataforma são apenas equipes
de produto que fornecem um produto para clientes
internos. É importante pensar nas equipes de entrega de
produtos como clientes porque as equipes da plataforma
devem, em geral, não ter obrigação de controlar o que as
equipes de produto fazem. Esta mensagem é reforçada
pelas próprias experiências da Microsoft. A Microsoft foi
usuária pioneira do modelo de equipe da plataforma,
formando a equipe do One Engineering System (1ES) em
2014. A função do 1ES era capacitar todos os engenheiros
da empresa, padronizando as melhores ferramentas
disponíveis. A equipe do 1ES compartilhou as lições
aprendidas no caso de sucesso do DevOps e suas 5 etapas
para mudar a cultura do whitepaper5.
InnerSource
Outra parte fundamental do modelo de equipe do
produto e da plataforma é o padrão InnerSource (também
conhecido como fonte compartilhada da empresa).
No guia para adotar o InnerSource, Danese Cooper
e Klaas-Jan Stol definem esse padrão como: "uma maneira
colaborativa e capacitadora de envolver os funcionários
na tomada e na implementação de decisões em toda
a corporação. Ele incorpora uma filosofia de relações
humanas, uma abordagem de recompensas e motivações
e um conjunto solto e adaptável de ferramentas e práticas."
As organizações com uma grande base de desenvolvedores
estão adotando o InnerSource seguindo os princípios
básicos do GitHub do InnerSource6. Cada vez mais estamos
vendo essa abordagem aberta e transparente aplicada
a muitas outras áreas dentro da TI, como governança,
arquitetura de referência, padrões de segurança e práticas
recomendadas, mas ela também pode ser aplicada
em muitas outras circunstâncias. Os benefícios que as
organizações acabam alcançando com a adoção do
InnerSource incluem agilidade de entrega, colaboração
5
Microsoft Azure, Five Steps to Culture Change, 2019
6
GitHub, Introduction to InnerSource, 2020
7
McKinsey, Insights- The Product Management Talent Dilemma, 2020
15
mais tranquila entre grupos, desenvolvimento de maior
qualidade e melhor documentação.
As equipes de plataforma são cruciais nesse esforço,
pois fornecem transparência sobre como as plataformas
self-service são criadas e mantidas compartilhando
o código-fonte por meio de um repositório de código
(repositório). As equipes de plataforma devem atuar como
mantenedores desse repositório, mas qualquer pessoa
pode contribuir para isso, Se a equipe de produto descobrir
que precisa estender os recursos de algo que uma equipe
de plataforma criou, não deverá esperar que a equipe de
plataforma faça isso. Espelhando o fluxo de trabalho do
colaborador de projetos Open Source, as equipes podem
codificar a alteração que desejarem e retorná-las à equipe
de plataforma como uma solicitação pull. Após revisão
e aprovação, a alteração poderá ser incorporada à base de
código principal. Todo o processo, em última análise, reduz
a rotatividade, economiza tempo valioso e capacita os
funcionários a serem proativos e a assumir riscos.
Cultive talentos de gerenciamento de produtos
Cultivar e desenvolver grandes talentos de gerenciamento
de produtos na organização é fundamental para o sucesso.
Considerando a concorrência no mercado para gerentes
de produto, o foco na identificação e no desenvolvimento
de talentos internos é a melhor estratégia. Para ajudar as
empresas a alcançar esse objetivo assustador, a McKinsey
identificou quatro etapas fundamentais para criar um
programa de qualidade para talentos de gerenciamento
de produtos7:
1. Articular o modelo de desenvolvimento de liderança
de gerenciamento de produto para a organização.
2. Fornecer aos gerentes de produto os
capacitadores organizacionais para o crescimento
e a aprendizagem contínuos.
3. Aproveitar uma "abordagem de campo e fórum"
para projetar uma jornada de aprendizado de ponta
a ponta, combinando treinamento no trabalho com
aprendizado em sala de aula ou bootcamp.
4. O recrutamento de gerente de produto deve ser uma
prioridade estratégica para a liderança sênior.
Relatório do DevOps corporativo 2020-21
CASO DE SUCESSO DE GERENCIAMENTO DE PRODUTO
Na indústria de moda acelerada, o tempo de
comercialização é essencial. Mas, para um varejista de
moda online em rápido crescimento, os sistemas de
TI desatualizados e complexos estavam se esforçando
para acompanhar o ritmo dos negócios em expansão
da empresa.
O varejista vende mais de 80.000 produtos de marca
e produtos de marca própria por meio de experiências
localizadas móveis e na Web. Desenvolver e manter todas
as aplicações necessárias para dar suporte a negócios
se tornou uma grande barreira para a inovação. A TI
não conseguiu escalar além de 300 lançamentos por
ano, resultando em gargalos significativos no pipeline.
A manutenção utilizou muitos recursos, enquanto as
inconsistências retardaram a entrega e aumentaram o risco.
O número de equipes de desenvolvimento aumentou de
dois para 35 em um curto período de tempo, trabalhando
em todo o site de varejo, soluções de pagamento,
pedidos e sistemas de desenvolvimento de back-office.
A entrega de software foi canalizada por meio de uma
solução de implantação complicada, com uma função de
lançamento e implantação centralizada. Eles precisavam
desesperadamente modernizar os sistemas para aumentar
RECURSOS AVANÇADOS DE GERENCIAMENTO DE PRODUTOS
Crie um portfólio de produtos
Migre do projeto para o produto
Financie seu portfólio de produtos
Saiba mais sobre o Beyond Budgeting
InnerSource com eficácia
Leia o folheto do GitHub do InnerSource
Cultive talentos de gerenciamento de produtos
Leia o guia para começar o gerenciamento de produtos
16
rapidamente a velocidade e a frequência com que as
atualizações de software e os novos recursos poderiam
ser liberados.
Uma abordagem do DevOps corporativo foi adotada para
substituir a entrega de software complexa e manual por
novas ferramentas e formas de trabalho modernas. As
equipes da Agile alinhadas por produtos foram criadas
com base em áreas funcionais do site, como pesquisa
ou cesta de compras, visando capacitar cada equipe
para iterar e melhorar a área de produto específica da
forma mais independente possível. Cada equipe de
desenvolvimento foi migrada individualmente para
um novo pipeline de entrega contínua, permitindo
a criação e implantação de produtos em qualquer lugar,
continuamente inovando e assumindo riscos.
A organização já escalou mais de 80 equipes de produtos
da Agile, que liberam mais de 3.000 lançamentos por ano,
o que permitiu que a organização atingisse um CAGR de
23% nos últimos quatro anos.
"O processo de lançamento agora
é consistente do desenvolvimento até
a prática. Temos uma taxa de sucesso
mais elevada e melhor visibilidade que
nos permitem ver quem fez alterações,
quando e onde os problemas estão
ocorrendo. Antes não era possível fazer
isso e a gerência agora confia muito
mais de que tudo está sendo feito da
maneira correta."
gerente de projetos, The Fashion Retailer
Relatório do DevOps corporativo 2020-21
Equipes distribuídas
e trabalho remoto
O trabalho distribuído e remoto não
é um novo conceito para as equipes de
desenvolvimento — as empresas têm
escritórios em todo o mundo e precisam
fornecer recursos para que os funcionários
trabalhem e para dar suporte aos clientes,
em diferentes fusos horários.
Muitas dessas organizações terceirizaram o trabalho para
aumentar a capacidade de entrega, reduzindo custos.
Algumas empresas dão aos funcionários a flexibilidade de
trabalhar em casa ou em qualquer outro local, onde for
melhor para eles. Novos fluxos de colaboração começam
a ser adotados, tanto em cadeias de valor da empresa
quanto no domínio social individual dos funcionários. Ao
mesmo tempo, as plataformas de colaboração baseadas
em SaaS trazem comunicações avançadas e ferramentas de
compartilhamento de documentos ao alcance de todas as
pessoas da empresa. Em particular, vimos grandes avanços em
ferramentas de produtividade remota de desenvolvedores.
As plataformas de produtividade do desenvolvedor, como
o GitHub, por exemplo, permitem que equipes distribuídas
e trabalhadores remotos colaborem efetivamente para
alcançar objetivos de desenvolvimento de software.
O Git, um sistema distribuído de controle de versão
originalmente desenvolvido para o projeto de kernel do
Linux, permite que os desenvolvedores trabalhem em
código-fonte desconectado de repositórios centralizados,
mas mesclem facilmente alterações no local central. É
compreensível que diferentes necessidades de colaboração
exijam suporte específico para operar da forma ideal.
Muitos desenvolvedores são altamente experientes em
trabalhos remotos como resultado da composição única
da indústria. Assim, eles colaboram para além dos limites
organizacionais em projetos Open Source e InnerSource.
17
A pandemia COVID-19 trouxe uma necessidade
urgente de fazer a transição para o trabalho remoto,
com os governos solicitando às pessoas que fiquem
em casa e evitem trabalhar em escritórios. Isso mudou
drasticamente as formas de trabalhar e viver. Os membros
da equipe, em todos os níveis de responsabilidade, em
organizações não consideradas serviços "obrigatórios"
ou "essenciais" foram obrigados a trabalhar em casa em
algum momento durante a crise.
O trabalho remoto obrigatório é muito diferente do
trabalho remoto como uma opção estratégica ou
operacional. A velocidade com que as organizações
precisaram migrar para um modelo de trabalho totalmente
remoto foi um choque e causou um frenesi em muitos
departamentos de TI que não tiveram tempo para se
preparar. O ambiente econômico em mudança significava
que os modelos de negócios eram forçados a se adaptar
rapidamente. Foi dada uma ênfase adicional à eficiência
e à redução custos, buscando de alguma maneira fornecer
o mesmo valor aos clientes que anteriormente. Os roteiros
de projetos e produtos existentes foram deixados de lado.
As equipes de TI se mesclaram para fazer o que podiam,
implementando recursos de videoconferência, assinaturas
eletrônicas e redes de alta qualidade, procurando
provisionar ambientes de hardware e desenvolvedor
e cuidando da proteção e segurança dos dados da empresa.
À medida que continuamos a lidar com a ideia de trabalho
remoto obrigatório, surgem oportunidades para aprender
com os desafios enfrentados e de focar o crescimento.
Embora não possamos ter certeza do que está por vir,
para nos prepararmos melhor para as próximas fases de
adoção do COVID19 e do DevOps corporativo, vários
desafios devem ser abordados.
Relatório do DevOps corporativo 2020-21 18

Quais são os desafios?

As organizações precisam, simultaneamente, adotar Desafios da capacidade de trabalho remoto

práticas de trabalho remotas, adaptando-se a um
cenário de negócios bem diferente. Algumas empresas
simplesmente tentam sobreviver, muito focadas na
redução de custos, enquanto outras organizações
percebem um enorme aumento na demanda por serviços
e precisam descobrir como atender a essa demanda com
uma equipe de trabalho que se tornou remota.
Sob a perspectiva das equipes do DevOps, os desafios
da operação de equipes distribuídas podem ser
categorizados em três áreas distintas:
Como a pesquisa DVI indica, ter as ferramentas de
desenvolvedor certas é um dos maiores propulsores
da performance dos negócios e as ferramentas de
colaboração são um dos fatores-chave nessa cadeia de
ferramentas. É claro que muitas empresas investiram
pouco na criação de cadeias de ferramentas para apoiar
o desenvolvimento e a colaboração remotos, levando
a um esforço para adotar soluções híbridas que terão
grandes repercussões futuras.

• Como codificar em qualquer lugar — permitindo

que desenvolvedores definam e mantenham uma
capacidade de trabalho remoto eficaz
• Como enviar de qualquer lugar — criar, testar
e implantar alterações de aplicações, continuando
a gerenciar sistemas de produção, de forma segura
• Como colaborar de qualquer lugar — equipe
distribuída eficaz que trabalha incluindo voz, código
e compartilhamento de documentos

IMPORTÂNCIA RELATIVA DO QUE LEVA A INDICADORES DE PERFORMANCE DE NEGÓCIOS FIG. 4

Arquitetura Arquitetura de software 1,045%

T ECNO LOG IA

Arquitetura de dados 0,586%

Infraestrutura e plataforma Adoção da nuvem pública (IaaS e PaaS) 2,533%

Infraestrutura como código 0,802%

Testes Automação de testes 1,548%

Desenvolvimento orientado a testes 0,324%

Segurança e conformidade Segurança 1,801%

Conformidade 2,887%
Ferramentas de desenvolvedor

Ferramentas Ferramentas de colaboração 5,369%

Ferramentas de desenvolvimento 5,334%

Ferramentas de DevOps 4,565%

Ferramentas de planejamento 6,167%

Pouco código / nenhum código 1,307%

Relatório do DevOps corporativo 2020-21 19

ferramentas que clonam e sincronizam dados parecem

oferecer soluções potenciais, mas também trazem uma
50% série de problemas.

aumento de bugs para equipes que são

distribuídas x colocalizadas8 Colaboração em equipe em ativos de qualquer lugar
A colaboração em equipe vai além da capacidade de
alocar itens de trabalho para membros da equipe. Para
Criar cadeias de ferramentas eficazes em geral exige inovar, os membros da equipe precisam ser capazes de
tempo e investimento. No entanto, a pandemia da coletar comentários dos clientes, compartilhar ideias,
COVID-19 resultou no aceleramento massivo, por parte de debater e resolver problemas juntos, tarefas que são
muitas organizações, da implantação do desenvolvedor dificultadas por uma equipe de trabalho totalmente
e da cadeia de ferramentas de colaboração remota. As remota. As organizações precisam capacitar as equipes
empresas já estão se recuperando das consequências com as ferramentas de colaboração remota certas
derivadas. Há problemas aparentemente pequenos, como e  treiná-las para trabalhar de forma eficiente dentro das
falta de computadores e largura de banda suficiente, limitações impostas pelo trabalho remoto.
até desafios mais complexos e preocupantes, como
GRÁFICOfísicos
ambientes CIRCULAR (pginadequados
inseguros, 21) para trabalhos Implantar de qualquer lugar
41% de aumento de conexões de desktop
confidenciais e um grande aumento de bugs8. remotas As organizações com grandes portfólios de aplicações
expostas à medida que as equipes tentam acessar
na infraestrutura local, gerenciadas por ferramentas de
ambientes de trabalho remotamente
gerenciamento na infraestrutura local, enfrentam desafios

41% significativos agora que os administradores de sistema são

forçados a trabalhar remotamente. Para manter e atualizar
aumento de conexões de desktop
remotas expostas à medida que as esses sistemas na infraestrutura local, uma solução de
equipes tentam acessar ambientes de acesso remoto segura deve ser disponibilizada, com
trabalho remotamente9
a capacidade de lidar com o aumento do volume para
trabalhadores remotos. Em geral, leva tempo para criar
Permitir que os membros da equipe trabalhem e implementar uma solução de acesso remoto segura, ou
remotamente sem atritos é um grande desafio. Não ser para escalar essa capacidade — um tempo que muitas
capaz de rastrear o trabalho, acompanhar o progresso, organizações não têm.
compilar o código, executar testes ou simplesmente
fazer os trabalhos que precisam ser feitos torna-se uma
dificuldade sem as ferramentas certas e a capacidade de
executá-los remotamente.

A segurança, ao trabalhar de forma distribuída, tem várias

camadas — as conexões de rede precisam ser protegidas
e criptografadas, enquanto o acesso a ativos da empresa
ou do cliente também deve ser protegido. Em muitas
organizações, os dados da empresa nem sequer são
permitidos em ambientes pessoais. O gerenciamento de
ferramentas de controle de origem, como o Git, sistemas
de replicação de arquivos como o OneDrive e outras

8
McKinsey, A New Management Science for Technology Delivery, 2019
9
ZDNet, RDP and VPN Use Skyrocketed Since Coronavirus Onset, 2020
Relatório do DevOps corporativo 2020-21
Lidar com os desafios
Plataformas de colaboração
Ferramentas de colaboração remota, como o Microsoft®
Teams e o Zoom, foram rapidamente adotadas por todas
as organizações que migraram para o trabalho totalmente
remoto. Apesar de as equipes do DevOps existentes
estarem bem familiarizadas com as ferramentas de
colaboração online, outras demoraram para se adaptar.
A maioria das equipes do DevOps estão familiarizadas
com sistemas de controle de versão distribuída, tornando
a transição perfeita, mas para manter a conexão, muitas
equipes criaram vários pontos de verificação de equipe
para manter a participação da equipe alta.
As equipes do DevOps exigem conexões informais,
para imitar o compartilhamento de conhecimento
e a colaboração menos organizados. É por isso que elas
estabelecem canais de chat no Slack e no Microsoft Teams
como substitutos para ambientes de coworking e conversas
nas pausas para o café. Avaliações por pares, brainstorms de
projetos etc. exigem abordagens diferentes. Por exemplo,
os recursos de colaboração de GIT, como "solicitações
pull" e os recursos das ferramentas de suporte, permitem
que os desenvolvedores adicionem avaliações por pares
e comentários de colegas ao trabalhar remotamente.
Para cenários de treinamento e explicação ad hoc, equipes
e organizações bem-sucedidas estão adotando o Visual
Studio Live Share, permitindo que os desenvolvedores
codifiquem juntos no mesmo ambiente. O mesmo
conjunto de ferramentas pode ser usado para treinamento
ou para entrevistas de contratação, pois fornece um
espaço colaborativo para que os desenvolvedores
trabalhem juntos, lado a lado, virtualmente.
A nuvem como um capacitador de trabalho remoto
Habilitar as equipes a acessar com segurança o código
e os dados tem sido um dos maiores obstáculos a serem
superados pelos departamentos de TI à medida que
a equipe de trabalho é forçada a migrar para o trabalho
remoto. Em especial, muitos desenvolvedores podem não
ter acesso em casa ao hardware de computador de alto
padrão que desfrutam no ambiente do escritório, nem ao
acesso seguro a ambientes e dados de desenvolvimento.
10
Resultados de pesquisa interna da Microsoft
20
As soluções de nuvem ajudaram as empresas a superar
esse problema. Para reduzir a baixa performance e os
computadores locais inseguros, as organizações de melhor
performance adotaram soluções Virtual Desktop Infrastructure
(VDI) ou máquinas virtuais (VMs) na nuvem. Um ambiente
de desenvolvedor hospedado na nuvem e gerenciado
centralmente pode ajudar a resolver muitas das questões de
configuração de ambiente que os desenvolvedores costumam
encontrar. Além disso, as organizações que antes adotavam
plataformas de DevOps baseadas em SaaS, como o GitHub
ou o Azure DevOps, já tinham resolvido esses desafios, e os
membros da equipe conseguiram fazer a transição perfeita
para o trabalho remoto.
2 dias
o tempo típico que desenvolvedores levam
para configurar um ambiente10
As organizações que já aproveitam os ambientes de
nuvem (em vez de ambientes na infraestrutura local)
para cenários de teste podem simplesmente continuar
executando casos de teste. Por outro lado, as equipes
sem capacidade de teste de nuvem têm dificuldade na
execução de testes e adotam serviços como o Azure
DevTest Labs para aliviar esse problema.
Com base na breve pesquisa referente a 250 projetos
de clientes da Sogeti, determinamos que a maturidade
do DevOps em si não teve forte influência na transição
para o trabalho remoto, embora houvesse uma pequena
diferença na facilidade de transição para equipes mais
maduras do DevOps. No entanto, a adoção e o investimento
em plataformas de nuvem simplificaram a  transição para
o trabalho remoto, em grande parte devido aos recursos de
escala e ao fato de que as soluções de acesso remoto seguro
já estavam em vigor. Isso significava que essas empresas
podiam continuar trabalhando e escalar facilmente para
uma organização mais distribuída.
Relatório do DevOps corporativo 2020-21
TRABALHO REMOTO E DISTRIBUÍDO — PRÁTICAS RECOMENDADAS DA MICROSOFT
Os itens a seguir foram extraídos diretamente de uma comunicação interna da Microsoft que define áreas específicas
de foco para permitir a produtividade remota da equipe de trabalho de desenvolvedor durante a COVID-19.
Incentivar a cultura de equipe
O trabalho remoto limita nossa capacidade de conversar
com alguém da mesa ao lado, andar pelos corredores
e reunir-se para almoços em grupo. Tudo isso colabora
para que os membros da equipe se desconectem dos
colegas. Para manter um ambiente de equipe colaborativo,
estabelecemos práticas de equipe, incluindo:
• Um canal de cultura no Microsoft Teams a ser usado
para conversas virtuais nas pausas do trabalho.
• Almoços virtuais e intervalos.
• Caminhadas ao ar livre durante chamadas de
check-in com colegas de equipe.
• Um tabuleiro de bingo de videoconferência, com itens
do tipo "cachorro latindo", "crianças brincando" etc.
• Uso do chat para perguntas e comentários ao
vivo e coesão da equipe, especialmente quando
alguns colegas precisam ficar calados por causa do
ambiente  de trabalho.
Manter-se informado
Manter os funcionários informados é um aspecto
importante do trabalho remoto.
• Nossa equipe criou uma lista online de informações
úteis, desde ponteiros de trabalho remoto e
orientação em toda a empresa até o hardware atual
e dicas para auto-hospedagem. Ela é atualizada
diariamente, em alguns casos por hora, com as
informações mais recentes à medida que chegam.
• Também tentamos gravar eventos virtuais e mais
reuniões do dia a dia em geral, para que as pessoas
possam acompanhar e assistir em sua própria agenda
ou fuso horário.
21
Configuração de tecnologia
Para otimizar nossos engenheiros para o trabalho
remoto, começamos pela configuração de tecnologia,
garantindo que eles tenham as conexões de hardware
e rede certas. A maioria dos nossos engenheiros já têm um
laptop disponibilizado pela Microsoft para permitir que
executem funções remotamente. Também incentivamos
os funcionários a trazer monitores, hardware e periféricos
para imitar configurações de trabalho no escritório. Isso
é especialmente importante para os desenvolvedores que
usam configurações de dois ou três monitores.
Um dos aprendizados de acesso remoto para equipes
de desenvolvimento é que, obviamente, os serviços de
nuvem podem ser uma opção de infraestrutura essencial
para permitir a produtividade remota do desenvolvedor.
Por exemplo, o GitHub Codespaces permite que você
crie ambientes de desenvolvimento hospedados na
nuvem e, em seguida, conecte-se a eles com editores de
sua escolha.
A nuvem pode ser útil até mesmo para desenvolvedores
que trabalham exclusivamente em desktops. Eles podem
usar laptops corporativos com uma solução Área de
Trabalho Virtual do Windows que permite a conexão
ao ambiente de desenvolvimento executado em VMs
avançadas na nuvem x localmente no dispositivo.
Envio
Em seguida, precisamos manter nossos ritmos bem
definidos para o envio de software. As equipes de
engenharia dependem de reuniões regulares diárias
e chats de shiproom para que todos progridam. Essas
reuniões não devem ser — e não são — abolidas.
Relatório do DevOps corporativo 2020-21 22

Fizemos uma migração delas exclusiva para o Microsoft Contratação

Teams. Além de ser o hub para reuniões remotas, o Teams
tem aplicações específicas para o desenvolvimento de
software, como o Azure Boards para planejar e rastrear
trabalhos, e o Microsoft Whiteboard, que permite aos
participantes da reunião esboçar fluxos e mapear ideias.
Essas ferramentas ajudam a reunir os membros da equipe
como se estivessem no escritório.
A contratação é outro processo essencial que não pode
ser deixado de lado enquanto trabalhamos remotamente.
Utilizamos o Live Share em entrevistas técnicas, o que
nos permitiu interagir e se comunicar com os candidatos
usando ferramentas com as quais estavam familiarizados.

Aprendizagem por pares

Trabalhar remotamente pode ser um desafio para os
desenvolvedores que participam de avaliações por pares
ou programação por pares, em que normalmente se
sentam lado a lado e aprendem uns com os outros. Nossos
desenvolvedores usam o Visual Studio Live Share para
sessões de depuração conjunta e aprendizagem por pares.
O Live Share permite que desenvolvedores trabalhem
juntos e de forma independente, muito semelhante
à colaboração presencial.

EQUIPES DISTRIBUÍDAS E RECURSOS AVANÇADOS DE TRABALHO REMOTO

Plataformas de Colaboração
Comece a usar o GitHub
Software de chat em grupo

A nuvem como um facilitador de trabalho

Introdução ao Visual Studio LiveShare
Relatório do DevOps corporativo 2020-21 23

Governança
A governança da TI faz parte da estratégia
geral de governança corporativa e garante
que as decisões de TI estejam alinhadas
com a estratégia de negócios. A boa
governança não é apenas "fazer as coisas
certas", mas também "fazer as coisas da
maneira certa".
Há uma ampla variedade de estruturas de governança de
TI, desde as mais comuns, como a COBIT 2019 até padrões
internacionais como a ISO38500. A maioria das estruturas
descreve as funções, responsabilidades, estrutura
organizacional e processos para orientar a tomada de
decisão na TI.
Startups e empresas de pequeno porte ágeis tendem
a aceitar a adoção e o amadurecimento de práticas do
DevOps. Elas costumam ter processos de governança
leves com gerenciamento simples e ainda mais fáceis
de automatizar. Empresas maiores com processos de
governança profundamente enraizados e regras rígidas
em geral demoram mais tempo, mas podem se beneficiar
enormemente da simplificação e da automação.
Se a governança de TI costuma determinar a velocidade
de mudança da TI, ela pode ser essencial para promover
a mudança rápida ou retardar a agregação de valor.

A governança influencia a forma como as metas

são definidas e atingidas pela TI. Ao mesmo tempo,
a governança também entra em conflito com
a independência desejada pelas equipes do DevOps.
Essas equipes precisam seguir os padrões organizacionais
em termos de arquitetura, segurança e procedimentos,
mas muitas vezes os consideram como obstáculos para
a entrega rápida. Apesar de serem trilhos de guia para
apoiá-los, a equipe muitas vezes os veem como inibidores
da inovação. Mas esses trilhos de guia também podem
ser a base de compartilhamento de conhecimento para
desenvolver equipes e indivíduos. Essa tensão entre
as restrições de importunos dos modelos tradicionais
de governança e os benefícios mais amplos que a boa
governança pode trazer está no cerne do desafio de
governança do DevOps.
Relatório do DevOps corporativo 2020-21
Quais são os desafios?
A TI como centro de custo, em vez de facilitador
estratégico
Muitas implementações de governança existentes se
baseiam no modelo de TI como centro de custo. Como
resultado, o foco principal é a economia. O DevOps,
por outro lado, é baseado em um modelo de "TI como
facilitador de negócios estratégicos", dedicado a acelerar
a inovação e o tempo de lançamento no mercado.
O ritmo lento dos processos de governança não DevOps
existentes paralisa a inovação e, muitas vezes, faz com que
ele parece mais um obstáculo do que um ativo.
Uma grande corporação de serviços financeiros que
entrevistamos leva no mínimo dois meses e 23 entregas
para obter a aprovação de uma ordem de compra.
Em outro exemplo, um provedor de telecomunicações
global leva no mínimo quatro semanas para que uma
proposta seja aprovada para o desenvolvimento de novos
softwares, cinco semanas para obter um ambiente, duas
a três semanas para fazer uma mudança de firewall e de
quatro a seis semanas para testes de ponta a ponta. Cada
uma dessas etapas é necessária para passar os processos
de aprovação de governança por meio de tíquetes
gerados da Central de Serviços. Esses processos foram
adotados visando "economizar dinheiro".
Governança prescritiva demais
Estruturas de governança altamente prescritivas baseadas
em regras são fragmentadas em escala empresarial.
No cenário de tecnologia de uma empresa, com
diferentes sistemas operacionais, implementações de
software poliglota e diversas atitudes em relação ao
risco, a frequência com que uma exceção às regras
é necessária acaba resultando em tudo considerado
como uma exceção, prejudicando demais os objetivos de
boa governança.
24
As implementações de governança herdadas têm
dificuldade para se adaptar à rápida evolução da
tecnologia. Por exemplo, ao analisarmos a evolução
da hospedagem de aplicações — sejam servidores
físicos, servidores virtuais, VMs hospedadas na nuvem,
contêineres e sem servidor — notamos que cada etapa
evolutiva precisa de regras de governança. O ritmo em
que a tecnologia evolui significa que é praticamente
impossível tentar prescrever a governança em um nível
de detalhe vinculado à implementação de tecnologia,
garantindo que ela permaneça relevante.
Para além da TI
Uma percepção comum é de que o DevOps é "algo da
TI" ou um "kit de ferramentas de desenvolvedor", como
o Agile foi antes dele. Na realidade, apesar de o DevOps
ser um modelo operacional mais recente para a TI, ele
está intrinsecamente vinculado à transformação digital
da organização inteira e a estrutura de governança
precisa abranger toda a empresa, não apenas a TI. No
entanto, o próprio modelo do DevOps representa desafios
de governança. Muitas vezes, as formas de trabalho
do DevOps, notadamente a liberdade e a autonomia
concedidas às equipes, foram mal interpretadas por
algumas equipes como uma liberdade do processo ou de
qualquer governança formal — um equívoco que precisa
ser abordado durante a implementação.
A necessidade de inteligência em tempo real
Por fim, sem comentários eficazes, de preferência em
tempo real, pode ser difícil atingir níveis apropriados de
governança. Ambientes de aplicações dinâmicos, o rápida
lançamento de novos recursos e a adoção mais rápida de
novas tecnologias significam que nunca foi tão necessário
ter business intelligence em tempo real que apoie
o modelo de governança.
Relatório do DevOps corporativo 2020-21 25

Lidar com os desafios

Faça a coisa certa, a coisa fácil
As equipes de governança bem-sucedidas devem
procurar trabalhar em prol de um princípio de governança
abrangente que faça a coisa certa, a coisa fácil. Dessa
forma, o cumprimento da governança torna-se o caminho
de menor resistência, e não um obstáculo a ser superado.
A função de governança pode dar suporte às equipes
do DevOps, publicando as práticas recomendadas que
fornecem orientações úteis e práticas. Criar uma cultura de
compartilhamento de conhecimento também pode tornar
a organização inteira mais eficiente e ajudar a desenvolver
equipes e indivíduos em termos de experiência e recursos.
Princípios, não regras
Tichaona Zororo, diretora da ISACA, a organização que
publica a estrutura de governança COBIT, aponta para um
princípio fundamental quando diz: "a governança deve se
basear em princípios e resultados e não em regras".
Um excelente exemplo dessa abordagem é o padrão
de serviço digital do governo britânico projetado
para melhorar a entrega de serviços digitais por
organizações do setor público do Reino Unido. O padrão
descreve 14 princípios de alto nível que regem o ciclo
de vida completo de um serviço digital — consulte
The Service Standard helps teams to create and run great
public services.
Antes de ativar qualquer serviço, as equipes precisam
demonstrar que o serviço está alinhado com os padrões
definidos, embora as especificidades da implementação
de cada equipe possam variar. Por exemplo, o padrão №7
diz "Usar formas ágeis de trabalho", mas não exige Scrum,
DSDM, Kanban ou qualquer outro método ágil específico.
Os métodos de implementação cabem a cada equipe,
mas, seja qual for a escolha da equipe, ela deverá estar
alinhada com a orientação mais detalhada.

A governança não trata da adoção de uma mentalidade

de comando e controle que busque impor regras
rígidas para controlar a entrega de serviços de TI em um
mundo de TI em rápida evolução. Em vez disso, trata-se
de delinear um conjunto de princípios ou resultados
fundamentais aos quais as equipes e os produtos devem
aderir. As equipes de governança devem fornecer padrões,
estruturas e ferramentas comuns que auxiliem as equipes
a aderir a esses padrões e, ao mesmo tempo, delinear
claramente as expectativas. Isso, por sua vez, oferece às
equipes a flexibilidade para desenvolver suas próprias
implementações, contanto que estejam alinhadas com os
princípios e os resultados acordados.
Relatório do DevOps corporativo 2020-21 26

ADOTAR UM MODELO DE INNERSOURCE

De acordo com os princípios fundamentais do GitHub do InnerSource11, a implementação bem-sucedida da
governança deve basear-se nestes cinco princípios fundamentais:

Aberto
Democratizar o acesso, criar igualdade de condições para o compartilhamento aberto de
trabalho, ideias e comentários e garantir o alinhamento cultural e estratégico.

Transparente
Garantir que o processo, bem como o produto, seja visível, predominantemente
dissociando as comunicações do tempo e do espaço.

Participativo
Compartilhar o trabalho e facilitar a descoberta, o uso e a contribuição dos outros.

Colaborativo
Trabalhar em conjunto para aumentar gradualmente a qualidade, a distribuição do
conhecimento e a velocidade de envio.

Controlado
Direcionar, orientar e apoiar a comunidade de software, por meio de padrões, funções e
patrocínio executivo.

A governança deve ser encarada menos como um As diretrizes e os artefatos de governança mantidos por
processo externo imposto às equipes e mais como uma meio de um modelo de InnerSource trazem a propriedade
coleção de práticas recomendadas compartilhadas que compartilhada para as equipes e uma maior motivação
tornam o trabalho melhor e mais eficiente. para usar e seguir as diretrizes de governança.

Em um nível muito prático, garantir que tudo (desde

o código-fonte da aplicação e padrões arquitetônicos
até padrões de segurança e metodologias de
desenvolvimento) seja aberto e transparente evidencia
que qualquer pessoa tem a oportunidade de desafiar
esses padrões e contribuir para melhorá-los.

11
GitHub, InnerSource, 2019
Relatório do DevOps corporativo 2020-21 27

Plataformas e arquiteturas de referência executáveis A consistência em escala empresarial é muitas vezes

As organizações com melhor performance estão criando
plataformas de tecnologia self-service, com o suporte de
uma documentação abrangente que ajuda os usuários
a aproveitar essas plataformas para, em última análise,
criar produtos melhores. Essas plataformas compartilhadas
permitem que as organizações incorporem e facilitem
a governança e, ao mesmo tempo, ajudem as equipes
a fazer a coisa certa.
Uma plataforma da empresa pode incluir segurança,
identidade, consistência, gerenciamento de custos
e automação de implantação como os principais serviços
prestados. Cada uma dessas plataformas de self-service
terá a governança "incorporada" para que as equipes
que usam a plataforma herdem a prática recomendada
de governança com pouco ou nenhum esforço. Como
exemplo, uma maneira de garantir que o custo seja
monitorado com precisão e seja atribuído aos produtos
ou departamentos corretos é utilizar rótulos de recursos.
O uso desses recursos de gerenciamento de custos pode
ser obrigatório na plataforma da empresa.
um desafio de governança. As organizações podem ter
centenas de desenvolvedores trabalhando em equipes com
organização própria; por isso, é importante ter práticas
de implementação consistentes em todo o cenário de TI.
Quase todas as empresas fazem uso de arquiteturas de
referência com orientações de práticas recomendadas sobre
como criar e executar aplicações, além de como incorporar
governança e segurança. Uma das práticas de governança
mais maduras é tornar essa arquitetura de referência
executável por meio de conjuntos de modelos, scripts
e ferramentas e mover as arquiteturas de referência além
dos diagramas Visio e dos documentos Word para o código
quando combinadas com ferramentas do DevOps, como
infraestrutura como código e configuração como código.
Quando combinados com os padrões de InnerSourcing
mencionados anteriormente, as equipes podem contribuir
para a criação e a iteração constante dessas arquiteturas
de referência como código, ajudando a garantir um
sistema de governança dinâmico e eficaz.

DIAGRAMA INTERNO DE ROTULAGEM DE RECURSOS DA SOGETI FIG. 5

gerenciamento secreto

reutilizar | padronização

implantação contínua executar | operar

design de arquitetura implementar

integração contínua
de caso comercial build
tempo de execução | plataforma

capacidade de observação | IA

qualidade contínua | segurança | métricas | relatório

organização | conformidade | governança

Relatório do DevOps corporativo 2020-21
Governança contínua
As abordagens tradicionais de governança dependiam
em grande parte de um processo de inspeção ou portão
de qualidade antes da produção/lançamento, o que
não é viável em grande escala e ritmo. Como resultado,
as empresas de melhor performance estão adotando
modelos de entrega contínua para governança para que
possam agregar valor aos clientes mais cedo por meio do
lançamento frequente de novos recursos de software.
Para combater práticas de governança complicadas, as
empresas também estão migrando para a automação da
governança, reduzindo a carga dos departamentos de TI
que não precisam mais executar lentos fluxos de trabalho
de aprovação e validação. No cerne dessa abordagem
contínua estão os pipelines CICD com as etapas de
governança incorporadas a cada pipeline, que permitem
a liberação frequente de produtos seguros e de alta
qualidade para os clientes. A governança contínua define
os princípios que podem ser implementados por meio
de controles de software automatizados que promovem
o código de uma etapa do pipeline para a próxima.
28
Busque comentários e insights
Tradicionalmente, tem sido difícil obter visibilidade
do estado atual da adesão de uma organização aos
princípios de governança. Também não é possível medir
facilmente os benefícios organizacionais da adoção
dessa governança.
A adoção do DevOps corporativo resolve isso. Um dos
princípios fundamentais do DevOps é criar loops de
comentários eficazes — quanto mais rápido for o  ciclo
de comentários, mais rápido uma organização poderá
aprender o que funciona e se adaptar conforme necessário.
As empresas estão cada vez mais transformando a IA
e as plataformas de aprendizado de máquina para
resolver esse desafio. As equipes de governança usam
essa tecnologia para filtrar e correlacionar dados, a fim
de transformar o grande volume de dados gerados
por cadeias de ferramentas do DevOps e plataformas
de nuvem em inteligência acionável que podem ser
usadas para otimizar processos de governança. Ao filtrar
e correlacionar dados, as equipes podem se concentrar
em adotar as ações corretivas necessárias sem mergulhar
na enorme quantidade de dados coletados.
Relatório do DevOps corporativo 2020-21
CASO DE SUCESSO DA GOVERNANÇA
Para uma grande empresa de seguros europeia, a boa
governança é essencial para evitar o que chama de
"problemas de segurança e caos" em mais de 20 diferentes
fluxos de tecnologia e desenvolvimento, cada um com
suas próprias arquiteturas de domínio e equipes do
DevOps. Com mais de 700 profissionais ativos do DevOps,
a governança eficaz garante que essas equipes trabalhem
de forma consistente, respeitando os ditames regulatórios
e da empresa, tudo isso sem prejudicar a velocidade de
desenvolvimento.
Para incorporar a boa governança, a seguradora
implementou uma equipe central que monitora e apoia
a adesão às cadeias de ferramentas de desenvolvimento.
Essas cadeias de ferramentas, por sua vez, foram
racionalizadas com a ajuda de arquitetos empresariais
e arquitetos de domínio para trazer mais controle
e eficiência. Quaisquer interrupções, problemas de
segurança ou usos ilegais de ferramentas podem ser
corrigidos rapidamente.
RECURSOS AVANÇADOS DE GOVERNANÇA
Faça a coisa certa, a coisa fácil
Saiba mais sobre a Estrutura de adoção de nuvem
Ferramenta de benchmark de governança da Estrutura de
adoção de nuvem
Princípios, não regras
Saiba mais com o padrão de serviço digital por padrão
Adotar um modelo de InnerSource
Leia mais sobre a introdução do GitHub ao InnerSource
Plataformas e arquiteturas de referência executáveis
Microsoft Azure Well-Architected Review
Governança contínua
Como o Azure aborda a automação de governança
Busque comentários e insights
Saiba mais sobre ferramentas de monitoramento de nuvem
29
Como o DevOps envolve pessoas e a habilitação de
tecnologias, a comunicação é vital na abordagem da
governança pela empresa. Um portal de serviço de TI
fornece informações sobre ofertas e serviços para as
equipes, juntamente com um conjunto completo de
documentação relevante. A equipe de comunicações
oferece supervisão dos acontecimentos atuais e planos
futuros, enquanto um fórum de comunicação é usado para
o compartilhamento de conhecimento entre os membros
da equipe, o que reduz muito atritos e interrupções
do trabalho.
Essa equipe de governança é altamente ativa e mantém
a dinâmica por meio de um canal de notificações
e atualizações, bem como de distribuições de email
regulares. Para a seguradora, esse compromisso com
boas práticas por meio da governança garante que as
equipes do DevOps trabalhem juntas para dar suporte aos
objetivos de negócios de forma eficiente e compatível.
"Passamos de "equipe" para "equipe sem
atritos", enquanto a boa governança
também nos ajuda a manter os custos de
desenvolvimento sob controle."
gerente de equipe
equipe de suporte do DevOps na nuvem
Relatório do DevOps corporativo 2020-21 30

Qualidade
A Sogeti define qualidade como a qualidade certa, em cadências regulares e contínuas, ou
seja, implementam a qualidade contínua como parte da
"a totalidade dos recursos e características entrega contínua.
de um produto ou serviço que se
baseiam em sua capacidade de atender As empresas, mais do que nunca, precisam muito
implementar a garantia de qualidade em sistemas,
necessidades declaradas ou implícitas13." engenharia e ambientes para garantir que a qualidade
seja entregue de maneira consistente e contínua. No
Isso requer uma disciplina de engenharia de qualidade,
momento, muitas empresas esperam "qualidade com
que permite às equipes do DevOps agregar valor comercial
velocidade", mas só verificam se há defeitos antes da
com alta qualidade, fornecendo um conjunto de princípios
implantação de código.
e práticas que dão garantia de qualidade de produtos
e serviços. As organizações de melhor performance pedem
às equipes do DevOps que agreguem esse valor, com

TÓPICOS DE CONTROLE DE QUALIDADE E TESTE E ATIVIDADES DO DEVOPS FIG. 6

te | Responsabilidade e funções | Monitoramento e controle | Gerenciamento de anomalias |

e e tes Rela
idad
qual tór
ios
de ea
ica ler
lít ta
Po s
de risc o de qualidade e estratégia de teste | Critérios de aceitação | Medidas de qualidade | Rev
se
áli isã
An o

PL ANE JAR IMPL ANTAR

R
RA
M
O

G
N
IT
O
RA
M
EN
TE

TO
IN

CÓ DIG O OPERAR
do
De

n
lt a
si g

u
de es
tes r or
te | a li a
G e re n v
ciamento de dados de teste | Automação de testes | Execução de testes | Investig a r e a

Estimativa | Planejamento | Infraestrutura | Ferramentas | Métricas | Melhoria contínua

Organização de tópicos Execução de tópicos Atividades do DevOps

12
OECD, Definition of Quality- ISO, 2020
13
Sogeti and Capgemini, Quality for DevOps Teams, 2019
Relatório do DevOps corporativo 2020-21
EM UMA ESCALA DE 1 A 10, COMO VOCÊ CLASSIFICARIA SUA MATURIDADE DE PROJETO NA QUALIDADE DE NUVEM E DO DEVOPS?
14%
10,5%
7%
5,2%
1 2 3 4
ESC AL A DE C L ASSI F I C AÇ ÃO
Por outro lado, as principais organizações do DevOps
estão focadas em "qualidade de ponta a ponta". Apesar
de ainda fazerem isso com procedimentos completos de
habilitação de código, elas também são capazes de validar
a qualidade do que está sendo entregue antes, durante
e após a implantação.
A qualidade deve fazer parte de todos os processos
para que os recursos e as características de um produto
sejam criados logo na primeira vez. A qualidade em
uma escala empresarial vai muito além dos testes
contínuos e da automação de testes, pois a engenharia
de qualidade também deve se concentrar na entrega,
no comportamento, nas práticas e em muitas outras
atividades de garantia de qualidade e teste. A estrutura
de atividades de garantia de qualidade da Sogeti mostra
alguns dos elementos-chave dessa abordagem (Figura 6).
31
FIG. 7
19,3%
14% 14%
11,9%
3,5%
0%
5 6 7 8 9 10
A pesquisa da Sogeti entre profissionais de nuvem
e do DevOps revelou um problema na "maturidade
de qualidade" na indústria (Figura 7). Como muitas
organizações passaram de equipes de TI em silos para
várias equipes do DevOps com escopos definidos, nossas
pesquisas mostram que as discrepâncias entre as práticas
de qualidade de cada equipe variam muito e há uma
necessidade de consistência. Quando os profissionais
de TI foram solicitados a classificar a maturidade no
DevOps e na nuvem, as respostas mostraram uma grande
divergência nos níveis de maturidade, conforme ilustrado
no diagrama acima. Em nossa pesquisa coordenada,
e com base em alguns aprendizados importantes do
livro "Qualidade para equipes do DevOps" da Sogeti,
vemos claramente uma série de desafios que impedem
a maturidade das organizações.
Relatório do DevOps corporativo 2020-21
Quais são os desafios?
Equilíbrio entre velocidade e qualidade
Alcançar o equilíbrio certo entre a qualidade e a velocidade
de entrega sempre foi complicado, como evidenciado
pelos resultados da pesquisa da McKinsey Developer
Velocity Index. Embora metade das organizações
relatem que obter uma avaliação por pares seja uma
etapa importante no processo de qualidade, apenas 7%
dos entrevistados são capazes de obter resultados de
avaliação por pares em menos de um dia. E 38% disseram
que precisam esperar entre três e cinco dias, com atrasos
aparentemente triviais que dificultam muito a velocidade
do desenvolvedor. As empresas desejam ter a qualidade
certa no momento certo e não querem esperar para
entregá-la. Para alcançar esse equilíbrio, muitas empresas
adotaram a automação.
A automação de testes costuma ser usada como
uma solução completa para contabilizar o dilema de
velocidade/qualidade, mas não resolve o fato de que
nem tudo, desde o planejamento até a produção, pode
ser automatizado. Precisamos de soluções mais amplas
e abrangentes.
EM GERAL, QUANTO TEMPO LEVA PARA OS DESENVOLVEDORES RECUPERAREM O RESULTADO DE AVALIAÇÕES DE PARCEIROS?
Menos de 1 dia 1 a 2 dias
7 31
REVI S ÕES DE CÓDI G O
32
Em busca de maturidade consistente e como aplicá-la
Garantir que as equipes multifuncionais implementem
práticas de garantia de qualidade de forma consistente
na empresa inteira é um fator-chave no gerenciamento
de qualidade. As organizações bem-sucedidas otimizam
a eficiência de várias equipes com organização própria,
reutilizando o conhecimento e aderindo a testes de
estruturas e cadeias de ferramentas acordadas. No
entanto, a imposição da consistência é um problema, não
apenas no processo de teste, mas em todos os princípios
de design, padrões e práticas recomendadas para
a criação do DevOps e arquiteturas de nuvem.
Interdependências complexas
Os produtos, aplicações e sistemas normalmente têm
muitas interdependências, tornando a liberação de novos
recursos desafiadora e lenta. Em muitas organizações,
os proprietários de produtos não podem simplesmente
se concentrar no próprio produto porque uma pequena
mudança (por exemplo, uma atualização regulatória)
pode exigir alterações derivadas em todos os outros
produtos, sistemas e aplicações que dependam do
produto. Isso resulta em uma mudança simples que se
torna uma atualização complexa, de várias equipes e de
vários produtos. Toda essa complexidade retarda o ciclo
de lançamento. Essas interdependências não são apenas
entre as equipes do DevOps, mas também com sistemas
e produtos fora do círculo de influência da organização,
como SaaS ou COTS, que aumenta ainda mais o desafio do
DevOps em oferecer a velocidades exigidas pela empresa.
FIG. 8
3 a 5 dias 6 a 7 dias Mais de 1 semana
35 18 6
Relatório do DevOps corporativo 2020-21 33

PROCEDIMENTOS AUTOMATIZADOS DE TESTES DO SISTEMA FIG. 9

EM GERAL, COM QUE FREQUÊNCIA OS PROCEDIMENTOS DE TESTE A SEGUIR SÃO TOTALMENTE AUTOMATIZADOS E ENVOLVEM ATIVIDADES MANUAIS MÍNIMAS

Quase nunca Ocasionalmente Às vezes Muitas vezes Quase sempre

Testes de unidade

1 8 21 47 23
Testes de integração

1 7 20 41 31
Testes de aceitação

3 5 20 41 30
Testes de performance

2 4 15 38 41
0 20 40 60 80 100

Falta de automação de testes O TDD (desenvolvimento orientado a teste) promove

A falta de automação de testes certamente não é um a automação de testes e fornece uma avaliação contínua
novo desafio e permanece uma barreira de longo prazo da qualidade funcional do código. O TDD também pode
para atingir a qualidade no DevOps. Nossa pesquisa levar a grandes benefícios em termos de qualidade, pois
mostra que apenas um terço das organizações relata obriga as equipes a esclarecer os requisitos antes de
que automatizou processos de teste "ocasionalmente" iniciar o desenvolvimento. No entanto, nossa pesquisa
ou "às vezes", o que significa que muitas organizações mostra que 31% das organizações não adotaram
estão deixando lacunas de qualidade significativas e/ou consistentemente uma abordagem de TDD. Além disso,
dependendo de testes manuais lentos e ineficientes. elas escrevem testes de unidade antes do desenvolvimento
menos de 40% do tempo.
Com é praticamente impossível realizar o teste
manualmente, não surpreende que as organizações
tenham duas vezes mais chances de automatizar testes de
performance em comparação com os testes de unidade.
Embora os testes de unidade devam almejar um alto nível
de automação, não representa um problema ter um certo
nível de teste manual.
Relatório do DevOps corporativo 2020-21
Fazer uma mudança cultural e definir o sucesso
Os desenvolvedores, em geral, não gostam de testes,
embora os bons desenvolvedores ofereçam testes
rigorosos. As empresas precisam de políticas em vigor que
permitam que os desenvolvedores ofereçam qualidade,
sem precisar fazer parte de uma fase distinta, separada
e de testes. A qualidade exige uma mudança cultural,
com diretrizes claras de todos são responsáveis pelo
teste e métricas para medir o sucesso. A ideia de que
"o  que é medido é realizado" se aplica a muitas equipes
de desenvolvedores. Sem métricas e insights concretos, as
equipes não focam a qualidade ou tentam implementar
verificações de qualidade nos lugares errados.
34
Nos últimos anos, as entrevistas da Sogeti revelaram que
as equipes de TI sentiram um aumento constante na
velocidade, mas também um aumento no tempo para se
recuperar de erros e implementar novas soluções — as
empresas precisam mudar o foco da velocidade para
estabilidade. A qualidade deve fazer parte de todos
os processos e das atitudes dos desenvolvedores.
Não basta saber a quantidade de bugs abertos para
informar às equipes sobre a qualidade de um produto
desenvolvido pela equipe do DevOps. Em muitos casos,
o relato sobre níveis de qualidade é o próprio desafio.
Em vez de simplesmente relatar o número de bugs
abertos, precisamos ver como os testes e os sistemas se
comportam com o tempo. A qualidade deve explicar
como a equipe do DevOps se sente em todas as fases do
desenvolvimento e do pipeline de lançamento, da criação
ao estágio de execução. Se sua organização não tiver boas
métricas sobre a qualidade do sistema, as equipes serão
sempre ineficientes e os produtos instáveis.
Relatório do DevOps corporativo 2020-21
Lidar com os desafios
Faça a mudança cultural com metas claras de
qualidade e transparência
Se o seu pessoal souber o que é necessário, será mais
fácil fazer a mudança cultural para um foco de qualidade
de ponta a ponta no DevOps corporativo. De acordo
com a pesquisa da Sogeti, as empresas que são claras
e bem-sucedidas ao descrever as características de
qualidade exigidas dos sistemas são muito mais eficientes
na automação de testes e têm uma qualidade de sistema
geral mais alta e previsível.
Sabemos que as organizações atribuem aos padrões
e regulamentações da indústria, como a ISO 25010, a
qualidade do produto e a qualidade em uso, mas em
nível cultural devem ir além desses padrões externos.
Muitas empresas de alta performance deixam claro para
as equipes de produtos que a qualidade é uma prática
comum e, ao tornar as equipes inteiras responsáveis, o
tempo gasto para garantir a qualidade é visto como uma
necessidade, e não como um inconveniente.
A qualidade precisa ser algo que as empresas e os
funcionários buscam. Ela deve ser incutida nos processos
e expectativas de comportamento profissional, e não vista
como um obstáculo de terceiros a ser ultrapassado.
Entenda a cadeia de suprimento de software
Atualmente, 90% dos sistemas de TI utilizam código
Open Source. Por isso, é essencial que as empresas
validem a qualidade do software oferecido por cadeias
de suprimento de software de terceiros. Sem insight sobre
a qualidade das cadeias de suprimentos, é impossível
relatar de forma completa sobre a qualidade geral de
um produto entregue. O gerenciamento da qualidade
do código emprestado dentro da cadeia de suprimento
de software pode ser atenuado usando uma lista de
materiais de software, um documento que fornece uma
lista completa de todos os componentes de determinado
software.
35
Juntamente com esses desafios de terceiros, as
interdependências também se estendem às equipes do
DevOps internas das empresas. Historicamente, as equipes
tendem a olhar exclusivamente para o próprio produto,
cuidando da qualidade e não pensando no processo
de integração e nos sistemas dependentes em cascata.
Uma maneira de abordar isso é implementar práticas
específicas, estruturas e equipes de teste de regressão de
ponta a ponta independentes junto com estratégias de
implantação para garantir que o sistema abrangente
dê suporte a cada um dos pequenos serviços implantados.
Determinar quem assume a responsabilidade pela
qualidade de um sistema inteiro, em vez de um
único produto, continua sendo um desafio central.
As organizações de melhor performance geralmente
implementam uma equipe separada cuja única
responsabilidade é executar testes de regressão de
ponta a ponta. Essas equipes horizontais trazem
provisionamento automatizado de ambientes e execuções
de teste, assumindo a responsabilidade pela integração de
produtos como aplicações COTS ou serviços SaaS que não
precisam do uso de uma equipe completa do DevOps.
As organizações mais avançadas em práticas do DevOps
devem considerar abordar a integração de vários produtos
interdependentes adotando arquiteturas e uma estratégia
de versão correspondente especificamente projetada para
dar suporte à implantação e integração de novos recursos.
Elas podem incluir lançamentos canários e implantações
de anéis em subseções menores de clientes (versões beta)
com execução de teste altamente automatizada para
agregar comentários sem liberar atualizações instáveis.
Relatório do DevOps corporativo 2020-21
Garanta a consistência com uma política de
qualidade clara
A qualidade precisa de consistência. A ponte entre os
negócios em geral e as equipes do DevOps é muito
aperfeiçoada quando princípios e políticas de qualidade
de entrega são especificados em nível organizacional. As
empresas devem ser impulsionadas por uma missão, uma
visão e uma estratégia, e as equipes do DevOps devem
implementá-las em processos incorporados e apoiados
por produtos de software. A política de qualidade e teste
de uma empresa traduz a missão, a visão e a estratégia
de negócios nos princípios, abordagens e objetivos que
descrevem como a organização lida com as pessoas,
os recursos e os métodos envolvidos no processo de
qualidade e teste.
Ao estabelecer esses princípios gerais e políticas de
qualidade, as organizações podem preparar o caminho
para tornar mais fácil para as equipes do DevOps fazer a
coisa certa. Isso também tornará os membros da equipe
mais satisfeitas e com melhor performance, e garantirá
que a organização perceba o valor dos negócios com
o alinhamento entre as equipes.
Esses princípios e políticas de qualidade também devem
abranger as cadeias de ferramentas e o uso de estruturas
de teste. Sabemos que algumas organizações dão às
equipes de DevOps a liberdade de escolher as ferramentas
e estruturas de sua preferência, mas isso só é viável quando
seguem os princípios aceitos claramente definidos.
Liberdade demais em geral leva a equipes ineficientes,
o que, por sua vez, leva à qualidade imprevisível. Todas
as empresas precisam de modelos padronizados para
recursos de nuvem e automação projetados para fornecer
sistemas consistentes prontos para empresas.
14
Capgemini, World Quality Report 2019, 2019
36
Equilibre a velocidade e a qualidade obtendo
inteligência com a automação de testes
Embora a velocidade e o valor de qualidade da automação
de testes sejam inegáveis no ciclo do DevOps, muitas
organizações lutam para adotar um sistema que seja
escalado adequadamente. O mais recente relatório
de testes contínuos da Sogeti e da Capgemini revelou
que apenas 24% dos casos de teste funcionais e de
performance são automatizados, enquanto apenas 22%
dos casos de teste são automatizados em sprints. Para
combater isso, as equipes devem estar prontas para
migrar simplesmente da automação de um script de
teste funcional de seleção, priorizando a qualidade e a
automação ciclo de vida de desenvolvimento. O principal
obstáculo aqui é como remover o teste como um gargalo
e torná-lo uma prática simples.
Uma recomendação no mais recente relatório de
qualidade mundial da Sogeti e da Capgemini14 se destina
a estruturas automatizadas inteligentes projetadas para
dar suporte ao ciclo de desenvolvimento. O relatório
acrescenta que a automação inteligente está definida para
fazer uma diferença significativa nos testes ao encontrar
e corrigir problemas rapidamente, ao mesmo tempo
em que ajuda as equipes de teste/desenvolvimento
combinados a decidir quais alterações darão os melhores
e mais rápidos retornos. Isso será primordial na entrega de
resultados de qualidade.
Relatório do DevOps corporativo 2020-21 37

CASO DE SUCESSO DE QUALIDADE

A qualidade era uma prioridade básica para uma grande
organização do setor de transporte que migrava de um
sistema herdado monolítico para sistemas distribuídos
modernos. À medida que a tecnologia existente se tornava
ultrapassada e ficava difícil dar suporte a ela, o objetivo
da empresa era modernizar, garantindo que os novos
sistemas agregassem o mesmo (ou mais) valor comercial
que o sistema herdado.
O novo modelo distribuído significava que várias equipes
de DevOps estavam trabalhando em uma variedade
de sistemas diferentes. Como tal, a gerência sênior da
empresa procurou manter uma visão geral abrangente do
progresso da migração para garantir que os negócios em
andamento não fossem afetados pelas mudanças.
A Sogeti, parceira de serviços de tecnologia de longo
prazo, criou um "monitor de confiança" para os negócios.
Usando ferramentas como um painel automatizado
em tempo real, todas as equipes (que somavam mais
de 10, principalmente o DevOps e o Scrum) publicaram
regularmente informações sobre a qualidade e os riscos
dos novos sistemas.
Com base nessas informações, a Sogeti analisou uma série
de indicadores medidos, incluindo dados de hardware
(como informações sobre instalações bem-sucedidas,
funcionalidade, performance e continuidade de negócios)
e dados de software (como um questionário periódico
para a equipe de operações e os usuários finais). Os
dados foram compilados em uma única "classificação
de confiança". Isso mostrou a confiança das equipes de
entrega de migração na robustez e na qualidade dos
diferentes sistemas. Ela também trabalhou para identificar
áreas em que mais trabalho era necessário e mostrou quais
sistemas estavam funcionando conforme o planejado.
Todos os meses, ao longo de vários anos, essa classificação
de confiança foi relatada à gerência sênior da empresa e
se tornou uma bússola confiável para orientar a transição
geral da organização para um cenário de TI moderno.

RECURSOS AVANÇADOS DE QUALIDADE

Faça a mudança cultural com metas claras de qualidade

e transparência
Leia mais sobre o relatório de testes contínuos

Entenda como a cadeia de suprimentos e equipes do DevOps

estão interconectadas
Saiba como o GitHub protege o software Open Source

Garanta a consistência com uma política de qualidade clara

Como a Sogeti define políticas claras de qualidade

Equilibre a velocidade e a qualidade obtendo inteligência

com a automação de testes
Leia mais no relatório de qualidade mundial da Capgemini
Relatório do DevOps corporativo 2020-21
Segurança
O DevOps corporativo e, com ele,
a adoção da nuvem em larga escala
representam uma mudança sísmica para
as equipes de segurança da informação.
Especialistas em segurança da informação têm acesso a
recursos que antes em meros sonhos. Por exemplo, agora
temos a capacidade de rastrear qualquer parte de código,
desde a implantação da produção até o ciclo de vida de
desenvolvimento de software, entender as validações
que ocorreram em cada etapa, desde o início do check-
in de código inicial. No entanto, também vivemos em um
mundo em que muitas equipes fazem várias implantações
de código por dia, cada uma com o potencial de apresentar
uma vulnerabilidade explorável se os princípios de
segurança não forem incorporados no ciclo de vida inteiro
e na organização do DevOps.
É claro que a segurança da informação é uma disciplina
mais ampla do que apenas o exemplo focado no código
da aplicação citado antes. Como indicado no padrão
ISO 27002 (código de prática para controles de segurança
da informação); "... o gerenciamento de segurança da
informação exige, no mínimo, a participação de todos os
funcionários na organização". A segurança também tem
um impacto real sobre os negócios, pois a pesquisa da DVI
mostrou claramente que a segurança e a conformidade
foram o segundo maior fator ponderado (23%) sobre
a diferença entre o quartil superior e a performance
empresarial do segundo quartil. A segurança não é apenas
um custo, mas também um fator de performance.
38
O DevOps ajuda as organizações a lançarem software
mais rápido, mas também pode ajudar a abordar as
necessidades de segurança quando desenvolvem soluções
de software e, em seguida, executá-las em produção.
Quando a segurança é incorporada na organização inteira,
ela ajuda a impulsionar a entrega de software mais rápido
e seguro e auxilia na obtenção de governança e controle
consistentes. Da mesma forma que a governança, quando
as equipes se sentirem responsáveis pelos produtos,
e a segurança for um objetivo em comum, os produtos
estarão muito mais propensos a serem seguros e os
colaboradores do DevOps os incorporarão em sistemas
e códigos. A segurança deve ser incorporada no ciclo de
vida completo de sistemas e equipes, e as empresas de
melhor performance estão adotando a automação com
mais frequência para atingir essa consistência de forma
econômica.
Infelizmente, não há uma abordagem de segurança "igual
para todos". Em vez disso, cada aplicação tem requisitos
e restrições exclusivas; portanto, as práticas precisam
ser adaptadas aos processos, requisitos de segurança e
procedimentos operacionais. O que as empresas precisam
é de um conjunto de princípios e regulamentos que
orientem a implementação de segurança em todo o ciclo
de vida de desenvolvimento de software (SDLC).
Relatório do DevOps corporativo 2020-21
Quais são os desafios?
RE C E I TA CAGR, 2014-2018
2%
1% 1%
4º quartil 3º quartil 2º quartil
Falta de uma abordagem abrangente de segurança
17% das organizações pesquisadas para o relatório DVI
disseram que só testam as vulnerabilidades de segurança
"para uma versão principal" ou "somente ao liberar para
a produção", e apenas 46% das empresas incorporam
ferramentas de segurança em pipelines do DevOps. Apesar
de 68% dos entrevistados afirmarem que "a segurança era
responsabilidade de todos", apenas cerca de 40% estavam
incorporando requisitos de segurança na fase de design,
colaborando em modelos de ameaças e priorizando
os requisitos de segurança como parte de backlogs de
desenvolvimento.
QUAIS DAS SEGUINTES PRÁTICAS DE SEGURANÇA SE APLICAM NO MOMENTO À SUA ORGANIZAÇÃO?
68%
A segurança é responsabilidade de todos (por exemplo,
há uma equipe de segurança centralizada; um especialista
em segurança qualificado em quase todas as equipes;
cada desenvolvedor é responsável por proteger seu
próprio código
47%
Temos uma equipe centralizada para gerenciar a
segurança do código Open Source e do pacote usado
pela nossa organização
46%
Security tools are integrated in the development
integration pipeline
39
FIG. 11 Tomadas coletivamente, é claro que as organizações não
estão adotando a abordagem holística de pensamento de
5%
sistemas para a segurança necessária para implementar um
modelo do DevOps de alta velocidade com segurança. Isso
é reforçado pelos resultados da pesquisa sobre o tempo de
resposta para resolver as principais violações de segurança.
6% dos entrevistados disseram que isso levaria "semanas"
e  17% disseram que levaria "entre 3 dias a uma semana"
para resolver. Apenas 7% disseram que tinham a capacidade
de solucionar uma grande violação em menos de 1 hora.
Proteção de open source
Outro insight fascinante que surgiu da pesquisa do DVI foi
Quartil superior a lacuna entre a adoção do Open Source e a capacidade
das empresas de usar o código Open Source com
segurança. Apesar de 65% das organizações afirmarem
que "frequentemente ou quase sempre aproveitam o Open
Source para o desenvolvimento de produtos", menos de
20% verificam automaticamente esses componentes em
busca vulnerabilidades e remediam essas vulnerabilidades
antes da implantação.
A implantação de código com vulnerabilidades conhecidas
deixa as organizações vulneráveis a ataques. Pesquisas
recentes no relatório do Estado de vulnerabilidades de
segurança de Open Source mostraram que o número de
vulnerabilidades de OSS saltou de 4.100, em 2018, para
6.100, em 2019, um aumento anual de 50%.
FIG. 10
44% 41%
O pessoal de segurança revisa e aprova a alteração de Os requisitos de segurança são tratados como restrições
código antes da implantação de design e os proprietários de produtos interagem com
especialistas em segurança desde a fase de design e
definição de requisitos
34%
Temos uma equipe centralizada de pesquisadores 40%
de segurança Os requisitos de segurança são priorizados como parte
da lista de pendências do produto
42%
Equipes de segurança e desenvolvimento colaboram em
modelos de ameaças 30%
Os desenvolvedores podem fornecer uma segurança de
código e pacote Open Source usada pela nossa
organizaçãoand package used by our organization
Relatório do DevOps corporativo 2020-21 40

Embora a adoção de Open Source ofereça enormes Falta de supervisão e investimento em nível
benefícios para as organizações empresariais, ela também de diretoria
gera grandes desafios de segurança. As organizações Embora um aumento nos regulamentos de dados
precisam entender onde o Open Source está sendo usado federais e multinacionais tenha levado a mais iniciativas
em aplicações e aderir de maneira consistente e estrita às de segurança de dados corporativos, os principais
práticas recomendadas de segurança de Open Source em obstáculos incluíram a falta de foco organizacional na
todo o ciclo de vida do desenvolvimento de software. segurança e o financiamento inadequado para iniciativas
de segurança. Quase metade das organizações têm
O desafio de segurança da nuvem segurança cibernética na agenda de Conselho pelo menos
Apesar dos melhores esforços dos fornecedores de nuvem, trimestralmente, de acordo com a pesquisa do futuro
muitas empresas parecem se esforçar para proteger os da cibernética na Deloitte15. No entanto, apenas 4% dos
ambientes de nuvem. Houve inúmeros casos de violações entrevistados dizem que a segurança cibernética está
de segurança em ambientes de nuvem de alto perfil e na agenda mensal do Conselho, apesar das crescentes
bem divulgados, por meio de erros humanos, resultando pressões regulatórias que tornam os diretores da empresa
em sistemas mal configurados, falta de habilidades pessoalmente responsáveis pela segurança dos dados.
essenciais, negligência ou pessoas dentro da empresa
mal-intencionadas. Muitas empresas têm dificuldade para
fazer a transição do modelo de data center tradicional
"segurança de perímetro (rede)" para a abordagem
em várias camadas de "defesa em profundidade"
recomendada em ambientes de nuvem. Os profissionais
de segurança precisam aprender novas habilidades e
novas abordagens para fornecer segurança na nuvem
eficaz. Para muitas organizações, essa transformação está
atrasada em termos de adoção na nuvem, criando uma
lacuna de segurança que as deixa vulneráveis.

15
Deloitte, The Future of Cyber Security 2019, 2019
Relatório do DevOps corporativo 2020-21 41

Lidar com os desafios

A adoção do DevOps, com foco na automação e na Ciclo de vida de desenvolvimento seguro

responsabilidade compartilhada, pode resultar em
sistemas seguros que estejam em conformidade com as
diretrizes de segurança e capazes de suportar as ameaças
de segurança existentes, se implementadas corretamente.
Enfrentar os desafios da segurança como parte de
uma transformação do DevOps corporativo exige uma
combinação de princípios-chave, arquiteturas padronizadas
("plataformas"), design organizacional e automação.
Adote o modelo de confiança zero
A mudança de mentalidade fundamental, especialmente
para organizações empresariais que passaram da
hospedagem na infraestrutura local para um modelo
de primeira nuvem como parte da adoção do DevOps,
traduz o modelo de confiança zero. A Microsoft define a
confiança zero como: "em vez de supor que tudo por trás
do firewall corporativo é seguro, o modelo de confiança
zero pressupõe a violação e verifica cada solicitação como
se fosse originária de uma rede aberta... A confiança zero
nos ensina a "nunca confiar, sempre verificar".
Os princípios orientadores da Confiança Zero são:
• Verifique explicitamente. Sempre autentique
e autorize com base em todos os pontos de dados
disponíveis, incluindo identidade do usuário, local,
integridade do dispositivo, serviço ou workload,
classificação de dados e anomalias.
• Use o "acesso menos privilegiado." Limite o acesso
do usuário com acesso Just-In-Time e Just-Enough
Access (JIT/JEA), políticas adaptativas baseadas em
risco e proteção de dados para proteger os dados
e a produtividade.
• Presuma violações. Minimize o raio de destruição
de violações e impeça o movimento lateral,
segmentando o acesso por rede, usuário, dispositivos
e consciência de aplicação. Verifique se todas
as sessões são criptografadas de ponta a ponta.
Use a análise para obter visibilidade, impulsionar
a detecção de ameaças e melhorar as defesas.
e deslocamento à esquerda
Desde o memorando do agora famoso Bill Gates
intitulado Trustworthy Computing , em 2002, o papel
dos desenvolvedores de software em segurança e a
importância de incorporar a segurança no ciclo de vida
do desenvolvimento de software16, passaram a fazer parte
das práticas recomendadas da indústria.
As empresas devem criar práticas recomendadas de
segurança para a forma como projetam, escrevem, criam
e testam aplicações para reduzir sensivelmente o número
de vulnerabilidades exploráveis com efeito na produção.
O primeiro passo é definir padrões de segurança
claros e transformá-los em práticas operacionais
e de desenvolvimento no dia-a-dia, incorporando-os
às plataformas usadas pelas equipes. Isso removerá
a dependência excessiva das equipes de segurança
centralizadas que muitas vezes são sobrecarregadas
com demandas causadas pela rápida taxa de mudança
do DevOps.
A pesquisa da Sogeti mostra que as empresas de melhor
performance apresentam verificações de segurança em
todas as fases do ciclo de vida do software — planejar,
desenvolver, criar, testar, liberar, fornecer, implantar,
operar e monitorar. A segurança da aplicação deve ser
agilizada para acompanhar as operações, colocando
as verificações de segurança e o controle dentro do
próprio pipeline de CI/CD. Os testes e a segurança devem
ser "transferidos para a esquerda" por meio dos testes
de unidade, funcionalidade, integração e segurança
automatizados. Esse é um diferenciador fundamental,
pois os recursos de segurança e funcionais são testados
e criados simultaneamente.

Para ler mais sobre como sua empresa pode adotar um

modelo de confiança zero, clique aqui.
Relatório do DevOps corporativo 2020-21 42

Proteger componentes de código reutilizáveis As organizações bem-sucedidas estão adotando

Criar componentes de código reutilizáveis seguros arquiteturas de referência do DevOps, um modelo que
e torná-los amplamente usados por meio da estratégia de documenta o conjunto completo de atividades, etapas,
InnerSource também é essencial para resolver a segurança práticas e tecnologias de um sistema que são usados
do DevOps corporativo. ao criar uma aplicação ou tecnologia. Com disposição
clara de todas as etapas ideais, desde a criação até
As melhores performances utilizam de forma consistente
o  monitoramento, as empresas podem ficar confiantes
componentes reutilizáveis e aproveitam o que é conhecido
de que as coisas estão sendo feitas da maneira "certa",
como "princípio DRY"17 (Don’t Repeat Yourself). O DRY
enquanto abordam todos os objetivos de segurança da
tem o benefício adicional de que você só precisa corrigir
organização ao mesmo tempo.
uma vulnerabilidade de segurança identificada no
módulo de código reutilizável uma vez para corrigir essa Ao usar essas arquiteturas de referência organizacional,
vulnerabilidade para todos, comparado a centenas de vezes as equipes geralmente criam blueprints do DevOps, que
em potencial se o código tiver sido reutilizado por meio de extraem as necessidades exatas de uma equipe ao longo
"copiar e colar". de cada etapa da arquitetura de referência do sistema. Ao
descobrir exatamente onde as equipes de ciclo de vida de
Obviamente, o software Open Source é uma das
desenvolvimento de software precisarão usar diferentes
principais fontes de componentes reutilizáveis para
tecnologias, as expectativas são claras. Isso garante que
muitas organizações empresariais e a melhoria da
as equipes do DevOps saibam exatamente o que devem
segurança desses componentes é uma importante meta
fazer para alcançar metas de negócios e de segurança.
da indústria. As melhores performances estão instalando
tecnologias automatizadas de remediação de segurança, Capacidade de observação, SIEM e SOAR
como Dependabot do GitHub18, que garante segurança Em um mundo tradicional de segurança cibernética, as
e visibilidade em toda a cadeia de suprimento de ferramentas de segurança, informações e gerenciamento
software Open Source. O Dependabot obtém o código de eventos (SIEM) fornecem soluções analíticas de
de Open Source de terceiros e verifica se há requisitos segurança unificada para ajudar a empresa a identificar
desatualizados ou inseguros. Ele sinaliza automaticamente ameaças e atividades maliciosas em toda a organização.
quais seções estão desatualizadas e permite fazer as Cada vez mais, as empresas de alta performance
atualizações necessárias para garantir que todo o código começaram a aproveitar a inteligência artificial (IA)
implantado seja seguro e compatível. para dar sentido aos terabytes de dados coletados por
ferramentas de monitoramento de segurança. A IA pode
Crie segurança em arquiteturas e plataformas de ajudar a fornecer insights mais profundos sobre o que está
referência acontecendo no ciclo de vida do desenvolvimento seguro
As plataformas e arquiteturas de referência executáveis e determinar a melhor resposta a ameaças à segurança.
são um ótimo ponto de partida ao lidar com a segurança
do DevOps corporativo. As equipes de segurança
central ajudam a definir um conjunto de arquiteturas de
referência seguras, preferencialmente definidas como
código e, em seguida, compartilhadas por meio do
modelo InnerSource discutido anteriormente. Exemplos
sólidos dessa prática se encontram no Azure Architecture
Center. Essas arquiteturas de referência seguras, de
preferência em conjunto com pipelines de lançamento
seguros, fornecem um caminho de menor resistência.
Assim, fazer as coisas da maneira certa com segurança
também se torna a maneira mais fácil.
16
Microsoft, SDL Practices, 2020
17
Microsoft, Patterns and practices for Super DRY development for ASP.NET Core, 2019
18
Dependabot
Relatório do DevOps corporativo 2020-21 43

Mas, a fim de agregar esses dados de segurança e Torne a segurança uma responsabilidade em nível
performance, as aplicações e sistemas precisam ser de diretoria
"observáveis". Isso significa que os sistemas devem ser A segurança é muitas vezes vista como um problema de
criados para expor dados operacionais importantes por TI, mas a criação de uma cultura de consciência de risco
meio de log ou outras interfaces para que as empresas deve começar em nível de diretoria. Não investir em
possam ter uma "visão" interna para entender como segurança e não garantir que as proteções de segurança
um sistema opera. Os requisitos para capacidade de essenciais estejam em vigor deixam as empresas abertas
observação precisam fazer parte do design da aplicação à responsabilidade. Em nossas entrevistas, é claro que as
e parâmetros claros devem ser definidos em relação aos empresas devem apresentar a segurança como um item
dados necessários para entender a integridade de uma de checklist mensal em reuniões do Conselho e definir
aplicação. Isso é de vital importância porque uma boa uma rubrica de conformidade que as ajude a aderir ao
capacidade de observação nos permite criar a linha de conjunto de políticas acordadas.
base do comportamento de uma aplicação em condições
normais. A detecção de anomalias pode ser usada para O National Cyber Security Center19 oferece uma extensa
detectar um comportamento anormal que talvez seja lista de perguntas que as diretorias executivas e os
o resultado de atividades maliciosas. CEOs devem constantemente fazer a si mesmos. O mais
importante é que sua empresa tenha uma compreensão
Ter insights quase em tempo real sobre a integridade de total e precisa de:
aplicações e infraestruturas e as ameaças de segurança
enfrentadas permite que as técnicas de automação do • O impacto na reputação da empresa, no preço da
DevOps sejam aproveitadas para automatizar algumas ação ou na existência se as informações confidenciais
das respostas a esses ataques. Algumas organizações internas ou de clientes mantidas pela empresa fossem
estão usando a sigla SOAR (orquestração de segurança, perdidas ou roubadas?
automação e resposta) para descrever esse processo. • O impacto nos negócios se os serviços online fossem
Aplicações como o Azure Sentinel poderão acionar interrompidos por um período curto ou prolongado?
uma resposta automatizada quando um limite de alerta
for atendido. Esses guias estratégicos automatizados Os conselhos de administração e a liderança em nível
podem lidar com ataques ou problemas comuns sem executivo devem sempre pensar no cenário maior e,
intervenção humana. embora em grande parte "invisíveis" pelos clientes, as
preocupações de segurança devem sempre ser uma
prioridade máxima para evitar falhas de segurança caras.

19
National Cyber Security Centre, Introduction to Cyber Security- Board Level Responsibility, 2019
Relatório do DevOps corporativo 2020-21 44

CASO DE SUCESSO DE SEGURANÇA

A segurança está na agenda da provedora de eletricidade
e gás holandesa Enexis. Como participante importante
na infraestrutura de energia dos Países Baixos, seu perfil
público afirma: "nossos 4.500 funcionários dedicados
trabalham muito todos os dias para garantir redes estáveis
e confiáveis e proteger o futuro do nosso fornecimento
de energia."
Uma capacidade de TI escalável e ágil em um ambiente
público e nativo da nuvem é fundamental para isso,
e a empresa trabalhou com a Sogeti para incluir
as transformações necessárias para o sucesso. Em
cooperação com parceiros, a Sogeti criou um roteiro e fez
a transição de mais de 100 aplicações existentes para uma
plataforma de aplicações nativa da nuvem, seja em IaaS,
PaaS ou SaaS.
A segurança estava no cerne desse processo, atribuindo
parte do sucesso à classificação de risco de dados e
sistemas que migraram para a nuvem. Dentro de uma
arquitetura de referência, a Sogeti definiu os níveis de
risco para a criação de recursos na nuvem, com princípios
para segurança e nuvem.
Com medidas apropriadas para níveis aceitáveis de risco,
as equipes do DevOps da plataforma Enexis entregaram
serviços padrão (por exemplo, rede, servidores etc.)
com segurança incorporada e correção automática.
Para a plataforma do DevOps e as equipes do DevOps
de aplicações que usam esses serviços padrão, a política
de segurança com base nessa classificação de risco foi
convertida em requisitos concretos para a plataforma
de nuvem. Dessa forma, as equipes puderam facilmente
realizar uma "revisão de avaliação de preparação para
a nuvem" antes de implantar para a produção.
Esse modelo do DevOps corporativo seguro foi ainda
mais habilitado pela simplificação da implementação
e integração de aplicações na operação de TI usando
a integração contínua e a implantação contínua
(CI/CD). Os  resultados foram impressionantes. A entrega
de aplicações diminuiu de 6-12 semanas para menos de
2 dias, com a abordagem de deslocamento à esquerda
permitindo a identificação e a correção de problemas de
segurança no início do ciclo para reduzir os custos gerais
do ciclo de vida.

RECURSOS DE SEGURANÇA DA
PRÓXIMA ETAPA

Adote o modelo de confiança zero Crie segurança em arquiteturas e plataformas

Saiba mais sobre o modelo de confiança zero
Veja como a Microsoft avalia as políticas de
Confiança Zero
Ciclo de vida de desenvolvimento seguro e
deslocamento à esquerda
Saiba como incluir a segurança no ciclo de vida de
desenvolvimento
de referência
Saiba mais sobre o Azure Architecture Center
Capacidade de observação, SIEM, SOAR
Consulte o Azure Sentinel da Microsoft
Leia a introdução à capacidade de observação
Automatize respostas de segurança com guias
estratégicos

Proteger componentes de código reutilizáveis

Leia mais sobre o princípio DRY
Veja como o GitHub implementa a segurança
Relatório do DevOps corporativo 2020-21
Conformidade
A conformidade representa muitos dos
mesmos desafios que a governança,
a segurança e a qualidade do DevOps
corporativo.
Embora essas áreas sejam determinadas principalmente
dentro de uma organização, a conformidade é promovida
em grande parte pela regulamentação externa, e as
empresas incapazes de provar que estão cumprindo
as regras podem enfrentar consequências jurídicas ou
financeiras significativas.
45
As empresas sempre se esforçam para estar em
conformidade com os regulamentos, mas à medida
que mais aplicações surgem no cenário da tecnologia
e oferecem serviços semelhantes às empresas existentes,
os credenciamentos de conformidade adquirem suma
importância para os clientes finais na escolha de quais
serviços serão usados. Os clientes, bem como as próprias
empresas, desejam ter a certeza de que informações
e dados estão seguros, protegidos e não comprometidos.
Navegar pela complexa rede de regulamentações locais,
globais e específicas da indústria em um ambiente do
DevOps em constante movimento é um desafio para
muitas organizações. Esses desafios se enquadram em
duas categorias: primeiro, criar, automatizar e executar
sistemas em conformidade; segundo, comprovar a
conformidade do sistema para os reguladores.
Relatório do DevOps corporativo 2020-21 46

Quais são os desafios?

Conformidade com o quê?

conformidade regulatória?
Quase metade dos executivos pesquisados pela E M G E R A L , Q UA N TO T E M P O L E VA PA R A A V E R I F I C A Ç Ã O
DA CO N F O R M I DA D E R E G U L ATÓ R I A ? FIG. 12
Microsoft disseram que não tinham certeza de quais
padrões de conformidade de dados precisavam seguir.
Meses
Esse número provavelmente aumentará à medida que
as organizações corporativas adotarem novos modelos 2
de negócios como parte de transformações digitais. Por
Semanas
exemplo, à medida que mais empresas começam a fazer
pagamentos online, elas se enquadram no escopo do 19
padrão de segurança de dados da indústria de cartões
Dias
de pagamento (PCI DSS) pela primeira vez. Outras
indústrias que enfrentam regulamentações significativas
38
de segurança de dados incluem o varejo (por meio do Horas
GDPR na UE) e os serviços de saúde (HIPPA), entre outros.
32

O desafio do GDPR e da segurança de dados Minutos/instante

O GDPR (Regulamento Geral sobre a Proteção de Dados) 8

da UE, que entrou em vigor em maio de 2018, trouxe
grandes desafios de conformidade para as empresas no
mundo inteiro. O GDPR engloba qualquer organização que
processa dados de cidadãos da UE, independentemente
de onde essa empresa seja incorporada, ou onde os dados
sejam processados ou armazenados. O GDPR forçou
muitos executivos seniores a concentrar a atenção na
governança devido ao potencial de enormes multas na
nova legislação.
No entanto, à medida que as organizações adotam o
DevOps, é muito comum ver dados replicados longe
dos "sistemas de registro" centralizados tradicionais em
repositórios de dados distribuídos. Esses repositórios
de dados também podem ser movidos da infraestrutura
local para ambientes hospedados na nuvem ou usar
novas tecnologias de banco de dados que os processos
de governança existentes não estão equipados para
governar com eficiência. Esse aumento da complexidade
arquitetônica pode trazer desafios para as organizações
que tentam cumprir os regulamentos de segurança
de dados.
0 5 10 15 20 25 30 35 40
A velocidade da conformidade
A pesquisa da Microsoft, como parte da pesquisa DVI,
mostrou que 59% dos entrevistados disseram que pode
levar "dias ou semanas" para avaliar o estado atual de
conformidade regulatória. No DevOps, onde vários
lançamentos de novos recursos de software podem
acontecer todos os dias em ambientes de nuvem em
constante evolução, o ciclo de comentários para entender
o estado atual de conformidade precisa ser muito mais
rápido. Basta verificar se uma aplicação ou ambiente
é seguro quando ele é implantado pela primeira vez
como parte da versão inicial que não é mais suficiente.
O  problema do "desvio de configuração", em que a
aplicação e a infraestrutura subjacente "derivam" do estado
de conformidade originalmente definido como o resultado
de pequenas alterações incrementais ao passar do tempo,
representa um grande desafio e ameaça para as empresas.
Relatório do DevOps corporativo 2020-21
Lidar com os desafios
Como citado anteriormente, a fim de abordar os
desafios de conformidade na transformação do DevOps
corporativo, as empresas precisam alcançar dois objetivos.
Primeiro, a organização deve estar em conformidade e,
segundo, ela precisa ser capaz de demonstrar
conformidade com um órgão regulador. O DevOps, se
implementado e escalado corretamente nas organizações,
pode ajudar a resolver esses requisitos, com um custo
total de propriedade muito menor do que os modelos
operacionais anteriores.
A plataforma em conformidade
Assim como a segurança, a conformidade pode ser
"incorporada" a arquiteturas de referência e plataformas
compartilhadas para que o maior ônus da conformidade
possa ser abstraído das equipes do DevOps alinhadas com
produtos. Por exemplo, a Microsoft publica arquiteturas de
referência para padrões de conformidade comuns, como
faria com a segurança. Essas arquiteturas vão além de
diagramas simples do Visio e documentos do Word para
incluir as etapas de automação do DevOps necessárias
para criar um ambiente totalmente compatível na nuvem
do Azure.
As organizações estão projetando e criando plataformas
compatíveis com base nessas arquiteturas de referência,
que muitas vezes são mantidas com práticas de
InnerSource. Essas plataformas de conformidade
compartilhada podem ser gerenciadas centralmente
como uma zona de destino para aplicações criadas por
equipes do DevOps ou instanciadas em qualquer lugar
por equipes do DevOps, com a certeza de que atendem
aos padrões de conformidade.
47
Conformidade como código contínua
O DevOps corporativo pode ajudar a abordar o desafio do
"desvio de configuração" com o conceito de conformidade
contínua. Os métodos de automação do DevOps, como
infraestrutura como código e configuração como código,
criam um modelo de código de como esperamos que o
ambiente de computação subjacente pareça. Da mesma
forma, os pipelines CI/CD, com a automação de testes
incorporados, definem como as aplicações são criadas,
implantadas e como devem se comportar. Quando
combinados, eles fornecem a capacidade de aplicar
continuamente os padrões de conformidade comparando
o modelo (expresso como código) com a realidade em
produção e corrigindo automaticamente qualquer desvio.
A chave para isso é um conceito chamado "Idempotência".
A idempotência, na linguagem do DevOps, refere-se
à  capacidade de reimplantar a mesma configuração ou
modelo de estado desejado para o ambiente existente,
independentemente do estado atual desse ambiente. Os
modelos de configuração idempotentes permitem que
as empresas usem "sintaxe declarativa" para descrever
a aparência desejada para o ambiente. Em outras palavras,
eles "declaram" que desejam que seja de determinada
maneira e a idempotência significa que, seja a primeira
vez ou a centésima vez que esta "declaração" foi emitida,
seja qual for o estado atual, as ferramentas farão
o que for determinado. A idempotência é especialmente
importante na automação, pois uma empresa pode dizer
"a cada meia hora, certifique-se de que um ambiente
seja assim...". Então, toda vez que a sintaxe declarativa é
aprovada, você sabe que, quando executa um comando,
tudo é validado, nada é duplicado e os ambientes
permanecem em conformidade contínua.
Relatório do DevOps corporativo 2020-21
Monitoramento de conformidade e relatórios
No entanto, não basta ser compatível — você precisa ser
capaz de relatar e documentar o status de conformidade
para atender às necessidades de equipes de conformidade
interna e auditorias externas de terceiros ou órgãos
reguladores.
As equipes habilitadas para o DevOps que adotaram
os modelos "como código" e "conformidade contínua"
têm uma vantagem inerente. As configurações como
código fazem parte da documentação da estrutura de
conformidade, e os relatórios automatizados de processo
de conformidade contínua demonstram a aplicação
e a imposição da referida estrutura. Cada vezes é mais
frequente que auditores de terceiros com experiência em
tecnologia avaliem onde as organizações têm aproveitado
modelos como código certificados pela indústria como
parte da estrutura de conformidade. As empresas
que podem demonstrar rapidamente a conformidade
consistente têm uma experiência de auditoria mais
tranquila.
48
As empresas com melhor performance estão
implementando painéis de conformidade, semelhantes
às soluções de monitoramento de aplicações que as
equipes de operações usam há anos. O objetivo do painel
de conformidade é fornecer às equipes do DevOps e às
equipes de conformidade centralizada inteligência em
tempo real no status de conformidade. Por exemplo,
o Azure Security Center tem um painel de conformidade
regulatória, conforme mostrado na Figura 13.
Esses painéis simplificam o processo de medição e geração
de relatórios sobre conformidade, mas ainda fornecem
a capacidade de aprofundar detalhes granulares, se
necessário.
Relatório do DevOps corporativo 2020-21 49

CASO DE SUCESSO DE CONFORMIDADE

A empresa de serviços públicos Eneco tinha ambições
ousadas de ficar à frente em inovação, sustentabilidade
e centricidade do cliente, enquanto se tornava mais
internacional. Ela reconheceu que os serviços de TI
baseados localmente existentes precisam ser alterados
para permitir isso. A organização decidiu migrar para uma
plataforma centralizada em nível de grupo para a TI.
Como a arquitetura de referência exigia novas formas
de trabalho inovadoras, era importante impor o uso a
equipes não familiarizadas com os princípios e padrões.
Hoje, os proprietários de produtos do DevOps têm mais
autonomia e propriedade em equipes multifuncionais,
mas ainda operam na estrutura de arquitetura de
referência da Eneco.

Mas como a Eneco poderia garantir o controle Além disso, uma base de nuvem com uma zona de
contínuo desse novo cenário tecnológico globalizado, destino criada no Microsoft Azure fornece todos os
especialmente nos serviços de TI baseados em nuvem e serviços genéricos (incluindo todos os serviços de
nas equipes do DevOps? A empresa ainda operava com segurança básicos e avançados) em uma única equipe
alguma tecnologia herdada na infraestrutura local, mas do DevOps de serviços gerenciados — em conformidade
tinha planos de se tornar totalmente baseada na nuvem com a arquitetura de referência. Isso liberou todas as
até 2022. Com cada vez mais pessoas migrando para outras equipes do DevOps para se concentrarem em criar
novas funções baseadas na nuvem, precisava haver um novos recursos, responder a eventos imediatos e expandir
nível de consistência na organização inteira. (ou reduzir) máquinas virtuais em poucos minutos.
Agora eles podem atender às necessidades de negócios
Trabalhando com a Sogeti, a Eneco estabeleceu uma
inesperadas sem precisar se preocupar se as VMs estão
arquitetura de referência de nuvem que descrevia os
atualizadas conforme as necessidades de conformidade,
princípios e padrões de nuvem, negócios e segurança pelos
conforme exigido pelos princípios definidos.
quais o cenário de TI deve ser executado. A conformidade
com essa arquitetura de referência garantiria a gestão ativa
pela Eneco de riscos, informações (fluxos), conformidade,
custos e qualidade. Essa mesma arquitetura de referência
desempenhou um papel importante na atenuação das
preocupações de conformidade externa, orientando o
uso e a segurança de dados e aplicações no processo do
DevOps, bem como em aplicações e serviços hospedados
por parceiros.

RECURSOS AVANÇADOS DE CONFORMIDADE

Plataforma compatível
Simplifique a conformidade

Conformidade como código contínua

Crie e gerencie políticas para impor a conformidade

Monitoramento de conformidade e relatórios

Gerencie desafios regulatórios com eficácia
Relatório do DevOps corporativo 2020-21 50

Conclusão

Nossa pesquisa mostrou que a velocidade É claro que a transformação do DevOps em escala
empresarial pode trazer desafios, especialmente em relação
do desenvolvedor, medida pelo índice de
ao gerenciamento de produtos, trabalho distribuído e
velocidade do desenvolvedor (DVI), está remoto, governança, qualidade, segurança e conformidade.
intimamente correlacionada a retornos
No entanto, do ponto de vista holístico, as organizações
melhorados para os acionistas, bem
de alta performance seguem ideologias e padrões comuns
como outros indicadores de performance para enfrentar esses desafios.
de negócios como inovação, satisfação
do cliente, gerenciamento de marcas
e talentos.

As organizações empresariais estão adotando o DevOps

à medida que procuram melhorar a velocidade do
desenvolvedor e permitir uma transformação digital
mais ampla. À medida que essas transformações digitais
continuam, os departamentos de TI estão passando por
uma transformação do DevOps para garantir que possam
atender às crescentes necessidades da organização e de
clientes em uma economia digital em constante mudança.
Relatório do DevOps corporativo 2020-21 51

AS ORGANIZAÇÕES EMPRESARIAIS DE MELHOR PERFORMANCE ESTÃO:

Migrando para equipes autônomas e alinhadas a produtos que usam práticas de entrega
1 contínuas, cadeias de ferramentas do DevOps e hospedagem na nuvem para acelerar a
entrega de produtos e melhorar a velocidade do desenvolvedor.

Implementando plataformas compartilhadas e self-service que têm a governança, a

2 conformidade, a segurança e a qualidade necessárias, tornando a coisa "certa" a fazer
também a coisa "fácil" a ser feita.

Adotando uma mentalidade de InnerSource para compartilhar e reutilizar códigos e

3 práticas recomendadas na empresa inteira, mas também para promover uma ética
colaborativa de melhoria contínua com propriedade e responsabilidade compartilhadas.

Aproveitando a automação sempre que possível para reduzir o tempo gasto em trabalhos
repetitivos, liberando as equipes para focarem na agregação de valor comercial e na
4
inovação, evitando a sobrecarga do operador ao lidar com grandes volumes de dados,
alertas etc.

Concebendo arquiteturas de referência padronizadas em torno de padrões comuns de

infraestrutura e aplicações de nuvem, usando táticas de automação do DevOps como
5 infraestrutura como código e configuração como código para mover essas arquiteturas
de referência de diagramas do Visio para modelos de código reutilizáveis que aceleram
a adoção generalizada.

Dividir os silos, não apenas entre Dev e Ops, mas também entre as equipes centralizadas
que estabelecem os padrões de qualidade, segurança e governança. As equipes de
6 produtos que precisam estar em conformidade com esses padrões. As equipes que
contribuíram com os padrões e os processos de governança têm maior probabilidade
de cumpri-los.

Medir e aprender — a capacidade de observação é fundamental para o sucesso das

empresas. Ele não só permite que eles meçam a qualidade e a performance, mas também
7
que relatem, para criar os loops de comentários que permitem que as organizações
aprendam, aprimorem e otimizem todos os processos e tecnologia.

As recomendações deste relatório podem ser usadas como um modelo para abordar os desafios destacados e
acelerar a transformação do DevOps. Isso, por sua vez, permitirá que as pessoas que transformam as organizações
empresariais obtenham melhores resultados para os clientes e melhores retornos para as partes interessadas.
Relatório do DevOps corporativo 2020-21 52

Autores

Samit Jhaveri é diretor de marketing de produto com o Microsoft Azure focado

no desenvolvimento de aplicações de nuvem e o DevOps com o GitHub. Ele atua como
o líder de negócios trabalhando em gerenciamento de produtos, liderança de vendas e
finanças com a responsabilidade de definir e executar a estratégia de entrada no mercado
E2E, incluindo preços e ofertas e planos de execução, como campanhas e ações de campo
e parceiro para o crescimento dos negócios. Ele também é responsável pela proposição
de valor do Azure para desenvolvimento e teste de aplicações, incluindo posicionamento
e mensagens, desenvolvimento de conteúdo e identidade visual. Antes da função atual,
Samit liderou uma equipe de engenharia na divisão de ferramentas e servidores da
Microsoft e foi responsável pelo envio de várias soluções B2B para diferentes indústrias
verticais. Samit obteve um MBA na Universidade de Washington e fez mestrado em
Gerenciamento de Sistemas de Informações na Universidade do Arizona.

Clemens Reijnen é CTO global de serviços de nuvem e líder do DevOps na Sogeti. Ele
foi recebeu o prêmio de melhor profissional da Microsoft por 10 anos seguidos e é membro
técnico da SogetiLabs. Ele é coautor do livro "Colaboração na nuvem" com a Microsoft
e escreve frequentemente sobre nuvem e DevOps em Sogeti.com. Como líder global do
DevOps, ele trabalha em estreita colaboração com os maiores clientes corporativos da
Sogeti para garantir que programas de adoção de nuvem e transformação empresarial do
DevOps valorizem os negócios.

Steve Thair é CTO e cofundador da DevOpsGroup Ltd, uma empresa líder em serviços
de nuvem e DevOps do Reino Unido. Fundada em 2013, a DevOpsGroup agiliza a adoção
do DevOps e da nuvem, de forma segura e simples, ajudando as organizações a prosperar
na nova economia digital. Em reconhecimento por sua liderança de pensamento
e contribuições para a comunidade do DevOps como cofundador de www.winops.org,
uma comunidade dedicada a promover padrões e práticas do DevOps em ambientes
tecnológicos Windows e Microsoft, em 2016 Steve Thair se juntou ao programa "Regional
Director" da Microsoft que reconhece ~ 180 dos principais visionários da tecnologia do
mundo por sua experiência técnica comprovada entre plataformas, liderança comunitária
e comprometimento com os resultados Steve escreve regularmente no blog sobre
o DevOps e tópicos de nuvem em www.devopsgroup.com/blog/.
Relatório do DevOps corporativo 2020-21 53

Métodos de pesquisa

Velocidade do Desenvolvedor Pesquisas adicionais

A pesquisa da McKinsey sobre o Índice de Velocidade do Dados adicionais foram coletados por pesquisas e
Desenvolvedor (DVI) leva em conta 46 fatores diferentes entrevistas com os leads de prática de nuvem e DevOps
em 13 áreas de capacidade (demonstração). Para da Sogeti. No total, esses leads de prática são responsáveis
desenvolver e validar essa lista de fatores, eles realizaram por mais de 250 implementações de nuvem e DevOps do
entrevistas com mais de 100 diretores de tecnologia, cliente, e seus comentários foram usados para fornecer
diretores de informações e outros líderes de engenharia as recomendações e o insight adicional do cliente no
sênior. Eles pediram a executivos de tecnologia em 440 relatório.
grandes organizações em 12 indústrias em nove países
para avaliar a performance da empresa. As pontuações
do DVI são calculadas como uma média ponderada de
pontuações em todos os fatores, com o mesmo peso
atribuído às três principais categorias — tecnologia,
práticas de trabalho e capacitação organizacional. A
análise considerou o impacto das pontuações do DVI na
receita, nos retornos totais dos acionistas e na margem
operacional. Eles também analisaram quatro indicadores
de performance de negócios não financeiros: inovação,
satisfação do cliente, percepção da marca e gerenciamento
de talentos. Por fim, eles fizeram correlações estatísticas da
performance dos negócios em relação às várias dimensões
da velocidade do desenvolvedor. Em seguida, eles usaram
a análise de pesos relativos da Johnson para quantificar
a importância relativa dos fatores correlacionados das
pontuações de DVI. Para ler mais sobre a pesquisa de DVI,
clique aqui.

Avisos legais

©2020 Microsoft Corporation. Todos os direitos reservados. Este documento é fornecido "no estado em que se encontra".
As informações e as opiniões expressas nele, incluindo URLs e outras referências a sites da Internet, podem ser alteradas sem
aviso prévio. Você assume o risco de utilização.

Este documento não oferece a você direitos legais sobre a propriedade intelectual de produtos da Microsoft.
Você pode copiar e usar este documento para fins internos e de referência.