Trate seu código de automação de TI como gado também.
A TI precisa adotar a padronização do código que faz a TI funcionar ou corre o risco de criar sistemas que desviam os benefícios financeiros e de eficácia da automação de TI.
Passei quase uma década desenvolvendo software. Software embarcado. Software web. Software cliente-servidor. Software de middleware e mainframe. Eu escrevi código profissionalmente em nove linguagens diferentes. O interessante é que não me lembro de usar mais de dois idiomas na mesma organização.
A maioria das organizações empresariais padroniza não apenas servidores, plataformas e estruturas, mas também linguagens. Existe uma meta de manutenibilidade para software que tem uma vida útil de mais de minutos e às vezes é contada em décadas. Manutenibilidade é a característica do software que permite que ele seja adquirido por outra pessoa e tenha suporte durante todo o seu ciclo de vida, independentemente de como essa vida útil possa ser medida. Isso geralmente ocorre devido à rotatividade de desenvolvedores e à disponibilidade no mercado de proficiência em idiomas, bem como aos custos de treinamento e manutenção geral. Como regra geral, as empresas padronizam linguagens de programação.
Isso é um anátema para as tendências atuais em microsserviços e computação sem servidor que apregoam como um benefício sua capacidade de oferecer suporte a um conjunto altamente diverso (poliglota) de linguagens. Bob e sua equipe podem escrever em Go enquanto Alice e sua equipe desenvolvem em C, Java ou Lambda. Embora certamente seja um bônus para desenvolvedores (que têm sua linguagem preferida), não é tão bom para organizações empresariais que precisam manter esse software ao longo do tempo. As APIs permitem sua integração e uso, tornando sua linguagem de implementação amplamente irrelevante em termos de desenvolvimento de aplicativos, mas em uma empresa o código subjacente ainda precisa ser mantido.
Quando se trata de automação de TI – a transformação digital interna que ocorre no lado da produção do negócio – é importante que as organizações reconheçam não apenas os benefícios da padronização nos scripts e sistemas que estão sendo construídos para suportá-la, mas também as armadilhas de não fazê-lo. Porque você não está construindo esses sistemas com a intenção de jogá-los fora na próxima semana, no próximo mês ou mesmo no próximo ano. Eles são um investimento de longo prazo que dará suporte à digitalização da implantação nos próximos anos. Isso significa estabelecer uma base flexível, mas firme, que se baseie nas melhores práticas aprendidas ao longo de décadas por desenvolvedores de aplicativos em empresas do mundo todo, a primeira das quais é a padronização.
1. Manutenibilidade
Eu sei que você gosta de escrever em PERL, mas todo mundo usa Python. Desenvolver automação na sua linguagem favorita faz dela sua favorita, o que significa que ninguém mais será capaz de mantê-la no futuro. Isso é ruim para você, porque você vai ficar preso a essa coisa por anos, assim como o peixinho dourado que você implorou aos seus pais quando tinha oito anos. Isso é ruim para a organização porque, se você sair, eles ficarão presos a um código que não conseguem manter e podem ter dificuldade para dar suporte. Uma pesquisa de 2016 conduzida pela SIG e O'Reilly descobriu que “70% dos entrevistados acreditam que a manutenibilidade é o aspecto mais importante do código a ser medido, mesmo em comparação ao desempenho ou à segurança”.
É muito importante. Veja scripts e sistemas como recursos compartilhados que podem ser facilmente modificados e suportados pela maioria das pessoas em TI agora e no futuro.
2. Compatibilidade
À medida que mais e mais serviços de TI são implementados como software, a tarefa de mantê-los atualizados e compatíveis com outros sistemas cresce. Se você acha que as APIs REST eliminam o problema de “compatibilidade com versões anteriores”, pense novamente. APIs são produtos (ou deveriam ser) e, portanto, também estão em constante evolução. E é pior na “rede”, onde há diferenças até mesmo na mesma linha de produtos, com diferenças de API de versão para versão que tornam a padronização uma tarefa de Sísifo. É um problema tão disseminado que a padronização de API ficou em terceiro lugar na lista de desafios tecnológicos que precisam ser resolvidos nos próximos anos, de acordo com um em cada quatro entrevistados do relatório State of API 2016 da Smart Bear .
E como muitas das linguagens que usamos em TI são interpretadas, mudanças de versão para versão podem destruir scripts e sistemas de automação cuidadosamente projetados. Mudanças de uma versão do node.js para outra podem ter um impacto profundamente negativo, desde quebrar um script até comportamento inesperado. Padronizar versões estáveis de ambientes de script e linguagens ajudará a minimizar o impacto de tais mudanças.
E você ainda terá que gerenciar patches e atualizações para cada sistema subjacente que alimenta essa automação, então quanto menos, melhor.
3. solucao-problemas
Jogar a padronização pela janela significa problemas para a solução de problemas. Isso é particularmente importante se você estiver migrando para uma métrica baseada no tempo de resolução para KPIs de TI . Quanto mais tempo levar para encontrar o problema, pior será a aparência da métrica. A padronização é um componente importante para reduzir o tempo de resolução. Se Bob for o único especialista em Python da equipe e estiver de férias (e inacessível) e seu script quebrar, quem estiver encarregado de solucionar o problema terá uma longa semana pela frente. Quando você incentiva a TI a usar sua linguagem preferida, você limita severamente a capacidade de outros de solucionar e resolver problemas. Mesmo que Bob não esteja de férias e não consiga encontrar o problema, poucos podem ajudar.
Esta não é uma área em que você queira mexer. De acordo com o InitialState , leva 30 vezes mais tempo para corrigir um bug do que escrever uma linha de código. Você pode visualizar o dinheiro sendo lentamente alimentado no triturador enquanto você se esforça para encontrar um bug no código com o qual não está familiarizado e, então , corrigi-lo. Não é uma imagem bonita. Você não pode eliminar o custo da solução de problemas, mas pode reduzi-lo eliminando o tempo adicional necessário para alguém que não conhece o idioma. Na produção, tempo é dinheiro, então qualquer coisa que você possa fazer para reduzir o tempo de resolução é essencial.
É por isso que, à medida que a TI adota lentamente linguagens de script, ferramentas e sistemas, não é uma má ideia sincronizar com o desenvolvimento de aplicativos. Se a TI padronizar os mesmos sistemas e linguagens (ou pelo menos alguns deles), você ganha uma legião de especialistas capazes de ajudar na solução de problemas e outros processos relacionados ao desenvolvimento, como revisões de código. Porque você está implementando revisões de código como um meio de encontrar bugs antes que eles causem problemas, certo? Certo?
A padronização é citada como um meio de combater o aumento de custos e certamente é um fator-chave para tais esforços. Mas a padronização também tem uma variedade de outros benefícios, incluindo a minimização da dívida técnica, a redução do tempo de resolução e a simplificação da manutenção operacional diária. Não padronizar nada certamente tem o efeito oposto nos orçamentos e no tempo, introduzindo complexidade e gargalos que anulam os benefícios da automação e impedem que as empresas obtenham os lucros e a produtividade necessários para crescer. Ao iniciar – ou continuar – sua jornada de automação de TI, lembre-se de tratar esses scripts e sistemas mais como gado e não como animais de estimação. Porque os animais de estimação exigem atenção pessoal e constante, algo que a TI não pode pagar daqui para frente.