Obsidian als Second Brain für DevOps-Engineers

# Obsidian als Second Brain für DevOps-Engineers

Warum DevOps-Engineers ein externes Gedächtnis brauchen

Du hast einen Incident um 2 Uhr nachts behoben. Drei Monate später tritt dasselbe Problem auf — und du weißt nicht mehr, was damals die Lösung war. Du hast ein Runbook geschrieben, irgendwo. Vielleicht in Confluence. Vielleicht in einem Slack-Thread. Vielleicht auf einem Sticky-Note, der längst im Papierkorb liegt.

Das ist kein persönliches Versagen. Das ist ein strukturelles Problem: DevOps-Engineers arbeiten mit einer extremen Informationsdichte — Architekturentscheidungen, Konfigurationsdetails, Postmortem-Erkenntnisse, CLI-Snippets, Monitoring-Alerts, Deployment-Schritte. Unser Gehirn ist nicht dafür gebaut, das alles zu behalten. Es ist dafür gebaut, Muster zu erkennen und Entscheidungen zu treffen.

Die Lösung heißt Second Brain — ein externes, durchsuchbares, vernetztes Wissenssystem, das deinem Gehirn die Last des Erinnerns abnimmt. Und das beste Tool dafür ist Obsidian.

Was ist Obsidian?

Obsidian ist ein lokaler Markdown-Editor mit einem entscheidenden Unterschied zu Notion, Confluence oder OneNote: Deine Daten gehören dir. Keine Cloud, kein Vendor-Lock-in, keine Subscription für Offline-Zugriff. Alle Notizen liegen als plain-text Markdown-Dateien auf deinem Dateisystem — in einem sogenannten Vault.

Was Obsidian von einfachen Editoren unterscheidet:

Bidirektionale Links: Notizen verweisen aufeinander mit [[Notizname]]
Graph-View: Visualisierung des gesamten Wissensnetzes
Dataview-Plugin: SQL-ähnliche Abfragen über deine Notizen
Community-Plugins: über 1.500 Plugins aus der Community
Volltext-Suche: über alle Dateien im Vault

Installation: Linux, macOS, Windows

Linux

Auf Linux empfiehlt sich die Flatpak-Version — sie läuft ohne Root-Rechte und aktualisiert sich automatisch:

# Flatpak installieren (falls nicht vorhanden)
sudo apt install flatpak  # Debian/Ubuntu
sudo dnf install flatpak  # Fedora

# Flathub-Remote hinzufügen
flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

# Obsidian installieren
flatpak install flathub md.obsidian.Obsidian

# Starten
flatpak run md.obsidian.Obsidian

Alternativ steht ein .AppImage und ein .deb-Paket auf obsidian.md/download bereit.

macOS

# Via Homebrew
brew install --cask obsidian

Windows

# Via winget
winget install Obsidian.Obsidian

# Via Chocolatey
choco install obsidian

Vault-Architektur für DevOps

Der erste Fehler beim Start mit Obsidian: einen riesigen Ordner-Baum vorab planen. Tu das nicht. Fang mit einer flachen Struktur an und lass sie sich organisch entwickeln. Hier ist eine bewährte Ausgangsstruktur für DevOps-Engineers:

vault/
├── daily/              # Daily Notes — Journal, Stand-ups
├── knowledge/          # Wiederverwendbares Wissen
│   ├── infrastruktur/  # Netzwerk, Server, Cloud
│   ├── kubernetes/     # K8s-spezifisches Wissen
│   ├── security/       # Security-Findings, Konzepte
│   └── tools/          # CLI-Tools, Konfigurationen
├── projects/           # Aktive Projekte
├── runbooks/           # Operationale Playbooks
├── postmortems/        # Incident-Analysen
├── adrs/               # Architecture Decision Records
├── templates/          # Wiederverwendbare Templates
└── archive/            # Erledigte Projekte, alte Notizen

Kernprinzip: Jede Notiz bekommt einen aussagekräftigen Titel und mindestens einen Tag. Die Verlinkung entsteht durch [[Notizname]] an den Stellen, wo du auf eine andere Notiz verweist. Over time wächst so ein Wissensnetz, das du im Graph-View sehen kannst.

Frontmatter-Konvention

Jede Notiz startet mit YAML-Frontmatter:

---
date: 2026-06-27
tags: [kubernetes, incident, production]
status: active
---

Das status-Feld ist besonders nützlich: active, reference, archived. Mit Dataview kann man dann gezielt nur aktive Runbooks oder offene Projekte anzeigen.

Git-Backup: Dein Vault unter Versionskontrolle

Plain-text Markdown hat einen riesigen Vorteil: Git. Mit dem Obsidian Git-Plugin committet und pusht Obsidian deinen Vault automatisch.

Setup

Vault-Ordner als Git-Repository initialisieren: git init
Remote hinzufügen (GitHub, Gitea, etc.): git remote add origin <URL>
In Obsidian: Community Plugins → „Obsidian Git“ installieren
Plugin-Settings: Auto-Backup alle 10 Minuten, Auto-Pull beim Start

Das Plugin arbeitet im Hintergrund. Du merkst es nicht — bis du merkst, dass du drei Monate alte Versionen einer Notiz recovern kannst.

Multi-Device-Sync

Der Vault liegt in Git → automatisch auf allen Geräten synchronisierbar. Auf dem Handy funktioniert Obsidian Mobile + Obsidian Git ebenfalls — dort nutzt du einen SSH-Key oder HTTPS-Token für den Push.

Wenn du einen self-hosted Gitea-Server hast, lässt sich der Vault dort als privates Repository ablegen — kein Cloud-Anbieter ist in der Lage, deine Notizen zu lesen.

KI-Integration: Claudian und Claude Code

Obsidian wird mit KI-Integration deutlich mächtiger. Das Community-Plugin Claudian (früher: „Companion“) verbindet deinen Vault direkt mit Claude von Anthropic oder mit einem lokalen Modell.

Claudian einrichten

Community Plugins → „Claudian“ installieren
API-Key hinterlegen (Anthropic Console oder lokaler Endpoint)
Provider wählen: Claude API, Ollama (lokal), OpenAI-kompatibel

Claudian kann:

Notizen zusammenfassen
Connections zwischen Notizen vorschlagen
Direkt im Editor Texte generieren oder überarbeiten
Auf den Vault-Kontext zugreifen (RAG über deine Notizen)

Claude Code + obsidian-skills

Wer Claude Code (das Terminal-Tool von Anthropic) nutzt, kann den Obsidian-Vault als Kontext-Quelle einbinden. Das Konzept: Skills und Memory-Dateien im Vault ablegen, die Claude Code automatisch beim Start lädt.

Ein Beispiel aus der Praxis: Im Vault liegt eine claude-memory/-Sektion mit Dateien wie 01-Infrastruktur.md. Claude Code liest diese beim Start — und kennt damit automatisch die Heimnetz-Topologie, aktive Projekte und persönliche Konventionen, ohne dass du jedes Mal neu erklären musst, wie dein Setup aussieht.

Das .agents/skills/-Verzeichnis im Vault kann Obsidian-spezifische Skills für Claude Code enthalten — etwa für das Erstellen neuer Notizen nach definierten Templates oder für die automatische Verlinkung mit bestehenden Notizen.

Templates: Post-Mortem, ADR, Runbook

Die stärkste Zeitersparnis kommt durch Templates. Obsidian hat ein eingebautes Template-System (Core Plugin „Templates“). Hier sind drei Templates, die jeder DevOps-Engineer braucht:

Post-Mortem Template

---
date: {{date}}
tags: [postmortem, incident]
severity: P1 | P2 | P3
status: draft | review | closed
---

# Post-Mortem: {{title}}

## Zusammenfassung
_Ein Satz: Was ist passiert?_

## Timeline
| Zeit | Ereignis |
|------|----------|
| {{time}} | Incident erkannt |
| | Erste Maßnahme |
| | Resolved |

## Root Cause
_Was war die eigentliche Ursache?_

## Contributing Factors
- 

## Impact
- **Betroffene Systeme:**
- **Downtime:**
- **Betroffene User:**

## Was gut lief
- 

## Was verbessert werden kann
- 

## Action Items
- [ ] @Verantwortlicher: Maßnahme — Deadline
- [ ] 

## Lessons Learned
_Was nimmt das Team mit?_

Architecture Decision Record (ADR)

---
date: {{date}}
tags: [adr, architecture]
status: proposed | accepted | deprecated | superseded
---

# ADR-{{number}}: {{title}}

## Kontext
_Warum müssen wir diese Entscheidung treffen?_

## Entscheidung
_Was haben wir entschieden?_

## Begründung
_Warum diese Option?_

## Alternativen betrachtet
- **Option A:** ... — abgelehnt weil ...
- **Option B:** ... — abgelehnt weil ...

## Konsequenzen
### Positiv
- 

### Negativ / Trade-offs
- 

## Verwandte Entscheidungen
- [[ADR-XXX]]

Runbook Template

---
date: {{date}}
tags: [runbook, operations]
service: 
owner: 
last-tested: 
status: active
---

# Runbook: {{Servicename}} — {{Vorgang}}

## Wann dieses Runbook
_Beschreibe den Auslöser: Alert, Symptom, Szenario_

## Voraussetzungen
- [ ] Zugriff auf ...
- [ ] VPN aktiv
- [ ] kubectl-Kontext: `kubectl config use-context ...`

## Schritte

### 1. Diagnose
```bash
# Status prüfen
kubectl get pods -n 
```

### 2. Maßnahme
```bash
# Lösung
```

### 3. Verification
```bash
# Bestätigen dass es funktioniert
```

## Rollback
_Was tun, wenn die Maßnahme nicht hilft oder neue Probleme entstehen?_

## Eskalation
- Primär: @Name (Slack: @handle)
- Sekundär: @Name

## Verwandte Runbooks
- [[Runbook: ...]]

Dataview: Living Documentation

Das Dataview-Plugin verwandelt deinen Vault in eine lebendige Datenbank. Statt statische Dokumente zu pflegen, definierst du Abfragen, die sich automatisch aktualisieren.

Beispiele aus der DevOps-Praxis:

Alle offenen Action Items aus Postmortems

```dataview
TASK FROM #postmortem
WHERE !completed
SORT file.mtime DESC
```

Aktive Runbooks nach Service

```dataview
TABLE service, owner, last-tested
FROM #runbook
WHERE status = "active"
SORT service ASC
```

ADR-Dashboard

```dataview
TABLE status, date
FROM #adr
SORT date DESC
```

Das Ergebnis: Statt manuell gepflegter Wiki-Seiten hast du ein Dashboard, das sich aus dem Inhalt deiner Notizen ergibt. Neue Runbooks erscheinen automatisch in der Liste — du musst nirgendwo „eintragen“.

Obsidian im Homelab: Tipps für self-hosted Setups

Wer ein Homelab betreibt, kann Obsidian noch tiefer integrieren:

Vault auf NAS oder Gitea

Statt GitHub kann der Vault auf einem self-hosted Gitea-Repository liegen. Das Obsidian-Git-Plugin unterstützt Custom-Remotes — einfach die Gitea-URL mit Token als Remote setzen:

git remote add origin https://<user>:<token>@gitea.example.com/<user>/vault.git

Infrastruktur-Dokumentation live halten

Ein nützliches Pattern: Infrastruktur-Notizen bekommen ein status-Feld und ein last-verified-Datum. Dataview zeigt dann alle Notizen an, die seit mehr als 90 Tagen nicht verifiziert wurden:

```dataview
TABLE last-verified, status
FROM #infrastruktur
WHERE date(last-verified) < date(today) - dur(90 days)
SORT last-verified ASC
```

Das ist besonders wertvoll für VPN-Konfigurationen, Firewall-Regeln und DNS-Einträge, die sich selten ändern, aber kritisch sind wenn sie falsch sind.

Passwort- und Secret-Handling

Niemals Passwörter oder API-Keys in den Vault schreiben, wenn der Vault in einem Remote-Repository liegt. Stattdessen: Referenz auf den Secret-Store (vault: homelab/service/credential) und den tatsächlichen Wert in Vault (HashiCorp Vault, Bitwarden, etc.) aufbewahren.

Workflow: Von der Daily Note zur dauerhaften Notiz

Der Alltags-Workflow, der sich für DevOps-Engineers bewährt hat:

Daily Note öffnen (Hotkey: Ctrl+Shift+D) — erste Anlaufstelle für alles
Alles hinschreiben — Meeting-Notes, CLI-Snippets, Erkenntnisse, Todo-Items
Ende des Tages: Daily Note durchgehen und wiederverwendbare Teile in permanente Notizen extrahieren
Verlinken: [[Notizname]] wo Zusammenhänge bestehen
Tags setzen für spätere Dataview-Abfragen

Der Daily-Note-Ordner wird damit zum ersten Entwurf — ein Ort ohne Ordnungszwang. Die permanenten Notizen sind das destillierte Wissen.

Empfohlene Plugins für DevOps

Plugin	Zweck
Dataview	Dynamische Tabellen und Abfragen
Obsidian Git	Automatisches Backup in Git
Templater	Mächtigere Templates (JavaScript-Support)
Claudian	KI-Assistent direkt im Vault
Calendar	Daily Notes als Kalender-Übersicht
Excalidraw	Diagramme und Architekturskizzen inline
Kanban	Aufgabenverwaltung als Board
Advanced Tables	Komfortables Bearbeiten von Markdown-Tabellen

Fazit: Weniger im Kopf, mehr im System

Ein Second Brain ist kein Selbstzweck. Es soll dir ermöglichen, mit vollem Fokus an aktuellen Problemen zu arbeiten — ohne Angst, dabei etwas zu vergessen oder später nicht mehr zu wissen, wie du ein Problem vor sechs Monaten gelöst hast.

Obsidian ist das richtige Tool dafür, weil es:

Plain-text und damit dauerhaft lesbar ist
Git-kompatibel ist und damit versioniert und auf allen Geräten synchronisierbar
Offline-first ist — funktioniert auch ohne Internet
Mit KI-Tools wie Claude integrierbar ist
Durch Plugins an jeden Workflow anpassbar ist

Der Aufwand für den Einstieg ist gering: Obsidian installieren, einen leeren Vault anlegen, eine erste Daily Note öffnen. Der Rest entwickelt sich von selbst — solange du konsequent dokumentierst, was du tust und was du lernst.

Dein zukünftiges Ich wird es dir danken — besonders um 2 Uhr nachts beim nächsten Incident.

Nutzt du Obsidian in deinem DevOps-Workflow? Welche Plugins oder Patterns haben sich bei dir bewährt? Schreib es in die Kommentare.

„` — # Obsidian als Second Brain für DevOps-Engineers ## Warum DevOps-Engineers ein externes Gedächtnis brauchen Du hast einen Incident um 2 Uhr nachts behoben. Drei Monate später tritt dasselbe Problem auf — und du weißt nicht mehr, was damals die Lösung war. Du hast ein Runbook geschrieben, irgendwo. Vielleicht in Confluence. Vielleicht in einem Slack-Thread. Vielleicht auf einem Sticky-Note, der längst im Papierkorb liegt. Das ist kein persönliches Versagen. Das ist ein strukturelles Problem: DevOps-Engineers arbeiten mit einer extremen Informationsdichte. Unser Gehirn ist nicht dafür gebaut, das alles zu behalten. Die Lösung heißt **Second Brain** — ein externes, durchsuchbares, vernetztes Wissenssystem. Und das beste Tool dafür ist **Obsidian**. ## Was ist Obsidian? Obsidian ist ein lokaler Markdown-Editor. **Deine Daten gehören dir** — keine Cloud, kein Vendor-Lock-in. Alle Notizen liegen als plain-text Markdown auf deinem Dateisystem in einem **Vault**. Was Obsidian besonders macht: bidirektionale Links (`[[Notizname]]`), Graph-View, Dataview-Plugin (SQL-ähnliche Abfragen), 1.500+ Community-Plugins, Volltext-Suche. ## Installation **Linux:** „`bash flatpak install flathub md.obsidian.Obsidian „` **macOS:** „`bash brew install –cask obsidian „` **Windows:** „`bash winget install Obsidian.Obsidian „` ## Vault-Architektur „` vault/ ├── daily/ # Daily Notes ├── knowledge/ # Wiederverwendbares Wissen │ ├── infrastruktur/ │ ├── kubernetes/ │ └── security/ ├── runbooks/ ├── postmortems/ ├── adrs/ └── templates/ „` Frontmatter-Konvention für jede Notiz: „`yaml — date: 2026-06-27 tags: [kubernetes, incident] status: active — „` ## Git-Backup Obsidian Git Plugin → automatischer Commit und Push alle 10 Minuten. „`bash git init git remote add origin https://:@gitea.example.com//vault.git „` Multi-Device-Sync läuft darüber — kein proprietärer Cloud-Sync nötig. ## KI-Integration: Claudian + Claude Code Das **Claudian**-Plugin verbindet Obsidian direkt mit Claude. RAG über den eigenen Vault ist möglich. Claude Code kann den Vault als Kontext-Quelle nutzen: Memory-Dateien in `claude-memory/` werden beim Start automatisch geladen. So kennt Claude Code deine Infra-Topologie, Projekte und Konventionen — ohne wiederholtes Erklären. ## Templates ### Post-Mortem „`markdown — date: {{date}} tags: [postmortem, incident] severity: P1 | P2 | P3 — # Post-Mortem: {{title}} ## Timeline | ## Root Cause | ## Action Items „` ### ADR „`markdown — date: {{date}} tags: [adr] status: proposed | accepted — # ADR-{{number}}: {{title}} ## Kontext | ## Entscheidung | ## Alternativen „` ### Runbook „`markdown — date: {{date}} tags: [runbook] service: status: active — # Runbook: {{Service}} — {{Vorgang}} ## Voraussetzungen | ## Schritte | ## Rollback | ## Eskalation „` ## Dataview: Living Documentation „`dataview TASK FROM #postmortem WHERE !completed SORT file.mtime DESC „` „`dataview TABLE service, owner, last-tested FROM #runbook WHERE status = „active“ „` Statt manuell gepflegter Wiki-Seiten: ein Dashboard, das sich aus dem Inhalt der Notizen ergibt. ## Empfohlene Plugins | Plugin | Zweck | |——–|——-| | Dataview | Dynamische Tabellen | | Obsidian Git | Auto-Backup | | Templater | Mächtige Templates | | Claudian | KI-Assistent im Vault | | Excalidraw | Architektur-Diagramme | | Kanban | Task-Board | ## Fazit Obsidian funktioniert, weil es plain-text, git-kompatibel, offline-first und KI-integrierbar ist. Der Einstieg ist minimal — Vault anlegen, erste Daily Note öffnen, konsequent dokumentieren. Dein zukünftiges Ich wird es dir danken — besonders um 2 Uhr nachts beim nächsten Incident.