Header image

5 Dicas para evitar problemas com Automação

27 de fevereiro de 2020Automação Industrial , Dicas

Em 2015, o engenheiro de software sênior Benjamin Willenbring ficou empolgado quando a empresa que trabalha, a Autodesk, introduziu o teste automatizado de software. Mas essa emoção não durou muito. A pequena equipe de automação não se comunicava muito com sua divisão. E quando os testes chegaram à produção, eles não eram o que se esperava. “Meus colegas de equipe falavam sobre os testes falharem e não ter muita confiança neles”, diz Willenbring. Ele descobriu que “conseguir realmente executar o teste era muito, muito difícil. Não estava documentado. Você precisava conversar com alguém. E havia uma quantidade enorme de arquivos e eu realmente não entendia o porquê”.

Os 6 passos para a aplicar a Hyperautomation nas empresas
► Sistemas elétricos em atmosferas explosivas – Cuidados! 
 5 dicas de como montar uma rede estruturada para empresa
► Falta de limpeza de ar-condicionado é um risco à saúde, entenda!
► O que é Automação Industrial e onde ela se aplica?
► Adequação à NR-10 – Segurança em Serviços e Instalações Elétricas
5 Dicas de Manutenção de Ar Condicionado
5 Dicas incríveis para Manutenção Elétrica Industrial
► Dicas de Manutenção Elétrica Predial Preventiva
► Os 10 principais itens da NR 12

A automação deveria facilitar o trabalho de Willenbring. Em vez disso, os problemas que ela criou passaram a dominar grande parte de sua energia pelos próximos anos.

A experiência de Willenbring não é incomum. E com a automação se espalhando rapidamente pela TI, os contos de advertência fornecem lições valiosas. Desde os fluxos de trabalho automatizados do DevOps até a RPA (automação de processo robótica, na sigla em inglês), os processos automatizados visam reduzir o trabalho escasso e liberar funcionários qualificados para tarefas de nível superior. Mas instalações defeituosas ou lançamentos defeituosos podem transformar o sonho de automação em um pesadelo.

Conversamos com vários profissionais de TI sobre histórias de terror de automação que eles ouviram ou sofreram e elaboramos seis mandamentos para ajudar suas iniciativas de automação a evitar tais destinos.

Automação faz parte do trabalho de todos

O inferno de testes automatizados de Willenbring tinha um problema importante: as únicas pessoas que os entendiam eram aqueles que os construíam, e eles estavam baseados em uma cidade diferente da sua divisão.

“Uma das dificuldades da estrutura de teste foi que ela não forneceu um bom feedback quando houve uma falha”, diz Willenbring. “Se algo falhou, a primeira coisa que você faz é entrar no Slack e entrar em contato com o líder de testes e perguntar: ‘Por que isso falhou?’ E então executar o teste manualmente de novo – alguma versão especial do framework para poder ver os resultados – e depois comunicar o que aconteceu “.

A estrutura de teste violou duas regras fundamentais que Robert Haas, gerente global de produto DevOps da DXC Technology, diz que todo regime de automação deve cumprir. A primeira é que o código de automação deve ser documentado. “Se você usa uma abordagem moderna como a documentação como código ou faz anotações nos diagramas do Visio, a resolução de problemas será mais fácil se houver alguma documentação que descreva o que foi feito originalmente”, diz Haas.

Sem documentação, os testes automatizados eram inescrutáveis ​​para a equipe de Willenbring. Como resultado, eles não conseguiram entender os resultados e perderam a confiança nos testes e na equipe que os criou. “Às vezes, os desenvolvedores apenas diziam: ‘Eu não me importo. Não há como isso ser um fracasso real'”, diz Willenbring. “Às vezes houve falhas reais que a estrutura de teste detectou. Mas o problema essencial era que havia falta de confiança nos testes e nos resultados”.

Outro conselho da Haas: “Priorize atividades que precisam ser automatizadas com base no valor comercial que elas oferecem”. Mas como a equipe de teste da Autodesk estava tão separada da equipe de desenvolvimento, Willenbring descobriu que muitas das áreas de sua base de código escolhidas para teste desafiavam o senso comum. “Você precisa permitir que especialistas no assunto, pessoas que entendem o que é importante, selecionem o que é testado”.

Foi preciso um novo diretor de engenharia para tirar Willenbring e sua equipe desse ciclo vicioso. O novo diretor determinou que “a qualidade é tarefa de todos”, incluindo a automação de testes. O teste centralizado foi acelerado e as divisões individuais foram responsáveis ​​por escrever testes para o código em que trabalhavam. Willenbring e sua equipe agora podem adaptar os testes às suas necessidades e integrar esse processo ao seu dia a dia. No final, ele diz: “Você precisa estabelecer uma política de tolerância zero para uma atitude de ‘esse não é o meu trabalho'”.

1 – Esteja preparado para a complexidade

O fornecedor de automação de segurança e conformidade Tripwire observou recentemente algo estranho com um de seus grandes clientes financeiros.

“Você permite que nossas soluções sejam implantadas de maneira automatizada”, diz Irfahn Khimji, country manager na Tripwire Canadá”, e durante muito tempo ficamos imaginando o que estava demorando tanto. Por que não estamos vendo o uso de nossa licença aumentar? significativamente? Porque eles deveriam estar girando muito rápido “.

Como se viu, o ideal de um pipeline automatizado de CI/CD (integração contínua e implantação contínua) estava sendo executado na realidade de diversas unidades de negócios da organização financeira, cada uma delas baseada em seu próprio conjunto personalizado de componentes de software.

“Eles têm mais de 30 aplicativos que estavam tentando integrar e enfrentaram alguns desafios com a mercantilização de cada uma dessas variações – os módulos de que precisam em várias bibliotecas e coisas assim”, diz Khimji. “Ajustar o pipeline para lidar com todas as diferentes variações realmente diminuiu o processo de automação, porque não foi apenas um clique e foi implantado – foi, ok, clique, clique e certifique-se de que cada uma dessas várias tecnologias esteja funcionando uns com os outros e capazes de implantar “.

Não existe uma bala mágica para resolver esse problema, mas você precisa estar ciente de que, à medida que o número de componentes em seu processo automatizado aumenta, a quantidade de canalização necessária para conectar esses componentes aumenta exponencialmente. Essa complexidade adicionará tempo e recursos à medida que você faz a transição para processos automatizados.

Outro fator que aumenta essa complexidade não é apenas quantos componentes você está conectando, mas de onde eles vêm. A maioria dos pipelines ou ambientes controlados por RPA inclui uma mistura heterogênea de componentes internos e de terceiros – o último dos quais pode ser um problema real se algo der errado.

“Garanta que todos os componentes de seus pipelines de CI CD ou processos automatizados tenham um contrato de manutenção com o fornecedor do software”, diz Haas da DXC Technology. “Se houver componentes de código aberto, faça uma avaliação de risco para determinar se você deve considerar o uso de uma versão gerenciada do produto, em vez de contar com o suporte baseado na Web da comunidade de código aberto“.

2 – Cuidado com a ‘caixa preta’

As instituições financeiras estão entre as mais ansiosas para implantar RPA e chatbots, e Muddu Sudhakar, CEO e cofundador da Aisera, alerta para um cenário que ele tem visto muito nesses ambientes: os processos são concebidos como uma única unidade monolítica de funcionalidade que tornar-se uma “caixa preta” cujas operações internas são difíceis de separar para solução de problemas.

“Em uma estrutura monolítica, o cliente verifica o status de sua conta e, se ele quiser sacar o dinheiro e movê-lo, tudo acontecerá em uma única etapa”, diz ele. “Se algo der errado e não houver monitoramento auditado dessa etapa, a única maneira de recuperar o dinheiro em uma falha catastrófica é ligar para o atendimento ao cliente – talvez você precise ir pessoalmente ao banco para obtê-lo”.

Para Sudhakar, esse tipo de design costuma ser um marcador dos esforços iniciais de uma organização com automação. Um projeto como esse pode produzir bons resultados, desde que tudo corra conforme o planejado. Mas quando isso não acontece, as organizações geralmente precisam voltar à prancheta para dividir essas caixas-pretas. Melhor seria evitá-los para começar.

“Divida cada processo em blocos de construção”, diz ele, “onde cada bloco de construção é auditável e monitorável”

3 – Construir com freios e contrapesos

Ari Meisel é o fundador da Less Doing e um coach de produtividade com um interesse especial em automatizar trabalhos manuais. Para pagar os boletos, ele costuma construir automações para a própria vida. Mas ele aprendeu uma lição valiosa quando tentou tirar algumas multas de estacionamento.

Meisel era dono de uma caminhonete – tecnicamente um veículo comercial – e, na cidade de Nova York, onde ele mora, o proprietário desse veículo pode facilmente contestar uma multa: “Você pode enviar uma carta e dizer: ‘Eu estava fazendo uma entrega.'”

A epifania que ele teve foi, e ele admite, “não totalmente legal”: ele criou uma automação que geraria faturas aleatoriamente e as enviaria juntamente com uma carta ao Departamento de Finanças disputando seus ingressos. E funcionou, até que “ficou preso e enviou exatamente a mesma carta e fatura centenas de vezes, e eles descobriram. Eu tinha que procurar um advogado e eles estavam ameaçando me mandar para a cadeia”, diz ele. “Acabou me custando US$ 36.000, porque eu meio que o configurei e esqueci.”

O que seu processo automatizado precisava, ele percebeu, era uma poka-yoke. Este termo, que significa “à prova de erros”, é emprestado dos japoneses; dentro do sistema de produção da Toyota, ele designou uma única etapa em um processo dividido em duas, sendo a segunda dependente da primeira. Esse aumento de etapas melhora paradoxalmente a eficiência, porque os erros não são exibidos na linha de produção, onde os efeitos podem sofrer metástases. Meisel diz que, em seu esquema de retirada de bilhetes, “eu poderia executar automaticamente algo que compararia uma fatura com a anterior para ver se era a mesma coisa. É uma coisa muito fácil de fazer”.

Isso amplia o conselho de Sudhakar da Aisera: Etapas automatizadas individuais não devem ser apenas auditáveis, mas constantemente auditadas por outras etapas automatizadas. Isso entra no domínio dos AIOps, em que plataformas automatizadas assumem o ônus do gerenciamento de TI dos engenheiros humanos. “Eu chamo isso de abordagem da NASA”, diz Sudhakar. “A NASA deve assumir que uma falha acontecerá. Uma solução AIOps com freios e contrapesos é muito importante.”

Mas, a menos que você tenha experimentado uma falha de automação em primeira mão, é difícil ver o valor, diz Meisel: “Noventa por cento das vezes, as pessoas precisam de ter algo errado. Eles dizem: ‘Eu não vou passar três dias criando essa automação da qual nunca vou me beneficiar. E então descobrir que precisam. ”

4 – Não negligencie a segurança

Os pipelines de CI/CD automatizados têm um segredo sujo: muitos foram lançados como shadow TI para solucionar as exigências de segurança. “Os desenvolvedores querem se desenvolver”, diz Khimji, da Tripwire. “Eles querem manter as coisas em movimento e seguir para a próxima iteração de [seu código]. Portanto, quando um processo rigoroso de TI e segurança atrapalha, eles pensam: ‘posso rodar essas imagens na nuvem e posso contornar isso.”

Isso não significa que os pipelines são inerentemente inseguros, mas você deve investigar quais práticas de segurança foram descartadas em prol da eficiência automatizada. Além disso, lembre-se de que qualquer processo automatizado representa mais um vetor para um ataque. Os processos que operam autonomamente podem ter permissões elevadas, tornando-os alvos tentadores. Sudhakar, da Aisera, diz que conhece pelo menos uma instância do que chama de “cisne negro”: um ator hostil que trabalha dentro de uma empresa usando o pipeline do DevOps para injetar malware na base de código. “Isso foi propagado até o ambiente de produção e o sistema não estava operacional”, diz ele.

5 – Não tente economizar com a automação

Com o hype vem mal-entendidos. Ajeet Dhaliwal, desenvolvedor-chefe e fundador da Tesults, descobriu que muitas organizações têm uma visão de “teste automatizado” que varia muito das melhores práticas. Isso é particularmente verdade em organizações menores, onde os executivos não têm formação técnica. Como eles entendem o teste manual, pela lógica deles, os testes automatizados devem ser apenas uma versão dos testes manuais que podem ocorrer sem intervenção humana.

Como resultado, diz Dhaliwal, “Eles incentivam os testadores tradicionais de controle de qualidade a realizar testes manuais que não tinham experiência em desenvolvimento de software para automatizar os testes”. Às vezes, isso significa usar ferramentas que simplesmente gravam testes manuais da interface do usuário para repetição posterior. “A robustez e flexibilidade dessas abordagens não correspondem ao que um desenvolvedor pode alcançar com relação à automação”, diz ele.

“Os desenvolvedores de testes automatizados também precisam ser engenheiros de software”, acrescenta Dhaliwal. “É bom ter alguns desenvolvedores juniores envolvidos, mas essas empresas precisavam de pelo menos alguns desenvolvedores experientes liderando o trabalho e eles não tinham isso”.

E, como Willenbring da Autodesk diz, os engenheiros de software precisam entender como criar processos automatizados também. “Supõe-se que essa seja uma das habilidades que seus desenvolvedores terão”, diz ele.

 

Via: cio


Related post


Leave A Comment

Your email is safe with us.