Sincronizar tempo e deriva

1) Por que o tempo - componente arquitetônico

• quebrar o Kerberos/OAuth/JWT (campos 'iat/nbf/exp');
• distorcer métricas/trailers e alertas;
• rolar corretores/clientes (temporizadores, retraias, backoff exponencial);
• perturbar a ordem e a idimpotência nos cenários distribuídos.

• Offset é a diferença de tempo local da referência.
• Skew (separação) é a diferença entre os nós.
• Draft (à deriva) - velocidade de saída do relógio (ppm) quando não há correção.
• Jitter - variabilidade de atrasos/medidas.

2) Fontes e protocolos de tempo

2. 1 NTP (Network Time Protocol)

Stratos (Stratum 1 - diretamente de GNSS/rádio, Stratum 2 - de Stratum 1, etc).

• slew (ajuste suave de frequência, seguro para aplicativos);
• step (salto de tempo; indesejável na venda).
• Implementações: crony, ntpd, systemd-timesyncd. Para servidores - de preferência crony.

2. 2 NTS (NTP over TLS)

Sincronização autenticada (proteção contra MITM e troca de tempo).
Recomendado para servidores de horário externos.

2. 3 PTP / IEEE 1588

Marcas de tempo de hardware (hardware timestamping) em NIC/ToR, milhões e microssegundos de precisão.
Modos: boundary/transparent clock, perfis de telecom/enterprise.
Usar para SLO rígido para ordem p99, HFT/telecom/indústria.

2. 4 GNSS (GPS/GLONASS) e PPS

Os receptores locais fornecem um PPS (pulse-por-segundo) de referência para o Stratum 1.
É importante considerar spufing/silenciamento - colocar antenas e monitor de integridade.

2. 5 Nuvens

Fontes de nuvem (intrínseca stratum-pool) reduzem off e jitter dentro do VPC.
Para ambientes híbridos - combine os parâmetros locais e de nuvem.

3) Tempo em OS e ferro

TSC/HPET/PTC: Os CPU modernos mantêm o TSC como um contador monótono rápido; fixa a frequência (invariant TSC).
Virtualização/contêineres: à deriva e «salto» com mais frequência. Hipervisor - serviço de tempo rigoroso; Os convidados são crony.
A economia de energia pode interferir na monotonia dos temporizadores - verifique as opções BIOS/UEFI.

4) Relógio monótono e «aço»

Wall-clock (tempo real, TZ/UTC) - para logs, marcas de eventos, pessoas.
Monotonic clock - para medição de intervalos/temporizações.

• Linux: `CLOCK_MONOTONIC`.
• C++: `std::chrono::steady_clock`.
• Go: partes monótonas incorporadas 'time. Time 'em intervalos.
• Java: `System. nanoTime () 'para longas, não para calendário.

Regra: Dedline e retais - em relógios monótonos; seriado/logado - em UTC.

5) Leap segundo/» leap smear» e armadilhas de calendário

O Leap segundo pode causar «00:59:60» ou uma repetição de segundo → galhos em temporais/métricas.

• Smear (flutuação suave de segundos em N horas).
• Passo (indesejado).
• Nunca dependa de um TZ/horário de verão local para a lógica; guarde o UTC e mostre no TZ do usuário.
• Atualize o TZDB - mudanças políticas acontecem.

6) Alinhamento de ordem sem confiança em «parede»

Lamport clocks e Vector clocks - relações de causa e efeito sem relógio físico.
Hybrid Logical Clocks (HLC) - Combinam tempo físico e contador, resistentes a um pequeno skew.
Modelos como o TruTime - retornam o intervalo '[earliest, latest]' e exigem um commit-wait para ser seriado.

7) Efeitos do tempo sobre protocolos e sistemas

Segurança: O Kerberos permite um skew pequeno (normalmente se 5 minutos), TLS/certificados sensíveis a 'notBefore/notAfter', JWT a 'exp/nbf/iat'.
Corretores/filas: Os deadline de tarefas/visibility timeout dependem da hora certa.
SUBD/clusters: conflito de versões por 'updated _ at '/ts - digite HLC/versões, em vez de comparar wall-timestamps crus.
Streaming: distingue entre event time e processing time; configure watermarks e lateness.
Crone/Planificadores: A deriva leva a um «pouso »/duplo lançamento. Use intervalos e chaves monótonas.

8) Observabilidade e tempo SLO

8. 1 Métricas

`time. offset _ ms '(offset ao árbitro),' time. jitter_ms`, `stratum`, `root_delay`, `root_dispersion`.
Для PTP: `path_delay`, `grandmaster_offset`, `gm_identity`, `clock_class`.
Alerts: off> limiar (por exemplo, 100-500 ms), perda de fonte, step-correção.

8. 2 Diagnósticos

`chronyc tracking/sources/sourcestats`

`ntpq -p`, `ntpstat`

PTP: 'pmc', ferramentas de venda NIC/ToR.

8. 3 SLO/orçamento errado

Exemplo SLO: "median offset ≤ 1 ms, p99 offset ≤ 25 ms, no step em nós de prod; PTP grandmaster failover ≤ 2 s».

9) Práticas de configuração (Linux/containers/K8s)

9. 1 crony (recomendado)

pool time. example. org iburst maxsamples 9 nts makestep 0. 5 1 # one step at big error at start rtcsync # synchronize hardware clock leapsectz right/UTC # leap seconds from tzdata driftfile/var/lib/chrony/drift

• `maxsources`, `minsamples/maxsamples`, `maxslewrate`.
• Para o DC isolado é um árbitro local + GPS/PPS.

9. 2 Contêineres e nós

Faça a sincronização no hóspede; Os contentores usam o núcleo.
Em K8s - DaemonSet com crony ou agente de tempo node-level; impeça a entrada de tempo por aplicativos.

9. 3 pilhas PTP

NIC com timestamping de hardware, demônio PTP, boundary clocks em ToR.
Espalmar domínios PTP (perfis), proteger contra «maus» grandmaster.

10) Segurança do tempo

NTS/Autenticado NTP, filtros e rate-limit (reforço NTP - vetor DDoS).
Segurança PTP: isolamento L2, LCA para multicast, monitoramento spoofing GM.
GNSS: antenas com boa visão, detecção de spoofing/jamming, fontes fallback.

11) Máquinas de engenharia e código

11. 1 Deadline/temporizadores

Guarde os dedline como «partida monótona + delta», em vez de wall-timestamp absoluto.
Adicione sempre um estoque no skew (por exemplo, 2 x p99-skew esperado para o TTL token).

11. 2 Comparação de versões

• versionagem/ETag;
• HLC/seq;
• bloqueios otimistas.

11. 3 Logs e traçados

Sempre UTC; inclua o campo 'time _ offset _ ms' no logs do agente.
Amaldiçoe o event-time nos eventos de rastreamento.

11. 4 Processamento de leap segundo

Selecione uma política (smear/step) uniformizada em todos os nós.
Teste: as métricas não devem ser «quebradas» em segundo.

12) Impacto sobre domínios

Auth: tokens - Leve em conta «clock skew allowance» (por exemplo, de 2 a 5 minutos).
Payments/seqüências de tempo: Arredem os intervalos em vez de tempo absoluto.
Corretores: horários de retrações - em relógios monótonos.
BD/TTL: TTL em Redis/DB - baseado no relógio local - coloque o estoque.
Analista: agregações de tempo - Use uma única UTC e sincronização ingestão.

13) Playbooks de teste (Game Days)

Draft inhation: desviar artificialmente o relógio para +/- M; verificar auth, corretores, SLO.
Outage NTP: desativar as fontes, monitorar o drive e a conversão automática.
Leap segundo/smear: simulação de chegada leap, avaliação de gráficos/temporizadores.
PTP GM failover: verificar a hora de mudança e off-set depois.
VM suspend/resume: certifique-se de que não há «saltos» e step nos hóspedes.

14) Anti-pattern

Comparar eventos de diferentes nós em wall-time sem HLC/seq.
Coloque os «locais de linha» do tempo (com TZ) no banco de dados em vez do UTC.
Permitir que aplicativos façam 'data -s '/' timedatectl set-time'.
Activar correções step na venda sem planejamento.
Ignorar atualizações TZDB e regras de horário de verão.
Usar wall-clock para backoff/temporizadores/token-TTL sem reserva para skew.
Tentar «tratar a ordem» com tempo físico em vez do relógio lógico.

15) Folha de cheque de implementação

• Política unificada: NTP (com NTS) ou PTP; uma lista de fontes confiáveis.
• Os nós estão configurados para slew, step apenas no início.
• Política unificada leap segundo (smear/step) para todos os clusters.
• Monitoramento off, jitter, stratum/PTP indicadores; Alertas.
• Aplicativos usam relógios monótonos para intervalos/deadline.
• Para ordem/conflito - HLC/versões, não wall-timestams.
• Reservas em skew em TTL de tokens, certificados, agendamentos.
• K8s/VM: sincronização em hosts, contêineres sem permissão para alterar o tempo.
• Documentação e runbooks sobre falhas de tempo, game days no calendário CI/CD.
• Atualizações regulares do TZDB, verificação de comportamento em eventos DST/leap.

16) FAQ

Q: Quando você precisa de PTP em vez de NTP?
A: Quando o SLO requer microssegundos-dezenas de microssegundos (TV/HFT/indústria) e há suporte para marcas de hardware na rede/mapas.

Q: Quanto colocar no clock skew?
A: Para um NTP típico na DC - dezenas a centenas de ms (p99); coloque 2 x reserva. Com PTP, unidades a dezenas de Iss.

Como sobreviver ao leap segundo?
A: Usar smear e políticas idênticas em todos os lugares; testar gráficos/agregadores e temporizadores.

Pode depender de wall-clock para deadline?
A: Não. Apenas um relógio monótono + reserva em skew.

Como guardar «tempo» na Base de Dados?
A: UTC ('timestamptz'), mais versões/HLC para resolver conflitos; Não guarde áreas locais nos dados.

17) Resultados

Tempo seguro é protocolo + política + disciplina no código. Sincronize nódulos (NTP/NTS ou PTP), use relógios para intervalos, UTC para dados, HLC/versão de ordem, coloque reservas em skew, monitora o off-set e realize o game days regularmente. Assim, você vai evitar as bagagens de autenticação «mística», divergências de eventos e SLO instável.