A gestão de mudanças no mundo local tinha um autor: você. Uma plataforma de segurança em nuvem tem três correntes de mudança rodando simultaneamente - a nuvem do fornecedor, que evolui no cronograma do fornecedor; a sua frota de agentes, que atualiza num cronograma que você governa; e a sua política, que muda exatamente quando os seus admins a mudam - e operações maduras as tratam como três disciplinas diferentes em vez de uma ansiedade só. Este artigo separa o que é controle documentado do que é prática de operador, e rotula qual é qual do início ao fim.
Corrente um: a nuvem, na qual você viaja
O lado do serviço - Service Edges, engines, o analytics - é atualizado pela Zscaler, continuamente e em toda a nuvem; essa é a substância do contrato como-serviço. A alavanca do operador aqui é a consciência, e o instrumento documentado são as publicações de release do fornecedor - sumários de release por produto e por ano, e notas de release de nuvem no portal de ajuda. A prática que vale institucionalizar (nossa, declarada como prática): alguém é dono de lê-las, em cadência, com uma pergunta permanente - algo neste ciclo toca a nossa configuração ou os nossos contornos? - porque o incidente mais barato é o que as notas de release previram.
Corrente dois: a frota, que você agenda
O Client Connector é a corrente de mudança que você genuinamente comanda, e o ponto de controle documentado são as Update Settings do portal - o mecanismo que governa qual release a sua frota toma e quando, ao lado dos sumários de release anuais do Client Connector, que dizem o que cada versão muda e com quais problemas conhecidos embarca. Sobre esse mecanismo documentado senta a disciplina que este artigo recomenda como prática, não como semântica do produto: role em anéis - uma população piloto que inclui a própria TI, depois um anel inicial mais largo, depois a frota - com o kit de troubleshooting apontado para o anel piloto e um gatilho de pausa definido. Um agente que encaminha todo o tráfego é o pior lugar para descobrir uma regressão em escala de frota, e as configurações de atualização existem precisamente para que você nunca precise.
Corrente três: a política, que você escreve
Mudança de política é onde o controle de mudanças clássico se aplica com força total, e a plataforma fornece a camada de registro: o Audit Log de Administradores, onde toda mudança - console ou API - aterrissa com autor, interface, timestamp e o diff de antes/depois. As disciplinas que fazem disso um sistema (prática, de novo, declarada como tal): mudanças propostas com o efeito esperado por escrito; a verificação pós-mudança de que o efeito, e só ele, ocorreu; o diff de auditoria como artefato de revisão em vez da prosa do ticket; e os timestamps de mudança guardados onde a linha do tempo do incidente os alcança - porque "o que mudou recentemente" é a primeira pergunta de toda investigação, e esta plataforma sempre sabe responder.
A disciplina composta
As três correntes se encontram num só calendário. Janelas de congelamento - a prática de segurar mudanças de frota e de política em períodos críticos do negócio - governam as correntes dois e três, enquanto a corrente um segue fluindo, que é exatamente por que a consciência da corrente um é um trabalho. Quando um incidente aterrissa, a primeira triagem é qual corrente se moveu: um release de nuvem, uma versão de agente cruzando a fronteira de um anel, ou um diff de política no audit log - três correntes, três suspeitos, uma linha do tempo, e o operador que as mantém separadas encontra a resposta em minutos em vez de reuniões.