Latest / We The People, in Tech or Not: O Debate / O Azure SQL Database agora fala o horário local. Veja o que quebrou no meu laboratório.

Transcript

O Azure SQL Database agora fala o horário local. Veja o que quebrou no meu laboratório. · We The People, in Tech or Not: O Debate

• 0:00
  WeThePeople In Tech or Not, o debate. Bem-vindo ao WeThePeople In Tech or Not, o debate.
• 0:07
  Este é um podcast gerado por inteligência artificial, baseado em um post da newsletter WeThePeople In Tech or Not, escrito por Alex Rosa.
• 0:15
  O nosso objetivo aqui é ajudar você, ouvinte, a aprender novas formas de explicar temas técnicos, desde o nível de quem é iniciante e não trabalha com tecnologia, até o nível de um especialista.
• 0:25
  É, hum, e pra começar, imagina a seguinte cena: o CEO da sua empresa ou a diretora financeira abre um relatório milionário de vendas logo de manhã.
• 0:35
  Aí ela olha os números e, tipo, percebe que o sistema diz que metade daquelas vendas altíssimas só vai acontecer amanhã. Nossa, o caos, né? Total.
• 0:44
  É exatamente essa confusão temporal, sabe, essa dor de cabeça corporativa que a gente vai dissecar no nosso debate de hoje. Com certeza.
• 0:51
  Olha, no dia 28 de setembro, a Microsoft anunciou que o banco de dados Azure SQL agora suporta fusos horários locais. É uma versão de testes públicos, né? O que a gente chama de preview.
• 1:03
  E pra colocar todo mundo na mesma página, até esse anúncio, todo banco de dados na nuvem da Microsoft vivia, hum, obrigatoriamente em apenas um fuso horário, o UTC, que é o Tempo Universal Coordenado.
• 1:14
  Ou seja, em termos práticos, o coração do seu sistema vivia com o relógio travado no horário de Londres, ignorando completamente onde a sua empresa de fato operava. Exato.
• 1:24
  Pensa no UTC como esse horário de Londres, sem variação de horário de verão.
• 1:29
  Então, tipo, se a sua operação física estivesse no Texas às 8:49 da noite e o aplicativo perguntasse ao banco de dados que horas são agora, usando aquela função técnica muito comum, o get date. Uhum, supercomum.
• 1:41
  Pois é, o sistema jamais responderia 8:49. Ele faria a conta pro horário universal e diria 1:49 da manhã do dia seguinte.
• 1:50
  Mas agora, hum, com um simples comando, o motor de dados pode responder no seu horário local, seja do Texas, de Tóquio, de São Paulo. E aí que o jogo muda. Muda muito.
• 2:01
  E é aqui que a gente desenha as linhas da nossa discussão, porque eu defendo que essa novidade, que pode parecer só um, ah, um detalhe burocrático de configuração, na verdade é uma vitória técnica gigantesca.
• 2:13
  Baseado nos 15 testes de laboratório do autor do texto, eu vejo isso como a solução pra um dos maiores gargalos modernos: migrar sistemas antigos, aqueles de servidores físicos nos porões das empresas, direto pra nuvem, sem precisar, sabe, reescrever milhares de linhas de código.
• 2:28
  Olha, eu entendo perfeitamente o fascínio da engenharia por isso. E confesso, não precisar reescrever código legado é uma promessa incrivelmente sedutora. Demais.
• 2:37
  Mas a minha perspectiva aqui é a de uma gestora de negócios pragmática, alguém focada na continuidade da operação.
• 2:44
  É, o tempo parece simples na teoria, até o momento em que você precisa armazenar isso em disco, ordenar e principalmente comparar durante um horário de verão. É, o horário de verão é complicado.
• 2:55
  E a bandeira vermelha gigantesca que eu levanto hoje é o risco dos erros silenciosos.
• 3:00
  Porque nos testes de laboratório do autor, o banco de dados entregou respostas completamente erradas sobre vendas e relatórios sem emitir um único aviso de erro. Não tem tela azul, não tem sirene. Uhum.
• 3:11
  Como alguém responsável pelos dados da empresa, a minha pergunta central é: a conveniência de não reescrever código vale o risco de colocar um bug invisível no meu negócio? É um questionamento superválido.
• 3:22
  E pra irmos ao fundo disso, a gente precisa desconstruir a mecânica da mudança, porque o recurso atua em duas camadas distintas. A primeira é a configuração do banco de dados em si. Ela é fixa.
• 3:33
  Pensa nela como o grande relógio de parede do escritório. Todo mundo que entra na sala olha pra aquele relógio. Tá. A segunda camada é a configuração de sessão. Essa é temporária e vale só pra uma conexão.
• 3:45
  É como você ajustar apenas o seu relógio de pulso pra falar com o cliente, sem encostar no relógio da parede. Isso é fantástico pra empresas que oferecem um banco de dados por cliente.
• 3:55
  Você ajusta o relógio da parede pra região do cliente e quando o gestor em Tóquio pede o relatório, hoje significa hoje no Japão.
• 4:02
  A teoria do relógio de parede é linda, se você tiver inaugurando um escritório novo, com as gavetas vazias. Mas na prática corporativa, a gente lida com escritórios que operam há anos. Certo, o histórico. Exato.
• 4:14
  Vamo pegar o pior cenário documentado no texto. Imagina que seu banco de dados é um imenso arquivo de aço. Durante cinco anos, cada documento foi carimbado silenciosamente com o horário de Londres.
• 4:24
  Aí a tecnologia muda o relógio da parede pro Texas e começa a guardar os novos documentos. Mas as folhas são idênticas, a tinta é a mesma, o número está nu. Você diz ao misturar dados antigos em UTC com os novos locais.
• 4:38
  Isso. Vamo destrinchar os números do laboratório? O autor inseriu 10 pedidos com o banco em UTC. Depois, mudou pro fuso dos Estados Unidos e inseriu cinco novos. O sistema, que é cego, guardou tudo.
• 4:52
  Só que o Texas tá cinco horas atrasado em relação a Londres. Ah, eu já sei onde cê vai chegar. Pois é. O sistema olhou pros números e concluiu que os cinco pedidos novos aconteceram cinco horas antes dos 10 antigos.
• 5:06
  O pedido número 15 apareceu como se fosse a décima transação. Pera aí, mas eu preciso defender a arquitetura aqui. O sistema foi impecável dada a instrução que recebeu.
• 5:16
  O banco de dados apenas ordena os valores absolutos. Se a equipe troca a regra no meio do jogo, mantendo os dados sem identificação, é uma falha na higiene dos dados originais. O sistema foi previsível.
• 5:27
  Previsível pro engenheiro, sim, mas letal pro negócio, porque nada quebrou. O banco não levantou uma plaquinha dizendo: "Temos fusos misturados". Ele entregou uma mentira coerente.
• 5:39
  Ele afirmou que havia 15 pedidos numa janela onde a realidade física dizia 10, porque enxergou vendas no futuro. Esse é o pior bug, o invisível. Ninguém recebe alerta.
• 5:49
  O executivo chega e paga comissões baseado numa linha do tempo quebrada. Eu entendo a gravidade, juro.
• 5:55
  Mas eu recuso a premissa de que isso invalida a utilidade colossal do recurso Porque quando arquitetada corretamente, essa mudança destrava um ganho de performance operacional gigantesco.
• 6:06
  Historicamente, pra buscar as vendas de hoje no horário local, o sistema antigo pegava milhões de linhas em UTC, aplicava uma conversão matemática uma por uma e só então verificava. Isso destrói a performance.
• 6:18
  A CPU chora. Uhum. Agora, se o banco entende o fuso local, o aplicativo pede as vendas de hoje e o motor usa atalhos ultrarrápidos, os índices, indo direto ao ponto.
• 6:28
  Olha, essa promessa de ganho de performance não me convence, a menos que a gente seja brutalmente honesto sobre as armadilhas matemáticas. O autor testou essa ilusão de velocidade. Ilusão, não.
• 6:39
  Bom, ele pegou 200 mil linhas de dados e rodou a famosa query C, comparando dados antigos em UTC com a data local. O sistema usou o índice rápido. Sim, rodou em milissegundos, mas o relatório retornou 1389 linhas a mais.
• 6:54
  Sim, porque o sistema foi instruído a comparar maçãs com bananas sem converter. Mas esse é o mundo real. O motor busca números puros.
• 7:03
  Quando você pesquisa rápido dados de Londres usando a lógica do Texas, aquelas 1389 linhas extras não eram um erro de cálculo. Eram cinco horas inteiras de dados do dia anterior.
• 7:14
  Do que adianta um relatório sair rápido se ele infla a receita do dia com vendas de ontem? O diretor vai comemorar a meta, mas o sistema mentiu eficientemente pra ele.
• 7:23
  Tá, esse é o momento perfeito pra trazer a lição técnica que resolve isso. O autor aponta a arquitetura correta.
• 7:29
  O atalho de performance funciona perfeitamente, sem erros, se a coluna for criada com um formato chamado date time offset. Ah, a tal da etiqueta. Exatamente.
• 7:39
  O tempo tradicional é tipo um bilhete em branco dizendo três da tarde. O date time offset é uma etiqueta de bagagem de aeroporto. Ele diz: "São três da tarde e esse carimbo é do Texas". Ele acopla o fuso à hora.
• 7:51
  No laboratório, com essa etiqueta, o sistema voou pelos atalhos e entregou o número exato. Se você usa essa fundação, você tem performance e risco zero. Eu reconheço que o date time offset é elegante.
• 8:03
  A teoria é linda, mas no ecossistema corporativo real, sistemas de 10 anos atrás quase nunca usam essa etiqueta. Desenvolvedores economizavam espaço e usavam o que eu chamo de tempo nu.
• 8:14
  E quando você injeta fuso local em tempo nu, você invoca o maior pesadelo da TI: o horário de verão. É, o horário de verão vai testar os limites de qualquer infraestrutura, na nuvem ou não.
• 8:25
  Sim, mas o estrago muda de figura. Primeiro domingo de novembro, o relógio recua. Duas da manhã viram uma da manhã de novo. O laboratório testou isso.
• 8:33
  Imagina duas vendas com 60 minutos de diferença na realidade universal. Uhum, 06:30 e 07:30. Isso. Quando caíram no sistema, com o relógio recuando, ambas foram carimbadas à 01:30 da manhã local. Qual é a consequência?
• 8:47
  Um sistema de faturamento calcula a diferença entre os dois eventos e diz zero minutos. A empresa não cobra nada porque o banco acha que aconteceu no mesmo instante. A empresa sangra dinheiro de forma invisível.
• 8:58
  Nossa, sim. Eu concordo plenamente que as anomalias das horas repetidas no outono e as puladas na primavera são o calcanhar de Aquiles.
• 9:06
  Quando o relógio pula pra frente, um processo de um minuto vira 61 minutos e quebra os SLA de maneira falsa. Exatamente. Acorda todo mundo de madrugada com falsos positivos.
• 9:17
  E mais, quebra funções de agendamento, como o wait for time. O sistema ignorou o fuso local e em vez de esperar cinco segundos, o motor decidiu esperar 19 horas. Mas sabe o que me tira o sono de verdade? A falha no BPAK.
• 9:30
  A ferramenta padrão pra backups e extrações de dados. O nosso bote salva-vidas. Nos testes, o BPAK falhou catastroficamente se houvesse comandos de fuso no código. Deu erro fatal SQL46010.
• 9:43
  Imagina, domingo, 3 da manhã, janela de migração apertada. O backup falha. O pânico se instaura. A conveniência de não alterar código compensa as ferramentas de backup falharem de madrugada? É um ponto fortíssimo.
• 9:56
  Um erro no BAKPAK é um impeditivo técnico severo e a Microsoft precisa sanar isso antes de sair do preview.
• 10:03
  Os riscos de quebra temporal são genuínos, mas a sua visão cética pressupõe que a única forma de usar isso é mudando o relógio de parede. E existe uma saída muito mais segura.
• 10:13
  Pera aí, como você escapa das armadilhas do horário de verão sem perder o recurso? Voltamos à diferença entre parede e pulso.
• 10:22
  A recomendação central do texto, a regra de ouro que mitiga todos os riscos que você levantou é: não mude o arquivo de aço. Mantenha o relógio da parede, o armazenamento permanente, no bom e velho UTC. Ah.
• 10:35
  Assim, nenhuma transição de horário de verão causa saltos, nenhuma hora é duplicada. Mas na hora que a aplicação conecta pra gerar aquele relatório milionário, ela usa a configuração de sessão.
• 10:47
  Você muda só o relógio de pulso do analista, temporariamente. Ah, entendi. Você separa o armazenamento da apresentação. A tradução do tempo acontece só na visualização, preservando a gravação original. Exato.
• 11:00
  A matriz de dados no cofre continua intocada, livre de erros. Mas na tela, a gestora enxerga tudo traduzido pro fuso local de forma nativa.
• 11:09
  Pra sistemas globais e cheios de histórico, essa configuração pontual é o equilíbrio perfeito. Olha, com essa distinção específica, acho que chegamos num consenso.
• 11:18
  Eu concordo que a flexibilidade do relógio de pulso é valiosa. Prum banco zerado e local, talvez o relógio de parede faça sentido. Mas eu mantenho minha ressalva.
• 11:28
  Pra históricos gigantes, o risco de corromper o passado mudando o relógio de parede é alto demais. Separar como se guarda de como se lê deve ser a regra. E essa é a regra de ouro onde a gente converge.
• 11:39
  Armazene em UTC, apresente via sessão. Isso nos leva a um próximo passo prático pro ouvinte. Seja você técnico ou gestor, o primeiro passo é uma auditoria.
• 11:50
  Antes de ativar qualquer coisa, procure no código por funções como get date, verifique as suas colunas de tempo nu. E como uma gestora atenta, eu aciono: audite seus backups. Teste o backup de ponta a ponta.
• 12:03
  E se for usar a sessão, faça simulações exatas das madrugadas de horários de verão. Se o faturamento não sobrevive a zero minutos de diferença, cê precisa mapear isso.
• 12:11
  O recurso tá em preview, os comportamentos ainda podem mudar. A precisão permanente de um cofre versus a flexibilidade de um painel. O sucesso depende da sabedoria de escolher qual usar.
• 12:23
  Se você quer se aprofundar, a gente convida você a ler o texto original. Tem todos os 15 cenários detalhados.
• 12:29
  É uma leitura indispensável pra dominar não só as promessas da nuvem, mas os abismos silenciosos que elas podem criar. O post é gratuito, mas está em inglês. Leia o post completo em intechornot.com.
• 12:42
  Repetindo: intechornot.com. Obrigado por acompanhar We the People in Tech or Not. Nós ficamos por aqui hoje.