Monitorizar sistemas quanto à disponibilidade e à velocidade, e sinalizar desvios antes de os utilizadores sofrerem com isso, é uma tarefa que pode ser largamente assumida. Não porque a IA subitamente entenda de infraestrutura, mas porque a própria tarefa já há anos que está estruturada em torno de valores de medição, limiares e repetição. Essa é uma conclusão diferente da que se aplica a tarefas em que o julgamento ou a negociação constituem o núcleo.
Três eixos são decisivos aqui: volume, grau de estruturação e custo do erro.
O volume é elevado. A monitorização decorre continuamente, dia e noite, sobre centenas ou milhares de pontos de medição. Uma pessoa que acompanhasse isso manualmente olharia para painéis de controlo a intervalos e perderia o que acontece entretanto. Um sistema que mede e compara com um valor-limite a cada segundo não perde isso.
O grau de estruturação é elevado. A tarefa consiste em: medir, comparar com uma norma e, em caso de desvio, emitir um sinal. Trata-se de um procedimento fixo, não de uma questão aberta. Compare-se isso com responder a uma pergunta de um utilizador sobre software, em que a pergunta é formulada de forma diferente de cada vez e requer contexto.
O custo do erro é baixo a médio. Um alerta perdido ou tardio é incómodo, mas geralmente recuperável: o sistema envia um novo aviso quando o desvio persiste, e a maioria dos valores-limite é definida com margem. Isso é diferente de uma tarefa em que um único passo em falta resulta imediatamente num utilizador sem uma aplicação a funcionar, como na resolução de um incidente de TI de primeira linha.
Dois eixos travam este quadro: a margem de julgamento e a criatividade situam-se, respetivamente, em 2 e 1.
Sinalizar um desvio é diferente de compreender o que esse desvio significa para a organização. Um pico na utilização de memória pode ser inofensivo, ou pode ser o início de um problema que, dentro de duas horas, paralisa a loja online. Determinar esse significado, e a decisão de escalar para um engenheiro que intervenha, continua a ser trabalho humano. A IA sinaliza o desvio; uma pessoa com conhecimento do ambiente avalia qual o valor desse desvio.
É precisamente por isso que esta tarefa não existe isoladamente. O sinal emitido por uma ferramenta de monitorização tem de ter um destino: como incidente registado com a urgência correta. A forma como isso prossegue está descrita em registar e priorizar incidentes de TI, uma tarefa que é ligeiramente menos delimitada do que a própria monitorização.
A avaliação é: um agente. Não um script isolado que verifica um único valor-limite, mas um sistema que mede continuamente, combina múltiplos sinais e determina por si próprio se um padrão merece um alerta antes de uma pessoa o ver. Isso é um passo além da simples emissão de alertas, e um passo atrás da autonomia total: o agente sinaliza e categoriza, um gestor decide o que acontece com o sinal.
Duas condições determinam se isso funciona. Têm de existir valores-limite configurados, ajustados ao que é normal para esses sistemas específicos: um limiar suficientemente rigoroso para uma aplicação pode disparar constantemente falsos alarmes noutra. E tem de existir um sistema de alerta automatizado que efetivamente entregue o sinal a alguém. Sem estas duas condições, não há nada para assumir: nenhuma norma com que comparar, nenhum canal para transmitir.
Numa empresa com alguns servidores e um horário de escritório fixo, a monitorização é muitas vezes ainda uma questão de verificação ocasional. O ganho de volume da automatização é aí limitado, simplesmente porque o volume é baixo. Numa empresa com muitos sistemas, clientes que esperam acesso a qualquer hora do dia, e um histórico de incidentes ocorridos durante a noite, o quadro é diferente: aí, a capacidade em fte libertada pela vigilância automatizada contínua aumenta rapidamente, porque a alternativa é uma pessoa que tem de estar permanentemente de prontidão.
Também o eixo do custo do erro varia por empresa. Num ambiente de testes interno, um alerta perdido não tem consequências. Num sistema que afeta diretamente transações de pagamento ou dados médicos, a exigência de conformidade é mais elevada, o que empurra ainda mais o eixo da conformidade, que aqui já se situa em 4, na direção do registo obrigatório e do acompanhamento demonstrável.
Isto não é uma afirmação sobre pessoal. Se e como uma organização utiliza de outra forma a capacidade libertada de um administrador de sistemas é uma escolha do empregador, com requisitos legais próprios sempre que isso toque em decisões sobre funções. Esta página descreve apenas o trabalho, não as pessoas que atualmente o realizam.
A monitorização raramente é uma tarefa isolada. Está relacionada com executar e verificar cópias de segurança, com a gestão de incidentes, e com o planeamento de quem deve estar disponível e quando para acompanhamento. Quem quiser uma visão mais ampla do que a IA pode assumir na função de TI como um todo encontra um ponto de partida na página sobre trabalho e planeamento.
Esta página apresenta uma avaliação com base na tarefa em forma geral. O que isso representa numa empresa específica depende do número de sistemas, dos valores-limite configurados e das consequências de um alerta perdido. É possível obter uma indicação para a situação concreta através do quickscan gratuito: doze perguntas, sem necessidade de conta, com uma indicação da parte das horas neste perfil que atualmente pode ser assumida pela IA. O werkscan completo, que decompõe o trabalho de uma empresa inteira em tarefas, está ainda em desenvolvimento.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.