Ist Überstunden-machen Betrug?

Geistige und körperliche Arbeit ist anstrengend. Wenn wir über einen Erschöpfungszustand hinaus weiter arbeiten, nimmt die Qualität unserer Arbeit und damit auch die Qualität der Arbeitsergebnisse ab. Je länger wir arbeiten, desto unkonzentrierter, fehleranfälliger und langsamer werden wir.

Wenn wir also 8 Stunden konzentriert arbeiten und danach noch weitere 4 Überstunden arbeiten, arbeiten wir in diesen 4 Überstunden nicht nur langsamer, sondern machen auch mehr Fehler. Diese Fehler müssen wir wieder korrigieren und das macht uns nochmal langsamer. Das vergleichbare Arbeitsergebnis dieser 4 Überstunden kann sehr wahrscheinlich am nächsten Tag, nach einer nächtlichen Erholung mit viel Schlaf, innerhalb von 1 Stunde erreicht werden. Das bedeutet, dass das gleiche Ergebnis entweder in 12 Stunden (8h + 4h Überstunden) oder in 9 Stunden (8h + 1h vom Folgetag) erreicht werden kann.

Natürlich ist es aus Sicht des Leistungserbringers besser 12 Arbeitsstunden in Rechnung zu stellen als nur 9 Stunden. Aber ist das nicht Betrug? Stellen Sie sich vor Sie fahren mit dem Zug in eine fremde Stadt. Dort steigen Sie in ein Taxi und sagen dem Taxifahrer, dass Sie zum Theater wollen. Der Taxifahrer weiß, dass es auf dem schnellsten Weg zum Theater 10 Minuten dauert. Da er aber ahnt, dass Sie sich nicht auskennen, fährt er Sie einen Umweg von 20 Minuten. Würden Sie sagen der Taxifahrer hat Sie betrogen?

Um eine Deadline einhalten zu können, ist es manchmal notwendig Überstunden zu machen. In diesen Fällen können wir eine ausreichende Erholungsphase nicht abwarten, sondern müssen die Zeit aus der Zukunft vorziehen. Das hat natürlich die oben erwähnten negativen Konsequenzen. Das Ergebnis wird früher erreicht, aber mit mehr Stunden. Ein solches Vorgehen ist nicht nur ineffizient, nicht nachhaltig und ungesund, sondern kostet den Leistungsempfänger unnötig Geld, das er sparen oder in neue Features hätte investieren können. Das sollte uns stets bewusst sein, wenn wir wieder Überstunden machen wollen.

“Wenn jemand zehn Minuten deines Lebens verschwendet, dann sind acht davon deine Schuld.” Markus Frank

 

 

Zentrale Service Einstellungen?

Dienstspezifische Einstellungen sollten bei dem jeweiligen Dienst abgelegt werden.

Kohäsion

Es ist eine Frage der Kohäsion. Dinge, die fachlich zusammengehören, sollten auch zusammen und in enger Nähe platziert werden. Es gibt wenig schlimmeres als ein Feature so aufzuteilen, dass es im ganzen System verteilt ist (hier ein bisschen Code, hier ein bisschen Config, hier wieder ein bisschen Code, da ein bisschen Doku, usw.). Dienste sollten möglichst autark sein und bestenfalls eigenständig existieren können. Je mehr Kopplung im System besteht, desto schwieriger wird die Weiterentwicklung. Deswegen sind zentrale Aspekte besonders gefährlich. Manche Funktionen müssen zentral realisiert werden, wie zum Beispiel Authentifizierung, weil es nicht anders geht. Alle Dinge, die nicht zwingend zentralisiert werden müssen, sollten es auch nicht. Für den Anwenderkomfort können zentrale Darstellung mit Hilfe von konsolidierenden Oberflächen und Backends For Frontends geschaffen werden.
Im weiteren zeige ich zusätzlich noch drei eindeutige Vorteile der dezentralen Konfiguration.

Atomare Änderungen

Änderungen und Weiterentwicklungen eines Dienstes müssen nicht mehr an zwei entfernten Stellen (Code und Config) nachgezogen werden und in zwei Phasen committed werden. Diese zwei Stellen haben in der Regel eine zeitliche Kopplung, die zu einer fest vorgegebenen Reihenfolge der Aktualisierung führt, die eingehalten werden muss.
Wenn Code und Config an der gleichen Stelle liegen, kann der Code weiterentwickelt und neue Einstellungen direkt mit angepasst werden. Beides kann mit einem einzigen Commit in der richtigen Reihenfolge atomar deployt werden.

Prepare and Forget

Eine Einstellung kann dann auch nicht fälschlicherweise zu früh deployt werden, was zu Fehlern in der aktuellen Version führen kann, sondern wird erst unmittelbar mit dem Code deployt. Ein Entwickler muss nach seinem Commit nicht erst darauf warten, dass sein Code in Test und schließlich nach Production deployt wird, damit er endlich die Einstellung für die jeweilige Umgebung einstellen kann. Die Einstellung wird automatisch angewendet, wenn der Code in die jeweilige Umgebung freigegeben und deployt wird. Der Entwickler brauch sich nicht mehr kümmern (wenn alles nach Plan läuft). Natürlich muss er die Einstellung für Test, Production und alle anderen Umgebungen kontrolliert vorbereiten, aber das tatsächliche Anwenden passiert transparent im Hintergrund, zur richtigen Zeit automatisiert.
Eventuelle Geheimnisse, die der Entwickler nicht kennen darf, müssen ihm verschlüsselt von der jeweils zuständigen Person mitgeteilt oder in Kooperation vorbereitet werden.
Auch das Wiederherstellen einer früheren Version ist aus der Perspektive der Einstellungen problemlos möglich, da die Einstellungen mit dem selben Commit assoziiert sind.

Verantwortung des Service beim Team

Solange das Team, das den Service entwickelt, auch die Verantwortung für den Betrieb des Services übernehmen soll, müssen alle relevanten Artefakte mit dem Service verwaltet werden. Das Repository repräsentiert auch eine organisatorische Klammer. Durch das Klonen des Repositories bekommen Entwickler nicht nur vollständigen Zugriff auf den Quelltext, sondern auch auf tatsächliche Einstellungen, Build Skripte und Deployment Ressourcen. Ein Entwickler kann sich also jederzeit eine funktionsfähige und sinnvoll konfigurierte Umgebung auf seinem Computer erstellen und für Test- und Entwicklungszwecke betreiben. Isolierte Weiterentwicklungen können dabei sogar problemlos in eigenen Branches erfolgen. Ein Entwickler hat jederzeit alle nötigen Ressourcen zur Verfügung, um die Anwendung eigenständig weiterzuentwickeln.

 

Einwände

Und wenn sich nur die Einstellung ändert?

Wenn Einstellung und Service in der selben Pipeline deployt werden, ist das erstmal nicht schlimm. Nachteilig ist lediglich, dass es vielleicht etwas länger dauert, bis die Einstellung aktiv wird. Soll die Änderungen sofort gelten, kann sie manuell oder über das K8S Dashboard vorgenommen werden, und wenn sie endgültig sein soll, kann diese Änderung durch commit dokumentiert werden. Durch das anschließende Deployment wird der Wert dann nicht nochmal geändert, weil er bereits auf dem Zielwert steht.

Und wenn sich eine Einstellung auf viele Dienste bezieht?

Einstellungen, die keinem Dienst zugeordnet werden können (Logging, Message Bus,…), können in der Regel der Umgebung zugeordnet werden. Daher sollten sie an einem dafür vorgesehehen Ort für Infrastruktur Konfiguration abgelegt werden.
Einstellungen, die von einem Dienst für andere Dienste bereitgestellt werden, sollten bei dem bereitstellenden Dienst abgelegt werden. Eine Änderung dieser Einstellungen sollte einen automatisierten Neustart der Konsumeten verursachen.

Und wenn sich alle Einstellungen ändern?

Generell sollten Einstellungen so platziert werden, dass wahrscheinliche und häufige Änderungen mit wenig Aufwand vorgenommen werden können, während für unwahrscheinliche und seltene Änderungen höhere Aufwände akzeptiert werden können. Es macht mehr Sinn für Weiterentwicklung einzelner Dienste zu optimieren als für das Umziehen des ganzen Systems in neue Umgebungen. Sollten sich dienstübergreifende Dinge, wie zum Beispiel die Domain, ändern, dann müssen im schlimmsten Fall viele Commits vorgenommen werden. Auch hier kann eine sofortige Änderung manuell oder im K8S Dashboard erfolgen, die dann anschließend noch committed werden muss. Sollten sich dienstübergreifende Dinge häufig ändern, sollten diese hoffentlich wenigen Einstellungen besser an dem Ort für Infrastruktur Konfiguration abgelegt werden.