Rastreamento de farmácias

1) Por que monitor de farmácia

Farmácia - parte do tempo em que o serviço está disponível para o usuário. Esta é a «primeira linha» de observabilidade, notar instantaneamente a indisponibilidade, degradação da rede, falha DNS/TLS, problemas de roteamento ou CDN. Para sistemas altamente ajustados e regulados (fintechs, iGaming), a farmácia afeta diretamente a receita, o cumprimento de SLA e os riscos penais.

2) Termos e fórmulas

SLI disponibilidade: 'SLI = (verificações bem sucedidas/todas as verificações) x 100%'.
SLO: disponibilidade de destino por janela (normalmente de 28 a 30 dias), como 99. 9%.
SLA: obrigação externa; Sempre ≤ um SLO interno.
MTBF/MTTR: tempo médio entre falhas/tempo médio de recuperação.

99. 0% → £432 min de indisponibilidade

99. 9% → £43 min

99. 99% → ~4. 3 min

99. 999% → £26 segundos

3) Que verificações são necessárias (caixa preta)

Executados a partir de pontos externos (diferentes regiões/provedores) para ver o serviço «olhos do cliente».

1. ICMP (ping) - rede básica/disponibilidade do nó. Rápido, mas não reflete o sucesso dos negócios.
2. TCP connect - A porta está ouvindo? Útil para corretores/BD/SMTP.
3. HTTP/HTTPS - status, cabeçalhos, tamanho, redirectos, tempo até o primeiro byte.
4. TLS/certificados - validade, cadeia, algoritmos, SNI, protocolos.
5. DNS - A/AAAA/CNAME, Saúde NS, Distribuição, DNSSEC.
6. gRPC - status de chamada, deadline, metadados.
7. Um aperto de mão, uma ligação, uma mensagem-eco.
8. Proxy/Routing/CDN - diferentes PoP, hash-up do cachê, geo-opções.
9. Cenários sintéticos transacionados (cliques/formulários): «login → busca → depósito (caixa de areia)».
10. Heartbeat/cron monitorização - o serviço é obrigado a «pulsar» (gancho a cada N minutos); sem sinal, alerta.

• Coloque os times mais perto do UX real (por exemplo, TTFB ≤ 300 ms, total ≤ 2 s).
• Verifique o conteúdo assertado (palavra-chave/campo JSON) para que «200 OK» com erro não seja considerado um sucesso.
• Duplique as verificações através de provedores independentes e redes (multi-hop, ASN diferente).

4) Caixa branca e saúde do serviço

Liveness/Readiness amostras para orquestrador (processos vivos? Prontos para o tráfego?).
Saúde das Dependências: BD, kesh, corretor de eventos, API externa (pagamentos/KYC/AML).
Sinalização/degradação de fichas: desativamos caminhos não críticos com problemas.

As provas brancas não substituem as verificações externas: o serviço pode ser «saudável dentro», mas não está disponível para o usuário devido ao DNS/TLS/rota.

5) Geografia e multiregionalidade

Execute sintéticos das principais regiões de tráfego e junto aos provedores de dependências críticas.
Quórum: O incidente é registrado se a região N falhar (por exemplo, 2 de 3) para cortar as anomalias locais.
O limite por cômodos é SLI/SLO individuais para segmentos importantes (países, VIP, operadoras de comunicações).

6) Política de alertas (mínimo ruído)

Região Multi + multi-amostra: pager apenas quando o fracasso é acordado (por exemplo, HTTP e TLS simultaneamente, ≥ 2 regiões).
N fracassos sucessivos ou uma janela de 2-3 minutos antes do paige.

• L1: on-call (serviços de produção).
• L2: rede/plataforma/segurança, dependendo da assinatura da falha.
• Encerramento automático: depois de estáveis M verificações de sucesso.
• Relógios silenciosos/concessões - para serviços internos não críticos - apenas tíquetes, sem pager.

7) Status-página e comunicação

Página de status público (cliente) e privada (interna).
Incidentes automáticos de sintéticos + anotações manuais.
Modelos de mensagens: detetado - identificado - impacto - rota de volta - ETA - resolvido - pós-cara.
Janelas de planejamento: declaração prévia, exceções a considerar separadamente do SLO.

8) Contabilidade de dependências externas

Para cada provedor (pagamentos, KYC, e-mails, CDN, nuvens) são as suas verificações de várias regiões.
Rota Failover: Mudança automática para provedor alternativo por sintética.
SLO individual ao nível do provedor e e2e-SLO integral.
Negociar SLA com provedores (status-webhooks, prioridade de suporte).

9) Dashboards e widgets-chave

Mapa do mundo com estado de verificação (HTTP, DNS, TLS).
Timeline incidentes com anotações de lançamentos/bandeiras.
P50/P95/P99 TTFB/TTL/latency por região.
Disponibilidade por grupo (país/provedor/dispositivo).
MTTR/MTBF, tendências de «minutos de inatividade» e «burn-down» orçamento de disponibilidade por mês.
Melhores causas de fracasso (TLS-expedy, DNS-resolving, 5xx, timeouts).

10) Processo de incidente (cenário rápido)

1. A região multi/multi-tipo alert está a funcionar.
2. O responsável confirma, ativa o congelamento, avisa os proprietários.
3. Diagnóstico rápido: status DNS/TLS/CDN, lançamentos recentes, cronograma de erros.
4. Contornar: mudança de rota, conteúdo folback/provedor, ativação do modo de degradação.
5. Restauração: verificar que sintético/tráfego real verde.
6. Comunicação no status da página; encerramento do incidente.
7. RCA e action items: correções, testes, alertas, playbooks.

11) Relatórios SLA/SLO

Relatórios mensais: farmácia por serviço/região, minutos de interrupção, MTTR, razões.
Comparação com SLA: crédito/compensação, se aplicável.
A atualização de liminares, distribuição de sintéticos, lista de dependências.

12) Modelos de verificação (exemplo)

• Método: 'GET/healthz/público' (sem segredos).
• Timeout: 2 c, retry: 1.
• Sucesso: '2xx', cabeçalho 'X-App-Versão' presente, campo JSON 'status'.

• Prazo> 14 dias, cadeia de validade, protocolos 'TLS 1. 2 + ', SNI correto.

• Tempo de resposta ≤ 100 ms, os registros A/AAAA estão de acordo com o plano, sem SERVFAIL/REFUSED.

• Webhook '/beat/< service a.' a cada 5 minutos; falta de 2 sinais consecutivos - alert L2 (tarefas de fundo/ETL).

13) Folha de cheque de implementação

• Verificações externas multi-regionais (HTTP/TCP/DNS/TLS/cenários profundos).
• Provas brancas de readiness/liveness para orquestrador.
• Separação de caminhos críticos/não críticos, bandeiras fichas de degradação.
• Quórum e debouns em alertas, escalada e fechamento de carro.
• Página pública e interna, modelos de mensagem.
• Verificações individuais e SLO para provedores externos + failover automático.
• Dashboards: mapa, timeline, marcação, minutos de inatividade, MTTR/MTBF.
• Relatórios regulares de SLA/SLO e RCA pós-incidente.

14) Erros frequentes

Somente uma porta ping/sem NTR/conteúdo é «verde» quando a indisponibilidade real.
Um ponto de monitoramento são conclusões falsas positivas/negativas.
Falta de controle TLS/DNS - interrupções repentinas devido ao atraso/misconfig.
Alertas por falhas isoladas de uma região/tipo de verificação.
Nenhuma relação com as alterações - não há anotações de lançamento ou bandeiras em dashboards.
Dependências não contabilizadas - o provedor de pagamentos caiu e o status geral é verde.

15) Resultado

Rastreamento de farmácias não é apenas «picar URL». É um sistema de verificação sintética de regiões reais, alertas inteligentes sem ruídos, comunicação transparente através do status-página, contabilidade de dependências externas e relatórios rigorosos. O monitoramento adequado da farmácia reduz a MTTR, protege a SLA e mantém a experiência do usuário previsível.