Pular para conteúdo

Processo de infraestrutura - OPS

Processo de atendimento de infraestrutura

O processo de atendimento de infraestrutura, ou OPS, tem por objetivo atender chamados de infraestrutura dos projetos da Almaviva Solutions. Esses chamados podem ser abertos por meio de pedidos dos clientes ou por membros dos times de desenvolvimento.

  • OPS: Equipe de infraestrutura responsável por fornecer o suporte técnico necessário para resolver solicitações realizadas pelo time de desenvolvimento ou cliente. Garantem que os ambientes estejam funcionando de forma adequada para que o time de desenvolvimento possa realizar suas atividades. Tipos de atendimento estão descritos na Política de OPS.

  • Cliente: Usuário dos sistemas e responsável pela conta ou licitação.

  • Time de desenvolvimento: Responsáveis pelo desenvolvimento e qualidade dos softwares solicitados pelo cliente. Garantem que as entregas sejam realizadas de acordo com os pedidos do cliente.

  • Gerência de desenvolvimento: Responsável por gerir os contratos e diretrizes acordadas com o cliente. Apoia o time de desenvolvimento nas solicitações realizadas e também a equipe de infraestrutura para garantir o atendimento adequado.

  • Gerência de infraestrutura: Responsável por manter os padrões de atendimento do OPS e apoiar o time nos devidos escalonamentos quando necessário.

Definições

Glossário

  • Board: Local onde serão abertos os chamados para atendimento da equipe de infraestrutura.

  • Card: Ticket aberto para atendimento da esteira de infraestrutura.

  • OPS: Equipe de infraestrutura que fará o atendimento dos cards disponíveis no board.

  • SEV: Classificação de severidade, podendo variar de 1 a 4, sendo 1 a de maior prioridade e 4 a de menor prioridade.

  • SLA: Classificação de atendimento, "Service Level Agreement", que significa "Acordo de Nível de Serviço". Trataremos baseado em prazos de entrega e estão correlacionados com as severidades. Mais detalhes em Política de OPS.

  • Escalonamento: Classificação para escalonar um chamado quando o tratamento do card estiver fora da alçada da equipe de infraestrutura. Mais detalhes em Política de OPS.

Board

O board é uma ferramenta que auxilia no controle das atividades (cards) solicitadas pelo cliente ou time de desenvolvimento, trazendo visibilidade de status de cada tarefa (ticket de atendimento). Também ajuda a identificar os responsáveis, severidade e a classificação do chamado a ser atendido. No board, cada card representa uma solicitação e é composto por colunas, onde cada uma representa um estado:

  • OPEN: Estado inicial. Nesta etapa, os cards fazem parte do backlog de atendimento e serão analisados pela equipe de infraestrutura para adequada classificação e identificação dos responsáveis.

  • ANÁLISE: Nesta etapa, devem ser analisadas as informações contidas no card, a fim de validar se contêm informações suficientes para que o analista siga com o atendimento. Pode ser considerado como backlog do time de infraestrutura.

  • ATENDIMENTO: Nesta etapa, o analista iniciará o atendimento e também deverá inserir as classificações de severidade e outras que considerar necessárias para uma adequada gestão do card.

    • VALIDAÇÃO: Nesta etapa, o analista de infraestrutura devolve o chamado para que o usuário/cliente valide se o chamado foi atendido.

  • CLOSED: Estado final. Aqui se encerra o ciclo de atendimento do card.

Desenho do processo

Desenho geral do processo que detalha os papéis envolvidos, assim como etapas e integrações realizadas.

Processo de infraestrutura

Detalhe do processo

Detalhamento dos Papéis, Entradas, Etapas e Saídas envolvidas no processo.

Solicitação de chamado pelo cliente - Sub-processo

Após a identificação de um possível incidente de infraestrutura avaliado pelo cliente, um chamado para atendimento deverá ser aberto para análise e solução.

  • Cliente.
  • E-mail.
  • Reunião.
  • Identificação do tipo de card: O cliente, identificando a necessidade, poderá acionar diretamente a equipe de infraestrutura.
  • Acionar equipe de infraestrutura pelo canal disponível: O cliente deverá acionar a equipe de infraestrutura através de uma das entradas descritas no item anterior.
  • Solicitação de insumos para composição do chamado.
  • Abertura do card (ticket) para atendimento.

Solicitação de chamado pelo time de desenvolvimento - Sub-processo

Após a identificação de um possível incidente de infraestrutura avaliado pelo time de desenvolvimento, um chamado para atendimento deverá ser aberto para análise e solução.

  • Time de desenvolvimento.
  • Reunião.
  • Abertura de card.
  • Identificação do tipo de card: O time de desenvolvimento, identificando a necessidade, deverá abrir um card no GitLab para que a equipe de infraestrutura possa avaliar o chamado.
  • Acionar equipe de infraestrutura pelo canal disponível: O time de desenvolvimento deverá acionar a equipe de infraestrutura através de uma das entradas descritas no item anterior.
  • Levantamento de insumos para composição do chamado.
  • Abertura do card (ticket) para atendimento realizado pelo próprio time.

Abertura de card no GitLab

Abertura

Os insumos que compõem a abertura do chamado servem para que a equipe de infraestrutura obtenha informações suficientes para uma adequada análise do chamado.

  • Cliente.
  • Time de desenvolvimento.
  • Reuniões de alinhamento e entendimento do chamado.

  • Reunião de alinhamento: O time de desenvolvimento e/ou o cliente deverão, caso necessário, realizar uma reunião de alinhamento para entendimento do card.

  • Coletar insumos: A coleta de insumos deverá ser realizada através de evidências de testes realizados ou mensagens de erros e logs recebidas pela aplicação.

  • Detalhamento de itens complexos: Caso o card a ser avaliado seja complexo, o time de desenvolvimento deverá levantar o máximo de insumos necessários para facilitar a avaliação do time de infraestrutura, como, por exemplo, detalhamento das etapas a serem seguidas para reprodução do cenário; usuários que o cenário ocorre; especificidades para reprodução do cenário. Quanto mais detalhes obtiverem, melhor será o processo de avaliação do chamado.

  • Insumos e evidências mapeadas.
  • Logs e mensagens de erros.

Levantar insumos para compor chamado - Sub-processo

Após a realização dos levantamentos de insumos, é necessário detalhar o card no GitLab.

  • Cliente.
  • Time de desenvolvimento.
  • Reuniões de alinhamento e entendimento do chamado.

  • Reunião de alinhamento: O time de desenvolvimento e/ou o cliente deverão, caso necessário, realizar uma reunião de alinhamento para entendimento do chamado.

  • Coletar insumos: A coleta de insumos deverá ser realizada através de evidências de testes realizados ou mensagens de erros e logs recebidas pela aplicação.

  • Detalhamento de itens complexos: Caso o card a ser avaliada seja complexo, o time de desenvolvimento deverá levantar o máximo de insumos necessários para facilitar a avaliação do time de infraestrutura, como, por exemplo, detalhamento das etapas a serem seguidas para reprodução do cenário; usuários que o cenário ocorre; especificidades para reprodução do cenário. Quanto mais detalhes obtiverem, melhor será o processo de avaliação do chamado.

  • Insumos e evidências mapeadas.
  • Logs e mensagens de erros.

Analisar cards e insumos para atendimento

Analise

Início da análise do time de infraestrutura para seguir com o atendimento do card. Nesta etapa, podem ser identificadas pendências que impedem o card de seguir para atendimento.

  • Time de infraestrutura.
  • Insumos descritos no card.

  • Analisar card: Analisar se o card foi bem descrito e possui os padrões definidos na Política de OPS.

  • Analisar insumos: Analisar se os insumos estão aderentes para um adequado atendimento, possuindo o conteúdo necessário para seguir com a etapa de atendimento.

  • Atualizar cards: Os cards sempre deverão ser atualizados para demonstrar transparência nas etapas do processo de atendimento.

  • Movimentar cards: Caso as etapas de análise do card e dos insumos sejam satisfeitos, o analista deverá mover o card para a coluna de "ATENDIMENTO".

  • Label de pendência: Caso as etapas de análise do card e dos insumos não sejam satisfeitas, o analista manterá o card em análise e deverá inserir o label de "PENDÊNCIA".

  • Card atualizado.
  • Inserção de label de pendência.

Atender Card

Atendimento

Fase em que o analista de infraestrutura realiza o atendimento do card aberto, respeitando as informações que constam na Política de OPS.

  • Time de infraestrutura.
  • Insumos descritos no card.
  • Classificações de Severidade, SLA e, caso necessário, escalonamento.

  • Atender o card: Atender o card respeitando a Política de OPS, que descreve como inserir as devidas classificações de Severidade, SLA e, caso necessário, escalonamento.

  • Inserir labels: Inserir as labels necessárias para a adequada classificação e acompanhamento do card. As labels a serem utilizadas constam na Política de OPS.

  • Atualizar cards: Os cards sempre deverão ser atualizados para demonstrar transparência nas etapas do processo de atendimento, inclusive mantendo o solicitante atribuído no card para adequada notificação.

  • Atualizar cards SEV1 e SEV2: Os atendimentos classificados como SEV1 e SEV2, a equipe de OPS deverá notificar o Gerente do Projeto utilizando @Fulano, para que esse replique o item no chat do google, conforme definido na Política de Comunicação via Chat – SEV1 e SEV2.

  • Movimentar card: Caso o atendimento do card seja satisfatório, o analista deverá mover o card para a coluna de "VALIDAÇÃO".

  • Manter card em atendimento: Caso as etapas de atendimento do card não sejam satisfatórias, o analista manterá o card em Atendimento e deverá inserir o label de "PENDÊNCIA". Essa opção só será permitida em casos em que seja envolvida uma equipe externa, na qual a equipe de infraestrutura não possui ação para ajustes, como, por exemplo, equipes de parceiros como HCL, IBM e Google, ou help-desk de alguma ferramenta.

  • Card atualizado.
  • Inserção de labels e solicitante.

Solicitar validação - Sub-processo

Fase em que o analista de infraestrutura envia para o solicitante do chamado para que o responsável valide se o card foi corrigido.

  • Cliente.
  • Time de desenvolvimento.
  • Time de infraestrutura.
  • Card atendido.

  • Movimentar cards: Caso o atendimento do card seja satisfatório, o analista deverá mover o card para a coluna de "VALIDAÇÃO".

  • Notificar solicitante: Será necessário notificar o solicitante para que valide se o chamado foi corrigido. Essa validação será feita através da própria ferramenta do GitLab, inserindo no campo de comentários após a movimentação do card. Exemplo: @Fulano, por favor, validar se o chamado foi corrigido.

  • Gerenciar pedido de validação: O analista de infraestrutura deverá gerenciar as solicitações de validação. Caso algum SLA seja atingido e o solicitante ainda não tenha respondido, o card poderá ser escalonado ao gestor responsável, seguindo o mesmo modelo de notificação já descrito.

  • Card atualizado.
  • Inserção de labels e solicitante.
  • Inserção de notificações para acionamento do solicitante.

Retorno da validação - Sub-processo

Fase em que o analista de infraestrutura recebe do solicitante do chamado o feedback sobre se o chamado foi resolvido.

  • Cliente.
  • Time de desenvolvimento.
  • Time de infraestrutura.
  • Card validado e respondida pelo solicitante.

  • Notificação do solicitante recebida (Equipe de desenvolvimento): O analista de infraestrutura deve acompanhar os cards em validação, verificando se há respostas enviadas pelo solicitante.

  • Notificação do solicitante recebida (Cliente): O analista de infraestrutura deve acompanhar os cards em validação, verificando se há respostas enviadas pelo solicitante. Quando o solicitante é o cliente, a orientação é que o analista faça outros tipos de acionamento para obter um retorno mais rápido e um melhor acompanhamento.

  • Movimentar cards: Caso o retorno da validação realizada pelo solicitante do card seja satisfatório, o analista deverá mover o card para a coluna de "CLOSED", indicando o fim do atendimento do card.

  • Retornar item para Atendimento: Caso o solicitante informe que o cenário persiste, o card deverá retornar à etapa de Atendimento, e todo o processo deverá ser realizado novamente.

  • Encerramento do card sem resposta: Caso a equipe de infraestrutura notifique o responsável e não obtenha resposta em até 48hrs, o card será fechado por ausência de resposta. Sendo assim, o analista deverá descrever essa informação e mover o card para a coluna de "CLOSED", indicando o fim do atendimento do card.

  • Card atualizado.
  • Inserção de labels e solicitante.
  • Atualização de comentários.

Fechar card

Fechamento

Fase final do atendimento de um card pela equipe de infraestrutura.

  • Time de infraestrutura.
  • Card atualizado.

  • Atualizar cards: O analista de infraestrutura deverá verificar, antes do encerramento do atendimento e do card, se todas as classificações e atualizações foram realizadas adequadamente.

  • Movimentar card: O analista deverá mover o card para a coluna de "CLOSED", indicando o fim do atendimento do card.

  • Card atualizado.
  • Card fechado.

Material de Suporte