Transformando histórias de terror do CMDB em estratégias de sucesso de TI

Sean Dawson: Sejam todos bem-vindos ao Cask Distillery Podcast, onde revelamos todo o potencial do ServiceNow com insights de especialistas e estratégias práticas, somente aqui no Cask Distillery Podcast. E hoje, temos um episódio assustador, porque o Dia das Bruxas está chegando!

Por isso, gostaríamos de reservar um momento para conversar com Chris Padmore, meu convidado especial de hoje - que é o diretor de prática de ITOM aqui na Cask - e falar sobre algumas das histórias assustadoras que podem acontecer no CMDB. Então, seja bem-vindo, Chris. Obrigado por reservar um tempo em sua agenda lotada, mesmo que isso tenha acontecido de última hora. Então, obrigado. 

Chris Padmore: Obrigado por me receber, Sean. 

Sean Dawson: Ah, não se preocupe. Então, vamos direto ao assunto, porque quero que você fale um pouco sobre algumas histórias e algumas coisas que podem dar errado com o CMDB, e a primeira em que pensamos foi a história do incidente "Phantom Update", então fale um pouco sobre isso para nós.

Chris Padmore: Ah, sim, essa é uma boa pergunta, e muitas pessoas provavelmente já se depararam com ela em algum momento, mas quero que você imagine o seguinte: Você tem uma equipe de TI de uma grande empresa, certo? E eles estão fazendo as atualizações típicas do CMDB. Depois, há uma nova pessoa e ela já fez suas alterações. Ela está fazendo suas atualizações. Mas cometem um erro - um erro muito pequeno. Você não acha que seria um grande problema. Mas, então, começa a acontecer uma tragédia. Um aplicativo fica inoperante. Ninguém sabe o motivo. Outro aplicativo fica inativo. Ninguém sabe disso. E eles estão tentando descobrir. Isso nunca aconteceu antes. E as pessoas estão procurando, e estão procurando. Estão verificando o CMDB e os tíquetes, e não sabem por que todas essas coisas estão caindo. 

E, ao que parece, o culpado foi um erro na atualização do CMDB. Assim, quando fizeram a última alteração no CMDB, removeram acidentalmente uma das principais dependências do servidor em que estavam sendo executados. Portanto, todas essas coisas estavam acontecendo no lado do servidor e não estavam relacionadas a todos os serviços upstream. Assim, eles podiam ver claramente que aquele servidor estava com um problema; aquele banco de dados não estava funcionando. Todos esses aplicativos não perceberam que dependiam desse banco de dados. E tudo isso porque alguém, sem querer, alterou uma dependência sem saber.

Sean Dawson: Uau. Então, na sua opinião, como garantir o mapeamento preciso de dependências no CMDB para evitar que isso aconteça? 

Chris Padmore: Portanto, sua amiga será a ferramenta Discovery. Ela se certificará de que, ao fazer a varredura e ver as dependências entre os componentes de TI, essas dependências sejam associadas corretamente no CMDB. Portanto, mesmo que eu remova essa dependência manualmente, quando o Discovery for executado da próxima vez, ele a colocará de volta, e você não precisará se preocupar com a falta de configurações e com o desconhecimento de todos os impactos upstream e downstream de algo. 

Sean Dawson: Muito bom. Obrigado por isso. Então, a próxima situação assustadora que podemos encontrar é o servidor fantasma. Fale um pouco sobre o que é isso e o que pode acontecer. 

Chris Padmore: Ah, sim, mas muitas pessoas também já viram isso. Você está sentado em seu help desk e recebe uma ligação dizendo: "Parece que o servidor 123 está fora do ar". E você procura o servidor 123 e ele está no CMDB, mas não está fazendo ping. Você não vê nenhum tíquete associado a ele. Não há nenhum aplicativo em execução nele. Você não vê ninguém solicitando-o, exceto por esse chamador fantasma. E você pensa: "Bem, de onde veio esse servidor? Por que ele está aqui?" E você tenta fazer uma varredura com o Discovery e nada acontece. Você pede para a equipe do servidor fazer login e eles dizem: "Bem, esse endereço IP não existe. Ele está dizendo: 'Nada encontrado'". Acontece que esse servidor costumava ser um servidor, costumava existir no CMDB. Mas ele foi desativado. E, em algum momento, quando alguém estava fazendo seu trabalho de desativação, quebrando suas dependências, deixou algo intacto.

Portanto, embora o servidor esteja lá, ele não está se comunicando com nada, ninguém pode acessá-lo, e alguém tem que ir fisicamente ao porão e desconectar esse servidor das instalações. Mas isso é assustador porque o pessoal de risco diz: "Bem, quem colocou o servidor aqui? Quem tem acesso a ele? Alguém entrou e conectou algo quando ninguém estava olhando?" - esse tipo de coisa. Acontece que é apenas uma sobra de servidor que deveria estar lá. E agora alguém pode ir até lá e realmente desligá-lo. 

Sean Dawson: É bom. Então, qual é o processo pelo qual alguém pode garantir que os ativos descomissionados sejam realmente removidos por completo?

Chris Padmore: Portanto, há algumas coisas que tentamos fazer. Temos algo chamado "processo de mudança de ciclo fechado". Portanto, é quando estamos fazendo algo como atualizar ou remover um componente. A última coisa que você quer fazer é verificar esse componente. E, em seguida, certificar-se de que o CMDB reflete com precisão suas atualizações.

Nesse caso, com a desativação, o que deveria ter acontecido é que o Discovery deveria ter visto que o servidor havia desaparecido completamente. Alguém deveria tê-lo marcado como "descomissionado" no CMDB. E, então, alguém da equipe do servidor deveria ter ido até lá e ter uma tarefa dizendo "desconecte-o da parede". E então você teria concluído a tarefa. Não apenas a desativação totalmente executada, mas também a documentação e os tíquetes informando: "Sim, essa pessoa foi até lá e desconectou o computador nesta data. E confirmamos que o Discovery não está mais vendo isso".

Sean Dawson: Ótimo. Então, vamos falar sobre a próxima. A "Catástrofe do desvio de configuração invisível".

Chris Padmore: Ah, sim, isso é, mais uma vez, coisas com as quais as pessoas provavelmente têm pesadelos se já se envolveram com elas. Mas imagine o seguinte: Temos nossos sistemas principais e os estamos escaneando. A equipe sabe como eles estão configurados e, normalmente, não temos nenhum problema com eles. Eles estão funcionando. Estão funcionando muito bem. Então, começamos a ver mudanças, começamos a ver que eles estão se comportando de forma diferente. E então, para ter certeza de que não é você, você vai e olha e vê, por exemplo, "Ei, isso diz que estamos usando dois servidores Linux, mas vejo dois servidores Windows executando esses aplicativos". "Ei, isso diz que estamos no patch 14, mas vejo que estamos no patch 8. O que está acontecendo?" E assim, o que pode acontecer é que, por qualquer motivo, as configurações principais desse sistema estão começando a mudar. As coisas estão ficando desatualizadas. As coisas não estão correspondendo ao que as pessoas planejaram. E alguém se preocupa com o fato de que alguém está no sistema fazendo algo que não deveria fazer. 

Mas não é o caso. Em geral, isso pode acontecer quando o código errado é enviado durante uma atualização de rotina. Portanto, essas são coisas que podemos detectar facilmente com a ferramenta Discovery. Podemos rastrear esses arquivos de configuração principais. Podemos rastrear quando eles estão sendo atualizados, o que os está atualizando e quais são as diferenças entre a última vez que o Discovery foi executado. E, em seguida, podemos gerar alertas automatizados, dizendo: "Ei, parece que esse arquivo de configuração foi alterado. Ele não foi alterado durante uma de suas principais janelas de alteração. Vamos pedir a alguém que dê uma olhada nele e veja o que realmente está acontecendo".

Sean Dawson: Que ótimo. E você realmente respondeu à minha pergunta: "Como podemos evitar isso?" Certo. E quanto ao desastre do efeito dominó da dependência? 

Chris Padmore: Ah, sim. Essa é uma experiência que tive pessoalmente há muitas e muitas luas atrás, mas imagine que você e sua equipe estão fazendo seu trabalho normal e fazendo apenas pequenas atualizações. Você tem dez servidores que são corrigidos regularmente, e chega aquela hora de novo. Então, é uma sexta-feira à tarde, você está fazendo suas correções, termina o dia, fecha tudo e vai para casa. Você vai para a cama pensando que vai aproveitar o fim de semana. Então, você acorda e tem 50 chamadas telefônicas não lidas, centenas e centenas de Slacks e um e-mail dizendo: "Ei, este sistema está fora do ar. Este sistema está falhando. O que está acontecendo?" E você entra em pânico porque se lembra que acabou de fazer uma atualização antes de ir para casa. Então, você começa a pensar: "Bem, não pode ser a minha atualização. Meu sistema é isolado. É apenas uma pequena atualização". E você faz login, e este aplicativo, este aplicativo está inativo, e você está enlouquecendo. Você pensa: "Não é possível que seja eu. Não é possível que seja eu". E então, por acaso, você olha e vê que, dos 10 servidores que você atualizou, o último servidor deveria ser o servidor CMDB 22 e, na verdade, você atualizou o servidor CMDB 2022, que não é o seu servidor. É o servidor de outra pessoa. 

Então, sem querer, você liberou um monstro em sua organização e não tem o know-how e o conhecimento para entrar e consertá-lo. Então, você está entrando em contato com as pessoas. Você está nessas chamadas de sala de guerra tentando descobrir o problema. E você tem que se levantar na frente de todos e dizer: "Acho que pode ser este servidor e acho que esta pode ser a mudança que causou o problema. Vamos pedir a alguém que dê uma olhada nisso".

Sean Dawson: Então, quais são as práticas recomendadas para gerenciar dependências em um CMDB? 

Chris Padmore: Novamente, você deve seguir seu processo de gerenciamento de mudanças. Certifique-se de que está revisando e validando todo o trabalho que está fazendo.

Ao fazer qualquer alteração, você terá uma lista de CIs em que trabalhará. É preciso garantir que você esteja realmente fazendo login nesses CIs para enviar suas alterações - que as tarefas que você está confirmando durante essas tarefas sejam validadas, como: "Ei, isso é uma captura de tela do número do servidor para que possamos confirmar que você está realmente conectado ao servidor certo?" Mais uma vez, você deseja fazer essas alterações de loop fechado usando o Discovery. Portanto, depois que você terminar de fazer as atualizações, o Discovery deverá reatualizar tudo para garantir que as configurações que você estava fazendo realmente se apliquem aos CIs listados na alteração. Portanto, se você deveria estar no servidor 20 e redescobrir o servidor 20 e ele disser "Nenhuma alteração detectada", talvez você esteja no servidor errado e não poderá aproveitar o fim de semana como planejava. 

Sean Dawson: Sim. E a atualização do CMDB AI Gone Wrong? Essa é mais recente, mas pode ser muito assustadora.

Chris Padmore: Sim, a IA em si é bastante assustadora se você não estiver acostumado a ela. Mas vamos imaginar que você tenha iniciado um dos módulos de aprendizado de máquina do ServiceNow e o esteja usando para sinalizar inconsistências em seu CMDB. E, portanto, você acabou de lançar a próxima versão dele. Ele está fazendo suas atualizações com base em algumas alterações recentes que foram feitas. Mas a IA se tornou autoconsciente e acha que sabe mais do que você. Assim, ela começa a marcar os ativos de TI como inválidos, incorretos, não detectáveis, não operacionais, com base nas alterações feitas anteriormente. E, quando você tem a chance de perceber, já tem centenas e centenas de servidores e bancos de dados com status operacionais errados. Você tem muitos e muitos relacionamentos removidos que não deveriam ter sido, e então você tem muitos e muitos recursos vinculados a serviços aos quais eles não deveriam estar vinculados. 

Sean Dawson: Sim. Então, uma boa pergunta seria: como a IA pode ser integrada com segurança ao gerenciamento do CMDB? 

Chris Padmore: Portanto, você deve se certificar de que não está adotando o aprendizado totalmente não supervisionado para começar com as atualizações de IA do CMDB. Você quer alguma validação. Ela aprende observando o que você está fazendo e vendo o que há no sistema. Mas é preciso treiná-la, principalmente se você estiver apenas começando. Você deve verificar se as atualizações que ele acha que está fazendo são válidas. Você deve fornecer o feedback dizendo: "Não, nessas circunstâncias, esse não é o tipo certo de atualização que queremos fazer". E você também deve testar essas coisas no ambiente inferior. Você quer ter certeza de que ele está se comportando conforme o esperado no ambiente de desenvolvimento e que você pode usar esses modelos na produção sem ter que reverter um monte de alterações que ele achava que deveria estar fazendo. 

Sean Dawson: Muito bom. Bem, obrigado, Chris, mais uma vez, pelo seu tempo. Sei que foi de última hora, mas queríamos agregar valor aos nossos espectadores e ouvintes, independentemente de como eles estejam combinando ou consumindo o podcast aqui. Então, muito obrigado, Chris.

Também quero destacar que Chris está envolvido em uma série de webinars sobre CMDB, para os quais colocaremos o link no rodapé ou acima, ou seja lá o que for que você esteja assistindo, que temos uma série sobre CMDB, com muitas informações excelentes. Portanto, enviaremos você para a página de registro para que possa participar deles e ver mais.

Mas, por enquanto, é isso. Tenham um Halloween seguro e feliz e se cuidem. Até logo. 

Chris Padmore: Obrigado, Sean. Vejo você em breve.