Gebruik deze sjabloon
Sterke interne infrastructuurdocumentatie beschermt uw bedrijf tegen storingen, audits en beveiligingsincidenten. Met Trupeer kunt u uren besparen op infrastructuurdocumentatie door te beginnen met een gratis template, deze aan te passen met uw brand guidelines en documentatie om te zetten in videowalkthroughs voor IT-teams en MSP's.
De meeste infrastructuurdocumentatie wordt één keer geschreven, tijdens een project, en is binnen zes maanden onjuist. Het blijft op de wiki staan, niemand vertrouwt het, en tijdens het volgende incident leest iemand het, twijfelt, en belt de persoon die het echt weet.
De oplossing is niet meer documentatie. Het is minder documentatie die waarheidsgetrouw wordt gehouden, gekozen door te vragen wat iemand daadwerkelijk nodig zou hebben om drie uur 's nachts.
Download de template voor infrastructuurdocumentatie
Formaat | Het beste voor |
|---|---|
Excel (.xlsx) | De inventaris, dependency matrix, netwerkdetails en een reviewtracker |
Word (.docx) | Runbooks, overzicht van de architectuur en het DR-plan |
Goedgekeurde versies en alles wat auditors opvragen | |
Google Sheets | Een gedeelde inventaris die het team bijhoudt |
Google Docs | Runbooks die worden bewerkt tijdens en na incidenten |
Gratis, bewerkbaar, geen watermark. Excel doet hier het meeste werk, omdat infrastructuurdocumentatie grotendeels gestructureerde data is die zich voordoet als proza.
Welke documentatie heeft u nodig?
U moet documenteren | Gebruik |
|---|---|
Wat er aan infrastructuur bestaat en hoe het is verbonden | Deze template |
IT-processen, beleid en algemene how-to's | |
Een specifiek project | |
Een softwareproduct voor de gebruikers | |
Een IT-procedure | |
Softwarearchitectuur en -ontwerp |
Zo past u deze template aan in Trupeer
Stap 1: Open de sectie Templates
Ga naar de sectie Templates in het hoofdmenu.
Stap 2: Selecteer en open een template
Klik op elke template waarmee u wilt werken om deze te openen.
Stap 3: Breid de templateweergave uit
Indien nodig, breidt u de templateweergave uit om de volledige indeling en details duidelijk te zien.
Stap 4: Bewerk de template
Klik op Bewerken om te beginnen met het aanpassen van de geselecteerde template.
In de editor kunt u:
Nieuwe secties toevoegen
Opmaakregels definiëren of bijwerken
Een logo toevoegen en de positie en bijbehorende instellingen aanpassen
Stap 5: Sla uw aangepaste template op
Nadat u alle noodzakelijke wijzigingen heeft doorgevoerd, klikt u op Opslaan om de bijgewerkte template als uw eigen versie op te slaan.
Stap 6: Bekijk en verfijn de template
Wanneer u wilt zien hoe uw aangepaste template eruitziet, opent u Voorbeeld.
Vanaf het voorbeeldscherm kunt u indien nodig direct verdere aanpassingen blijven doen, zodat de template precies verschijnt zoals u het wilt.
Met een interne template voor infrastructuurdocumentatie kunt u:
Uren besparen op schrijven: Sla de lege pagina over met een structuur die is gebouwd voor IT-infrastructuur.
Beveiligingsniveau verbeteren: Ingebouwde velden zorgen voor veilige omgang met credentials.
In lijn blijven met uw merk: Pas uw logo, lettertypen en kleuren toe met de brand kit van Trupeer.
Downtime verminderen: Duidelijke documentatie verkort MTTR tijdens incidenten.
Klaar zijn voor audits: Afgestemd op SOC 2, ISO 27001 en vergelijkbare frameworks.
Werken met globale teams: Vertaal documentatie naar 65+ talen met één klik.
De test om 3 uur 's nachts
De enige test die telt voor infrastructuurdocumentatie.
Stel u een incident voor om drie uur 's nachts. De persoon die het systeem heeft gebouwd zit in een vliegtuig. Iemand die competent is maar niet bekend is met uw documentatie kijkt ernaar. Kunnen ze achterhalen wat er kapot is, waar het van afhankelijk is, wat er gebeurt als ze het opnieuw opstarten, en wie ze moeten escaleren?
Alles wat daarbij helpt, is het waard om op te schrijven. De rest is optioneel, en optionele documentatie verdunt de nuttige onderdelen en verbruikt het onderhoudsbudget.
Pas het meedogenloos toe. Een gedetailleerde geschiedenis waarom een technologie in 2021 is gekozen, slaagt niet. Een notitie dat deze service moet worden gestart nadat de database is gestart en vóór de API-gateway.
Wat slaagt de test om 3 uur 's nachts
Wat er is. Systemen, servers, services, met wat elk ervan doet in één zin.
Waar het zich bevindt. Cloudprovider en regio, of fysieke locatie en rack.
Waar het van afhankelijk is, en wat ervan afhankelijk is. Het meest waardevolle onderdeel van infrastructuurdocumentatie.
Hoe u het bereikt. Hostnames, adressen, consoles, maar nooit credentials.
Hoe normaal eruitziet. Zodat een onbekende persoon kan zien of iets echt fout is.
Wat het kapotmaakt. Bekende faalmodi en hun symptomen.
Hoe u het veilig opnieuw start, inclusief volgorde en alles wat eerst moet gebeuren.
Wie het beheert, en het escalatiepad met echte contactgegevens.
Wat de impactzone is. Wat er uitvalt als dit uitvalt.
Wat meestal niet slaagt
Geschreven voor volledigheid in plaats van gebruik, en daarom niet de moeite waard om te onderhouden.
Volledige configuratie-dumps die de dag na export al verouderd zijn. Gedetailleerde onderbouwing van eerdere keuzes, wat thuishoort in een architecture decision record en niet in operationele documentatie. Elke parameter van elk systeem wanneer er operationeel maar een paar echt toe doen. Screenshots van consoles, die snel verouderen en zelden helpen. En alles wat elders een bron van waarheid dupliceert, want twee kopieën betekent dat één fout is en u niet kunt zien welke.
Het algemene principe: als het sneller vanuit het systeem te ontdekken is dan uit een document te lezen, documenteer het dan niet.
De infrastructuurinventaris
De basis. Eén rij per systeem of service.
Veld | Vul in |
|---|---|
Naam | Zoals het verschijnt in monitoring en in gesprekken |
Doel | Eén zin, in gewone taal |
Type | Server, service, database, netwerkapparaat, SaaS |
Omgeving | Productie, staging, development |
Locatie | Cloudprovider en regio, of locatie en rack |
Eigenaar | Team, en een benoemd contact voor escalatie |
Kritikaliteit | Tier 1 tot 3, gedefinieerd hieronder |
Afhankelijk van | Wat het nodig heeft om te functioneren |
Waarvan afhankelijk | Wat er kapotgaat als dit stopt |
Toegangsmethode | Console, SSH-bastion, VPN. Geen credentials |
Monitoring | Waar de meldingen naartoe gaan |
Back-up | Frequentie, locatie, laatst geverifieerd herstel |
Runbook | Link |
Laatst geverifieerd | Datum waarop iemand bevestigde dat deze rij waar is |
Het laatste veld is het veld dat de meeste inventarissen overslaan, en het veld dat bepaalt of iemand de documentatie vertrouwt. Een rij die niemand in twee jaar heeft gecontroleerd, moet zichtbaar als onbetrouwbaar worden beschouwd in plaats van stilletjes onjuist te zijn.
Kritikaliteitstiers
Definieer ze, omdat ze bepalen hoeveel documentatie elk systeem verdient.
Tier | Betekent | Verwachte documentatie |
|---|---|---|
1 | Storing stopt het bedrijf | Volledig runbook, getest DR, dependency map, elk kwartaal beoordeeld |
2 | Storing verslechtert een functie | Runbook, dependencies, tweemaal per jaar beoordeeld |
3 | Storing is een dag te verdragen | Alleen inventarisitem en eigenaar |
De meeste organisaties documenteren tier 3 tot dezelfde diepte als tier 1, raken uitgeput, en eindigen met alles half gedocumenteerd. Doe tier 1 goed en laat tier 3 een enkele rij zijn.
Dependencies
Het meest waardevolle en meest verwaarloosde onderdeel van infrastructuurdocumentatie.
Tijdens een incident is de vraag zelden wat er kapot is. Het is wat er nog meer wordt geraakt, en wat deze component nodig heeft om weer terug te komen. Geen van beide is te ontdekken vanuit een lijst met servers.
Documenteer dependencies in beide richtingen:
Systeem | Afhankelijk van | Waarvan afhankelijk | Opstartvolgorde | Mislukt als dependency omlaag gaat |
|---|---|---|---|---|
Order API | Postgres primary, Redis, Auth-service | Webapp, mobiele app, partnerintegraties | Na Postgres en Auth | Ja, direct |
Reporting service | Postgres replica | Alleen interne dashboards | Elke | Verslechtert, levert gecachte data |
Twee dingen maken dit nuttig. De opstartvolgorde, omdat het opnieuw opstarten van dingen in de verkeerde volgorde een kort incident verandert in een lang incident. En of de dependency hard of soft is, omdat een service die geleidelijk verslechtert een heel ander probleem is dan een service die direct faalt.
Neem ook externe dependencies op. Betalingsproviders, identity providers, DNS, certificate authorities en SaaS-API's veroorzaken storingen die u niet kunt oplossen, en weten dat snel is het waard om om drie uur 's nachts te weten.
Netwerkdocumentatie
Element | Documenteer |
|---|---|
Netwerksegmenten | Doel, adresbereik, VLAN |
Routing | Tussen segmenten en naar het internet |
Firewalls | Waar ze staan, wie regels beheert, hoe u een wijziging aanvraagt |
VPN | Endpoints, wie toegang heeft, hoe u toegang aanvraagt |
DNS | Zones, waar ze gehost worden, wie ze kan wijzigen |
Load balancers | Wat er achter elk zit, gedrag van health checks |
Certificaten | Wat ze dekken, vervaldatum, eigenaar van verlenging en methode |
Externe connectiviteit | ISPs, circuits, contactpersonen, contractreferenties |
Het verstrijken van certificaten verdient extra aandacht. Het veroorzaakt storingen die volledig voorspelbaar, volledig te voorkomen en onevenredig vaak waarschijnlijk zijn om in het weekend te gebeuren. Documenteer wat wanneer verloopt, wie het verlengt en of verlenging geautomatiseerd is.
Runbooks
Het document dat iemand tijdens een incident daadwerkelijk opent.
Sectie | Inhoud |
|---|---|
Systeem en eigenaar | Met contact voor escalatie |
Wat dit systeem doet | Eén alinea |
Hoe normaal eruitziet | Metrieken, verwacht gedrag, typische belasting |
Veelvoorkomende meldingen | Wat elke melding betekent en wat u moet doen |
Hoe u het veilig opnieuw start | Stappen, volgorde, vereisten |
Bekende faalmodi | Symptoom, oorzaak, oplossing |
Wat u niet moet doen | De acties die dingen erger maken |
Escalatie | Wanneer en aan wie |
Gerelateerde runbooks | Dependencies |
De sectie "wat u niet moet doen" is zeldzaam en waardevol. Elk volwassen systeem heeft een actie die redelijk lijkt en het incident erger maakt: opnieuw opstarten in de verkeerde volgorde, een cache wissen die zes uur nodig heeft om opnieuw op te bouwen, failover uitvoeren terwijl de secondary achterloopt.
Schrijf runbooks voor tier 1-systemen en voor alles wat al een incident heeft veroorzaakt. Niet voor alles.
Toegang en credentials
De sectie waar documentatie schade veroorzaakt in plaats van het te voorkomen.
Zet nooit credentials in documentatie. Geen wachtwoorden, geen API-sleutels, geen verbindingsstrings met ingesloten secrets, geen private keys. Niet op de wiki, niet in het Excel-bestand, niet "tijdelijk".
Documenteer wél de toegangsmethode. Welk systeem de credential beheert, wie toegang kan verlenen en hoe iemand het aanvraagt om 3 uur 's nachts. Dat is wat de persoon daadwerkelijk nodig heeft, en het is veilig om op te schrijven.
In plaats van | Documenteer |
|---|---|
Het admin-wachtwoord | Credentials in [vault], toegankelijk voor het platformteam, break-glass-procedure in [runbook] |
Een API-key | Key opgeslagen in [secrets manager] als [name], elk kwartaal geroteerd door [owner] |
Een gedeelde login | Toegang via SSO-groep [name], aanvragen via [process] |
Documenteer vervolgens de break-glass-procedure goed, omdat noodtoegang die niet beschikbaar is tijdens een noodsituatie een veelvoorkomende en vermijdbare fout is.
Disaster recovery
Wat DR-documentatie moet bevatten om überhaupt iets waard te zijn.
Recovery time en recovery point objectives per tier 1-systeem, afgestemd met de business in plaats van aangenomen door IT. Wat de recovery-procedure daadwerkelijk is, stap voor stap. Waar back-ups staan en, kritisch, wanneer een restore voor het laatst succesvol is getest. Wie een disaster afkondigt en wie het plan activeert. Hoe het team communiceert wanneer normale systemen down zijn, want een DR-plan dat alleen op de down-systemen is opgeslagen is een bekende blunder.
De belangrijkste regel in elk DR-document is de datum van de laatste succesvolle restore-test. Een back-up die nooit is hersteld is een hypothese.
Diagrammen
Infrastructuur heeft meer baat bij diagrammen dan bij de meeste documentatie, en ze verouderen sneller.
Één high-level diagram met de belangrijkste componenten en hoe ze met elkaar verbonden zijn. Dit is degene die mensen echt gebruiken.
Netwerktopologie, waar de omgeving complex genoeg is om het nodig te hebben.
Datastroom, met name waar het over trust boundaries of jurisdicties heen gaat.
Houd ze simpel. Een diagram dat niemand in één oogopslag kan lezen tijdens een incident is decoratie.
Date ze, en zet de eigenaar erop.
Geef de voorkeur aan diagrammen-as-code als uw team het bijhoudt, omdat een diagram in een versiegecontroleerde tekstindeling met de wijziging wordt bijgewerkt in plaats van erna.
Een verkeerd diagram is slechter dan geen diagram, omdat mensen meer vertrouwen hebben in plaatjes dan in proza.
Bijhouden dat het klopt
Het hele probleem, en de reden waarom de meeste infrastructuurdocumentatie faalt.
Documenteer minder. Nauwkeurigheid schaalt omgekeerd met volume. Vijftien accurate pagina's winnen van tweehonderd verouderde.
Koppel documentatie-updates aan het wijzigingsproces. Een wijziging die infrastructuur aanpast is niet compleet totdat de documentatie het weerspiegelt. Dit is het enige mechanisme dat betrouwbaar werkt.
Automatiseer wat te ontdekken is. Inventaris, adressen, configuraties en topologie kunnen vaak worden gegenereerd. Geautomatiseerde documentatie kan niet verouderen zoals handgeschreven documentatie dat doet.
Schrijf alleen wat niet te ontdekken is. Doel, eigenaarschap, kritikaliteit, dependencies, bekende faalmodi, wat u niet moet doen. Machines kunnen niets van deze dingen afleiden.
Date alles, en zet de datum duidelijk zichtbaar. Een zichtbare laatst-gecontroleerd-datum helpt lezers hun vertrouwen te kalibreren.
Review op schema per tier, elk kwartaal voor tier 1.
Repareer het tijdens incidenten. Het moment waarop iemand ontdekt dat de documentatie onjuist is, is het moment waarop ze de kennis hebben om het te fixen. Maak er een taak van vijf minuten van, geen ticket.
Automatisering en discovery
De moeite waard om in te investeren, omdat het de grootste faalmodus wegneemt.
Configuration management databases, inventarissen van cloudproviders, repositories voor infrastructure-as-code en tools voor netwerkdiscovery kunnen allemaal continu accurate informatie over de huidige status genereren. Alles wat ze kunnen produceren, moet niet handmatig worden bijgehouden.
De splitsing die werkt: machines documenteren wat er is, mensen documenteren wat het betekent. Een automatisch gegenereerde inventaris vertelt u dat een server bestaat en wat erop is geïnstalleerd. Alleen een persoon kan u vertellen dat het degene is die niet tussen 2:00 en 4:00 uur opnieuw mag worden gestart vanwege de batch-run.
Waar infrastructuur als code is gedefinieerd, is de code de documentatie van wat er is. Wat nog moet worden geschreven is de intentie, operationele kennis en de faalmodi.
Wie is eigenaar
Wijs eigenaarschap toe per systeem in plaats van documentatie de taak van één persoon te maken, die het nooit overleeft wanneer die persoon vertrekt.
Het team dat een systeem beheert, is eigenaar van de documentatie ervan. Een benoemd individu is eigenaar van de algemene standaard, de templates en het reviewritme. En het wijzigingsproces dwingt updates af, omdat eigenaarschap zonder mechanisme een intentie is.
Het faalpatroon is een documentatie-eigenaar die iedereen achtervolgt. Dat werkt ongeveer twee maanden.
De documentatie testen
Het equivalent van een restore-test, en net zo verwaarloosd.
Neem iemand die het systeem niet heeft gebouwd, geef alleen de documentatie, en vraag hen om een routine operationele taak uit te voeren. Een gecontroleerde restart, een failover, een restore naar een testomgeving.
Alles wat ze niet kunnen doen op basis van de documentatie is een gat. Alles wat ze verkeerd doen is een defect. Dit is ongemakkelijk en het is de enige betrouwbare manier om te weten of de documentatie om 3 uur 's nachts zou werken, omdat de persoon die het heeft geschreven altijd de gaten uit het hoofd kan aanvullen.
Doe dit minstens jaarlijks voor tier 1-systemen, idealiter als onderdeel van een game day of DR-oefening.
Best practices
Pas de test om 3 uur 's nachts toe op alles voordat u het schrijft.
Documenteer tier 1 goed en tier 3 minimaal.
Dependencies in beide richtingen, met opstartvolgorde.
Nooit credentials, altijd toegangsmethoden.
Laatst-gecontroleerd-datum op elk record.
Automatiseer alles wat te ontdekken is, schrijf alleen intentie en operationele kennis handmatig.
Documentatie-updates afgedwongen door het wijzigingsproces.
Runbooks bevatten wat u niet moet doen.
Restore-tests gedateerd in het DR-plan.
Test de documentatie met iemand die het niet kent, jaarlijks.
Veelvoorkomende fouten
Credentials in de wiki.
Alles gedocumenteerd tot dezelfde diepte, zodat niets wordt onderhouden.
Dependencies gedocumenteerd in slechts één richting.
Geen opstartvolgorde, waardoor herstel langer duurt dan de storing.
Configuratie-dumps die bij aankomst al verouderd zijn.
Diagrammen zonder datum en zonder eigenaar, die lang worden vertrouwd nadat ze niet meer kloppen.
Documentatie als projectdeliverable, nooit daarna bijgewerkt.
Één persoon is nominaal verantwoordelijk voor alles.
DR-plannen opgeslagen op de infrastructuur die ze dekken.
Back-ups gedocumenteerd, restores nooit getest.
Geen laatst-gecontroleerd-datum, zodat lezers niet kunnen beoordelen wat ze moeten vertrouwen.
Geschreven door de persoon die het heeft gebouwd, getest door niemand.
Leg vast wat alleen de persoon weet die het heeft gebouwd
Open de templates in Trupeer AI, pas uw brand kit toe zodat de documentatie voldoet aan uw standaarden, en bewerk elke sectie direct. De setup staat in de template guide.
Automatisering dekt wat er is. Wat het niet kan vastleggen is de operationele kennis: de volgorde waarin dingen terugkomen, de check die u doet voordat u failover uitvoert, en de reden waarom niemand die service op dinsdag opnieuw start.
Die kennis leeft bij één of twee mensen en verdwijnt wanneer zij vertrekken. Laat ze een failover of een restore doorlopen terwijl u opneemt, en Trupeer AI genereert het geschreven runbook en een ingesproken video walkthrough op basis van dezelfde sessie, in de volgorde waarin ze het echt doen in plaats van de volgorde die ze zich zouden herinneren bij het opschrijven.
Het kost ze ook minder tijd dan schrijven, wat belangrijk is, omdat de reden dat operationele kennis niet wordt gedocumenteerd is dat de mensen die het hebben het drukst zijn. Vertaal het naar 65+ talen voor gedistribueerde teams en houd de set bij in uw knowledge base naast de runbooks.
Leg het vast. Breng het in uw merkstijl. Vertaal het. Trupeer het.
Veelgestelde vragen
Is er een gratis template voor infrastructuurdocumentatie in Word?
Ja. Word bevat de runbooks, het overzicht van de architectuur en het DR-plan, de onderdelen die echt verhalend zijn. Gratis downloaden, geen aanmelding, geen watermark.
Is er een gratis template voor infrastructuurdocumentatie in Excel?
Ja, en Excel doet het meeste werk. Het bevat de systeeminventaris met kritikaliteitstiers en laatst-gecontroleerd-datums, de dependency matrix in beide richtingen, netwerkdetails, tracking van certificaatverval en het reviewschema.
Is er een gratis template voor infrastructuurdocumentatie in PDF?
Ja, als goedgekeurde versies en voor alles wat een auditor of klant wil zien. Houd de werkversies bewerkbaar, omdat infrastructuurdocumentatie die niet snel kan worden bijgewerkt niet wordt bijgewerkt.
Kan ik een gratis template voor infrastructuurdocumentatie downloaden?
Ja, elke indeling is een gratis download zonder account en zonder toeschrijving.
Zijn er gratis templates voor IT-documentatie?
Ja. Deze pagina gaat specifiek over infrastructuur. Voor IT-documentatie in bredere zin, inclusief processen, beleid en how-to-materiaal, zie IT-documentatievoorbeelden en templates, en voor IT-procedures de IT SOP-template.
Is er een IT-documentatie template in Word?
Ja, op de pagina IT-documentatievoorbeelden en templates. Deze pagina is smaller en behandelt de systemen, netwerken en dependencies die uw infrastructuur vormen.
Is er een projectdocumentatie template in Word, gratis om te downloaden?
Ja, op de pagina projectdocumentatie template. Projectdocumentatie behandelt de scope, het plan en de deliverables van een project, terwijl infrastructuurdocumentatie behandelt wat er in productie bestaat, ongeacht welk project het heeft gebouwd.
Wat is IT-infrastructuurdocumentatie?
Een overzicht van de systemen, netwerken, services en dependencies die uw omgeving vormen, samen met de operationele kennis die nodig is om ze te beheren en te herstellen. Het behandelt wat er is, waar wat van afhankelijk is, hoe normaal eruitziet en hoe u reageert wanneer er iets kapotgaat.
Wat moet infrastructuurdocumentatie bevatten?
Een systeeminventaris met eigenaren en kritikaliteit, dependencies in beide richtingen met opstartvolgorde, netwerk- en connectiviteitsdetails, runbooks voor kritieke systemen, toegangsmethoden maar nooit credentials, back-up- en disaster recovery-details inclusief de laatste succesvolle restore-test, en een laatst-gecontroleerd-datum op alles.
Hoe houdt u infrastructuurdocumentatie up-to-date?
Documenteer minder, automatiseer alles wat te ontdekken is en koppel documentatie-updates aan uw wijzigingsproces, zodat een wijziging niet compleet is totdat de documentatie het weerspiegelt. Zet een zichtbare laatst-gecontroleerd-datum op elk record, review op kritikaliteitstier en laat iedereen fouten direct oplossen in plaats van een ticket aan te maken.
Moeten credentials in documentatie worden opgeslagen?
Nee. Geen wachtwoorden, API-sleutels, verbindingsstrings of private keys, in welk systeem dan ook, tijdelijk of anderszins. Documenteer in plaats daarvan welke vault of secrets manager de credential beheert, wie toegang kan verlenen en de break-glass-procedure voor noodgevallen. Dat is wat iemand tijdens een incident daadwerkelijk nodig heeft en het is veilig om op te schrijven.
Hoeveel infrastructuur moet u documenteren?
Zoveel als nodig is om de test om 3 uur 's nachts te doorstaan voor kritieke systemen, en heel weinig voor de rest. Tier 1-systemen hebben volledige runbooks, dependency maps en getest DR nodig. Tier 3-systemen hebben één inventarisrij en een eigenaar nodig. Alles tot dezelfde diepte documenteren is waarom de meeste infrastructuurdocumentatie uiteindelijk verouderd raakt.
Wat is een runbook?
Een operationeel document voor één systeem met wat normaal eruitziet, wat veelvoorkomende meldingen betekenen, hoe u het veilig opnieuw start inclusief volgorde en vereisten, bekende faalmodi, wat u niet moet doen en wanneer u moet escaleren. Het is wat iemand opent tijdens een incident, en het moet worden geschreven voor een competent persoon die niet bekend is met dat specifieke systeem.
Hoe documenteert u dependencies?
In beide richtingen, omdat u tijdens een incident zowel moet weten wat dit systeem nodig heeft als wat er kapotgaat als het stopt. Neem opstartvolgorde op, of elke dependency hard of soft is, en externe dependencies zoals identity providers, DNS en payment processors, die storingen veroorzaken die u niet zelf kunt oplossen.
Hoe vaak moet infrastructuurdocumentatie worden beoordeeld?
Op kritikaliteitstier: elk kwartaal voor tier 1, tweemaal per jaar voor tier 2 en bij wijzigingen voor tier 3. Naast geplande reviews moet het wijzigingsproces updates afdwingen, en iedereen die een fout ontdekt tijdens een incident moet het direct kunnen oplossen.
Hoe weet u of uw documentatie echt werkt?
Test het. Geef iemand die het systeem niet heeft gebouwd alleen de documentatie en vraag hen om een routine operationele taak uit te voeren, zoals een gecontroleerde restart of een restore naar een testomgeving. Alles wat ze niet kunnen is een gat. Dit jaarlijks doen voor tier 1-systemen is het equivalent van een restore-test, en wordt net zo vaak overgeslagen.
Kan ik deze template voor infrastructuurdocumentatie aanpassen?
Ja, elke versie is volledig bewerkbaar. Pas de kritikaliteitstiers en velden aan uw omgeving aan. De twee die u het beste kunt behouden zijn de laatst-gecontroleerd-datum en de mapping van dependencies in beide richtingen, omdat die bepalen of de documentatie wordt vertrouwd en of het helpt tijdens een incident.
