Edição de 21/09: um alerta de orçamento não autoriza gastar

O destinatário do alerta não é necessariamente o decisor

Uma PME agenda um lote de descrições de produtos durante a noite. O orçamento tem um aviso por correio eletrónico, mas ninguém escreveu se o operador pode continuar o lote. A pergunta que escolhemos é quem autoriza novas tarefas depois de atingido um limite interno.

Propomos separar três estados: aviso que pede investigação, suspensão que impede admitir novos trabalhos e retoma que exige uma decisão registada. Este é um desenho original a implementar e testar pela equipa. Não afirmamos que um alerta de cloud, por si só, seja um corte automático ou uma garantia de despesa máxima.

Financiamento e previsão não são a mesma coisa

A FinOps Foundation enquadra Budgeting como financiamento aprovado e responsabilidade orçamental. Forecasting fornece modelos de despesa futura para apoiar esse financiamento. OWASP LLM06 recomenda autorização a jusante do modelo. Estas três funções sustentam a distinção que fazemos entre sinal, decisão e execução.

Um limite no ponto de admissão

O nosso desenho coloca a verificação antes de admitir um novo trabalho, não depois de terminar o lote. O dono do orçamento aprova um âmbito, uma janela e uma margem reservada para o que já estiver em curso. O operador não aumenta estes valores apenas por ter recebido o alerta.

Escolha com engenharia a unidade de controlo que o sistema consegue observar: trabalhos admitidos, consumo acompanhado ou estimativa reservada por tarefa. Registe a diferença entre reserva e custo observado. Se a informação chegar tarde ou faltar, propomos suspender novas admissões até reconciliar. Isso não promete cancelar cobranças já incorridas nem interromper automaticamente cada tarefa em execução.

A falha que deve ser ensaiada

Cenário hipotético: chega o alerta, o responsável financeiro está ausente e a fila continua a crescer. A experiência de mesa deve pedir ao operador que explique o comportamento sem improvisar uma autorização. A resposta prevista é manter a suspensão de novas tarefas e preservar a fila, com um substituto previamente designado para decidir.

Outro caso introduz dados de consumo atrasados. Verifique o que acontece às reservas, tarefas em curso e tentativas de reenvio. Não aceite como prova apenas a captura da mensagem de alerta: queremos o registo da admissão recusada e a identificação dos trabalhos que ainda podem gerar custo.

A retoma é uma nova autorização pequena

A matriz é uma proposta não testada. Cada retoma deve nomear lote, motivo, margem, janela e decisor. Ao expirar a janela, o mecanismo volta a suspender novas admissões, mesmo que a fila não esteja vazia. Um operador pode executar a retoma aprovada; não deve ser obrigado a inventar a disponibilidade financeira.

Como encerrar o episódio

Depois do lote, compare reservas, consumo observado e fatura quando disponível. Registe diferenças sem as transformar em falha automática de pessoas: pode faltar instrumentação, existir uma hipótese errada ou haver um trabalho duplicado. O dono do produto decide quais descrições continuam necessárias; finanças decide o financiamento.

Para uma PME portuguesa, a regra deve caber num turno normal e sobreviver à ausência do aprovador. Guardar a decisão e o teste de suspensão é mais útil do que acrescentar destinatários ao alerta sem lhes dar autoridade. Não apresentamos este desenho como controlo já eficaz: a equipa terá de verificar o ponto de corte e declarar o custo que permanece fora dele.