2022 State of Devops Report PT-BR

2022 ACCELERATE
Relatório State of DevOps
Patrocínio
Índice
01 Resumo executivo 03
05 Surpresas 55
Informações
02 Sua equipe está
à altura?
06 demogácas
08
e mogácas 59
03 O que fazer para

melhorar? 07
Considerações
nais 67
Introdução 19
Nuvem 21
08 Agradecimentos 68
SRE e DevOps 26
09
Capacidade técnica de DevOps 29
Autores 69
Cultura 37
04 Por que a segurança

da cadeia de
10 Metodologia 73
suprimentos
é imporante 42
11 Leitura adicional 76
ACCELERATE State of DevOps 2022 Índice 2

01
Resumo executivo Derek DeBellis Claire Peters
Nos últimos oito anos, elaboramos o relatório

Accelerate State of DevOps com base em
enevisas com 33 mil possionais. O oco da
nossa pesquisa é examinar como capacidades
e práticas indicam os resultados que
consideramos centrais para DevOps:
• Desempenho da enega de sofwae: as

quatro métricas principais do desempenho da
enega de sofwae, que são equência de
implanação, empo de lead paa aleações, axa
de alha nas aleações e empo de esauação
do seviço.
• Desempenho operacional: a quinta métrica

pincipal, que é a conabilidade.
• Desempenho da oganização: se a
oganização consegue cumpi as meas
de desempenho e de lucaividade.
Também analisamos os fatores que levam

a outros resultados, como esgotamento
e a probabilidade de os funcionários
ecomendaem as pópias equipes.
ACCELERATE State of DevOps 2022 Resumo executivo 3

Como proteger a
cadeia de suprimentos
de sofwae
Em 2021, descobrimos que proteger a cadeia de A adoção de boas páicas de seguança no

supimenos de sofwae é essencial paa alcança desenvolvimento de aplicativos está relacionada a
muios esulados imporanes. ouos beneícios. Consaamos que as equipes que
Neste ano, nos aprofundamos mais na segurança estabelecem essas práticas de segurança reduziram
da cadeia de supimenos de sofwae, que é o ema o esgoameno dos desenvolvedoes. Ene as
pincipal da nossa pesquisa e elaóio. Usamos o equipes com baixos níveis de práticas de segurança,
amewok Supply Chain Levels o Secue Ariacs a probabilidade de altos níveis de esgotamento
(SLSA) para analisar práticas técnicas que auxiliam no é 1,4 vez maior que nas equipes com altos níveis de
desenvolvimeno dessa seguança. Também usamos o seguança.1 As equipes que estabelecem práticas
Secue Sofwae Developmen Famewok (NIST SSDF) de seguança êm pobabilidade muio maio de
do Insiuo Nacional de Padões e Tecnologia paa ecomenda a pópia equipe aos demais. Além
analisar atitudes, processos e práticas não écnicas disso, as práticas de segurança relacionadas a
elacionados à poeção da cadeia de supimenos de SLSA sugerem um bom desempenho tanto da
sofwae. oganização quano da enega de sofwae, mas

é peciso implana sólidos ecusos de inegação
Descobrimos que o maior fator para prever as práticas
conínua paa que isso ocoa.
de segurança de desenvolvimento de aplicativos
de uma oganização ea culual e não écnico.
As culuas com ala conança, baixa culpa e oco
em desempenho adotam práticas de segurança
emegenes em equência 1,6 vez maio que culuas
com baixa conança e ala culpa concenadas em
egas. Também enconamos evidências iniciais de
que a veicação de seguança anes da implanação
é ecaz em idenica dependências vulneáveis, o que
eduz as vulneabilidades no código de podução.
1
Nessa esaísica, consideamos "alos níveis" como desvio-padão >= 1 na ponuação (po exemplo, seguança), e "baixos níveis" como
desvio-padão <= -1.

Fatores que impulsionam o
desempenho organizacional
Além das práticas de segurança mencionadas acima,
as principais variáveis que afetam o desempenho Nuvem
organizacional costumam estar em uma destas Descobrimos que o uso da nuvem é um indicador
categorias: do desempenho oganizacional. As empesas com
sofwae ciado na nuvem e paa a nuvem cosumam
Cultura organizacional e da equipe ter melhor desempenho oganizacional. O uso
As culuas com ala conança e baixa culpa, segundo de nuvens privadas, públicas ou híbridas (ou uma
a denição de Westrum, costumam ter maior mistura delas) corresponde a um melhor desempenho
desempenho oganizacional. Da mesma forma, as organizacional do que o uso apenas de servidores
oganizações com equipes que se sentem apoiadas por no local. Ene as oganizações que usam nuvens
nanciameno e paocínio da lideança costumam ter públicas, a probabilidade de desempenho acima da
melho desempenho. A esabilidade e a pecepção média é 1,4 vez maio que as demais.
positiva da equipe (probabilidade de recomendá-
O uso da nuvem também parece afetar o desempenho
la) também costumam levar a níveis mais altos de
organizacional por meio de outros fatores no nosso
desempenho oganizacional. Po úlimo, as empesas
conjuno de dados. Um dos exemplos é a seguança
que oeecem condições de abalho exíveis
da cadeia de supimenos. Consaamos que as
costumam ter níveis mais altos de desempenho
oganizações que usam nuvens públicas cosumam
oganizacional.
implementar práticas de SLSA, talvez porque os
provedores de nuvem ofereçam componentes para
Conabilidade
muias páicas de SLSA, como a auomação de builds
As práticas que associamos com a engenharia de
e implemenações.2,3 A quesão pincipal é que, ao
conabilidade (como meas claas, métricas salientes
usa plaaomas de nuvem, as equipes êm acesso
ec.) e a exensão em que as pessoas cumpem as
a muios ecusos e páicas que cosumam melhoa
expecaivas de conabilidade são bons indicadoes
o desempenho oganizacional.
de alos níveis de desempenho oganizacional.
2
Jung, Sun Jae. "Inoducion o Mediaion Analysis and Examples o Is Applicaion o Real-wold Daa." Jounal o pevenive medicine and
public healh = Yebang Uihakhoe chi vol. 54,3 (2021): 166-172. doi:10.3961/jpmph.21.069
3
Caión, Gabiel Cepeda, Chisian Nizl e José L. Roldán. "Mediaion analyses in parial leas squaes sucual equaion modeling:
Guidelines and empiical examples." Parial leas squaes pah modeling. Spinge, Cham, 2017. 173-195.

O contexto é imporante
Há muio empo, DORA considea que os eeios dependem do conexo geal da equipe. Acediamos
que é imporane enende as caaceísicas da equipe (pocessos, ponos ores, limiações e meas)
e o ambiene em que o abalho é eio. Po exemplo, um ecuso écnico que é vanajoso em um conexo
pode se pejudicial em ouo. Ese ano, ciamos um modelo clao dessas condições hipoéicas na oma
de ineações. Muias das hipóeses oam conmadas pelos dados dese ano:
• O alo desempenho na enega de sofwae só aingi essa mauidade, não deecamos

benecia o desempenho oganizacional quando elação ene SRE e o cumpimeno de meas
esse úlimo desempenho ambém é alo. Não de conabilidade. No enano, conome cesce,
adianta entregar rapidamente quando o serviço a adoção da SRE ainge um pono de inexão
não em a conabilidade que os usuáios espeam. em que o uso dela se ona um ore indicado
da conabilidade. Po sua vez, essa melhoa na
• A implemenação de conoles de seguança conabilidade aea o desempenho oganizacional.
da cadeia de supimenos de sofwae, como
aqueles recomendados pelo amewok SLSA, êm • Capacidades técnicas dependem umas das
impacto positivo sobre o desempenho da entrega ouas. A enega conínua e o conole de vesão
quando a inegação conínua esá memene amplicam a capacidade múua de melhoa
esabelecida. Sem a inegação conínua, pode o desempenho da enega de sofwae. A
have conio ene o desempenho da enega combinação de enega conínua, aquieua
de sofwae e os conoles de seguança. acoplada com exibilidade, conole de vesão e
inegação conínua pomove um desempenho na
• As páicas de engenhaia de conabilidade enega de sofwae maio que a soma das pares.
do sie (SRE) êm impaco não linea sobe a
capacidade da equipe de cumprir as metas de
conabilidade. A SRE só auxilia na conabilidade
quando uma equipe alcança cero nível de
mauidade nessa páica. Anes de a equipe

As condições de que a enega depende e a Sabemos disso porque, em geral, as equipes que
necessidade de entender o contexto de uma azem isso êm melho desempenho oganizacional.
equipe nos levam a uma conclusão semelhane Nem sempe (o que unciona paa uma oganização
a ese echo de 2021: não unciona necessaiamene paa oua), mas na
maioia do empo sim. Ao esa páicas de DevOps,
"Paa aze melhoias signicaivas, as equipes
não se peocupe com evenuais alhas enquano você
pecisam adoa uma losoa de melhoia
descobe o que unciona paa sua equipe.
conínua. Use os compaaivos de mecado paa
medi seu esado aual, idenica esições com
Este ano, também descobrimos algumas surpresas
base nas capacidades investigadas pela pesquisa
nos dados, mas você vai pecisa coninua lendo
e esa melhoias paa alivia essas esições.
paa sabe.
A expeimenação envolveá uma combinação
de vióias e alhas, mas em ambos os cenáios as
equipes podeão ealiza ações signicaivas como
esulado das lições apendidas."
De fato, este ano descobrimos um efeito alinhado

As equipes que reconhecem
a essa losoa geal: as equipes que econhecem a a necessidade de melhorar
necessidade de melhorar continuamente costumam ter continuamente costumam
melho desempenho oganizacional do que as demais.
ter melhor desempenho
Ou seja, as equipes precisam se adaptar organizacional do que as
continuamente e testar novas práticas de demais.
desenvolvimeno de sofwae.

02
Sua equipe está Derek DeBellis
à altura?
Quer saber como sua equipe se compara às outras O segundo método inclui uma quinta métrica,
empesas do seo? Esa seção inclui a avaliação de conabilidade, que usamos paa enende o
comparativo de mercado mais recente do desempenho desempenho opeacional. Po que adiciona uma
de DevOps. Vamos examina a maneia como as méica nova à análise de agupameno? Poque
equipes desenvolvem, entregam e operam sistemas emos viso consanemene a imporância dela.
de sofwae. Depois vamos dividi as esposas em Temos evidências que sugeem que o desempenho da
gupos que indicam as combinações mais comuns de entrega pode prejudicar o desempenho organizacional
desempenho de DevOps. quando não esá associado a um sólido desempenho
opeacional. Ao conáio do nosso méodo adicional
Ese ano, incluímos dois méodos de agupameno. de agrupamento, este é um exercício descritivo,
O pimeio é baseado no pecedene hisóico. Nese que tenta mostrar maneiras comuns em que as
método, criamos grupos com base em quatro métricas equipes operam entre o desempenho da entrega e o
que indicam o desempenho da enega de sofwae: opeacional. Po isso, não é sempe óbvio qual gupo é
empo de lead, equência de implanação, empo de melho.
esauação do seviço e axa de alha nas aleações. Há
Pimeio vamos ve uma beve visão geal das cinco
um esumo de cada uma abaixo. O objeivo é quanica
medidas que usamos para entender o desempenho
o desempenho aual da sua equipe paa que você possa
opeacional e da enega de sofwae.
compaá-lo a ouas equipes.
ACCELERATE State of DevOps 2022 Sua equipe está à altura? 8

Desempenho operacional e
da entega de sofwae
Paa aende à demanda dos seoes em evolução, as paa indica a capacidade opeacional. As equipes
oganizações pecisam enega e opea sofwae que se destacam nas cinco medidas demonstram um
de maneia ápida e conável. Quano mais ápido as desempenho oganizacional excepcional. Chamamos
equipes pudeem aze mudanças no sofwae, mais essas cinco medidas de desempenho operacional e
apidamene você conseguiá agega valo aos seus da entega de sofwae (SDO, na sigla em inglês).
clienes, ealiza expeimenos e ecebe eedback. Essas méicas esão elacionadas a esulados no
Com oito anos de coleta e pesquisa de dados, nível do sisema. Isso evia as amadilhas comuns
desenvolvemos e validamos quatro métricas que das méicas de sofwae de aseameno, que
medem o desempenho da enega de sofwae. Desde podem coloca unções umas cona as ouas e aze
2018, incluímos uma quinta métrica oimizações locais ao cuso do esulado geal.

Desempenho da
enega de sofwae
Tempo de lead MTTR

paa aleações
Cinco métricas do desempenho

operacional e de entrega
As quatro métricas de desempenho da entrega de
sofwae podem se consideadas em emos de Fequência de Taxa de falha
implanação nas aleações
capacidade e esabilidade. Medimos a capacidade
usando o tempo de lead das alterações de código (ou
seja, o empo da conmação do código aé o lançameno
na podução) e a equência de implantação. Medimos a
estabilidade usando o tempo para restaurar um serviço Desempenho
operacional
após um incidente e a taxa de falha nas alterações.
A quinta métrica, que representa o desempenho

operacional, é uma medida de práticas operacionais
modenas. Baseamos o desempenho operacional Conabilidade
na conabilidade, que signica veica se os
serviços atendem às expectativas dos usuários, como
disponibilidade e desempenho. Anes nós medíamos a
disponibilidade em vez da conabilidade. Mas, como a
disponibilidade é um oco especíco da engenhaia de
conabilidade, expandimos paa medi a conabilidade
em 2021. Dessa oma, epesenamos melho
disponibilidade, laência, desempenho e escalonabilidade.
Especicamene, pedimos aos paricipanes paa avalia
a capacidade deles de atingir ou exceder as metas de
conabilidade. Consaamos que as equipes com gaus
variados de desempenho da entrega chegam a resultados
melhores (por exemplo, menos esgotamento) quando
ambém pioizam o desempenho opeacional.

Método de agrupamento histórico: indicavam sempe que ês gupos capuavam melho
agrupando o desempenho da os dados, seja qual osse a écnica aplicada. A abela
entrega abaixo mostra as características do desempenho da

enega de cada gupo.
Nese ano, ao avalia a solução com quao gupos

que usamos desde 2018, percebemos que os A dieença supeendene em elação ao ano passado é
dados mostravam claramente um grupo com baixo que não consideamos nenhum gupo como elie desa
desempenho e ouo com alo desempenho. No vez. O gupo alo dese ano é uma misua dos gupos
entanto, os dois grupos que costumávamos usar para alo e elie do ano passado. Decidimos omii o gupo de
demarcar o desempenho médio e o desempenho alto elie poque o gupo com melho desempenho não indica
não eam dieenciados o suciene paa jusica caaceísicas sucienes da elie do ano passado.
uma divisão. Além disso, os váios índices usados paa

escolhe a melho solução de agupameno
Mética de desempenho na entega de sofwae Baixo Médio Alto
Fequência de implantação Entre uma vez por Entre uma vez Sob demanda
mês e uma vez a por semana e (várias
No caso de aplicaivos ou seviços pincipais em que você abalha, com que
cada seis meses uma vez po mês implanações
equência sua oganização implana códigos na podução ou os libea paa
por dia)
usuáios nais?
Tempo de lead para alterações Ene um mês e Entre uma Entre um dia e
No caso de aplicaivos ou seviços pincipais em que você abalha, qual seis meses semana e um uma semana
é o empo de lead paa aleações (ou seja, quano empo leva paa i da mês
conmação do código à execução do código na podução)?
Tempo de estauação do seviço Entre uma Entre um dia e Menos de

semana e um mês uma semana um dia
No caso de aplicaivos ou seviços pincipais em que você abalha, quano
tempo geralmente leva para restaurar o serviço quando ocorre um incidente
ou um deeio que aea os usuáios (po exemplo, ineupção não planejada
ou deciência do seviço)?
Taxa de falha nas alterações 46% a 60% 16% a 30% 0% a 15%

No caso de aplicaivos ou seviços pincipais em que você abalha, qual
pocenagem de aleações na podução ou libeadas paa os usuáios esula
em queda no seviço (po exemplo, leva à deciência ou ineupção do
seviço) e, poseiomene, exige emediação (po exemplo, exige um hoix,
evesão, coeção de encaminhameno, pach)?

Isso sugee que a amosa não epesena equipes Dito isso, quando comparamos os grupos baixo,
ou oganizações com uncionáios que senem médio e alto deste ano com os do ano passado,
que evoluíam. Uma hipóese possível (que não vemos um leve aumeno no desempenho da enega.
podemos ama como ao po ala de dados) é Paece que os gupos dese ano esão ene dois
que houve edução da inovação no desenvolvimeno dos gupos do ano passado. O gupo alo de 2022
de sofwae, em emos de páicas, eamenas esá ene o alo e o elie de 2021. O gupo baixo de
e comparilhameno de inomações. A edução 2022 paece esa ene o baixo e o médio de 2021.
pode se esulado da aual pandemia, que dicula O aumento no grupo de baixo desempenho sugere
o comparilhameno de conhecimenos e páicas que, embora o teto do desempenho na entrega tenha
em equipes e oganizações. Isso eia eduzido as subido, o piso desceu.
oporunidades paa se euni e apende uns com
os ouos, o que, po sua vez, onaia a inovação
mais lena. Espeamos analisa melho os dados paa
enende as causas dessa consaação.
7%
2018 20%
2019 26%
2021 N/A
2022
Elite Elite Elite Elite
48% 11%
23% Alto
Alto 40%
Alto
Alto
69%
37% 44% Médio
Médio 28%
Médio
Médio
15% 12% 7% 19%

Baixo Baixo Baixo Baixo

Os números na tabela acima mostram que
a pocenagem de paricipanes com alo
desempenho é a mais baixa em quao anos.
Já a pocenagem de paricipanes com baixo
desempenho eve um aumeno dásico de 7% em
2021 paa 19% ese ano. Mais de dois eços dos
paricipanes dese ano esão no gupo médio. A
evidente queda nos grupos com desempenho alto
e de elie pode indica que os paricipanes dese
ano esão em oganizações ou equipes que ainda
não esabeleceam (ou esão esabelecendo agoa)
uma cultura de DevOps, que vemos surgir em várias
equipes modenas.
Talvez estejamos falando demais sobre as

diferenças entre 2021 e 2022 em vez de destacar as
semelhanças. Há muias caaceísicas semelhanes
nos grupos dos dois anos, incluindo uma enorme
sepaação ene paricipanes com desempenho
alo e baixo. Po exemplo, esimamos que os
paricipanes com alo desempenho1 enham 417
vezes mais implanações que aqueles com baixo
desempenho.
1
Consule a seção "Meodologia" paa
entender como a estimativa é feita

Agrupamento do desempenho em nossos modelos. Nas oganizações que não
na entrega e do desempenho demonstram um desempenho operacional sólido,
operacional a capacidade de processamento e a estabilidade

êm meno impaco no desempenho oganizacional.
Decidimos aze uma análise po gupos nas ês Achamos que descrever o cenário do desempenho de
categorias que as cinco métricas representam: DevOps sem considerar o desempenho operacional
capacidade de processamento (composto por tempo signica deixa uma pare essencial de oa.
de lead das aleações no código e equência de

implanação), estabilidade (composto por tempo de Ao analisa os dados, chegamos a uma solução com
esauação do seviço e axa de alhas nas aleações) quao gupos. Cona os númeos dos quao gupos e
e desempenho operacional (conabilidade). O moivo os respectivos nomes:
é o papel essencial que o desempenho operacional tem
Desempenho
Estabilidade Capacidade de processamento
operacional
Grupo % paricipantes
Tempo de
Taxa de falha nas Fequência de
estauação do Conabilidade Tempo de lead implantação
alterações
serviço
Entre uma Entre uma vez por

Entre um dia e uma Às vezes atende às 28%
Início 31% a 45% semana e um semana e uma vez
semana expectativas
mês po mês
Sob demanda
Geralmente atende (várias 17%
Fluidez Menos de uma hoa 0% a 15% Menos de um dia
às expectativas implanações po
dia)
Entre uma Entre uma vez por

Desace- Geralmente atende 34%
Menos de um dia 0% a 15% semana e um semana e uma vez
leação às expectativas
mês po mês
Entre uma vez por

Desati- Ene um mês e seis Geralmente atende Ene um mês e 21%
46% a 60% mês e uma vez a
vação meses às expectativas seis meses
cada seis meses

Cada grupo tem as próprias peculiaridades
e é esponsável po uma popoção
substancial das espostas.
O grupo Início não em desempenho bom nem uim

nas nossas dimensões. Talvez o gupo eseja na ase
No enano, se você visiasse duas equipes do inicial do desenvolvimento do produto, recurso ou
mesmo grupo, elas pareceriam muito diferentes, seviço. Talvez eseja menos peocupado com a
e nossa hisóia não capua udo que você veia. conabilidade poque o oco é ecebe eedback,
A história que apresentamos para cada grupo entender se o produto é adequado ao mercado e, em
acima é uma enaiva de usa nossa expeiência geal, exploa.
trabalhando com várias equipes para tornar
ineligíveis esses padões nos dados. Além disso, se O grupo Fluidez tem bom desempenho em
você visiasse a mesma equipe em dois momenos odas as caaceísicas: ala conabilidade, ala
dieenes, é possível que ela não casse no esabilidade, ala capacidade de pocessameno.
mesmo gupo. Um moivo paa isso é que a equipe Apenas 17% dos paricipanes esão nesse esado.
melhoou ou pioou. Oua possibilidade é que a
equipe migou paa um padão de implanação mais
Os paricipanes do gupo Desaceleação não
apropriado ao estado atual do aplicativo ou serviço
implanam com equência, mas gealmene êm êxio
dela. Po exemplo, no início do desenvolvimeno
quando o azem. Mais de um eço dos paricipanes
de um aplicativo ou um serviço, o foco da equipe
está nesse grupo, sendo o maior e mais representativo
ea a exploação (gupo Início). Mas, conome
da amosa. Ese padão é caaceísico (mas não
foi encontrando o nicho dela, a equipe mudou
exclusivo) de siuações em que as equipes esão
o oco paa a conabilidade (gupo Fluidez ou
melhoando aos poucos, mas elas e os clienes esão
Desaceleação).
saiseios com a siuação aual do aplicaivo ou poduo.
Po m, o gupo Desativação é como uma equipe

que está trabalhando em um serviço ou um aplicativo
que ainda tem valor para ela e os clientes, mas que
não esá mais em desenvolvimeno aivo.

As pincipais dieenças ene os gupos são as Algo curioso é que o grupo Fluidez costuma se preocupar
páicas e as capacidades écnicas. Devido ao alo menos com a documenação. Ano passado, consaamos
nível de desempenho operacional e na entrega de que a documenação é essencial paa o desempenho
sofwae do gupo Fluidez, decidimos examinar opeacional e da enega (SDO, na sigla em inglês). Como
as diferenças entre ele e os outros grupos nesses o grupo Fluidez consegue bom desempenho de SDO
aspecos. Consaamos que, em elação aos demais sem gande dedicação à documenação? Em pimeio
grupos, o grupo Fluidez dedica mais aenção a eses lugar, há muitos caminhos para um bom desempenho de
itens: SDO oa da documenação. Além disso, é possível que
o grupo Fluidez refatore constantemente o código para
• Aquieuas com acoplameno exível: na
cia um pocesso com documenação auomáica. Assim,
medida em que as equipes podem fazer grandes
a necessidade de documentos como descrevemos na
mudanças no design do sistema sem depender
pesquisa seia meno.
das mudanças de outras equipes em outros
sistemas
O grupo Desaceleação, que oma a maio popoção
dos paricipanes, é omado gealmene po pessoas de
• Aumena a exibilidade: a exibilidade da
oganizações maioes, com menos ecusos naivos da
empesa em elação ao abalho dos uncionáios
nuvem do que os demais. Imagine uma empesa muio
• Conole de vesões: a oma de geencia madua, com pocessos calcicados que, no m das conas,
mudanças no código e conguação do ainda popocionam expeiências esáveis e conáveis
aplicaivo, na conguação do sisema ec. (e valiosas) aos usuáios nais. O gupo mosa uma
culua geneaiva e oienada ao desempenho.2 Uma das
• Inegação conínua (CI): a equência de caaceísicas mais ineessanes do gupo Desaceleação
inegação das amicações na linha pincipal é a combinação incomum de baixa capacidade de
processamento e alta cultura de trabalho positiva (uma
• Entrega contínua (CD): capacidades para colocar
culua "geneaiva" segundo Wesum). É mais comum
mudanças em podução de maneia segua,
ver capacidade de processamento e cultura de trabalho
susenável e eciene
popocionais (ambas alas ou baixas). Espeamos pesquisa
2
(Westrum)
mais para entender melhor a elação ene os dois aoes.

Também compaamos os gupos em ês esulados: • Existem atributos relacionados aos quatro
esgotamento, desempenho organizacional e trabalho gupos que não esão nos nossos dados. Po
não planejado. As consaações oam conáias às exemplo, o amanho da oganização pode se
nossas expecaivas. O gupo Desativação teve maior um bom indicado da mauidade. O gupo
desempenho oganizacional que os demais. Analisando Fluidez é formado principalmente por empresas
as características do grupo (baixa estabilidade e baixa pequenas, o que pode indicar que os produtos
capacidade de processamento), isso parece contrariar delas esão na ase inicial.
as consaações aneioes de DORA. Mas, em vez
de considerar isso uma anomalia aleatória (grande • A maioria dos integrantes do grupo Fluidez
probabilidade), queremos analisar algumas possíveis são de empesas menoes, que podem esa
explicações. menos limitadas por processos históricos e
inaesuua. Po isso, elas eiam pocessos
Paa enende essas consaações, é imporane de DevOps mais sosicados. Dio isso, os
e em mene oua consaação complemena. O dados mosam uma coelação posiiva ene
grupo Desativação consegue alto desempenho o amanho da oganização e o desempenho
organizacional a um grande custo: as equipes do grupo oganizacional, po moivos que podem não e
êm os maioes índices de esgoameno, se senem ligação com ecnologia.
mais susceíveis a eos e ecebem mais abalho não
planejado. Ao mesmo empo, os esulados sugeem • O grupo Fluidez costuma ignorar os princípios
que a conabilidade é o suciene paa alcança alo descios na culua geneaiva de Wesum.
desempenho organizacional, mas, sem velocidade Vimos que isso gealmene pejudica o
e estabilidade, a equipe vai pagar um alto custo em desempenho oganizacional.
esgoameno e abalho não planejado.
• As oganizações de cada gupo podem e
Temos outras hipóteses para explicar por que o grupo denições dieenes sobe expecaivas
Desativação tem melhor desempenho organizacional de conabilidade e maneias dieenes de
que os demais, especialmente o grupo Fluidez. Cona monioá-las. O mesmo vale paa a denição das
os ponos a segui. meas de desempenho oganizacional.

• O grupo Desativação tem alto desempenho Estamos interessados em continuar explorando
oganizacional no curo pazo, mas como seá novas maneias de desceve as vaiações do
o desempenho no longo prazo? O esgotamento seo. A pari de agoa, queemos coninua
vai causar rotatividade dos funcionários? As incluindo o desempenho operacional como uma
oganizações vão consegui escalona os dimensão elevane paa enende as vaiações.
processos? Também queremos evitar grupos muito prescritivos
e avaliaivos (como Elie). Em vez disso, o oco
• Esamos azendo as pegunas em váios níveis. seá o simples execício desciivo de idenica
Pegunamos sobe capacidades écnicas (como conselações comuns do desempenho de SDO.
aquieua com acoplameno exível) no nível da
equipe, mas perguntamos sobre desempenho
oganizacional no nível da oganização. As
oganizações cosumam e muias equipes.
É possível que o paricipane da pesquisa
econheça que a oganização esá uncionando,
mas a equipe em que ele abalha não esá.
Além disso, o grupo Fluidez tem o segundo melhor

desempenho organizacional, atrás do grupo
Desativação, e os níveis de esgotamento e trabalho
não planejado dele esão ene os menoes. Como
demonstram os grupos Fluidez e Desaceleação,
losoas de DevOps são mais ecazes quando há
conabilidade.

03
O que fazer para Derek DeBellis
melhorar?
O que fazer para melhorar
os vários resultados?
O objetivo do relatório State of DevOps é apresentar
oienações baseadas em evidências, que ajudem sua
equipe a se concentrar em práticas e capacidades
de DevOps e chega aos esulados imporanes paa
vocês. Nese ano, expandimos nossa invesigação
para a segurança e o conjunto de resultados que
as equipes queem. Anes nosso oco eam os
resultados relacionados a desempenho operacional
e da enega de sofwae (SDO, na sigla em inglês) e
desempenho oganizacional. Isso ainda é imporane,
mas também queríamos analisar o esgotamento,
a probabilidade de recomendar a equipe, o trabalho
não planejado e a endência a eos. Não apenas
como maneiras de melhorar o SDO e o desempenho
oganizacional, mas como ns em si mesmos. Po
isso, este ano, destacamos práticas e capacidades
que paecem inuencia esses esulados.
ACCELERATE State of DevOps 2022 O que fazer para melhorar? 19

O modelo de pesquisa dese ano mudou paa eei Além das quatro chaves
melhor uma eoia em que DORA é baseado: não
exise uma abodagem única paa DevOps. Na páica, Como as métricas de DORA
consaamos que, paa aze ecomendações, é peciso melhoram o desempenho
enende o conexo geal da equipe. Uma páica do desenvolvimento e das
que é benéca paa uma equipe pode se pejudicial opeações? Uma equipe
paa oua. Po exemplo, há empos omulamos a multifuncional de engenheiros
hipótese de que as capacidades técnicas (como de sofwae da Libery
aquieua com acoplameno exível, desenvolvimeno Muual Insuance analisa o
com base na linha pincipal, conole de vesões e desempenho regularmente
inegação conínua) êm maio impaco posiivo usando as métricas "quatro
sobe o desempenho da enega de sofwae quando chaves" de DORA. Po exemplo,
exise enega conínua. Ese ano, modelamos essa e Jenna Dailey, chefe de scrum
ouas ineações de oma explícia. A mea é amplia sênio da Libery Muual,
nosso conhecimento de "o que tem efeito sobre o contou que uma equipe usou
quê?" paa "em que condições eses eeios exisem, a pesquisa de DORA para
são amplicados ou aenuados?". Enende essas idenica um gagalo, miga
condições oi uma aea complicada e conusa, mas para uma abordagem de
esamos elizes de mosa algumas consaações desenvolvimento conduzida
iniciais a você. por testes e melhorar o
desempenho geal.
Os modelos de pesquisa deste ano e dos anos
aneioes esão disponíveis no nosso site. Saiba mais sobre a abordagem da
Libery Muual paa usa dados
e métricas DORA e melhorar a
qualidade e a enega de sofwae
no recente Tomoow Talks.

Eric Maxwell
Nuvem
36% 25%
Continuando o movimento que vimos nos últimos
anos, o uso da compuação em nuvem segue
cescendo. De ao, a pocenagem de pessoas
que amam usa a nuvem pública, incluindo váias de aumento no uso de aumento no uso
nuvens, aumenou de 56% em 2021 paa 76% agoa. da nuvem pública da nuvem híbida
O númeo de pessoas que amam não usa a

nuvem, incluindo aquelas que não usam nuvem
pivada, caiu de 21% no ano passado paa 10,5%.
O uso de mais de uma nuvem pública subiu de 21%
paa 26%, e o uso da nuvem híbida aumenou de
25% paa 42,5%. Também egisamos um pequeno
aumeno no uso da nuvem pública, de 29% no
elaóio do ano passado paa 32,5% agoa.

O uso da compuação em nuvem em impaco posiivo no
desempenho oganizacional em geal. Os paricipanes que usam
a nuvem êm pobabilidade 14% maio de alcança as metas de
desempenho oganizacional do que os demais que não a usam.
Como mostramos nos anos anteriores e continuamos da axa. Esse ao pede uma maio invesigação. Em
a valida nese elaóio, o uso da compuação em vez de especular quanto aos motivos, vamos investigar
nuvem tem um impacto positivo sobre o desempenho melho em pesquisas uuas. Mas, com poucas exceções,
oganizacional em geal. Os paricipanes que usam o uso de aplicativos nativos da nuvem (que foram criados
a nuvem êm pobabilidade 14% maio de alcança e arquitetados para a nuvem) se destacou com sinais
as metas de desempenho organizacional do que os posiivos em udo que pesquisamos.
demais que não a usam. Segundo nossa pesquisa, com
a compuação em nuvem, as equipes se supeam em O uso de qualque plaaoma de compuação em
aspectos como segurança da cadeia de suprimentos nuvem, pública ou privada, contribui positivamente
de sofwae e conabilidade, aoes que levam ao para os resultados de cultura e de ambiente de
desempenho oganizacional. trabalho (por exemplo, cultura generativa, menos
esgoameno, mais esabilidade e maio saisação
Algo surpreendente é que usuários de todos os tipos de
dos uncionáios). Os usuáios da nuvem iveam
nuvem (pública, privada, híbrida e multi) mostraram uma
ponuação 16% maio nesses esulados culuais.
associação negaiva com a axa de alhas nas aleações,
ou seja, um aumento
O uso da nuvem continua acelerando ano a ano
Vaiação
2022
desde 2021
Nuvem híbida 42,47% 25%
Uma ou váias nuvens públicas 76,08% 36%
Nuvem privada 32,55% 12%
Sem nuvem 10,55% -50%

O uso da nuvem híbrida e de várias nuvens (bem como privada)
parece ter impacto negativo sobre os indicadores de desempenho
da enega de sofwae (MTTR, empo de lead e equência de
implanação), a menos que os paricipanes enham alo nível de
conabilidade.
Nuvem híbida e váias nuvens a imporância de uma páica obusa de SRE e

aumentam o desempenho a imporância da conabilidade na enega de
organizacional sofwae.
Coninuamos vendo sólidas indicações de que o uso
da nuvem híbrida e de várias nuvens públicas tem Em 2021, pedimos que os paricipanes conassem o
impaco posiivo sobe a oganização. Os possionais motivo principal paa usa váias nuvens públicas. Já
que usam váias nuvens êm desempenho em 2022, pedimos que os paricipanes conassem
oganizacional 1,4 vez maio que aqueles que não todos os benefícios advindos do uso de vários
usam a nuvem. No enano, o uso de nuvem híbida povedoes de nuvem. A disponibilidade oi o beneício
e de várias nuvens (bem como privada) parece ter mais ciado, o que coincide com a aenção que
um impacto negativo sobre vários indicadores de pecebemos no seo em elação à conabilidade:
desempenho da enega de sofwae (MTTR, empo paa seem conáveis, os seviços pecisam esa
de lead e equência de implanação), a menos disponíveis. Mais de 50% dos paricipanes amam
que os paricipanes ambém enham alo nível de usa os beneícios especícos de váios povedoes de
conabilidade. A consaação ambém demonsa nuvem.
Beneícios da adoção de váios povedoes de nuvem
Disponibilidade
Usa os beneícios especícos de cada povedo
Divisão da conança ente váios povedoes

62,61%
51,59%
47,54%
50%
dos paricipantes amam
usar vários provedores de
Recupeação de desastes 43,48% nuvem
Compliance jurídico 37,97%
Tática de negociação ou equisito de compas 19,13%
Outros 4,06%

O uso das cinco características da
compuação em nuvem é o início de
uma longa cadeia causal que leva ao
desempenho oganizacional.
As cinco características O cliene gealmene não em conole dieo sobe

da computação em nuvem o local exato dos recursos fornecidos, mas pode
especica a localização em um nível de absação
Manendo nossa abodagem de pesquisa,
mais alo, como país, esado ou daa cene.
pocuamos descobi não apenas se os
paricipanes usam ecnologias de compuação em
Elasticidade rápida: é possível provisionar e liberar a
nuvem, mas como eles usam as ecnologias. Paa
capacidade de forma elástica, para aumentar ou reduzir
isso, perguntamos sobre as cinco características
a escala apidamene com a demanda. Os ecusos
essenciais da compuação em nuvem, segundo
disponíveis para provisionamento parecem ser ilimitados
a denição do Insiuo Nacional de Padões e
e podem ser apropriados em qualquer quantidade a
Tecnologia (NIST, na sigla em inglês).
qualque momeno.
Autoatendimento sob demanda: os consumidores

Serviço mensurado: os sistemas de nuvem controlam
podem povisiona ecusos de compuação quando
e otimizam recursos automaticamente por meio da
necessáio, auomaicamene, sem ineação humana
medição em um nível de absação apopiado ao ipo
do povedo.
do serviço, como armazenamento, processamento,
lagua de banda e conas de usuáio aivas. É possível
Amplo acesso à rede: os ecusos êm ampla
monitorar e controlar o uso de recursos, além de gerar
disponibilidade, e os consumidores podem acessá-los
elaóios sobe a anspaência no uso.
po váios clienes como smarphones, ables, lapops
e esações de abalho.
Pooling de recursos: os ecusos do povedo são

agrupados em um modelo multilocatário, com recursos
ísicos e viruais atribuídos dinamicamente sob
demanda.

Ese elaóio valida a pesquisa DORA dos ês
anos anteriores, concluindo que a presença dessas
cinco caaceísicas em uma oganização em
impacto positivo sobre o desempenho operacional
e da enega de sofwae. Também consaamos
que as características melhoram o desempenho
organizacional porque iniciam processos que afetam
a oganização de maneias posiivas. Demonsa as
cinco caaceísicas da compuação em nuvem é a
primeira etapa de uma longa jornada que aumenta o
desempenho oganizacional.
Em 2022, percebemos que as equipes aproveitam os

dieenciadoes da compuação em nuvem cada vez
mais. Pelo quaro ano consecuivo, houve cescimeno
na adoção das cinco caaceísicas. O pool de
ecusos eve o maio aumeno, de 14%. A elasicidade
rápida, que era o segundo atributo mais usado ano
passado, eve o meno aumeno, de 5%.
Alteação
NIST 2021 2022
percentual
Acesso amplo à rede

74% 80% 8
Elasticidade rápida
Autoatendimen-
to sob demanda
77%
73%
81%
78%
5
7
14%
de aumento no pool
de recursos
Serviço mensurado 78% 83% 7
Pool de recursos 73% 83% 14

Dave Stanke
SRE e DevOps A conabilidade é essencial
As equipes de tecnologia bem-sucedidas fazem mais A adoção da SRE esá disseminada nas equipes que
pela oganização do que enega código. Mais aé do que entrevistamos: a maioia dos paricipanes usa uma ou
enega código de qualidade. Elas ambém gaanem que mais das páicas que mencionamos. Nessas vaiadas
os serviços entregues estejam disponíveis, tenham bom equipes, os dados evelam uma elação suil ene a
desempenho e sejam consistentes com as expectativas conabilidade, a enega de sofwae e os esulados:
dos usuáios ao longo do empo. A conabilidade é uma quando há baixa conabilidade, o desempenho da
medida multifacetada da capacidade da equipe que
enega de sofwae não é um bom indicado do sucesso
cumpi esses compomissos. Ese ano, coninuamos
oganizacional. No enano, com uma conabilidade
nossa análise sobe a conabilidade como ao na
melho, começamos a ve uma inuência posiiva da
enega de sofwae e nas opeações.
enega de sofwae sobe o sucesso comecial.
A engenhaia de conabilidade do sie (SRE) é uma inuene
abodagem de opeações. Ela eve oigem no Google e
hoje é paicada em muias oganizações. A SRE pioiza
apendizado empíico, colaboação muliuncional, amplo Sem a conabilidade, o
uso de auomação e o uso de écnicas de medição como
desempenho da entrega
objeivos de nível de seviço (SLOs). Ouas páicas
modenas de opeações usam méodos semelhanes, mas
de sofwae não é um
com nomes dieenes. Po isso, paa avalia a exensão das bom indicador do sucesso
práticas da forma mais objetiva possível, tivemos o cuidado oganizacional.
na pesquisa em usar uma linguagem neutra e descritiva no
exo apesenado aos paricipanes. Também coleamos
dados sobe os esulados da engenhaia de conabilidade:
na medida em queas equipes conseguem cumprir as
meas da áea. O modelo pediivo inclui as enadas e os
esulados (páicas de SRE e esulados de conabilidade),
bem como ouas capacidades de DevOps.

O investimento na SRE melhora
a conabilidade, mas apenas
depois de um cero limia de
adoção.
Esse enômeno é consisene com o uso do amewok ou aé mesmo egessões. Mas aqueles que pesisem
"magem de eo" da SRE: quando um seviço não é diane desses desaos alcançam níveis susenados e
conável, não há vanagem paa os usuáios em envia enovados de conquisas elevadas.
código apidamene nesse conexo ágil.
Nossa pesquisa ese ano mosa um padão de cuva J nas
Como os engenheios de conabilidade do sie dizem há equipes de ecnologia que esudamos. Quando as equipes
empos, a conabilidade é o "ecuso" mais imporane de azem menos páicas de engenhaia de conabilidade (o
qualque poduo. Nossa pesquisa susena a obsevação que sugee que esão no início da jonada de adoção da
de que cumprir as promessas aos usuários é necessário SRE), essas páicas não são bons indicadoes de melho
paa que a melhoa na enega de sofwae gee conabilidade. No enano, conome adoam mais a SRE,
beneícios paa a oganização. as equipes chegam a um pono de inexão em que o uso
dela passa a ser indicador da conabilidade e, po sua vez,
Obseve a cuva J do desempenho oganizacional.
Quais desaos esão à espeia no caminho paa a

conabilidade? Na publicação "Enepise Roadmap to
SRE" da O'Reilly,¹ James Bookbank e Seve McGhee,
colaboadoes da pesquisa DORA, eeem sobe
a expeiência deles na implemenação da SRE em
oganizações esabelecidas e ecomendam "obseva
a cuva J da mudança". Descia no elaóio Sae o
DevOps de 2018, a "curva J" é um fenômeno em que as
ansações oganizacionais cosumam mosa sucesso
no início, seguido por períodos de retorno diminuído
¹ https://sre.google/resources/practices-and-processes/
enterprise-roadmap-to-sre/

Equipes conáveis ciam
seviços conáveis:
a cultura de equipe
generativa indica melhor
conabilidade.
As equipes que esão começando a jonada paa Investimento em

a SRE precisam estar preparadas para revezes pessoas, pocessos e
ao longo do caminho. É uma esada longa, que ferramentas
exige o realinhamento da cultura, dos processos
e das ferramentas aos novos princípios A conabilidade é um esoço humano, e a SRE
noreadoes. Mas as equipes podem e é exemplo disso em muias omas. Um dos
cereza de que, com empo e a coninuação do pincípios da abodagem é que a pecepção
invesimeno, há ala pobabilidade de sucesso. dos usuáios é a vedadeia medição da
conabilidade, em vez de dados inenos de
Altos monioameno. Enão não é supesa que a

conabilidade seja conduzida po uma dinâmica
posiiva de equipe. Consaamos que as equipes
Resulados de conabilidade
com culua geneaiva, que exibe conança e

colaboação, são mais popensas a paica a SRE
e a alcança bons esulados de conabilidade.
As equipes estáveis, com membros consistentes
ao longo do tempo, também oferecem maior
conabilidade aos seviços volados ao usuáio.
E, como no DevOps de forma geral, incrementar
Baixos
o esforço humano com processos e ferramentas
Baixa Adoção de páicas de SRE Alta ajuda na engenhaia de conabilidade. Páicas

como o uso da compuação em nuvem e da
As equipes que persistem além do início da adoção da SRE
inegação conínua são bons indicadoes de
alcançam melhores resultados de confabilidade.
melhoes esulados de conabilidade.

Eric Maxwell
Recursos técnicos de DevOps

Este ano, analisamos várias capacidades técnicas para entender
os esulados geados po cada páica. Consideamos duas
ases amplas do desenvolvimeno de sofwae: o "loop ineno",
que inclui aeas de desenvolvedoes como pogamação,
ese e envio ao conole de vesões, e o "loop exeno", que
inclui atividades como mesclagem de código, análise de código
auomaizada, execução de ese, implanação e lançameno.
Inega
Pogama
Enviar
Implana
Loop interno Loop externo Testar
Testar Criar
Lançar

Equipes com alto
desempenho que cumprem
as meas de conabilidade
êm pobabilidade 1,4 vez
maio de usa CI.
Nossa pesquisa mostra que as empresas que se

sobressaem no desenvolvimento dos loops interno De ao, os paricipanes que usam as capacidades
e externo conseguem enviar código de maneira acima mais do que a média êm desempenho
mais ápida e mais conável. As capacidades que oganizacional 3,8 vezes melho que aqueles que não
mais conibuem paa o alo desempenho são as usam.
conole de vesões, inegação conínua, enega

conínua e aquieua com acoplameno exível. Integação contínua
A inegação conínua (CI) az pare do pocesso de

desenvolvimeno do loop exeno. Ela cia auomaicamene
As equipes com alto
um areao e execua váios eses auomaizados paa
desempenho que cumprem as
cada conmação, paa veica se o código esá pono
metas de conabilidade têm:
paa implanação. O pocesso eona eedback ápido
33% maio pobabilidade de usa

e auomaizado aos desenvolvedoes, que podem enão
o controle de versões abalha com maio conança. A CI é um ao essencial paa

leva o código da esação de abalho do desenvolvedo aé
39%
a podução. Como nos anos aneioes, consaamos que a
maio pobabilidade de CI aumena o desempenho da enega. As equipes com alto
patica a integação desempenho, que cumpem as metas de conabilidade,
contínua
têm pobabilidade 1,4 vez maio de usa CI que as demais.
46% maio pobabilidade de

praticar a entrega contínua
Nese ano, analisamos melho a oua pare do pocesso
de desenvolvimento do loop externo, a entrega contínua,
que vamos discui em um póximo capíulo. Mas anes
40%
maio pobabilidade de
vamos ve mais de pero um componene complemena
te sistemas baseados
da inegação conínua: o desenvolvimeno baseado na
em uma arquitetura com
linha pincipal.
acoplamento exível

Desenvolvimento baseado em linha As pessoas com mais de 16 anos de expeiência que
principal usam o desenvolvimento baseado em linha principal

alcançam os beneícios da páica e êm esas
O desenvolvimento baseado em linha principal é a características:
prática de mesclar código continuamente na linha

pincipal e evia amicações de ecusos de longa  Maior desempenho geal maio da enega de sowae
duação. Há anos já se consaou que a páica,  Menor quanidade de abalho não planejado
consideada um complemeno da inegação conínua,  Menor popensão a eos
acelea a velocidade da enega de sofwae.  Menor axa de alhas nas aleações
Devido à mudança demogáca nese ano em emos O povável moivo paa isso é que a implemenação do
de empo de expeiência possional, pecebemos desenvolvimento baseado em linha principal exige mais
que a expeiência é imporane na implemenação do páicas. Quando as equipes não êm egas ígidas
desenvolvimeno baseado em linha pincipal. No ano contra o abandono de linhas principais quebradas,
passado, 40% dos paricipanes amaam e mais não usam amicações de código esias e azem
de 16 anos de expeiência possional, caegoia que evesões auomáicas de código que quebam a linha
epesenou apenas 13% ese ano. Coninuando com o pincipal, ca mais diícil segui essa páica.
tema "a entrega depende", vemos que as pessoas com
menos expeiência êm menos esulados posiivos No entanto, a presença do desenvolvimento
com o desenvolvimeno baseado em linha pincipal. baseado na linha principal mostra um impacto
Consaamos que elas êm esas caaceísicas: positivo sobre o desempenho organizacional em
geal.
 Menor desempenho geal da enega de sowae
 Maior quanidade de abalho não planejado
 Maior popensão a eos
 Maior axa de alhas nas aleações

Frank Xu
Entrega contínua No ano passado, analisamos as capacidades

técnicas de DevOps que indicam a prática de
A entrega contínua (CD) é uma prática de CD pela equipe. Consaamos que aoes como
desenvolvimeno de sofwae que: aquieua com acoplameno exível e eses e
inegações conínuos esão ene os indicadoes
1. Pemie que a equipe implane sofwae
mais ores. Nese ano, além de analisa os
na podução ou paa os usuáios nais
fatores que motivam o uso da CD, analisamos e
a qualquer momento
idenicamos os eeios da CD sobe os esulados
2. Gaane que o sofwae eseja pono
de desenvolvimento, tanto sozinha quanto na
paa implanação em odo o ciclo de vida,
ineação com ouas capacidades de DevOps.
mesmo duane a ciação de ecusos
3. Cia um loop de eedback ápido paa que
A CD melhora o desempenho da
a equipe veique se o sisema em boa
entega de sofwae
qualidade e esá pono paa implanação,
Assim como nas consaações do ano passado, o
além de pioiza a coeção de poblemas que
uso da CD indica melhor desempenho na entrega de
bloqueiam o desenvolvimento
sofwae, ano sozinha quano combinada a ouas
capacidades de DevOps. As equipes que usam muio a
A enega conínua não implica necessaiamene
CD êm maio pobabilidade de e ala equência de
em implanação conínua, a páica em que cada
implanação de código na podução e meno empo
build do sofwae é implanado auomaicamene.
de lead paa mudanças e paa esauação de seviço.
É peciso apenas que o build eseja pono paa
implanação a qualque momeno.

As equipes que combinam o controle Práticas técnicas e CD
de vesões e a enega conínua êm Nossa pesquisa mostrou regularmente que há um amplo
conjuno de capacidades écnicas que apoiam a CD.
pobabilidade 2,5 vezes maio de
Neste ano, analisamos o que acontece quando algumas
ter alto desempenho da entrega de dessas capacidades individuais são usadas com a
sofwae do que aquelas que usam CD. Consaamos que o desenvolvimeno baseado em
apenas uma das páicas. linha pincipal e a aquieua com acoplameno exível,
quando juntas com a CD, podem prejudicar o desempenho
da equipe. Po exemplo, vimos evidência de que as equipes
que adoam as aquieuas com acoplameno exível e a
Além disso, a pobabilidade de os paricipanes eem maio
CD em conjuno êm pobabilidade 43% maio de anecipa
desempenho da enega de sofwae é 2,5 vezes maio
mais eos do que a média, em compaação às equipes que
quando a equipe deles ambém adoa o conole de vesões.
só adoaam a CD. Esses eos incluem, po exemplo, alhas
A CD pode aumenta o tabalho temporárias de produtos, vulnerabilidades de segurança
não planejado e edução signicaiva de desempenho em sevidoes.
Os dados sugerem que a entrega contínua faz os Esses eeios, que exigem maio invesigação, aponam
desenvolvedores gastarem mais tempo com retrabalho ou a exisência de alguma icção nas equipes que esão
com abalho não planejado. Uma hipóese paa explica melhoando. A icção pode esa elacionada à cuva J da
isso é que os desenvolvedores costumam criar aplicativos ansomação, em que as equipes êm melhoias no início,
de maneia ieaiva quando os loops de eedback são mais mas esmoecem depois que passam dos iens mais áceis.
inegados. Po isso, eles podem considea que algumas É peciso compomeimeno paa alcança odo o poencial
mudanças ieaivas são abalho não planejado na mesma da melhoia. Ao melhoa qualque capacidade, como a CD,
pare do sofwae. Esse abalho pode se, ao mesmo observe os efeitos sobre a equipe e o desempenho
empo, não planejado e moivado pelo eedback de uma em geal.
implanação aneio.

David Farley
Arquitetura com
acoplamento exível
Os sisemas com acoplameno exível são imporanes
paa a ecácia de equipes e oganizações. Isso não
está restrito a sistemas baseados na nuvem ou em
micosseviços. Tem a ve com a capacidade de muda
da oganização. A acilidade com que uma oganização
consegue muda um sofwae de maneia segua
e conane é indicado da qualidade do sofwae.
Com uma aquieua com acoplameno exível,

as equipes conseguem fazer o seguinte:
• Faze gandes mudanças no design do sisema
sem esperar que outras equipes mudem outros
sistemas
• Recebe eedback mais ápido po meio de eses
independentes e sob demanda com menor custo
de coodenação
• Implana código com empo de inaividade
irrisório
No relatório deste ano, perguntamos aos

paricipanes se o sofwae ciado po eles é
baseado em uma arquitetura com acoplamento
exível. Os esulados são iniganes e mosam
divesas associações posiivas ene pesença
desse tipo de arquitetura e o desempenho das
equipes em váias dimensões.

Os beneícios de uma aquitetua geenciando cenenas de seviços. Mas o acoplameno
com acoplamento exível exível é mais do que uma simples medição da conagem de
seviços no sisema. Os componenes de uma aquieua
As equipes que ciam sofwae com aquieuas com acoplameno exível podem se implanados de
com acoplameno exível esão mais bem maneia independene. Com essa independência, as equipes
posicionadas para ter bom desempenho em conseguem desenvolver, testar e implantar serviços sem os
esabilidade, conabilidade e capacidade de alos gasos de coodenação ene as equipes.
pocessameno. Essas equipes ambém êm
No mundo eal, o acoplameno exível não esá esio a
maior probabilidade de recomendar a empresa
um esilo de aquieua. Taa-se da capacidade de aze
delas a um amigo ou colega.
mudanças em uma pare do sisema sem que elas aeem
É comum que sofwaes que usam uma aquieua
ouas pares. Dessa oma, as oganizações podem dividi
de acoplameno exível sejam ciados po equipes
o trabalho para que cada equipe progrida sem precisar
que implementam na nuvem e usam arquitetura de
coodena com as demais.
micosseviços.
Na nossa expeiência, as equipes que pecisam de
eses de inegação poundos com ouos seviços
paa cona no sofwae anes da implanação ainda não
As equipes que criam
alcançaam o acoplameno exível. Paa isso, as equipes
sofwae com aquieuas com
pecisam melhoa as ineaces e o isolameno ene os
acoplameno exível esão mais sisemas. Uma maneia ecaz de melhoa as ineaces
bem posicionadas para ter bom e o isolamento é melhorar a capacidade de teste dos
desempenho em estabilidade, seviços e dos componenes. Quando o design pemie

esa seviços isoladamene, a ineace em acoplameno
conabilidade e capacidade
exível po denição.
de pocessameno.

Também constatamos que as equipes coesas Surpresas nos resultados
e estáveis que usam arquitetura com acoplamento
exível são mais popensas a usa páicas de A pesquisa deste ano revelou que a arquitetura com
desenvolvimeno de sofwae que incenivam acoplameno exível pode conibui paa o esgoameno
e apoiam a melhoia conínua. Po exemplo, páicas nas equipes. Essa é uma supesa que conaia as
de SRE como deni meas de conabilidade paa consaações dos anos aneioes. Nossa análise mosa
priorizar o trabalho ou revisar regularmente essas que as equipes esáveis com uxo live de inomações
meas com base em evidências auxiliam na êm meno nível de esgoameno. A culua geneaiva
aquieua com acoplameno exível. de Westrum e a estabilidade da equipe promovem
a aquieua com acoplameno exível e diminuem
Nas oganizações com essas aquieuas, é mais o esgoameno, enão esa é uma claa conadição.
ácil adiciona uncionáios, poque as equipes não É peciso mais pesquisa paa chega a conclusões
precisam se coordenar e podem aumentar de forma deniivas.
independene.
Ao mesmo empo, quando uma oganização consolidada
Em esumo, o impaco do acoplameno exível dos de seguança dene e conola os equisios da áea, as
seviços de sofwae vai além do aspeco écnico. equipes podem e maio diculdade paa desacopla o
Ele também afeta os aspectos sociotécnicos do sofwae delas das demais equipes. O ao demonsa mais
desenvolvimeno. O acoplameno é a base da Lei de ainda o benefício de transferir a segurança para a equipe
Conway, a ideia de que os sisemas de design de uma mais esponsável pelo aplicaivo (cona ambém: Po
oganização espelham a esuua de comunicação que a seguança da cadeia de supimenos é imporane).
dela. Sisemas com acoplameno mais exível indicam Essa é uma das formas mais sutis de acoplamento nas
oganizações com acoplameno mais exível, com oganizações. Os dados que coleamos dizem espeio à
desenvolvimeno mais disibuível e maleável. seguança, mas a consaação povavelmene vale ambém
paa ouas unções cenalizadas. Quando anseem as
decisões sobe seguança e ouas unções cenalizadas
às equipes, as oganizações se apoximam dos beneícios
do uso da aquieua com acoplameno exível.

Daniella Villalba
Cultura
"Foi assim que sempe zemos as coisas aqui."
Povavelmene as pessoas já epeiam essa

frase inúmeras vezes, em diversos setores, para
desceve como a oganização delas lida com
desaos e oporunidades.
Cada oganização em uma culua pópia, e nossa

pesquisa mostrou que a cultura é fundamental
paa o sucesso da oganização e o bem-esa dos
uncionáios.
Também é um aspecto essencial do DevOps, já

que esse método trata de ferramentas, práticas
ecolaboação ente pessoas para desenvolver
e enega sofwae de maneia ápida, conável
e segua. Enende os aoes que aeam a culua
da oganização ajuda a lideança a enena os
desaos nessa áea. Po isso, pomove uma
cultura saudável deve ser uma prioridade para as
oganizações. Se oem ignoados, os desaos
da culua alvez impedião a disseminação das
páicas de DevOps.

Neste ano, continuamos usando a tipologia ou paológica. Os uncionáios das oganizações
organizacional de Westrum para medir a integridade da com uma culua geneaiva êm maio popensão a
culua das oganizações. Além disso, expandimos nossa perence a equipes esáveis, poduzi documenação
denição de culua, medindo oaividade da equipe, de alta qualidade e gastar o tempo com trabalho
condições exíveis de abalho, pecepção da adoção imporane.
oganizacional e esgoameno.
Rotatividade da equipe
Os dados da pesquisa deste ano convergem com
as consaações aneioes de que o desempenho Invesigamos a oaividade da equipe e consaamos
organizacional é afetado pelo tipo de cultura em uma que há maio popoção de equipes estáveis
oganização. Em especíco, uma cultura generativa (cuja composição não mudou muio nos úlimos
está associada a melhor desempenho organizacional 12 meses) nas oganizações com alo desempenho.
em elação às oganizações com culua buocáica A rotatividade constante pode prejudicar a
produtividade e o moral, já que os novos membros
da equipe pecisam de empo paa a inegação.
E aqueles que cam
Cultura organizacional de Westrum
Patológica Burocrática Generativa

Voltada ao poder Voltada a regras Voltada ao desempenho
Baixa coopeação Coopeação modesa Ala coopeação

Os mensageios são aacados Os mensageios são ignoados Os mensageios são einados
Evita responsabilidades Limita responsabilidades Comparilha esponsabilidades
Conciliações são desencoajadas Conciliações são oleadas Conciliações são incenivadas
Falhas levam à busca de um bode Falhas levam à jusiça Falhas levam a invesigações
expiatório
Novas ideias são desuídas Novas ideias causam problemas Novas ideias são implanadas

precisam se adaptar às mudanças na carga de trabalho presencial ou híbrido está ligada ao maior desempenho
e na dinâmica da equipe. Além disso, nossa pesquisa oganizacional. Consaamos que as oganizações com
mosou que as equipes esáveis amam poduzi maior exibilidade paa os uncionáios êm melho
mais documenação de qualidade do que aquelas desempenho organizacional do que aquelas com
com ala oaividade. Paa equipes que lidam com condições mais ígidas. É uma evidência de que da
mudanças constantemente, é difícil manter as práticas libedade aos uncionáios paa modica as condições
que levam à documenação de qualidade. de trabalho quando necessário gera benefícios diretos e
angíveis paa as oganizações.
Esgotamento
As oganizações com alo
desempenho costumam O esgotamento é um sentimento de medo, apatia
e condições de abalho ou cinismo em elação ao abalho. Quando soem

esgoameno, as pessoas não esão apenas
exíveis.
desmoivadas ou exausas. Elas ambém cosumam e
meno saisação no abalho, o que pode aumena a
oaividade. O esgoameno esá associado a váios
Condições exíveis de tabalho problemas de saúde psicológica e física, como maior
isco de depessão e ansiedade, doença cadíaca e
Consideando que váias oganizações adoaam pensamenos suicidas.¹
condições exíveis de abalho desde o sugimeno da
pandemia de COVID-19, invesigamos se a libedade No ano passado, medimos o esgotamento no contexto
dos funcionários de escolher entre trabalho remoto, da pandemia de COVID-19 e consaamos que a culua
geneaiva esá associada a um índice meno do enômeno.
¹ Maslach C, Leiter MP. Understanding the burnout experience: recent research and its implications for psychiatry.
World Psychiatry. 2016 Jun;15(2):103-11. doi: 10.1002/wps.20311. PMID: 27265691; PMCID: PMC4911781.

A pecepção dos
uncionáios sobe a
Os modelos exíveis de oganização
abalho esão associados
a menor índice de Po úlimo, invesigamos a pecepção da adoção
da lideança. Paa isso, pedimos que as pessoas
esgotamento e aumento
estimassem o grau de apoio que as equipes delas
na probabilidade de o devem ecebe nos póximos 12 meses. Os esulados
funcionário recomendar mosam que a maio pecepção da adoção da
a equipe como um bom lideança (po exemplo, mais apoio nanceio, mais
alocação de ecusos, paocínios) esá associada a
luga paa abalha.
oganizações com alo desempenho.
Também pedimos que as pessoas estimassem a
Nese ano, eplicamos essa consaação e expandimos pobabilidade de have uma violação de seguança
nossa compeensão sobe o assuno, mosando que ou uma ineupção complea nos póximos 12
equipes esáveis e condições exíveis de abalho meses. Segundo os esulados, as pessoas que
ambém esão associadas a menos esgoameno. abalham em oganizações com bom desempenho
Também medimos o Ne Pomoe Scoe (NPS) das esão menos popensas a esima a ocoência de
equipes, que indica se as pessoas recomendam as eos gaves. Elas êm uma pespeciva mais
equipes a amigos ou colegas. Consaamos que o NPS posiiva da oganização. Também consaamos
das equipes esá associado à pecepção da adoção que as pessoas que abalham em oganizações
da lideança. Em um eexo das consaações sobe com alo desempenho de sofwae e de
o esgotamento, descobrimos que, quando há cultura entrega não costumam achar que as
geneaiva, equipe esável e condições exíveis de práticas atuais delas precisam de
abalho, as pessoas esão mais popensas a ecomenda mudanças para melhorar os
as equipes aos demais. esulados comeciais.

Algumas palavas sobe Coninuamos a enaiza a imporância da culua,
epesentação mas sabemos que mudar ou mesmo melhorar a
culua de uma oganização não é uma aea ácil.
Constatamos que os funcionários de grupos sub- Recomendamos que as oganizações enem pimeio
epesenados amam gasa mais empo com abalho enende as expeiências dos uncionáios paa
não planejado, que esejam em oganizações com depois investir recursos para solucionar problemas
alo ou baixo desempenho. Também consaamos que culuais como pare da ansomação do DevOps.
esses uncionáios êm maio nível de esgoameno
do que aqueles que não perencem a gupos sub-
epesenados. Os lídees de equipe pecisam e
cuidado com o risco desse desequilíbrio e alocar o
abalho po igual ene os membos.
Em conjuno, as consaações essalam a imporância

de criar um ambiente saudável e inclusivo para os
uncionáios, ano na oganização quano na equipe.

04
Por que a segurança John Speed Meyers Todd Kulesza
da cadeia de
suprimentos
é imporante mudou udo isso. Quando alguém consegue
invadir milhares de grandes empresas e redes
Em novembo de 2020, poucos possionais de govenamenais sem chama a aenção, usando
tecnologia suspeitavam que uma crise na segurança aualizações de sofwae do ipo cavalo de oia,
da cadeia de supimenos de sofwae esava se os empos mudam apidamene.
apoximando. A Open Souce Secuiy Foundaion,
sucessora de iniciativas anteriores, havia sido fundada Hoje entendemos que o tópico da segurança na
paa cuida da seguança de sofwaes de código cadeia de supimeno de sofwae é essencial.
abero. Havia alguns pontos imporanes para lidar com Talvez não no jana em amília, mas ceramene
o poblema, mas o ópico não esava nas manchees na sala do conselho.
dos pincipais jonais. Um gande aaque, SolarWinds,
ACCELERATE State of DevOps 2022 Segurança da cadeia de suprimentos 42

01
Há váias iniciaivas, e gande pare do seo de A adoção já começou: as práticas de
sofwae se compomeeu a eoma as pópias segurança da cadeia de suprimentos de
práticas de segurança nessa área e a melhorar a sofwae da SLSA e da SSDF já êm uma
seguança dos elemenos comuns em código abero. modesa adoção, mas ainda há espaço paa mais.
02
Neste capítulo, vamos falar sobre duas iniciativas: As culturas mais saudáveis saem na
Supply Chain Levels o Sofwae Ariacs (SLSA, se frente: a cultura organizacional é um
ponuncia "salsa") e NIST Secue Sofwae Developmen moivado imporane paa as páicas
Famewok (SSDF). Ambas oeecem váias medidas de seguança de desenvolvimeno de sofwae.
de defesa para impedir que invasores adulterem os Com maio conança, as culuas "sem culpa" esão
pocessos de podução de sofwae e passem pelas mais propensas a estabelecer práticas de SLSA e
deesas da ede com aualizações maliciosas. SSDF do que as culuas oganizacionais com baixa
conança.
Mas qual é o gau de adoção das páicas de
03
seguança da cadeia de supimenos de sofwae Existe um ponto de integação cucial:
da SLSA e da SSDF? Quais páicas pecisam a adoção dos aspecos écnicos da
de ajuda paa aumena a adoção e quais já são segurança da cadeia de suprimentos de
amplamene usadas? Aé hoje, não havia esposas sofwae paece depende do uso de CI/CD, que
sisemáicas paa essas pegunas. Apesenamos gealmene az a plaaoma de inegação paa
algumas respostas iniciais derivadas de entrevistas muias dessas páicas.
com cenenas de possionais de sofwae sobe
04
as páicas que eles usam nessa áea. Há quao Há beneícios inespeados: além
consaações que se desacam: da edução do isco, as páicas
de seguança melhoes êm ouas
vanagens, como edução do esgoameno.

O que as empresas
fazem hoje para evitar
as vulneabilidades de
segurança O amewok SLSA, na vesão 0.1 aualmene,
descreve uma série de práticas de integridade da
cadeia de supimeno de sofwae, associadas
Paa enende melho o que as oganizações azem
a "níveis". Os níveis mais alos coespondem a
hoje paa idenica e coigi vulneabilidades de
maio gaania de seguança. Pegunamos aos
seguança no sofwae, adicionamos mais de 20
paricipanes sobe váias das páicas associadas
pegunas à pesquisa dese ano. Elas se dividem em
à SLSA. A peguna ea: "As páicas a segui esão
duas categorias:
bem esabelecidas paa a aplicação ou o seviço
pincipal em que você abalha?". A abela 1 mosa
• Pegunas em que o paricipane pecisa concoda
as denições das páicas de SLSA usadas na
ou discoda com uma amação. Po exemplo,
pesquisa.
"Minha oganização em um méodo ecaz paa
corrigir ameaças à segurança" ou "Eu tenho acesso
A SSDF, aualmene na vesão 1.1, é um conjuno de
às ferramentas necessárias para realizar testes de
páicas que ajudam as oganizações a disibui
seguança".
sofwae com menos vulneabilidades, bem como
minimizar o impacto potencial das vulnerabilidades
• Pegunas paa medi se páicas de seguança
esanes. Em vez dos "níveis" da SLSA, as páicas
esão bem esabelecidas nas oganizações. Po
da SSDF são divididas em quao caegoias:
exemplo, "Os builds
pepaação da oganização, poeção do sofwae em
são denidos apenas po scips e nada mais"
desenvolvimeno, podução de sofwae poegido
ou "As vesões de podução são ciadas em um
e esposa ecaz às vulneabilidades descoberas.
sisema cenalizado de CI/CD, nunca na esação
Pegunamos aos paricipanes o quano eles
de abalho de um desenvolvedo". Usamos a
concodam (ou discodam) de amações que
escala "esabelecido/não esabelecido" poque
escevem as páicas da SSDF. A abela 2 mosa um
eses iniciais mosaam que os paricipanes
esumo das pegunas.
tendem a concordar com algumas perguntas
elacionadas à seguança. Mas as pegunas sobe
SSDF oam omuladas de oma mais naual,
com a escala de esposa concodo/discodo.

Prática da SLSA Denição da pesquisa
As vesões de podução são ciadas em um sisema cenalizado de

CI/CD centralizadas
CI/CD, nunca na esação de abalho de um desenvolvedo
Pesevação do his- As evisões e os especivos hisóicos de aleações são pesevados po peíodo indenido
tórico
Scipt de build Os builds são oalmene denidos po scips e nada mais
Isolamento Os builds são isolados e não podem ineei em builds simulâneos ou poseioes
Arquivos de texto de As denições e as conguações de build são denidas em aquivos de exo,
build amazenados em um sisema de conole de vesões.
Metadados de parâ- Os meadados de build (po exemplo, dependências, pocesso, ambiene)
metros eeenes a um areao conêm odos os paâmeos de build
Metadados de de- Os meadados de build (po exemplo, dependências, pocesso,
pendências ambiene) eeenes a um areao documenam odas as dependências
Geação de Os meadados de build (po exemplo, dependências, pocesso, ambiene) são geados
metadados pelo seviço de build ou po um geado de meadados que lê os dados daquele seviço
No build, as eapas não podem caega enadas dinamicamene (ou seja, odas
Bloqueio de entradas
as ones e dependências necessáias são coleadas anes)
Sem edição dos Os usuáios dos seviços de build não podem edia os meadados de
usuários build (po exemplo, dependências, pocesso, ambiene)
Os meadados de build (po exemplo, dependências, pocesso,
Disponibilidade dos
ambiene) esão disponíveis paa quem pecisa deles (po exemplo, em
metadados
um banco de dados cenal) e são enegues em um omao aceio
Análise por duas Duas pessoas de conança pecisam analisa cada aleação individual
pessoas no hisóico de uma evisão anes do envio
Assinatura dos meta- Os meadados de build (po exemplo, dependências, pocesso, ambiene) que
dados descevem a podução de um areao são assinados pelo seviço de build
Tabela 1: peguntas sobe SLSA na pesquisa

Obsevação: os paricipanes inham cinco opções paa cada peguna: não esá
estabelecido, um pouco estabelecido, moderadamente estabelecido, muito estabelecido e
oalmene esabelecido.

Prática da SSDF Denição da pesquisa
Avaliações de segu- Uma avaliação de seguança é ealizada paa odos os ecusos pincipais em que eu abalho
rança
Análise/teste contí- Realizamos continuamente análises e testes manuais ou automatizados do código de todas as
nuo do código novas vesões com supore, paa idenica ou conma a pesença de vulneabilidades que não
foram detectadas
Teste de segurança Eu ou outra equipe realizamos testes de segurança no início do processo de desenvolvimento de
inicial sofwae
Lidar com ameaças
Minha oganização em um méodo ecaz paa lida com ameaças à seguança
efetivamente
Integação à equipe
Os papéis de seguança são inegados à nossa equipe de desenvolvimeno de sofwae
de desenvolvimento
Exigência de docu- Nossa oganização em pocessos paa idenica e documena odos os equisios de seguança
mentos do sofwae que desenvolvemos ou adquiimos (incluindo de eceios e de código abero)
Revisão egula dos Os equisios de seguança são evisos a inevalos egulaes (uma vez po ano ou menos se
requisitos necessário)
Geação de Os meadados de build (po exemplo, dependências, pocesso, ambiene) são geados pelo
metadados seviço de build ou po um geado de meadados que lê os dados daquele seviço
Integação ao ciclo Na minha empesa, o poocolo de seguança de sofwae az pare do pocesso de
de desenvolvimento desenvolvimento
Pocesso padão em Na minha empesa, emos um pocesso padonizado paa lida com a seguança do sofwae em
todos os projetos diferentes projetos
Monitoramento dos Monioamos pemanenemene as inomações de ones públicas sobe possíveis
relatórios de segu- vulneabilidades no sofwae que usamos e nos componenes de eceios nesse sofwae
rança
Ter as ferramentas Tenho acesso às ferramentas necessárias para executar testes de segurança
necessárias
Tabela 2: peguntas sobe SSDF na pesquisa

Obsevação: Os paricipanes inham see opções paa cada peguno: discodo oalmene,
discodo, discodo um pouco, não concodo nem discodo, concodo um pouco, concodo e
concodo oalmene.

No geal, consaamos uma adoção elaivamene uma oganização é um bom indicado da mauidade das
ampla das práticas emergentes do setor, mas com páicas de seguança. Po isso, acediamos que, sem
muio espaço paa um maio esabelecimeno. essa peça essencial da infraestrutura, é muito difícil para
Po exemplo, 66% concodaam com a amação uma oganização gaani a execução consisene de
"Na minha empresa, o protocolo de segurança de veicações, lines e eses nos areaos de sofwae
sofwae az pare do pocesso de desenvolvimeno", ciados.
mas apenas 18% concodaam oalmene. As guas
1 e 2 mosam as esposas dos paricipanes às Além da CI/CD, ouas páicas bem esabelecidas são
pegunas sobe seguança. a pesevação indenida do hisóico do código (60%),
a denição de build apenas po meio de scips (58%),
Consaamos que o uso de sisemas de inegação o isolameno dos builds (57%) e o amazenameno das
conínua/enega conínua (CI/CD) paa vesões de denições de build no conole de vesões (56%). Po
podução é a páica mais bem esabelecida: 63% ouo lado, as duas páicas menos esabelecidas são
dos paricipanes concodam que ela esá "muio" ou a exigência de apovação de dois ou mais analisas
"compleamene" esabelecida. O ao de que a CI/ paa cada mudança no código (45%) e a assinaua
CD está no topo da lista está alinhado a pesquisas dos metadados de build para evitar ou detectar
anteriores sobre segurança, que constataram que a aduleações (41%).
maioia das oganizações implemena a veicação
de seguança no nível do aplicaivo como pare do
pocesso de CI/CD. Além disso, enevisas qualiaivas
sobre segurança, feitas em separado, mostraram que
a maioia dos desenvolvedoes não consegue execua
eamenas no local duane o desenvolvimeno. Da
mesma oma, o amewok SLSA usa os sisemas de
CI como pono de inegação cenal paa a seguança
da cadeia de supimenos. Segundo nossa análise
de modelo, que descevemos na póxima seção, a
pesença de CI em

Além das perguntas sobre as práticas estabelecidas, É óimo que a amação enha o meno nível
ambém pegunamos se os paricipanes concodam de concodância, mas o ao de que a maioia
ou discodam com algumas amações sobe a dos paricipanes ama que os pocessos de
seguança na oganização deles. A declaação com segurança atuais tornam o desenvolvimento
maio nível de concodância (81%) oi: "Monioamos lento sugere que há muito espaço para melhoria
pemanenemene as inomações de ones públicas nas eamenas e abodagens da seguança.
sobe possíveis vulneabilidades no sofwae que Nossa análise de modelo apoia jusica essa
usamos e nos componentes de terceiros nesse inepeação, mosando um eeio miso (poém
sofwae". Po ouo lado, a declaação com a meno pequeno) sobre o desempenho da entrega de
popoção de concodância (56%) oi sobe os sofwae.
impactos negativos das práticas de segurança no
desenvolvimeno de sofwae. A amação ea: "Os
pocessos de seguança de sofwae que exisem
na minha empresa tornam mais lento o processo de
desenvolvimeno dos aplicaivos em que abalho".

Não esá esabeleci-
Completamente ou Modeadamene
do ou pouco esta-
muito estabelecido estabelecido
belecido
CICD cenalizada
Pesevação do hisóico
Script de build
Isolameno
Campos de texto de build
Meadados de paâmeos
Meadados de dependências
Geação de meadados
Bloqueio de enadas
Sem edição dos usuáios
Disponibilidade dos metadados
Análise por duas pessoas
Assinatura dos metadados
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Pocenagem dos paricipanes
Figua 1. Estabelecimento das páticas da SLSA

Resposas na pesquisa sobe o esabelecimeno das páicas da SLSA. A maioia dos paricipanes
indicou cero gau de esabelecimeno de odas as páicas, mas poucos amaam que elas já esão
"compleamene" esabelecidas.

Concordo Não concodo nem discodo Discordo
Avaliações de seguança
Análise/ese conínuo do código
Teste de segurança inicial
Lidar com ameaças efetivamente
Idenicação ecaz de ameaças
Inegação ao desenvolvimeno
Exigência de documenos
Revisão egula dos equisios
Inegação ao ciclo de desenvolvimeno
Pocesso padão em odos os pojeos
Monioameno dos elaóios de seguança
Ter as ferramentas necessárias
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Pocenagem dos paricipanes
Figua 2. Estabelecimento das páticas da SSDF

Resposas na pesquisa sobe o esabelecimeno das páicas da SSDF. Assim como a SLSA, a
maioia dos paricipanes concodou que as oganizações deles seguem odas as páicas.

O que ajuda as empresas
a segui boas páticas de
segurança?
Os dados da nossa pesquisa sugerem que há vários
A segurança do aplicativo é apenas um aspecto do
fatores que tornam mais fácil para os engenheiros
desenvolvimeno de sofwae, uma das váias demandas
aze o cero pela seguança.
sobe o empo e a aenção dos desenvolvedoes. Taa
a seguança com ala icção pode gea usação O pincipal ao que consaamos não ea écnico, mas sim
nos desenvolvedoes e se inecaz, já que as pessoas cultural: as organizações próximas do grupo de cultura
eviam os ponos de icção. Po exemplo, segundo "generativa" de Westrum são mais popensas a estabelece
um conjunto de entrevistas com engenheiros de práticas de segurança conome a denição do amewok
sofwae possionais, o conao deles com as equipes SLSA¹. Alguns aspecos das culuas geneaivas são ala
de seguança ea limiado ao início ou ao m de um coopeação, comparilhameno de iscos e esponsabilidades
pojeo e havia diculdade na ineação ene eles. Nas e apende com os eos. Nossa hipóese é que essas
palavas de um paricipane: "Temos uma equipe de características geram várias práticas saudáveis de seguança.
segurança do aplicativo, mas eles nunca analisaram meu Po exemplo, inceniva os engenheios de sofwae a seem
código… Eu geralmente os evito, como a maioria dos mais proativos sobre a segurança da cadeia de suprimentos,
engenheios". recompensar pessoas de qualquer papel por atividades

de segurança, ou reduzir o risco que as pessoas veem em
Uma maneia de melhoa a seguança de sofwae é
denuncia possíveis poblemas de seguança.
reduzir as barreiras que impedem o seguimento das
páicas. Os desenvolvedoes com quem convesamos Em emos de ecnologia, ês dos mais imporanes
queem aze a coisa cera. Eles aé expessaam aoes da seguança esão elacionados à inaesuua.
usação com a pioidade que o lançameno de Isso az senido: se a inaesuua acilia a ealização de
ecusos em sobe a coeção de possíveis poblemas aeas como veicação de vulneabilidades ou análises
de seguança. Po exemplo, um paricipane de oua manuais de código, é mais provável que os engenheiros
pesquisa sobe seguança disse que o maio desao as usem. Consaamos especicamene que sistemas de
ea: "Tona isso uma pioidade. Não é sexy, não vende contole de código-onte, integação contínua e
poduos [e] não é um poblema aé que se one um
poblema".
¹ Um fator interessante é que essas mesmas pessoas não concordaram mais que as outras com as perguntas da NIST SSDF. A SLSA e a
SSDF tratam de aspectos diferentes da segurança de desenvolvimento de aplicativo, mas esperávamos que houvesse sobreposição entre
esses conjuntos de perguntas. Como mencionamos, é possível que haja um viés para as respostas "concordo" na escala da SSDF, o que
explicaria a diferença.

entega contínua estão associados a páticas da SLSA ferramentas de segurança no computador local
mais mes. Uma pare imporane disso é o momeno onaia o abalho mais ápido e eciene.
em que os poblemas de seguança chamam a aenção
dos desenvolvedoes, que é duane a CI segundo Os fatores culturais e tecnológicos que mencionamos
oua pesquisa. Gealmene a CI vem logo anes das acima são os pincipais paa a seguança, mas não os
evisões de código e inclui a execução de veicações de únicos. Alguns ouos aoes imporanes:
vulnerabilidade e de outras ferramentas, o que garante a • Flexibilidade nas condições de abalho (po
aplicação dos mesmos equisios de seguança a odas exemplo, a oganização aceia o abalho de casa?)
as conmações. Quando não há um sisema de build • Uso da nuvem, seja pública ou pivada
cenalizado, a veicação ca muio mais diícil. Po sua • Trabalho com um aplicativo ou serviço nativo da
vez, a ausência do conole de código-one ona diícil nuvem
e um sisema de build cenalizado. • Sentir que a empresa valoriza a equipe e
investe nela
Mas a veicação de seguança na CI/CD pode • Baixa oaividade na equipe
não se cedo o suciene paa os engenheios de • Tamanho da oganização (as maioes êm
sofwae. Em enevisas sobe seguança com ponuações de seguança mais alas)
desenvolvedores de aplicativo, eles disseram que a
Mas esses aoes paecem esa coelacionados à
veicação de seguança nas esações de abalho
culua geneaiva de Wesum (po exemplo, condições
deles poupaia empo e esoço. Duas siuações muio
exíveis de abalho, senimeno de valoização pela
ciadas: 1) sabe de anemão se uma dependência com
vulnerabilidades conhecidas está sendo usada, para oganização ou baixa oaividade da equipe) ou com
reavaliar se é necessário usá-la antes do build; e 2) o uso da CI/CD (po exemplo, abalha em aplicaivos
evia o longo empo de espea da CI, às vezes váias naivos da nuvem ou em uma gande oganização). Po
esses dados, acreditamos que a cultura organizacional
hoas, apenas paa conma se as mudanças auais
e os processos modernos de desenvolvimento (como
coigiam um poblema de seguança. Em ambos os
a inegação conínua) são os pincipais aoes paa
casos, os engenheios de sofwae disseam que uma
a seguança de desenvolvimeno de aplicaivo. As
"ineupção" de CI é necessáia, mas pode execua
as mesmas oganizações que queem aumena a seguança devem
começa po esses aoes.

Quais são os esultados das
boas páticas de seguança?
Quais beneícios as oganizações alcançam quando eliminam as ameaças à seguança, mas nossas evidências
melhoram as práticas de segurança do desenvolvimento sugerem que elas reduzem o risco à segurança das
de sofwae? Os dados da nossa pesquisa mosam oganizações.
que os paricipanes espeam menor chance de
violações de seguança, inteupções de seviço e
As páicas de seguança ambém êm impaco posiivo
degadação de desempenho quando as empesas
sobre os resultados de desempenho, mas com uma surpresa:
estabelecem mais páticas de seguança da cadeia
a CI em papel essencial. Quando a CI não é implemenada,
de supimentos. Da mesma forma, realizamos outra
as páicas de seguança não mosam efeito algum sobre
pesquisa na primeira metade de 2022 e constatamos
o desempenho da enega de sofwae. Mas, quando a CI
que o uso de eamenas como veicações de
é implemenada, as páicas êm um ore eeio posiivo
vulneabilidade duane a CI aumena a pobabilidade
sobe o desempenho. Isso signica que a CI é necessáia
de idenica vulneabilidades nas dependências de
para que as práticas de segurança tenham efeito positivo
sofwae. Os paricipanes que usam essas eamenas
sobe o desempenho da enega de sofwae. Além disso, as
êm o dobo de pobabilidade de idenica uma
páicas de seguança gealmene êm eeio posiivo sobe o
vulnerabilidade de segurança no próprio código ou nas
desempenho oganizacional, que é amplicado quando a CI
dependências. Resumindo: paece que as páicas da
esá bem esabelecida. O gáco abaixo mosa esse eeio.
SLSA e da SSDF uncionam bem. Não amamos que elas
CI acima da média 0,45% 0,66%
CI abaixo da média 0,33% 0,46%
Páicas de seguança abaixo da média Páicas de seguança acima da média

Páticas de seguança (elacionadas à SLSA)
popoção com o desempenho oganizacional acima da média

0,4 0,5 0,6

Além da edução na pecepção dos iscos de seguança,
os paricipanes ambém elaaam menos esgotamento
ene os membos da equipe e maio disposição de As ferramentas e os
ecomenda a oganização como bom luga paa processos que ajudam a
tabalha. Essas consaações mosam como a incorporar práticas seguras
segurança é uma tarefa a mais para os engenheiros de
no uxo de abalho aual
sofwae. As eamenas e os pocessos que ajudam a
incopoa páicas seguas no uxo de abalho aual
de desenvolvimento
de desenvolvimeno (em vez de abalho não planejado (em vez de abalho não
ou pânico quando uma ameaça é descobera) são uma planejado ou pânico
oma de eduzi os iscos e aumena a saisação dos
quando uma ameaça é
desenvolvedoes.
descobera) são uma
Em conjuno, as evidências sugeem que equipes forma de reduzir os riscos
saudáveis e com bom desempenho tendem também e aumena a saisação
a te boas páticas de seguança, amplamente dos desenvolvedoes.
esabelecidas. Mas, como já noamos, ainda há espaço
paa melhoia. Segui amewoks como a SLSA ou a
SSDF, po si só, não melhoa as méicas de culua e
de desempenho que medimos. Mas esá clao que a
seguança não pecisa vi em oca de ouas pioidades
no desenvolvimeno.

05
Surpresas Derek DeBellis
Embora o tema de cada relatório seja as respostas esponsáveis po coodena ou oiena a implanação
da pesquisa naquele ano, procuramos entender as das páicas. Oua possibilidade é que houve uma
consaações no conexo de odo o caálogo de mudança no seo ou no mundo. O que uncionava
relatórios State of DevOps e pesquisas adjacentes onem não necessaiamene vai unciona amanhã. Po
(po exemplo, sobe esgoameno e culua). Tesa a exemplo, forças macroeconômicas e mais um ano à
conabilidade desses eeios po meio da eplicação é somba da pandemia de COVID-19 podem e mudado
um aspeco essencial do pogama de pesquisa. Dessa a ísica do DevOps. Po úlimo, mudanças suis no que
forma, podemos ajustar nossas teorias de acordo com incluímos no nosso modelo podem ter alterado as
os dados e enende a evolução ou o sugimeno de elações ene as vaiáveis.¹
endências.
Ese ano, enconamos algumas supesas. Há muios

moivos possíveis paa isso. Na amosa dese ano, há
mais pessoas no início da carreira do que em relatórios
aneioes. Uma inepeação é que há mais pessoas
diretamente responsáveis por implementar as práticas
e as capacidades técnicas, em vez de pessoas
¹ "Book of Why", de Judea Pearl, e "Statistical Rethinking",

de Robert McElreath, apresentam exemplos incríveis que
mostram como a inclusão ou a retirada de fatores dos
modelos estatísticos afeta o resultado.
ACCELERATE State of DevOps 2022 Surpresas 55

01
Uma consaação inespeada ou oa da hipóese az Obsevamos com equência que o
diculdades paa os pesquisadoes na hoa de esceve desenvolvimento baseado em linha principal
o elaóio. Exise o isco de que a consaação seja tem impacto positivo sobre o desempenho
espúia ou, pelo menos, não esabeleça ainda (ou mesmo da enega de sofwae. De ao, obsevamos isso
conaie) a evidência empíica de váios esudos. Po odos os anos do esudo desde 2014. As capacidades
isso, o mais responsável é realizar outras pesquisas para de desenvolvimento baseado em linha principal
tentar replicar os esulados e enende a causa deles. Ao iveam comporameno incomum nese ano.
destacar as surpresas, os pesquisadores também correm Po exemplo, elas iveam um impaco negaivo
o risco de menosprezara quantidade de efeitos que sobe o desempenho da enega de sofwae. Nos
sugiam com equência ao longo dos anos de pesquisa. elaóios aneioes, ocoeu o conáio. Como esa
Nós fazemos uma análise estatística de mais de cem consaação é ão inusiada, queemos ve se ela seá
caminhos paa cada elaóio Sae o DevOps. Assim replicada em pesquisas posteriores e se a comunidade
corremos o risco de gerar resultados espúrios por mero em alguma explicação.
acaso. Tenamos compensa isso com a eplicação odos
02
os anos. Descobrimos que o desempenho da entrega
de sofwae só aumena o desempenho
Po ouo lado, quando não publicamos a consaação, organizacional quando o desempenho
há o risco de criar um efeito de "armário de arquivo" opeacional ambém é alo. Mas muios paricipanes
em que o que é esperado ou palatável se torna não apesenaam alo desempenho opeacional.
conhecido, e o que é inesperado ou difícil de aguentar Isso conaia nossas pesquisas aneioes, em que a
ca escondido. Nós buscamos um equilíbio: não conexão ene o desempenho da enega de sofwae
queemos sensacionaliza consaações ecenes, mas e o oganizacional esava muio mais claa.
achamos essencial divulgá-las. Aqui esão os aos que
mais nos supeendeam e nossa inepeação deles:
² Kerr, N. L. (1998). HARKing: Hypothesizing after the results are known. Personality and social psychology review, 2(3), 196-217.
³ Rosenthal, R. (1979). The fle drawer problem and tolerance or null results. Psychological bulletin, 86(3), 638.
ACCELERATES tate of DevOps 2022 Surpresas 56

03 05
As páicas de documenação pejudicam Páicas de engenhaia de conabilidade
o desempenho da enega de sofwae. prejudicam o desempenho da entrega
Isso conaia os elaóios aneioes. Uma de sofwae. Uma explicação é que não
hipóese é que a documenação esá cando cada há elação causal ene os dois aoes. Nese ano
vez mais automatizada, especialmente em equipes observamos, em uma nova análise por grupos
com alo desempenho. Aé coleamos mais dados, (consulte "Sua equipe está à altura?"), que um
emos poucas evidências paa apoia ou eua esse subconjuno de gupos se dedica mais à conabilidade
agumeno. e ignoa o desempenho da enega de sofwae.
Acediamos que os aoes não esão ligados, ou seja,
04
Algumas capacidades técnicas (como é possível aze um sem aze o ouo. Mas, paa que
desenvolvimento baseado em linha principal, o desempenho da enega de sofwae enha impaco
aquieua com acoplameno exível, CI e no desempenho organizacional, é necessário haver
CD) paecem se indicadoes de esgoameno. Como já conabilidade.
mencionamos, muios dos paricipanes desa amosa
06
esão em uma ase aneio da caeia em elação aos Adicionamos práticas da SLSA para
paricipanes dos anos aneioes. Po isso, é possível enende se as equipes esão adoando
que os paricipanes esejam implemenando o ecuso essas abordagens para proteger a cadeia
e não sejam os esponsáveis po cia ou supevisiona de supimenos de sofwae. Havia a expecaiva de
a iniciaiva. O pocesso de implanação pode se mais uma associação ene a implemenação de páicas de
desaado que a supevisão. Queemos pesquisa mais segurança e o desempenho, como uso de capacidades
paa enende melho a consaação. écnicas, melho desempenho da enega de sofwae
e melho desempenho oganizacional. Mas camos
supesos em ve que as páicas de seguança são o
mecanismo com o qual os recursos técnicos afetam
ambos os desempenhos.

A inclusão das páicas da SLSA paece se esponsável
pelo eeio da inegação conínua, do conole de vesões Acesse htp://doa.communiy
e da entrega contínua no desempenho da entrega de (em inglês) e paricipe da
sofwae e no oganizacional. Em ouas palavas, paece
Comunidade DORA para
haver uma cadeia causal nos dados: várias capacidades
écnicas êm impaco posiivo nas páicas da SLSA e,
continuar a conversa sobre estas
por meio disso, passam a ter impacto positivo também supesas e ouas consaações
sobe essas omas de desempenho. Usamos análises do elaóio dese ano.
de mediação paa deeca esse esulado.4 5Isso nos
inceniva a analisa se a medição das páicas da SLSA
esá idenicando ouos aibuos da equipe (como o
desempenho geral) e como as práticas de segurança
melhoam o desempenho da enega de sofwae e o
oganizacional.
Queremos estudar esses efeitos novamente no

próximo ano, para ver se conseguimos reproduzir
e explica os novos padões ou se devemos ignoá-
los como pontos fora da curva (que também
devemos explica). Como sempe, apeciamos o
eedback da comunidade.
4
Jung, Sun Jae. "Introduction to Mediation Analysis and Examples of Its Application to Real-world Data." Journal of preventive medicine and public
health = Yebang Uihakhoe chi vol. 54,3 (2021): 166-172. doi:10.3961/jpmph.21.069
5
Carrión, Gabriel Cepeda, Christian Nitzl e José L. Roldán. "Mediation analyses in partial least squares structural equation modeling: Guidelines and
empirical examples." Partial least squares path modeling. Springer, Cham, 2017. 173-195.

06
Informações Derek DeBellis
demogácas
e mogácas
Assim como nos anos aneioes, coleamos inomações
demogácas de cada paricipane da pesquisa.
As caegoias incluem gêneo, deciência e gupos
Agradecemos sua
sub-epesenados.
colaboação com nossa
pesquisa e com o setor! Nese ano, obsevamos uma epesenação consisene
com os elaóios aneioes em caegoias mogácas,
incluindo amanho da empesa, seo e egião. Mais de
Quem respondeu 60% dos enevisados abalham como engenheios ou
à pesquisa? geenes, e um eço abalha no seo de ecnologia.

Além disso, vemos a epesenação do seo de seviços
Com oito anos de pesquisa e respostas de mais nanceios, vaejo e empesas indusiais/de manuaua.
de 33.000 possionais do seo, o elaóio Sae

of DevOps mostra as práticas de desenvolvimento
de sofwae e de DevOps que mais dão sucesso às
oganizações. Ese ano, mais de 1.350 possionais
que trabalham em vários setores ao redor do mundo
comparilhaam expeiências paa ajuda a enende
melho os aoes que geam maio desempenho.
Agadecemos sua colaboação com nossa pesquisa
e com o seo! Em esumo, a epesenação ene
inomações demogácas e mogácas
pemaneceu incivelmene consisene.
ACCELERATE State of DevOps 2022 Quem respondeu à pesquisa? 59

Gêneo
Informações 18%
Feminino
demogácas
6%
Peo não
Gêneo responder
A amosa dese ano em uma maio popoção

de mulhees do que 2021 (18% cona 12%). A
1%
popoção de homens (76%) é meno que em 2021
Não bináio
(83%). Os paricipanes indicaam que as mulhees 76%
Masculino
epesenam 25% das equipes deles, idênico a
2021 (25%). Pocenagem de mulhees: mediana de 25%
Deciência
11%
Deciência Sim
Idenicamos deciências em seis dimensões 7%

que seguem a oienação do Washington Group Peo
não dize
Shor Se. Ese é o quaro ano que pegunamos
sobe deciências. A pocenagem de pessoas 82%
com deciência é igual à do elaóio de 2021, 11%. Não
Gupos sub-epesentados
Gupos sub-epesentados
19%
Sim
Idenica-se como membo de um gupo sub-
epesenado pode se eei a aça, gêneo ou
10%
oua caaceísica. Ese é o quino ano que Peo
pegunamos sobe a ala de epesenaividade. A não dize
pocenagem de pessoas que se idenicam como

sub-epesenadas aumenou um pouco, de 17% em 71%
Não
2021 paa 19% em 2022.

Anos de expeiência
Nese ano, mais paricipanes êm cinco anos

ou menos de expeiência (35%) do que em 2021
(14%). Porano, não é supesa que a popoção de
paricipanes com mais de 16 anos de expeiência
(13%) seja muio meno que em 2021 (41%).
A mudança pode explica alguns padões nos dados, e

achamos imporane e isso em mene ao inepea
os esulados, especialmene em compaação ao ano
passado.
2021 2022
41%
33%
27%
25%
20%
18%
13%
8% 11%
3%
0-2 3-5 6-10 11-15 >16
Anos de experiência

Fimogaa
Papel Desenvolvimento ou engenharia 26%
DevOps ou SRE 23%
Operações ou infraestrutura de TI 19%
Dos paricipanes, 85% são pessoas
Gerente 17%
que trabalham em equipes de
Diretor executivo 4%
desenvolvimento ou engenharia Engenheiro de plataforma 3%
(26%), em equipes de DevOps Segurança das informações 2%
ou de SRE (23%), em equipes de Consultor, coach ou treinador 1%
opeações ou inaesuua de Engenharia ou garantia de qualidade 1%
Estudante 1%
TI (19%) ou são geenes (17%). A
Gerenciamento do produto 1%
popoção de paricipanes que
Serviços profssionais 1%
abalham em equipes de opeações
ou inaesuua de TI (19%) mais que
dobou desde o ano passado (9%). Os
dieoes execuivos (9% em 2021 paa
4%) e os seviços possionais (4% 2022
em 2021 paa 1%) iveam as maioes
Tecnologia 44%
eduções em elação ao ano passado.
Serviços fnanceiros 13%
Varejo/consumo/e-commerce 8%
Setor Outros 6%
Educação 5%
Como nos relatórios anteriores de Indústria e manufatura 5%
State of DevOps, a maioria dos Saúde e medicamentos 4%
paricipanes abalha no seo de Telecomunicações 4%
Mídia e entretenimento 4%
tecnologia, seguido por serviços
Seguros 3%
nanceios, "ouos" e vaejo.
Governo 2%
Organizações sem fns lucrativos 2%
Energia 1%

Região
Nese ano, pedimos que os paricipanes selecionem o

país de onde são em vez da egião. A egião, gealmene
representada por um continente, pareceu algo muito
gosseio paa enende a composição dos paricipanes.
Recebemos esposas de pessoas em mais de 70 países,
e 89% dos paricipanes vêm de 22 países.
1%
1%
Dinamarca
Países Baixos 1%
Suécia 1%
4% 8%
Reino Polônia 4%
Canadá
Unido Alemanha
29% 2%
1%
Estados 1% Iália
Japão
Unidos da Porugal 21%
América 8% Índia
2% 3%
1% Espanha Fança 1% Filipinas
México Turquia 1%
2%
1% Singapura
Indonésia
Basil
8% 1%
3%
Outros países com África
Austrália
menos de 1% de parici- do Sul
pantes

Número de funcionários esão com oganizações com 2.000 a 4.999 uncionáios.
Também vimos uma boa epesenação (13%) de pessoas
Assim como nas pesquisas State of DevOps anteriores, os em oganizações com 500 a 1.999 uncionáios, 15% com
paricipanes vêm de oganizações de váios amanhos. 100 a 499 uncionáios e 15% com 20 a 99 uncionáios.
22% dos enevisados são de empesas com mais de Nese ano, os paricipanes iveam a opção de seleciona
10.000 uncionáios, e 7% são de empesas com 5.000 a "Não sei" sobe o amanho da oganização, e 15%
9.999 uncionáios. Ouos 15 dos paricipanes selecionaam isso ou ignoaam a peguna.
Mais de 10 mil 16%

5.000 a 9.999 10%
2.000 a 4.999 10%
500 a 1.999 14%
100 a 499 17%
20 a 99 13%
10 a 19 2%
5a9 1%
1a4 2%
Não sabe ou ignoou 15%

Tamanho da equipe
Nese pedimos, pegunamos aos paricipanes o

númeo apoximado de pessoas nas equipes deles.
25% dos paricipanes abalham em equipes com
cinco pessoas ou menos. 50% abalham em equipes
com oio pessoas ou menos. 75% abalham em
equipes com 12 pessoas ou menos.
5 10 15 20 25 30
Tamanho da equipe

Destino da implantação oam os conêinees. Ese ano não oi dieene, mas a uma
popoção meno (54%) que no ano aneio (64%).
O ano de 2021 foi o primeiro em que decidimos

peguna onde os paricipanes implanam o seviço ou Também adicionamos mais opções paa que os paricipanes
o aplicativo principal em que eles abalham. Paa nossa indicassem onde eles implanam.
supesa, o pincipal desino de implanação
Conêinees, ex.:
Docke, Kubenees 54%
SaaS 47%
VMs na nuvem 42%
FaaS (unção como seviço), ex.: AWS
Lambda, Google Cloud Funcions 41%
Dispositivos móveis 33%
PaaS (plaaoma como seviço),
ex.: Heoku, App Engine, Elasic Beansalk 32%
Servidores (bare metal) 31%
Hadwae de VM 26%
Soluções comeciais ponas paa uso (COTS,
17%
na sigla em inglês)
Ouos (especique) 2%

07
Considerações Derek DeBellis
nais
ao sugimeno de alguns eeios. Po exemplo, o
Sempre que elaboramos este relatório, procuramos desempenho da enega de sofwae só em impaco
aze uma apesenação igoosa que mose positivo sobre o desempenho organizacional quando
como práticas e capacidades levam a resultados há alo desempenho opeacional (conabilidade), o
essenciais para os negócios, como o desempenho que leva à conclusão de que as oganizações pecisam
oganizacional. Avaliamos se é possível eplica váios de ambos paa e sucesso. Há ambém algumas
efeitos dos relatórios anteriores e estendemos o supesas, que desacamos em uma seção especíca.
escopo do trabalho para as prioridades emergentes
na áea de DevOps. Nese ano, elaboamos a Agradecemos a todos que contribuíram com a pesquisa
pesquisa e a análise para nos aprofundar nas práticas dese ano. Espeamos que nossa pesquisa ajude você e
de seguança. Também aleamos a modelagem sua oganização a cia equipes e sofwaes melhoes,
estatística para analisar a condicionalidade ou sem abi mão do equilíbio ene abalho e vida
dependência de alguns eeios. Também exploamos pessoal.
novas maneiras de descrever o cenário do
desempenho opeacional e da enega de sofwae.
De muitas maneiras, a narrativa que surgiu neste ano

é um eco dos anos anteriores: capacidades técnicas
ampliam umas às outras e melhoram o desempenho;
o uso da nuvem traz vários benefícios; a cultura
e a exibilidade do local de abalho melhoam o
desempenho organizacional; e o esgotamento dos
uncionáios impede que as oganizações alcancem
meas. A análise de ineações que adicionamos ao
modelo ajudou a enende as condições que levam
ACCELERATE Sae o DevOps 2022 Consideações nais 67

08
Agradecimentos
O relatório deste ano foi possível graças a muitos
colaboadoes dedicados. Elaboação de pegunas, análises,
exos, edições e elaboação de elaóios da pesquisa são
apenas algumas das formas como nossos colegas ajudaram
a ealiza ese gande esoço. Os auoes gosaiam de
agadece a odas essas pessoas pelas conibuições e
oienações no elaóio dese ano. Os agadecimenos esão
em odem alabéica pelo sobenome.
Scot Aucoin Eic Maxwell

Alex Baet John Speed Meyes
James Bookbank Seve McGhee
Kim Casillo Jacinda Mein
Lolly Chessie Alison Milligan
Jenna Dailey Pablo Péez Villanueva
Deek DeBellis Claie Pees
Rob Edwads ConnoPoske
Dave Faley Dave Sanke
Christopher Grant Dustin Smith
Mahshad Haei Seh Vago
Nathen Harvey Daniella Villalba
Damih Kaunaane Benna Washingon
Todd Kulesza Kaiyuan "Fank" Xu
Amanda Lewis Nicola Yap
Ian Lewis
ACCELERATE State of DevOps 2022 Agradecimentos 68

09
Autores
Claire Peters
Claie Pees é pesquisadoa de expeiência do usuáio no Google, esudando váios

aspecos e expessões de DORA em conexos aplicados. Ela esuda o Pogama
de Modenização de Aplicaivos do Google Cloud (CAMP, na sigla em inglês),
engajamentos do cliente orientados por DORA e as ferramentas relacionadas a
Quatro Chaves, para ajudar equipes e pessoas a aplicar os princípios de DORA no
abalho diáio. Claie ambém az pare da equipe de pesquisa pincipal de DORA e
elaboa a pesquisa anual de DORA e o elaóio Sae o DevOps. Ela em mesado
em análise culual aplicada pela Univesidade de Copenhague.
Dave Farley
Dave Faley é dieo-geene e undado da Coninuous Delivey Ld e ciado do

canal Coninuous Delivey no YouTube. Dave é coauo da séie de livos de sucesso
Coninuous Delivey. Também é auo do bes-selle Moden Sofwae Engineeing:
Doing Wha Woks o Build Bete Sofwae Fase. É coauo do Manieso Reaivo
e vencedo do Pêmio Duke pelo pojeo de código abero LMAX Disupo. Dave é
pioneio em enega conínua, omado de opinião e especialisa em CD, DevOps,
TDD e design de sofwae. Também em longo hisóico de ciação de equipes
com alo desempenho, pepaação de oganizações paa o sucesso e ciação de
sofwaes excepcionais. Cona mais coneúdo de Dave no Twite, YouTube, blog
e site.
ACCELERATE State of DevOps 2022 Autores 69

Daniella Villalba
Daniella Villalba é pesquisadoa de expeiência do usuáio dedicada ao pojeo
DORA. O oco dela é enende os aoes paa deixa os desenvolvedoes
elizes e poduivos. Anes do Google, Daniella esudou os beneícios
do einameno de mediação, os aoes psicossociais que aeam as
expeiências de esudanes univesiáios, a memóia de esemunhas e
conssões alsas. Ela em PhD em psicologia expeimenal pela Univesidade
Inenacional da Flóida.
Dave Stanke
Dave Sanke é engenheio de elações com o desenvolvedo no Google. Ele

dá consuloia sobe páicas ecomendadas paa adoa DevOps e SRE. Dave
já ocupou váias posições ao longo da caeia, incluindo CTO de sarup,
geene de poduos, supore ao cliene, desenvolvedo de sofwae, sysadmin
e designe gáco. Ele em mesado em adminisação de ecnologia pela
Univesidade Columbia.
Derek DeBellis
Deek DeBellis é pesquisado em expeiência quaniaiva do usuáio no Google.

As aividades de Deek no Google são aze pesquisas, analisa logs e descobi
maneias de medi conceios essenciais ao desenvolvimeno de poduos. Deek
publicou ecenemene sobe a ineação ene humanos e IA, o impaco do
sugimeno da COVID-19 sobe a ineupção do abagismo, design paa eos
de PLN e o papel da UX nas discussões sobe pivacidade.
ACCELERATEState of DevOps 2022 Autores 70

Eic Maxwell
Eic Maxwell é chee da áea de ansomação digial de DevOps do Google,
em que orienta as melhores empresas do mundo a serem ainda melhores
pouco a pouco, coninuamene. Eic passou a pimeia meade da caeia como
engenheiro, nas trincheiras, automatizando tudo e adquirindo empatia por outros
possionais. Ele é cociado do Pogama de Modenização de Aplicaivos
Google Cloud (CAMP, na sigla em inglês), membo da equipe pincipal de DORA
e auo de DevOps Enepise Guidebook. Anes do Google, Eic abalhava com
ouos ãs de ocadilhos na Che Sofwae.
John Speed Meyes

John Speed Meyes é cienisa de dados da Chainguad, sarup de seguança
da cadeia de supimenos de sofwae. Os pojeos de pesquisa de John incluem
ópicos como seguança da cadeia de supimenos de sofwae, seguança de
sofwae de código abero e a esposa do mundo ao cescene podeio milia
da China. John abalhou na In-Q-Tel, na RAND Copoaion e no Ceno de
Avaliações Esaégicas e Oçamenáias. John em PhD em análise de políicas
pela Faculdade de Pós-gaduação Padee RAND, mesado em assunos públicos
(MPA, na sigla em inglês) pela Faculdade de Assunos Públicos e Inenacionais
da Univesidade Pinceon e bachaelado em elações inenacionais pela
Univesidade Tufs.
Kaiyuan "Frank" Xu
Kaiyuan "Fank" Xu é pesquisado em expeiência quaniaiva do usuáio do
Google. Ele analisa logs e dados de pesquisa paa enende os padões de uso e o
eedback dos usuáios sobe os poduos Google Cloud, melhoando a excelência
do poduo paa os desenvolvedoes. Anes do Google, Kaiyuan ealizou po anos
pesquisas qualiaivas e quaniaivas de usuáio na Micosof paa os poduos
Azue Powe Plaom. Ele em mesado em design e engenhaia cenados em
humanos pela Univesidade de Washingon.

Nathen Harvey
Nahen Havey é engenheio de elações com desenvolvedoes do Google.

Ao longo da carreira, ele ajudou equipes a realizar o próprio potencial ao
mesmo empo que alinhou a ecnologia aos esulados dos negócios.
Nathen teve o privilégio de trabalhar com algumas das melhores equipes
e comunidades de código abero, ajudando a aplica os pincípios e as
páicas de DevOps e SRE. Nahen coediou e conibuiu paa 97 Things
Every Cloud Engineer Should Know, O'Reilly 2020.
Todd Kulesza
Todd Kulesza é pesquisado em expeiência do usuáio no Google, esudando

como os engenheios de sofwae abalham hoje e como eles vão abalha melho
no uuo. Ele em PhD em ciência da compuação pela Univesidade Esadual do
Oegon.

10
Metodologia
Projeto de pesquisa
Neste estudo, usamos um projeto interseccional
e baseado em eoia, chamado pevisão ineencial,
um dos tipos mais comuns usados em pesquisas Cálculo das dieenças ente baixo
de negócios e ecnologia hoje. O pojeo pediivo e alto desempenho
inferencial é usado quando o projeto puramente Na seção "Sua equipe esá à alua?", compaamos
expeimenal não é viável ou possível. equipes com baixo e alto desempenho nas quatro
méicas do desempenho da enega. O méodo
é simples. Vamos usa a equência de implanação
População e amostagem
como exemplo. O gupo alo implana sob demanda
A população segmenada paa esa pesquisa oi composa
(ou seja, váias vezes ao dia). Se eles azem quao
po possionais e lídees que usam (ou abalham
implanações po dia em média, o oal é de
com pessoas que usam) ecnologias e ansomações,
1.460 implanações ao ano (4 * 365). Já as equipes
pincipalmene os que esão amiliaizados com
com baixo desempenho implantam de uma vez ao
DevOps. Paa pomove a pesquisa, usamos lisas
mês a uma vez po semese. A equência média
de e-mails, pomoções on-line, um painel on-line e
delas é de uma vez a cada 3,5 meses ou ceca de
mídias sociais. Além disso, pedimos às pessoas que
3,4 implanações ao ano (12/3,5). Dividimos 1.460
comparilhassem a pesquisa nas edes delas (ou seja, com
implanações do gupo alo po 3,4 implanações
amosagem de bolas de neve).
do gupo baixo paa obe o esulado de 417. Essa
Como criar construções latentes abordagem foi generalizada para as demais métricas
Fomulamos nossas hipóeses e consuções usando de desempenho de desenvolvimeno.
consuções validadas aneiomene sempe que
possível. Desenvolvemos novas consuções com base
em eoia, denições e inomações de especialisas.
Depois pocuamos esclaece a inenção paa
aumentar a probabilidade de que os dados coletados na
pesquisa sejam conáveis e válidos.¹
¹ Churchill Jr, G. A. "A paradigm for developing better measures of marketing constructs", Journal of Marketing Research 16:1, (1979), 64–73.
ACCELERATE Sae o DevOps 2022 Meodologia 73

Métodos de análise
estatística
padões comuns de esposa (ou seja, gupos) em
termos de capacidade de processamento (composto
Análise de grupo
po equência de implanação e empo de lead),
Paa ambas as soluções de agupameno mosadas
desempenho opeacional (conabilidade) e esabilidade
na seção "Sua equipe esá à alua?", usamos
(composo po empo paa esauação do seviço e
agupameno hieáquico com uma vesão do méodo
axa de alhas nas aleações). Também exploamos
de aglomeação de Wad² paa avalia se as soluções
váios algoimos de agupameno paa veica a
eam adequadas aos dados.
sensibilidade dos esulados à nossa abodagem. Não
conhecemos uma oma esabelecida de quanica
Paa os pimeios esulados, pocuamos po
essa sensibilidade, mas os grupos que surgiram tinham
gupos de esposas em emos de equência de
caaceísicas semelhanes.
implanação, empo de lead, empo paa esauação
do seviço e axa de alhas nas aleações. Nese ano,
Modelo de medição
enconamos ês gupos depois de avalia 14 soluções
Anes de ealiza a análise, idenicamos consuções
de agrupamento hierárquico, usando 30 índices para
usando análise exploratória de fator com análise
deemina o númeo de gupos.³
de componene pincipal usando oação vaimax.4
Conmamos a validade divegene e a conabilidade
A segunda análise que apresentamos tinha o mesmo
dos eses esaísicos usando a exação de vaiação
método da primeira, mas foi implantada sobre
média (AVE, na sigla em inglês), coeção, ala de
dimensões dieenes nos dados. Queíamos pocua
Cronbach5, rhoA6A, índice heterotrait-monotrait5 7 e
conabilidade composa.
² Murtagh, Fionn e Pierre Legendre. "Ward’s hierarchical agglomerative clustering method: which algorithms implement Ward’s criterion?". Journal
o classifcation 31.3 (2014): 274-295.
³ Charrad M., Ghazzali N., Boiteau V., Niknafs A. (2014). "NbClust: An R Package for Determining the Relevant Number of Clusters in a Data Set".
Journal of Statistical Software, 61(6), 1-36. URL: http://www.jstatsoft.org/v61/i06/
4
Straub, D., Boudreau, M. C., & Gefen, D. (2004). Validation guidelines for IS positivist research. Communications of the Association for Informa-
tion systems, 13(1), 24.
5
Nunnally, J.C. Psychometric Theory. Nova York: McGraw-Hill, 1978
6
Hair Jr, Joseph F., et al. "Partial least squares structural equation modeling (PLS-SEM) using R: A workbook". (2021): 197.
7
Brown, Timothy A. e Michael T. Moore. "Confrmatory actor analysis". Handbook o structural equation modeling 361 (2012): 379.

Modelagem de equação estutual
Tesamos os modelos de equação esuual (SEM, na
sigla em inglês) usando a análise de mínimos quadados
paciais (PLS, na sigla em inglês)8, que é uma modelagem
de equação esuual baseada em coelação.
Análise do segundo
modelo de grupo
Paa enende o que deemina a associação aos
gupos, usamos a egessão logísica mulinomial.9
Usamos essa abodagem poque o objeivo ea
peve a associação aos gupos, que, nese caso,
são dados caegóicos com mais de dois níveis.
Paa enende os esulados pevisos pelas
associações aos gupos, usamos egessão linea
paa cada esulado (esgoameno, abalho não
planejado e desempenho oganizacional).
8
Hair Jr, J. F., Hult, G. T. M., Ringle, C. M., & Sarstedt, M. (2021). "A primer on partial least squares structural equation modeling (PLS-SEM)".
Sage publications.
9
Ripley, Brian, William Venables e Maintainer Brian Ripley. "Package ‘nnet’". Pacote R versão 7.3-12 (2016): 700.

11
Leitura adicional
(alguns links
estão em inglês)
Explore o programa de pesquisa de DevOps
Paricipe da Comunidade DORA paa htps://goo.gle/devops-eseach
discutir, aprender e colaborar para melhorar
o desempenho operacional e da entrega de Leia o e-book Pêmios DevOps do Google
sofwae.
Cloud para aprender com outras empresas
htp://doa.communiy
que implemenaam páicas de DORA
htps://goo.gle/devops-awads
Saiba mais sobre a métrica Quatro Chaves
htps://goo.gle/ou-keys
Conheça o Pogama de Modenização de
Aplicaivos do Google Cloud (CAMP, na sigla
Cona mais inomações sobe capacidades
em inglês).
de DevOps.
htps://goo.gle/3daLa9s
htps://goo.gle/devops-capabiliies
Como usar dados e métricas de

Cona como implemena as páicas de
DORA na sua oganização no Enepise DORA para transformar processos
Guidebook tecnológicos
htps://goo.gle/enepise-guidebook htps://goo.gle/3Doh8Km
Encontre recursos sobre engenharia Leia o arigo: "The ROI o DevOps

de conabilidade do sie (SRE) Tansomaion: How o quaniy he impac o
htps://se.google you modenizaion iniiaives" de Fosgen, N.,
htps://goo.gle/enepise-oadmap-se Humble, J., & Kim, G. (2018).
htps://goo.gle/3qEClIh
Faça a veicação ápida do DevOps
htps://goo.gle/devops-quickcheck
ACCELERATE State of DevOps 2022 Leitura adicional 76

Leia o livro: Accelerate: The science behind devops: Saiba mais sobe o Sofwae Bill o Maeials de NTIA.gov
Building and scaling high peroming technology htps://www.nia.gov/SBOM
organizations. IT Revoluion.
htps://ievoluion.com/book/acceleae Seguança cibenéica: eação do goveno dos
Esados Unidos aos incidenes na SolaWinds e do
Saiba mais sobe o amewok Supply chain Levels Micosof Exchange
o Secue Ariacs (SLSA) htps://www.gao.gov/poducs/gao-22-104746
htps://slsa.dev
Saiba mais sobe a veicação de seguança no
nível do aplicaivo como pare da CI/CD
Saiba mais sobe Secue Sofwae Developmen
htps://go.dev/blog/suvey2022-q2-esuls#secuiy
Famewok (NIST SSDF)
htps://goo.gle/3qBXLWk Po úlimo, mas não menos imporane, cona os
elaóios aneioes de Sae o DevOps. Todos esão
Saiba mais sobre a cultura de DevOps: Cultura disponíveis em htps://goo.gle/doa-sods:
organizacional de Westrum Relatório Accelerate State of DevOps de 2014
htps://goo.gle/3xq7KBV Relaóio Acceleae Sae o DevOps de 2015
Relaóio Acceleae Sae o DevOps de 2016
Leia mais sobe a Open Souce Secuiy Foundaion Relaóio Acceleae Sae o DevOps de 2017
htps://openss.og/ Relatório Accelerate State of DevOps de 2018
Relaóio Acceleae Sae o DevOps de 2019
Saiba mais sobre in-toto Relatório Accelerate State of DevOps de 2021
htps://in-oo.io/
ACCELERATE State of DevOps 2022 Leitura adicional 77

2022 State of Devops Report PT-BR

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

2022 State of Devops Report PT-BR

Enviado por

Direitos autorais:

Formatos disponíveis

2022 ACCELERATE

Relatório State of DevOps

03 O que fazer para

04 Por que a segurança

ACCELERATE State of DevOps 2022 Índice 2

Nos últimos oito anos, elaboramos o relatório

• Desempenho da enega de sofwae: as

• Desempenho operacional: a quinta métrica

Também analisamos os fatores que levam

ACCELERATE State of DevOps 2022 Resumo executivo 3

Em 2021, descobrimos que proteger a cadeia de A adoção de boas páicas de seguança no

da cadeia de supimenos de sofwae, que é o ema o esgoameno dos desenvolvedoes. Ene as

elacionados à poeção da cadeia de supimenos de SLSA sugerem um bom desempenho tanto da

sofwae. oganização quano da enega de sofwae, mas

ACCELERATE State of DevOps 2022 Resumo executivo 4

ACCELERATE State of DevOps 2022 Resumo executivo 5

• O alo desempenho na enega de sofwae só aingi essa mauidade, não deecamos

ACCELERATE State of DevOps 2022 Resumo executivo 6

De fato, este ano descobrimos um efeito alinhado

ACCELERATE State of DevOps 2022 Resumo executivo 7

ACCELERATE State of DevOps 2022 Sua equipe está à altura? 8

ACCELERATE State of DevOps 2022 Sua equipe está à altura? 9

Tempo de lead MTTR

Cinco métricas do desempenho

A quinta métrica, que representa o desempenho

ACCELERATE State of DevOps 2022 Sua equipe está à altura? 10

agrupando o desempenho da os dados, seja qual osse a écnica aplicada. A abela

entrega abaixo mostra as características do desempenho da

Nese ano, ao avalia a solução com quao gupos

uma divisão. Além disso, os váios índices usados paa

Mética de desempenho na entega de sofwae Baixo Médio Alto

Tempo de estauação do seviço Entre uma Entre um dia e Menos de

Taxa de falha nas alterações 46% a 60% 16% a 30% 0% a 15%

ACCELERATE State of DevOps 2022 Sua equipe está à altura? 11

15% 12% 7% 19%

ACCELERATE State of DevOps 2022 Sua equipe está à altura? 12

Talvez estejamos falando demais sobre as

ACCELERATE State of DevOps 2022 Sua equipe está à altura? 13

na entrega e do desempenho demonstram um desempenho operacional sólido,

operacional a capacidade de processamento e a estabilidade

de lead das aleações no código e equência de

e desempenho operacional (conabilidade). O moivo os respectivos nomes:

é o papel essencial que o desempenho operacional tem

Entre uma Entre uma vez por

Entre uma Entre uma vez por

Entre uma vez por

ACCELERATE State of DevOps 2022 Sua equipe está à altura? 14

O grupo Início não em desempenho bom nem uim

Po m, o gupo Desativação é como uma equipe

ACCELERATE State of DevOps 2022 Sua equipe está à altura? 15

mudanças no código e conguação do ainda popocionam expeiências esáveis e conáveis

ACCELERATE State of DevOps 2022 Sua equipe está à altura? 16

ACCELERATE State of DevOps 2022 Sua equipe está à altura? 17

Além disso, o grupo Fluidez tem o segundo melhor

ACCELERATE State of DevOps 2022 Sua equipe está à altura? 18

ACCELERATE State of DevOps 2022 O que fazer para melhorar? 19

ACCELERATE State of DevOps 2022 O que fazer para melhorar? 20

O númeo de pessoas que amam não usa a

ACCELERATE State of DevOps 2022 O que fazer para melhorar? 21

O uso da nuvem continua acelerando ano a ano

Nuvem híbida 42,47% 25%

Uma ou váias nuvens públicas 76,08% 36%

Nuvem privada 32,55% 12%