- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 02-03-2019 07:33 PM
Mantendo a plataforma atualizada
Uma das vantagens das soluções aPaaS é a facilidade para realizar atualizações, um simples hotfix ou uma migração de versão pode ser instalado logo após o fornecedor disponibilizá-lo.
Com a ServiceNow não é diferente. Neste momento, a versão London Patch 5está disponível para todos os clientes da plataforma. Além disso, eles mantém um plano de atualizações trimestrais, garantindo que todas as instâncias estejam com as correções necessárias para operar. Esse plano é executado mesmo que o cliente não se preocupe muito com a administração das suas instâncias. Quer conferir? Acesse o Hi e veja a change request January 2019 Patching Program, registrada — provavelmente — no dia 17 de dezembro; ela apresenta as atualizações compulsórias do primeiro trimestre deste ano.
Instalando uma nova versão
Embora a sua execução dependa somente de uma solicitação no Hi, a instalação de uma nova release não deve ser tratada de forma simplista. Basta uma olhada rápida no release notes de qualquer versão para notar a quantidade de atualizações.
Acredito que você também deseja explorar as novidades da versão Madrid (já disponível nas instâncias pessoais), mas há algumas perguntas que precisamos responder, antes de solicitar a migração das instâncias de homologação e, principalmente, de produção:
- Quais novidades podemos aproveitar?
- Quais novidades podem acelerar o roadmap da plataforma?
- Quais novidades irão atrapalhar?
- A nova versão quebra alguma customização ou parametrização?
- As integrações serão afetadas?
- É necessário divulgar a nova versão? Será necessário preparar treinamentos ou materiais de apoio?
Nas diversas migrações que participei, aprendi com os melhores profissionais algumas lições que trato como pré-requisitos para que o projeto sejam bem sucedido. Compartilhei essas lições em um encontro do ServiceNow Developers Meetup.
Os feedbacks que recebi após a palestra motivaram a publicação deste artigo. Espero que as lições que aprendi também sejam úteis para você. 😃
Se você trabalha há pouco tempo com a plataforma, sugiro começar pela série de artigos Um tour pelo ServiceNow (partes 1, 2, 3 e 4).
Pré-requisitos para uma migração bem sucedida
1º PASSO: CONSULTE O RELEASE NOTES
por que mexer em algo estável?
Ler o release notes de uma nova versão precisa estar na rotina do System Administrator, Platform Owner, Business Analyst ou qualquer outro papel envolvido na gestão da plataforma ServiceNow dentro da empresa. É através dele que podemos conhecer — em detalhes — as melhorias, novas funcionalidades e novas aplicações.
Este conhecimento é necessário para responder a pergunta:
Quais novidades trarão benefícios para a empresa?
No release notes é possível descobrir como a nova versão acelera o roadmap da plataforma, além de mostrar novas funcionalidades que não imaginávamos utilizar, mas que podem trazer diversos benefícios. Também é possível avaliar se a ServiceNow está trazendo uma solução para algo que você precisou customizar; neste caso, considere voltar para o out-of-the-box, é um trabalho que poupará esforço nas futuras migrações, além de mitigar o risco de incidentes.
Ou seja, responder a pergunta acima é um ponto de partida para justificar — de forma objetiva — o esforço da migração, algo necessário mesmo para early adopters.
Caso a sua empresa considere o ServiceNow uma “ferramenta” para gerenciar chamados e, por isso, tenha terceirizado a gestão, cobre do seu fornecedor esta análise (bom, também sugiro que você procure entender as possibilidades da plataforma, com certeza a sua empresa pode aproveitar melhor o investimento).
MIGRE A SUA PERSONAL DEVELOPMENT INSTANCE
teste as novidades sem medo de quebrar algo
Desde a Jakarta (acho) a ServiceNow disponibiliza a nova versão primeiro para desenvolvedores (as) e entusiastas da plataforma, através da Personal Development Instance (clique aqui e saiba como solicitar uma).
Este é um baita benefício, pois — antes de expor as suas instâncias corporativas — você poderá validar se tudo funciona da forma como está descrito no release notes. Por exemplo, a documentação da versão London citava um plugin para o SAFe, mas a nova aplicação demorou alguns dias para ficar disponível nas instâncias pessoais. Publiquei a dúvida no Community, algo que foi resolvido poucas semanas depois.
Se você deseja avaliar a jornada completa (e tiver tempo disponível), crie duas contas no ServiceNow Developers e…
- Na primeira conta, crie uma instância na nova versão. Teste os recursos mais relevantes, aqueles que você identificou na leitura do release notes.
- Na segunda conta, crie uma instância na mesma versão da sua empresa e solicite a migração. Dê uma olhada nos relatórios gerados pelo Upgrade Monitor e teste novamente os recursos mais relevantes.
Por que ter o trabalho de criar duas instâncias? Há funcionalidades que não funcionarão em instâncias migradas ou estarão disponíveis em uma data mais próxima do lançamento oficial da nova versão (foi o caso do plugin para o SAFe), as duas instâncias te ajudarão a antecipar esta situação.
Quer um exemplo? O release notes da versão Madrid fala sobre novas funcionalidades no processo de Gestão de Problemas, mas você precisa ir no detalhe da documentação para descobrir que alguns recursos estarão disponíveis somente para instâncias provisionadas na nova versão.
MIGRE UMA DAS SUAS INSTÂNCIAS NON-PROD
vai quebrar alguma customização?
Ótimo! Você já conhece e explorou as novidades da nova versão. Agora é hora do pré-rock’n’roll (a.k.a. 1º ensaio da migração😞 Migre uma das suas instâncias non-prod.
Embora a ServiceNow sugira que você não faça este tipo de teste em uma instância de homologação, não vejo grandes problemas em usá-la temporariamente como sandbox, desde que alguns passos sejam observados:
- Defina o prazo que a instância estará na nova versão (recomendo que não ultrapasse 15 dias);
- Isolar o acesso ao ambiente e comunicar os usuários;
- Garantir que todos os update sets em validação foram concluídos e instalados na instância de produção;
- Definir as etapas para equalizar as instâncias, contemplando as integrações, o MID Server e outras coisas que precisam funcionar na instância de homologação.
Com esta abordagem, o time de desenvolvimento pode continuar trabalhando nas parametrizações e customizações da plataforma, em paralelo com as validações no espaço (temporariamente) alocado como sandbox.
Agora é hora de validar os novos recursos e, principalmente, confirmar se as customizações e integrações funcionam corretamente. Invista um bom tempo para analisar as informações do Upgrade Monitor, especialmente os skipped records; a correção dos itens críticos pode influenciar o prazo (e o sucesso) da migração. A análise requer conhecimento técnico, então você precisa contar com um arquiteto ou desenvolvedor, especialistas na plataforma ServiceNow (caso você não seja essa pessoa).
Aproveite o momento para explorar as novidades que trarão benefícios para a sua empresa e preparar a ‘venda’ da nova versão para as pessoas que terão que se comprometer com o projeto de migração (donos de processo e gerentes de processo).
No final desta etapa, você terá um plano para upgrade de versão, com o nível de detalhe exigido pela cultura da sua empresa. Este plano será o seu apoio para convencer as pessoas de que a migração é necessária e viável (bom, você é a primeira pessoa que precisa estar convencida disso).
VENDA A NOVA VERSÃO PARA OS POs/BAs
se eles não se engajarem, a migração pode ir para o vinagre
Lá atrás sugeri que todos os envolvidos na gestão da plataforma ServiceNow leiam o release notes. Bom, nem sempre isso vai funcionar (arrisco dizer que que raramente funciona).
A galera está focada no dia a dia, que vai muito além do ServiceNow; é por isso que você — System Administrator ou Platform Owner — terá que apresentar e vender a nova versão para os ‘decisores’ de cada processo. Se vocês usam somente as aplicações de ITSM, provavelmente o público será pequeno, mas a gestão das partes interessadas fica mais complexa quando você inclui outros módulos, como o ITBM, Security Operations, CSM ou aplicações customizadas.
Como eu sugeri no tópico anterior, um plano estruturado é importante, mas a segurança que você transmitir durante a apresentação é o que fará a diferença na hora de convencer as pessoas.
Ah, vale reforçar o óbvio: A galera não vai simplesmente ‘aprovar’ o plano, cada ‘decisor’ terá que dedicar um tempo para testar a sua aplicação; cada um será responsável pela validação do seu processo. É fundamental você deixar isso claro para todos.
Dependendo da empresa, vale promover uma conversa individual, com cada decisor, antes da apresentação geral. Assim você consegue identificar e resolver os questionamentos, aumentando a chance de sucesso.
Todos compraram a ideia? Então agora começa o rock’n’roll. De um lado, a galera testando e registrando bugs (se você tiver poucas customizações, boa parte dos ‘bugs’ serão dúvidas funcionais); do outro lado, o time técnico estará trabalhando nas correções.
Eu poderia dar algumas dicas sobre como você pode conduzir o dia a dia do projeto de migração, mas, para não fugir do assunto, sugiro que dê uma lida na série de textos onde apresento Uma visão prática (e parcial) sobre gestão de projetos.
CRIE O SEU CHECKLIST
quais são as atividades essenciais (e a sequência)?
Sou fã de checklists. Talvez a admiração tenha começado em 2010, quando me aventurei em algumas aulas práticas de avião e conheci esta ferramenta que já evitou milhões de acidentes aéreos.
Um ano depois, conheci o livro Checklist — como fazer as coisas benfeitas; em poucos mais de 200 páginas, Atul Gawande narra a sua aventura para ajudar a Organização Mundial da Saúde a descobrir uma forma de diminuir erros em cirurgias. Contar o final do livro não vai estragar o prazer da leitura: A solução foi um checklist.
Entendendo a importância da ferramenta, a ServiceNow sugere um ‘Upgrade planning checklist’. Vale a pena conhecer, mas usá-lo como guia pode ser muito trabalhoso, pois são mais de 50 passos que provavelmente não se aplicarão ao seu contexto.
Recomendo que você crie o seu checklist. A ideia não é repetir atividades que já estejam sendo controladas em outra ferramenta (cronograma, por exemplo), mas listar questões críticas que fazem parte da quinzena ou semana que antecede o D0 (dia da migração da instância de produção); foque naqueles detalhes que, se forem esquecidos, geram um grande ruído. Dois exemplos de atividades que podem compor o seu checklist:
- Solicitação liberação de acesso ao prédio: D-5
- Comprar comida para o time que irá trabalhar no final de semana da migração: D-1
Converse com o arquiteto e com o desenvolvedor sobre a necessidade de um checklist técnico. Dependendo das customizações, pode ser necessário listar algumas etapas de instalação de update sets, após a migração de versão. Se você não conseguir convencê-los no discurso, conseguirá mostrar a importância do checklist durante os ensaios da migração, nosso próximo item. 😃
ENSAIE A MIGRAÇÃO
treino difícil, jogo fácil
Os gerentes de processo tinham concluído todos os casos de teste. Os update sets já estavam prontos e faríamos o último ensaio, somente para validar o checklist técnico e garantir que estava tudo pronto para a migração, que seria realizada no final de semana seguinte.
Nos ensaios anteriores, a execução de todos os passos demoraram aproximadamente duas horas, por isso, estranhamos a migração não ter sido concluída após quatro horas. Decidimos interromper o processo na oitava hora, obviamente havia um problema.
A ServiceNow investigou o incidente e concluiu que seria necessário atualizar o hardware dedicado a nossa instância. Não daria tempo de realizar um novo ensaio após a correção, mas avaliamos os riscos e decidimos seguir com o plano. A migração foi um sucesso.
Imagine se tivéssemos deixado o ensaio de lado e o incidente com o hardware surgisse no dia da migração. A pressão e o transtorno seriam enormes, além de afetar a credibilidade do time.
Mas o ensaio não serve somente para você evitar situações extremas, é uma maneira de você validar as etapas críticas da migração, garantindo que tudo esteja contemplado no checklist técnico. O tempo consumido em cada etapa será útil para definir a janela de mudança, então não se esqueça de registrá-lo.
APROVEITE A MIGRAÇÃO
#partiunovaversao
Se a lição de casa foi feita com esmero, é hora de curtir com a equipe o momento da migração, mas sempre tendo em mente que alguma coisa pode dar errado. 😃
Sobre alguma coisa dar errado, lembrei de uma situação que enfrentamos na migração da versão Eureka para a Geneva…
A UI15 foi uma das novidades da versão Eureka. No dia da migração (uma madrugada de segunda-feira), todas as etapas técnicas foram concluídas com sucesso, mas a nossa instância estava ‘travada’ na interface anterior. Concluímos que a solução requeria atuação da ServiceNow, por isso, registramos no Hi um incidente de alta prioridade, garantindo suporte imediato. Apesar do susto, deu tudo certo.
Ou seja, o risco de algo dar errado é uma constante, por isso, esteja preparado para tomar (ou influenciar) alguma decisão no calor do momento.
Uma última dica: Não se esqueça de registrar o tempo consumido em cada etapa do checklist, assim será possível comparar aquilo que foi previsto com o que foi realizado. 😉
CELEBRE (E FAÇA A RETROSPECTIVA)
quais são as lições aprendidas? podemos melhorar o checklist?
Sei que a sua rotina é agitada, por isso, é normal ignorar a celebração de uma grande entrega. Os próximos desafios nos aguardam (ou melhor, já começaram), não podemos parar. Mas o esforço para reunir as pessoas e comemorar uma entrega significativa vale a pena. Após um período de trabalho intenso na mesma iniciativa, um momento de distração pode ajudar a unir o time e contribuir com o sucesso do próximo projeto.
Tão importante quanto celebrar é refletir sobre as lições aprendidas, especialmente no caso de uma migração de ServiceNow, algo realizado com frequência (uma a cada 12 ou 18 meses). Há algumas técnicas que podem ajudá-lo nesta tarefa (já usei, com sucesso, a Starfish), mas talvez seja necessário experimentar várias técnicas e dinâmicas até identificar a ideal.
Além das lições aprendidas relacionadas com o trabalho em equipe, considere também a perspectiva técnica. É possível melhorar o checklist?
Não se esqueça que o trabalho não termina com o fim das dinâmicas e reuniões de lições aprendidas, será necessário promover ações e mostrar para todos os desdobramentos.
ESTEJA ENTRE OS MELHORES
esta não é uma frase de autoajuda
Podemos dominar técnicas e ferramentas, mas é o brilhantismo coletivo que fará a diferença no resultado final. Embora algumas práticas corporativas incentivem a criação de heróis, isso não se sustenta. Os heróis costumam surgir durante crises que poderiam ser evitadas, ou seja, é quase uma premiação pela ineficiência.
O produto do brilhantismo coletivo é perene e permite que cada um enxergue a sua contribuição no resultado. Não há heroísmo individual ou de um grupo seleto, mas trabalho em equipe.
Diferentemente do que alguns livros de autoajuda vendem, não existe uma receita de bolo (ou checklist =)) para criar uma equipe excepcional. Quando se trata de pessoas trabalhando juntas, há muitas variáveis para considerar: Cultura individual, cultura corporativa, valores, gestão, entrosamento, características individuais, momento econômico, etc.
Esta compreensão ajuda a evitar frustrações e a direcionar energia naquilo que é relevante. Há coisas que você pode resolver e há aquelas que você pode influenciar (por isso, estude negociação e persuasão), mas há coisas que você não consegue resolver. Sobre as últimas, torço para que não influenciem no resultado do seu projeto.
Sucesso no seu projeto de migração! 😃
Obrigado e um abraço!
- 737 Views
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Excelente artigo.
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Muito bom!
