DevSecOpsARTIGO

Automatizando o desconhecido

Embora seja chato, atrevo-me a dizer que você não deve tentar automatizar um serviço, caso não o tenha usado por alguns anos "manualmente".

Enquanto o Gerenciamento de Configurações não é novo como um conceito, ele é novo para um monte de administradores de sistemas. Muitos começaram a usá-lo nos últimos dois anos e têm investido em fluxos de trabalho, módulos, reutilização etc. para manter seus sistemas ativos e funcionando. No entanto, ao mesmo tempo, há uma tendência preocupante que vejo surgir: a de automatizar algo que você não entende completamente.

Vejo isso em duas variantes: tentar automatizar algum serviço que alguém não entende completamente ou copiar cegamente módulos e códigos, de forma que seu aplicativo ou sistema não entenda o que se passa sob o capô.

Automação = conhecimento + visão + um objetivo

Sempre que você escrever um módulo Puppet ou um Chef Cookbook, estará essencialmente escrevendo no código aquilo que você acha que é a melhor forma de implementar, gerenciar e assegurar um serviço ou função. Você está derramando seus anos de experiência, seu conhecimento sobre o assunto, seus insights sobre a tecnologia e seu objetivo a longo prazo para esse módulo. Seu módulo/cookbok deve refletir sua visão de como esse serviço deve funcionar e o seu papel no sistema.

Isso só é possível quando você realmente domina essa tecnologia. Você pode automatizar uma parte da tecnologia que você não entende, mas não deveria, pois essa automação cria uma dívida técnica desde o primeiro dia em que foi criada e fornece a base para práticas piores. É uma espiral descendente da qual é difícil sair, porque as chances são de que você está esteja usando esse pedaço de código em produção.

Isso pode acontecer por uma série de razões: prazos apertados e pressão da gestão são as mais comuns. Você faz a escolha de entregar o trabalho feito e fazê-lo funcionar. A curto prazo, a automação funciona: você terá algo funcionando e em execução. A longo prazo, você está preso a uma tecnologia mal aplicada e com uma dependência no código que acabou de escrever, sem tempo para desfazer os hacks rápidos que foram utilizadas. É a clássica dívida técnica.

A realidade é que automação leva tempo. Um monte de tempo, se você deseja que tudo seja feito direito. Não é a automação em si, mas compreender os detalhes técnicos, as carências, as soluções e as melhores práticas de uma determinada tecnologia. E você não pode escrever um módulo ou um cookbook para qualquer coisa relacionada à tecnologia, caso não a domine.

Usando automação desconhecida

Então, se você não tiver tempo para dominar a tecnologia envolvida, com certeza poderá simplesmente pegar um módulo ou um cookbook no forje do Puppet ou na loja do Chef e fazer a automação, certo? Deixe que outras pessoas inteligentes escrevam os módulos com seus anos de experiência e conhecimento. Você acabou apenas o implementa e se beneficia de seu trabalho.

Isso dará certo até um certo ponto. Se você utilizar um módulo já escrito, entenderá o que esse módulo está fazendo? Sabe como é seu funcionamento interno e como depurá-lo em busca de problemas? Como irá reagir quando o serviço estiver lento para responder ou então estiver offline? Você sabe onde procurar e onde aplicar a correção?

Implementar módulos que outros escreveram, contendo uma tecnologia que você não domina, é como seguir um guia na Internet com comandos passo a passo. O módulo vai fazer o trabalho, mas você não vai saber por que certas medidas ou ações são tomadas. Você não vai saber por que as coisas são feitas do jeito que estão sendo feitas. E quando você realmente precisar dele – quando acontecer algum problema, ou falha de serviço -, você não saberá para onde correr, já que o funcionamento interno do módulo será uma caixa preta.

É preciso compromisso

E com isso eu não quero dizer um simples git commit. Construir uma infraestrutura de gerenciamento de configuração, escrever e gerenciar os módulos e implementá-los de forma correta exige compromisso sério. É preciso tempo, esforço, conhecimento e motivação. Isso significa se preocupar com a qualidade do código.

Embora seja chato, atrevo-me a dizer que você não deve tentar automatizar um serviço, caso não o tenha usado por alguns anos “manualmente”. Se você ainda não teve a chance de depurá-lo, de ter experimentado as deficiências de uma típica “implementação pela primeira vez” e ainda não aprendeu suas lições, é melhor não automatizá-lo. A automatização não vai lhe trazer nenhum benefício (você precisa repetidamente de uma configuração ruim?) e irá apenas retardar as coisas (como faço para migrar meu módulo legado para essa maneira nova e melhorada da gestão?).

Verdade seja dita, a gestão da configuração não é uma coisa fácil.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em https://ma.ttias.be/automating-unknown/

Trabalha com programação de linguagens e servidores há mais de 10 anos. Atualmente, trabalha na Nucleus como desenvolvedor e engenheiro de sistemas. Seus interesses incluem Linux, Apache, MySQL e PHP.

Ver perfil