FARO
Aprender · O Assessment

Como o FARO avalia a adoção de automação

Faro para o que vale automatizar.

O assessment responde, com método, quatro perguntas de negócio: onde a organização está, o que automatizar primeiro, o que o ambiente permite e qual plataforma dimensionar. Cada pilar se apoia em frameworks e padrões reconhecidos — esta página mostra como cada parte é feita e de onde vem.

Para todos

Em uma frase

Um assessment de adoção é um diagnóstico estruturado: em vez de "achar" que a empresa está pronta e chutar o tamanho da plataforma, ele mede a maturidade, prioriza o que vale, levanta a realidade técnica e só então dimensiona — cada passo com um fundamento que dá para explicar.

Para quem é de negócio

  1. Você entende onde está a organização. um nível de maturidade de 1 a 5, com o retrato de cada estágio.
  2. Você vê o que priorizar. casos ordenados por valor contra esforço (oportunidade relativa ao esforço).
  3. Nada é opinião solta. cada parte se apoia em um método público — dá para perguntar "de onde vem isso?".

Para quem é técnico

  1. Você registra a realidade do ambiente. discovery por domínio: versões, topologia, restrições de rede.
  2. O sizing é derivado, não chutado. forks, RAM, nós e banco saem de requisitos oficiais.
  3. Fonte rotulada. cada número traz a origem: (a) produto, (b) serviços, (c) framework público.

Há um glossário simples e ressalvas honestas ao final. A legenda de fontes: a · produto documentação normativa · b · serviços material orientativo · c · terceiro framework/benchmark público.

Visão geral

Os quatro pilares — e por que nesta ordem

Primeiro entende-se a maturidade (cultura e prática), depois o que tem valor (casos de uso), depois a realidade técnica (discovery) e só então quanto de plataforma (sizing). Cada pilar alimenta o próximo.

Diagnóstico
1 · Maturidade
Onde a organização está na jornada?
→
Priorização
2 · Casos de uso
O que automatizar primeiro e por quê?
→
Levantamento
3 · Discovery
O ambiente real suporta o quê?
→
Dimensionamento
4 · Sizing
Que plataforma sustenta isso?
Pilar 1

Estratégia & Maturidade

1

Onde a organização está na jornada

Mede o amadurecimento em automação — não só ferramentas, mas cultura, padronização, governança e alcance. Resultado: um nível de 1 a 5.

Como é feito

  1. Contexto (B0). Setor, tamanho das equipes, ferramentas atuais, objetivos. Não pontua — calibra a leitura das demais respostas.
  2. 23 perguntas de maturidade (B1). Cada uma sonda uma dimensão (padronização, colaboração, governança, medição de valor, autonomia). As respostas viram uma pontuação que mapeia a um dos 5 estágios.
  3. 10 perguntas complementares (B2a). Aprofundam aspectos estratégicos (patrocínio executivo, reuso, comunidades de prática) que qualificam o nível.
  4. Cálculo do nível (1–5). Agrega B1 (ponderado por B2a) e posiciona num estágio, com o retrato daquele estágio e as atividades-chave para avançar.

Os 5 estágios

#EstágioO que caracteriza
1Awareness
Consciência
Automação ad hoc e individual. Scripts pessoais, sem padrão nem compartilhamento; ganhos locais e não medidos.
2Standardized
Padronizado
Práticas e ferramentas comuns começam a ser adotadas. Conteúdo reutilizável, convenções de nomes, primeiras integrações.
3Proactive
Proativo
Automação planejada, não reativa. Governança básica, controle de acesso por função, medição inicial de resultados.
4Institutionalized
Institucionalizado
Automação é padrão da organização. Comunidades de prática, reuso amplo, governança madura, valor medido de forma consistente.
5Optimized
Otimizado
Melhoria contínua orientada a dados. Automação integrada à estratégia; analytics guiam decisões; escala organizacional.

Por que assim: automação madura não é "ter uma ferramenta" — é ter padrão, reuso, governança e valor medido disseminados. Um modelo de estágios evita tratar todos igual: quem começa precisa de padronização; quem é avançado precisa de otimização e escala. O nível também alinha expectativas (não se pede orquestração de processos a quem ainda não padronizou tarefas).

Analogia: é como o nível de proficiência num idioma (A1 a C2). Ninguém "reprova"; o teste diz onde você está para saber o que estudar em seguida — e não dá para pular etapas, você constrói sobre o nível anterior.
De onde vem: modelo de maturidade da adoção de automação em 5 estágios (autoavaliação orientativa; é um retrato para conversa, não um selo). As 23+10 perguntas operacionalizam as "key questions" de cada estágio. b · serviços redhat.com/…/automation-maturity-guide-ebook ↗
Pilar 2

Casos de uso — priorização

2

O que automatizar primeiro e por quê

Classifica cada caso por esforço/dificuldade (Complexidade e Risco, combinados no índice ICO) e por valor de negócio (Valor). Resultado: um quadrante Valor × Complexidade.

Como é feito

  1. Inventariar os casos candidatos (ex.: patching, provisionamento de VM, coleta de conformidade).
  2. Pontuar Complexidade: nº de sistemas/integrações, dependências, variabilidade, conhecimento especializado.
  3. Pontuar Risco: impacto de falha, criticidade do sistema, exposição de segurança, reversibilidade.
  4. Combinar em ICO — consolida complexidade + risco num único eixo de "dificuldade de entrega".
  5. Pontuar Valor: tempo manual poupado, frequência, nº de hosts, redução de erro/risco, ganho de conformidade.
  6. Plotar no quadrante Valor × Complexidade e ler as regiões: alto valor / baixa complexidade = quick wins; alto valor / alta complexidade = estratégicos; baixo valor / baixa = oportunistas; baixo valor / alta = evitar.

Por que assim: recursos são finitos. Priorizar valor contra esforço entrega resultado cedo (gera patrocínio) e evita começar por um caso difícil e de pouco valor. Separar o Risco importa: um caso "fácil" tecnicamente pode ser perigoso (mexer em produção crítica) — risco alto rebaixa a prioridade mesmo com baixa complexidade.

Analogia: a lista de tarefas do fim de semana com dois critérios — quanto ajuda e quão trabalhoso/arriscado é. Faz-se primeiro o que ajuda muito e custa pouco (trocar a lâmpada do corredor); planeja-se o que ajuda mas dá trabalho (reformar a cozinha); adia-se o que dá trabalho e quase não muda nada.
De onde vem: a estrutura Valor × Esforço é a matriz de priorização consagrada de gestão de portfólio/produto c · terceiro. O Valor é julgamento de negócio do cliente; a quantificação financeira (Automation Savings Planner / ROI) está em roadmap — não ofertada nesta fase a · produto. ICO é o nome interno do FARO para o eixo complexidade+risco; a estrutura é o padrão público.
Pilar 3

Discovery técnico

3

O que o ambiente real suporta

Coleta evidências técnicas por domínio (rede, virtualização, SO, storage, identidade…). Entrega o retrato factual da infraestrutura que a automação vai tocar.

Como é feito

  1. Definir os domínios a investigar.
  2. Coletar evidências: inventário de hosts, versões, topologia de rede (segmentação, firewalls, portas), plataformas de virtualização/nuvem, sistema operacional, latências e restrições.
  3. Registrar requisitos de conectividade: portas, NTP, SSH, acesso root/sudo, PostgreSQL externo, saída para console/analytics.
  4. Identificar segmentação de rede que exigirá desenho de mesh (redes isoladas → nós de salto).
  5. Consolidar como insumo direto para casos de uso viáveis e para o sizing.

Por que assim: sem o retrato técnico, sizing e arquitetura são chute. O discovery revela as restrições que definem a topologia — redes segmentadas obrigam nós de salto; o banco externo tem versão suportada; NTP/SSH/portas precisam estar prontos antes de instalar. É o pilar que conecta "o que queremos automatizar" com "o que o ambiente permite".

Analogia: a visita de medição antes da reforma. O arquiteto não compra material sem medir os cômodos e ver onde passam canos e fiação. Sem essa medição, você compra a plataforma errada para a casa que tem.
De onde vem: a lista do que evidenciar (SO suportado, PostgreSQL, portas, NTP, SSH, tipos de nó) vem do planejamento de instalação / requisitos de plataforma a · produto; a prática de descoberta guiada por domínios apoia-se no material de jornada de adoção / discovery b · serviços. services-journey-automation-adoption ↗
Pilar 4

Sizing da plataforma (AAP 2.7)

4

Que plataforma dimensionar

Dimensiona dinamicamente: forks, RAM, CPU, quantidade e tipo de nós (control/execution/hybrid/hop), PostgreSQL, IOPS e a topologia testada. Uma arquitetura suportada, não arbitrária.

Como é feito

  1. Estimar a carga: nº de hosts, jobs simultâneos, janelas → define o número de forks (execuções em paralelo).
  2. RAM: mínimo oficial de 16 GB por nó (32 GB para a growth com seed de collections). Acima do piso, dimensione pela carga de forks (heurística de capacidade ~100 MB/fork).
  3. CPU: mínimo oficial de 4 vCPU por nó; acima disso acompanha a densidade de forks.
  4. Escolher e contar os tipos de nó (Automation Mesh) — ver tabela abaixo.
  5. PostgreSQL: versão 15 (gerenciado pelo instalador ou externo com a versão suportada pela release), com recursos próprios.
  6. Validar IOPS de disco (banco e nós): alvo oficial 3000 IOPS, medido com o FIO.
  7. Encaixar numa topologia testada (Growth / Enterprise) em vez de desenhar do zero.

Tipos de nó (Automation Mesh)

NóPapel
ControlOrquestra e gerencia jobs — não executa playbooks.
ExecutionExecuta os playbooks.
HybridFaz ambos (padrão em topologias menores).
HopNó de salto para atravessar segmentação de rede — só roteia, não executa nem controla.

Variáveis que determinam o sizing

VariávelO que a determina
ForksCarga: nº de hosts × jobs simultâneos desejados.
RAMPiso oficial 16 GB/nó (32 GB na growth com seed); acima, pela carga de forks.
CPUPiso oficial 4 vCPU/nó; acima, densidade de forks.
DiscoOficial 60 GB/nó (80 GB com metrics service).
Nós (qtd/tipo)Topologia testada + segmentação de rede (hop nodes).
PostgreSQLVersão 15 (externo ou gerenciado).
IOPSAlvo oficial 3000, validado via FIO.

Por que assim: forks são o motor da execução paralela; se faltar RAM, os jobs falham ou ficam lentos — por isso RAM se atrela a forks, não a um valor fixo. Separar control de execution (enterprise) dá resiliência e escala independente. Hop nodes existem porque redes reais são segmentadas. IOPS via FIO importa porque um banco lento derruba tudo — "o disco parece rápido" não é evidência, a medição é. Usar uma topologia testada garante uma combinação suportada.

Analogia: dimensionar a cozinha de um restaurante pelos pratos por hora. Os forks são os fogões acesos ao mesmo tempo; cada um precisa de gás e bancada (RAM/CPU). Separa-se quem cozinha (execution) de quem coordena os pedidos (control); há um passa-pratos (hop) quando cozinha e salão estão em andares diferentes. O estoque (banco) precisa ser rápido (IOPS) para não travar a fila — e segue-se uma planta já testada em vez de improvisar.
De onde vem: os mínimos por nó — 16 GB RAM · 4 vCPU · 60 GB disco · 3000 IOPS · PostgreSQL 15 — foram confirmados nos guias 2.7 Plan e Install (System requirements) ingeridos na base a · produto. A quantidade de nós da topologia Enterprise segue a inventory oficial. Referências: System requirements 2.7 ↗ · Tested deployment models 2.7 ↗
Roadmap

Valor / ROI — em roadmap (não ofertado nesta fase)

A quantificação financeira do valor (Automation Savings Planner / ROI) está em amadurecimento e não é entregável ativo nesta fase. Nesta fase, o Valor é o julgamento de negócio do cliente e o Volume é derivado de hosts×frequência do as-is — sem projeção financeira.

O que existe hoje (sem projeção de R$)

  1. Os campos nº de hosts, duração da tarefa manual e frequência são capturados no as-is.
  2. O motor deriva o Volume (hosts×frequência) a partir desses fatos — não é nota respondida pelo cliente.
  3. A priorização usa a Bolha = (Valor × Volume × Criticidade) ÷ Complexidade — oportunidade relativa ao esforço.

Em roadmap: uma projeção de economia/ROI ao estilo Automation Savings Planner (custo manual − custo automatizado, projetado em 1–3 anos) poderá ser ativada em fase futura. Planejar (forecast) ≠ realizado (medido depois).

De onde vem: a referência é o Automation Savings Planner da Red Hat a · produto — mantido aqui apenas como roadmap. Estudos de impacto econômico de terceiros seriam só benchmark, nunca método c · terceiro.
Fechamento

Como explicar a alguém em 4 frases

#PilarFrase
1MaturidadeDiz onde a organização está e o que é realista pedir dela.
2Casos de usoDiz o que fazer primeiro (valor × esforço), com o valor quantificado.
3DiscoveryRevela as restrições reais do ambiente.
4SizingTransforma tudo numa plataforma dimensionada e suportada.
Termos em linguagem simples

Glossário

Fork — uma execução em paralelo. Mais forks = mais tarefas ao mesmo tempo (e mais RAM).
Maturidade — o quão disseminada e organizada é a automação (de scripts soltos a prática de toda a empresa).
ICO — Índice de Complexidade Operacional — junta Complexidade e Risco num só "grau de dificuldade de entrega".
Quadrante — mapa Valor × Complexidade: mostra os quick wins e os casos a evitar.
Discovery — o levantamento técnico do ambiente (versões, rede, restrições).
Sizing — o dimensionamento da plataforma (quanto de máquina/banco/rede é preciso).
Node (nó) — uma máquina da plataforma, com um papel: controlar, executar ou saltar rede.
IOPS — velocidade do disco em operações por segundo; medida com a ferramenta FIO.
Ressalvas honestas

O que esta avaliação é — e o que não é

  • O nível de maturidade é orientativo, não uma certificação. Serve para conversa e plano, não como selo.
  • Números de sizing mudam por versão. Todo valor marcado confirmar na 2.7 deve ser conferido na página oficial da versão instalada antes de virar compromisso.
  • ICO é nome interno para o eixo complexidade+risco; a estrutura Valor × Esforço é padrão público — não é apresentada como framework externo.
  • Cada fonte é rotulada por natureza: a · produto (normativo), b · serviços (orientativo), c · terceiro (benchmark). Não se mistura o que é requisito com o que é sugestão.