← Gestão de Projetos de TI: da necessidade à operação
03 / 8 · 55 MIN

Risco, mudança e decisões de arquitetura

Avalia impactos e atribui decisões aos responsáveis adequados.

Conceito e mecanismo

Um risco descreve uma condição incerta e o efeito possível nos objetivos. Um problema já ocorrido precisa de ação, responsável e prazo. Mantém ambos visíveis, com sinais de evolução e resposta proporcional. Quando surge uma mudança, analisa impacto em âmbito, esforço, prazo, operação, segurança e dependências antes de prometer implementação. Uma decisão de arquitetura deve preservar contexto, alternativas e consequências num registo adequado. Se o contexto mudar, liga a nova decisão à anterior, mantendo o histórico. O gestor de projeto coordena a decisão e a execução, mas não substitui automaticamente a autoridade de arquitetura, segurança, negócio ou operação.

Aplicação guiada

Num cenário fictício, o fornecedor propõe um serviço gerido para acelerar a migração. A equipa deve rever a distribuição de responsabilidades: em AWS, a fronteira muda com o serviço escolhido; dados e permissões continuam a exigir decisões do cliente. Evita assumir que cloud elimina manutenção, risco ou requisitos de acesso. Para resiliência, distingue RTO de RPO e exige evidência do percurso completo. Um ensaio pode cumprir tempo de recuperação e falhar a janela de perda de dados. Leva ao fórum adequado opções com consequências e risco residual, em vez de apresentar uma única solução como inevitável. Uma exceção precisa de dono, validade e critérios de resolução.

Medir recuperação até ao resultado útil

A aplicação pode arrancar antes de o fluxo de negócio estar pronto. Se aplicação e base de dados recuperam em paralelo em doze e vinte minutos, e depois há cinco minutos de reconciliação, o resultado útil surge aos vinte e cinco. Com objetivo de vinte e dois, há um desvio de três minutos. Define a fronteira da medição com negócio e operação e inclui dependências necessárias. Um resultado técnico verde por componente pode coexistir com um fluxo que falha o objetivo. Não substituas essa evidência por uma garantia publicada de um fornecedor.

Separar tempo, ponto e efeitos externos

O ponto de recuperação depende dos dados efetivamente recuperados. Um backup das nove e meia, avançado por logs completos até às nove e cinquenta e cinco, deixa cinco minutos de perda potencial se a falha ocorreu às dez. Isto não determina o tempo necessário para repor o serviço. Analisa também efeitos externos: reverter o binário não desfaz ficheiros já enviados a um consumidor. Antes de repetir envios, reconcilia confirmações e define tratamento de duplicações ou omissões com os responsáveis. O plano deve representar o estado persistente e a compatibilidade necessária.

Prática: reportar resultados separados

Usa os valores abaixo para construir um relatório de resiliência com uma linha para tempo e outra para ponto de recuperação. Declara quais limites passaram e quais exigem tratamento, sem resumir tudo numa única cor. Em seguida, verifica uma exceção válida apenas para piloto até sexta às dezoito horas: o rollout de sábado não fica autorizado por ter a mesma configuração. Identifica âmbito, validade, condições e autoridade. O resumo deve ligar resultado observado e decisão necessária, preservando o histórico de aprovação e evitando ampliar silenciosamente uma autorização limitada.

Synthetic resilience exercise / Exercício fictício de resiliência
workflow_minutes = max(12, 20) + 5 = 25
RTO = 22; overrun = 3
failure = 10:00; last_recovered_point = 09:55
potential_loss = 5 minutes; RPO = 10 minutes
RTO_met = false; RPO_met = true
Local rollback does not prove remote files were not consumed.
NA PRÁTICA

RTO e RPO são critérios separados; aceitar um não demonstra cumprimento do outro.

Armadilhas comuns

Risco materializado sem ação; pedido informal como aprovação; cloud como transferência de toda a responsabilidade.

Tópicos relacionados: Mandato, âmbito e aceitação · Capacidade, dependências e previsão · Governance, fornecedores e comunicação

Leva esta ideia contigo

Regista alternativas, impactos e autoridade antes de comprometer a mudança.

Criar conta

Referência: Maintain an architecture decision record · PM² reference practices and cloud operational governance; primary guidance reviewed 2026-09-30