1 
30 Minuten 
Software-Sanierung: Wie man kranke Systeme wieder gesund macht. 
Dr. Josef Adersberger (josef.adersberger@q...
2 
Manch Software ist ein Intensivpatient. 
http://www.klinikum.uni-heidelberg.de
Grund 1: Das Ding läuft nicht richtig. 
3 
https://developers.facebook.com/status 
MTTR: ~46 Stunden 
Äußere Qualität
Grund 2: Qualitätsschulden und Software-Bankrott. 
4 
Software von angemessenerQualität 
Änderungskosten in € 
Zeit 
Softw...
5 
Doch wie helfen? 
http://www.starflash.de/stars/dr.-house-fanclub-266439.html
6 
1: Anamnese 
Erhebung der Leidensgeschichte des Patienten.
7 
Was ist das Fehlerbildvor Kunde? Wie hoch ist der Schaden? 
Wann wurde der Fehler erstmalig gemeldet und wie häufig tri...
8 
Untersuchung 
Messungen und Inspektionen am Patienten durchführen: 
Vitalfunktionen 
Symptombezogen 
Gesamtheitlich
9 
http://www.siemens.com/press/pool/de/pressebilder/2013/healthcare/imaging-therapy-systems/HIM201311007 
Eine Frage der ...
Das Software-EKG + ein guter Profiler. 
10 
Viele Knoten und Prozesse 
Non-invasive Messpunkte: SNMP, WPC, JMX, … 
Hohe...
EKGpi: Eine Software-Blackbox. 
11
SonarQube: Ein Vital-Monitor der inneren Softwarequalität. 
12 
Trends! 
Die wichtigsten Metriken 
Alarme 
Anomalien
Structure101: Ein Röntgenapparat für Code. 
13 
Architekturkonsistenz 
Komplexitätsverteilung 
Zyklen 
Refactoring-Simulat...
14 
Diagnose 
Symptom: Ein Zeichen, das auf eine Erkrankung hinweist. 
Befund: Ergebnis einer Untersuchung (pathologisch ...
15 
Diagnostik 
Symptomatik 
Anamnese: Anwendung macht hauptsächlich NW-IO. Kein Reproducer. 
Beschwerde: Java-Web-System ...
Bei Qualitätsschulden ist die Diagnose einfacher: 90% der Symptome lassen sich auf wenige Ursachen zurückführen. 
16 
■Man...
17 
Dings 
bums 
Die ewig konsistente Architektur
Natürlich haben wir eine Architektur! 
18
Qualitätsschulden entstehen jedoch insbesondere auch durch 
mangelhafte fachliche Modularisierung. 
19
20 
Therapie 
Therapie: Maßnahmen zur Behandlung von Krankheiten. 
Gezielte Therapie 
Notfalltherapie 
Verdachtstherapie
Der Therapie-Plan: Maßnahmenkatalog. 
21 
■Symptom (Auffälligkeit) 
■(Therapie-) Maßnahme 
■Was passiert, wenn man es nich...
Wichtig ist die Nachsorge: Ein Qualitätskontrakt definiert ein verbindliches Qualitätsniveau und Qualitätsziele. 
22 
Test...
23 
Abweichungen 
Trends 
Attraktoren 
Information Radiatorenmachen Qualität sichtbar
24 
Information Radiatorenmachen Qualität sichtbar 
Featuring: Shake-to-Build
QAwareGmbH, Aschauer Str. 32, 81549 München, GermanyTel +49 89 232315-0, Fax +49 89 232315-129, info@qaware.de, www.qaware...
Nächste SlideShare
Wird geladen in …5
×

Software-Sanierung: Wie man kranke Systeme wieder gesund macht.

621 Aufrufe

Veröffentlicht am

Manche Softwaresysteme sind Intensivpatienten: Sie können nur mit hohem Aufwand weiter am Leben gehalten werden. Sämtliches Budget wird verbraucht, um Qualitätsschulden zurück zu zahlen: Bugs fixen; Performance tunen; Sicherheitslöcher stopfen; Architekturbrüche auflösen.
Wir stellen im Vortrag die 4 Schritte der Software-Sanierung vor:
Erstens, die Probleme erfassen. Hierbei hilft uns ein Diagnoseverfahren, das der Medizin entlehnt ist. Zweitens, die Ursachen identifizieren. Hier zählt es, die richtigen (Open-Source-) Werkzeuge einzusetzen zur statischen Analyse von Code- und Architekturanomalien und zur dynamischen Analyse von Laufzeitanomalien. Drittens, Maßnahmen ableiten und umsetzen sowie einen wirksamen und vernünftig priorisierten Maßnahmenkatalog erstellen und daraus Refactoringpläne ableiten und ausführen. Viertens, die Erfolge messen also bestimmen, wie wirksam die Maßnahmen wirklich waren, ob das Ziel schon erreicht ist, oder ob weitere Maßnahmen angegangen werden müssen.
Neben dem eigentlichen Ablauf beschreiben wir eine Reihe an Methoden, Best Practices und Werkzeuge, die dabei erfolgskritisch sind.

Veröffentlicht in: Technologie
0 Kommentare
2 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
621
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
15
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
2
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Software-Sanierung: Wie man kranke Systeme wieder gesund macht.

  1. 1. 1 30 Minuten Software-Sanierung: Wie man kranke Systeme wieder gesund macht. Dr. Josef Adersberger (josef.adersberger@qaware.de)
  2. 2. 2 Manch Software ist ein Intensivpatient. http://www.klinikum.uni-heidelberg.de
  3. 3. Grund 1: Das Ding läuft nicht richtig. 3 https://developers.facebook.com/status MTTR: ~46 Stunden Äußere Qualität
  4. 4. Grund 2: Qualitätsschulden und Software-Bankrott. 4 Software von angemessenerQualität Änderungskosten in € Zeit Software von degenerierterQualität Budget Erste zerbrochene Fensterscheibe Software- Qualitätsschulden Innere Qualität
  5. 5. 5 Doch wie helfen? http://www.starflash.de/stars/dr.-house-fanclub-266439.html
  6. 6. 6 1: Anamnese Erhebung der Leidensgeschichte des Patienten.
  7. 7. 7 Was ist das Fehlerbildvor Kunde? Wie hoch ist der Schaden? Wann wurde der Fehler erstmalig gemeldet und wie häufig tritt er seitdem auf (MTTF)? Wie lange dauert es, um das System nach dem Fehler wieder lauffähig zu bekommen (MTTR)? Kann der Fehler reproduziert werden? Sind Logsoder Monitoring-Daten für vor, während und nach dem Fehler verfügbar? Gab es vor dem Fehler ein besonderes Ereignis (z.B. betrieblicher Eingriff, ausgefallenes Nachbarsystem oder Request-Spitze)? Welche Ideen gibt es für die Fehlerursachen? Wie lange wird die Software bereits entwickelt? Wie viele Entwickler haben daran entwickelt und wie hoch war ihre Fluktuation? Wie umfangreich ist die Software (z.B. in Lines-of-Code)? Was sind die größten Produktivitätshemmnisse bei den Entwicklern? Wo drückt der Schuh? Gibt es ein Architekturbildder Software? Bei Laufzeitproblemen: Bei Qualitätsschulden: Welche Technologienwerden eingesetzt?
  8. 8. 8 Untersuchung Messungen und Inspektionen am Patienten durchführen: Vitalfunktionen Symptombezogen Gesamtheitlich
  9. 9. 9 http://www.siemens.com/press/pool/de/pressebilder/2013/healthcare/imaging-therapy-systems/HIM201311007 Eine Frage der Werkzeuge
  10. 10. Das Software-EKG + ein guter Profiler. 10 Viele Knoten und Prozesse Non-invasive Messpunkte: SNMP, WPC, JMX, … Hohe Abtastfrequenz Integrierte Log-Analyse Explorative Analyse-UI
  11. 11. EKGpi: Eine Software-Blackbox. 11
  12. 12. SonarQube: Ein Vital-Monitor der inneren Softwarequalität. 12 Trends! Die wichtigsten Metriken Alarme Anomalien
  13. 13. Structure101: Ein Röntgenapparat für Code. 13 Architekturkonsistenz Komplexitätsverteilung Zyklen Refactoring-Simulation
  14. 14. 14 Diagnose Symptom: Ein Zeichen, das auf eine Erkrankung hinweist. Befund: Ergebnis einer Untersuchung (pathologisch weist auf Erkrankung hin) Beschwerde: Aussage des Patienten Diagnose: Krankheitsursache erschließen. Dafür sind neben den Symptomen oft weitere Untersuchungen notwendig. Ausschluss-Diagnose: Ursachen ausschließen. Differenzial-Diagnose: Iterative risiko-und wahrscheinlichkeitsorientierte Eingrenzung. Verdachtsdiagnose: Auf Verdacht behandeln.
  15. 15. 15 Diagnostik Symptomatik Anamnese: Anwendung macht hauptsächlich NW-IO. Kein Reproducer. Beschwerde: Java-Web-System stürzt seit letztem Release erratisch nach wenigen Stunden Laufzeit ab. Differenzialdiagnose„Systemausfall Web-System“. Befund (o.B.): Keine Fehlermeldungen in den Applikations-und Systemlogs. Befund (o.B.): Keine Speicherknappheit im Monitoring erkennbar. Befund (o.B): Keine Korrelation des Ausfalls mit der Systemlast erkennbar. Befund (o.B.): Keine Korrelation des Ausfalls mit einem bestimmten Request. Befund (pathologisch): Zu gering gesetzte FileHandles(ulimit) im Betriebssystem. Notfalltherapie: Watchdoginstallieren, der Neustart auslöst. Therapie: FileHandlesper ulimiterhöht. Untersuchung: Log-Level der System-Logs erhöhen und Logs aus anschließendem Produktionslauf monitoren. Befund (pathologisch, Leitsymptom): System-Log zeigt weiterhin einen JVM-Exit mitSegmentation Error (ungültige Speicherreferenzierung). Eingrenzung: Fehler entsteht nicht durch Java-Code. Er kannentstehen durch: 1.Einen Bug in einer verwendeten nativen Bibliothek 2.Einen Bug in der JVM 3.Eine fehlerhafte Konfiguration der JVM 4.Eine fehlerhafte Konfiguration des Systems Ausschluss-Diagnose: •Untersuchung: JVM-Shutdown-Hook ergänzen, der Core- Dumpbei Exit erstellt und in Produktion auf Fehler warten. •Untersuchung: Alle JVM-Parameterder Anwendung ermitteln. Befund (pathologisch): Segmentation Error im JVM-Codefür Netzwerk-IO. Verdachtsdiagnose(nach Internet-Recherche): Bug in JVM 6 mit unpassendem Default-Wert für StackShadowPages. Therapie:StackShadowPageserhöht. Untersuchung: Produktion überwachen. Befund (o.B.): Produktion läuft stabil.
  16. 16. Bei Qualitätsschulden ist die Diagnose einfacher: 90% der Symptome lassen sich auf wenige Ursachen zurückführen. 16 ■Mangelnde Testüberdeckung. ■Unüberlegter Einsatz von (Open-Source-) Bibliotheken und Frameworks. ■Zu viele Code-Anomalien und uneinheitlich formatierter Code. ■Zu viel duplizierter Code. ■Zu wenig Kommentare an den wichtigen Stellen. ■Komplexitätsnester. ■Keine (vernünftige) Architektur. ■Fehlende Architekturkonsistenz. Die Ursachen für die restlichen 10% lassen sich gut durch eine Woche Pair Programmingmit einem Stamm-Entwickler ermitteln.
  17. 17. 17 Dings bums Die ewig konsistente Architektur
  18. 18. Natürlich haben wir eine Architektur! 18
  19. 19. Qualitätsschulden entstehen jedoch insbesondere auch durch mangelhafte fachliche Modularisierung. 19
  20. 20. 20 Therapie Therapie: Maßnahmen zur Behandlung von Krankheiten. Gezielte Therapie Notfalltherapie Verdachtstherapie
  21. 21. Der Therapie-Plan: Maßnahmenkatalog. 21 ■Symptom (Auffälligkeit) ■(Therapie-) Maßnahme ■Was passiert, wenn man es nicht macht? ■Priorität ■Aufwand ■Wirkung
  22. 22. Wichtig ist die Nachsorge: Ein Qualitätskontrakt definiert ein verbindliches Qualitätsniveau und Qualitätsziele. 22 Tests Code Duplikate Kommentare Architektur Komplexität Funktionalität Änderbarkeit Metrik rot gelb C1-Testüberdeckung über alle Testebenen <60% < 65% Testerfolg < 100% Ignorierte Testfälle > 0 Rot: Code-Duplikate (ohne Generate) mit mehr als 10 Anweisungen duplizierter Code-Struktur. Metrik rot gelb Dokumentierte API <90% <100% Kommentarquote < 10% <25% Rot: Verletzung gegen eine definierte Soll-Architektur existieren. Rot: Abhängigkeitszyklen über Paketgrenzen hinweg. Rot: Anteil am Code- Volumen der Methoden mit einer zyklomatischenKomplexität > 10 ist größer als 10%. Metrik rot gelb Code-Anomalien mit Schweregrad Blocker oder Critical oder Major. > 0 Code-Anomalien mit Schweregrad Minor, Info > 0 Semantik der Farben: Rot: Zu keinem Zeitpunkt akzeptabel. Reißleinen- Prinzip. Gelb: Muss vor einem Release blau sein. Grau: Wenn nichts gemessen wird. Blau: Wenn nicht gelb/rot/grau.
  23. 23. 23 Abweichungen Trends Attraktoren Information Radiatorenmachen Qualität sichtbar
  24. 24. 24 Information Radiatorenmachen Qualität sichtbar Featuring: Shake-to-Build
  25. 25. QAwareGmbH, Aschauer Str. 32, 81549 München, GermanyTel +49 89 232315-0, Fax +49 89 232315-129, info@qaware.de, www.qaware.de QUANTENSPRUNG DANK ANDERSDENKEN Josef Adersberger josef.adersberger@qaware.de @adersberger

×