Arquitetura que não depende de ninguém
Uma arquitetura não falha no dia em que cai, mas no dia em que sai quem a compreendia. O que faz um sistema sobreviver ao seu autor e como se desenha para que isso aconteça.
LerPublicações
Artigos
Notas de trabalho sobre arquitetura cloud, custo e governo multicloud. O que aprendemos a operar, escrito para ser útil.
Arquitetura Cloud
12 artigos
Ver linha
Arquitetura cloud que não depende de ninguém
Doze artigos sobre como se desenha uma arquitetura cloud que sobrevive a quem a fez: decisões e requisitos escritos, desenho por zonas, dados primeiro, documentação que não envelhece, homologação face a uma norma, o custo como requisito e a recuperação testada antes de ser precisa.
Fundamentos
Decidir por escrito
Um registo de decisão de arquitetura ocupa uma página e poupa semanas. O que deve conter, quando escrevê-lo e como evitar que se transforme em burocracia.
LerOs requisitos que ninguém diz
Ninguém pede por escrito que o sistema recupere numa hora ou que não perca mais de cinco minutos de dados, mas todos o esperam. Os atributos de qualidade que decidem uma arquitetura e como torná-los explícitos.
LerDesenhar
Desenhar por zonas
Antes de escolher serviços é preciso traçar fronteiras. Zonas de rede, de confiança e de ambiente: o método para que uma arquitetura se perceba num relance e se possa proteger por partes.
LerMonólito, microsserviços ou algo pelo meio
Os microsserviços não são uma melhoria do monólito: são outro conjunto de compromissos. Que critérios inclinam a decisão e que componentes exige cada opção.
LerOs dados primeiro
A computação move-se facilmente; os dados não. Onde vive cada dado, quanto custa movê-lo, quanto demora e que lei o obriga a ficar decide a arquitetura mais do que qualquer serviço.
LerMulticloud e híbrido, com critério
Usar várias clouds ou combinar cloud com infraestrutura própria pode ser a decisão certa ou uma fonte de complexidade sem retorno. Quando convém, quando não convém e que padrão escolher.
LerDocumentar e validar
Documentação que não envelhece
A documentação de arquitetura morre no dia em que se separa do sistema. Tratá-la como código, com uma fonte única e saídas geradas, é o que a mantém viva.
LerAntes de corrigir, saber o que há
Todo o sistema herdado tem uma parte documentada e outra que só existe em produção. Como se faz um levantamento que descobre o que realmente corre antes de mudar alguma coisa.
LerHomologar sem travar
Rever arquiteturas face ao padrão da organização não tem de ser um estrangulamento. Com uma norma escrita e um parecer classificado por gravidade, a revisão ajuda em vez de travar.
LerOperar
O custo é um requisito de desenho
Uma arquitetura que cumpre tudo mas custa o dobro do previsto não está bem desenhada. Estimar o custo por componente antes de implementar, e porque é que corrigi-lo tarde sai tão caro.
LerDesenhar para falhar
Tudo falha mais cedo ou mais tarde. Uma arquitetura madura decide de antemão quanto tempo pode estar em baixo e quantos dados pode perder, desenha-se para o cumprir e testa-o antes de precisar.
LerEngenharia FinOps
12 artigos
Ver linha
FinOps, do conceito à operação
Doze artigos para passar de uma fatura que ninguém entende a um custo cloud que se explica, se atribui e se decide. Começa pelo que é um dado de custo, continua com a forma de construir o pipeline que o normaliza e corrige, e termina em como se orçamenta, se otimiza e se opera, também para a inteligência artificial.
Fundamentos
O custo cloud não é uma fatura
A fatura cloud diz quanto gastou, não porquê. Que perguntas não responde e como começar a transformar o custo em informação para decidir.
LerFinOps não é cortar custos
FinOps não é um programa de poupança. É uma forma de trabalhar que transforma o custo cloud numa decisão de negócio, com um ciclo que se repete.
LerAnatomia de um dado de custo
Uma linha da fatura cloud parece um número. Na realidade, combina utilização, tarifa, descontos e compromissos. Perceber essas peças é o primeiro passo para não tirar conclusões erradas.
LerConstrução
FOCUS explicado
O FOCUS é a norma aberta que dá à faturação de todos os fornecedores as mesmas colunas e o mesmo significado. O que resolve, o que não resolve e porque convém adotá-lo desde o início.
LerArquitetura de um pipeline de custos
Do ficheiro em bruto do fornecedor ao dado que serve para decidir há seis camadas, e cada uma existe por uma razão. É assim que se desenha um pipeline de custos que se pode auditar e que não depende de ninguém.
LerCorrigir antes de confiar
O dado de faturação não chega pronto a usar. Duplicados, compromissos mal repartidos e encargos mal classificados distorcem qualquer análise. Como detetá-los e corrigi-los com regras.
LerAtribuir o que não tem responsável
Sem atribuição não há responsáveis, e sem responsáveis o custo não desce. Etiquetas, contas e regras para atribuir cada custo a uma equipa, uma aplicação e um produto, incluindo o que é partilhado.
LerDecisão
A métrica de unidade
O custo total sobe quando o negócio cresce, e isso não diz nada. O custo por unidade de negócio diz: indica se cada cliente, transação ou produto custa mais ou menos do que antes.
LerOrçamento e previsão
Na cloud, o gasto decide-se cada vez que alguém implementa algo. Orçamentar é estimar antes de implementar, prever com a tendência real e saber do desvio antes de chegar a fatura.
LerOtimizar: tarifa contra utilização
Para baixar o custo cloud há duas alavancas, quanto se consome e a que preço. A ordem em que se mexem importa, e errar a ordem prende a organização a compromissos de que não precisava.
LerOperação
FinOps sem equipa de FinOps
Uma PME não precisa de uma área de FinOps para o praticar. Precisa de responsáveis claros, de uma revisão mensal curta e de decisões registadas. Um modelo operacional mínimo que funciona.
LerFinOps para IA
O gasto em inteligência artificial chega por caminhos diferentes da cloud tradicional e cresce sem que ninguém o veja por inteiro. Como levá-lo ao mesmo formato, atribuí-lo e medi-lo por funcionalidade.
LerCibersegurança
13 artigos
Ver linha
A segurança demonstra-se
Conformidade verificada, da infraestrutura ao código: conhecer o que vê um atacante, converter os referenciais em controlos próprios com evidência que se recolhe sozinha, proteger por camadas (privilégios, software, dados e acesso híbrido), registar o que importa, detetar com poucos alertas bons, responder com um guião ensaiado e conseguir que o seguro seja também o mais fácil.
Demonstrar, não declarar
A segurança demonstra-se
«Somos seguros» não é uma resposta. A única resposta útil a «como o sabes?» é uma evidência: que controlo existe, quem o revê, quando foi verificado pela última vez e que resultado deu.
LerO que vê um atacante
Não se pode proteger o que não se sabe que existe. A superfície de ataque é tudo o que alguém de fora pode alcançar: endereços, portas, domínios, serviços esquecidos. Inventariá-la é o primeiro controlo.
LerDos referenciais aos controlos
Um controlo, vários referenciais
ISO 27001, NIST CSF, CIS, exigências de clientes e da regulação: cada referencial pede o seu, e quase todos pedem o mesmo com outras palavras. Um catálogo próprio de controlos, cada um mapeado para todos os referenciais, evita fazer o mesmo trabalho cinco vezes.
LerControlos com evidência
Um controlo sem evidência é uma intenção. Cada controlo precisa de um responsável, uma forma de o verificar, uma frequência e um registo do resultado. Com isso, uma auditoria deixa de ser uma busca desesperada de provas.
LerEvidência que se recolhe sozinha
A conformidade anual retrata um dia; a contínua retrata todos. Quando a maioria dos controlos se verifica sozinha e guarda o seu resultado, o estado de segurança deixa de ser uma surpresa em cada auditoria.
LerProteger por camadas
Privilégio mínimo, a sério
Todos dizem aplicar o privilégio mínimo. Quase ninguém mede a distância entre as permissões que cada identidade tem e as que de verdade usa. Essa distância é, na prática, a superfície de ataque interna.
LerO código também é superfície
A maior parte do código que se implementa não foi escrita pela organização: são dependências, imagens base e ferramentas de terceiros. Saber o que contém cada artefacto, verificá-lo em cada construção e assinar o que se publica fecha uma porta que quase ninguém vigia.
LerCifrar não basta
Quase tudo está cifrado hoje por omissão, e ainda assim os dados fogem. A proteção real depende de quem controla as chaves, de saber que dados são sensíveis e onde estão, e de que o acesso decifrado esteja tão vigiado como o cifrado.
LerAcesso híbrido sem rede aberta
Entre a infraestrutura própria e várias clouds, o acesso tradicional abre uma rede inteira para dar acesso a um só sistema. O acesso por aplicação, verificando identidade e dispositivo em cada ligação, dá a cada pessoa apenas o que precisa.
LerDetetar e responder
Registar o que importa
Registar tudo é caro e não garante nada; não registar o importante é cegueira. Que eventos guardar, onde, quanto tempo e protegidos contra quem é uma decisão de desenho, não uma configuração por omissão.
LerPoucos alertas, bons
Mil alertas por dia não protegem ninguém: ignoram-se. A deteção útil são poucas regras, cada uma ligada a um risco concreto, com um responsável e uma ação prevista, que se afinam até que quase todos os alertas signifiquem algo.
LerResponder com um guião
Um incidente de segurança não é o momento de decidir quem faz o quê. A resposta funciona quando existe um guião escrito, com papéis, passos e decisões previstas, e quando foi ensaiado antes de ser preciso.
LerSegurança que não trava
Quando a segurança é vivida como um obstáculo, as equipas contornam-na. Quando o seguro é também o mais fácil, porque vem incluído no modelo, na plataforma e nas regras, cumpre-se sem o pedir.
LerGoverno Multicloud
11 artigos
Ver linha
Organização primeiro, automação depois
Como se governam várias clouds sem travar as equipas: responsáveis com nome e decisões no nível que lhes corresponde, uma norma que se pode cumprir e evolui, exceções com data de validade, estrutura de contas, uma só identidade, políticas que se herdam e um governo que se mede e se versiona.
Organização primeiro
Organização primeiro, automação depois
Automatizar uma organização desordenada não a ordena: multiplica a sua desordem à velocidade das máquinas. Antes das ferramentas de governo são precisas três coisas muito mais simples.
LerDomínios, papéis e responsáveis
Uma área de TI não se organiza por pessoas nem por ferramentas, mas por domínios de responsabilidade. Cada domínio tem papéis, e cada papel tem entregáveis com um responsável. Escrito e versionado, esse mapa acaba com o trabalho duplicado e com o que ninguém faz.
LerO que se decide em cada nível
Se tudo se decide em cima, nada avança. Se tudo se decide em baixo, cada equipa faz o que lhe apetece. Separar o estratégico, o tático e o operacional, com o seu ritmo e a sua forma de escalar, é o que permite decidir depressa sem perder o rumo.
LerA norma
Uma norma que se possa cumprir
As normas de TI costumam falhar por excesso: demasiado longas, demasiado vagas, impossíveis de verificar. Uma norma útil é curta, neutra, diz o que é obrigatório e o que não é, e cada regra pode verificar-se.
LerA vida de uma norma
Uma norma que não muda acaba ignorada; uma que muda sem aviso acaba incumprida. Tratá-la como um produto com versões, propostas, revisão, período de transição e retirada é o que a mantém viva e respeitada.
LerExceções com data de validade
Toda a norma tem exceções legítimas. O problema não é que existam, mas que se esqueçam. Uma exceção saudável tem responsável, motivo, risco aceite e data de validade, e vive num registo que alguém revê.
LerVárias clouds, um governo
A estrutura de contas é a primeira política
Antes de qualquer regra automática, a forma como se organizam contas, subscrições e projetos já decide quem pode fazer o quê, o que se isola do quê e como se reparte o custo. É a decisão de governo mais difícil de mudar depois.
LerUma identidade para todas as clouds
Com três clouds e dezenas de contas, gerir utilizadores em cada uma é inviável e perigoso. Uma só origem de identidade, papéis definidos uma vez e acessos temporários para o delicado resolvem a maior parte do problema.
LerPolíticas que se herdam
Uma regra aplicada no topo da hierarquia de contas chega sozinha a todas as de baixo, incluindo as que se criarem amanhã. Combinar regras que impedem com regras que detetam permite governar dezenas de contas sem as revisar uma por uma.
LerMedir e evoluir
Medir o governo
Um governo que não se mede julga-se por anedotas: o bloqueio da semana passada, o incidente do mês anterior. Quatro indicadores simples dizem se a norma se cumpre, se as exceções estão sob controlo e se o governo ajuda ou estorva.
LerO governo também se versiona
O governo não é um projeto que se termina, mas um sistema que evolui com a organização. Versioná-lo, anunciar as suas mudanças e medir como são adotadas é o que evita tanto a estagnação como o caos.
LerAutomação e IaC
14 artigos
Ver linha
Infraestrutura que se pode reconstruir
Do clique manual numa consola a uma infraestrutura que se pode reconstruir a partir do seu código: declarar em vez de ordenar, cuidar do estado, reutilizar com módulos, ler o plano e o seu custo antes de aplicar, manter cada servidor como deve ser, mudar sem medo e automatizar a operação com critério, incluindo saber o que não automatizar.
Do clique ao código
Infraestrutura que se pode reconstruir
Se amanhã desaparecer todo o ambiente, quanto tempo leva a tê-lo igual ao de hoje? A resposta mede melhor do que qualquer outra a maturidade de uma infraestrutura.
LerO problema dos cliques
As consolas web dos fornecedores cloud são cómodas e perigosas ao mesmo tempo. Cada clique muda a infraestrutura sem deixar um rasto útil, e com o tempo cada ambiente transforma-se numa peça única que ninguém sabe reproduzir.
LerDeclarar, não ordenar
Um script diz que passos dar; uma declaração diz como deve ficar. A diferença parece pequena e muda tudo: o que acontece se se executar duas vezes, se algo já existia ou se falhar a meio do caminho.
LerO código da infraestrutura
O estado, a memória da infraestrutura
Entre o código e a infraestrutura real há uma terceira peça que quase ninguém vê até falhar: o estado. Onde se guarda, quem o pode escrever e como se protege decide se a infraestrutura como código é segura ou um risco.
LerMódulos, peças que se reutilizam sem copiar
Copiar o código de um ambiente para criar outro funciona uma vez. À terceira cópia, cada uma é diferente e corrigir um erro obriga a procurá-lo em todas. Os módulos resolvem isso com uma só definição e parâmetros por ambiente.
LerVer o plano antes de aplicar
Antes de mexer na infraestrutura, a ferramenta pode dizer exatamente o que vai criar, modificar e destruir. Ler esse plano, e exigir aprovação quando inclui algo destrutivo, evita a maioria dos desastres.
LerO custo, dentro do plano
Se o plano de uma mudança diz que recursos se criam, também pode dizer quanto custarão por mês. Mostrar essa cifra na revisão muda conversas que antes se tinham quando já chegava a fatura.
LerCada servidor como deve ser
Linhas de base, o servidor que deve ser
Criar um servidor com código é metade do trabalho. A outra metade é que, meses depois, continue configurado como foi definido: pacotes, utilizadores, acessos, patches. Isso escreve-se como uma linha de base e verifica-se com regularidade.
LerDetetar o desvio
O desvio é a distância entre o que diz o código e o que existe de verdade. Aparece sempre; o que distingue uma infraestrutura saudável é que o deteta cedo e decide o que fazer com cada diferença.
LerMudar sem medo
Reversão a sério
Todo o plano de mudança diz como avançar; poucos dizem como retroceder. Em infraestrutura, voltar atrás não é sempre desfazer: às vezes é manter o anterior vivo até estar seguro do novo.
LerRegras como código
«Nenhum armazenamento público», «tudo cifrado», «nada sem etiquetas de custo». Se estas regras só estão num documento, não se cumprem. Se estão em código, verificam-se em cada mudança, antes de a aplicar.
LerO herdado também entra
Quase ninguém começa do zero. Há anos de infraestrutura criada à mão que também tem de entrar no código. Não se faz de uma vez nem se reconstrói tudo: incorpora-se por partes, começando pelo que tem mais risco.
LerAutomatizar a operação
Procedimentos que se executam sozinhos
Um procedimento escrito num documento depende de alguém o encontrar, o ler bem e não saltar um passo às três da manhã. O mesmo procedimento como código executa-se igual todas as vezes, e chama uma pessoa apenas quando é preciso critério.
LerO que não convém automatizar
Automatizar não compensa sempre. Há tarefas tão raras, tão variáveis ou tão arriscadas que o script custa mais do que poupa, ou faz mais dano do que evita. Saber distingui-las faz parte do ofício.
LerEngenharia de Plataforma
15 artigos
Ver linha
Software que se pode auditar
A vida de uma aplicação dentro de uma plataforma governada: porque é que uma plataforma é um produto, como nasce uma aplicação, de onde tira a sua verdade, como se constrói e se implementa sem surpresas, como se aprende com cada falha e como trabalha a IA quando as regras são escritas pelas pessoas.
Porquê
Software que se pode auditar seis meses depois
Seis meses depois de implementar, alguém pergunta que versão está a correr, quem a aprovou e porque foi feita assim. Se a resposta depende da memória de alguém, a plataforma não está governada.
LerUma plataforma é um produto interno
Uma plataforma interna falha quando se impõe e vence quando se escolhe. Tratá-la como um produto, com utilizadores, um caminho recomendado e algo a ganhar ao usá-lo, é o que a distingue de uma lista de proibições.
LerAntes do código
Fases e portas de aprovação
Uma aplicação passa por fases reconhecíveis, da ideia à produção. Entre fase e fase há uma porta de aprovação com nome, critério e responsável. Assim sabe-se sempre em que ponto está cada coisa e quem disse que podia avançar.
LerA especificação manda
Escrever o que se vai construir antes de o construir parece lento. É o mais rápido que existe, porque cada ambiguidade resolvida num parágrafo é uma semana de refazer código que não se perde.
LerComeçar sempre igual
Quando cada aplicação nasce com a mesma estrutura, qualquer pessoa da equipa sabe onde está cada coisa em qualquer repositório. O modelo de aplicação é a peça mais modesta de uma plataforma e uma das que mais tempo poupa.
LerUma só verdade
Um só registo para tudo
Que aplicações existem, em que porta escutam, com que endereço se publicam e quem é o seu responsável. Se essa informação vive em cinco lugares, tarde ou cedo dois dirão coisas diferentes.
LerSegredos com nome, nunca com valor
Uma palavra-passe num repositório é uma palavra-passe publicada, mesmo que o repositório seja privado. O repositório deve saber que segredos cada aplicação precisa; só um gestor de segredos deve saber o seu valor.
LerEstado e diário de bordo, a memória do projeto
Dois documentos simples sustentam a continuidade de um projeto. O estado diz onde está hoje; o diário de bordo conta como chegou até aí. Um sobrescreve-se, o outro nunca se edita.
LerConstruir e implementar
Construir uma vez, implementar por digest
Se em produção se implementa algo diferente do que foi testado em aceitação, a aceitação não serviu de nada. Construir uma só vez e mover sempre o mesmo artefacto, identificado pela sua impressão digital, fecha essa porta.
LerAmbientes que se parecem a sério
A aceitação só serve se se parecer com a produção. O que pode mudar entre ambientes, o que nunca deve mudar e como manter essa diferença escrita e pequena.
LerQue falhe a construção, não a produção
Tudo o que se pode verificar sem critério humano deve ser verificado antes de publicar, e se falhar, deve parar tudo. Melhor uma implementação quebrada com uma mensagem clara do que um erro nas mãos de um utilizador.
LerOperar e aprender
O que corre, onde e porquê
A partir de qualquer serviço em produção devia poder percorrer-se o caminho para trás até ao requisito que o justifica. Essa cadeia de rastreabilidade é o que transforma uma auditoria de semanas numa consulta de minutos.
LerCada falha deixa uma regra
Um incidente resolvido que não muda nada voltará a acontecer. A forma de aprender das falhas é transformar cada uma em algo permanente: um teste, uma validação, uma regra ou uma decisão escrita.
LerIA na plataforma
Agentes que executam, pessoas que decidem
Os assistentes de IA já escrevem código, implementam e documentam. Dentro de uma plataforma governada podem fazer muito trabalho de forma autónoma, desde que as portas de aprovação que exigem critério continuem a ser das pessoas.
LerAs regras escrevem-nas as pessoas
A IA não devia decidir como trabalha uma organização. Devia aplicar e verificar as regras que a organização escreve. Quando as duas interpretações não coincidem, essa diferença é justamente o que há que olhar.
Ler