Usa questo modello
La via più rapida per ottenere un'eccellente documentazione IT è partire da esempi comprovati. Con Trupeer, puoi risparmiare ore nella stesura della documentazione IT iniziando con esempi e modelli di documentazione IT gratuiti, personalizzandoli con le tue linee guida del brand e trasformando lunghi documenti IT in video guide che ingegneri e team di supporto utilizzeranno davvero.
Ogni team IT dispone di documentazione, ma quasi nessuno se ne fida. Il wiki ha quattrocento pagine, di cui solo tre sono aggiornate, e nessuno sa dire quali siano queste tre.
Questo non è un problema di disciplina. È un problema di progettazione: la documentazione IT descrive sistemi che cambiano continuamente, e la maggior parte di essa è scritta come se descrivesse qualcosa di fisso.
Scarica i modelli di documentazione IT
Formato | Ideale per |
|---|---|
Word (.docx) | Runbook, policy, panoramiche dell'architettura, procedure |
Excel (.xlsx) | Inventari, matrici di dipendenza, registri, tracciamento delle revisioni |
Versioni approvate e tutto ciò che i revisori richiedono | |
Google Documenti e Fogli | Documentazione che il team modifica in modo collaborativo |
Gratuito, modificabile, senza filigrana.
Come personalizzare questo modello in Trupeer
Passo 1: Apri la sezione Modelli
Vai alla sezione Modelli dal menu di navigazione principale.
Passo 2: Seleziona e apri un modello
Fai clic su qualsiasi modello con cui desideri lavorare per aprirlo.
Passo 3: Espandi la vista del modello
Se necessario, espandi la vista del modello per vedere chiaramente il layout completo e i dettagli.
Passo 4: Modifica il modello
Fai clic su Modifica per iniziare a modificare il modello selezionato.
All'interno dell'editor, puoi:
Aggiungere nuove sezioni
Definire o aggiornare le regole di formattazione
Aggiungere un logo e regolarne la posizione e le relative impostazioni
Passo 5: Salva il tuo modello personalizzato
Dopo aver apportato tutte le modifiche necessarie, fai clic su Salva per memorizzare il modello aggiornato come tuo.
Passo 6: Visualizza l'anteprima e perfeziona il modello
Quando vuoi vedere l'aspetto del tuo modello personalizzato, apri l'Anteprima.
Dalla schermata di anteprima, puoi continuare ad apportare modifiche direttamente se necessario, assicurandoti che il modello appaia esattamente come desideri.
Con gli esempi e i modelli di documentazione IT puoi:
Risparmiare ore di scrittura: Parti da strutture collaudate invece che da una pagina bianca.
Coprire ogni elemento IT: Modelli per architettura, runbook, modifiche, sicurezza, DR e SOP.
Rimanere fedele al brand: Applica il tuo logo, font e colori utilizzando il kit del brand di Trupeer.
Inserire i tecnici più velocemente: Associa i documenti a video guide per accelerare l'apprendimento dei nuovi tecnici.
Essere sempre pronto per gli audit: Le sezioni integrate supportano SOC 2, ISO 27001 e audit simili.
Raggiungere team globali: Traduci i documenti IT in oltre 65 lingue con un solo clic.
Le sette categorie della documentazione IT
Categoria | Risposte | Esempi di documenti |
|---|---|---|
Infrastruttura | Cosa esiste e come si connette | Inventario, diagrammi di rete, mappe delle dipendenze |
Operativa | Come eseguirlo e risolverlo | Runbook, procedure, percorsi di escalation |
Di processo | Come viene svolto il lavoro IT | SOP, gestione dei cambiamenti, processo di gestione degli incidenti |
Architettura | Come sono progettate le cose e perché | Diagrammi, registri delle decisioni, standard |
Applicativa | Come funziona il software e come viene utilizzato | Documenti tecnici, riferimenti API, guide utente |
Governance | Le regole | Policy, prove di conformità, controllo degli accessi |
Conoscenza | Come risolvere problemi ricorrenti | Articoli della knowledge base, guide pratiche, FAQ |
La maggior parte dei team ha un po' di tutte e sette le categorie e nessuna copertura completa. Va bene così. Ciò che conta è che le parti critiche di ciascuna siano aggiornate, piuttosto che ogni categoria sia popolata in modo esaustivo.
Tasso di obsolescenza
La proprietà che dovrebbe guidare ogni decisione sulla documentazione IT, e quella su cui nessuno pianifica.
Velocità di obsolescenza | Tipi | Implicazione |
|---|---|---|
Continua | Inventari, configurazioni, indirizzi IP, scadenza dei certificati | Automatizza o accetta che sarà errata |
Per rilascio | Riferimenti API, documenti applicativi, screenshot, istruzioni dell'interfaccia utente | Collega gli aggiornamenti al processo di rilascio |
Per modifica | Runbook, dipendenze, topologia di rete | Collega gli aggiornamenti alla gestione dei cambiamenti |
Lenta | Decisioni sull'architettura, standard, policy, definizioni dei processi | Una revisione annuale è sufficiente |
L'errore sta nel trattare tutte e quattro le categorie allo stesso modo, di solito con una revisione trimestrale di tutto. È un approccio decisamente troppo lento per la prima riga e un sovraccarico inutile per l'ultima.
La conseguenza pratica: per qualsiasi elemento nella prima riga, non gestirlo manualmente. Generalo o non averlo affatto, perché gli inventari scritti a mano risultano errati nel giro di poche settimane, ed essere imprecisi è peggio che non avere documentazione.
Documentazione a rapida obsolescenza
Inventari, configurazioni, indirizzi, versioni, capacità, certificati.
Automatizzala. Gli inventari dei provider cloud, i database di gestione delle configurazioni, i repository infrastructure-as-code, i sistemi di rilevamento e monitoraggio della rete possono generare tutto questo in modo continuo e accurato.
Laddove non puoi automatizzare, riduci al minimo indispensabile che deve essere vero e inserisci una data in evidenza. Un breve elenco con una data di ultima verifica visibile è più utile di uno completo ma senza data, perché i lettori possono valutare il livello di affidabilità.
Non duplicare mai un sistema di registrazione (system of record). Se la console cloud sa quali istanze esistono, non mantenere un elenco parallelo. Due fonti significano che una è errata e nessuno saprà quale.
Documentazione a lenta obsolescenza
Decisioni sull'architettura, standard, policy, definizioni dei processi, il motivo per cui le cose sono come sono.
Questa è la documentazione che vale maggiormente la pena scrivere a mano e che viene scritta meno spesso, perché è la parte che le macchine non possono produrre. Nulla può dedurre il motivo per cui hai scelto un database anziché un altro, perché un servizio non deve essere riavviato tra le 2:00 e le 4:00 o quale vincolo ha guidato un design insolito.
I registri delle decisioni sull'architettura (ADR) sono il formato che vale la pena adottare: cosa è stato deciso, quando, quali erano le alternative e perché. Brevi, datati, mai modificati a posteriori, sostituiti anziché aggiornati. Rispondono alla domanda che consuma più tempo quando arriva un nuovo collaboratore, ovvero "perché è fatto così".
Cosa automatizzare e cosa scrivere
Le macchine documentano | Gli umani documentano |
|---|---|
Cosa esiste | A cosa serve |
Configurazione attuale | Perché è configurato in quel modo |
Topologia e connessioni | Quali dipendenze sono rigide e quali flessibili |
Versioni e livelli di patch | Quali aggiornamenti sono rischiosi e perché |
Chi ha l'accesso | Chi dovrebbe avere l'accesso e come richiederlo |
Cronologia degli avvisi | Cosa significa effettivamente ogni avviso |
Scadenza dei certificati | Chi lo rinnova e come |
La distinzione è netta e merita di essere resa esplicita nei tuoi standard di documentazione. I team che la ignorano finiscono per aggiornare a mano la metà rilevabile automaticamente, senza mai scrivere la metà che solo loro conoscono.
Documentazione dell'infrastruttura
Cosa esiste, dove e come si connette. L'inventario, i dettagli di rete, le dipendenze, la capacità.
Presenta il tasso di obsolescenza più elevato di qualsiasi categoria, quindi automatizza tutto il possibile e scrivi a mano solo le dipendenze, la criticità e lo scopo. Trovi tutti i dettagli nel modello di documentazione dell'infrastruttura interna.
Documentazione operativa
Runbook, procedure di riavvio, percorsi di escalation, risposta agli incidenti, disaster recovery.
La documentazione che viene utilizzata sotto pressione, quindi dovrebbe essere scritta per una persona competente ma non familiare con il sistema, alle tre del mattino. Includi cosa non fare, che è la sezione che evita che un breve incidente si trasformi in uno lungo, e mantienila accessibile quando i sistemi che descrive sono offline.
Documentazione dei processi
Come avviene il lavoro IT: gestione delle modifiche, gestione degli incidenti, evasione delle richieste, provisioning degli accessi, approvvigionamento.
Obsolescenza lenta, quindi una revisione annuale di solito è sufficiente. Il valore sta nella coerenza piuttosto che nell'attualità. Usa il modello SOP IT per le procedure e il modello di processo aziendale per i flussi più ampi.
La gestione del cambiamento merita una particolare attenzione, poiché è anche il meccanismo che mantiene aggiornato il resto della tua documentazione.
Documentazione dell'architettura
Diagrammi, standard, registri delle decisioni, scelte tecnologiche, stato obiettivo.
L'obsolescenza più lenta e il valore a lungo termine più elevato. Un buon diagramma dello stato attuale vale più di cinquanta pagine di descrizione, e un registro delle decisioni che spiega una scelta insolita evita discussioni ricorrenti.
Mantieni i diagrammi abbastanza semplici da essere letti a colpo d'occhio, inserisci la data e preferisci i diagrammi generati da codice (diagrams-as-code) se il team li deve gestire, poiché un diagramma nel controllo versione viene aggiornato insieme alla modifica anziché mesi dopo.
Documentazione dell'applicazione
Documentazione tecnica, riferimenti API, guide all'integrazione, guide utente.
Soggetto a obsolescenza a ogni rilascio, quindi collega gli aggiornamenti al processo di rilascio piuttosto che a un calendario di revisione. Un riferimento API obsoleto anche solo di una versione causa problemi reali a chiunque si integri con te.
Modelli: documentazione tecnica, documentazione software, manuale utente.
Documentazione di governance
Policy, standard, prove di conformità, controllo degli accessi, registri di controllo.
Obsolescenza lenta ma conseguenze gravi in caso di errore, ed è la categoria che con maggiore probabilità verrà esaminata da un soggetto esterno. Applica il controllo di versione a tutto, registra l'approvazione e conserva le versioni superate anziché eliminarle, poiché potrebbe essere necessario mostrare cosa era valido in una determinata data.
Modelli: policy di approvvigionamento IT, policy di protezione dei dati, policy aziendale.
Documentazione della conoscenza
Articoli della knowledge base, guide pratiche, guide alla risoluzione dei problemi, FAQ.
La categoria con il ritorno più evidente, poiché ogni articolo può evitare ticket ripetitivi. Crea articoli basandoti sui dati reali dei ticket piuttosto che su supposizioni, e misura se il volume dei ticket su quell'argomento diminuisce.
Modelli: knowledge base, articolo guida pratica, pagina FAQ.
Governance: chi possiede cosa
La documentazione senza proprietà decade silenziosamente, e un proprietario designato della documentazione che rincorre tutti gli altri funziona per circa due mesi.
Il team che gestisce un sistema possiede la sua documentazione. Non un team dedicato alla documentazione, né la persona che si è trovata a scriverla per prima.
Una sola persona possiede lo standard: modelli, posizione dei file, cadenza delle revisioni, convenzioni di denominazione.
Il processo di modifica impone gli aggiornamenti. Una modifica non è completata finché la documentazione non la rispecchia. Questo è l'unico meccanismo che funziona in modo affidabile su larga scala.
Ogni documento indica un proprietario e una data di revisione, entrambi visibili ai lettori.
Revisioni programmate in base al tasso di obsolescenza, non in modo uniforme.
Dove conservarla
In meno posti rispetto a quelli utilizzati dalla maggior parte delle organizzazioni.
L'errore comune è avere la documentazione sparsa tra wiki, cartelle condivise, sistemi di ticketing, diversi repository e note personali. Nessuno sa dove cercare, quindi si finisce per chiedere a un collega, che è esattamente il risultato che la documentazione dovrebbe evitare.
Scegli una posizione principale e sii rigoroso. Laddove la documentazione appartenga effettivamente ad un altro luogo, come i documenti API nel repository del codice, inserisci un collegamento ad essa dalla posizione principale invece di copiarla.
Assicurati che la documentazione operativa sia raggiungibile quando i sistemi sono offline. Un runbook ospitato sulla stessa infrastruttura che descrive è un problema comune e facilmente evitabile.
Cultura della documentazione
Meccanismi pratici piuttosto che semplici esortazioni.
Rendi l'aggiornamento più rapido del chiedere informazioni. Se per modificare una pagina servono quattro clic e per chiedere a un collega basta un messaggio, le persone preferiranno chiedere.
Consenti a chiunque di correggere qualsiasi cosa. I flussi di lavoro di approvazione per la correzione di un refuso garantiscono che i refusi rimangano.
Correggi durante l'incidente. Il momento in cui qualcuno scopre che la documentazione è errata è il momento in cui ha le conoscenze per correggerla. Rendi questa operazione un compito da due minuti.
Riconoscilo. Il lavoro di documentazione è invisibile nella maggior parte dei colloqui di valutazione delle prestazioni, il che fa capire alle persone cosa viene effettivamente valorizzato.
Non pretendere la documentazione di tutto. Un team a cui viene chiesto di documentare tutto produce solo quantità, e la quantità è ciò che rende la documentazione inaffidabile.
Il comportamento su cui progettare il sistema prevede piccole e frequenti correzioni da parte di molte persone, non grandi sforzi periodici da parte di uno solo.
Come misurarla
Percentuale di sistemi di livello 1 con un runbook aggiornato. Semplice e onesto.
Distribuzione dell'età dei documenti. Quanta parte del patrimonio documentale non è stata verificata da un anno.
Tempo di incidente legato alla documentazione. Quante volte gli incidenti sono stati prolungati da una documentazione mancante o errata, rilevato nelle analisi post-incidente.
Ticket risolti tramite un articolo esistente rispetto a quelli inoltrati al livello successivo.
Tempo di onboarding per i nuovi assunti, su cui la documentazione influisce direttamente.
Modifiche al mese per numero di persone distinte, che misura se la documentazione è un'abitudine condivisa o il lavoro di una sola persona.
Quest'ultimo è il miglior indicatore culturale disponibile. Una documentazione modificata da tre persone è una pratica di team. Una documentazione modificata da una sola persona è una dipendenza.
Il set iniziale
Se parti da zero, questo è l'ordine consigliato.
Inventario dei sistemi con proprietari e livello di criticità. Tutto il resto vi farà riferimento.
Runbook per i sistemi di livello 1. Cosa si rompe, come riavviare, a chi rivolgersi per l'escalation.
Mappa delle dipendenze per i sistemi critici, in entrambe le direzioni.
Accesso ed escalation. Chi contattare, come ottenere l'accesso di emergenza.
Processo di modifica. Il meccanismo che mantiene aggiornato tutto quanto sopra.
Articoli della knowledge base per i dieci argomenti di ticket più frequenti.
Registri delle decisioni sull'architettura (ADR), avviati da oggi anziché ricostruiti a posteriori.
Policy, in base ai requisiti di conformità.
Sei settimane di sforzo concentrato producono i primi quattro punti per la maggior parte degli ambienti di medie dimensioni, e questi quattro coprono la maggior parte di ciò di cui chiunque ha effettivamente bisogno.
Best practice
Suddividi la documentazione in base al tasso di obsolescenza e gestisci ogni categoria in modo diverso.
Automatizza tutto ciò che è rilevabile, scrivi a mano solo ciò che le macchine non possono dedurre.
Non duplicare mai un sistema di registrazione (system of record).
Proprietario e data di ultima verifica visibili su ogni documento.
Aggiornamenti imposti dal processo di modifica.
Un'unica posizione principale, con collegamenti anziché copie.
Documentazione operativa raggiungibile anche quando i sistemi sono offline.
Chiunque può modificare qualsiasi cosa, immediatamente.
Documenta meno, ma mantieni le informazioni reali.
Decisioni sull'architettura registrate nel momento in cui vengono prese, non ricostruite in seguito.
Errori comuni
Tutto viene revisionato con la stessa frequenza.
Inventari scritti a mano che risultano errati nel giro di poche settimane.
Duplicazione di ciò che la console cloud conosce già.
Documentazione intesa come deliverable di progetto, mai più aggiornata dopo il go-live.
La quantità di documenti scambiata per copertura completa.
Assenza di date, per cui i lettori non possono valutare di cosa fidarsi.
Flussi di lavoro di approvazione che rendono le piccole correzioni non convenienti.
Documentazione sparsa in cinque posizioni diverse.
Runbook memorizzati sugli stessi sistemi che descrivono.
Una sola persona formalmente responsabile di tutta la documentazione.
Credenziali inserite direttamente nella documentazione.
Documentato solo ciò che esiste, mai il perché.
La metà che le macchine non possono catturare
Apri i modelli in Trupeer AI, applica il tuo kit del brand in modo che la documentazione sia coerente e modifica direttamente qualsiasi sezione. La configurazione è descritta nella guida ai modelli.
L'automazione copre bene la metà soggetta a rapida obsolescenza. Ciò che non può produrre è la conoscenza operativa: l'ordine in cui ripristinare i servizi, i controlli prima di un failover, il motivo per cui nessuno distribuisce aggiornamenti di venerdì su quel particolare sistema.
Questa conoscenza risiede nella testa di una o due persone, non viene mai scritta perché si tratta dei collaboratori più impegnati che hai, e se ne va quando decidono di lasciare l'azienda.
Chiedi loro di illustrare la procedura durante una registrazione: Trupeer AI produrrà il runbook scritto e una video guida narrata partendo dallo stesso passaggio, catturato nell'ordine in cui lavorano effettivamente piuttosto che in quello che ricorderebbero scrivendo. Questo richiede meno tempo rispetto alla scrittura, ed è l'unico motivo per cui viene fatto.
Traducilo in oltre 65 lingue per i team distribuiti e conserva il set nella tua knowledge base insieme alla documentazione generata.
Registra. Personalizza col brand. Traduci. Trupeerizza.
Domande Frequenti
Esistono modelli di documentazione IT gratuiti?
Sì, in questa pagina e tra i modelli collegati, che coprono infrastruttura, runbook, procedure, architettura, documentazione applicativa, policy e articoli della knowledge base. Tutti gratuiti, senza bisogno di account e senza filigrana.
Esiste un modello di documentazione IT in Word?
Sì. Word è adatto per i documenti narrativi: runbook, procedure, panoramiche dell'architettura e policy. Excel è ideale per gli inventari, i registri e le matrici di dipendenza, che costituiscono la maggior parte del resto.
Posso scaricare modelli gratuiti di documentazione IT?
Sì, ogni formato è scaricabile gratuitamente senza registrazione e senza obbligo di attribuzione.
Esistono modelli gratuiti di documentazione IT in PDF?
Sì, per le versioni approvate e per tutto ciò che devi fornire a un revisore. Mantieni modificabili le copie di lavoro, poiché la documentazione difficile da aggiornare finisce per non essere aggiornata.
Esiste un modello gratuito di documentazione IT in Excel?
Sì, ed Excel svolge il lavoro più importante in questo caso: inventari di sistema con date di criticità e di ultima verifica, matrici di dipendenza, tracciamento delle scadenze dei certificati, registri di accesso e pianificazione delle revisioni.
Esistono esempi e modelli di documentazione IT per studenti?
I modelli sono gratuiti per progetti di studio e corsi. Vale la pena sapere che la documentazione IT reale è diversa dalla maggior parte degli esempi accademici: è più breve, ricca di tabelle e valutata sulla base del fatto che una persona non familiare con il sistema possa usarla durante un incidente, piuttosto che sulla sua completezza. Se stai documentando un progetto per una valutazione, il modello di documentazione di progetto è solitamente il più adatto.
Qual è il miglior modello gratuito di documentazione IT?
L'inventario dei sistemi, perché tutto il resto vi fa riferimento e la maggior parte dei team non ne ha uno aggiornato. Subito dopo, i runbook per i tuoi sistemi più critici. Questi due coprono la maggior parte di ciò di cui chiunque ha effettivamente bisogno durante un incidente.
Cos'è la documentazione IT?
La registrazione della tecnologia di un'organizzazione: cosa esiste, come funziona, come gestirla e risolverla, come viene svolto il lavoro IT e le regole che lo governano. Abbraccia sette categorie, dall'infrastruttura agli articoli della knowledge base, e ciascuna decade a un ritmo diverso.
Quali sono i tipi di documentazione IT?
Sette: infrastruttura (cosa esiste), operativa (come gestirla), di processo (come avviene il lavoro IT), di architettura (progettazione e decisioni), applicativa (software e API), di governance (policy e conformità) e di conoscenza (come risolvere i problemi ricorrenti).
Cosa dovrebbe includere la documentazione IT?
Come minimo, un inventario dei sistemi con proprietari e criticità, runbook per i sistemi critici, mappature delle dipendenze in entrambe le direzioni, informazioni su accessi ed escalation, il processo di modifica e articoli della knowledge base per i ticket più comuni. Aggiungi i registri delle decisioni sull'architettura d'ora in avanti, anziché cercare di ricostruire le decisioni passate.
Come si mantiene aggiornata la documentazione IT?
Suddividila in base alla velocità con cui diventa obsoleta e tratta ogni tipo in modo diverso. Automatizza tutto ciò che è rilevabile, scrivi a mano solo ciò che le macchine non possono dedurre, collega gli aggiornamenti al processo di modifica in modo che una modifica non sia completa finché la documentazione non la rispecchia, inserisci date di ultima verifica visibili su tutto e consenti a chiunque di correggere immediatamente qualsiasi cosa.
Perché la documentazione IT diventa sempre obsoleta?
Perché i sistemi che descrive cambiano senza che nessuno tocchi il documento, e perché la maggior parte dei team documenta in modo globale anziché selettivo. Quantità e accuratezza sono inversamente proporzionali: quindici pagine accurate valgono più di duecento obsolete, e le duecento richiedono più tempo per essere gestite male di quanto le quindici ne richiedano per essere gestite bene.
Chi dovrebbe possedere la documentazione IT?
Il team che gestisce ciascun sistema possiede la relativa documentazione, con una persona che possiede lo standard e la cadenza generale. Un singolo proprietario della documentazione che rincorre tutti gli altri è il modello destinato a fallire, di solito entro un paio di mesi. È il processo di modifica, non una persona, a imporre gli aggiornamenti su larga scala.
Dove dovrebbe essere conservata la documentazione IT?
In un'unica posizione principale, con collegamenti anziché copie laddove i contenuti risiedano effettivamente altrove. L'errore comune è avere la documentazione sparsa tra wiki, cartelle condivise, ticket e repository, così nessuno sa dove cercare e finisce per chiedere a un collega. Assicurati che la documentazione operativa sia raggiungibile quando i sistemi che descrive sono offline.
Quanta documentazione IT è sufficiente?
Quella sufficiente a consentire a una persona competente ma non familiare con il sistema di gestire un incidente su un sistema critico senza ricorrere all'esperto. I sistemi di livello 1 necessitano di runbook completi e mappe delle dipendenze. I sistemi a bassa criticità necessitano di una riga di inventario e di un proprietario. Documentare tutto con la stessa profondità è il motivo più comune per cui la documentazione finisce per diventare obsoleta.
Posso personalizzare questi modelli di documentazione IT?
Sì, tutte le versioni sono completamente modificabili. Adatta i campi al tuo ambiente e mantieni in ogni caso due cose: la data di ultima verifica su ogni record e la distinzione tra ciò che automatizzi e ciò che scrivi a mano.
