A matemática que ninguém faz antes de montar um NOC interno
Cobrir um turno 24x7 não significa contratar uma pessoa. Significa contratar várias. Um dia tem três turnos; um ano tem 365 dias, férias, baixas, feriados e fins de semana que não desaparecem só porque a operação continua a precisar de vigilância. Para garantir que há sempre alguém a observar, sem falhas, são precisas várias pessoas por turno coberto — não uma. Multiplique isso pelos salários de perfis capazes de tomar uma decisão de escalonamento real, e não apenas ler um alerta e reencaminhá-lo no Slack, e o custo deixa de parecer o de "uma pessoa a vigiar um ecrã" e passa a parecer o de montar um departamento inteiro.
E isso é só o custo das pessoas. Antes de o primeiro alerta bem formado chegar ao ecrã certo, é preciso construir a stack de observabilidade, definir limiares que não gerem ruído, escrever runbooks que alguém consiga seguir às quatro da manhã sem ter de pensar, e montar uma política de escalonamento que decida quem acorda quem e quando. Isso não é um projeto de fim de semana. São meses de iteração, normalmente aprendidos à custa de incidentes mal geridos antes de o sistema amadurecer de verdade.
Vigiar não é a parte difícil. Decidir, sim
Qualquer pessoa consegue olhar para um dashboard. O difícil é saber, no momento exato em que uma métrica sai do intervalo normal, se isso é ruído normal de uma sexta-feira à tarde ou o início de uma falha que vai custar dinheiro real se ninguém agir nos próximos cinco minutos. Essa decisão precisa de duas coisas ao mesmo tempo: profundidade técnica para entender o que está a acontecer, e contexto de negócio para saber quão grave é realmente. Um operador a rodar numa escala interna, para quem isto é mais uma tarefa entre outras quinze, raramente tem as duas coisas. Uma equipa externa especializada, que já viu o mesmo padrão de falha em infraestruturas semelhantes dezenas de vezes, normalmente tem.
Escalar bem — aumentar capacidade antes de o utilizador notar lentidão, reduzi-la assim que o pico passa para não pagar a mais — é exatamente o tipo de decisão que beneficia da repetição. Uma equipa cuja única função é esta, todos os dias, desenvolve um critério que uma equipa interna, para quem isto é secundário, simplesmente não tem tempo de desenvolver.
O dia em que o único que sabe está de férias
Toda operação montada com pouca gente tem o mesmo ponto fraco: depende de essa pouca gente estar disponível. Se o único engenheiro que realmente entende como escalar a sua infraestrutura está de férias, de baixa, ou simplesmente a dormir quando dispara o alerta crítico, não há plano B — há um incidente que se arrasta enquanto alguém tenta localizá-lo ou improvisar sem o contexto necessário.
Um fornecedor de outsourcing sério não tem esse problema porque não depende de uma pessoa: depende de uma equipa com redundância real, documentação partilhada e processos que não vivem só na cabeça de alguém. Quando essa pessoa vai de férias, o serviço não se ressente, porque nunca dependeu dela em primeiro lugar.
O que a sua equipa deixa de fazer quando vigia em vez de construir
Cada hora que um engenheiro sénior passa de prevenção, agarrado ao telemóvel à espera de um alerta, é uma hora que não está a desenhar produto, a rever arquitetura, ou a resolver o problema que realmente move o negócio. O custo de oportunidade de ter a sua melhor gente a vigiar dashboards nunca aparece numa fatura, mas é real: é o roadmap que atrasa, a dívida técnica que nunca é paga, a funcionalidade que o cliente pede há meses e que ninguém tem tempo de construir porque metade da equipa técnica está dividida em escalas de prevenção.
Externalizar a vigilância não é tirar trabalho à sua equipa. É devolver-lhe o tempo que a operação 24x7 lhe estava a tirar do produto. A sua equipa volta a fazer aquilo que sabe fazer melhor, e o negócio deixa de pagar duas vezes pelo mesmo problema: uma em engenheiros de produto a trabalhar com pouco sono, e outra em oportunidade perdida por não avançar ao ritmo que deveria.
Um SLA com consequências, não uma promessa de boa vontade
Quando a monitorização é feita por uma equipa interna, o compromisso de resposta costuma ser informal: "vemos isso assim que pudermos", "tentamos estar sempre disponíveis". São boas intenções, não garantias. Quando externaliza com um fornecedor sério, o tempo de resposta é uma cláusula do contrato, com penalizações se não for cumprido. Essa diferença parece administrativa, mas muda completamente o incentivo: alguém com uma consequência financeira real se não responder no tempo acordado comporta-se de forma muito diferente de alguém que conta apenas com boa vontade.
Isto não é desconfiar da sua própria equipa. É reconhecer que um compromisso sem consequências, por bem-intencionado que seja, não é o mesmo que uma responsabilidade contratual.
Começar já, não daqui a um ano
Montar um NOC interno que funcione bem não é um projeto de uma semana: normalmente é um ano ou mais de maturação, com incidentes reais a servir de prova de fogo enquanto a equipa aprende à custa própria quais os alertas que importam de verdade e quais são ruído. Externalizar o serviço significa herdar uma stack de monitorização e uma equipa que já passaram por essa curva de aprendizagem com outros clientes. No primeiro dia já há cobertura real, não a promessa de que a haverá quando o projeto amadurecer.
Para a maioria das empresas, montar isto de raiz não é um investimento estratégico. É repetir um trabalho que já está resolvido, com pior relação custo-resultado do que pagar por algo que já funciona.
A sua infraestrutura só é vigiada em horário de escritório?
Fazemos uma auditoria sem compromisso à sua cobertura atual e mostramos-lhe exatamente onde tem falhas reais de vigilância.