Kein neuer Inhalt — eine Kurzform der bereits verifizierten/dokumentierten Ergebnisse aus diesem Projekt, als Gesprächsleitfaden aufbereitet: typische Interview-Fragen zu jedem Anzeigen-Punkt, mit kurzer Antwort + Verweis auf die volle Herleitung. Ziel: laut vorsprechen können, ohne die komplette Doku nochmal lesen zu müssen. Reihenfolge folgt der Nachweistabelle im README.
"Wie installieren Sie Liberty, und wie unterscheidet sich das von traditionellem WAS?"
→ Zwei Wege: klassisch (ZIP entpacken, server create) oder build-getrieben
(liberty-maven-plugin, hier verwendet). Der entscheidende konzeptionelle Unterschied zu
traditionellem WAS: Liberty lädt nur die in server.xml angeforderten Features
(Feature-Manager-Modell) statt eines monolithischen "alles ist immer da". Beleg: echter
Serverstart mit CWWKF0011I, siehe
docs/10-installation-konfiguration/02-liberty-serverstart-verifiziert.md.
"Welche Java-Version läuft auf Ihrem WAS, und worauf müssen Sie bei einem Versionswechsel
achten?"
→ Traditionelles WAS ist bei Java sehr konservativ (WAS 9.0.x: Java 8 im Standard, Java 11 erst
über spätere Fixpacks, nie offizielle Java-17+-Unterstützung). Liberty ist deutlich agiler
(kontinuierliche Releases, Java 21 LTS mittlerweile voll unterstützt). Dazu kommt die
JVM-Frage: kommerzielles WebSphere Liberty läuft meist auf IBM Semeru (OpenJ9), nicht auf
HotSpot — relevant fürs GC-Tuning, siehe unten. Details:
docs/00-ueberblick/systemlandschaft.md.
"Wie ziehen Sie einen Thread-Dump, ohne den Server neu zu starten?"
→ server javadump <name> (Liberty-Bordmittel, funktioniert unabhängig von HotSpot/Semeru) oder
jcmd <pid> Thread.print (HotSpot-spezifisch). Real ausgeführt, echter Dump mit 53 Threads
analysiert. Siehe
docs/20-monitoring-tuning/02-heap-und-thread-dumps.md.
"HotSpot oder IBM Semeru — worin liegt der Unterschied beim GC-Tuning?"
→ HotSpot: G1/Parallel/ZGC, Flag -XX:+UseG1GC, Log via -Xlog:gc*. IBM Semeru/OpenJ9: Policies
gencon (Default)/optthruput/optavgpause/balanced/metronome, Flag -Xgcpolicy:, eigenes
Log-Format, Diagnose-Artefakte javacore.txt/.phd statt .hprof. Wer nur HotSpot kennt, greift
in einer echten IBM-Shop-Umgebung ins Leere. Siehe
docs/20-monitoring-tuning/01-jvm-heap-und-gc.md.
"Anwendung reagiert langsam — wie gehen Sie vor?"
→ Erst Thread-Dump ziehen (Beweis sichern, bevor ein Neustart ihn vernichtet), dann: viele
RUNNABLE-Threads mit gleichem Stacktrace = Code-Hotspot; viele BLOCKED auf demselben Lock =
Contention; Pool nahe am konfigurierten Maximum = Pool selbst der Engpass. Konkretes Runbook:
docs/30-troubleshooting-runbooks/01-runbooks.md.
"Was unterscheidet DB2 for z/OS von DB2, das ich vielleicht von Linux kenne?"
→ Eigene Betriebswelt: Zugriff über DDF (Ports 446/447), Sicherheit über RACF statt LDAP,
CPU-Verbrauch in MSU gemessen und oft direkt lizenzrelevant — Connection-Pool-Größe ist deshalb
nicht nur Performance-, sondern potenziell eine Kostenfrage, die man mit dem DB2-Team abstimmt.
Details: docs/40-bindeglied-dev-ops-db2-netzwerk/01-db2-fuer-zos-und-mainframe-grundlagen.md.
"Können Sie kurz erklären, was z/OS als Plattform ausmacht?"
→ Adressräume statt Prozesse, Datasets statt Dateisystem, EBCDIC statt ASCII/UTF-8 (relevant bei
Datenaustausch), viel Kernbank-Logik läuft als Batch-Job (JCL/JES) statt als Server-Prozess. Für
Transaktionsauslösung (nicht nur Datenzugriff) sind CICS/IMS bzw. z/OS Connect EE oft der
richtigere Weg als JDBC. Details:
docs/40-bindeglied-dev-ops-db2-netzwerk/00-was-ist-zos.md.
"Ein Kollege meldet SQLCODE -30081 — was tun Sie?"
→ Kommunikationsfehler, erster Verdacht ist die Netzwerkstrecke (Firewall-Freigabe
dezentral↔zentral, DVIPA-Erreichbarkeit) — nicht sofort beim DB2-Team suchen. Vollständige
Fehlerbild-Tabelle: 01-db2-fuer-zos-und-mainframe-grundlagen.md.
"Wie sieht Ihre Deployment-Pipeline aus?"
→ Stage-Modell (LOCAL/TEST/QS/PROD, DEPLOY_STAGE-Parameter), PROD manuell freigegeben und
branchgebunden. Eigener Smoke-Test-Schritt für LDAP-Erreichbarkeit vor dem eigentlichen
Deployment. Alle Skripte real getestet (deploy.sh: BUILD SUCCESS, echter Serverstart bis
Bereitschaft, sauberer Stopp). Siehe
docs/50-automatisierung-deployment/ und das
Jenkinsfile.
"Was gehört für Sie zu einer sauberen Übergabe an den Betrieb?"
→ Nicht ein Tool, sondern eine Disziplin: sieben konkrete, immer beantwortbare Fragen (wo läuft
was, wer pflegt welche Rolle/welches Zertifikat, wer ist Eskalationskontakt bei DB2/Netzwerk,
wie zieht man einen Dump ohne Neustart). Checkliste:
docs/50-automatisierung-deployment/02-jenkinsfile-und-uebergabe.md.
"Wie funktioniert Ihr Rollen-/Rechte-Modell?"
→ Zwei Ebenen: LDAP (ldapRegistry) beantwortet "wer ist der Nutzer", application-bnd in
server.xml bildet LDAP-Gruppen auf Anwendungsrollen ab. Real getestet: Nutzer aus der
Admin-Gruppe bekommt isPortalAdmin: true, aus der User-Gruppe spiegelbildlich — beide Seiten
(LDAP-Gruppe UND application-bnd) müssen gepflegt werden, sonst greift die Rolle nicht. Siehe
docs/60-security-lifecycle/01-rollen-und-rechte.md.
"Wie gehen Sie mit Zertifikatsrotation um?"
→ securityUtility createSSLCertificate — verweigert bewusst das Überschreiben eines
bestehenden Keystores (Schutz, kein Bug), deshalb: alten Keystore mit Zeitstempel sichern, neuen
erzeugen, Fingerabdruck vorher/nachher per keytool vergleichen, server.xml umstellen, bei
Verbindungen zu DB2 for z/OS zusätzlich den RACF-Keyring-Trust auf Mainframe-Seite aktualisieren.
Real durchgeführt inkl. unterschiedlicher SHA-256-Fingerabdrücke vorher/nachher. Siehe
docs/60-security-lifecycle/03-zertifikate-ssl.md.
"Wie stellen Sie 24x7-Verfügbarkeit für eine Liberty-Anwendung sicher?"
→ Grundprinzip: mehr als eine unabhängige Instanz derselben Anwendung. Real demonstriert: zwei
gleichzeitig laufende Liberty-Prozesse, beide erreichbar, beide liefern für dieselben
LDAP-Credentials dasselbe Rollen-Ergebnis (gemeinsames Verzeichnis statt getrennter
Nutzerbestände) — echte HA-Partner, kein Zufall. Siehe
docs/70-high-availability/01-appserver-ha-demo.md.
"Und wenn der Lastverteiler selbst mal nicht mitspielt?"
→ Genau das ist in diesem Projekt tatsächlich passiert (Container-zu-Host-Netzwerk-Problem beim
Traefik-Versuch) — ehrlich als Blocker dokumentiert statt behauptet. Zeigt den
Diagnose-Weg (Server-Bindung prüfen, DNS prüfen, Firewall-Regel, VM-Neustart), auch wenn das
Ergebnis am Ende "nicht in dieser Umgebung lösbar" war. Siehe
docs/70-high-availability/03-traefik-load-balancing-versuch.md.
"Und Messaging-HA?"
→ IBM MQ kennt Multi-Instance-Queue-Manager (aktiv/passiv) und Queue-Manager-Cluster (mehrere
aktive Knoten). Liberty-seitig macht connectionNameList (statt hostName) den Unterschied —
eine Liste von Knoten, die der Reihe nach versucht wird. Siehe
docs/70-high-availability/02-messaging-ha.md.