Faro para o que vale automatizar.
Um método que transforma a decisão de "o que automatizar" numa conta rastreável — cada número com origem, fonte e responsável. Fundamentado em frameworks consagrados do mercado, combinados num trilho único.
O FARO responde uma pergunta difícil — "de tudo que dá para automatizar, o que fazer primeiro?" — trocando opinião por uma nota justificada para cada caso, e usando essas notas para montar um plano de entrega em etapas. Quem é técnico e quem é de negócio enxergam, juntos, por que cada automação está na fila e quando será feita.
Não conhece um termo? Há um glossário em linguagem simples ao final. E, em cada quadro com ⓘ, passe o mouse para ver a explicação.
Toda lista de "o que automatizar" vira disputa de opinião: cada área acha o seu caso o mais importante e o arquiteto arbitra sem base. O FARO existe para acabar com o achismo — transforma a priorização numa conta em que cada nota tem fator, fonte e responsável.
Cada nota vira número numa régua única, igual para todos os domínios: um "3" em rede custa o mesmo "3" em storage (calibração cruzada). A decisão deixa de ser a opinião de um consultor e passa a ser a soma de práticas reconhecidas aplicadas com disciplina.
Nenhum framework de mercado, isolado, resolve a classificação e priorização de automações ponta a ponta com uma régua cross-domínio. O FARO é a composição original dessas práticas — cada uma usada exatamente na parte onde tem autoridade (ver seção 06). O diferencial não é uma fórmula secreta: é a orquestração disciplinada de padrões reconhecidos numa régua reprodutível.
Mnemônico I·A·O. Cada passo tem objetivo, fundamento, RACI (quem responde), gate (critério para avançar) e onde vive na plataforma.
Descobrir e catalogar os casos de uso candidatos.
Classificar de forma defensável, por números de fonte confiável.
Priorizar, validar com o cliente e entregar o que vale.
Duas leituras: como ler uma classificação pronta e como usar o método para produzir uma.
O Volume/Frequência não é perguntado ao cliente — é derivado do as-is (a descrição de como o processo é feito hoje). Assim o mesmo fato é capturado uma única vez e a nota sai sem achismo.
| Execuções-alvo/ano (X) | Nota | Leitura |
|---|---|---|
| menos de 50 | 1 | esporádico |
| 50 a 499 | 2 | ocasional |
| 500 a 1.999 | 3 | semanal / dezenas |
| 2.000 a 9.999 | 4 | frequente |
| 10.000 ou mais | 5 | diário / muitos alvos |
Exemplo: 200 hosts, 1×/semana → 1 × 52 = 52/ano → X = 200 × 52 = 10.400 → faixa "10.000 ou mais" → Volume = 5.
Na tela Classificar, o card do Volume traz um "🧮 como é calculado" com estes números já aplicados ao caso de uso aberto — se um valor não fecha, ajuste os campos de hosts e frequência no as-is (botão “i” do caso de uso).
Um roteiro que qualquer pessoa da equipe consegue seguir. Cada passo diz o que fazer, quem faz (pela competência) e onde vive na plataforma.
| # | O que fazer | Quem faz | Onde na plataforma |
|---|---|---|---|
| 1 | Descrever o caso — o que se quer automatizar em 1 frase + contexto técnico (equipamentos, software, versões) | quem conhece a demanda | Casos de uso → Criar |
| 2 | Descobrir a documentação/collection oficial da tarefa | especialista | Doc-lookup |
| 3 | Responder os fatos técnicos (fatores objetivos) → o sistema calcula Complexidade e Risco | especialista + arquiteto | Classificar |
| 4 | Responder as notas de negócio — Valor e Criticidade (o Volume é derivado de hosts×frequência do as-is) | cliente / dono do negócio | Classificar |
| 5 | Conferir os índices que se calculam sozinhos — ICO, Quadrante, Bolha | automático | Classificar / Priorização |
| 6 | Vincular o caso a um projeto (sai do backlog) | lead / arquiteto | Casos de uso → Vincular |
| 7 | Organizar em ondas — começando pelos quick wins (read-only) | lead / arquiteto | Projetos → Ondas |
| 8 | Entregar onda a onda, com aprovação (gate) entre elas | equipe + cliente | Projeto / Priorização |
Como classificar um caso de uso por números, obtidos de fontes confiáveis, de forma clara e auditável — sem nada "digitado à mão" no final. A resposta é uma cadeia rastreável por fator (passe o mouse no ⓘ de cada quadro):
--check confiável ≥ 4.Os índices se calculam sozinhos a partir das notas (Passo 5 — gate: nada à mão):
o quão perigoso é rodar o caso.
quick win · estratégico · eficiência · reavaliar.
o retorno relativo do caso.
"Faro" não é só sigla. Um faro rastreia, segue a pista e separa o que vale do que não vale — exatamente os três momentos:
| Inventariar = farejar / rastrear | descobrir candidatos e catalogar a pista (Passos 1–2) |
| Avaliar = seguir a pista com critério | medir cada caso por números de fonte confiável, não por instinto (Passos 3–5) |
| Orquestrar = decidir o que vale | priorizar, validar com o dono do negócio e entregar o que compensa (Passos 6–9) |
O esforço e o risco de automatizar não derivam de o que a tarefa faz (rede, storage, virtualização), mas de como o Ansible a executa. Essas propriedades são as mesmas em qualquer domínio — por isso a mesma régua vale para todos.
Um módulo idempotente "sai sem executar ações" quando o estado desejado já existe. Com módulo idempotente = baixa complexidade em qualquer domínio; sem garantia = alta. docs.ansible.com · playbooks_intro
--check / dry-run)Roda sem alterar e reporta o que mudaria — mas módulos sem suporte "não reportam e não fazem nada", tornando o dry-run enganoso. Testabilidade é propriedade técnica. docs.ansible.com · check mode
Padronizam a gerência por estado (merged/replaced/overridden/…) e retornam before/after/commands, permitindo asseverar not changed. O padrão de complexidade acompanha o módulo, não o domínio. docs.ansible.com · resource modules
command/shell) = sinal de maior complexidade/riscoSó tem check mode parcial e a doc recomenda o módulo específico. Recorrer a comando cru é abrir mão de idempotência nativa e dry-run confiável — em qualquer domínio. docs.ansible.com · command
Cada fator mede complexidade/risco por uma propriedade técnica verificável — não por opinião. Régua faro-1.0, 8 fatores (q1..q8).
| # | Fator | Por que mede (âncora técnica) |
|---|---|---|
| 1 | Nº de sistemas/plataformas | cada alvo a mais multiplica pontos de falha e estado a convergir |
| 2 | Módulo pronto (certified) vs. comando cru | módulo sai sem ação se já no estado; comando cru não garante isso |
| 3 | Ordem / estado | dependência de ordem/estado é risco documentado (ex.: overridden pode remover seu acesso) |
| 4 | Reversibilidade da operação | operação irreversível eleva o Risco por si só (a própria escala de q4 vai a 5) |
| 5 | Nº de exceções por modelo/versão | cada exceção quebra a experiência consistente do resource module |
| 6 | Interface API / CLI / UI | API tende a módulo idempotente; CLI empurra para comando cru; UI é frágil |
| 7 | Dry-run (--check) confiável | check mode enganoso (módulo sem suporte não reporta) → Risco +1 |
| 8 | Lógica / decisão condicional | check mode não prevê conditionals sobre variáveis registradas |
Reversibilidade (4) e --check (7) são fatores separados. A idempotência comprovável (not changed na 2ª execução) é a âncora de verificação do método — não um fator pontuado. Credenciais / pré-requisitos são campo do as-is, não fator. Fontes: documentação oficial Ansible; motor faro-1.0.
Cada peça entra no passo onde tem autoridade. Não usamos o framework inteiro — usamos a parte específica que resolve aquele ponto. verificado = confirmado por acesso; n/c = domínio oficial, mas bloqueado a robô (403).
| Framework | Qual parte usamos | Como usamos no FARO | Fonte |
|---|---|---|---|
| PMI / PMBOK | a Matriz de Responsabilidades (RAM/RACI) | define, por nota, o único responsável — Passo 3 | pmi.org 403 |
| TOGAF ADM | a descoberta estruturada por domínios de arquitetura | organiza o levantamento de casos por domínio — Passo 2 | opengroup.org ok |
| ITIL 4 | a prática de Change Enablement | rege mudança em produção e governança — Passos 1 e 9 | axelos.com n/c |
| Scrum / SAFe | a cadência em intervalos (Planning Interval) | entrega em ondas priorizadas — Passo 6 (não a cerimônia completa) | scaledagile.com ok |
| Wideband Delphi | a calibração de estimativa por consenso | alinha as notas 1–5 entre especialistas, reduzindo viés — Passo 4 | ref. ok |
| IFPUG / COSMIC | o conceito de medir tamanho indep. de tecnologia (proxy) | inspira a régua de complexidade cross-domínio — Passo 4 (não contagem certificada) | cosmic-sizing.org ok |
| DORA | as 4 métricas de entrega | medem o desempenho da entrega das automações — Passo 9 | dora.dev ok |
| ADR | o registro de decisão (contexto + trade-offs) | toda decisão relevante vira um ADR — Passo 9 | adr.github.io ok |
| Modelo C4 | os níveis de diagrama (contexto/contêiner) | desenham a arquitetura das soluções — Passo 9 | c4model.com ok |
O FARO ancora peças oficiais Red Hat — cada uma rotulada: (a) produto (normativo) ou (b) serviços/marketing (orientativo). O Automation Savings Planner (valor/ROI) fica em roadmap — não ofertado nesta fase.
| Peça | Rótulo | Passo | Qual parte / papel |
|---|---|---|---|
| Maturidade — 5 estágios | (b) | 1 | posiciona a evolução (autoavaliação, não certificação) |
| Services Journey — fase Discuss | (b) | 2 | descoberta de casos + envolver especialistas (SMEs) |
| Automation Savings Planner roadmap | (a) | — | valor/ROI — não ofertado nesta fase. Os campos hosts×frequência do as-is alimentam o Volume derivado, não uma projeção financeira. |
| Automation Hub — certified/validated | (a) | 8 | ordem de preferência certified→validated→community |
Fontes: Maturity e-book · Services Journey brief · Savings Planner AAP 2.5 / AAP 2.4 · Managing content.
Para quem não é da área técnica — cada termo do método em uma frase do dia a dia.
| Caso de uso (UC) | uma automação candidata — algo que se quer automatizar (ex.: "fazer backup da configuração dos switches"). |
| Backlog | a lista de casos ainda sem projeto — a "fila de espera". |
| Complexidade (1–5) | o quanto é difícil/trabalhoso automatizar. 1 = trivial, 5 = muito complexo. |
| Risco (1–5) | o quanto pode dar errado ao executar. Só ler = baixo; apagar algo sem volta = alto. |
| Valor / Volume / Criticidade | o lado do negócio: quanto compensa e quão crítico é (Valor e Criticidade são do cliente). O Volume — com que frequência acontece — é derivado de hosts×frequência do as-is, não perguntado. |
| ICO | "quão perigoso é operar" — o maior entre Complexidade e Risco (Baixo/Médio/Alto). |
| Quadrante | a estratégia: alto valor + baixa complexidade = "quick win" (fazer já). |
| Bolha (Oportunidade) | o retorno pelo esforço — quanto maior a bolha, mais vale a pena. |
| RACI | quem responde o quê: o técnico responde os fatos técnicos; o cliente, as notas de negócio. |
| Onda | uma etapa de entrega do projeto, com data e objetivo; começa pelos casos mais seguros. |
| Idempotência | rodar a automação duas vezes dá o mesmo resultado, sem estragar nada — o "padrão-ouro". |
Check mode (--check) | o "ensaio" da automação: mostra o que mudaria, sem mudar de verdade. |
| Collection (certified / community) | peça pronta do Ansible. "Certified" = com suporte oficial; "community" = sem suporte (exige autorização). |
| Comando cru | quando não há peça pronta e é preciso "mandar o comando na mão" — mais arriscado. |
É a honestidade que torna o método defensável. Por isso estas ressalvas ficam à vista, não em rodapé: