Criação de relatórios de incidentes de TI: Uma porta de entrada para insights após incidentes de TI

Em busca da memória institucional

As empresas digitais se esforçam para oferecer experiências de serviço sempre ativas para impulsionar a produtividade dos funcionários e a receita geral da empresa. No entanto, apesar dos esforços multifacetados das equipes de TI, pequenos sinais podem passar despercebidos, transformando-se em incidentes inesperados de TI, levando a ataques cibernéticos e interrupções de serviços.

Além disso, a ausência de memória institucional impede que as equipes de TI refaçam suas etapas e apliquem correções de curso enquanto resolvem incidentes de TI. Manter um registro central dos relatórios de incidentes com todos os detalhes sobre um incidente e sua resolução é crucial para agilizar os esforços, especialmente quando são necessários 277 dias, em média, para detectar incidentes de segurança cibernética. É imperativo criar um relatório de incidentes de TI bem documentado para ajudar as equipes de TI a discernir o que deu errado, identificar as possíveis causas, identificar quem está no comando e, finalmente, ajudar na resolução eficaz.

Familiarizando-se com os relatórios de incidentes de TI

Um relatório de incidente de TI é um documento formal que descreve as características críticas dos incidentes de TI em um local central, desde descobrir o que aconteceu e analisar quando e como isso aconteceu até a resolução final e as próximas etapas. A consolidação desses detalhes em um repositório central ajuda as equipes de TI a aprenderem com as experiências anteriores e a criarem melhorias, aumentando a confiabilidade de suas operações de serviço.

Estabelecendo a base para o emprego de relatórios de incidentes de TI

Para entender por que as empresas digitais precisam aproveitar os relatórios de incidentes de TI, aqui está uma rápida olhada em vários cenários e na utilidade desses relatórios.

A partir dos cenários listados acima, fica claro que documentar incidentes de TI por meio de relatórios de incidentes pode oferecer vários benefícios. Agora vamos nos aprofundar nos detalhes da criação de um relatório de incidentes de TI.

Estruturação de um relatório de incidentes de TI

Ao definir claramente a estrutura de um relatório de incidentes de TI, as empresas podem promover uma documentação coerente, permitindo fácil acesso às informações. Veja como poderia parecer.

Fig.1 Uma estrutura típica de um relatório de incidentes de TI.

 

Com uma ideia de como as empresas podem estruturar seus relatórios de incidentes de TI, vamos agora nos aprofundar em como elas podem criar um do zero.

Elaboração de relatórios de incidentes de TI

Digamos que a Zylker, uma empresa multinacional fintech fictícia que opera um gateway de pagamento on-line, sofra uma interrupção inesperada do serviço. Vamos ver como ela capturou os detalhes desse episódio, passo a passo, nas várias seções de um relatório de incidente:

1. Resumo

Esta seção contém uma visão geral concisa do incidente, destacando o que aconteceu, quando e onde ocorreu e os sintomas.

Por exemplo, usuários nos Estados Unidos (EUA) não conseguiram acessar os serviços de pagamento on-line em 15 de junho de 2024, das 14h às 16h30, devido a um certificado SSL desatualizado. Durante o incidente, eles encontraram um aviso de segurança mostrando um erro 525.

Com essas informações, a Zylker estava melhor equipada para avaliar a natureza e o escopo de incidentes semelhantes.

2. Detecção e avaliação de impacto

Detecção:

Esta seção contém informações sobre a origem do incidente e o tempo necessário para detectá-lo. Por exemplo, a Zylker examinou seus logs de monitoramento, que revelaram um aumento nas taxas de erro relacionadas a falhas de handshake do SSL às 14h04. Também observou um aumento nas chamadas em seus canais de suporte ao cliente a partir das 14h15.

Esta seção contém informações sobre a origem do incidente e o tempo necessário para detectá-lo. Por exemplo, a Zylker examinou seus logs de monitoramento, que revelaram um aumento nas taxas de erro relacionadas a falhas de handshake do SSL às 14h04. Também observou um aumento nas chamadas em seus canais de suporte ao cliente a partir das 14h15.

Avaliação do impacto:

Além disso, a seção de avaliação de impacto enumera o impacto do incidente de TI em diferentes usuários em todas as regiões, bem como nos serviços de TI, aplicações e hardware afetados.

No cenário da Zylker, o processamento de pagamentos e as operações de conta para clientes e comerciantes nos EUA não estavam disponíveis. Além da incapacidade dos servidores Web da Zylker de fornecer tráfego HTTPS, seus componentes de TI, incluindo a aplicação móvel da empresa, seus gateways de API e suas integrações comerciais e de comércio eletrônico, também foram afetados, resultando em falhas nas transações

3.Linha do tempo

Uma sequência detalhada de eventos, da detecção à resolução, junto com seus registros de data e hora, é uma parte essencial de um relatório de incidente. Isso também inclui os eventos preparatórios, as ações de todas as partes interessadas envolvidas e as escalações. Veja como ficou no caso de Zylker:

Para promover melhorias eficazes em sua resposta a incidentes, a Zylker examinou as dependências entre vários eventos para deduzir possíveis gatilhos ou causas básicas e identificar as lacunas existentes.

4. Análise e investigações

Essa é a parte mais importante de um relatório de incidente e lista os fatores subjacentes, de bugs de software a falhas de hardware ou erros humanos, que poderiam ter precipitado o incidente de TI.

Na história da Zylker, suas soluções de monitoramento detectaram um aumento repentino nas taxas de erro de handshake SSL. A empresa descartou fontes do lado do cliente, pois uma mensagem de erro comum foi relatada pelos usuários. Para determinar a causa exata, a empresa investigou as configurações do servidor, como conjuntos de cifras, e examinou a validade do certificado. Este último revelou que seu certificado SSL expirou e não foi renovado.

Ao explorar incidentes anteriores e os fatores causais, a Zylker descobriu vulnerabilidades sistêmicas, incluindo gerenciamento manual de certificados, um CMDB desatualizado e a falta de certificados de backup. Agora, a empresa pode planejar medidas corretivas para evitar tais recorrências.

5. Ações de remediação

Depois de documentar a causa raiz, também é importante registrar as atividades de mitigação e solução de problemas realizadas para restaurar os níveis operacionais normais.

Por exemplo, a Zylker gerou um novo certificado SSL e o implantou em um ambiente de teste para garantir a compatibilidade com seu cenário de TI. Depois de implantar o certificado em seus servidores de produção, a organização examinou o acesso interno e externo aos serviços, ajudando-a a validar o estabelecimento de conexões seguras.

Para superar os gargalos encontrados durante a remediação de incidentes, ela aproveitou as práticas de infraestrutura como código e as ferramentas de teste que podiam simular diferentes condições de carga, garantindo a preparação e o teste perfeitos de certificados SSL.

6. Respostas

Depois de detalhar as ações de remediação, o relatório do incidente também deve apresentar um relato das ações bem-sucedidas e fracassadas. Além disso, ele também deve capturar as melhorias sugeridas, desde a automação de operações até o treinamento de talentos de TI.

Para ilustrar, veja o que a empresa planejou implementar para evitar tais recorrências:

• Envio de notificações oportunas às partes interessadas relevantes 30, 14 e sete dias antes da expiração do certificado
• Automatizar o processo de renovação do certificado
• Configurar mecanismos de backup para recuperar informações essenciais em caso de falha na renovação

Ao documentar ações preventivas e corretivas, a corporação promoveu uma cultura de aprendizado e incorporou as melhores práticas em sua estratégia de gestão de incidentes, permitindo uma adaptação perfeita ao cenário tecnológico em constante mudança.

Assim, com relatórios de incidentes de TI, empresas digitais como a Zylker podem armar suas equipes de TI com uma grande quantidade de insights, desde padrões até medidas preventivas.

Criando um relatório sólido de incidentes de TI com o ServiceDesk Plus

Com o ServiceDesk Plus, as equipes de TI podem reunir informações cruciais, da detecção à resolução, em uma única janela. Elas podem coletar informações abrangentes com modelos de incidentes personalizáveis e, ao mesmo tempo, rastrear detalhes a partir de ferramentas de monitoramento em um ticket. Ao acessar os itens de configuração de dentro do ticket, elas podem avaliar com eficácia o impacto de um incidente. Com esse contexto, elas podem se concentrar na causa raiz com o gerenciamento de problemas. Além disso, elas podem traçar a linha do tempo dos eventos a partir do histórico das operações realizadas. Por fim, elas podem acompanhar as várias tentativas de resolução, garantindo que os esforços futuros sejam bem orientados.

Ao consolidar os detalhes em todo o ciclo de vida de um incidente, o ServiceDesk Plus fornece às equipes de TI informações precisas na ponta dos dedos, facilitando a criação de relatórios sólidos de incidentes de TI. Para entender como o ServiceDesk Plus pode ajudá-lo a se manter à frente da concorrência, solicite uma demonstração personalizada.