Perfis e scripts

Configurar um CPE de cada vez funciona enquanto são poucos. O que não escala é lembrar o que cada um deveria ter. São três peças que separam “configurado uma vez” de “configurado e continua assim”: o perfil, o script e a conciliação.

Perfil de provisionamento

O perfil é a declaração do que um CPE deve ter. O provedor define uma vez e aplica a muitos.

A palavra que carrega o sentido é declaração. Um perfil não é um roteiro executado uma vez e esquecido; é uma afirmação de estado desejado, que continua valendo depois de aplicada. É essa permanência que torna possível a pergunta da conciliação: o equipamento ainda tem o que deveria ter? Ela não faz sentido diante de um comando avulso, porque um comando não deixa para trás nada com que comparar.

O ganho de operação vem daí. A configuração deixa de ser o que o técnico daquele dia lembrou de fazer e passa a ser o que está escrito. Dois assinantes na mesma condição recebem a mesma coisa, e a decisão sobre o que eles recebem passa a morar num lugar só, em vez de estar distribuída pela memória de quem instalou cada um.

Alterar um perfil já aplicado alcança os equipamentos que o seguem, sem que ninguém precise reaplicá-lo um a um. Isso é o que faz do perfil um lugar só: se a mudança parasse na tela de edição, o parque continuaria com o que recebeu no dia da instalação, e o perfil viraria documentação do que deveria ter sido feito em vez de descrição do que está valendo.

Há também uma decisão que o perfil obriga a tomar, e que costuma ser adiada: o que entra nele e o que fica de fora. Tudo o que o perfil declara passa a ter uma versão correta, e quem mudar aquilo passa a divergir do perfil. Um parâmetro que o assinante costuma alterar, se estiver declarado, vai aparecer como divergência toda vez que ele o alterar.

Isso não é defeito da ferramenta; é o que declarar significa. Mas obriga a escolher o que o provedor considera parte do serviço e vai manter, e o que ele deixa sob controle de quem mora ali. A escolha é de política, e sai mais barata antes de o primeiro perfil ir para o parque do que depois.

O que um perfil declara cobre quatro classes: o Wi-Fi do assinante — nome de rede, senha, canal —, a conexão com o provedor, a rede interna que o CPE entrega dentro da casa e o acesso de gerência do próprio equipamento. As duas primeiras são o serviço; a terceira é o que o assinante encosta com mais frequência, e por isso é a que mais pede a decisão do parágrafo acima; a quarta é a que ninguém lembra de conferir e é a que menos deveria variar de aparelho para aparelho.

A associação entre um perfil e os equipamentos que o seguem é feita de três formas, que convivem: por modelo, quando o que muda é o aparelho; por etiqueta, quando o recorte é do provedor e não cabe em nenhum atributo do equipamento — uma cidade, um lote de instalação, um piloto; e equipamento a equipamento, para a exceção que não vale virar categoria.

Scripts

Nem tudo cabe numa declaração. Existe o modelo que precisa de um passo a mais, a correção que só cabe a um subconjunto do parque, a mudança que tem ordem entre as etapas. Para esses casos há o script: uma sequência de passos, escrita uma vez e executada quando o caso aparece.

A diferença em relação ao perfil é de natureza, não de tamanho. O perfil diz como o equipamento deve estar; o script diz o que fazer. Um descreve destino, o outro descreve caminho. É por isso que a conciliação, adiante, fala de perfil e não de script: comparar um equipamento com um destino é possível; compará-lo com um caminho, não. Um script foi executado ou não foi.

O critério prático para escolher entre os dois é a repetição. Se o caso vai voltar, ele quer virar perfil; se é exceção com data para acabar, o script resolve. Ignorar o critério tem um custo que só aparece depois, porque scripts se acumulam: um parque mantido por uma coleção de scripts avulsos volta ao problema que o perfil resolvia, o de ninguém saber, olhando para um CPE, o que ele deveria ter.

A execução devolve o resultado passo a passo, e mostra em qual etapa parou quando alguma falha. A diferença é prática: um script que responde apenas “falhou” transfere o diagnóstico para quem executou, que vai refazer as etapas uma a uma para descobrir onde. E a execução alcança um conjunto de equipamentos de uma vez, pelos mesmos recortes que associam um perfil — o que preserva a única escala que interessa aqui, a de aplicar a mesma decisão a muitos aparelhos sem repeti-la manualmente.

Conciliação

Conciliar é comparar o que o equipamento tem com o que o perfil manda ter. O resultado é uma lista: os CPEs cujo estado real não corresponde ao declarado.

O valor está em achar a divergência antes de o assinante achar. Um equipamento fora do perfil costuma continuar funcionando — mal, ou de um jeito que só incomoda em certos usos. A pessoa do outro lado não vai relatar que o CPE dela está fora do perfil; ela vai ligar dizendo que a internet está ruim, semanas depois, e o atendimento vai começar do zero.

O paralelo mais próximo dentro da plataforma é a divergência CTO/PON, descrita em Relatórios. Também ali a lista mostra onde duas descrições da mesma coisa não fecham; também ali o custo de não olhar só é cobrado depois; e também ali o trabalho é preventivo por natureza — feito fora da urgência, ou não feito. A diferença é o que se compara. Lá, o que a rede informa contra o que alguém cadastrou. Aqui, o que o equipamento tem contra o que o provedor declarou.

A comparação é disparada por quem opera, e não roda sozinha em ciclo. O que ela entrega é a lista, não a correção: reaplicar o perfil sobre os divergentes é uma ação à parte, que alguém decide tomar e que tem permissão própria — a plataforma não corrige o parque por conta própria a partir de uma divergência.

Isso tem uma consequência que vale dizer, porque o texto acima elogia o trabalho preventivo: preventivo aqui depende de alguém lembrar de comparar. A conciliação que ninguém dispara não acha divergência nenhuma.

Um caso típico

Um lote de CPEs volta da manutenção. Os aparelhos foram testados, funcionaram e saíram de lá com configuração de fábrica — o que, do ponto de vista de quem consertou, é o estado correto de entrega. Eles são reinstalados e passam a funcionar: sobem, se anunciam, dão sinal de vida. Nenhum alarme, nenhum chamado.

Na conciliação, o lote inteiro aparece. Não um aparelho, não um assinante que ligou reclamando: a lista, com todos eles, apontando a mesma divergência em relação ao perfil que deveriam seguir. A correção é feita sobre o conjunto, de uma vez, em vez de um aparelho por vez à medida que os assinantes forem descobrindo o que está faltando.

O caso é típico porque o modo de falhar é típico: nada quebrou de forma visível. Sem a comparação, esse lote tende a virar uma sequência de chamados espalhados pelas semanas seguintes, cada um chegando como caso isolado, e cada um custando um diagnóstico inteiro para se descobrir a mesma coisa.

Definir um perfil, executar um script e aplicar uma correção sobre muitos equipamentos são três permissões distintas entre si, e nenhuma delas acompanha a leitura. A diferença importa justamente aqui, onde uma ação alcança o parque inteiro em vez de um assinante — ver Controle de acesso.

Por onde continuar

• Controle de acesso — como a plataforma decide quem pode definir um perfil, executar um script e aplicar uma correção sobre muitos equipamentos de uma vez.
• CPE e TR-069 — o inventário e a admissão que vêm antes de qualquer perfil.
• Relatórios — o mesmo raciocínio preventivo aplicado ao cadastro da planta óptica.