Modelo gratuito de SOP de TI

Modelo gratuito de SOP de TI

Os SOP de TI documentam os procedimentos padrão que as equipas de TI e de operações seguem — desde a administração de sistemas à resposta a incidentes e à gestão de alterações. Utilize este modelo para registar de forma consistente todos os procedimentos de TI e manter a sua equipa preparada para auditorias.

Os SOP de TI documentam os procedimentos padrão que as equipas de TI e de operações seguem — desde a administração de sistemas à resposta a incidentes e à gestão de alterações. Utilize este modelo para registar de forma consistente todos os procedimentos de TI e manter a sua equipa preparada para auditorias.

Use este modelo

Use este modelo

Os IT SOPs são o que mantém as operações de tecnologia consistentes, seguras e em conformidade. Com a Trupeer, pode poupar horas na escrita de IT SOPs começando com um modelo gratuito de IT SOP, personalizando-o com as suas diretrizes de marca e usando o nosso criador de SOP com IA para transformar cada procedimento num vídeo walkthrough claro.

O que é um IT SOP e o que fica de cada lado

Um procedimento operacional padrão é a sequência escrita para uma tarefa que se repete, destinada a alguém competente mas não especialista, suficientemente específica para que duas pessoas que a sigam produzam o mesmo resultado.

Dois documentos ficam de cada lado e confundem-se com ele constantemente.

Uma policy define uma regra e um limite. Diz que compras acima de um determinado valor precisam de aprovação. Não diz qual é o botão que faz surgir uma ordem de compra. As policies mudam raramente e são aprovadas pela governança. Se se vir a escrever "deve" e "não pode", está a escrever policy, e isso pertence a um documento de policy em vez disso.

Um runbook ou método de procedimento é uma execução única de uma única alteração, muitas vezes com timings, escrito para uma única noite. É consumido e depois arquivado. Um SOP é o elemento reutilizável que o runbook empresta. Quando o trabalho é um cutover único com uma janela de rollback, quer um método de procedimento, não um SOP.

O SOP fica entre eles: a regra está noutro lugar, o calendário está noutro lugar, e o que sobra é como o trabalho é realmente feito, esta semana, nos sistemas que realmente tem.

Se quiser a versão de uso geral deste documento que se aplica a qualquer equipa, o nosso modelo de SOP cobre a estrutura padrão. Esta página explica o que muda quando o procedimento é um procedimento de IT.

O que torna um IT SOP diferente de todos os outros

Os SOPs de restaurantes, os SOPs de RH e os SOPs de armazém descrevem trabalho que uma pessoa continuará a fazer daqui a cinco anos. Alguém vai sempre cumprimentar o cliente e verificar o stock.

Os procedimentos de IT não são assim. A maioria descreve trabalho que uma pessoa deve deixar de fazer. Provisionar uma conta, rodar uma chave, restaurar um ficheiro, redimensionar um volume, limpar uma fila, conceder acesso a uma drive partilhada: cada um destes é uma tarefa que começa a sua vida como um procedimento humano e, se a equipa for boa, termina a sua vida como um script, uma ação de self-service, ou uma definição na plataforma que torna impossível formular a pergunta.

O que significa que uma biblioteca de IT SOPs é duas coisas ao mesmo tempo. É um conjunto de instruções e é um inventário de tudo o que a equipa está a fazer manualmente. O segundo uso é o mais valioso e quase ninguém o explora, porque o modelo não o pede.

Por isso, este modelo adiciona um campo que outros modelos de SOP não têm. Cada procedimento transporta um veredito sobre o seu próprio futuro, e a biblioteca é revista com base nesses vereditos, e não apenas pela exatidão. Uma equipa que escreve quarenta SOPs num ano e apaga doze está a fazer melhor do que uma equipa que escreve quarenta e mantém os quarenta, e o modelo deve tornar isso visível.

Como personalizar este modelo na Trupeer

Passo 1: Abrir a secção de Templates

Vá à secção Templates no menu principal.

Open the Templates section in Trupeer

Passo 2: Selecionar e abrir um modelo

Clique em qualquer modelo com que queira trabalhar para o abrir.

Select and open a template in Trupeer

Passo 3: Expandir a vista do modelo

Se necessário, expanda a vista do modelo para ver o layout completo e os detalhes com clareza.

Expand the template view in Trupeer

Passo 4: Editar o modelo

Clique em Edit para começar a modificar o modelo selecionado.

Edit the template in Trupeer

No editor, pode:

  • Adicionar novas secções

  • Definir ou atualizar regras de formatação

  • Adicionar um logótipo e ajustar a sua posição e definições relacionadas

Passo 5: Guardar o seu modelo personalizado

Depois de fazer todas as alterações necessárias, clique em Save para guardar o modelo atualizado como seu.

Save your customized template in Trupeer

Passo 6: Pré-visualizar e afinar o modelo

Quando quiser ver como fica o seu modelo personalizado, abra a Pré-visualização.

Preview and fine-tune the template in Trupeer

A partir do ecrã de pré-visualização, pode continuar a fazer ajustes diretamente, se necessário, garantindo que o modelo aparece exatamente como o quer.

Com um modelo de IT SOP pode:

  • Poupar horas na escrita: Ignore a página em branco com uma estrutura criada para procedimentos de IT.

  • Manter-se pronto para auditorias: Secções integradas suportam SOC 2, ISO 27001 e auditorias semelhantes.

  • Manter-se alinhado com a marca: Aplique o seu logótipo, fontes e cores usando o brand kit da Trupeer.

  • Formar equipas de IT: Combine SOPs com vídeos de formação em IT.

  • Padronizar procedimentos: Use o mesmo modelo para cada IT SOP.

  • Atingir equipas globais: Traduza IT SOPs para 65+ idiomas com um clique.

O campo de disposição

Três vereditos, registados no cabeçalho, revistos trimestralmente.

Automatizar. O procedimento é determinístico, não tem julgamento e é executado com frequência suficiente para valer o esforço de engenharia. Rotação de chaves, provisionamento de contas a partir de um pedido aprovado, renovação de certificados, verificação de backups, rotação de logs, operações padrão de redimensionamento. Dê-lhe um trimestre-alvo, não uma intenção vaga. O SOP mantém-se ativo até a automatização ser entregue e, depois, o SOP é eliminado em vez de ficar a apodrecer ao lado disso, que é o erro que cria duas fontes de verdade concorrentes.

Entregar ao requerente. O procedimento é determinístico, mas alguém fora da equipa quer que seja feito, e a única razão pela qual o IT está envolvido é que o botão está por trás de uma permissão. Self-service de passwords, pedidos de adesão a grupos, atribuição de licenças, instalações comuns de software. O trabalho aqui não é um script; é um caminho de self-service mais um job aid que torna tudo óbvio. O SOP passa a ser a especificação desse caminho.

Manter humano. Julgamento genuíno, suficientemente raro para que a automatização custe mais do que poupa, ou suficientemente consequente para que uma pessoa deva ser responsável pela decisão. Triagem de incidentes, decisões de capacidade, qualquer coisa que envolva negociar com um fornecedor, qualquer coisa em que a ação correta dependa do estado do negócio e não do estado do sistema.

Para decidir, multiplique a frequência de execução pela duração média para obter horas por ano e, depois, pergunte se algum passo exige um julgamento que uma regra não conseguiria codificar. Sessenta horas por ano sem julgamento é um candidato a automatização apenas pela aritmética. Quatro horas por ano com três chamadas de julgamento mantém-se humano, não importa o quão aborrecido pareça.

A estrutura do modelo

Copie a partir daqui. O bloco do cabeçalho inclui os campos que a maioria dos modelos de SOP omite.

Cabeçalho. Número e título do SOP, escritos com o verbo em primeiro lugar, por exemplo "Restaurar uma mailbox eliminada" em vez de "Processo de restauração de mailbox". Responsável. Revisor. Data de criação. Data da última verificação, o que significa a data em que alguém executou este procedimento pela última vez e confirmou que os passos ainda correspondem à realidade, e não a data em que alguém editou a redação. Disposição e trimestre-alvo. Frequência de execução e duração média. Acesso necessário, indicado como a função ou grupo real. Sistemas envolvidos. Reversível sim ou não.

Gatilho. O evento ou pedido que inicia este procedimento, descrito com tanta precisão que uma pessoa consegue dizer se está no âmbito.

Não executar se. As condições em que o procedimento está errado. Esta secção evita mais incidentes do que os passos por si só.

Pré-requisitos. Acesso, aprovações, informação e tudo o que tem de ser confirmado antes do passo um. Inclua a verificação do consumidor: quais outros sistemas, jobs ou integrações dependem do que está prestes a alterar. Se não conseguir responder a isso, a resposta não é "não"; é "desconhecido".

Passos. Numerados, uma ação por cada, com o resultado esperado ao lado de cada ação. Se um passo não tiver um resultado observável, ou não é um passo ou ainda não decidiu como é o sucesso.

Verificação. Não é uma repetição do último passo. A verificação responde se o resultado aconteceu e tem de abranger o ciclo mais longo que a alteração toca. Batch noturno, atraso de replicação, expiração de cache, agendamento cron, sincronização a jusante. Um procedimento verificado apenas por um teste síncrono foi verificado apenas nos primeiros dez segundos da sua vida.

Rollback. Como desfazê-lo e o ponto a partir do qual já não é possível.

Escalonamento. Quem, por que via, e o que lhes dizer.

Registo de alteração. Data, quem, o que mudou e porquê. Três linhas chegam.

Um exemplo prático e o que custou

A Brightmoor Insurance executou um procedimento chamado "Rodar a chave de assinatura do gateway de pagamento" a cada noventa dias. Seis passos. Tinha sido escrito em 2023 e executado catorze vezes sem incidentes.

Numa terça-feira de março, um engenheiro trabalhou nele às 14:20. Gerar a nova chave no portal do gateway, adicioná-la ao repositório de configuração, implementar a configuração, reiniciar o serviço de pagamento, confirmar que um pagamento de teste tem sucesso no sandbox e revogar a chave antiga. Todos os passos foram concluídos. O pagamento no sandbox teve sucesso. O ticket foi encerrado às 14:35 com uma nota a dizer que a rotação estava concluída.

Às 02:10, o batch noturno de recolha de prémios falhou na autenticação. Usou a mesma chave de assinatura, guardada num ficheiro de configuração separado num servidor que nunca tinha sido migrado para o repositório de configuração, porque esse servidor era anterior à migração e ninguém que fez a migração sabia que existia.

As quatro mil e cento recolhas de débito direto não foram efetuadas. A falha foi detetada às 06:40, quando a equipa financeira fez a reconciliação da manhã. As recolhas foram reprocessadas até às 11:00, mas o processamento da carta noturna já tinha gerado avisos de recolha falhada para todos os clientes afetados, e o centro de contacto fez trezentas e oitenta chamadas nos dois dias seguintes. Quatro pessoas passaram dois dias nisto, além de um envio de pedido de desculpa.

O SOP não estava errado. Cada um dos seus seis passos estava correto e cada um foi seguido. Falhou por duas razões que eram ambas estruturais, e não administrativas. Não tinha um pré-requisito a perguntar quais sistemas consomem esta chave, por isso um segundo consumidor ficou invisível durante três anos. E a sua verificação foi uma chamada ao sandbox, que provou que o serviço de pagamento estava saudável às 14:32 e não provou nada sobre o job do batch que não iria correr durante mais doze horas.

A parte interessante é o que fizeram a seguir. O instinto foi adicionar um sétimo passo. O que fizeram, na realidade, foi construir o inventário de consumidores que o incidente os obrigou a compilar e, assim que esse inventário existiu, a rotação tornou-se automatizável. O procedimento foi entregue como um job agendado no trimestre seguinte e o SOP foi eliminado.

A saída mais valiosa do documento nunca foram as instruções. Foi o inventário de que as instruções afinal precisavam, e o campo de disposição é o que faz com que uma equipa procure isso de propósito, e não depois de uma falha.

Formatos e quais usar para trabalho de IT

A maioria dos guias lista quatro formatos de SOP e deixa-o escolher. Para trabalho de IT, a escolha é mais limitada do que parece.

Passo a passo é o ideal para tarefas operacionais lineares com início e fim conhecidos. Restaurações, provisionamento, rotações, implementações. Este é a maioria dos IT SOPs e o formato que a estrutura acima assume.

Diagrama de fluxo ou árvore de decisão é o ideal para diagnóstico, em que a próxima ação depende do que acabou de encontrar. Triagem de incidentes, falhas de conectividade, investigação de desempenho. Não force isto para uma lista numerada, porque a numeração implica uma sequência que não existe e as pessoas acabam por a seguir mesmo assim.

Checklist é o ideal para confirmação pré-voo e pós-alteração, em que a ordem importa menos do que a completude. Combine-o com um procedimento passo a passo em vez de substituir um.

Hierárquico só faz sentido quando um procedimento realmente se ramifica por ambiente ou nível, e normalmente é um sinal de que tem dois procedimentos a usar um único título.

Escrever um em noventa minutos

Grave o ecrã a fazer a tarefa, a velocidade normal, num sistema real, explicando o que está a verificar à medida que avança. Essa gravação é o rascunho.

Escreva os passos a partir da gravação e, depois, elimine todos os passos em que estava apenas a navegar. Adicione o resultado esperado a cada passo que mantiver. Escreva o gatilho e a secção "não executar se" por último, porque só vai saber o que pertence lá quando os passos existirem.

Depois, entregue a alguém que não tenha feito a tarefa e observe-os a segui-la sem ajudar. Cada lugar em que param é um passo em falta ou um conhecimento assumido. Corrija-os, defina a data da última verificação para hoje e publique.

Noventa minutos é realista para um procedimento que já conhece. Duplicar isso para um procedimento que está a documentar a partir do conhecimento de outra pessoa é normal, e um knowledge transfer SOP ajuda a estruturar essa conversa.

Quais IT SOPs escrever primeiro

Não os que parecem importantes. Escreva os que pontuam alto em três aspetos ao mesmo tempo: executa-se frequentemente, dói quando é feito mal e, atualmente, vive na cabeça de uma única pessoa.

Essa regra costuma revelar o mesmo conjunto inicial. Procedimentos de acesso e identidade, ou seja, entradas, saídas, escalonamento de privilégios e gestão de contas partilhadas. Backup e restauro, que quase todas as equipas documentaram para backup e não para restauro. Declaração e escalonamento de incidentes, incluindo quem tem permissão para o fazer. Passos de alteração e release para o seu sistema mais frequentemente tocado. Rotação de certificados e chaves. Reconstrução de endpoint e entrega de ativos.

As saídas e o restauro são os dois que mais fiavelmente acabam por ficar sem documentação, e são também os dois em que o custo de improvisar é mais alto.

Qualquer coisa que escreva aqui deve apontar para o seu inventário de sistemas, em vez de o descrever. O registo de aplicações e credenciais é o local certo para isso, e a descrição mais ampla do sistema pertence ao seu IT documentation.

Rever a biblioteca

Uma vez por trimestre, sente-se com a lista e faça três perguntas a cada entrada.

Foi verificado nos últimos seis meses, ou seja, alguém o executou de facto. Os procedimentos não verificados são piores do que os que não existem, porque as pessoas confiam neles.

A sua disposição mudou. Um procedimento que era raro no ano passado e agora é semanal passou para o território da automatização.

Foi entregue algo. Conte os SOPs eliminados este trimestre porque o trabalho por trás deles foi automatizado ou entregue. Se esse número for zero por três trimestres seguidos, a biblioteca tornou-se um exercício de arquivo em vez de um conjunto de trabalho.

O que deixar de fora

Capturas de ecrã de coisas que mudam, ou seja, qualquer interface que o seu fornecedor atualiza no seu calendário. Elas datam o documento mais depressa do que as palavras e são a principal razão pela qual as pessoas deixam de confiar num procedimento. Descreva o alvo pelo nome, e não pela posição no ecrã.

Explicações sobre por que o sistema funciona do modo como funciona. A curiosidade genuína é aceitável, mas pertence à documentação, não a um procedimento que alguém está a ler enquanto uma fila fica acumulada.

Regras de aprovação e limites. Isso é policy, e duplicá-las em procedimentos significa atualizar catorze documentos quando um único número muda.

Registar o procedimento em vez de o escrever

A parte mais lenta na construção de uma biblioteca de SOPs não é decidir o que escrever; é a digitação. E um procedimento escrito a partir da memória está sempre a faltar os dois cliques que o autor deixou de notar há anos.

A Trupeer AI transforma uma gravação do ecrã num procedimento documentado, pelo que o método de noventa minutos acima se reduz a uma única passagem. Grave a tarefa uma vez e obtém um guia passo a passo com os passos já escritos, um vídeo para as pessoas que preferem vê-lo e um documento na sua knowledge base, com a sua própria marca.

Registe. Dê marca. Traduza. Trupeer.

O SOP creator foi construído exatamente para isto; documentation mantém os procedimentos e as descrições do sistema juntos, e a tradução significa que uma equipa follow the sun lê o mesmo procedimento no seu próprio idioma. As instruções de configuração estão no document template setup guide.

Perguntas Frequentes

Existe um modelo gratuito de IT SOP em Excel?

O Excel é o recipiente errado para o procedimento e o recipiente certo para a biblioteca. Crie uma folha com uma lista de todos os SOPs, com colunas para título, responsável, data da última verificação, disposição, frequência de execução, horas por ano e trimestre-alvo. Essa folha é o que torna a revisão trimestral possível. Os próprios procedimentos pertencem a algum lugar com histórico de versões e pesquisa.

Existe uma versão para Word, ou um download gratuito de Word doc?

O bloco do cabeçalho e os títulos das secções acima foram escritos para serem colados diretamente no Word ou no Google Docs e usados como a estrutura da sua casa. Não existe um download bloqueado, o que também significa que não há um formulário entre si e o modelo. Guarde a sua versão preenchida como ponto de partida departamental, em vez de a copiar novamente cada vez.

Existe uma versão em PDF?

Exporte o seu próprio ficheiro depois de o procedimento ter sido verificado. O PDF é o ideal para um procedimento que foi aprovado e está a ser distribuído para auditoria, e é o errado para um documento de trabalho, porque um procedimento que ninguém consegue editar fica desatualizado no lugar.

Posso descarregá-lo gratuitamente?

A estrutura, o campo de disposição e o exemplo prático são gratuitos e sem restrições. Use-os, edite-os, coloque-os na sua própria biblioteca de modelos com o seu próprio nome, sem atribuição.

Existe um gerador gratuito de SOP?

Sim, e os geradores são genuinamente úteis para o primeiro rascunho. O SOP creator da Trupeer AI constrói o procedimento a partir de uma gravação do ecrã, o que significa que os passos vêm do sistema e não da sua memória. Independentemente do que usar, as partes que um gerador não consegue fornecer são a disposição, a verificação do consumidor e a janela de verificação, por isso espere ter de adicioná-las manualmente.

Como faço um formato de SOP para a minha equipa?

Escolha uma estrutura, preencha-a para três procedimentos reais e, depois, pare e veja o que teve de fazer o modelo para conseguir expressar. Ajuste uma vez e, depois, congele. As equipas que continuam a refinar o formato nunca acumulam procedimentos, porque cada novo SOP desencadeia um debate sobre a forma do documento em vez do conteúdo do trabalho.

Qual é o melhor modelo de SOP?

O que a sua equipa vai manter verificado. A estrutura importa muito menos do que a responsabilidade e uma data de revisão, e um procedimento simples de seis secções que alguém executou no mês passado supera um elaborado que ninguém abriu desde que foi escrito.

Quanto tempo deve ter um IT SOP?

Um ecrã para os passos na maioria dos casos. Se os passos ultrapassarem cerca de quinze, o procedimento é normalmente dois procedimentos, ou contém navegação que deve ser cortada. O cabeçalho, os pré-requisitos e a verificação podem ser tão longos quanto for necessário, porque são as partes que evitam incidentes.

Com que frequência devem ser revistos os IT SOPs?

Verifique cada procedimento pelo menos de seis em seis meses executando-o e reveja toda a biblioteca trimestralmente com base no campo de disposição. Qualquer coisa que envolva acesso, chaves ou restauros merece um ciclo mais curto, e qualquer procedimento envolvido num incidente deve ser re-verificado antes de o incidente ser encerrado.

Precisa de um editor de vídeo, tradutor e argumentista?

Experimente o Trupeer gratuitamente

Marcar uma demonstração

Precisa de um editor de vídeo, tradutor e argumentista?

Experimente o Trupeer gratuitamente

Marcar uma demonstração

Precisa de um editor de vídeo, tradutor e argumentista?

Experimente o Trupeer gratuitamente

Marcar uma demonstração