No mundo de um engenheiro de confiabilidade do site (SRE),a falha não é apenas uma opção, mas também esperada. Sistemas, aplicativos web, servidores, dispositivos, etc., são todos propensos a problemas de desempenho e paralisações inesperadas em algum momento. É um fato inevitável. Essas falhas inesperadas podem levar a enormes perdas de receita, confiança do cliente e dependendo da indústria, talvez multas. Felizmente, a gestão de incidentes da SRE é uma das principais práticas usadas para limitar a interrupção causada por problemas inesperados. Em um artigo diferente, falamos sobre a engenharia do caos e como as equipes da SRE buscam e testam proativamente falhas para evitar que o pior aconteça. No entanto, como todos sabemos, as questões podem escapar pelas rachaduras. O objetivo é evitar que esses incidentes se tornem falhas em cascata em larga escala. As equipes de SREs e DevOps podem usar esses incidentes para reconstruir melhor e melhorar seus sistemas e serviços.
O que é um incidente?
Antes de investigarmos mais sobre este tema, primeiro temos que discutir o que é um incidente. Onde está a linha traçada entre algo que requer ação imediata versus algo que pode ser investigado mais tarde? Se cada questão fosse classificada como urgente, ninguém obteria qualquer resolução. No contexto da TI (Tecnologia da Informação), um incidente é simplesmente um evento ou problema que interrompe a operação normal ou a qualidade do serviço. Não resultou em uma falha, mas se não for controlada, tem a possibilidade de causar maior impacto aos seus serviços e operações. E eles geralmente acontecem às 2:00 da manhã enquanto você está feliz dormindo e é acordado pelo som do seu telefone disparando. Estamos brincando, claro, mas você sabe que algo é ruim se acontecer tão cedo pela manhã. Nada de bom acontece às 2:00 da .m., especialmente quando estamos falando do setor de TI.
O que é gerenciamento de incidentes?
Agora que falamos sobre o que é um incidente, a gestão de incidentes é o processo pelo qual as equipes resolvem esses eventos e trazem sistemas e serviços de volta ao funcionamento normal. Devemos também observar que o gerenciamento de incidentes é apenas um elemento de um conceito maior conhecido como Gerenciamento de Serviços de TI, ou ITSM. A ITSM define como as equipes projetam, criam e fornecem seus serviços. É muito mais do que apenas suporte a TI. ITSM são as políticas, processos e estrutura por trás do ciclo de vida dos serviços de TI. ITSM é uma das práticas da Biblioteca de Infraestrutura de Tecnologia da Informação, ou ITIL.
A ITIL fornece a estrutura e as diretrizes para a construção de soluções ITSM. Você já pode estar familiarizado com outras frameworks, como Business Process Framework (eTOM), Control Objectives for Information and Related Technologies (COBIT), FitSM, ISO/IEC 20000 e Microsoft Operations Framework (MOF).
O Framework ITSM (IT Service Management, gerenciamento de serviços de TI)
Se recuarmos e apenas focarmos nos elementos dentro da estrutura ITSM por um tempo, existem outros seis componentes que compõem a “roda” ITSM, juntamente com o gerenciamento de incidentes. Embora não entremos em detalhes sobre isso, mas é importante entender como todas essas peças se encaixam junto com a gestão de incidentes.
Catálogo de Serviços
O catálogo de serviços de TI é tipicamente um banco de dados ou recurso que uma organização cria para fornecer aos usuários informações sobre seus serviços e ofertas operacionais. Esses catálogos de serviços fornecem informações úteis sobre serviços atuais e planejados, bem como preços, processo de compra, pontos de contato e outras entregas.
Balcão de Serviços
O service desk pode ser considerado como o ponto de contato entre o prestador de serviços e os usuários, como funcionários internos, stakeholders ou clientes. É o “hub” central onde os usuários vão buscar assistência e serviço. Pela definição da ITIL, o service desk pode assumir a forma de resolução de incidentes ou solicitações de serviço, mas qualquer que seja o caso, o objetivo principal do service desk para fornecer um serviço rápido e eficiente.
Gerenciamento de Problemas
Quando falamos de gerenciamento de incidentes, uma equipe da SRE pode ser capaz de resolver rapidamente um incidente, mas o problema subjacente ainda pode existir e persistir por mais um tempo. O gerenciamento de problemas é o processo pelo qual as causas básicas dos incidentes são permanentemente corrigidas, o que melhora o desempenho a longo prazo e futuras implantações de serviços.
Gestão de Mudanças
Qualquer tipo de mudança, seja sobre novas implantações de serviços ou mudanças pessoais, há sempre um elemento de risco. A gestão de mudanças é o processo de determinar como as mudanças afetarão a implantação do serviço e/ou considerarão os efeitos sobre o próprio negócio. O gerenciamento de mudanças também é às vezes agrupado com a gestão de lançamentos.
Gestão de Ativos
Você não pode virtualizar tudo… ainda. Os serviços de software ainda exigem dispositivos físicos e hardware para que eles funcionem. E as organizações precisam rastrear, gerenciar e atualizar continuamente esses dispositivos para garantir que seus serviços possam funcionar sem problemas. A gestão de ativos também é referida como gerenciamento de ativos de TI, ou ITAM.
Gestão de Conhecimento, Política e Procedimentos
O objetivo da gestão do conhecimento é reduzir a redundância em termos de coleta, revisão e compartilhamento de informações dentro de uma organização. Isso ajuda a melhorar a eficiência e garante que as informações são consistentes, atualizadas e disponíveis.
Lifecyle de Gerenciamento de Incidentes: Processo e Etapas
A resposta de uma organização a um incidente, seja sobre tempo de inatividade, violações de segurança ou ataques cibernéticos, ou mesmo latência prolongada e erros repetidos, é fundamental para o sucesso contínuo do negócio e confiança do cliente ou usuário final. Os SREs devem gerenciar sistemas distribuídos complexos. Embora os benefícios desses sistemas sejam que eles são mais confiáveis, escaláveis e tolerantes a falhas, isso também os torna extremamente complexos, o que pode resultar em tempos de remediação mais longos, pois os problemas são mais difíceis de detectar e identificar. As melhores equipes de gerenciamento de incidentes da SRE aderem a um rigoroso processo de gerenciamento e remediação de incidentes. Embora as etapas e processos reais possam variar entre as organizações, a maioria segue o mesmo caminho básico. Vejamos o processo e as etapas de gerenciamento de incidentes da SRE.
1. Identificação de incidentes
Você não pode corrigir problemas que você não sabe. A identificação do incidente começa com alguma forma de monitoramento ou mecanismo de alerta. Falamos sobre o monitoramento de sistemas distribuídos em um artigo diferente e como isso diz respeito às equipes da SRE. Saber quando e onde ocorre um erro, tempo de inatividade ou latência do aplicativo é um fator crítico para limitar o impacto aos usuários e clientes. No entanto, em alguns casos, um incidente se tornará conhecido através de um bilhete de suporte, um telefonema ou mesmo uma mídia social, o que nunca é uma boa notícia quando os problemas são postados publicamente para todos verem.
2. Registro de incidentes
Qualquer que seja o método de detecção, uma vez identificado um incidente, ele deve ser registrado. O registro de incidentes serve a múltiplos propósitos. Ele garante que há um registro formal que foi apresentado e para revisar as tendências de incidentes mais tarde. Se o mesmo incidente, ou semelhante, aparecer repetidamente, pode ser uma indicação de uma questão mais complexa que precisa ser abordada. Ao registrar um incidente, informações relevantes também estão incluídas, como o estamp, a descrição do incidente e quem descobriu o problema. Quanto mais informações detalhadas, melhor.
3. Categorização de incidentes
Em seguida vem a categorização do incidente com base em fatores como gravidade, urgência ou área funcional impactada. Como registrar o incidente, mais informações são fornecidas podem ajudar mais tarde ao determinar a equipe ou indivíduo certo para atribuir à resposta ao incidente.
4. Priorização de incidentes
Com base na forma como o incidente foi categorizado, o próximo passo é definir o nível de prioridade. Novamente, algumas dessas etapas ocorrem ao mesmo tempo, então, em alguns casos, elas podem ser realizadas ao mesmo tempo. As organizações normalmente usam uma escala simples de baixo, médio ou alto, no entanto, alguns incidentes podem automaticamente se enquadrar em categorias específicas, dependendo do que for impactado. Por exemplo, se o incidente estiver relacionado a uma paralisação, isso automaticamente cairia em alta prioridade.
5. Resposta, resolução e encerramento de incidentes
O último passo é finalmente responder e resolver o incidente para encerrar. Este último passo é mais uma forma de arte do que uma ciência. Não há botão fácil aqui. Pode levar vários ciclos e tenta confirmar que o incidente está finalmente resolvido. Cada tentativa pode trazer mais informações e teorias adicionais sobre por que o incidente pode estar acontecendo. Isso também pode levar à identificação de outras oportunidades onde as fraquezas podem estar presentes. Uma vez que o incidente tenha sido tratado, é hora de encerrar a solicitação e responder ao usuário original que relatou o incidente.
Autópsias
Após uma resposta a um incidente, é tipicamente uma boa ideia rever os detalhes do incidente na íntegra. Isso é chamado de incidente pós-morte. Determinar quais incidentes requerem uma autópsia são tipicamente decididos pela equipe ou organização, no entanto, as razões permanecem as mesmas. As autópsias ajudam a identificar áreas que podem ser melhoradas, identificar pontos cegos de desempenho e refinar seu processo de resposta a incidentes. Uma autópsia deve resumir todos os aspectos do incidente e incluir os seguintes elementos:
- Resumo de alto nível e cronograma do incidente.
- Análise de causa básica e fonte do incidente.
- Ações tomadas para resolver o incidente e quais foram eficazes ou não eficazes.
- Prevenção futura de incidentes, juntamente com informações adicionais que foram descobertas.
As autópsias são uma das principais regras da cultura SRE. Na verdade, eles chamam de morte sem culpa. A ideia por trás desse conceito é que todos na equipe agiram com as melhores intenções e ninguém é culpado pelo incidente. O foco é identificar por que isso aconteceu e como melhorar o desempenho do sistema em frente. Os erros são uma parte natural da indústria, por isso, em vez de culpar os indivíduos, o foco é criar um sistema mais robusto e resiliente para que as questões nunca mais aconteçam.
Conclusão: SRE Incident Management – Visão geral, técnicas e ferramentas
O gerenciamento de incidentes da SRE é fundamental para manter sistemas, aplicativos, sites e serviços em funcionamento. Os segundos importam, especialmente quando se trata da experiência do usuário. Em grandes sistemas distribuídos, o menor problema poderia causar problemas em cascata. Configurar proativamente os alertas e notificações certos pode ser a diferença quando os problemas acontecem e garantir que o impacto para os usuários seja limitado. Para obter mais informações sobre como a plataforma Dotcom-Monitor se integra com essas ferramentas de gerenciamento de incidentes, visite nossa Base de Conhecimento.
Experimente o Dotcom-Monitor gratuitamente e tenha acesso a todas as soluções, integrações e recursos da plataforma.
