# Sugestões de melhorias, dúvidas e problemas no Delivery do Monolítico

1. O Selftest não é claro. Dá `Execution Failed+NPEs+Erros` e está tudo bem. Já faz anos que isso é assim. Precisamos enxugar o selftest para mostrar apenas o que deu problemas. O que deu certo não precisa mostrar.
1. Porque temos que pedir para o DBA e esperar que seja inserido manualmente no banco de dados parameters e features switches? Não seria mais fácil ter um processo padrão e automatizado para isso?
1. Não temos um modo visual para saber se está chaveado para galápagos 100%. Ficamos aguardando a msg no #deliveryps dos sysadimins e isso impacta em segurança e velocidade. Porque não temos um dashboard em tempo real do estado das aplicações?
1. O graceful das jvm de produção não funcionam bem graceful --- demos kill nas hsamcro 1 e 3. Isso deveria ser assim mesmo?
1. As hsamcro logam muitos _erros normais_. Veja o filtro no splunk para ignorá-los:

Se esses erros são frenquentes deveríamos pedir para os times responsáveis para de logar esses erros.
1. Pelas zox não tive acesso as hsamcro de tb 1 e 2.
1. Quando os pacotes são instalados nas máquinas, precisamos esperar que alguém informe no #deliveryps. Não existe um lugar comum para vermos e garantirmos que as versões instaladas estão corretas. Só conseguimos ver após as aplicações iniciarem pelo splunk.
1. Quando o pessoal está executando procedimentos no banco de dados não temos visibilidade do que está acontecendo. Temos que esperar eles executarem script a script manualmente. Além de a verificação também ser manual pelos DBAs. Devemos automatizar esse processo usando flyway ou ferramentas similares para termos além de tudo, auditoria onde todos possam consultar e não somente os dbas/ads.
1. O chaveamento para galapagos ainda é "manual"? Pelo o que eu ententi, alguém vai lá na mão e retira do DTC, espera que todos caiam no Galápagos para falar: "blz, agora estamos chaveados". Porque não temos isso mais automatizados, de ponta a ponta, até mesmo a notificação?
1. O Cassol teve que lembrar pra subir GT e TB juntos para voltarmos de Galápagos o quanto antes em caso de problemas nos teste em GT. Podemos automatizar isso com o foco em ficar o mínimo possível fora do ar nos deliveries com parada.
    > _Porque, em Galápagos, [em torno de] perdemos 30% das transações._ --- Cassol
1. Não temos previsibilidade na subida do JMS/huricane. Tínhamos várias mensagens na DLQ. Podemos mover essas msgs antes de subir as hurricanes e depois volta-las para as DLQs. Assim ficamos menos tempo em galápagos ou fora durante o delivery. Demoramos 16min em uma das máquinas desta vez;
1. Identificamos que as hurricanes estavam demorando muito para subir. Identificamos isso pela velocidade do log correndo na tela. Não temos um indicador do progresso do carregamento das filas na hurricane. Precisamos ter mais previsibilidade. Talvez um simples contador na `qtde total de filas -filas que já subiram` para sabermos o quanto falta.
1. As filas vão carregando e não sabemos quando vai terminar, se é a última fila ou não. Precisamos identificar o progresso. Uma das hurricanes demorou  16m:30s:964ms para iniciar;
1. Para subir o jboss, precisamos garantir que todos os EJBs estão STARTed e funcionado. Identificamos o progresso do start dos EJBs pelos logs. Precisamos ter visibilidade e previsibilidade do estado de cada EJB (container/service) para garantir que tudo está ok em produção;
1. Precisamos ter o status de cada EAR para garantir que tudo subiu dentro de cara JBOSS;
1. Colocar os ambientes de volta no ar depende dos sysadmin fazem de forma manual. Temos que lembrá-los sempre de não fazer isso sem que executemos os testes de delivery. Precisamos de garatias e evidências que os testes passaram conforme o esperado antes de colocar o ambiente no ar novamente;
1. Só conseguimos testar um ambiente se galápagos estiver desabilitado para esse ambiente por causa de redirecionamento nos apaches. Não conseguimos executar o isolamento completo para execução dos teste de delivery, dependemos de chaveamento dos sysadmins;
1. Gastamos muito tempo durante o delivery verificando se as histórias dos times estão ok. Todos deveria usar feature toggle e subir desativado. Assim testamos apenas se as feature toggle não quebraram nada. Depois, durante o dia, pedimos para ligar as features e testar as novas features em produção;
    * Em um feature específica ficamos validando várias coisas antes de seguirmos com o rollforward/rollback;
1. Não temos ou não encontrei um mapa com todas as dependências que o pagseguro depende em QA atualizada. O mais próximo foi https://grafana.stg.pagseguro.intranet/d/DRyD2-cZz/qa-health?orgId=1&from=now-3h&to=now. Garantir que todas a dependências estejam saudáveis na execução dos teste em QA diminui problemas nos testes de integração;
    * Colocar o QA no new relic permite ter essa visão de dependências atualizada dinamicamente em runtime e monitoramos se as dependências estão saudáveis ou não por lá. Assim, ganharemos tempo nos teste automatizados e diminuimos tempo na semana de delivery.


## Cayman

* Quando o banco entra em modo restrito, disparamos muitas conexões e demoramos muito para morrer e subir em outro slave. Acho que podemos melhorar, pelo menos em questão de logs no splunk;
* Para cada "erro" de lock logamos várias vezes no splunk. Acredito que não precisamos logar nada ou pelo menos diminuir o volume de logs:

        2019-10-01 05:09:18.527 ERROR [] [b.c.u.p.c.s.l.SelectForUpdateLockStrategy] (SimpleAsyncTaskExecutor-10:) cid=b2004e5398d47b2d@ha_cm_payment_release_in,  m=lockAccounts2
        2019-10-01 05:09:18.527 ERROR [] [b.c.u.p.c.s.e.FinancialMovementScriptExecutor] (SimpleAsyncTaskExecutor-10:) cid=b2004e5398d47b2d@ha_cm_payment_release_in,  br.com.uol.ps.cayman.exception.LockAcquisitionException: m=lockAccounts
        2019-10-01 05:09:18.529 WARN  [] [b.c.u.p.c.s.e.FinancialMovementScriptExecutor] (SimpleAsyncTaskExecutor-10:) cid=b2004e5398d47b2d@ha_cm_payment_release_in,  m=handleError, e=lockAcquisitionException
        2019-10-01 05:09:18.529 INFO  [] [u.p.a.p.SimpleTimeTracker] (SimpleAsyncTaskExecutor-10:) cid=b2004e5398d47b2d@ha_cm_payment_release_in,  tag=FinancialMovementScriptExecutor.execute.error,start=1569917358517,duration=12
        2019-10-01 05:09:18.529 ERROR [] [b.c.u.p.c.s.s.ScriptExecutorListenerAdapter] (SimpleAsyncTaskExecutor-10:) cid=b2004e5398d47b2d@ha_cm_payment_release_in,  Erro processando request de movimentacao financeira.
        br.com.uol.ps.cayman.exception.LockAcquisitionException: m=lockAccounts
* Ainda estamos logando em duplicidade algumas informações de estatísticas. Vamos remover o quanto antes:

        2019-10-01 05:11:54.751 INFO  [] [b.c.u.p.c.s.s.ScriptExecutorListenerAdapter] (SimpleAsyncTaskExecutor-5:) cid=a939173aef25a9cf@ha_cm_payment_in,  m=ONMESSAGE,cid= 968D6176807408FA@HA_CM_PAYMENT_IN,initExec=01-10-2019 05:11:54.750, endExec=01-10-2019 05:11:54.751, duration=1


## Sugestões e abordagem

Aqui deixo algumas sugestões de abordagens para escolhar o que fazer para melhorar o processo de delivery do monolítico e até priorizar demandas.
Na minha opnião devemos priorizar apenas o que:

1. **Aumenta a agilidade.** O que nos faz entregar mais rápido;
1. **Mitiga riscos de falha humana.** Tudo tem que ser automatizado e auditável. Devemos conseguir, em um único lugar ter um histórico linear no tempo sabendo o que ocorreu, deu certo e o que falhou. (Um log dos eventos que ocorreram seria bem legal)

Pelo o que percebi, as filas são os pontos principais no delivery e talvez o ponto que mais demora. Priorizar melhorias nesses pontos traria resultados mais expressivos.