Fundamentos de Engenharia da Confiabilidade

Antonio Muniz

2022
Fundamentos de Engenharia da Confiabilidade
Antonio Muniz
© Copyright do Instituto de Gestão e Tecnologia da Informação.
Todos os direitos reservados.

2
Sumário

Capítulo 1. Pilares das práticas SRE............................................................................4

O que faz um Engenheiro de Confiabilidade de Sites? ................................................. 5

DevOps x SRE ................................................................................................................ 7

Capítulo 2. Por que SRE é mandatório para a transformação digital? ....................11

Capítulo 3. Relação do SRE e DevOps com Business Agility.....................................17

Referências…………… ........................................................................................................25

3
Capítulo 1. Pilares das práticas SRE

O artigo de 2016 do Google destaca que as práticas SRE e DevOps “não são dois
métodos concorrentes para desenvolvimento e operações de software, mas sim amigos
íntimos projetados para quebrar as barreiras organizacionais e oferecer um software
melhor mais rapidamente.”

Segundo a Red Hat, a Engenharia de Confiabilidade de Sites (SRE) é uma

abordagem da Engenharia de Software às operações de TI. As equipes de SRE usam
software como uma ferramenta para gerenciar sistemas, solucionar problemas e
automatizar tarefas operacionais:

• Na abordagem de SRE, as tarefas que historicamente foram realizadas pelas

equipes de operações, muitas vezes manualmente, passam a ser delegadas a
engenheiros ou equipes de operações que usam software e automação para
solucionar problemas e gerenciar sistemas de produção.

• A prática de SRE é muito útil sobretudo na criação de sistemas de software

escaláveis e altamente confiáveis. Ela ajuda a gerenciar sistemas extensos por
meio de código, o que é mais escalável e viável para administradores de
sistemas que administram centenas ou milhares de máquinas.

• O conceito de Engenharia de Confiabilidade de Sites foi criado pela equipe de

engenharia do Google e é atribuído à Bem Treynor Sloss.

• A abordagem de SRE ajuda as equipes a encontrar um equilíbrio entre lançar

novas funcionalidades e assegurar que elas sejam confiáveis para os usuários.

4
 • Padronização e automação são dois componentes importantes do modelo de
SRE. Os engenheiros de confiabilidade de sites devem sempre procurar uma
maneira de aprimorar e automatizar as tarefas operacionais.

• Desse modo, a SRE ajuda a aumentar a confiabilidade de um sistema, não

somente no presente, mas também a aprimorá-la ao longo do tempo,
conforme esse sistema cresce.

• As práticas de SRE facilitam o trabalho das equipes que estão abandonando a

abordagem mais tradicional, para a execução de operações de TI e adotando
a natividade em nuvem.

O que faz um Engenheiro de Confiabilidade de Sites?

Ainda seguindo as definições da Red Hat, a função do Engenheiro de

Confiabilidade de Sites é singular e requer experiencia, conhecimento e habilidades em
desenvolvimento de software, administração de sistemas e operações de TI.

• As equipes de SRE são responsáveis pela maneira como o código é implantado,

configurado e monitorado, bem como pela disponibilidade, latência,
gerenciamento de mudanças, resposta a emergências e gerenciamento de
capacidade dos serviços em produção.

• A adoção das práticas de SRE ajuda as equipes a determinar quais

funcionalidades novas podem ser lançadas e em que momento. E isso é feito
com o uso de contratos de nível de serviço (SLAs) que definem a confiabilidade
obrigatória de um sistema por meio de indicadores de nível de serviço (SLI) e
objetivos de nível de serviço (SLO).

5
• O SLI é uma métrica definida sobre aspectos específicos dos níveis de serviços
oferecidos. Os principais indicadores incluem latência de solicitação,
disponibilidade, taxa de erro e capacidade do sistema. Um SLO é baseado no
intervalo ou valor desejado para um nível de serviço com base no SLI.

• Em seguida, um SLO é determinado para a confiabilidade exigida do sistema

com base no tempo de inatividade considerado aceitável. Esse nível de tempo
de inatividade é chamado de “orçamento de erro”, o limite máximo permitido
para erros e interrupções.

• Na abordagem de SRE, não se espera que haja 100% de confiabilidade, mas as

falhas são planejadas e aceitas.

• A equipe de desenvolvimento pode “gastar” o orçamento de erro ao lançar

uma funcionalidade nova. Com base no SLO e no orçamento de erro
disponível, a equipe de desenvolvimento pode determinar se é viável ou não
lançar uma certa solução ou serviço.

• Se um serviço em execução está dentro desse orçamento, então a equipe de

desenvolvimento pode lançar esse serviço quando desejar. No entanto, se o
sistema apresentar muitos erros ou permanecer inativo por um tempo maior
do que o permitido pelo orçamento de erro, nenhum lançamento novo deverá
ser realizado até que as falhas estejam dentro do parâmetro.

• A equipe de desenvolvimento conduz testes automatizados nas operações

para demonstrar confiabilidade.

• Os engenheiros de confiabilidade de sites dividem seu tempo entre a execução

de tarefas operacionais e no trabalho em projetos. De acordo com as práticas
recomendadas pelo Google para SRE, um engenheiro de confiabilidade de sites

6
 só pode gastar no máximo 50% do tempo trabalhando nas operações. O tempo
deve ser monitorado para assegurar que essa porcentagem não seja
ultrapassada.

• O restante do tempo é gasto em tarefas de desenvolvimento, como criação de

funcionalidade novas, escalonamento do sistema e implementação da
automação.

• O excesso de trabalho operacional e o baixo desempenho dos serviços podem

ser redirecionados para que a equipe de desenvolvimento solucione esses
problemas. Assim, o engenheiro de confiabilidade de sites não passa tanto
tempo nas operações de uma aplicação ou um serviço.

• A automação é uma parte importante da função do engenheiro de

confiabilidade de sites. Se eles estiverem enfrentando um problema que se
repete, então devem criar uma solução automatizada. Essa também é uma
maneira de assegurar que o trabalho operacional não ocupe mais da metade
da carga de trabalho desses profissionais.

• Manter o equilíbrio entre o trabalho operacional e de desenvolvimento é

essencial na abordagem de SRE.

DevOps x SRE

Existe uma grande dúvida sobre a diferença entre DevOps e SRE. Segundo a Red
Hat, a metodologia DevOps é uma abordagem de cultura, automação e design de
plataforma que tem como objetivo agregar mais valor aos negócios e aumentar a
capacidade de resposta às mudanças por meio de entregas de serviços rápidas e de alta

7
qualidade. A SRE pode ser considerada uma forma de implementar a metodologia
DevOps:

• Assim como o Devops, a SRE tem como foco a cultura e os relacionamentos.

Ambas as abordagens têm como objetivo aproximar as equipes de operações
e desenvolvimento para acelerar a entrega de serviços.

• Ciclos de desenvolvimento mais rápidos, melhor qualidade de serviço, maior

confiabilidade e redução no tempo gasto pela TI em cada aplicação
desenvolvida são alguns dos possíveis benefícios alcançáveis com as práticas
de DevOps e SRE.

• No entanto, a SRE é diferente porque depende dos engenheiros de

confiabilidade de sites da equipe de desenvolvimento que também têm
experiência em operações de TI para eliminar problemas de comunicação e
fluxo de trabalho.

• A função do engenheiro de confiabilidade de sites combina as habilidades das

equipes de desenvolvimento com as de operações porque tem
responsabilidades que abrangem ambas as áreas.

• A SRE pode ajudar as equipes de DevOps cujos desenvolvedores estão

sobrecarregados com as tarefas operacionais e precisam de alguém com
habilidades mais especializadas nessa área.

• Em termos de codificação e criação de novas funcionalidades, o foco da

metodologia de DevOps está em percorrer o pipeline de desenvolvimento de
modo eficiente. Já a abordagem de SRE está focada no equilíbrio entre os
esforços de manter a confiabilidade de sites e a criação de novas
funcionalidades.

8
 • As plataformas de aplicações modernas baseadas em tecnologia de containers,
Kubernetes e microsserviços são essenciais para as práticas de DevOps, pois
ajudam a entregar serviços de software seguros e inovadores.

Podemos classificar as práticas SRE em 5 pilares que serão explicadas a seguir:

1. Observabilidade

‒ Métricas para detectar rápido, comportamentos indesejados dos

sistemas em produção;

‒ Traces para resolver rápido;

‒ Logs para descobrir causas;

‒ SLI, SLO, Error budget.

2. Mudanças de Baixo Risco

‒ Qualidade ágil (funcional e não funcional);

‒ CI/CD, Canário, Feature Toggle;

‒ Degradação suave, Self-healing;

o Microsserviços, Kubernetes, Service Mesh, Serverless.

o Engenharia do Caos.

Consulte no link abaixo a diferença entre resiliência e anti-fragilidade, que é

fundamental para a engenharia do caos:

https://www.linkedin.com/video/live/urn:li:ugcPost:6851479131322929152/.

9
3. Incidentes e causa raiz

‒ Plantão conjunto do SER e Dev;

‒ Post-mortem sem culpa (evitar, detectar e resolver mais rápido);

‒ Congelar releases de aplicações frágeis e/ou fora do SLO.

4. Infra como código e automação

‒ Provisionar ambientes self-services para Devs;

‒ Infra imutável, testes de infra;

‒ Automatizar tarefas repetitivas (toil) e liberar tempo para melhorias;

‒ AIOps, MLOps.

5. Gestão da demanda e capacidade

‒ Planejar capacidade para atingir SLO;

‒ Otimizar utilização;

‒ Fomentar Cloud Native.

10
Capítulo 2. Por que SRE é mandatório para a transformação digital?

Gosto de fazer uma analogia colocando o SRE e DevOps como o combustível da

transformação digital, pois de nada adianta ter diversos experimentos, se não implantar
rapidamente em produção para obter o feedback imediato do cliente.

Além da experimentação contínua, as práticas SRE evitam também falhas de

software que são cada vez mais impactantes. Por exemplo, observe o resultado das 10
falhas mais impactantes dos últimos anos no artigo de 2018 do Portal Computerworld:

1. TSB Bank

Milhões de clientes do Banco TSB, do Reino Unido, tiveram suas contas

bloqueadas após uma atualização de TI que levou a uma interrupção do banco on-line.
A expectativa era de que uma atualização encerrasse os serviços bancários pela Internet
e dispositivos móveis em um único fim de semana de abril último, mas acabou causando
messes de interrupção.

Os problemas surgiram com a mudança do TSB para uma nova plataforma

bancária após sua divisão do Lloyd Banking Group. Imediatamente depois que o novo
sistema foi ligado, muitos clientes tiveram problemas ao fazer login, enquanto outros
visualizavam detalhes das contas de outras pessoas. Os clientes permaneceram
bloqueados mesmo após duas semanas da interrupção inicial.

Em julho, o TSB ainda estava trabalhando no acúmulo de reclamações, quando

outra interrupção ocorreu, bloqueando os clientes de suas contas online mais uma vez.
O TSB alegou que o problema foi resolvido mais tarde naquele dia, mas o problema
poderá estremecer ainda mais relação do banco com a empresa controladora Sabadell.
De acordo com o Financial Times, o grupo bancário espanhol está considerando a venda
do TSB.

11
 2. Welsh NHS

Em 2018, os médicos e funcionários do hospital Welsh NHS, no Reino Unido,

sofreram uma falha generalizada que os impediu de acessar os arquivos dos pacientes.

De acordo como Centro Nacional de Segurança Cibernética, a falha aconteceu

devido a problemas técnicos, e não após um ataque cibernético. Ainda assim houve uma
grande interrupção, já que os funcionários não conseguiram acessar os resultados de
exames de sangue e raios-X. Isso também causou um backlog, já que os pacientes não
puderam ser contatados para cancelar os compromissos, e as anotações não puderam
ser digitadas e salvas nos sistemas.

3. Meltdown e Spectre

No início de 2018, os pesquisadores do Google revelaram vulnerabilidades de

hardware, chamadas Meltdown e Spectre, que afetaram quase todos os computadores
no mercado.

A primeira falha afeta principalmente os processadores Intel, enquanto o

Spectre afeta os processadores Intel, AMD e ARM. Daniel Gruss, um dos pesquisadores
que descobriu a falha na Universidade de Tecnologia de Graz, descreveu o Meltdown
como “um dos piores bugs de CPU já encontrados.” Embora estas sejam principalmente
vulnerabilidades de hardware, elas se comunicam com o sistema operacional para
acessar locais em seu espaço de memória.

Meltdown, explica o Google, “(...) rompe o isolamento mais fundamental entre

os aplicativos do usuário e o sistema operacional. Isso permite que um programa acesse
a memória e os segredos de outros programas e do sistema operacional.” Enquanto isso,
o Spectre “(...) interrompe o isolamento entre aplicativos diferentes e permite que um
invasor engane programas que seguem as melhores práticas, para vazar seus segredos.”

12
 4. WannaCry

Em maio de 2017, um grande ataque de ransomware chamado WannaCry

(também conhecido como WnnaCrypt0r e WCry) atingiu o NHS England e várias
organizações no Reino Unido e em todo mundo.

O ataque aconteceu por causa das vulnerabilidades encontradas em sistemas

operacionais da Microsoft instalados em milhões de computadores. Segundo a
Microsoft, as versões do Windows que eram vulneráveis ao ataque, eram versões que
não mais suportadas pela empresa, como o Windows 8 e o Windows XP.

5. Cloudbleed

Em fevereiro de 2017, a Cloudflare enfrentou um grande bug de software que

vazou dados confidenciais de clientes, como senhas, cookies e tokens de autenticação.

A Cloudflare é conhecida por fornecer serviços de desempenho e segurança

para milhões de sites de clientes e, embora a falha tenha sido corrigida em questão de
horas, estima-se que o vazamento de dados possa ter começado em setembro de 2016.

6. Bitcoin Unlimited

O Bitcoin Unlimited sofreu um grave vazamento de memória que causou a

queda de 800 para cerca de 300. O valor representava quase 70% dos nós executados
pela empresa na época. Embora o vazamento tenha sido corrigido rapidamente, este
parece ser o terceiro vazamento que trava o método preferido do Bitcoin Unlimited.

7. British Airways

Pela sexta vez em um ano, a British Airways enfrentou uma enorme falha global
de TI que levou a companhia aérea a cancelar todos os voos de Heathrow e Gatwick, em
maio de 2017.

13
 A falha de TI afetou mais de mil voos, além do Call Center, do site e do aplicativo
para dispositivos móveis. De acordo com a União GMB, a falha poderia ter sido evitada
se a empresa não tivesse demitido centenas de seus funcionários de TI em 2016.

8. Nest

Em meados de janeiro de 2016, o termostato “inteligente” da Nest

(pertencente ao Google) foi atingido por uma falha de software que deixou os usuários,
literalmente, numa fria.

Uma atualização de software deu errado, forçando as baterias do dispositivo a

drenar e deixando-a incapaz de controlar a temperatura. Com isso, os clientes não
conseguiam aquecer suas casas ou obter água quente em um dos fins de semana mais
frios do ano.

A Nest disse que a falha foi causada por uma atualização de firmware, além de
problemas como filtros de ar antigos ou caldeiras incompatíveis. Desde então, lançou
uma atualização de software 4.0.1, que diz ter resolvido o problema para 99,5% dos
clientes afetados.

9. HSBC

No início de 2016, o HSBC sofreu uma grande interrupção de TI. Milhões de

clientes do banco não conseguiram acessar contas on-line, sendo que os serviços só
retornaram ao normal após uma interrupção de dois dias. O diretor de operações do
banco, Jack Hackett, culpou uma “questão técnica complexa” em seus sistemas internos.

10. Glitch

Em dezembro de 2015, uma falha causou a libertação antecipada de mais de

3,2 mil prisioneiros americanos. O problema aconteceu após o software que calcula a

14
sentença de um preso, dependendo do bom ou mau comportamento, tenha tido um
erro. A ferramenta foi introduzida em 2002. Estima-se que, em média, os prisioneiros
foram libertados com 49 dias de antecedência.

Considerando que SRE fortalece a confiabilidade, é importante que todos

tenham clareza que a qualidade é um compromisso de todos e não somente de um
departamento centralizado. Observe na figura abaixo que as empresas mais inovadoras
já perceberam que devem colocar o cliente no centro.

Fonte: Muniz et al., 2021

15
 Essa nova abordagem justifica-se porque temos clientes cada vez mais
exigentes. Aliás, nós também queremos serviços melhores e confiáveis, conforme a
tabela abaixo:

Fonte: Muniz et al., 2019

16
Capítulo 3. Relação do SRE e DevOps com Business Agility

A dinâmica acelerada do mundo digital coloca as startups em vantagem

competitiva, pois já nascem adaptando-se continuamente às necessidades dos clientes,
enquanto as grandes empresas precisam combater uma estrutura mais rígida que
funcionou durante muitos anos.

Segundo artigo da SambaTech, o mercado está cada vez mais exigente e

imediato, o mundo líquido (Zygmunt Bauman) não permanece mais em seu estado por
muito tempo, e nem preciso citar a questão das concorrências. Diante deste cenário
complexo, surgem grandes preocupações das lideranças nas organizações. Uma delas é
a exigência de uma resposta rápida a todas estas necessidades do mercado e, claro, a
adaptação constante frente à velocidade do progresso da tecnologia:

• As organizações hoje em dia estão vorazes pela agilidade e transformação

digital. A parte de ser modismo já passou, estamos agora falando de “ou muda
ou morre!”. A pergunta não é mais quando isso vai acontecer, agora é “como
começo?”.

• E aí que está o grande problema: as organizações querem se adaptar – na

verdade elas precisam -, e estão investindo em treinamentos para toda equipe
de TI sobre scrum, kanban, Less, SAFe, Nexus e mais um monte de ferramentas
e frameworks do mercado para “tentar” alcançar a agilidade organizacional
desejada.

• Conhecer e dominar estas ferramentas ou frameworks é importante, como

também saber o que é ser ágil e fazer ágil, não podemos desconsiderar estes
conhecimentos e práticas. Com isso os times técnicos (delivery) conseguem
alcançar um bom nível de produtividade, contudo, isso fica apenas para aquele
time, e o foco permanece apenas nos métodos, tornando-os executores dos
mesmos, deixando de lado a essência e grande objetivo da agilidade, que é

17
 trazer resultado para o negócio. No final o que você tem é apenas um time
ágil, mas não a organização.

• Vamos alinhar algo: a agilidade foi criada para gerar mais resultado para o
negócio, e isso, em alguns momentos, acredito que o mercado esqueça.

• Em vários momentos ao iniciar uma consultoria em algumas empresas, eu

acabo detectando esta disfunção durante o diagnóstico inicial, os times
executam frameworks, não focam na entrega de valor para o cliente, e na
grande maioria das vezes nem conversam com o cliente, tendo como grande
objetivo entregar mais pontos, ou entregar tudo que está no backlog ou
simplesmente realizar o máximo de itens possíveis dentro de duas semanas.
Isso não é ser ágil, e claro, não alcança a expectativa do cliente.

• Ah, sem contar que isso que falei acima é somente na TI, os outros setores da
organização nem sabem o que é ágil, ou seja, você tem um Silo Ágil, parabéns.

• Você percebe que há uma disfunção e falta de sincronismo quando vê o RH

brigando com a contabilidade, a contabilidade brigando com o marketing, o
marketing com a TI e assim vai a onda da culpabilidade, onde eu coloco a culpa
em quem eu quiser. Mas, o problema é que ninguém assume. Você não vê as
pessoas falando em como resolver o problema, mas vê gastando energia em
procurar o culpado daquilo ter ocorrido.

• A TI fala que está organizada, que é ágil, mas que o PO ou clientes não
conseguem entender o que eles fazem e ficam tentando atrapalhar a sprint,
neste caso está claro que não há um alinhamento sobre o objetivo estratégico
que estão buscando, concluindo que o cliente não foi envolvido no
planejamento.

• Então vem a grande pergunta: como fazer com que uma organização alcance
agilidade em todos os níveis, não somente na TI?

18
• Estou falando de Business Agility, ou, Agilidade Organizacional.

• Business Agility é a capacidade da organização de se adaptar e flexibilizar para

atender às mudanças constantes e necessidades do mercado, entregando
valor ao cliente.

• Independentemente se estas mudanças são originadas internamente ou

externamente, geram para as organizações um aprendizado rápido e contínuo.

• Se a organização puder navegar por estas oportunidades de maneira produtiva

e econômica, sem comprometer a qualidade, poderá atravessar qualquer
tempestade competitiva.

• Business Agility está ligada à estratégia da organização, e não no delivery.

Agilidade Organizacional não tem nada a ver com ter times ágeis, é mais do
que isso.

Observe na figura a seguir um resumo destas características:

Fonte: Muniz et al., 2019

19
 Existe uma ligação direta entre agilidade e SRE desde os primórdios do
Manifesto Ágil. A figura abaixo destaca a evolução do movimento ágil, para que fique
claro como dependemos de SRE para escalar essas práticas para toda a organização.

Fonte: Muniz et al., 2021

O artigo da Sambatech descreve um resumo dessas três ondas:

• 1ª Onda – Em 2001 veio a primeira onda da agilidade, quando vários

profissionais da área de tecnologia, cansados de sofrerem nas mãos dos
clientes insatisfeitos, juntaram suas experiências práticas e criaram o
Manifesto Ágil. As equipes de TI começaram a ter resultados com as
abordagens ágeis, utilizando como base o manifesto criado (4 valores e 12
princípios).

20
 • 2ª Onda – Em 2007/10 o mercado entendeu que houve uma ampliação das
necessidades de agilidade em vários times, que estavam criando o mesmo
produto ou atuando de forma integrada e com dependências. Foi onde surgiu
a visão da escala de agilidade e apareceram os primeiros frameworks para
escalar o ágil, SAFe, Nexus, Kanban (sim, também escala muito bem), Less etc.

• 3ª Onda – E então em 2016, surgiu o conceito mundial de Business Agility, pois

foi percebida a necessidade de levar agilidade para outros setores, devido a
demanda de envolver outras áreas para entrega de produtos de forma
frequente, porque estas entregas não mais dependiam somente da TI.
Surgiram então o RH Ágil, Marketing Ágil e outras áreas que precisam entender
o que é ser ágil. A grande marca da terceira onda é atualizar a forma como
estabelecemos, lideramos e conduzimos as organizações, transformando para
uma mentalidade ágil, o que promove uma cultura de rápida aprendizagem
organizacional e aplicando práticas ágeis em todos os níveis de organização.

Muito se fala atualmente que toda empresa é uma empresa de software, e

considero verdadeira essa expressão porque as tecnologias digitais colocam os serviços
na palma da mão dos clientes.

Dentre as práticas do Business Agility que tem relação direta com SRE, destaco
abaixo os pilares que precisam ser trabalhados conjuntamente nessas duas iniciativas
nas organizações:

21
 Fonte: Muniz et al., 2021

As práticas SRE também são indicadas pelo Gartner, uma das maiores
referências em tendências para tecnologia e gestão. Existem diversos relatórios do
Gartner relacionando SRE com agilidade e destaco na figura abaixo a importância da
cultura colaborativa e automação.

22
 Fonte: Gartner Inc, 2017

Considerando todas as iniciativas necessárias para a adoção das práticas SRE,

fica evidente o importante papel da liderança para engajar os times multidisciplinares,
pois a complexidade do mundo em que vivemos torna necessária a participação de
muitas pessoas para entregar resultados sustentáveis.

23
 Confira no site abaixo como a mudança de estrutura do modelo tradicional para
a cultura SRE depende de lideranças inspiradoras que acreditem no poder da autonomia
com times que equilibrem liberdade com responsabilidade:
https://www.liderproexpert.com.br/webnario.

24
Referências

BEYER, Betsy et al. Engenharia da Confiabilidade do Google. São Paulo: 2016.

BUSINESS Agility: agilidade em toda organização. Sambatech, Nova Lima, 11 jan. 2021.
Disponível em: https://sambatech.com/blog/enredos-da-samba/business-agility/.
Acesso em: 24 jan. 2022.

INTRODUÇÃO à automação. Red Hat, c2022. Disponível em:

https://www.redhat.com/pt-br/topics/automation. Acesso em: 24 jan. 2022.

INTRODUÇÃO ao DevOps. Red Hat, 19 abr. 2018. Disponível em:

https://www.redhat.com/pt-br/topics/devops. Acesso em: 24 jan. 2022.

INTRODUÇÃO às aplicações nativas em nuvem. Red Hat, 20 jun. 2018. Disponível em:
https://www.redhat.com/pt-br/topics/cloud-native-apps. Acesso em: 24 jan. 2022.

MUNIZ, Antônio et al. Jornada Business Agility. Rio de Janeiro: 2021.

MUNIZ, Antonio et al. Jornada DevOps. Rio de Janeiro: Brasport, 2019.

O QUE é SRE (engenharia de confiabilidade de sites)?. Red Hat, 4 mai. 2020. Disponível
em: https://www.redhat.com/pt-br/topics/devops/what-is-sre. Acesso em: 24 jan.
2022.

25