O que a arquitetura pode nos ensinar sobre sistemas de autocura

As equipes de DevOps e os engenheiros de confiabilidade do site (SREs) lidam com o código diariamente. Fazer isso os ensina a examinar seu mundo, fazer observações astutas e estabelecer conexões inesperadas. Afinal, embora altamente lógico e matemático por natureza, o desenvolvimento de software é, pelo menos em parte, uma forma de arte. 

Não está convencido com essa afirmação? Considere os paralelos entre os feitos arquitetônicos mais notáveis ​​da história e a engenharia de software moderna. É uma comparação adequada: assim como a engenharia de software, a arquitetura emprega cálculos matemáticos complexos para criar algo bonito. E em ambas as disciplinas, um leve erro de cálculo pode levar a consequências significativas. Fascinantemente, muitos erros arquitetônicos famosos são análogos aos problemas que encontramos no código.

Lembre-se, a inspiração está em toda parte – contanto que você saiba onde procurar. Aqui estão algumas lições que os engenheiros de software podem aprender com as epifanias arquitetônicas ao longo dos séculos, especialmente em relação ao futuro dos sistemas de autocorreção.

Lição 1: Os casos extremos sempre explorarão as vulnerabilidades do sistema

A Citicorp Tower – agora chamada de 601 Lexington – terminou a construção na cidade de Nova York em 1977, época em que era o sétimo edifício mais alto do mundo. O design de última geração do arranha-céu incluía três palafitas de mais de 100 metros. Foi uma maravilha na conclusão. No entanto, um aluno de graduação logo descobriu algo chocante: ventos fortes pode comprometer a integridade do edifício. Especificamente, se fortes ventos de esquadria atingissem os cantos da Citicorp Tower, a estrutura estava sujeita a colapso - um literal caso extremo.

A torre tinha uma chance em 16 de desabar a cada ano. Essas probabilidades podem atrair alguém sentado em uma mesa de jogo, mas as perspectivas eram sombrias para os arquitetos e engenheiros estruturais por trás do Citicorp Tower. Felizmente, os técnicos conseguiram reforçar as juntas aparafusadas do edifício. O desastre foi evitado.

Os engenheiros estruturais sabiam que o Citicorp Tower acabaria enfrentando um vento forte o suficiente para comprometer seus rolamentos. Da mesma forma, engenheiros de software experientes sabem que o monitoramento robusto de desempenho de aplicativos (APM) e o gerenciamento de eventos não são suficientes para proteger um sistema dos inevitáveis ​​casos extremos. Isso porque sistemas estáticos sem aprendizado de máquina (ML) capacidades não podem lidar com novas situações inesperadas e não planejadas, como ventos de quadrante. Ao confiar apenas em ferramentas de monitoramento, um administrador humano deve decifrar os erros e escalar o processo de gerenciamento de incidentes.

Para reduzir o tempo médio de recuperação (MTTR)/tempo médio de detecção (MTTD), as equipes de DevOps devem aceitar a alta probabilidade de casos extremos e trabalhar para implantar soluções de autoaprendizagem preventivamente. Esta lição vai longe, pois a previsão é crítica na engenharia.

Lição 2: “Construir o avião enquanto ele voa” cria um ciclo sem fim

Eventos trágicos resultaram em vários as lições mais importantes da história da aviação. Quando um avião sofreu imensa descompressão durante o voo e caiu em 1954, os engenheiros verificaram que as janelas quadradas dos passageiros eram um ponto de estresse desnecessário. Daqui em diante, aviões foram equipados com janelas arredondadas. Incêndios a bordo levaram a novos arranjos de assentos priorizando a facilidade de evacuação. Essas mudanças salvaram inúmeras vidas.

Em muitas indústrias – incluindo a aviação – não há como testar exaustivamente um produto. Como mencionado anteriormente, os casos extremos são inevitáveis. A maior lição aqui é que os engenheiros de software devem prestar atenção às vulnerabilidades de seus sistemas quando elas se apresentam. A partir daí, eles devem abordá-los de forma expedita. Fazer isso requer duas coisas: (1) identificar e rastrear os principais indicadores de desempenho (KPIs) corretos e (2) investir tempo e recursos para melhorar os sistemas com base em métricas relevantes.

A equipe de engenharia média investe em 16 a 40 ferramentas de monitoramento, mas muitas vezes erra o alvo em que as métricas demonstram o sucesso. Menos de 15% das equipes rastreiam o MTTD, portanto, perdem 66% do ciclo de vida do incidente. E um quarto das equipes relatam faltando seus acordos de nível de serviço (SLAs) apesar do investimento significativo em rastreamento de disponibilidade. Isso nos diz que a coleta de dados precisa de uma análise completa e sistemática para cortá-la – soluções pontuais não são mais suficientes.

Engenheiros de software, equipes de DevOps e SREs devem priorizar processos e ferramentas que extraem valor de grandes quantidades de informações sobre disponibilidade. Em vez de simplesmente observar um erro crítico, eles devem pegar uma página do livro de um engenheiro de aviação e tomar decisões críticas rapidamente. O segredo para fazer isso está na IA.

Lição 3: IA é um bloco de construção fundamental para sistemas de autocorreção

Um sistema de autorrecuperação totalmente autônomo e perfeitamente funcional é ideal para qualquer engenheiro de software. Os sistemas que se corrigem sozinhos são bons para a satisfação do cliente, pois eliminam o tempo de inatividade dispendioso do consumidor. Além disso, eles são incrivelmente benéficos para as funções de gerenciamento de serviços de TI (ITSM), pois reduzem significativamente a necessidade do tedioso gerenciamento de tíquetes. Construir tal sistema requer vários componentes, muitos dos quais estão atualmente fora de alcance. Mas estamos mais perto de uma realidade de autocura do que alguns podem imaginar.

A falta de adoção generalizada de IA continua sendo o maior obstáculo que os sistemas de autocorreção enfrentam hoje. Embora muitas empresas tenham adotado ferramentas rudimentares baseadas em IA ou ML, a integridade dessas ferramentas é questionável. Ou seja, muitos engenheiros lidam com inteligência artificial para operações de TI (AIOps) tecnologias que seguem a lógica de automação baseada em regras em vez de algoritmos autônomos de IA. A distinção pode parecer ínfima, mas, na prática, é a diferença entre horas de produtividade perdidas e milhões em possíveis perdas.

O fato é que as ferramentas AIOps baseadas em regras analisam as interações entre soluções pontuais díspares e provavelmente podem identificar erros de dados comuns. Mas os sistemas baseados em automação não podem processar a evolução de erros inteiramente novos ao longo do tempo, nem podem prever novos defeitos nos dados. Isso ocorre porque os administradores humanos que codificam essas funções solicitam que o sistema siga uma se isso, então aquilo padrão lógico. As ferramentas AIOps genuinamente eficientes atenuam os erros que surgem em todos os quatro pontos clássicos de telemetria – da detecção à resolução – classificando padrões novos e problemáticos antes que os técnicos humanos percebam sua existência. 

Enquanto esperamos o terceira onda iminente de IA, esta versão do AIOps é a mais próxima que temos dos sistemas de autocorreção. Será interessante acompanhar como os aplicativos AIOps atuais se infiltrarão no futuro da IA, que incluirá automação totalmente realizada e possibilidades de pensamento independente. Talvez então os engenheiros estruturais também colham as recompensas de um sistema de autocorreção baseado em IA.

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• Platoblockchain. Inteligência Metaverso Web3. Conhecimento Ampliado. Acesse aqui.
• Fonte: https://www.dataversity.net/what-architecture-can-teach-us-about-self-healing-systems/