do latim: força, vigor, potência vital
O trabalho de operar em escala. A disciplina do como isso roda continuamente, sob carga real, quando não pode quebrar? Arquitetura para carga de verdade, observabilidade para comportamento estocástico, modos de falha mapeados.
Em algum lugar da sua organização existe um sistema que funciona. Ele sobreviveu à demo, ao piloto, à sala cheia de gente concordando — a todo teste que alguém pensou em rodar antes de soltá-lo no mundo.
Produção faz perguntas diferentes. O que acontece na hora em que ninguém está olhando? Quando uma dependência some sem aviso? Quando dez mil pessoas chegam de uma vez, não as dez que testaram com paciência?
É para esse momento que o Vis existe — não para duvidar do que já funciona, mas para descobrir, antes da realidade, exatamente onde ele para.
Um trabalho de Vis começa onde o Ratio termina: com um conceito que já se provou — validado aqui, ou validado em outro lugar. Dali em diante, o trabalho é concreto. Construímos, ou reconstruímos, para que rode continuamente, sob carga real, com os modos de falha que mais cedo ou mais tarde vão ocorrer, já mapeados antes de acontecerem.
Não vamos abrir com uma contagem de sprints, e vamos te dizer por quê: um sistema que entrega no prazo e falha em produção cinco meses depois não entregou no prazo de verdade — entregou cedo, e adiou o resto da conta, com juros. Isso dura o tempo que o sistema precisa para se tornar confiável. Não o tempo que uma apresentação um dia prometeu.
Você não recebe um sistema que simplesmente funciona hoje. Recebe um projetado contra os modos de falha que ainda não aconteceram — mapeados no papel, de propósito, antes que a produção os encontre sozinha.
Você poderia pedir ao time que construiu o protótipo — mas quem está mais perto dos atalhos costuma ser quem menos os enxerga como risco. Poderia contratar uma integradora de sistemas — a maioria é feita para contratos longos e equipes que entram e saem, onde quem escopa o sistema raramente responde por ele às três da manhã. Poderia contratar engenheiros por contrato — eles entregam código que roda hoje, mas engenharia de produção é julgamento sobre a falha que ainda não aconteceu, e isso não é uma habilidade alugada por sprint.
A Eligere trabalha no espaço entre esses três. Só principals — quem mapeia os modos de falha é quem constrói os caminhos de recuperação. Sem banco de reserva, sem repasses, ninguém aprendendo às suas custas, no seu sistema, em produção.
Essa não é uma pergunta nova para nós. É a pergunta por trás da maior parte do que escrevemos.
Às vezes, a resposta honesta é: recomece.
O protótipo que provou a sua ideia foi feito para provar uma ideia — rápido, leve, tolerante a atalhos que um único testador nunca notaria. Produção não os tolera. Às vezes a fundação existente sobrevive a essa tradução. Às vezes não — e o certo é dizer isso antes que o sistema diga por você, na pior hora possível.
Isso não é trabalho desperdiçado. É o trabalho, no prazo. O seu — não o de uma queda.
Se existe na sua organização um sistema que funciona na demo e te preocupa em produção — essa é a conversa que vale a pena ter.
Começar essa conversa →