Estudo de caso: como uma softhouse reduziu downtime com o menor custo

Uma softhouse de médio porte (vamos chamar de SoftHouseX) mantém, em regime de contrato, dois sistemas críticos para um cliente do setor de serviços com o menor custo. O contrato de mantenimento e SLA: havia multa por hora de indisponibilidade quando o sistema ultrapassava o limite acordado, basicamente o valor foi calculado a partir da media de faturamento por hora.

O problema enfrentado era o que fazer para diminuir o risco de downtime, inclusive durante manutenções e correções.

1) Contexto e requisitos

A SoftHouseX operava:

Sistema A (Marketplace): Como o nome diz, basicamente ele é um marketplace com alto volume de transações.

Sistema B (API de Integrações): integrações com parceiros e automações; se para, filas acumulam e operações travam.

Requisito contratual: indisponibilidade acima do limite gera multa por hora, com apuração baseada em registros de monitoramento e evidências de indisponibilidade (time-outs, falhas de health-check e indisponibilidade do endpoint principal).

Meta interna da SoftHouseX:

• reduzir incidentes (Tirar o macaquinho das costas);
• reduzir MTTR (tempo de recuperação) de horas para minutos;
• tornar manutenção previsível e rastreável.

2) Situação inicial

Ambos os sistemas estavam hospedados em um único servidor (modelo “tudo junto”):
aplicação + banco no mesmo host,
atualizações feitas “in-place” (deploy direto na máquina),
backup existia, mas restore não era testado com frequência,
monitoramento era básico (ping/HTTP simples), sem observabilidade de causa.

Principais fontes de indisponibilidade (Por ordem):

• Instabilidade/interrupções na camada de conectividade do provedor anterior (incidentes de rede e rotas), que geravam downtime mesmo quando a aplicação estava saudável.
• Deploy com efeito colateral: atualização de dependência quebrava o Sistema A e, por estar no mesmo host, o Sistema B era afetado por consumo de recursos.
• Manutenção do SO: reinício para atualização de kernel derrubava tudo.
• Falha pontual (disco/rede/stack): mesmo que rara, quando ocorria o impacto era total.
• Banco como ponto único de falha: qualquer problema no banco derrubava o ecossistema.

O resultado era previsível: poucos incidentes, mas caros. O problema não era “ter incidentes”; era a arquitetura transformar qualquer incidente em parada total.

3) A decisão: separar o problema em duas camadas

A SoftHouseX entendeu que precisava resolver o downtime em duas frentes:

• Arquitetura e processo (redundância + modo de operar)
• Governança de continuidade (contrato, SLA, previsibilidade e compensação)

Foi nesse contexto que decidiram hospedar na Name Host e contratar o Plano de Alta Disponibilidade (HA), contratado à parte, voltado a ambientes críticos, com previsão de indenização de R$ 1.000 por hora em caso de indisponibilidade.

A lógica foi simples: não basta “prometer esforço”, era necessário compromisso mensurável.

4) Arquitetura “depois” (sem fantasia, com trade-offs)

A SoftHouseX adotou um desenho que reduz pontos únicos e torna manutenção segura:

4.1. Separação por função e impacto

• VPS App-A (aplicação do Sistema A)
• VPS App-B (aplicação do Sistema B)
• VPS DB (banco de dados dedicado)
• Proxy/Balanceamento na frente (para roteamento e health-check)

Mesmo sem entrar em detalhes proprietários, a mudança central foi: um problema não derruba o outro sistema por disputa de recursos.

4.2. Deploy com rollback

Eles implantaram um fluxo de deploy com:

build versionado, migração de banco controlada, capacidade de rollback rápido caso health-check falhe.

Isso não elimina bugs. Mas reduz drasticamente o tempo entre “deploy ruim” e “voltar a operar”.

4.3. Monitoramento como critério de decisão

A SoftHouseX colocou monitoramento externo para:

• Endpoints críticos do Sistema A
• Endpoint principal e rota “/health” do Sistema B e
• Latência e taxa de erro,
• Alertas por degradação (não só “caiu/subiu”).

O contrato de multa por hora não perdoa “eu acho que caiu”. Então precisavam de evidência objetiva.

5) A política de indisponibilidade (para evitar discussão)

• Um ponto que economizou atrito com o cliente foi definir o que conta como downtime:
• Downtime real: endpoint crítico indisponível ou taxa de erro acima do limiar por X minutos contínuos.
• Degradação: latência anormal sem indisponibilidade total registrado, mas tratado fora da multa por hora (a menos que o contrato diga o contrário).
• Janelas de manutenção: previamente acordadas (quando aplicável), com comunicação formal.

Sem isso, todo incidente vira “disputa de narrativa” — o que é péssimo quando há multa.

6) Onde entra o Plano de Alta Disponibilidade da Name Host

A SoftHouseX já tinha feito o “trabalho duro” (arquitetura + processo). O Plano de HA da Name Host foi contratado como uma camada adicional para ambientes críticos:

Plano de HA é contratado à parte (não é padrão em todo serviço).

Em caso de indisponibilidade acima do limite contratual, haveria uma indenização de R$ 1.000 por hora.

A leitura pragmática foi: a softhouse reduz risco com engenharia; o plano de HA reduz risco residual com compromisso formal.

Isso é particularmente útil quando você presta serviço e responde por disponibilidade: você não controla todas as variáveis, mas pode estruturar responsabilidade e previsibilidade.

7) Resultados observados

Após 90 dias de operação no novo modelo, a SoftHouseX reportou:

Incidentes com parada total: caíram de alguns por trimestre para raros e curtos.
Tempo de recuperação (MTTR): reduziu significativamente, porque rollback e isolamento evitavam investigação longa para voltar a operar.
Manutenções: deixaram de ser momento de risco e viraram rotina, pois o deploy era controlado e observável.
Discussão de multa: diminuiu, porque havia evidência clara do que ocorreu e quando ocorreu.

Importante: O ganho veio de duas decisões realistas:

• reduzir as chances de parada total;
• reduzir o tempo de recuperação quando inevitável.

8) O que deu errado?

Nem tudo foi perfeito. Dois pontos apareceram:

• Migrações de banco exigem disciplina
• O maior risco não estava na infraestrutura, mas em migração mal planejada. Eles passaram a exigir “migração reversível” ou estratégia de migração em duas fases.

Monitoramento mal calibrado gerava ruído
Muitos alertas e muitos falsos positivo que cansaram a equipe. Ajustaram thresholds e criaram níveis de alerta (degradação vs indisponibilidade).

9) Checklist replicável

Se você mantém sistema com penalidade por indisponibilidade, vale validar:

• Você separou aplicações críticas para reduzir efeito cascata?
• Seu deploy tem rollback rápido e health-check real?
• Você definiu o que é downtime (e o que não é)?
• Você mede do lado de fora (monitoramento externo)?
• Você tem evidência para auditoria/contestação?
• Você tem um plano formal de continuidade (SLA/HA contratado) para risco residual?

Conclusão

A combinação que funcionou para a SoftHouseX foi:
engenharia e processo para reduzir falha e acelerar recuperação;
Plano de Alta Disponibilidade da Name Host, contratado à parte, para formalizar compromisso em ambiente crítico, incluindo indenização de R$ 1.000 por hora.