4.8 KiB
Vortrag "Chaos Engineering"
- BUgra Derre von Dailmer TSS
- Daimler TSS -> Freitag Nachmittag frei für eigene Projekte
Sinnbild: Der Affe stört SW-Engineers happy life. Er sorgt für chaotische Zustände
Lustige Frage: Wer würde sich trauen einen Herzschrittmacher für sich selbst zu programmieren , kaum Hände oben ;-)
Leslie Lamport: Systemausfälle als Regel. Verteilte Systeme führen dazu das das eigene System nicht mehr funktioniert, transitive unbekannte Abhängigkeiten!
Chaos kann man trainieren. Chaos erzeugt nicht fehler es deckt sie auf.
Phasen des chaos
- Hypothesen formulieren (Szenarien)
- Experimentieren veränderungen vornhemen z.B. Latenzen einführen
- lernen
- anpassen
Methodik eher für Cloud Dienste? Buchempfehlung - Release It Gamedays - Vollautomatische Durchführung von Chaos tests die z.B. ein Team Treffen -> SH ist unser Monkey ;-) Schon durch das blosse durchdenken der Experimente können Fehler gefunden werden bzw. man erkennt ohne Experiment dass es fehlschalgen wird.
Embedded raus aus dem Bett (Bosch) Harald Göttlicher
Cooler/ Netter Typ, Bosch Kollege , Zuständig für Coninous Delivery Embedded Entwicklung hat spezielle Anforderung z.B. Hardwarebindung
Wer wenig oft liefert macht viel manuel und ist ineffizient Niedriger Durchsatz Hohe Fehlerraten weil große Releases mehr Inhalt haben was zum mehr Komplexität bedeutet Aussagen basieren auf einem Report -> siehe state of devops report
Lernen von DevOps, passen diese Methoden für Embedded?
Vision : Monolithen in ganz viele einzelne Kompnenten aufteilen -> Microservices Wir brauchen einen Paradigmenwechsel von Schichtenarchitektur zu Komponentenarchitektur für einzelne Funktionen. Schneide kleiner als du gedacht hast. Viele Komponenten bedueten viel Aufwand für Automatisierung -> Lösung Automatisierung der Automatisierung. Es gibr auch tools dafür z.B. Ansible , Chef , Puppet Umgebungen zum bauen in Container kapseln.
Der näcshte Schritt man denknt nicht mehr in layern sonder in Komponenten. Inkrementeller Build, es wird eine BOM von letzter Version gemacht und ein Diff zur aktueller gemacht, es werden nur aktualiesierte Artefakte aktualisiert.
Tests müssen passend zu Komponenten geschnitten werden.
Implementation Patterns Dr. Frank Gerhardt
Buch Implementation Patterns von Kent Beck Implementation Patterns sind zwischen Desgin PAtterns und Style Guide
andere Leute sind wichtig , andere Perspektiven Berücksichtigen. So programmieren dass andere den Code auch verstehen.
Programmieren is wie Jeopodardy.
3 Werte & 6 Prinzipien:
Werte
- Kommunikation , liteerate programming,
- Simplicity, keine goldenen Wasserhähne
- Flexibiiliät, kann auch missbraucht werden, es macht vorab keinen Sinn vorab zuviel zu abstrahieren. Keep options open
Prinzipien
- locale consequences
- keine wiederholung
- logik anda data together
- symmetrie / Integriät
- ..
Kosten für code entstehen nicht in der Entwicklung sondern später beim erweitern und pflegen
Conditional, if / if / if / else sollten symmetrisch sein
Gemeinsame sprache entiwcklen verinfacht feedback in Code Reviewees
Message pattern: compute() input,process,output
single exit , nicht mehr relevant heute
Erkenntnis: Implementation pattterns viel wichtiger als Programmiersprachen Konzepte ( lambdas, predicates,)
DSL mit Kotlin FRank Scheffler
Code in Github Kotlin Konzepte: val macht immutable variablen, keine null Zuweisung wenn überhaupt denn Deklaration Fragezeichen? String templating Man Klassen Funktionen andichten (Extension Functions)
Dr. Elmar Juergens / Meine Erfahrungen aus 10 Jahre Entwicklung von Qualitätsanalysen
- Gründer von Firma welche Qulaitätsanalysesoftware erstellt / nutzt
Software Inelligence Test Gap Analyse - Tickets können auch als Datenquelle zur Priosierung von zu testenden Modulen verwendet werden.
Die Herausforderung ist die Testfälle zu identifizieren die den geänderten Code durchlaufen. Optimiert den Testdurchlauf hinsitlich zeit. Beim REview muss der Test nachgewiesen werden.
Nur auf dem master/develop branch alle tests durchführen, auf dem feature brach reicht es aus nur die impaktierten TEsts auszuführen, bei uns dauert es 20 Minuten und es wird immer gebaut.
Code peer reviews: Review abgeschlossen wenn alle Probleme abgeschlossen sind. Unit of review ist ticket! Jira Zustand für REview und Rework
Nutzen von Reviews:
- Code wird besser es kommt nichtmal drafau an funktionale FEhler zu finden
- Haupfaktor Wissenstransfer
Zum Nachschlagen
- Kubernetes
- Circuit Breaker Pattern, wiederkehrende Verbindung die erfolglos sind behandeln -> fallback lösung
- Wie testet man einzelne Bundles?
- Dokumentation der einzelnen Bundles mit Sinn und Schnittstellen
- Mit Kotlin experimentieren
- Mit Predicates arbeiten
- Funktionale Interfaces
- Generics
- DSL Buch Fowler