{"id":22389,"date":"2021-11-16T17:15:21","date_gmt":"2021-11-16T17:15:21","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/2021\/11\/16\/principios-da-sre-as-7-regras-fundamentais\/"},"modified":"2026-08-27T21:23:48","modified_gmt":"2026-08-27T21:23:48","slug":"principios-da-sre-as-7-regras-fundamentais","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/principios-da-sre-as-7-regras-fundamentais\/","title":{"rendered":"Princ\u00edpios SRE: As 7 Regras Fundamentais"},"content":{"rendered":"<figure id=\"attachment_34573\" aria-describedby=\"caption-attachment-34573\" style=\"width: 1200px\" class=\"wp-caption alignnone\"><img fetchpriority=\"high\" decoding=\"async\" class=\"size-full wp-image-34573\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/hero-sre-principles-outside-google.webp\" alt=\"Ilustra\u00e7\u00e3o de uma pilha web onde a equipe possui o n\u00facleo da aplica\u00e7\u00e3o mas depende de servi\u00e7os externos de CDN, DNS, pagamento e autentica\u00e7\u00e3o\" width=\"1200\" height=\"800\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/hero-sre-principles-outside-google.webp 1200w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/hero-sre-principles-outside-google-300x200.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/hero-sre-principles-outside-google-1024x683.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/hero-sre-principles-outside-google-768x512.webp 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><figcaption id=\"caption-attachment-34573\" class=\"wp-caption-text\">O livro do Google SRE assume que voc\u00ea possui toda a pilha. Muito do que seus usu\u00e1rios experienciam roda em infraestrutura que n\u00e3o \u00e9 sua.<\/figcaption><\/figure>\n<p>Os sete princ\u00edpios SRE v\u00eam de uma empresa que possui seus data centers, sua rede, seus balanceadores de carga e cada linha de c\u00f3digo entre eles. Sua pilha provavelmente n\u00e3o \u00e9 assim. Grande parte do que seus usu\u00e1rios experimentam roda em infraestrutura que voc\u00ea n\u00e3o pode acessar via SSH: um CDN, um provedor de autentica\u00e7\u00e3o, um gateway de pagamento, DNS, um gerenciador de tags, uma API parceira.<\/p>\n<p>Essa lacuna importa, porque os princ\u00edpios ainda valem fora do Google. Mas v\u00e1rios deles mudam de forma quando o componente que est\u00e1 falhando n\u00e3o \u00e9 seu para consertar. Um or\u00e7amento de erros se comporta diferente quando um ter\u00e7o dele \u00e9 gasto por uma falha de outra empresa. Os quatro sinais dourados parecem diferentes fora do firewall do que dentro dele. E o risco que voc\u00ea n\u00e3o pode eliminar pela engenharia, precisa medir.<\/p>\n<p>Este artigo percorre todos os sete princ\u00edpios da maneira como o <a href=\"https:\/\/sre.google\/sre-book\/table-of-contents\/\" target=\"_blank\" rel=\"noopener\">livro do Google SRE<\/a> os define, e ent\u00e3o adiciona a parte que o livro pula: como cada princ\u00edpio se manifesta quando voc\u00ea depende de servi\u00e7os que n\u00e3o controla. Se voc\u00ea \u00e9 novo na fun\u00e7\u00e3o, comece com <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/o-que-e-um-sre-site-reliability-engineer\/\">o que um engenheiro de confiabilidade de site faz<\/a> e depois volte aqui.<\/p>\n<h2 id='o-que-s\u00e3o-os-princ\u00edpios-sre'  id=\"boomdevs_1\" id=\"what-are-the-sre-principles\">O que s\u00e3o os Princ\u00edpios SRE?<\/h2>\n<p>Os princ\u00edpios SRE s\u00e3o as regras de trabalho que o Google codificou para executar sistemas confi\u00e1veis em escala: abra\u00e7ar e gerenciar risco, objetivos de n\u00edvel de servi\u00e7o, eliminar trabalho repetitivo (toil), monitoramento, automa\u00e7\u00e3o, engenharia de releases e simplicidade. Juntos eles respondem a uma pergunta: qu\u00e3o confi\u00e1vel esse servi\u00e7o precisa ser, e qual \u00e9 a forma sustent\u00e1vel mais barata de mant\u00ea-lo assim?<\/p>\n<p>A lista n\u00e3o mudou desde que o livro SRE foi publicado em 2016. O que mudou foi a pilha m\u00e9dia. Microsservi\u00e7os, depend\u00eancias SaaS e scripts de terceiros significam que parte da sua confiabilidade agora est\u00e1 nas m\u00e3os de outras empresas. Cada se\u00e7\u00e3o abaixo cobre o princ\u00edpio conforme escrito, depois o que se quebra quando a depend\u00eancia n\u00e3o \u00e9 sua. No final, uma lista curta de melhores pr\u00e1ticas SRE extra\u00eddas dos sete princ\u00edpios.<\/p>\n<h2 id='princ\u00edpio-1-abra\u00e7ar-e-gerenciar-o-risco'  id=\"boomdevs_2\" id=\"principle-1-embracing-and-managing-risk\">Princ\u00edpio 1 \u2013 Abra\u00e7ar e Gerenciar o Risco<\/h2>\n<p>A formula\u00e7\u00e3o do Google: 100% de confiabilidade \u00e9 a meta errada. Usu\u00e1rios acessam voc\u00ea por meio de redes e dispositivos que falham por conta pr\u00f3pria, ent\u00e3o, al\u00e9m de um certo ponto, os \u201cnines\u201d extras custam dinheiro real e ningu\u00e9m nota a diferen\u00e7a. Escolha uma meta de confiabilidade que o neg\u00f3cio possa defender e trate a diferen\u00e7a entre essa meta e a perfei\u00e7\u00e3o como um or\u00e7amento que voc\u00ea pode gastar enviando funcionalidades. O <a href=\"https:\/\/sre.google\/sre-book\/embracing-risk\/\" target=\"_blank\" rel=\"noopener\">cap\u00edtulo Abra\u00e7ando o Risco<\/a> exp\u00f5e isso em detalhes.<\/p>\n<p>Dentro do Google, isso funciona porque o risco \u00e9 um dial (controle) que eles podem ajustar. Mais replica\u00e7\u00e3o, mais redund\u00e2ncia, implanta\u00e7\u00f5es mais lentas: gaste dinheiro, obtenha \u201cnines\u201d.<\/p>\n<p>Fora do Google, parte desse dial n\u00e3o est\u00e1 conectado a nada. Voc\u00ea n\u00e3o pode adicionar uma r\u00e9plica ao seu gateway de pagamento. N\u00e3o pode ajustar o comportamento de failover do seu provedor de DNS. A confiabilidade deles \u00e9 um termo contratual, n\u00e3o um par\u00e2metro de engenharia.<\/p>\n<p>Ent\u00e3o o princ\u00edpio muda de forma: para os componentes que voc\u00ea possui, gerencie risco pela engenharia. Para os componentes que n\u00e3o possui, gerencie-o pela medi\u00e7\u00e3o. Voc\u00ea precisa saber a disponibilidade real do seu provedor de autentica\u00e7\u00e3o medida do lado dos seus usu\u00e1rios na internet, n\u00e3o o n\u00famero na p\u00e1gina de status dele. P\u00e1ginas de status rotineiramente exibem verde durante falhas parciais, e uma depend\u00eancia que est\u00e1 ativa no pr\u00f3prio data center ainda pode ser inacess\u00edvel do seu. Medi\u00e7\u00e3o independente \u00e9 o que transforma &#8220;achamos que o CDN est\u00e1 inst\u00e1vel&#8221; em uma conversa de renova\u00e7\u00e3o embasada por dados. Este \u00e9 o primeiro trabalho que o Dotcom-Monitor faz aqui: colocar uma checagem externa em cada depend\u00eancia cr\u00edtica. Uma <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/produtos-de-monitoramento\/ferramenta-de-monitorizacao-de-dns-dotcom-monitor\/\">checagem DNS<\/a> contra os servidores de nome do provedor, uma checagem HTTP(S) na borda do CDN, uma <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/produtos-de-monitoramento\/monitoramento-de-api\/web-api-monitoring\/\">checagem de API<\/a> contra o gateway de pagamento. Cada uma constr\u00f3i seu pr\u00f3prio hist\u00f3rico de tempo de atividade e tempo de resposta a partir de uma rede global. E onde os n\u00fameros justificam, rode em volta do risco: um segundo provedor DNS, um caminho de pagamento reserva, uma c\u00f3pia em cache do script de terceiros.<\/p>\n<h3 id='como-implementar-o-gerenciamento-de-risco'  id=\"boomdevs_3\">Como Implementar o Gerenciamento de Risco<\/h3>\n<ul>\n<li>Liste todas as depend\u00eancias que um pedido do usu\u00e1rio acessa (DNS, CDN, autentica\u00e7\u00e3o, pagamentos, tags de terceiros) e marque quais voc\u00ea pode controlar pela engenharia e quais s\u00f3 pode medir.<\/li>\n<li>Crie um dispositivo Dotcom-Monitor para cada uma que s\u00f3 possa medir: uma tarefa DNS apontada para os servidores de nome do provedor, uma tarefa HTTP(S) na borda do CDN, uma tarefa de servi\u00e7os web contra o endpoint de pagamento ou autentica\u00e7\u00e3o.<\/li>\n<li>Execute essas checagens de v\u00e1rios locais de monitoramento nas regi\u00f5es dos seus usu\u00e1rios, para que uma falha regional no fornecedor n\u00e3o fique escondida atr\u00e1s de uma regi\u00e3o saud\u00e1vel.<\/li>\n<li>Leve o relat\u00f3rio de uptime de cada dispositivo para a conversa com o fornecedor, e adicione rotas reserva (DNS secund\u00e1rio, caminho de pagamento reserva) s\u00f3 onde esses dados indicarem que o risco justifica o custo.<\/li>\n<\/ul>\n<h2 id='princ\u00edpio-2-objetivos-de-n\u00edvel-de-servi\u00e7o-sla-slo-sli'  id=\"boomdevs_4\" id=\"principle-2-service-level-objectives-sla-slo-sli\">Princ\u00edpio 2 \u2013 Objetivos de N\u00edvel de Servi\u00e7o (SLA, SLO, SLI)<\/h2>\n<p>Tr\u00eas termos se confundem constantemente, ent\u00e3o aqui est\u00e1 a separa\u00e7\u00e3o:<\/p>\n<ul>\n<li><strong>SLA (Service Level Agreement, Acordo de N\u00edvel de Servi\u00e7o):<\/strong> o contrato. O que voc\u00ea promete aos clientes, com penalidades se n\u00e3o cumprir.<\/li>\n<li><strong>SLO (Service Level Objective, Objetivo de N\u00edvel de Servi\u00e7o):<\/strong> a meta que voc\u00ea define para um indicador de n\u00edvel de servi\u00e7o, tipicamente interno e mais restrito que o SLA para que o alarme pr\u00f3prio dispare antes do contrato ser quebrado. 99,9% de uptime, finaliza\u00e7\u00e3o do checkout em menos de 3 segundos, esse tipo de meta.<\/li>\n<li><strong>SLI (Service Level Indicator, Indicador de N\u00edvel de Servi\u00e7o):<\/strong> a medi\u00e7\u00e3o propriamente dita. O n\u00famero real de uptime, o tempo de resposta real, a taxa de erro observada.<\/li>\n<\/ul>\n<p>O SLI mede, o SLO define a meta, o SLA promete. Tudo a jusante, incluindo os <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/caracteristicas\/uptime-and-sla-reports\/\">relat\u00f3rios de uptime e SLA<\/a> que voc\u00ea entrega a um cliente, depende do SLI ser confi\u00e1vel.<\/p>\n<p>E \u00e9 aqui que a maioria dos times tem um ponto cego: um or\u00e7amento de erro \u00e9 t\u00e3o preciso quanto a medi\u00e7\u00e3o por tr\u00e1s dele. Se suas checagens rodarem a cada 5 minutos, cada falha registrada tem um come\u00e7o e um fim conhecidos apenas dentro de um intervalo de 5 minutos, e falhas mais curtas que esse intervalo podem acabar sem nunca serem vistas. Veja o que isso faz ao or\u00e7amento mensal de erro nos alvos SLO comuns, usando um m\u00eas de 30 dias (43.200 minutos):<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>SLO Mensal<\/th>\n<th>Or\u00e7amento de Erro (m\u00eas de 30 dias)<\/th>\n<th>Menor Falha que uma Checagem de 5 Minutos V\u00ea com Confian\u00e7a<\/th>\n<th>Um Intervalo de 5 Minutos como % do Or\u00e7amento<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>99,0%<\/td>\n<td>7h 12m (432 min)<\/td>\n<td>5 min<\/td>\n<td>1,2%<\/td>\n<\/tr>\n<tr>\n<td>99,5%<\/td>\n<td>3h 36m (216 min)<\/td>\n<td>5 min<\/td>\n<td>2,3%<\/td>\n<\/tr>\n<tr>\n<td>99,9%<\/td>\n<td>43m 12s (43,2 min)<\/td>\n<td>5 min<\/td>\n<td>11,6%<\/td>\n<\/tr>\n<tr>\n<td>99,95%<\/td>\n<td>21m 36s (21,6 min)<\/td>\n<td>5 min<\/td>\n<td>23,1%<\/td>\n<\/tr>\n<tr>\n<td>99,99%<\/td>\n<td>4m 19s (4,32 min)<\/td>\n<td>5 min<\/td>\n<td><strong>116%, mais que todo o or\u00e7amento<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<blockquote><p>Voc\u00ea n\u00e3o pode medir um SLO mensal de 99,99% com checagens de 5 minutos. Um \u00fanico intervalo de checagem \u00e9 maior que todo o seu or\u00e7amento mensal de erro.<\/p><\/blockquote>\n<p>A matem\u00e1tica da probabilidade \u00e9 t\u00e3o rigorosa quanto. Com um intervalo de checagem de <em>I<\/em> minutos, uma falha aleat\u00f3ria que dura <em>D<\/em> minutos (onde <em>D<\/em> \u00e9 menor que <em>I<\/em>) \u00e9 capturada com uma probabilidade aproximada de <em>D\/I<\/em>, assumindo que o in\u00edcio da falha seja independente da escala de checagem. Ent\u00e3o uma falha de 4 minutos contra um intervalo de 5 minutos \u00e9 capturada cerca de 4 vezes em 5, e a chance restante de 1 em 5 \u00e9 a falha ocorrendo inteiramente entre duas checagens sem ser registrada. Para falhas que duram mais que o intervalo, o atraso m\u00e9dio de detec\u00e7\u00e3o \u00e9 cerca de metade dele, ent\u00e3o checagens de 5 minutos adicionam em m\u00e9dia 2,5 minutos antes de qualquer um saber.<\/p>\n<p>Um caveat: a tabela assume uma \u00fanica checagem agendada e contagem de downtime baseada em intervalos. Confirma\u00e7\u00e3o multi-local e SLIs baseados em requisi\u00e7\u00e3o mudam detalhes, n\u00e3o o problema da amostragem.<\/p>\n<figure id=\"attachment_34580\" aria-describedby=\"caption-attachment-34580\" style=\"width: 1200px\" class=\"wp-caption alignnone\"><img decoding=\"async\" class=\"size-full wp-image-34580\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/error-budget-check-interval.webp\" alt=\"Gr\u00e1fico mostrando um intervalo de checagem de 5 minutos consumindo uma parte crescente do or\u00e7amento mensal de erro conforme metas SLO se apertam de 99% para 99,99%\" width=\"1200\" height=\"675\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/error-budget-check-interval.webp 1200w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/error-budget-check-interval-300x169.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/error-budget-check-interval-1024x576.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/error-budget-check-interval-768x432.webp 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><figcaption id=\"caption-attachment-34580\" class=\"wp-caption-text\">Conforme o SLO se aperta, um intervalo de checagem consome mais do or\u00e7amento. Em 99,99%, ultrapassa todo o or\u00e7amento.<\/figcaption><\/figure>\n<p>Falhas curtas tamb\u00e9m n\u00e3o s\u00e3o casos extremos. Entre as falhas que o Dotcom-Monitor detecta, cerca de 38% se resolvem em menos de 5 minutos. S\u00e3o principalmente oscila\u00e7\u00f5es de roteamento de rede, reinicializa\u00e7\u00f5es, rein\u00edcios e failovers que se corrigem antes que algu\u00e9m possa intervir razoavelmente, e nosso Filtro de Resposta segura o alerta exatamente por esse motivo. Mas filtradas do alerta n\u00e3o significa filtradas do registro: esses tempos de inatividade ainda contam contra o SLA, interno ou de fornecedor, e precisam ser contabilizados. Das falhas que disparam alerta, mais de 56% se resolvem em at\u00e9 15 minutos da primeira notifica\u00e7\u00e3o, cerca de 18% duram mais que uma hora, e aproximadamente 3% passam de 24 horas. A divis\u00e3o varia um pouco entre tipos de servi\u00e7os, mas a forma se mant\u00e9m: mais de um ter\u00e7o de todas as falhas est\u00e3o em um intervalo que uma checagem de 5 minutos mal consegue ver. Por isso a frequ\u00eancia de checagem \u00e9 uma decis\u00e3o de medi\u00e7\u00e3o, n\u00e3o s\u00f3 de custo: em intervalos de 1 minuto, o quantum de medi\u00e7\u00e3o cai para 2,3% de um or\u00e7amento mensal de 99,9% ao inv\u00e9s de 11,6%, e as falhas curtas que dominam os incidentes come\u00e7am a aparecer no seu registro. \u00c9 por isso que o Dotcom-Monitor executa checagens at\u00e9 a cada minuto e baseia seus relat\u00f3rios SLA nesses registros: o n\u00famero de conformidade que voc\u00ea mostra a um cliente \u00e9 t\u00e3o confi\u00e1vel quanto a amostragem por tr\u00e1s dele.<\/p>\n<h3 id='como-implementar-objetivos-de-n\u00edvel-de-servi\u00e7o'  id=\"boomdevs_5\">Como Implementar Objetivos de N\u00edvel de Servi\u00e7o<\/h3>\n<ul>\n<li>Defina dois ou tr\u00eas SLIs que seus usu\u00e1rios reconheceriam, como uptime medido de um navegador real ou tempo de checkout, e fa\u00e7a uma checagem Dotcom-Monitor ser a fonte oficial de cada um.<\/li>\n<li>Configure cada SLO mais restrito que o SLA que protege, depois ajuste a frequ\u00eancia de checagem do dispositivo para se adequar ao n\u00edvel: conforme a tabela acima, qualquer meta al\u00e9m de 99,9% necessita de checagens a cada 1 minuto.<\/li>\n<li>Agende relat\u00f3rios de uptime e SLA para as pessoas que gerenciam a conversa do SLA, para que o n\u00famero de conformidade venha do mesmo registro da checagem que gera os alertas.<\/li>\n<li>Combine antecipadamente o que acontece quando o or\u00e7amento de erro acabar, enquanto ningu\u00e9m discute um incidente espec\u00edfico.<\/li>\n<\/ul>\n<h2 id='princ\u00edpio-3-elimine-trabalho-repetitivo-toil'  id=\"boomdevs_6\" id=\"principle-3-eliminate-toil\">Princ\u00edpio 3 \u2013 Elimine Trabalho Repetitivo (Toil)<\/h2>\n<p>Toil \u00e9 trabalho manual, repetitivo que escala com o tamanho do servi\u00e7o e n\u00e3o produz valor duradouro. O <a href=\"https:\/\/sre.google\/sre-book\/eliminating-toil\/\" target=\"_blank\" rel=\"noopener\">cap\u00edtulo Eliminando Toil<\/a> definiu um limite famoso: SREs n\u00e3o devem gastar mais da metade do seu tempo com isso, e o resto em engenharia para eliminar o toil.<\/p>\n<p>Defini\u00e7\u00f5es abstratas fazem toil f\u00e1cil de concordar e dif\u00edcil de identificar. Ent\u00e3o nomeie-o. Na maioria dos times, ele se parece com isso:<\/p>\n<ul>\n<li>Algu\u00e9m entra todo dia de manh\u00e3 para confirmar se o fluxo de checkout ainda funciona.<\/li>\n<li>Algu\u00e9m testa manualmente o formul\u00e1rio de cadastro ap\u00f3s cada deploy.<\/li>\n<li>Algu\u00e9m mant\u00e9m um lembrete de calend\u00e1rio para datas de expira\u00e7\u00e3o de certificados SSL.<\/li>\n<li>Algu\u00e9m consulta uma API parceira manualmente sempre que os tickets de suporte aumentam, para saber se o problema \u00e9 do seu lado ou deles.<\/li>\n<\/ul>\n<p>Cada um desses \u00e9 uma transa\u00e7\u00e3o roteirizada esperando para ser escrita, e \u00e9 onde o Dotcom-Monitor ganha seu valor diretamente. Um script gravado com o <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/caracteristicas\/everystep\/\">EveryStep<\/a>, seu gravador de transa\u00e7\u00f5es point-and-click, percorre o mesmo caminho de checkout a cada poucos minutos em um navegador real e dispara um alerta no momento que qualquer passo falhar. Suas checagens de certificado acompanham a data de expira\u00e7\u00e3o sem precisar do calend\u00e1rio. As checagens de API sondam o endpoint parceiro numa agenda e mant\u00eam o hist\u00f3rico de tempo de resposta que resolve a discuss\u00e3o &#8220;nosso lado ou deles&#8221; num piscar de olhos.<\/p>\n<p>O teste para decidir o que automatizar primeiro n\u00e3o \u00e9 sofistica\u00e7\u00e3o, \u00e9 recorr\u00eancia. A checagem humana di\u00e1ria \u00e9 a que a m\u00e1quina deve fazer a cada minuto.<\/p>\n<h3 id='como-implementar-a-elimina\u00e7\u00e3o-de-toil'  id=\"boomdevs_7\">Como Implementar a Elimina\u00e7\u00e3o de Toil<\/h3>\n<ul>\n<li>Registre por uma semana todas as checagens manuais que algu\u00e9m no time faz; a recorr\u00eancia, n\u00e3o a dificuldade, decide o que automatizar primeiro.<\/li>\n<li>Grave a que mais se repete como um script EveryStep clicando pelo fluxo uma vez, depois deixe rodar a cada poucos minutos em vez de uma vez por manh\u00e3.<\/li>\n<li>Substitua o calend\u00e1rio de expira\u00e7\u00e3o do certificado pelas checagens SSL do Dotcom-Monitor, e coloque APIs parceiras em checagens programadas de servi\u00e7os web para que ningu\u00e9m precise lembrar delas de cabe\u00e7a.<\/li>\n<li>Monitore as horas de checagem manual removidas a cada trimestre, para que o trabalho de automa\u00e7\u00e3o continue vis\u00edvel e financiado.<\/li>\n<\/ul>\n<h2 id='princ\u00edpio-4-monitoramento-e-os-quatro-sinais-dourados'  id=\"boomdevs_8\" id=\"principle-4-monitoring-and-the-four-golden-signals\">Princ\u00edpio 4 \u2013 Monitoramento e os Quatro Sinais Dourados<\/h2>\n<p>O <a href=\"https:\/\/sre.google\/sre-book\/monitoring-distributed-systems\/\" target=\"_blank\" rel=\"noopener\">cap\u00edtulo Monitoramento de Sistemas Distribu\u00eddos<\/a> nomeia quatro sinais dourados: lat\u00eancia, tr\u00e1fego, erros e satura\u00e7\u00e3o. Acompanhe esses quatro e voc\u00ea pegar\u00e1 a maioria dos problemas.<\/p>\n<p>O cap\u00edtulo menciona monitoramento black-box, mas a maioria dos times acaba instrumentando os quatro sinais de dentro do sistema. Observe-os de onde seus usu\u00e1rios est\u00e3o, e tr\u00eas dos quatro mudam:<\/p>\n<div class=\"table-wrap\">\n<table>\n<thead>\n<tr>\n<th>Sinal<\/th>\n<th>Interno (APM, Prometheus, M\u00e9tricas de Servidor)<\/th>\n<th>Externo (Checagens Sint\u00e9ticas Externas)<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Lat\u00eancia<\/strong><\/td>\n<td>Tempo da aplica\u00e7\u00e3o e banco de dados. Exclui tudo que ocorre antes do pedido alcan\u00e7ar seus servidores.<\/td>\n<td>DNS + TCP + TLS + borda do CDN + transfer\u00eancia + renderiza\u00e7\u00e3o. O n\u00famero que o usu\u00e1rio realmente sente.<\/td>\n<\/tr>\n<tr>\n<td><strong>Tr\u00e1fego<\/strong><\/td>\n<td>Requisi\u00e7\u00f5es por segundo, totalmente vis\u00edveis.<\/td>\n<td>N\u00e3o observ\u00e1vel externamente. Uma checagem sint\u00e9tica gera seu pr\u00f3prio tr\u00e1fego; n\u00e3o v\u00ea o seu.<\/td>\n<\/tr>\n<tr>\n<td><strong>Erros<\/strong><\/td>\n<td>Taxa 5xx, contagem de exce\u00e7\u00f5es.<\/td>\n<td>O HTTP 200 que devolveu um checkout quebrado. O script de terceiros que falhou silenciosamente. O elemento da p\u00e1gina que nunca foi renderizado.<\/td>\n<\/tr>\n<tr>\n<td><strong>Satura\u00e7\u00e3o<\/strong><\/td>\n<td>CPU, mem\u00f3ria, profundidade da fila, pools de conex\u00e3o.<\/td>\n<td>N\u00e3o mensur\u00e1vel diretamente. Inferido a partir da lat\u00eancia que degrada conforme a carga sobe.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<figure id=\"attachment_34587\" aria-describedby=\"caption-attachment-34587\" style=\"width: 1200px\" class=\"wp-caption alignnone\"><img decoding=\"async\" class=\"size-full wp-image-34587\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/golden-signals-inside-vs-outside.webp\" alt=\"Diagrama dos quatro sinais dourados divididos por ponto de vista, mostrando quais sinais s\u00e3o vis\u00edveis de dentro da pilha versus do monitoramento sint\u00e9tico externo\" width=\"1200\" height=\"900\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/golden-signals-inside-vs-outside.webp 1200w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/golden-signals-inside-vs-outside-300x225.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/golden-signals-inside-vs-outside-1024x768.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2021\/11\/golden-signals-inside-vs-outside-768x576.webp 768w\" sizes=\"(max-width: 1200px) 100vw, 1200px\" \/><figcaption id=\"caption-attachment-34587\" class=\"wp-caption-text\">Dois dos quatro sinais dourados s\u00e3o totalmente vis\u00edveis apenas de um lado. Nenhum ponto de vista cobre tudo.<\/figcaption><\/figure>\n<p>Leia a tabela honestamente e a conclus\u00e3o n\u00e3o \u00e9 &#8220;exterior \u00e9 melhor.&#8221; \u00c9 que nenhum ponto de vista v\u00ea tudo. Tr\u00e1fego e satura\u00e7\u00e3o pertencem \u00e0s suas ferramentas internas: Prometheus, Datadog, New Relic, qualquer que seja sua pilha APM. Lat\u00eancia e erros na experi\u00eancia do usu\u00e1rio pertencem ao <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/solucoes\/synthetic-monitoring\/\">monitoramento sint\u00e9tico<\/a> externo. Essa \u00e9 a metade que o Dotcom-Monitor cobre. Checagens em navegador real de uma rede global carregam suas p\u00e1ginas como os usu\u00e1rios fazem e cronometrizam o caminho todo: resolu\u00e7\u00e3o DNS, handshake TLS, borda do CDN, renderiza\u00e7\u00e3o da p\u00e1gina, passos de usu\u00e1rio roteirizados. Checagens de protocolo para HTTP(S), API, DNS, TCP e ICMP acompanham as depend\u00eancias ao redor da p\u00e1gina. Os dois n\u00e3o competem; s\u00e3o vis\u00f5es diferentes dos mesmos quatro sinais, e voc\u00ea precisa de ambos.<\/p>\n<p>A regra pr\u00e1tica: todo sinal que seus usu\u00e1rios possam sentir precisa ter pelo menos uma medi\u00e7\u00e3o feita de onde os usu\u00e1rios est\u00e3o. Um painel APM mostrando verde enquanto o CDN entrega p\u00e1ginas de erro em cache a metade da Europa n\u00e3o \u00e9 hipot\u00e9tico. \u00c9 o modo padr\u00e3o de falha do monitoramento interno apenas.<\/p>\n<h3 id='como-implementar-o-monitoramento'  id=\"boomdevs_9\">Como Implementar o Monitoramento<\/h3>\n<ul>\n<li>Mantenha tr\u00e1fego e satura\u00e7\u00e3o em seu stack APM ou Prometheus; d\u00ea lat\u00eancia e erros para as checagens em navegador real do Dotcom-Monitor rodando das regi\u00f5es onde seus usu\u00e1rios realmente est\u00e3o.<\/li>\n<li>Configure asser\u00e7\u00f5es de conte\u00fado nessas checagens, n\u00e3o s\u00f3 checagens de c\u00f3digo de status, para que o checkout quebrado atr\u00e1s de um HTTP 200 falhe do mesmo jeito que falha para o usu\u00e1rio.<\/li>\n<li>Roteirize as transa\u00e7\u00f5es que importam (login, busca, checkout) com o EveryStep, para que o monitoramento percorra o mesmo caminho que seus usu\u00e1rios.<\/li>\n<li>Compare os n\u00fameros internos e externos regularmente; a lacuna entre eles \u00e9 sua camada de CDN, DNS e terceiros.<\/li>\n<\/ul>\n<h2 id='princ\u00edpio-5-automa\u00e7\u00e3o'  id=\"boomdevs_10\" id=\"principle-5-automation\">Princ\u00edpio 5 \u2013 Automa\u00e7\u00e3o<\/h2>\n<p>O argumento SRE para automa\u00e7\u00e3o \u00e9 consist\u00eancia em escala. Humanos esquecem passos, m\u00e1quinas n\u00e3o, e qualquer resposta que precise acontecer \u00e0s 3 da manh\u00e3 n\u00e3o deve depender de um humano alerta \u00e0s 3 da manh\u00e3.<\/p>\n<p>A parte que muda fora do Google: automa\u00e7\u00e3o \u00e9 t\u00e3o boa quanto o sinal que a aciona. Scripts de failover, jobs de rollback e regras de autoescalonamento disparam com um evento de detec\u00e7\u00e3o, ent\u00e3o todo minuto de atraso na detec\u00e7\u00e3o \u00e9 um minuto somado a cada resposta automatizada que voc\u00ea construiu. A matem\u00e1tica da se\u00e7\u00e3o SLO se aplica diretamente: um failover automatizado disparado por uma checagem de 5 minutos d\u00e1 \u00e0 falha uma vantagem m\u00e9dia de 2,5 minutos.<\/p>\n<p>E alguns gatilhos de automa\u00e7\u00e3o s\u00f3 podem vir de fora. Um script que faz failover para um provedor de pagamento reserva precisa saber que o prim\u00e1rio est\u00e1 falhando para os usu\u00e1rios, n\u00e3o s\u00f3 que o endpoint de sa\u00fade responde ping dentro da mesma rede. O Dotcom-Monitor fecha esse ciclo disparando <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/caracteristicas\/recursos-alertas\/\">alertas<\/a> e webhooks pelas suas checagens externas, ent\u00e3o o failover \u00e9 disparado pelo que os usu\u00e1rios est\u00e3o vivenciando, n\u00e3o pelo que o endpoint de sa\u00fade afirma.<\/p>\n<h3 id='como-implementar-automa\u00e7\u00e3o'  id=\"boomdevs_11\">Como Implementar Automa\u00e7\u00e3o<\/h3>\n<ul>\n<li>Comece pelas respostas que voc\u00ea j\u00e1 faz manualmente durante incidentes: reinicializa\u00e7\u00f5es, failovers, rollbacks.<\/li>\n<li>Integre os webhooks de alerta do Dotcom-Monitor aos scripts que realizam essas a\u00e7\u00f5es, para que o gatilho seja uma falha confirmada externamente e n\u00e3o um endpoint interno de sa\u00fade.<\/li>\n<li>Use grupos de escalonamento de alerta para que a primeira notifica\u00e7\u00e3o alcance a pessoa ou sistema que age, e n\u00e3o uma caixa de entrada compartilhada que ningu\u00e9m monitora \u00e0s 3 da manh\u00e3.<\/li>\n<li>Deixe o Filtro de Resposta absorver falhas que se resolvem sozinhas para que elas n\u00e3o acionem suas automa\u00e7\u00f5es, e revise os gatilhos trimestralmente contra as taxas de falsos positivos.<\/li>\n<\/ul>\n<h2 id='princ\u00edpio-6-engenharia-de-releases'  id=\"boomdevs_12\" id=\"principle-6-release-engineering\">Princ\u00edpio 6 \u2013 Engenharia de Releases<\/h2>\n<p>Engenharia de releases \u00e9 a disciplina de construir e entregar software da mesma maneira toda vez: builds versionados, pipelines repet\u00edveis, rollbacks que funcionam porque foram ensaiados.<\/p>\n<p>CI\/CD moderno cobre a maior parte disso dentro do pipeline. Testes passam, artefatos s\u00e3o constru\u00eddos, deploys s\u00e3o enviados atr\u00e1s de flags. O que o pipeline n\u00e3o consegue dizer \u00e9 se o sistema funciona para usu\u00e1rios ap\u00f3s o deploy. CI prova o build; por si s\u00f3 n\u00e3o diz nada sobre o registro DNS que n\u00e3o propagou, o cache do CDN servindo o pacote antigo, a tag de terceiros que quebrou em combina\u00e7\u00e3o com seu c\u00f3digo novo, ou o valor de configura\u00e7\u00e3o que s\u00f3 existe em produ\u00e7\u00e3o.<\/p>\n<p>\u00c9 a verifica\u00e7\u00e3o p\u00f3s-deploy que preenche essa lacuna. Um script EveryStep que percorre o caminho cr\u00edtico (carrega a p\u00e1gina, faz login, finaliza a transa\u00e7\u00e3o), rodado da rede do Dotcom-Monitor contra produ\u00e7\u00e3o imediatamente ap\u00f3s cada release, \u00e9 o \u00fanico teste que exercita o que os usu\u00e1rios realmente recebem. Times que o adotam tratam como a etapa final do pipeline: deploy, verificar de fora, e s\u00f3 ent\u00e3o marcar o release como conclu\u00eddo. Se a checagem falha, o rollback ocorre enquanto o raio de impacto ainda \u00e9 medido em minutos.<\/p>\n<h3 id='como-implementar-engenharia-de-releases'  id=\"boomdevs_13\">Como Implementar Engenharia de Releases<\/h3>\n<ul>\n<li>Versione todo build e fa\u00e7a rollback ser uma a\u00e7\u00e3o ensaiada, de um passo, n\u00e3o improvisada.<\/li>\n<li>Fa\u00e7a uma transa\u00e7\u00e3o EveryStep contra produ\u00e7\u00e3o a etapa final do pipeline de deploy, rodando da rede Dotcom-Monitor para que DNS, cache CDN e tags de terceiros fa\u00e7am parte do teste.<\/li>\n<li>Direcione o webhook de alerta da checagem de volta para o pipeline, para que uma execu\u00e7\u00e3o p\u00f3s-deploy com falha vire um sinal autom\u00e1tico de rollback e n\u00e3o um ticket para de manh\u00e3.<\/li>\n<li>Mantenha a mesma checagem rodando entre releases; seu hist\u00f3rico \u00e9 a linha de base para saber se um deploy deixou as coisas mais lentas.<\/li>\n<\/ul>\n<h2 id='princ\u00edpio-7-simplicidade'  id=\"boomdevs_14\" id=\"principle-7-simplicity\">Princ\u00edpio 7 \u2013 Simplicidade<\/h2>\n<p>O <a href=\"https:\/\/sre.google\/sre-book\/simplicity\/\" target=\"_blank\" rel=\"noopener\">cap\u00edtulo Simplicidade<\/a> argumenta que confiabilidade e complexidade est\u00e3o em conflito: cada componente que voc\u00ea adiciona \u00e9 um componente que pode falhar, e o software deve ser exatamente t\u00e3o complexo quanto precisa para seu trabalho.<\/p>\n<p>Aplique isso \u00e0 pilha de monitoramento em si, porque o monitoramento \u00e9 onde a complexidade se acumula silenciosamente. Times acabam com uma ferramenta APM, uma plataforma de logs, um pingador de uptime, um servi\u00e7o de p\u00e1gina de status e tr\u00eas dashboards que ningu\u00e9m abre. Cada ferramenta alerta conforme seu pr\u00f3prio cronograma, e o resultado combinado \u00e9 a fadiga de alertas: tantas notifica\u00e7\u00f5es que a que importa \u00e9 apagada junto com o resto.<\/p>\n<p>Um fornecedor de monitoramento dizendo para voc\u00ea usar menos ferramentas de monitoramento \u00e9 um argumento incomum, exatamente por isso vale a pena faz\u00ea-lo. O teste de simplicidade para uma pilha de monitoramento tem duas perguntas. Primeiro: para cada coisa que voc\u00ea monitora, voc\u00ea sabe qual ferramenta \u00e9 autorit\u00e1ria quando duas discordam? Segundo: cada alerta que dispara tem uma pessoa que age sobre ele? Se uma ferramenta falhar nessas duas perguntas para tudo o que monitora, ela n\u00e3o est\u00e1 monitorando, \u00e9 barulho com taxa de assinatura. Consolidar <a href=\"https:\/\/www.dotcom-monitor.com\/pt-br\/solucoes\/uptime\/\">monitoramento de uptime<\/a>, transa\u00e7\u00f5es, API e infraestrutura numa s\u00f3 plataforma com um caminho \u00fanico de alerta \u00e9 uma decis\u00e3o de simplicidade antes de uma decis\u00e3o de compra. \u00c9 assim que o Dotcom-Monitor \u00e9 constru\u00eddo: essas checagens em um lugar s\u00f3, um caminho \u00fanico de alerta, trabalhando junto com a ferramenta APM que monitora o interno, em vez de substitu\u00ed-la.<\/p>\n<h3 id='como-implementar-simplicidade'  id=\"boomdevs_15\">Como Implementar Simplicidade<\/h3>\n<ul>\n<li>Inventarie suas ferramentas de monitoramento e anote, para cada uma, a \u00fanica coisa para a qual \u00e9 autorit\u00e1ria.<\/li>\n<li>Delete todo alerta que n\u00e3o tem dono e nenhuma a\u00e7\u00e3o associada; se ningu\u00e9m age, \u00e9 barulho.<\/li>\n<li>Integre as checagens externas (uptime, p\u00e1gina, transa\u00e7\u00e3o, API, infraestrutura) no Dotcom-Monitor como uma plataforma \u00fanica com um caminho \u00fanico de alertas, e deixe seu APM cuidar do interno.<\/li>\n<li>Repita a auditoria anualmente; pilhas de monitoramento acumulam complexidade sozinhas.<\/li>\n<\/ul>\n<h2 id='melhores-pr\u00e1ticas-sre'  id=\"boomdevs_16\" id=\"sre-best-practices\">Melhores Pr\u00e1ticas SRE<\/h2>\n<p>Os princ\u00edpios dizem o que buscar. Estas s\u00e3o as pr\u00e1ticas que se mant\u00eam nos times que n\u00e3o possuem toda a pilha:<\/p>\n<ul>\n<li><strong>Defina SLOs no que os usu\u00e1rios experienciam, n\u00e3o no que os servidores reportam.<\/strong> &#8220;Checkout finaliza em menos de 4 segundos em um navegador real&#8221; \u00e9 um SLO que os usu\u00e1rios reconhecem. &#8220;API p95 abaixo de 200ms&#8221; \u00e9 um insumo para isso.<\/li>\n<li><strong>Adapte a frequ\u00eancia de checagem ao seu SLO.<\/strong> Conforme a tabela do or\u00e7amento de erros acima: em 99,95%, um quantum de 5 minutos j\u00e1 consome 23% do or\u00e7amento mensal, e em 99,99% ultrapassa o or\u00e7amento completamente. Trate checagens de 1 minuto como o limite pr\u00e1tico a partir de 99,95%.<\/li>\n<li><strong>Monitore suas depend\u00eancias como monitora a si mesmo.<\/strong> DNS, CDN, pagamento, autentica\u00e7\u00e3o: uma checagem externa para cada depend\u00eancia cr\u00edtica, com seu pr\u00f3prio hist\u00f3rico de tempo de resposta. Quando a p\u00e1gina de status delas mostra verde e seus usu\u00e1rios dizem &#8220;quebrado&#8221;, esses dados resolvem a disputa.<\/li>\n<li><strong>Escreva a pol\u00edtica de or\u00e7amento de erro antes de gastar o or\u00e7amento.<\/strong> Concorde de antem\u00e3o o que acontece quando o or\u00e7amento acaba: congelamento de funcionalidades, sprints de confiabilidade, prioridades de postmortem. Um or\u00e7amento sem pol\u00edtica \u00e9 um gr\u00e1fico que ningu\u00e9m usa.<\/li>\n<li><strong>Ensaie a resposta a incidentes antes de precisar.<\/strong> Plant\u00f5es, caminhos de escalonamento e postmortems sem culpados s\u00e3o abordados em profundidade no nosso guia de <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/gerenciamento-de-incidentes-sre-visao-geral-tecnicas-e-ferramentas\/\">gest\u00e3o de incidentes SRE<\/a>.<\/li>\n<li><strong>Mantenha honesta a contagem de ferramentas.<\/strong> Audite anualmente a pilha de monitoramento contra as duas perguntas de simplicidade acima. Nossa sele\u00e7\u00e3o de <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/principais-13-ferramentas-de-engenheiro-de-confiabilidade-do-site-sre\/\">ferramentas SRE<\/a> cobre as categorias que valem a pena.<\/li>\n<li><strong>Fa\u00e7a do relat\u00f3rio de confiabilidade um h\u00e1bito, n\u00e3o uma corrida contra o tempo.<\/strong> Relat\u00f3rios agendados de uptime e SLA fazem a conversa de conformidade come\u00e7ar a partir de n\u00fameros compartilhados, e n\u00e3o de uma ca\u00e7a no log ap\u00f3s desacordo.<\/li>\n<\/ul>\n<h2 id='conclus\u00e3o'  id=\"boomdevs_17\" id=\"the-bottom-line\">Conclus\u00e3o<\/h2>\n<p>Os sete princ\u00edpios SRE sobreviveram \u00e0 sa\u00edda do Google. O que n\u00e3o sobreviveu foi a suposi\u00e7\u00e3o por tr\u00e1s deles: que o time que os aplica controla a pilha onde aplicam. Voc\u00ea n\u00e3o controla, e isso muda o trabalho. O risco que voc\u00ea n\u00e3o pode eliminar pela engenharia precisa ser medido. Or\u00e7amentos de erro s\u00e3o t\u00e3o reais quanto o intervalo da checagem por tr\u00e1s deles. Ferramentas internas monitoram tr\u00e1fego e satura\u00e7\u00e3o; lat\u00eancia experienciada pelo usu\u00e1rio e erros s\u00f3 aparecem de um ponto de vista externo. A verifica\u00e7\u00e3o p\u00f3s-deploy precisa rodar de fora, porque s\u00f3 l\u00e1 o sistema inteiro existe.<\/p>\n<p>O fio condutor comum \u00e9 a medi\u00e7\u00e3o de fora. Cada princ\u00edpio, aplicado a uma pilha cheia de componentes que voc\u00ea n\u00e3o possui, acaba precisando de um ponto de vista independente: checagens por depend\u00eancia para risco, intervalos de 1 minuto para or\u00e7amentos de erro, navegadores reais para os sinais dourados, transa\u00e7\u00f5es roteirizadas para toil e releases, uma plataforma para simplicidade. Esse \u00e9 o papel que o Dotcom-Monitor desempenha em todos os sete. N\u00e3o \u00e9 prefer\u00eancia de ferramenta \u2014 \u00e9 o que os princ\u00edpios exigem quando a pilha deixa de ser sua.<\/p>\n<section class=\"final-cta\">\n<h2 id='me\u00e7a-a-pilha-que-voc\u00ea-n\u00e3o-possui'  id=\"boomdevs_18\" id=\"see-what-external-checks-catch\">Me\u00e7a a Pilha que Voc\u00ea N\u00e3o Possui<\/h2>\n<p>Execute checagens em navegador real em intervalos de 1 minuto a partir de uma rede global, e veja o que seu or\u00e7amento de erro tem perdido. <a href=\"https:\/\/userauth.dotcom-monitor.com\/Account\/FreeTrialSignUp?SolutionType=Monitoring\">Comece um teste gratuito<\/a>.<\/p>\n<\/section>\n","protected":false},"excerpt":{"rendered":"<p>Os 7 princ\u00edpios de SRE, reescritos para equipes que n\u00e3o possuem toda a sua pilha. O que falha fora do Google, e o que medir em vez disso.<\/p>\n","protected":false},"author":8,"featured_media":34578,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5170],"tags":[],"class_list":["post-22389","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-nao-categorizado"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/posts\/22389","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/comments?post=22389"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/posts\/22389\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/media\/34578"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/media?parent=22389"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/categories?post=22389"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/pt-br\/wp-json\/wp\/v2\/tags?post=22389"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}