Olha Na Na equipe de sustentação, trabalha também muito tempo na equipe ali
que é do wfm de operação de despacho também e outros sistemas que estão
envolvendo ali, né? Parte de operação de despacho,
então eles é hoje eles dão, fazem a sustentação, né?
É desses sistemas aqui do outro lado, aqui também a gente tem,
é uma empresa tá trabalhando com a gente já tem um tempo já que é da centrop.
É, tem o João Carlos castellani, então aqui é um arquiteto Vladimir, né?
Faz a parte de gestão aí do do projeto é esse projeto, tem o intuito de,
na verdade, nesse trabalho, tem o intuito de de validade de ponta a
ponta. Lá as integrações estão envolvidas com
ADMS, tá, ô Vladimir, falei correto, aí eu não sei se não tá perfeito,
tá perfeito. Luis, e a e a ideia a gente dá um entendimento,
né, de como é que eu.
Do trabalho de vocês, né? Em sustentação, uma coisa importante nessas transições,
né? E o é e o castelani conduz aí as
perguntas, né? Castelani, né? É importante também de vocês falar um
pouco do do processo de vocês, né, do fluxo que vocês têm de atendimento e
como é que vocês são acionados também, só para eles entenderem também qual é o
trabalho de vocês e também até comentar as dores que vocês encontram, né?
O que recebem, né?
Referente ao a essas integrações que envolvem a dms,
desde o legado até Oo sistema, né? Corporativos que integram com a dms até
OA dms, se que que a gente fala aqui primeiro ou
se pode ser, pode falar primeiro, que aí já inicia.
A tá assim a gente costuma receber, né? O primeiro contato, assim,
é com o chamado de algum usuário reportando alguma coisa. No geral, é isso.
Assim, é uma ocorrência que não, que não tá aparecendo na tela,
uma ocorrência que não retorna dado, faltante.
Esse tipo de coisa é a gente recebendo o chamado, a gente vai seguindo os fluxos.
É pra quem está chegando na raiz do problema, né? Baseado em logs,
aí no lk cincdia é o Kafka. Ali a gente vê saúde das filas e tal.
Resumindo, é isso. Assim, a gente está recebendo os repasses da
equipe de projeto de grão em grão, a gente tem recebido,
é um pouquinho mais do projeto. Então assim, em resumo, é isso. Agora,
a sustentação de vocês está focada no novo ADMS.
É assim, a gente sustenta todos os sistemas teccom,
né? Mas Oo foco, a gente do nosso aqui tem sido mais o
adms. Ah, tá, mas no fundo vocês sustentam tudo.
Vocês têm essa visão geral da operação de despacho, né? Focado ali em si.
Gold despachos iOS, no geral, é com aquele comercial perfeito.
Carcelane em algum ponto aí que você queira começar a explorar? Foi mal,
tava no mudo, é só só curiosidade, é pelo que eu entendi.
O foco é na qualidade do dado, geralmente os os,
as demandas que que que são enviadas pra vocês resolverem ou investigarem.
É relacionado a qualidade de dados? É isso? Não,
não pode ser uma ocorrência simplesmente que não apareceu ou tá travado.
O cara tá abrindo falta de energia em algum lugar e as ocorrências não caem pra
ser despachada pra equipe. É esse tipo de coisa. Assim,
não necessariamente a qualidade do dado, o dado em si,
nem aparecer às vezes ou alguma lentidão em algum alguma parte do fluxo.
Então deixa eu reformular é No No fluxo de informação.
Então é eu tenho 11 pipeline, um workflow. Então se o evento travar em algum desses,
em algum dos em algum dos das etapas, você vai estar investigando porque travou
e liberando esse evento pra poder seguir o seu caminho. Se o evento.
Se a informação que estiver dentro do evento tiver algum dado incoerente ou
faltante ou é errado, por exemplo, né? Que é causa em algum impacto em alguma
outra, em alguma outra etapa do evento. Vocês também estão investigando isso, tá?
Então é, é. Vocês estão atuando no fluxo
informacional. É isso, tá? É.
Se tiver 11, situação onde eu tenho um processo que
ele tem uma falha, ele ele dá um erro 500. Isso vocês também investigam?
É se for algum erro mais nesse sentido de rede.
Assim a gente coloca as outras equipes pra apoiar, né? Por exemplo,
a equipe de rede ou a equipe de de banco, se a gente vê que algum problema no mongo,
né? Ou a equipe do kafta lá, se tiver alguma coisa relacionada A Fila
consumidor e tal.
Tá, entendi. Então deixa eu ver se eu entendi.
Vocês fazem uma análise de fluxo do fluxo informacional,
aí vocês identificam a falha. Se for uma falha processual,
vocês acionam a equipe responsável por aquele processo para eles fazerem as
devidas correções e o fluxo se seguir, certo? Vocês não atuam na correção?
A gente atua na correção também, se for a cor, se o problema for sistêmico,
né? Em sistemas nossos, uma fila 11 consumidor,
um produtor que tá que relacionado a sistema é nosso,
a gente atua na achando problema e corrigindo,
se for alguma coisa mais pro lado de infraestrutura é a equipe de
infraestrutura, tá bom, beleza, então vamos lá,
é o cigode enviou um evento e esse evento nunca chegou, tá? É?
Me dá um exemplo de como é que vocês atuam nesse cenário?
Eles identificam que foi esse gótico que enviou ao evento e o evento travou lá No
No no Kafka e não foi processado. O trabalho no Kafka,
a gente vai caçar na fila. Por exemplo, na censid,
a pula na censid buscou a é a censid, fez uma chamada,
mas ninguém nunca respondeu. Por exemplo, tem algum erro no meio do caminho?
A gente vai num, num.
Num num serviço que deveria ler essa API, por exemplo, e ver se ele tá rodando,
é basicamente é isso. Assim, vamos. E por que que esse serviço não pegou?
O serviço tá rodando, mas não pegou a mensagem. E por que? Ah,
porque tá algum problema na rede, pode ser,
ou porque faltou alguma informação e tá dando erro no consumidor ali, pode ser.
Ou realmente faltou um dado que deveria ter vindo do cigode e não veio.
Perfeito, vamos lá, nesse cenário é, faltou um dado que deveria ter vindo no
cigode e não veio, como é que vocês, como é que vocês corrigem o problema?
A gente abre o log e verifica qual que seria esse erro, ele verifica no fonte,
tipo assim, Ah, realmente está faltando, é uma coluna que deveria ter vindo do
mundo, não tem. Então a gente vai abrir uma demanda
corretiva para ajustar isso aí. Ah, beleza, então vocês abrem uma demanda,
aí o pessoal lá que cuida do cigode, vai lá, vai.
É, ajusta essa, executa essa demanda e aí ele reenvia o
dado. É isso que são vocês mesmos ou a equipe
do projeto, tá, tem como? Ainda está um pouco em época de repasse
aí, ou a gente abre a corretivo, corrija, ou a gente tem sido maior parte,
a gente repassa para a equipe do projeto ajustar.
Então vocês fazem a sustentação do código, então vocês também fazem as correções,
as correções no código. Vocês, além de identificar,
vocês fazem a correção no código, é isso, show, é se cair para uma aí,
como é que aí, beleza, é aí você fez um replay, tá? É? Entendi.
Não entendi, entendi. É aí vocês fazem. Então, por exemplo,
se eu tiver 111 processo onde eu tenho um evento que ele passou por 5 pipelines,
5 etapas, ele falou na última, você identifica que o que porque ele
falhou, efetua a correção lá no, digamos, segód.
Aí ele vai reenviar esse evento e ele vai passar por todas as etapas até bater na
última e passar pela última, é isso?
Ou você consegue fazer a correção e mandar só pra pra última etapa,
o evento EE essa última etapa processar cara, não,
não vai ter um padrão desse não. Assim, dependendo do erro,
pode ser que ele nem reenvie mais. E aí tem que ter algum tipo de tratamento
manual aí, tá?
Tá, entendi. Então se eu tiver um erro de dados num
num evento, não quer dizer que eu vá fazer um replay
desse evento corrigido, eu posso efetuar um processo manual de
correção na base, na base destino, é isso, é, pode ser que isso aconteça assim,
isso é um problema que a gente tem, inclusive. Entendi, mas aí tá,
é porque vamos lá, como a gente tá trabalhando com com
eventos, né? A gente tem 111.
11 designer pater, que é um designer pater de eventsocing.
Então o que que acontece? O eventsocing, eu eu armazeno os eventos,
todos que eu gerei, tá é no time Siri da vida e caso eu
precise, caso eu tenha alguma falha alguma,
algum é processo de perda, eu reaplico os eventos,
eu reidrato esses eventos e dou um replay e ele vai e segue o fluxo,
o fluxo natural.
Se eu faço uma ação manual que corrige um problema que deveria ser um evento
reenviado, concordo. Eu não vou ter esse evento histórico
porque se eu tentar fazer um replay, esse evento não vai existir na base e ele
vai replicar o erro novamente, entendeu? Lógico, é, você diz,
hoje a gente tem isso. Não entendi não, não, hoje a gente não tem.
Mas geralmente em processos num num não há metodologia event drive,
porque vocês são event drive, são eles são orientados a evento.
Uma das boas práticas é você ter um event socing da vida, que é o que é,
você ter uma base onde você armazena esses eventos e você,
se houver uma necessidade, você reaplica esse evento,
dá um replay no evento, então geralmente.
Sempre que há um problema a gente tem que corrigir o evento,
não pode fazer nenhum processo manual de correção de base ou do recebimento desse
evento. Por quê? Porque senão eu não tenho mais o evento
sócio, entendeu? É lógico, porque se eu precisar fazer um replay,
eu não consigo fazer esse esse esse replay, porque a base,
a base de eventos está inconsistente, a base do evento sócio,
que é inconsistente. Isso é só um ponto, né?
Eu acho que vocês não têm esse esse esquema de eventsocing aqui, né, vocês?
Manda os eventos, eventos que vão sendo processados,
EEE morrem, né? Você não armazena os eventos.
Todos que vocês foram que foram processando por causa,
por necessidade de auditoria ou ou caso eu precise fazer um replay de um período
de tempo de eventos, Ah, eu quero reaplicar esses eventos. Não,
não, não, não rola isso aqui, né? Não é? Acho que não. Ô Wagner, se.
Parei, eu acho que não, né? Não tem nenhum, não grava isso não.
Morreu ali e morreu, entendi é eu, eu, eu acho que não sei se é que você já
concluiu a parte do fluxo Lucas serrani mas uma coisa importante pra gente ver é
a questão dos principais problemas, né? O dores que eles tiveram, né? É,
ele tinha mostrado um diagrama.
Depois tirou da tela, é então podia talvez detalhar um
pouquinho isso, tá bom, vai lá, vai lá, OPA, ô pessoal, eu caí,
acabou a energia aqui, agora eu voltei, eu acho que o diagrama foi você que
começou Pedro, não, não sei se foi Norberto,
talvez não fui eu. É que eu tinha na época do projeto LMS,
né? É na implantação ali do.
Do Barramento, a equipe de monitoração pediu pra gente
fazer 111 fluxo ali do atendimento né, que seria feito.
E aí considerando também eles, né? Mais tarde é castellani e vladimente.
Vai falar com eles também hoje em seguida, né? É, então começa aqui, ó. Ou seja,
tem uma falha no sistema. Exemplo tá no horário, fora do horário,
né, normalmente.
E o usuário do sistema identifica, né, a inconsistência e entra em contato via
telefone, WhatsApp, é via Teams com a equipe de monitoração.
Ele recebe esse incidente e aí ele tem um processo ali que ele também é.
Tem um atendimento ali. Via é ITSM, né?
Pode ser também 11 alerta, né? Isso aqui era 11 ideia que a gente tinha
lá de fazer o alerta. É através de um alerta automático, né,
que ele tem também. Ele recebe alerta automático? É,
tem a parte de do itsm também, que abre o chamado também com o itsm.
EE eles e ele, o pessoal da monitoração, eles acionam as Torres aqui de é
sobreaviso no caso aqui, sustentação de sistemas.
Aí tem o tem Oo pessoal que está aqui com a gente, né?
Tanto o Wagner quanto Pedro Lucas tem também aqui de de aplicação aplicações
como frente cáfe, que é as demais. Tá aqui,
tem alguns exemplos aqui do que eles acionam, né?
E eles retornam quando estão fazendo atendimento esses atendimentos
emergenciais, né? Sobre aviso, eles retornam,
isso pro no que eles chamam de nock é ON zero. Lá que é a monitoração, tá?
Normalmente o pessoal de monitoração, eles não têm conhecimento técnico
aprofundado pra poder tomar uma ação, ou conhece, conhece, né?
É então por isso que ele manda pros especialistas e sobre aviso.
Olha, mas é isso, só pra comentar como que funciona de uma
forma geral o fluxo show, se quiser a gente pode ir pros pros,
para as 2. Isso aí, aí seria legal você parar, né?
Que eu entendo que quando você faz uma implantação grande, né,
você deve ter um conjunto de problemas, né,
que podem se repetir ou não na próxima, né?
E a coisa vai estabilizando aí no congonha que você tem.
Processo recorrentes. Se não pudesse dar uma palhinha sobre
isso, Pedro, EE Vagner, tá. Eu eu vou falar da da da primeira dor que
a gente teve aqui, que foi na no na questão do repasse.
Não sei nem se entra, né, nessa parte com vocês,
mas é questão de de documentação, né? Por um ser um processo muito grande,
a gente não conseguia é enxergar direito o fluxo, porque não tinha é.
A ligação ali entre entre todos, né? E o repasse não tava legal.
A gente fez até uma documentação aqui por conta com a engenharia e reversas usando
e ela que se puder mostrar aí pra eles compartilhar aqui, tá?
Aí a gente começou a entender um pouquinho melhor e começou a atuar.
Sabe de algumas coisas?
Você já viu o nome? É isso aí você não é? A gente criou algo mais, mais visual,
pra gente entender sabe onde nascia, onde os headpoints que tinha e o fluxo
mais resumido sabe qual fila que populava, qual fila que que consumia,
pra gente ter uma, ter uma noção melhor.
É assim, esse é um resumo que a gente tem de até
para ajudar a gente a achar problemas aí eventuais, se a galera reclama, né,
que a galera costuma reclamar. Isso aconteceu entre ADMSEO cibod ou foi
ou foi pós. A entrada aqui do OS foi 11, retorno ali é isso.
É um documento de apoio aqui para gente.
Ele quer comentar mais alguma coisa aqui? Aí você clica só No No na fila aí Pra Ele
ver aqui do cacho e ele ver quem sobe. Tem um pouquinho de regras,
tem quem expõe quem, só pra gente entender melhor.
Agora eu acho que eu vou falar das outras. Lá é os serviços,
aí qual serviço que consome, o que vai pro mongo? Vai,
passa um pouco no Oracle, vai seguindo, passa a passo de cada.
Ela é micro serviço ou fila do Kafka que a gente tem,
vai tá documentado aqui como foi a gente que fez, às vezes chega um pode chegar,
às vezes em alguma análise a gente vê algum, algum gap que tá faltando aqui,
a gente vai e arruma documentação, só entendi essa documentação está gerando
por IA, foi gerado por IA, é inicialmente, né, mas ela não está sendo atualizada, né?
Pelo IA vocês estão, então também é aí.
O problema é o estouro, né? Aí quando quando chega No No começo do
mês, eu faço, eu rodo um prompt lá que ele pega AO,
dá um game deep, né? No que foi alterado e vê se teve alguma
alteração, inclusão de alguma coisa que diretualiza
já direto. E ela pega da onde, pega do slogs, pega direto do fonte. Ah,
ele pega do código do código, é isso?
Entendi, então você aí, você tá fazendo o live cyco do do evento,
é isso? Isso tipo de vida do evento, isso. Pô, legal, isso aí.
A gente tem como ter acesso, é isso? Vocês tem acesso no Jota,
você tá No No meu Jota lá no.
Ah, isso está no isso está na rede interna,
está na rede, é, a gente está até vendo como é que vai
disponibilizar isso aí pra colocar isso aí num num site, sei lá,
então ficou legal, entendi, tá, então se não der, eu posso mandar,
é de repente compactar e é compactar um ZIP lá, porque esse é HTM, né?
São vários HTML, certo? Manda, manda um ZIP e a gente.
E a gente depois abre aqui e dá uma analisada, tá,
ficou bem legal que a gente testou lá, tá? Aí sim, beleza.
E então porque a gente tem passado aqui de, sei lá,
de dificuldades aí pra achar os problemas ou. Ou resolver. Em seguida,
a gente listou algumas coisas aqui.
Que é, por exemplo, erros que acabam acontecendo no ambiente.
A gente não tem alarme efetivo que de fato é consiga preparar a gente antes de
chegar no usuário final, né? Quase todos os serviços nossos assim não
relacionados ao DMSA gente tem algum tipo de alerta,
alarme que vai chegar ou pra gente mesmo ou pra monitoração,
pra gente ser acionado antes é do problema chegar no nosso cliente final.
É, e no ADMSA, gente, não tá tendo. Claro que nenhuma das coisas que a gente
foi acionada, a gente teve um alerta efetivo. De fato é,
tem uns alertas, né? Mas acho que mais é no data dog,
então todas as vezes que teve problema não teve alerta praticamente, sabe?
Então assim, não, não pegou nada, então não tá muito eficaz esses alertas,
então.
É algum um outro problema que a gente acaba tendo aqui.
A gente é nesse processo de repasse aí também e tal a gente.
Já os usuários acabam reportando um problema,
a gente vai na censídia pra tentar achar o que, né? A chamada que foi feito,
os dados que foram passados e aí vão ter ir na censídia mesmo.
Não sei se é uma limitação interna ou da censídia, eu não sei.
Essa limitação de só vai ter log de 1 dia. Então se o cara teve um problema,
mas um pouco só hoje a gente já perdeu.
É, e o tamanho, né? Às vezes tem um penode ali que é um pouco
maior e assim simplesmente não grava. A gente acaba ficando dependendo de
alguns logs que podem ou não existir essas questões.
Você já passou já para o para as equipes, já para a equipe, não, a gente custa,
acaba que comenta assim uma sala de guerra ou outra, mas não,
não tem muito não, não segue aí não.
É algumas coisas que a gente já pegou, tipo de problemas em sala de guerra que a
gente acaba tendo, né? Tipo assim, é o tamanho das filas, né?
A gente tem filas que são consumidas aí pelos consumidores, é.
E a gente vê que vez ou outra acontece de ter uma fila lotada,
processando sem parar e várias outras paradas ali. É processionar, processionou.
É os consumidores processando a mesma fila.
Vários 11 ou 2 consumidores lotados e sei lá,
os outros 7 deveriam ter vazios ali que acaba tendo um atraso nos processamentos.
Mas com muitos serviços e dorina reparados é terceira.
Dorina pode repetir essa dor.
Essa é mais no sentido assim. A gente é acionado e a gente vê que A
Fila está muito grande. A Fila de mensagens do carro fica lá,
está lotado e a gente vai nos consumidores e tem tipo,
uns 10 consumidores lá e um com todos e um processando sozinho tudo que tem na
fila. Sabe como os outros 9 estão parados? Porque foi tudo foi foi direcionado para
aquele consumidor x ali é, né? E causa atraso e tal.
É esse seria nosso terceira dor que a gente pensou.
Aí tá uma quarta que costuma acontecer já na sala de guerra também é quando dá
qualquer tipo de problema x, que é relacionado a um pouco aqueles
eventos que você comentou lá, o João, que é tipo assim, vamos supor,
um serviço caiu, alguma fila, deu algum problema ou rede ou segurança
ou qualquer coisa assim. A gente perdeu algumas mensagens,
alguns dados de ocorrência, o que quer que seja,
não foram atualizados e isso fica perdido por aí.
É, a gente tem que fazer um, a gente não, a gente não, não tem 111 forma.
Pelo menos que a gente saiba que a gente tenha visto de reprocessar esses dados
que depois ficaram perdidos. É, é a questão do MIP aí, né?
Não sei se entra aqui o Norberto OMIP, que é OS lá,
mas que são os dados com ADMS mando de atendimento geral.
Só uma curiosidade é o Kafka, ele ele faz uma retenção de quanto tempo?
Quanto? Como é que está configurado o Kafka?
Ele ele ele retém o evento durante quanto tempo? Não sei, sabe, Oo default é 7 dias,
aí se se não se não pedir para mudar, fica 7 retenção mesmo.
Usou 7 lá nos entendi, mas existe esse esse tipo de problema.
Por exemplo, é, eu mandei 11 evento, esse evento não foi processado.
Eu demorei mais de 7 dias para poder tomar uma ação. E esse evento se perder,
não é com 7 dias não. Mas assim já aconteceu esses casos de
cara, perder uma mensagem. E aí, como é que reprocessa?
Mas aí foi naqueles casos de de que o pessoal tava reiniciando, né?
O não até Oo cancelando. Conhece esse caso do reset do ofsete?
Quando tinha, quando eu tava usando OCDCO, foi foi a escada que perdeu,
é a última vez que perdeu foi nesses 2, depois não perdeu mais nenhuma mensagem.
Não, não é? Mas na verdade não tinha perdido, né?
Era só uma questão do ofsete do BID isso.
Na verdade, Oo processo da equipe do Barramento que
eles estavam fazendo, eles faziam reset do of 7 e aí parava No
No ponto atual, né? Sem retornar para o ponto do passado, né?
Antes do do incidente, é quer dizer assim, passou uma atualização de uma ocorrência
de um serviço. Deveria ter processado ela aí,
ou processou ou processou com erro.
E esse dado que está na atrás, a gente não tem uma forma de mandar ele
novamente pra reprocessar, entendeu? Mas nesse sentido que a gente comentou
mais no início, ali, não. Então é isso isso que eu falei, assim,
o o event sourcing resolveria isso? Tá, então como é que funciona e funcionaria o
event sourcing? É como se eu tivesse um.
Um processamento 11 lambda, né? Eu tivesse 2 pernas, né?
Então na hora que eu recebo o evento, uma das pernas,
uma dos um dos caras que está subscrevendo,
ele não vai fazer nada com esse evento, ele simplesmente vai armazenar esse
evento num num, num object store, por exemplo, tá?
Então ele vai chegar lá e falar assim, ó, vai criar uma partição, ó,
é evento de ordem de serviço, ele vai criar uma partição data, hora,
minuto, dependendo de como você criar a sua
partição.
Então ele vai, armazena aquele evento ali, tá?
E o outro cara que tem que processar ele, vai subscreve também e processa, tá,
então tudo bem, tá tudo funcionando direitinho.
Esse cara que tem o histórico de todos os eventos que foram, que foram publicados.
Aí você chegou e falou assim, pô, esse cara aqui, ele estava com um erro,
o código que tinha que processar esses eventos,
estava processando esses eventos de maneira errada, tá?
E aí você corrige esse código e fala assim,
eu quero fazer um replay desses eventos.
O que que é o replay? Você vai no event socing do daquele,
daquela daquele tópico e você manda reidrato os eventos,
você cria um processo que reenvia aqueles eventos pro Barramento,
aí ele joga de novo os eventos e ele vai processo.
Aí você garante que tá com o mesmo ideia, tá com o mesmo tudo, não sei o que,
e esse cara ali vai lá e reprocessa. Entendeu o o cenário,
a lógica do event socing.
Entendi, entendi é, eu entendi como é que ela funciona?
Eu não sei como que a gente implementaria ela aí, né? Não sei se tipo assim,
será que algum evento pode ser reprocessado?
É também pensando em regra de negócio, né? Eu não sei. Aí é uma outra questão,
entendeu? Assim é porque, porque.
Se você, por exemplo, se eu tiver um evento que está cálculo,
fazendo um cálculo errado e ele está atualizando e fazendo um cálculo errado,
concorda? Quando você acerta o cálculo, você tem que fazer,
você pode fazer o reprocessamento. Só que você vai falar o seguinte, pô,
mas aí eu tenho uma base que ele sempre faz in surt.
Então ele vai inserir um novo, um novo registro que ele não deveria
inserir. Aí o processamento, você vai ter que identificar o processo,
você vai ter que limpar a base.
Né, daquele período que ele calcula errado,
né, aquele dado tá errado mesmo, eu vou ter que fazer um processo de
limpeza de base e vai, você vai fazer o replay,
aí ele vai processo tudo de novo, entendeu? Acabou assim, aí vai,
vai depender de caso a caso. Mas OA questão não é essa,
a questão é que você tem um repositório de eventos,
um histórico que você consegue fazer uma auditoria nesse repositório e você
consegue fazer replay reaplicar esses eventos,
é claro que dependendo do problema.
A reaplicação, ela pode ter algum tipo de pode ter algum
tipo de cenário, por exemplo, Ah É, eu não vou deletar na base,
mas eu quero que faça um update dessa informação, você vai ter que criar um bet,
vai fazer alguma coisa pra fazer um update e reprocessar,
mas você tem os eventos, entendeu? Você sempre,
sempre que você toma uma ação, você toma uma ação em relação aos eventos,
os eventos são sua, sua fonte da verdade, entendeu? Eu quero tirar um backup,
eu quero fazer uma resiliência, eu vou fazer uma resiliência.
Desses eventos, desse event store. Porque se eu copiar esses eventos store
pra um outro, pra um outro lado, eu posso mandar aplicar num outro,
num outro Barramento, numa outra, numa no meu site de contingências e todo
o processo vai funcionar normalmente, entendeu?
Ele vai atualizar o que tem que ser atualizado.
Esse é o objetivo do event Soccer, entendeu?
Por isso que pra vocês que dão sustentação seria interessante tê lo,
em determinados cenários, talvez não em todos, não sei o que,
mas em determinados cenários eu acho que é interessante você ter esse cara,
entendeu?
Esse esse outro que o Pedro falou aí do da fila, né? É,
tem às vezes algum consumidor, né? Ele para e aí A Fila fica cheia, né?
E até ele voltar EEEA fila esvaziar ele demora um tempo.
Aí tem tem vezes que que ele esvaziam, sei lá, tipo,
vamos supor que deu uns 50000 de de fila.
E aí começa a baixar lentamente. Mas aí chega um certo ponto que alguns
alguns, algumas réplicas, né, ficam zeradas e a outras com 8000,
por exemplo, sabe? Acho que é o balanceamento.
E aí depois que cai nesse nessa réplica, acho que não tem como tirar, né?
Aí nesse aí fica complicado. Que que eu acho difícil?
Entendi é, vocês trabalham com partições no casco ou
você é uma fila normal sem partição nenhuma? Tem tem partições?
Entendi EEE como e como são feitas essas partições?
Porque geralmente você tem o que? Você tem vários consumidores, né?
Você tem várias partições, cada um tá olhando uma partição, né?
Porque provavelmente AA partição você vai garantir a ordem se há necessidade de uma
ordenação. Então, por exemplo, Ah, eu crio um partition key com minha,
com com o meu, com a minha chave primária, com a minha pecada, minha da minha tabela.
Então eu sei que sempre que eu mandar para aquela partição.
Tá, eu vou mandar 11 a minha. A minha chave primária sempre vai cair
naquela partição. Então se eu alterar 11 cliente a
informação de um cliente, eu fiz 11 iniciat update de elite desse
cliente, eu vou ter um iniciat de update de elite
na ordem correta. Eu vou poder pegar essa, essa, essa partição,
vou trabalhar com esse cara nessa mesma, vai cair sempre na mesma partição, tá?
E aí eu consigo ter um processos, processos em paralelo,
consumindo esses tópicos sem.
Ter a situação de um processo, um consumidor, né,
é pegar uma informação antes do outro, né, tirar da ordem, né?
Vocês trabalham dessa maneira? É, tem as partições lá,
cada cada fila vai ter a sua, a sua particularidade Na Na partição, né?
Vai ser um lote, vai ser vai ser um cliente,
vai ser uma ocorrência, cada um vai ter o seu algoritmo ali,
de diferenciação ali.
Mas e você, tem chaves nessas? Vocês têm chaves únicas pra essas
partições? Quando, quando, quando eu mando o evento,
eu poderia fazer a ordenação ou ordenação, não é?
Não é muito importante pro cenário de vocês pra ordenação, eu tenho certeza.
Sabe o Wagner?
Não sei se para ordem, eu sei que tem a chave única para o
modelo do negócio. Ali, em todos os lotes x vão ser processados
na parte de são tal todas as os TIP tal, não sei, para a parte de são tal,
mas não sei se mas a gente tem uma ordem também.
O o Oeste chegou até a comentar qual que era Oo script que eles usavam lá,
mas eu esqueci o nome se você entrar lá no control center por cada tópico.
Você vai ver as partições e as chaves delas. E o esquema reis também, né?
Tem ali a parte do Álvaro dele e pra ordem de serviço eu lembro que quando eu
conversei com eles, né? Tinha sim, tinha, tinha aqui, né? É,
Norberto consegue extrair alguns exemplos?
Deixa eu pegar aqui agora, enquanto vocês estão falando,
eu vou abrir aqui. Você pode até extrair e mandar pra gente,
entendeu? Salvar alguns exemplos de esquina e de
partição de configuração pra gente como exemplos assim, meio que é aleatórios, né?
O ézio que ele comentou seria aquele analista que eu falei que é mais sênior
que tem. Foi até ele que disse pra mim aquela
questão do de que eles usavam interno.
Mas ele foi conversar com ele depois que o que o Carlos André disse que que não
era interno, era externo, né? Aí ele falou que deu um erro e que estava
tratando com Carlos André usar interno, aí eu não sei qual é o erro, tá?
Ele saiu de férias, eu não sei se vocês tiveram isso também,
tá? OOO, Wagner e Pedro Lucas, é o acesso ali quando a gente fala do
Indy. Point que acessa Oo Kafka, o esquema read, né?
A plataforma da confront.
Eu não sei se eles têm essa visão também. É,
vocês acessam usando é o endereço que é externo ou open shift,
ou o que acessa o serviço dentro do open shift cara é o do open shift,
o do open shift, aqui o control center éps, né?
ACBP lá de produção, tá? Então acho que.
É isso que esse é um questionamento também que eu queria ver com ele.
Pelo que a gente viu lá, está acessando externamente, ou seja,
passa pelo pelas soluções que necessitam acessar externo.
Eles passam pela UF 5 e tudo mais, né? O que é interno não precisaria, né?
E parece que o que está interno está os serviços, né,
que estão dentro do Ben shift, eles estão indo para fora e retornando de
novo para dentro para acessar o Kafka. Entendeu pelo dependendo do endereço que
vocês estão utilizando?
Esse era 1.eu, vou pegar aqui o as chaves aqui,
espera aí, é, são são: tá, Norberto? Um ponto é, é,
é isso que você falou que é a rede interna do open shift e não sair pra não
sair pra rede, pra rede Corp, né? E aí você entra na rede Corp,
aí você tem que passar por vários, vários nós, né? Passa pelo f 5,
passa pelo suici, já passa por faz um.
Dar uma volta ao mundo. E a outra coisa é que existem,
pelo menos aparentemente, existem micro serviços que estão com isso
hard coach e existem os que estão usando propriedades do do cobernets.
O ideal é que fosse tudo com todas essas configurações fossem próprias do
cobernets, né? Pra poder ser fácil de você alterar o ind
point.
32 por menos.
E a outra outra questão que seria uma boa prática é quando a aplicação toma um erro
e não consegue processar. Eu acho que o o traicket dela, o faine,
ele deveria dar uma mensagem para essa, esse esse evento, né?
Que ela não conseguiu processar e ir para uma DLQ, né?
Aí ele joga para DLQEA gente consegue analisar ADLQ você teria informação da
DLQ que você tá entrando na DLQE você aí consegue saber que hoje?
Aplicação de produtivia processar, isso não conseguiu,
então ela jogou pra essa DLQ aqui, aí você pelo menos tem uma noção de de
onde foi e consegue fazer um replay da DLQ, né? Recolocar,
botar um reidratar a mensagem via DLQ, isso também seria 111 prática legal,
desculpa aí, OADLQ, eu sei que vocês eu sei que vocês estão
utilizando, não sei se estão usando pra.
Pra todos os tópicos, né? 3 empresas no ambiente e sei o que que tá
acontecendo, né? Hoje a gente tem um primeiro grupo que a
gente já montou, né, que é da da Minas sul, sudeste,
Mato Grosso do Sul. E essa perto de vocês aí,
das 3 empresas de uma vez só, de tanto, tanto tempo.
Isso pra gente é muito crítico, porque quando a gente alterou um cadastro
em uma das empresas, a gente IA quebrar.
Pra todo mundo é, e hoje a gente é, hoje a gente não tem no adms uma forma de
integração do modelo de equipes. É, é, é por equipe, né? Vamos falar assim,
só manda o pacote inteiro, é o que eles aceitam. Hoje é assim,
isso isso está causando um desconforto Na Na questão do, do de quando dá erro, né?
Eu acaba dando erro no cinema, na empresa.
Todas as empresas é assim, cara, a gente desde o início a gente a gente
ficou esse gap aí, a gente tentou com eles uma forma de de
fazer essa integração de um de um outro jeito, né? E até então eu não tenho uma.
Não vejo uma saída assim, sabe? Não sei como é que você pode ajudar a
gente nesse ponto, não vamos continuar.
Ah, tá, então nesse caso aí que ele tá até
olhando, não sei se tem a ver com o que vocês
estão falando aqui, né? Esse é do lado do adms, né?
Esse processamento da equipe, mas aqui ó, eu tava vendo aqui,
realmente tem tem bastante tópico aqui sem q eu não sei se esse que vem do CDC,
eles se eu tô no mudo, deixa eu ver, não, não tá não tá não é?
Esse que são via CDC vem por exemplo do Oracle né?
Com conector seirce do banco com MGR, por exemplo, dual né? CFLCLPDA, tabela,
despachante, esses vem com aqui né? Mas é o que próprio lá do CDC é.
E aqui o esquema reis, né? Dele, mas pegando outros aqui que eu até
imaginei que tivesse tipo igual a locação, né?
Diz que tô no ambiente de homologação, tá? Eu não achei aqui,
não aparece aqui o esquema read nem aqui. Eu não sei se é porque tá em homologação
ou se realmente não colocou aí aqui coordenado. Mesma coisa é.
Lembro daquela conversa que a gente teve lá com a.
Com a galera do cigode lá que recebia os dados do cigode e depois fazia um
processamento, não tinha nenhum deles, tinha esquema Regis,
então do é aquele era do atendimento né? Da equipe do atendimento é mas Oo do o do
cigode eu imaginei que tivesse WFM porque era era 11 dos pré requisitos né iniciais
lá usar o esquema. Regis, na minha cabeça tava usando.
Esse de ordem de serviço. Eu achei estranho não ter não estar
separado por algum aqui, né? Mas aí aqueles que é separado por evento
e não tem bom, peço desculpa.
Voltei aqui, deixa eu ver aqui a ordem de serviço,
requisição. Não tá tendo nem movimentação. Parece não é porque?
É porque quando você olha as é, por exemplo, aqui ó, vamos ver aqui ó,
ordem de serviço, requisição, resposta, ordem de serviço, serviços,
ordem de serviço. Não, não, não precisa entrar não.
Eu quero dar um exemplo aqui, bota aí, ó, ordem de serviço.
Requisição, resposta, ordem de serviço e aquisição,
ordem de serviço programado, ordem de serviço e serviços,
a ordem de serviço e situação alterada. Vocês estão criando,
aparentemente vocês acabam criando alguns tópicos que são tópicos para o evento
específico, a mudança de estado específica daquele
daquela daquele agregado ou entidade, entendeu? E geralmente é.
É preferível você ter o quê você ter 11 os eventos da ordem de serviço.
Então eu tenho ordem de serviço criada, uma ordem de serviço alterada,
uma ordem de serviço, mas não ter tópicos pra isso.
Eu tenho só um tópico pra ordem de serviço, eu crio um event type,
aí dentro desse event type eu tenho lá qual é o evento,
e aí eu posso filtrar aquele event type e pegar só o que eu preciso,
mas eu consigo garantir a ordem, entendeu? E quando você cria?
Um evento, porque na naquele pessoal lá do
atendimento ficava mais explícito, você tinha um evento da criação da os,
você tinha um evento da alteração da os. Você não tem como garantir a ordem disso.
Eu posso o evento, eu posso processar a alteração antes,
antes de processar a criação. E outra, eu crio eventos demais, entendeu?
Eu crio tópicos demais, EE eventos demais e fica e fica e fica.
Cria mais, consome mais recurso do Kafka, entendeu? Acaba,
começa a consumir mais recurso. Então é e aí faz nesse cenário que eu tô
falando aqui, o primeiro, né, que eu falei que eu que eu teria 111
tópico de ordem de serviço. Faria sentido eu ter uma partição,
porque aí eu partistione um partistion q porque eu eu crio uma QI que é.
Da ordem do número, da ordem de serviço, e aí todos os eventos daquela ordem de
serviço vão cair naquela partição específica. E aí eu vou ter a ordenação,
eu vou ter o evento de criada, evento de alterado,
não sei que aí vai cair na ordem que eu que eu recebo,
e aí eu consigo processar de maneira ordenada, tá, então é, é, é uma forma, né?
Aqui é, esse aqui é bem legal, aqui é ordem de de serviço criado,
despachado.
Ordem de serviço criado, despachado ordem de serviço cancelado
aqui, ó, você vê que esses 3 aqui ó, esses 3, esses 3, esses 3 tópicos,
cada um está para um tipo de evento, mas o evento é da própria ordem de
serviço, entendeu? É uma mudança de estado da ordem de
serviço. Eu nunca, se eu preciso de ordenação disso,
eu nunca vou conseguir ter essa ordenação.
Então é isso, é uma coisa que deveria ser vista a gente,
mas até mesmo de repente, não faz sentido o que eu estou falando.
Ah, não, não preciso de ter organização, pode vir assim,
só que mesmo assim eu estaria criando muito, muitos tópicos, né? Então,
na verdade, aqui eu teria um único tópico que seria
ordem de serviço, e aqui o event type que vai estar lá No
No esquema, vai ser cancelado, vai estar, vai ter um valor cancelado,
vai ter um valor chamado, vai ter um valor criado.
Vai ter 11 valor despachado. Aí eu posso filtrar por esse event Tape.
Aí eu tenho o pailload, que é o esquema, o esquema que eu que eu do evento em
sinta, e aí eu posso botar no event Tape ou
outras coisas como Oo ID do evento, o ID do agregado.
Então o ID do agregado seria o ID da própria ordem de serviço. Eu posso ir,
aí eu vou fazer o que segregate ID ou ID da ordem de serviço,
ele vai virar OA minha chave é o candidato a ser a chave.
Do da minha partição, que aí eu consigo ordenar por aquele tudo
que for evento daquele, daquela, daquela chave, né, daqueles daquela,
pra mariqui, ele vai, ele vai estar numa mesma ordem,
ele vai cair sempre na mesma partição e vou automaticamente vou processar,
remover ordenado, eu consigo garantir que eu posso ter é é
escalabilidade de processo, entendeu porque?
Porque cada processo vai bater numa, numa, cada consumidor bate numa, numa,
numa partição específica, e eu não vou ter nenhum risco de.
De de um consumidor estar processando alguma coisa de uma ordem específica
antes do outro. Entendeu? Porque? Porque AA todas as todas as os eventos
daquela ordem específica vão estar na mesma partição, mais ou menos isso.
Por isso é que esse também aqui é ordem de serviço, arquivado, agendado,
bloqueado, cancelado, ó, lá a quantidade.
E eu ainda tenho ordem de serviço aqui que eu não sei pra que que serve,
mas estou falando assim, esses caras aqui todos estariam dentro de
ordem de serviço. Aí você começa a racionalizar,
pelo que eu entendi, eles, eles ficam dentro de ordem de ser desse
cara. A ordem de serviço mesmo eu acho que eles
são é duplicados, né? O dado pra pra cada situação, né? É,
mas se for isso, ainda é pior, né? Porque no caso do no caso do do
atendimento.
Eles tinham um evento, tinham um tópico que era que era ordem,
uma ordem lá qualquer. E aí eles quebravam em outros 7 tópicos,
que era o que cada cada evento do que ele tinha falado,
cada evento daquela da cada tipo de evento daquela daquela, daquela entidade,
eles eles criavam um tópico, então eu pego uma fila,
um evento que cai naquela fila, em vez de tratar naquela fila mesmo,
eu tenho um processo que.
Particiona isso que quebra essas coisas e cria outras outros eventos.
Então aí 11 evento que poderia ser um único evento,
eu acabo tendo mais 7 eventos, entendeu? Mais 7 eu entendi,
eu acho que eu não tinha essa visão e acho que a equipe de desenvolvimento
também não tinha essa visão dessa possibilidade de você fazer um filtro ali
na hora de consumir, entendeu? E aí, então, isso é uma, isso é uma coisa que.
Que eu considerei um ofensor, entendeu? Assim é reduzir essa quantidade de de de
tópicos, tá EE ter Fontes da verdade única,
entendeu? Porque quando eu tenho 11, porque eu não estou conversando lá com o
pessoal, ele é o mesmo evento que tava gerando lá,
que o time do sigois tá gerando provavelmente essa ordem de serviço,
digamos. Só que quando eles quebram, eles transformam aquilo e eles podem
inserir erros ali, entendeu por quê? Porque na verdade ele quebrou o evento,
entendeu assim?
O que eles tinham que fazer é consumir o evento,
o evento como está e executar alguma ação. Não pegar o evento como o evento e
transformar em outro evento, pra depois processar aquele evento com
aquelas informações que já estão no evento anterior. Quer dizer,
não faz muito sentido, entendeu? Você está processando à toa, entendeu?
Você está gastando recurso à toa. E o problema que a gente tem lá no.
Do time do open shift é, eu tenho uma quantidade de recursos que
estão sendo exauridos e quando eu entro em exaustão dos recursos,
eu faço o que eu tenho que comprar mais licença.
E aí eu tenho 11 programa de custo de licença, então faz faz muito sentido, né?
Porque Oo Kafka é premium, né? É uma coisa que e ele custa mais caro do
que os os outros tipos de fila também, né?
Mas pra esses processos, que é de negócio saber disso,
isso é importantíssimo aqui. Eu acho que por isso que eu disse que é,
é bom a gente bater um papo lá com com o desenvolvedor mais sênior, né?
Entender com ele essa questão e se foi isso mesmo, é propor essa melhoria, né?
Você, você entendeu? Wagner e Pedro.
Mas eu acho que essa era uma boa discussão para a gente ter junto ou com
eles participando também, para a gente ser igual. Você falou aí,
beleza, tem mais alguma coisa que vocês querem
ver aqui? Deixa eu só mostrar aqui uma rapidinho,
Ah, tá, vou compartilhar aqui com vocês. Esse aqui não é um trabalho.
O Vladimir acabou que saiu, né?
Depois, João, eu eu acho muito importante a gente
quando for gerar documentação, né? Uma coisa que eu tô percebendo, né,
que eu vejo sempre aqui é, eu já tinha essa noção até na época
quando eu tava na equipe de desenvolvimento. É,
são a forma como a comunicação interna aqui dentro da energia isso.
E até a questão dos é, os treinamentos normalmente são gravados,
né? E é alguém que tem mais senioridade, faz um treinamento,
passa a informação adiante e aí replica esse treinamento pros demais, né? EOE,
muitas das vezes tem falhas, né, tem furos e tem coisas que são replicadas,
porque não existe uma área específica ali de treinamento, entendeu?
E de repasse de conhecimento, né? Então, por exemplo, uma mudança dessa.
O cara que fez a gravação do treinamento, ele não vai voltar lá e fazer a edição do
treinamento e falar assim, ó, Oo, quando vocês quiserem dividir,
operacionar isso aqui. Ou você tem eventos, né?
Que é da mesma entidade? Não faz sentido. Vocês podem usar como você falou, né?
11 type event que você falou, né? Ali dentro do esquema head e tal.
Isso é uma coisa que depois a gente vai discutir, tá?
É geralmente o que eu tenho feito, tá, é aqui, é, é um exemplo, tá, é um exemplo,
não, não quer dizer que seja aplicado pra você,
é um exemplo que eu que eu fiz pra uma outra empresa, tá? A gente cria ADR, né,
decide um recorde, isso o que acontece, isso uma aí consegue olhar essa
informação e validar se aquilo que está sendo gerado tá conforme,
conforme OOA decisão de arquitetura.
Mas o que eu quero mostrar aqui não é nem isso,
eu quero mostrar só o que que a gente fez aqui, né, que essa é a estrutura que foi,
que foi definida, né? Então é, a gente definiu aqui o que eu tenho,
o event, isso aqui seria o esquema do envelope do
do evento, então eu tenho o event AD, que é OID do evento,
esse event AD deveria ser único, tá? Por quê? Porque aí eu consigo garantir,
aí depotência, eu tenho o event type, aquilo que eu tava falando com você ali.
Que são os eventos, o tipo do evento que é produto criado,
aquilo que você está ali, produto alterado, produto cancelado,
essas coisas. Tem o agregate type, que é o string, que é o nome do agregado,
por exemplo, produto, porque aqui a gente está trabalhando com
DDD, então e a gente pode até fazer isso, então eu tenho um produto, tá?
Então o agregate aí de no caso o agregate, o agregate string seria no caso.
Ordem de serviço naquele que você estava colocando ali o ID do agregado,
que seria a minha chave, que seria geralmente a chave do a chave,
a pecado do agregado tá onde quando ocorreu Oo soft né? Quem,
qual sistema serviço que produziu isso? O correlation ID ou a gente correlação
pra gente poder ter a correlação desse desses eventos.
A versão do esquema tá uma versão do esquino,
já que a gente tá e o pailode esse pailode.
É, a gente fez isso aqui, eu não precisaria desse pay load.
Eu poderia ter o esquema embaixo aqui, um pay load e o esquema aqui,
só que aqui a gente acabou. Como já tinham muitos eventos que que já
tinham sido gerados. Ele fez 11 inunion dos um inunion dos
avos do avro recordes do do tipagos, né? Que a gente tem aqui. Ele gera o esquema,
mas se você olhar aqui, ó.
Isso aqui resolve um Monte de problema pra vocês, entendeu? Entre aspas, né?
Não sei se é esse seria o ideal. Você consegue olhar o evento,
saber quem foi o sistema que produziu aquele evento,
se ele foi feito alguma alteração, você consegue filtrar,
você diminui a quantidade de de de tópicos,
porque você você vai ter um tópico por agregado, tá? É.
Que você sabe, quando quando o evento foi gerado,
você sabe quem foi a fonte, você tem um cor elation ID então esse cor
elation ID vai ser replicado. Se eu tiver uma transformação do evento,
eu vou manter aquele cor, elation IDE, eu vou ter que conseguir garantir a
correlação. Então, o que eu acho que falta aqui é,
é uma estratégia, né, para você definir um padrão de de eventos,
entendeu? Um padrão de esquema de eventos que que
seria como se fosse um envelope, né? Um envelope, esses eventos todos.
Quando sempre que a gente criar 11 evento, a gente tem que usar esse, esse,
esse envelope, sempre que eu criar o tópico,
vou ter que ter um envelope e esse tópico vai receber esses eventos com esse
envelope, entendeu? Isso é um exemplo. E aqui é o aqui é o é um padrão que eu
defini ali pro pessoal de ADR, né? Que teria teria OADR eu contexto teria,
porque eu tô gerando esse ADR.
É a decisão, né? Aqui no caso é o é o evento e assim por
diante. Da mesma forma que eu tenho aqui é um
Barramento da axonomia, então aqui eu vou definir a topologia e
vou definir o seguinte, que eu tenho que a minha grandalidade
tópica é puro agregado, eu defini que é puro agregado,
então eu tenho um agregado dentro desse agregado eu posso ter várias,
várias entidades, mas eu vou ter o tópico daquele agregado.
É como se eu tivesse uma relação de um pra um pra um pra m, né?
Então eu tenho minha tabela mestre, né? E eu tenho os deteios.
Então tudo isso vai fazer parte de um agregado, tá? O master detail.
Então todas as tabelas que fazem parte daquele que dependem daquela daquela
tabela, pai, elas estão dentro do agregado.
E aí eu tenho um único, um único tópico pra esse agregado, tá?
Então, por exemplo, se eu tiver um agregado,
que é no caso aqui produtos acadêmicos, eu tenho produto acadêmico,
eu tenho 2 tipos de produtos, é um produto que é curso e um produto que
é evento, evento, evento, evento, palestra, essas coisas.
Então eu tenho o agregado, é produto, produto, produto acadêmico.
Então eu vou ter um tópico só pro produto acadêmico,
eventos de curso e eventos de de evento.
De palestra, eles vão estar no mesmo agregado.
Então olha a racionalização de tópicos que a gente tem, entendeu?
Eu tenho bem menos tópicos e aí eu consigo pela chave,
não sei o que resolver pelo instagle pela chave eu consigo resolver o problema,
entendeu? É isso que eu eu só exemplifiquei,
não tô dizendo que seja assim que vocês vão usar esse skin,
esse envelope ou ou não tô nem a gente tem que avaliar isso nesse no cenário de
vocês, mas eu tô dando só um exemplo do.
O que que você consegue ganhar com uma reestruturação dessa, entendeu? Tipo,
uma coisa mais, mais é governável, né? E mais racionável e mais racionalizada em
relação a recursos, né? Depois, depois do Roberto,
eu vou querer te mostrar isso aqui, porque provavelmente a minha,
eu vou fazer uma proposta de gente gerar ADRs, entendeu?
Resolveria o problema do do da comunicação, né?
Eu vou fazer uma proposta para você em relação a.
A gente até não. Então hoje a gente tem até o wiki e tá
até já começando a gerar a Dr também, só que tem 111 questão que eu até mesmo
discuto com o pessoal interno aqui da da arquitetura,
que aqui é a parte de arquitetura, de soluções, mas AA parte,
vamos dizer assim, o engenheiro, né, que desenvolve,
ele assume um papel ali do lado de arquiteto, de software, vamos dizer, né?
E aí nesse caso, quando a gente cria ODRA, gente cria ele com uma visão muito mais,
mais alto nível, entendeu? É dos componentes que se integra.
Ele tem uma visão muito pro pessoal de Infra estrutura e pra equipe de
desenvolvimento. Eles seguem nesse o os padrões deles.
Mas eu acho que tem que ter uma união melhor,
porque é pode ter que ele deixa que o deixa que está com ele,
porque sabe aquela linha tênue entre 11 lado e o outro?
Entre arquiteto de solução, arquiteto de software, por exemplo.
E aí nesse caso, eu acho que aí ficou faltando algumas
coisas que eu acho que tava até conversando com o pessoal interno mesmo,
daqueletura de soluções da gente, tentar buscar isso pra gente também aqui,
entendeu? Porque eu tô vendo que acontece muita
falha, justamente porque você imagina que tá de
um jeito e aí não tá? E também não tem essa questão também de
do arquiteto ficar acompanhando a obra às vezes, entendeu? Eu fico sabendo.
O arquiteto de solução, ele deveria criar ADRs específicas pra
solução dele, mas continuam sendo ADRE. Essas é. E aí o arquiteto de de domínio,
né? O arquiteto Oo arquiteto corporativo, ele vai criar ADRs mais estruturais, tá?
O arquiteto, no caso de vocês.
Que eles têm algumas ADRs, é estruturante. Então, por exemplo, é, eu vou criar uma,
vou, digamos, eu vou criar uma Dr que vai definir qual
é a topologia do do Kafka, concorda? É estruturante. O arquiteto de software,
ele tem que seguir essa Dr. Ele pode até fazer algumas outras ADRs
específicas pro software dele, tá? Algumas decisões arquiteturais pro
software dele, mas aí, mas ele não pode infringir.
AA regra é como se a gente estivesse fazendo o seguinte,
a gente criou uma espécie de Constituição, tá? Eu posso criar leve em cima daquela,
daquela, daquela, daquela Constituição, mas eu não posso infringir a Constituição,
não posso quebrar uma regra definida, entendeu? Então aí,
caso eu quebre essa regra, o que que acontece?
Eu deveria alterar a estruturante. Aí o arquiteto de software tem que
conversar com o com o arquiteto de.
De soluções, tá? E aí o arquiteto de soluções,
eles entram em um acordo, tá? A outra coisa que eu propus aqui,
mas ainda tá em em vigência, é ter 11 fluxo de aprovação. Então,
quando você, arquiteto de soluções, faz 111 Dr, você tem que ver quem,
quais são as áreas que são impactadas, tá? E buscar a aprovação.
Dessas, dessa Dr com as áreas impactadas, e aí ela virou.
Aí a gente gera um consenso e a partir desse consenso ela vira uma Dr da empresa,
não a Dr. Do nordeste, porque isso acontece muito, tá? É,
a gente cria uma Dr ou cria alguma regra, e a regra da pessoa, entendeu a regra?
Não sei se acontece aí, mas.
Eu já vi várias vezes acontecer isso. Ah, não,
isso aqui é aquela decisão do Norberto. Isso aqui é a regra do Norberto ali que a
gente vai ter que seguir. A partir do momento que o cara fala regra
do Norberto ou regra da da que é uma regra de arquitetura,
é porque ele não consentiu com aquilo. Ele não se sente parte daquilo,
ele se sente como se eu sou obrigado a seguir aquilo.
E todo ser humano quando é obrigado a fazer alguma coisa, ele tenta burlar, né?
Faz. Faz muito sentido essa parte da concessão.
Entendeu? Então eu acho que o mais importante não é
nem AADR em si, mas Oo mais importante é fazer um
consenso do que é o melhor, né? Pra pra empresa.
Aí você tem que envolver as áreas, né? Porque às vezes o cara fala, pô,
mas isso aí vai vai ser complicado pra mim, não sei o que.
E aí você vai abrindo concessões, né? Aí você vai negociando e vai chegando num
num, num local onde onde você onde tem um
acordo, né?
Que é o viável a fazer, né? Então isso é legal, tá?
E a outra coisa é o seguinte, é documentar, né,
porque uma coisa é você falar, né, outra coisa é você escrever.
Quando você escreve, tem um peso maior, então quando as pessoas escrevem e
concordam, quando a pessoa fala assim, Ah, eu não concordo, por causa disso,
aí você vai botar assim, ó isso aqui, essa decisão, ela não foi,
ela não pode ser feita assim por causa disso, se a pessoa que falou aquilo, né,
o isso, né?
Ela falou, não, não quero que escreva, então é porque tem alguma coisa errada,
entendeu? Assim, olha, se se se for uma coisa racional,
uma coisa não for uma coisa política, se for uma coisa técnica,
não sei o que que a gente tá discutindo, não tem um,
não tem necessidade de você não poder colocar aquilo no documento, entendeu?
Você falou assim, Ah, esse documento, isso aqui foi a gente restringiu ou não
vai utilizar por causa disso, né? E gera um gap, né?
Isso aqui vai ser um gap, isso aqui tem que ser tratado a posterior.
Entendeu? Isso aqui ficou em aberto ainda, até a gente decidiu isso aqui,
mas essa parte aqui ficou em aberto, entendeu? E aí você consegue ir evoluindo,
tá, então isso é uma coisa que é que é que é
interessante. Acho que, cara, a gente tem outra reunião, cara, né? Tem,
acho que é 10 e 10 e meia, 10 e meia isso. Não sei se você poderia estar aqui a essa
hora também, né, que já passou o período, né?
O Norberto, essa parte de lk, eles não cuidam não, né? Do não.
Então a gente vai conversar com o pessoal da lk também. É a próxima reunião, né?
Uma das dor nossa aqui que a gente faltou a gente falar é,
a gente não sabia se eles vinham. Isso também é a questão do da quantidade
de log do alicat tipo às vezes 11 OS, né, ela tem, sei lá, 500 linhas de logs, sabe?
Então aí pra gente identificar um incidente ali,
no caso tem que ser só a galera assim de desenvolvimento,
tem mais proeficiência assim de conseguir, porque eles já sabem qual serviço faz o
quê. Então aí eles já filtro pelo serviço, filtro por algumas coisas que que fica
mais fácil pra eles, sabe? Mas Ah, tem muito log lá que acho que vai
debugando tudo, né? Traz tudo. É eu essa questão do da geração do log,
né?
É aí pra gente conseguir identificar o erro no nosso dele. A gente sofre.
E se for do do do Kafka, então é muito mais verboso, né?
Porque é Java. Então todo um evento tem aquela árvore,
né? Ali uma coisa que chama a outra, que chama a outra,
que chama a outra e ele vai gravando tudo.
Eu pensei, por exemplo, classificar os eventos,
às vezes os caras ficaram de uma ocorrência, aí tem log de banco,
tem log de mongo, tem log de chamada, tipo assim, de repente se classificar,
a gente consegue retirar o que a gente não quer, né?
Não não classificar só pelo log leve de devolver informação, não classificar,
mas isso aqui é só log de banco, não é o que eu quero ver. Então eu tiro,
acho que assim, sabe como as coisas assim, eu sei que não é banco, sei que é,
não sei, mas assim, de fato é muita coisa, é, a gente pode ver isso.
Também. Bom, ele caiu aqui, né? Mas ele vai ouvir a gravação e aí a gente
manda pra eles também, tá? Mas aí é uma boa de adicionar na
documentação. Tá buscando essa essa empresa descer
depois do da entrada lá do adms do primeiro empresa que aconteceu algo
quando subiu ali, uma contingência, ele ficou fora, né?
E aí o pessoal perguntou, pô, será que vai aguentar as 9 empresas, né?
Subir às 9?
E aí foi identificando os problemas. Às vezes tinha problemas de configuração,
alguns alguma parte de desenvolvimento, teve que fazer mudança,
tinha conceitos ali que não tava legal, tinha coisas do lado do ADMS que,
por exemplo, da mesma forma que ele comentou aqui das
partições das filas do lado do ADMSA, fila deles não,
não é dividida em partição, é, não tinha essa questão daqui, né?
Partitsion q ali do lado do do ADMS, eles não usam um Kafka lá.
É, e aí era uma fila única com todas as os
incidentes, entendeu? E por algum motivo essa fila estava não
estava conseguindo o processamento, não estava conseguindo suprir essa fila e
estava engargalando do lado da adms. Aí eles fizeram alguma mudança no código
deles, eu não sei exatamente por que que agora
melhorou, então assim foi resolvendo essas coisas,
aparentemente vai, vai, tá indo, né? Já foram 3 empresas aqui,
isso foi na primeira.
EE, não está acontecendo, eu não sei né? Talvez vocês saibam em dia está
acontecendo alguma coisa, mas ninguém me reportou onde estava
acontecendo depois que implantou as 3 empresas,
o mesmo que aconteceu quando foi na pós implantação, ali na primeira contingência.
Não, o que o que tá rolando mais é aquela mais,
mas é bem raro, tipo assim não acontecendo,
não é A Fila entupi ali foi algum consumidor parou,
tipo é esses problemas que tem.
Mas assim, de esse que você como volta do do
consumidor, que às vezes tem 11, né? Um tem um pode ali e tá e aí ele tá
processando mais do que os outros. Aí eu a gente percebeu aqui.
Eu falei assim, bem na hora que eu falei assim não,
e acabou Oo tempo da reunião, né? Talvez você tem outro aí,
você caiu e o pessoal ó, foi rápido, Hein? Não, não, eu cai, foi mal, cara.
Eu falei aqui um Monte de coisa, sem, sem, sem perceber,
mas basicamente o que eu falei foi que eu achava que Oo ofensor é é essa quantidade
de tópicos, tá assim, uma visão bem enviesada, né?
Pelo que eu tô olhando, se a gente conseguisse reduzir esses
tópicos e criar uma coisa mais estruturada,
a gente conseguiria habilitar um evento sócio.
E aí o ewinsourcing, ele resolve um problema do do pessoal do
plaen shif que que que gostaria de tirar um tirar backups do Kafka, né,
pra fazer a contingência e eles não tem como fazer backup do Kafka. Por quê?
Porque não dá pra fazer backup de Kafka, entendeu? Então o que que acontece?
Mas se eu se eu ir armazenando os eventos em algum objeto histórico ou alguma
alguma coisa particionário, por exemplo, eu faço uma partição de 1515 minutos,
concordo, eu consigo fazer um incremental.
De 15 em 15 minutos eu vou ter uma diferença só de 15 minutos de de eventos
pra 111, site de contingência, um site de backup dessa estrutura de
eventos. E aí fica mais tranquilo de fazer.
Depois a gente conversa mais e queria entender mais como é que a gente poderia
fazer isso. Uma outra equipe terceira, né? Conversou com a gente,
falou em usar é um outro um outro broker de Kafka e enviar pra pra outro Kafka.
Mas eu eu não sei se seria melhor alternativa por questão de custo também,
né? Mas eu acho que vai barrerar em custo, né? É, vai barrerar em custo.
Aí essa que você comentou, eu achei melhor até então é,
você tem que ver se se isso faz sentido, entendeu? É se eu tiver 111,
ambiente onde eu preciso ter um.
O meu SLA de de de contingência é é de segundos, entendeu? Assim,
aí faz mais sentido eu ter uma estrutura toda, ter replicada toda a estrutura,
incluindo o Kafka e reenviar pro Kafka, e esse ambiente fica ligado o tempo
inteiro. Se eu tiver um ambiente que é desligado,
que eu tenho um SLA que eu tenho, que eu posso ter 111 perda de de dados,
entendeu? Controlado assim com.
Aí eu acho que é mais, bem mais barato eu ter um ambiente onde
eu pego a, pego uma replicação, pego um evento sócio, replico, o dado tá,
quando eu subo num ambiente, eu equalizo, entendeu? Mas é verdade, mas aí é decisão.
Aí tem que ver qual é o essa. Mas independente disso,
o evento sócio serve para várias coisas, incluindo refazer o replay do evento que
você precisa na hora que você precisa.
Bem mais fácil. O pessoal comentou aqui também de uma
necessidade deles, mas tem a ver com a parte do lk ali,
porque às vezes eles vão fazer pesquisa, né? E até mesmo investigar.
Usam muito o lk, que tem os logs lá e eles tem umas
questões que quando vão fazer os filtros, dependendo do tipo de erro aí eu acho que
seria mais com a equipe de desenvolvimento ali junto com a equipe de
lk.
É, eles fariam de filtros pra dizer, por exemplo, pô,
eu queria filtrar por tipo do erro, né? Não em relação ao seu erro,
é o status do erro ali, né? Mas, por exemplo, se é erro de banco,
se é erro de e assim por diante, mas isso é tranquilo,
mas eu acho que é só é. Então isso que eu falei é tranquilo,
eu acho que é mais só envolver a equipe de desenvolvimento EEA,
equipe ali do alecar.
É, é tranquilo, é tranquilo, tá, mas é o lk também tem uma modelagem, né?
Então, dependendo do modelo que esteja lá, você vai fazer,
ou você vai fazer uma pesquisa, texto livre, né?
Ou ele vai ter 11 campo lá de tipo de erro, e aí você vai lá e faz a pesquisa,
filtrando naquele campo que é melhor, né? Seria melhor se ele tivesse, tá?
Então, mas se não tiver, ele pode criar uma regra no LKE,
criar um campo virtual lá, entendeu? E você acessar ali, isso também é viável,
entendeu? O que fazer? Sim. Bom, beleza, tem mais alguma coisa, Pedro e eu, vá,
não só só isso, só isso tudo, né, beleza?
Show, valeu. Até a próxima, então. Valeu, pessoal. Valeu. Tchau. Um abraço, tchau.