lessons-learned

Lessons learned

Allgemein

  • nicht nur reaktiv sondern proaktiv agieren: Wer nur Feuer löscht kommt irgendwann nicht mehr nach
  • Doku: am besten ein Wiki an (einer?) zentralen Stelle dokumentieren (single source of truth) aufmachen und Architektur-Entscheidungen dokumentieren. Für Anwendungen gibt es Automatisierung
  • Automatisierung muss leicht lesbar sein UND logisch aufgebaut sein (also idealerweise so etwas wie ansible (YAML) und nicht Code den man nachvollziehen muss (wie z.B. puppet)). imperativ ist leichter zu verstehen als deklarativ.
  • Rechner übersichtlich lassen (ein fremder admin sollte also alles finden können, vor allem init-Skripte usw.)
  • Notfallpläne entwerfen
    • … und testen
  • Fehlersuche
    • alle Informationen sammeln (incl. Fehlermeldungen), dann Thesen bilden und systematisch überprüfen (Versuche dokumentieren!)
    • erst Fehlerbehebung dann optimierung (nicht auf Verdacht rumfummeln)
    • Immer post-mortem machen

networking

IPv4:

  • private IPs nicht aus den meist-benutzen 10.0, 172.16, 192.168.0. → Konflikte!

IPv6:

Allgemein:

  • NAT vermeiden (routing wo immer möglich) → NAT ist kein Zugangsschutz, sondern ein workaround

VPN

  • nur benötigte Routen pushen (Standardgateway umbiegen kann aber dennoch Sinn machen, dann aber auch DNS ändern)
  • betriebssystemunabhängiger Client (quasi nicht möglich außer bei bestimmten IPSec-Ausprägungen), daher muss ein Client (wie z.B. openvpn) auf allen wichtigen Plattformen verfügbar sein

DNS

  • nur öffentliche Domains verwenden (kein .local, keine Erfindungen):
    • split-DNS vermeiden
    • letsencrypt möglich machen
    • Anwendungen später erreichbar machen können (z.B. mit IPv6)
  • nur fully-qualified Adressen verwenden (nicht via Suchdomänen vervollständigte DNS-Records), also nicht „start“ sondern „start.FIRMA.de“. Hintergrund:
    • öffentliche SSL-Zertifikate sind nur auf volle Adressen möglich, private CAs sind oft zu aufwendig
    • eine Suchdomäne ist Kontextabhängig (LAN, VPN) und kann zu Unerwünschten Ergebnissen führen

Monitoring

Grundregeln: 

#1 If you break it, will you even notice?
#2 If you break it, can you fix it?

Quelle: https://blog.koehntopp.info/2015/03/27/go-away-or-i-will-replace-you.html

  • ausnahmslos alle Dienste die irgendjemand benutzt ins monitoring
  • alerting (wer bekommt was?)
    • muss stimmen sonst geht die eine wichtige Meldung unter (E-Mail nicht ideal)
    • unterschiedliche Kanäle: E-Mail, Instant-messenger-Kanal (Kanäle) ggf. sogar für unterschiedliche Zielgruppen (Admins, Entwickler, …)
  • Prioritäten („severity“) → nicht alles ist wichtig … (und nicht für jeden!)
  • ggf. externes monitoring hinzufügen (von anderem Provider) oder sogar monitoring von verschiedenen Netzen aus etablieren
  • Dualstack-Monitoring (falls IPv6 existiert)

Stellenausschreibung

Wie bekommt man die „richtigen“ Leute?

  • viele tools reinbringen, z.B. „wir arbeiten mit proxmox, Grafana, Ceph, Atlassian Tools …“, warum? Ihr wollt Leute die bekommen die gute Tools zu schätzen wissen und das gerne machen bzw. lernen wollen

ihr seid eine Organisation mit hohem technischem Niveau, sprich viel Raum zum lernen und wachsen. D.h. keinen Sachbearbeiter IT der nur noch Lieferanten steuert sondern jemand der hand-on anpacken will.

  • Lernen steht im Vordergrund (fachliche und persönliche Entwicklung und den Besuch von Weiterbildung und Konferenzen)
  • Arbeitszeit (Vertrauensarbeitszeit, Gleitzeit und HomeOffice mit möglichst vielen Tagen)
  • Firmenbeschreibung: kein Marketing bla-bla („eins der führenden Unternehmen …“) sondern erklären wem die Produkte was bringen (Sinnstiftend ist heute „in“)
  • Gehalt (mindestens Marktüblich) oder ausgleichen mit den o.g. Faktoren (Zuschuss für Fitness-studio und Altersvorsorge sind investitionen in den Mitarbeiter)