Política de Atualizações
PROCESSO GESTÃO DE MUDANÇAS TI​
1. Introdução
Gerenciamento de Mudanças, conhecido em diversas organizações como GMUD, é parte integrante dos processos de Governança de TI e é um processo que vem trazer segurança e controle para a Gestão da Organização e para seus parceiros e clientes, pois assegura que as atualizações nos serviços da organização ou oferecidos por ela terão continuidade e disponibilidade resguardada por este processo.
2. Propósito
Os principais objetivos deste processo é assegurar que mudanças sejam feitas de forma controlada, bem avaliadas, priorizadas quando necessário, planejadas, testadas, implementadas, documentadas e por último que garanta controle total das mudanças.
O processo de Gestão de Mudanças está inserido nos Frameworks ITIL e COBIT e nas normas ISO 2000 e ISO 27000, conforme abaixo.
- ITIL (IT Infrastructure Library) – Framework de boas práticas para o gerenciamento dos serviços de TI.
- COBIT (Control Objectives for Information and Related Technologies) – Framework de boas práticas para o gerenciamento e governança de TI.
- ISO 20000 – Norma de Gestão e Qualidade dos Serviços de TI.
- ISO/IEC 27000 – Família de normas, onde a mais conhecidas as ISO 27001 e ISO 27002 são relacionadas à segurança de dados digitais ou sistemas de armazenamento eletrônico, onde a ISO 27001 é um modelo focado em determinar, implantar, operar, monitorar, rever, manter e melhorar um Sistema de Gestão da Segurança da Informação e o ISO 27002 estabelece o código de práticas para Segurança da Informação.
3. Escopo
3.1 Tipos de Mudança
Nesse processo estão previstas as mudanças relacionadas a área de Tecnologia da Informação, onde estão previstas as mudanças abaixo.
- Processos de TI – Refere-se a mudanças nos processos gerenciados pela Governança de TI.
- Infraestrutura – Refere-se a mudanças na infraestrutura de aplicações, banco de dados, redes e segurança.
- Sistemas – Refere-se a mudanças nas aplicações (sistemas).
3.2. Impacto
3.2.1. Tipo de Impacto
No processo de Mudança teremos os tipos de impactos definidos conforme abaixo.
- Sem Impacto – Não causa impacto na experiência do usuário.
- Baixo Impacto – Pode gerar alguns segundos de instabilidade.
- Médio Impacto – Pode gerar alguns minutos de instabilidade ou queda.
- Crítico – Necessita de interrupção nos serviços.
3.3. Categoria
Padrão – Mudanças pré-aprovadas sem impacto que são de baixo risco e sem criticidade, realizadas com frequência e seguem um processo documentado.
Normais – Mudanças que oferecem algum tipo de impacto, que necessitam de aprovação e poderão ser planejadas dentro das janelas programadas de releases.
Emergenciais – Mudanças que oferecem algum tipo de impacto,geralmente relacionadas a incidentes críticos ou de alto impacto que a execução não pode aguardar as janelas programadas e poderão ser executadas a qualquer momento mediante aprovação.
3.4. Atividades
Numa descrição breve, estas são as atividades principais do processo de mudança:
- Requisitar formalmente a mudança.
- Classificar o risco da mudança requisitada.
- Avaliar a mudança classificada, de modo a autorizar ou não a sua implantação.
- Planejar ou definir a janela da mudança autorizada.
- Executar a mudança agendada.
- Revisar a mudança após implantação.
3.5. Fluxo do Processo
3.6. Requisição de Mudança (RDM)
A requisição de mudança deverá ser efetuada através do preenchimento do formulário (RDM), com as informações pertinentes à mudança a ser executada no diretório do Google Drive:\Plataforma Gestão\Governança\RDM\Pata do mês correspondente a RDM.
O nome do arquivo (Formulário RDM) deverá conter o código de referência (Task Jira/Ticket Movidesk) no momento da criação e após a criação da RDM no Monday será renomeado adicionando o ID da RDM no nome do arquivo.
O Gestor de mudanças deverá contactar o requisitante da mudança quando necessário para esclarecimentos sobre a requisição de mudança.
A requisição de mudança deverá ser preenchida pelo Solicitante com o apoio do Desenvolvedor responsável pela mudança solicitada e deverá ser efetuada revisão por um Tech-Lead.
Todas as requisições de mudanças, categoria “Normal” , que necessitam de aprovação do comitê de GMUD, deverão ser elaboradas e submetidas para aprovação no máximo até as 10 horas do dia da reunião de Gestão de Mudanças, para que haja tempo hábil para análise e aprovação técnica.
Todas as requisições referentes a melhorias deverão ter o documento funcional preenchido e compartilhado com a equipe de CS com a antecedência de 1 dia para análise e verificação sobre a necessidade de Review e comunicação aos clientes.
Para mudanças que necessitam de review técnica e review funcional, elas devem acontecer antes da reunião de Comitê onde a mudança será apresentada.
3.6.1. Status Requisição Mudança (RDM)
Abaixo os status definidos para cada etapa do processo.
- Em Análise – Requisição criada pelo solicitante.
- Em Aprovação – Requisição aguardando aprovação técnica.
- Em Aprovação GMUD – Requisição aprovada tecnicamente, aguardando aprovação do Comitê de mudanças.
- Aprovada – Requisição Aprovada, planejada e aguardando release.
- Concluída com Sucesso – Mudança aplicada em ambiente de produção com sucesso.
- Concluída com Erros – Mudança aplicada em ambiente de produção com erros, não efetuado rollback.
- Rollback – Mudança aplicada em ambiente de produção e efetuado rollback.
- Cancelada – Requisição que por algum motivo não será mais efetuada.
- Reprovada – Requisição reprovada pelo Comitê de Mudanças.
3.7. Perfis de Acesso & Status
3.8 Gestão de Aprovações (GMUD)
3.8.1 Categoria Normal
Para aprovação das mudanças de categoria “Normal”, são efetuadas reuniões duas vezes na semana, previamente agendadas, onde estão tratadas as mudanças planejadas e emergenciais que estiverem prontas para serem executadas na próxima janela que tenham sido criadas e enviadas previamente às requisições (RDM) dentro do prazo estabelecido.
Para apresentação na reunião, a mudança deve cumprir os requisitos abaixo.
- RDM Preenchida e enviada dentro do tempo estabelecido (3 horas que antecedem a reunião).
- Review Técnica e Review de Negócio quando aplicadas.
- Plano de Testes efetuado e documentado (Plano de Testes).
- Plano de Remediação (Rollback) definido.
- Documentação Técnica da Mudança (Quando se aplica).
3.8.2. Categoria Emergencial
As requisições de mudanças emergenciais não aprovadas como “Emergenciais”, deverão seguir os procedimentos padrão das mudanças de categoria “Normal”.
As mudanças emergenciais que não puderem ser tratadas nas reuniões de comitê programadas, deverão ser levadas para aprovação através do preenchimento do Formulário de RDM e comunicação por e-mail para aprovação aos membros do Comitê e feita a comunicação pelos canais WhatsApp e/ou Discord, que quando necessário o comitê gestor deverá se reunir às 17:00 horas do dia em que a execução da mudança necessita ser executada para aprovação, será criada uma agenda fixa nesse horário para utilização quando necessário.
3.8.3. Categoria Padrão
As mudanças da categoria “Padrão” não estão isentas da criação e envio da requisição de mudança (RDM), que seguem os mesmos padrões das outras categorias de mudança, onde a definição de quem irá executar a release bem como os recursos que participarão deverão estar previamente informados e os nomes informados na requisição de mudança.
O gestor de mudança irá validar se a RDM proposta se enquadra como mudança padrão e caso não se enquadre a requisição de mudança pode ser reprovada.
A requisição de mudança (RDM) deverá ser solicitada com antecedência de 2 horas do seu horário de execução para que haja tempo hábil para análise e revisão da requisição. As releases de mudanças dessa categoria deverão poderão ser executadas dentro das janelas estabelecidas, de segunda-feira a quinta-feira.
Para categorização da RDM como “Padrão”, ela deve atender os requisitos abaixo (check-list).
- Não envolver React
- Não envolver API.
- Não envolver Jobs.
- Não possuir dependência de outra mudança de categoria “Normal”.
- Não implicar em mudança de processo significativa que precise ser avaliada pelos integrantes do comitê.
3.8.4. Aprovação Técnica
No caso das Requisições categoria “Normal”, que necessitam da aprovação do comitê para serem efetuadas, deverão previamente à reunião de comitê, serem aprovadas tecnicamente pelos Tech Leads, lembrando que a aprovação não será válida quando efetuada pelo Tech Lead da Squad solicitante.
No caso das Requisições categoria “Padrão”, que não necessitam da aprovação do comitê para serem efetuadas, podem ser aprovadas pelo próprio Tech Lead da Squad solicitante;
3.9. Plano de Remediação (Rollback)
O Plano de Remediação é um dos fatores cruciais para realização da mudança. Nenhuma mudança deve ser aprovada sem um plano de remediação pronto. Este plano é uma forma de restaurar a situação inicial, especialmente referente a software e a dados.
Porém, algumas mudanças não são reversíveis e, nestes casos, uma abordagem alternativa de remediação é requerida. Normalmente, quando lidamos com mudanças de migração de versão ou troca de servidor, por exemplo, existem vários riscos, ou seja, sinistros que podem ocorrer durante a execução da mudança que podem afetar a todo um cronograma e até mesmo a paralisação de parte ou de todo o negócio.
Justamente por estes motivos existe o Plano de Remediação, pois é de conhecimento dos envolvidos que algo pode dar errado e, se realmente algum sinistro vier ocorrer, já existirá um plano para reverter à mudança ao seu estado original ou alguma redundância estará disponível para contornar a situação. O plano de remediação pode variar a cada modelo de mudança.
3.10. Papéis e Responsabilidades
3.10.1. Papéis Definidos
Teremos definidos três tipos de papéis no processo de Gestão de Mudanças:
- Gerente de Mudança.
- CCM – Comitê de Controle de Mudança.
- CCME – Comitê de Controle de Mudança Emergencial
3.10.2. Gerente de Mudança
Responsabilidades.
Com a colaboração do gerador da mudança, receber, registrar e alocar as propriedades para todas as requisições (Releases) e rejeitar qualquer mudança que seja totalmente impraticável.
- Preparar a agenda de mudanças que serão discutidas no CCM.
- Decidir quem deve participar das reuniões do CCM.
- Presidir as reuniões do CCM.
- Comunicar o planejamento de execução das mudanças aos interessados..
- Relacionar-se com as partes para coordenar a construção, teste e implantação das mudanças.
- Atualizar o log das mudanças em andamento.
- Revisar as mudanças implantadas para verificar se elas atingiram os objetivos propostos.
- Encerrar os registros de mudanças concluídas e produzir relatórios do processo.
3.10.3. CCM (Comitê Controle de Mudança)
O papel do CCM, Comitê Controle de Mudança, é um papel que pode ser criado dependendo da organização, envolvendo as partes interessadas para dar apoio na avaliação da mudança em casos mais complexos e relevantes que o Gerente de Mudança não pode avaliar sozinho a situação.
CCM – Deverão fazer parte do CCM os papéis abaixo.
- Membro infraestrutura.
- (PO) Product Owner.
- Membro Service Desk.
- Coordenação de Desenvolvimento.
- Gestor de Desenvolvimento.
- Gestor / Coordenador CS.
- Gestor de Mudança.
- Líderes Técnicos.
- Pessoa técnica responsável pelas atualizações (Sem obrigatoriedade).
3.10.4. CCME (Comitê Controle de Mudança Emergencial)
CCME – O CCME (Comitê de Controle Emergencial), surge em alguns casos quando existe a necessidade de executar uma mudança emergencial, e está mudança não pode esperar o CCM completo, neste caso surge o corpo conhecido como (CCME), para a Organização será
composto a princípio pelos mesmos papéis do CCM, onde pode ocorrer a não participação de algum membro na decisão sobre a aprovação da mudança emergencial.
3.11. Matriz RACI
3.12. Janelas de Mudanças
3.12.1. Janelas Planejadas
As janelas planejadas para mudanças deverão ocorrer toda quarta e sexta-feira às 06:00, sendo que essa janela pode ser revista pelo comitê caso necessário.
3.12.2. Janelas de Mudanças de Impacto Crítico
Mudanças com impacto crítico com possível indisponibilidade da plataforma, deverão ser executadas nas janelas previamente definidas e comunicadas que ocorrerão sempre com início às 00:00hs.
Lembrando que as mudanças passarão pelo comitê de mudanças, onde será definida a melhor data para a execução da mudança com base em todos os requisitos, impactos e riscos.
3.12.3. Janelas de Mudanças Categoria Padrão e Categoria Emergencial (Que possam Ser planejadas nas janelas do dia)
Horário.
De segunda a quinta-feira às 10:00 e às 15:00 horas.
Executor da Release.
Trabalharemos com uma escala para os executores que deverá ser divulgada semanalmente no canal de release (Discord) e GMUD (Whats App)
Requisitos.
O solicitante da release deverá seguir o padrão de documentação estabelecido.
O Solicitante deve comunicar ao executor da release sobre a necessidade até 2 horas antes do horário da release, mesmo que ainda não esteja tudo pronto, para que o executor possa analisar a mudança e se planejar.
O Solicitante deve comunicar aos envolvidos na release sobre o horário que ela irá ocorrer e solicitar a participação.
Mudanças Emergenciais deverão ter a ciência e aprovação do Comitê de Mudanças, exceto situações em que as mudanças já estejam pré-aprovadas pelo comitê.
A aprovação técnica das RDMs dessa categoria poderá ser efetuada pelo próprio Tech Lead da Squad solicitante.
3.13. Comunicação
A comunicação interna será previamente realizada através das “Reviews” e posteriormente as aprovações nas reuniões de comitê pelo Gestor da Mudança. Quando a mudança a ser implementada for relacionada a melhorias com impacto para os clientes externos, a área de CS será responsável pela comunicação da mudança.
3.14. Recursos Envolvidos na Mudança
Os recursos envolvidos na execução da mudança deverão ser comunicados com antecedência e informado ao Admistrativo quais são os recursos que irão participar da mudança quando envolver atividades fora do horário normal de trabalho.
Deverão participar das atualizações de mudanças (releases), os recursos técnicos envolvidos, o QA, que será responsável pela validação pós release, um recurso de infraestrutura sempre que necessário e uma pessoa de liderança para acompanhar a release. Nos casos de mudanças de alto impacto, também deverá ser definida a equipe responsável pela mudança implantada, que deverá suportar a atualização da mudança na produção.
3.15. Garantia
Durante um período de 30 dias após a implantação da nova mudança, a Squad responsável pela melhoria implementada será responsável por lidar com os incidentes que possam surgir e exigir correções de desenvolvimento.
Quando os erros forem detectados pela Squad responsável pela implementação, eles deverão ser tratados na própria Squad e no caso dos erros serem reportados pelos clientes ou pela área de CS, os erros serão tratados pela Squad responsável pela implementação através do sistema de incidentes Movidesk.
Para as novas funcionalidades que ainda estão em fase de experimentação, ou seja, versões “beta” da solução, a Squad responsável pela entrega da nova solução será encarregada de lidar com as correções e incidentes, sendo responsabilidade do Service Desk os atendimentos somente após a versão da nova solução se tornar oficial.
