Shownotes & Links
Transkript
Anja Kammer: Hallo und herzlich willkommen zum INNOQ Podcast. Heute spreche ich mit Stefan Negele. Hallo Stefan!
Stefan Negele: Hallo Anja!
Anja Kammer: Warum haben wir uns heute getroffen?
Stefan Negele: Wir hatten uns überlegt, dass wir mal einen Podcast aufnehmen zum Thema, damals war das noch ein Observability und dann haben wir uns relativ lange über das Thema unterhalten und dann gesagt, ja, nehmen wir mal was dazu auf. Und sind aber dann draufgekommen, dass so die ursprüngliche Idee irgendwie Observability, Observability-Technologien eigentlich gar nicht so spannend ist, sondern dass es eigentlich eher darum gehen sollte, welche Sachen oder welche Metriken sind denn eigentlich spannend für ein Produkt-Team?
Anja Kammer: Genau.
Stefan Negele: Ja, und dann ist uns aufgefallen: Wie nennen wir diese Metriken überhaupt? Haben wir gesagt: Okay, wir nennen die Produktmetriken und wir betrachten die aus Dev Sicht. Wie wir überhaupt darauf gekommen sind. Wir haben natürlich beide irgendwie täglich damit zu tun. Was hast du denn damit zu tun, Anja? Welche Berührungspunkte hast du? Was ist deine Motivation, dich mit dem Thema auseinanderzusetzen?
Anja Kammer: Meine Motivation war, dass ich in vielen Projekten Fehler gemacht habe. Bei der Definition von Metriken, beim Thema Observability, vor allem in verteilten Systemen, ist es überhaupt nicht trivial. Das ist eine super schwierige Aufgabe für ein verteiltes System, Observability herzustellen und Fehler zu finden oder herauszufinden, ob ein Job, der einmal die Woche läuft, überhaupt erfolgreich gelaufen ist. Das stellt man sich easy vor, ist aber gar nicht so easy. Und ich würde gerne meine Erkenntnisse teilen oder darüber reden, wie man schlauer an das Thema Observability herangehen kann. Und bei dir, Stefan?
Stefan Negele: Ich komme da aus einer anderen Richtung. Zum ersten Mal habe ich mich intensiv mit dem Thema beschäftigt, als ich mit einem Team eine Steuerungssoftware für IoT Geräte umgesetzt habe. Und die Kommunikation mit diesen Geräten war sehr Hardware-nah über einen seriellen Bus. Die Konstellation von dem Ganzen war dann natürlich auch noch ein bisschen tricky. Die Software war von uns, die Hardware war aber nicht von uns und die Hardware wurde auch nicht mehr so wirklich supported vom Hersteller.
Anja Kammer: Super.
Stefan Negele: Ja genau. Und das Problem mit diesem seriellen Bus ist natürlich, dass wenn du ein einzelnes Gerät hast, das ausfällt, dann eine komplette Gerätegruppe, also alle Geräte, die an diesem Bus hängen, theoretisch mit ausfallen können und da muss man natürlich Maßnahmen ergreifen. Und die erste direkte Maßnahme ist natürlich, wenn man erkennt welches Gerät man nimmt, das Gerät aus der Gleichung und hofft, dass der Rest weiter funktioniert. Aber man hat natürlich auch langfristige Maßnahmen. Man muss irgendwas gegen dieses kaputte Gerät unternehmen und das heißt, man braucht einen Alert, man informiert am besten einen Techniker oder bzw. informiert ihn nicht nur, sondern sagt: Geh mal dahin, tausche das Gerät aus oder repariere es. Damit kennt sich dann die Person hoffentlich besser aus. Und idealerweise passiert das Ganze noch bevor die Kunden das mitbekommen. Oder man gibt ihnen zumindest das Gefühl, dass man die Sache im Griff hat. Eine andere Motivation war aber auch gewissermaßen eine Rechtfertigung. In so einer Situation will natürlich niemand Schuld tragen. Und wir konnten dann eben als Entwicklungsteam in Zahlen, Tabellen und Graphen relativ cool aufzeigen, dass die Probleme nicht durch unsere Software kommen. Klar gab es auch Probleme, die durch die Software kommen. Die können wir aber dann auch beheben. Aber wir können eben aufzeigen, dass die Probleme nicht durch die Software kommen, sondern oft durch fehlerhafte Hardware. Dadurch, dass wir die Maßnahmen ergreifen konnten, Techniker informieren, konnten wir uns eben statt mit sinnloser Fehlersuche eben damit auseinandersetzen, neue Features umzusetzen oder das Produkt zu verbessern, vielleicht Performance zu verbessern und solche Dinge.
Anja Kammer: Ja, das finde ich sehr interessant. Und man sagt ja auch immer: Nein, Observability ist ein OPS Thema, ein Betriebsthema. Damit sollten sich Entwicklungsteams nicht auseinandersetzen, damit sie eben Zeit haben für ihre Entwicklung. Aber ich glaube, du stimmst mir da zu. Wir hatten schon darüber gesprochen. Das kann man nicht voneinander trennen. Man kann die Softwareentwicklung nicht von der Observability der Features trennen, die man da entwickelt. Weil wer ist denn die perfekte Person, um die richtigen Metriken zu identifizieren, die gemonitored werden sollen als die Person, die das Feature entwickelt haben?
Stefan Negele: Genau. Wir haben hoffentlich vertikale Teams. Das heißt, unser Dev Team ist idealerweise ein Produkt Team. Das kümmert sich um ein komplettes Produkt. Das heißt, es hat auch Produktverantwortung und hat konzentriertes Wissen zu dem Produkt bzw. eben zu der Domäne, zu der dieses Produkt gehört. Und das bedeutet dann zum Beispiel auch, wenn wir so ein Team haben, dann ist das produktiver und Lösungen sind passgenauer zu dem Problem oder zu unserem Need. Man kennt das zum Beispiel aus Team Topologies. Da gibt es die Stream-aligned Teams und es geht eigentlich die ganze Zeit darum, dass wir uns damit auseinandersetzen: Was sind die Bedürfnisse von unseren Nutzerinnen? Und Verständnis zu entwickeln für die Nutzerinnen unserer Software. Und am Ende führt das dann dazu, dass Personen, die Software entwickeln, zu Produktentwicklerinnen werden.
Anja Kammer: Genau, richtig. Das will man gar nicht so wahrhaben, dass Softwareentwicklerinnen Produktentwicklerinnen sind. Aber auch in der DevOps-Bewegung ging es darum, den gesamten Software-Lebenszyklus von dem Entwicklungsteam managen zu lassen. Dieser DevOps Gedanke hat sich dann weiterentwickelt zu, dass immer mehr Kund:innen-Feedback auch mit in die Entwicklung einfließen. Denn die Zusammenarbeit zwischen Entwicklung und Ops bezieht auch Kundinnen Feedback mit ein. Ops bedeutet ja Operations, bedeutet den Betrieb der Software und zum Betrieb der Software gehört auch Feedback der Kund:innen und die Metriken, die Nutzungsmetriken mit in den Entwicklungsprozess wieder einzuweben. Und wenn wir jetzt über Endkundinnen oder Nutzenden reden, dann können das auch interne Nutzende sein. Wenn ich eine interne Software für mein Unternehmen baue, dann sind meine Kundinnen eben diejenigen Kolleginnen, die meine Software verwenden. Oder wenn ich einen Service anbiete und dieser Service stellt eine API zur Verfügung für andere Teams. Dann sind die anderen Teams, die meine API benutzen, meine Kundinnen. Das ist natürlich viel einfacher, mit Nutzerinnen zu sprechen, die im selben Gebäude arbeiten oder im selben Unternehmen arbeiten. Es ist aber unfassbar schwierig, mit Kundinnen zu arbeiten oder dieses Kundinnenen-Feedback zu erheben, wenn es End-Nutzende sind, die eigentlich nichts davon haben, wenn sie mit mir kommunizieren. Wenn ich jetzt nur technische Metriken zur Verfügung habe, Datenbank, Read, Latenz.
Stefan Negele: Festplattenauslastung.
Anja Kammer: Genau, diese typische Festplattenauslastung.
Stefan Negele: Das hat es mir angetan.
Anja Kammer: Ja, genau. Die braucht doch kein Mensch. Zumindest keine Kundschaft braucht das. Keine Nutzende braucht das. Denen ist das doch egal, ob die Festplatte voll ist oder nicht. Was sie interessiert, ist, ob die Features funktionieren. Das bedeutet, technische Metriken geben nur ein unvollständiges Bild von dem, ob die Nutzenden eigentlich zufrieden sein können mit dem Service, den wir bieten. Wir brauchen immer noch Feedback der Kundinnen, ob das Produkt, was wir entwickeln, passgenau ist. Und das können wir messen.
Stefan Negele: Jetzt stellt sich natürlich die Frage: Ja, das können wir messen. Aber was wollen wir messen? Was ist eigentlich unser Produkt und welche Metriken sind wichtig? Da gibt es natürlich verschiedene Wege, wie man da rangehen kann. Wir haben uns im Vorfeld ein bisschen damit auseinandergesetzt, was man tun kann, auch Kolleginnen befragt. Eine Sache, die ganz spannend ist, ist ein Ansatz, den kennen wir als Softwareentwickler. Ich kannte es nicht. Und ich glaube, die meisten Softwareentwickler kennen das auch nicht, weil das aus der Produktentwicklung kommt. Und ich glaube, Google hat das zuerst ins Leben gerufen. Das nennt sich goals-signals-metrics und das hilft eben, aussagekräftige Produktmetriken zu erstellen. Und worum es da im Kern geht, sind eben die drei Dimensionen goals, signals, metrics. Das heißt, der erste Punkt, wir überlegen uns erstmal intensiv: Welches Ziel soll eigentlich erreicht werden? Was ist eigentlich der Grund für mein Feature? Warum setze ich das um? Wie hilft das den Nutzenden weiter? Und wenn ich das für mich definiert habe, welches Ziel, hoffentlich weiß ich es vorher schon. Aber wenn ich es klar definiert habe, welches Ziel ich erreichen will, dann kann ich aufstellen, welche Indikatoren es dafür gibt, dass dieses Ziel erreicht wird. Oder eben Signale oder signals. Und daraus wiederum kann ich dann Metriken erstellen. Diese Indikatoren kann ich messen. Und durch diese Messung kann ich dann eben Metriken erstellen.
Anja Kammer: Was sind das für Indikatoren, die den Erfolg meines Features messen?
Stefan Negele: Ich versuche mal, da ein Beispiel zu nehmen. Man könnte sagen, für einen internen Mitarbeitenden wird ein Reporting abgelegt, irgendwo einmal am Tag auf meinem File System. Und dann wäre eben der Indikator: Ist das File da? Ein weiterer Indikator wäre: Ist das File erreichbar? Und vielleicht wäre noch ein Indikator: Hat das File die korrekten Daten?
Anja Kammer: Und mithilfe diese Indikatoren, ob die Datei da ist, ob sie die richtigen Daten enthält, wann sie vielleicht sogar geschrieben wurde, da können wir eine Aussage darüber treffen, ob das Ziel erreicht wurde, den Report zu erstellen und verfügbar zu machen.
Stefan Negele: Ja.
Anja Kammer: Ja, ich glaube auch, das hat auch viel mit der Unternehmensstrategie oder mit der Produktstrategie zu tun. Welche Strategie verfolgt dieses Produkt? Ist es besonders leicht nutzbar, besonders schnell? Dann muss ich das auf jeden Fall messen. Wenn es besonders schneller sein soll als ein anderes Konkurrenzprodukt, dann muss ich das Konkurrenzprodukt messen und dann messe ich idealerweise auch mein Produkt, weil ich will ja schneller sein. Aber im Grunde weiß das dann der oder die Product Ownerin.
Stefan Negele: Ich wollte es gerade sagen, weil du gerade eben mit dem Beispiel kamst: Ist mein Produkt schneller als das von der Konkurrenz? Und sowas kennen wir in der Software Architektur dann doch sehr gut. Sowas finden wir auf jeden Fall in unseren Qualitätszielen oder in unseren Qualitätsszenarien wieder.
Anja Kammer: Normalerweise erstellen wir Metriken und Alerts anhand von unseren Qualitätszielen. Wenn wir eine gute Softwareentwicklung machen, wenn wir eine gute Architekturarbeit leisten, dann setzt man sich mindestens am Anfang eines jeden Software-Projektes hin und definieren erstmal die Qualitätsziele. Soll mein Produkt besonders fehlertolerant sein? Soll es besonders sicher sein? Soll die Usability besonders hoch sein? Soll es besonders performant sein? Es kommt darauf an, die Performanz muss für das eine Produkt nicht so hoch sein, für das andere ist es aber super entscheidend. Ein schlechtes Beispiel, finde ich. Aber es ist ein Beispiel, zum Beispiel für den Hochfrequenzhandel im Aktienmarkt. Da ist die Performance super wichtig entscheidend. Für normale Endnutzenden Anwendungen ist es häufig gar nicht so entscheidend, wie hoch die Performance ist. Wichtiger ist, dass den Kundinnen gesagt wird, wann ihre Aufgabe fertig bearbeitet wurde, beispielsweise. Das kann asynchron abgefrühstückt werden, wobei es bei dem Hochfrequenzhandel wichtig ist, dass sofort Ergebnisse gezeigt werden. Das ist wieder eine Produktentscheidung. Das können wir als Entwicklungsperson nicht machen. Das können wir als Architekten nicht machen. Das ist wieder eine Produktentscheidung. Aber wir müssen uns aufstellen in unseren Qualitätszielen. Und wir sind auch diejenigen, die gemeinsam mit der Produktentwicklung, gemeinsam mit dem POs erarbeiten, in welchen Szenarien wie die Performance zum Beispiel aussieht. Beispielsweise zwischen 8:00 Uhr bis 17:00 Uhr am Tag und zwar für die deutsche Zeitzone zum Beispiel. Wann greifen unsere Nutzenden auf die Anwendung zu? Das heißt zwischen 8:00 Uhr bis 17:00 Uhr greifen unsere Nutzenden zu. Das ist die Zeitzone XY. Und zu dieser Zeit sollen 95% aller unserer Requests unter 200 Millisekunden für die gesamte Applikation beantwortet werden. Oder falls wir zum Beispiel ein Onlineshop anbieten, dann soll 95% aller Suchanfragen innerhalb von soundsoviel Millisekunden beantwortet werden. Der Checkout muss nicht ganz so schnell sein, weil der Checkout, da ist den Leuten die Korrektheit wichtiger als die Performance wichtiger. Und so definieren wir unsere Qualitätsziele und anhand dessen definieren wir Szenarien, die unsere Qualitätsziele mit messbaren Indikatoren ausstatten. Und diese Szenarien nehmen wir dann für unsere Observerability her, damit wir überprüfen können, ob unsere Qualitätsziele auch erreicht sind. Das ist die normale Art und Weise, wie wir heutzutage unsere Observerability erstellen sollten. Es ist ähnlich zu dem, was wir gerade gesagt haben. goal-signal-metrics, aber weniger produktbezogen, weil auch in diesem Qualitätszielen können Dinge drin sein, die die Kundinnen gar nicht interessiert.
Stefan Negele: Ja, zum Beispiel Wartbarkeit der Software. Das ist dem Kunden relativ egal. Was heißt relativ, komplett egal, nur indirekt relevant, wenn er schnell neue Features will. Aber das ist denen ja egal
Anja Kammer: Genau, die Wartbarkeit ist für viele Unternehmen wichtig, weil es eben Teil des Unternehmensziels ist. Warum? Weil dann irgendwie schneller für Features entwickelt werden können oder weil die Entwicklungsteams dann besonders zufrieden sind. Ich möchte auf jeden Fall einen wartbaren Code haben und wenn ich zufrieden bin, arbeite ich gerne für meinen Arbeitgeber. Das bedeutet, das Unternehmen kann Know-how bei sich behalten. Das kann Teil eines Unternehmensziels sein, wenn das Unternehmen mitbekommt: Ah, Fachkräftemangel, wir kriegen gar nicht so viele gute Menschen. Es wäre gut, wenn wir die guten Mitarbeiterinnen, die wir haben, auch behalten können. Dann wäre Wartbarkeit natürlich ein gutes Qualitätsziel.
Stefan Negele: Es geht natürlich auch um die Vermeidung von Fehlern bei Wartbarkeit. Software, die nicht gut wartbar ist, hat oft Fehler und ist dann auch wieder indirekt schlecht für die nutzende Person.
Anja Kammer: Ich habe noch eine Frage mitgebracht von meinem Kollegen Sven Johann. Ich würde die gerne mal vorlesen. Und zwar hat er gesagt: Ein wirklich hartes Problem ist zu definieren, wann die Mehrheit der Nutzenden so langsam unglücklich über Performance oder Verfügbarkeit wird. Das kann ein unlösbares Problem in manchen Kontexten sein. Das stimmt. Wie wollen wir so Szenarien erstellen, wenn wir gar nicht wissen, was unsere Nutzenden eigentlich erwarten?
Stefan Negele: Das Wissen daraus ist aber schon sehr wichtig für SLOs und SLAs.
Anja Kammer: Genau, bei den SLOs, also Service Level Objectives, da formuliert man auch die Erwartungshaltung der Anwenderinnen. Aber wie Sven schon gesagt hat, das ist super schwierig, das überhaupt zu wissen. Das heißt, es ist ein iterativer Prozess. Man kann es nicht von heute auf gleich genau wissen, was die Erwartungshaltung der Kundinnen ist. Sie wissen es manchmal sogar selber nicht.
Stefan Negele: Was hier ganz wichtig ist, auf jeden Fall interessiert den Kunden nicht, ob irgendwo ein Server läuft. Das kann man schon mal von vornherein sagen.
Anja Kammer: Genau, oder wie hoch die Festplattenauslastung ist. Wenn wir jetzt bei dem Report Beispiel bleiben. Wichtig ist, dass der Report erreichbar ist. Es ist sogar nicht wichtig, wo dieser Report gespeichert ist. Es ist nicht wichtig, ob dieser Report generiert wurde. Wichtig ist, ob er überhaupt da ist, erreichbar ist, mit den richtigen Daten, wie du gesagt hast. Das heißt die aktuellen Daten, wenn es ein täglicher Report ist. Das bedeutet, eigentlich müsste ich nicht mehr monitoren, ob dieser Job überhaupt gelaufen ist. Wichtig ist, dass das Ergebnis da ist, und zwar, dass der Report mit den korrekten Daten erreichbar ist. Und das ist nämlich genau das, was die Kundinnen interessiert.
Stefan Negele: Und dass er eben für die Kunden auffindbar und unerreichbar ist.
Anja Kammer: Auffindbar und unerreichbar. Genau. Aber ich glaube, das ist ein iterativer Prozess. Genau diese richtigen Messpunkte zu finden. Und man fällt auf jeden Fall oft auf die Nase. Was denkst du, wie oft ich auf die Nase gefallen bin, bis ich die richtigen Metriken identifiziert habe, die wirklich wichtig sind für die Endnutzenden am Ende?
Stefan Negele: Und es ändert sich ja auch. Man hat bei den SLAs, das ist auch ein iterativer Prozess. Man passt das auch ständig an. SLA oder Service Level Agreement ist dann im Endeffekt der Vertrag mit dem Kunden, um das mal kurz zu erklären. Und hier hat man dann auch ständige Anpassungen, Neuverhandlungen und so weiter. Und da muss man seine Metriken auch entsprechend anpassen und anpassen können. Diese Metriken müssen dann auch entsprechend wartbar sein.
Anja Kammer: Vor allem ist es schwierig zu definieren, was überhaupt ein Ausfall ist. Wenn ich zum Beispiel eine Software habe, die viele Features hat, wie viele Features müssen zu langsam oder nicht erreichbar sein oder Fehler produzieren, bis das gesamte Produkt als Ausfall definiert wird? Immer wenn ich anderen diese Frage stelle, also ich führe auch Trainings durch, also Schulungen. Und immer, wenn ich bei diesem Thema bin, bin ich so gemein und frage: Was ist denn überhaupt Verfügbarkeit? Oder was ist denn überhaupt ein Ausfall? Und da wird gesagt: Na ja, wenn die Seite nicht erreichbar ist. Was ist denn schlimmer? Eine Seite ist zu langsam oder nicht erreichbar? Wenn sie zu langsam ist, dann ist man frustriert als Nutzender, oder? Wenn es aber nicht verfügbar ist, dann weiß ich: Ich versuche es einfach später noch mal, obwohl es vielleicht schlimmer ist, wenn der Service gar nicht erreichbar ist. Aber ich warte nicht unendlich darauf, dass irgendwas lädt. Und stelle dir vor, dann lädt etwas und ich mache einen Klick und dann dauert das wieder lange. Das ist doch viel frustrierender, als wenn mir eine Fehlermeldung gezeigt wird. Und das ist die Frage. Die Nutzenden entscheiden: Was ist denn ein Ausfall? Wie viele Features müssen ausfallen oder nicht erreichbar oder zu langsam sein, bis die Nutzenden sagen: Das Produkt ist nicht nutzbar.
Stefan Negele: Mir ist gerade ein ganz gutes Beispiel eingefallen bei Streaming-Anbietern. Die haben oft so Fallback-Szenarien, dass sie zum Beispiel, wenn Recommendations, also wenn man jetzt zum Beispiel auf die YouTube Startseite geht, kriegt man ganz viele Empfehlungen auf sein Profil basierend. Wenn aber zum Beispiel, ich weiß nicht wie YouTube das macht, aber wenn der Recommendations Service ausfällt, dann zeigen die irgendwelche Videos und dann ist jetzt die Frage, da wird es schon kompliziert. Ist das jetzt ein Ausfall? Weil die Seite ist erreichbar, man kann auch Videos abspielen. Das kann ich jetzt auch nicht beantworten.
Anja Kammer: Aber vielleicht bekommst du da eine schlechtere Reputation, weil deine Nutzenden sagen: Was wird mir denn da angeboten? Das ist doch total bescheuert. Vielleicht, wenn da eine Fehlermeldung drin wäre, “die Recommendations können nicht angezeigt werden”, dann wäre vielleicht das Ziel zu sagen: Wir zeigen lieber nicht die Falschen an, statt falsche. Aber das kommt auf das Produkt an.
Stefan Negele: Ja, absolut.
Anja Kammer: Was erwarten meine Nutzenden? Das ist superspannend. Das kann man gar nicht so abschließend bewerten.
Stefan Negele: Nee, da kann man jetzt auch nicht irgendwie sagen: So macht man’s. Wenn wir das könnten, dann wären wir wahrscheinlich sehr reich.
Anja Kammer: Ja, genau. Was ist denn jetzt der Unterschied zwischen diesen ominösen Produktmetriken und technischen Metriken? Kommen wir auch ohne technische Metriken aus?
Stefan Negele: Nein, wir kommen nicht ohne technische Metriken aus, weil irgendwo am Ende eine technische Metrik wahrscheinlich die Grundlage für meine Produktmetrik oder ein Zusammenspiel von technischen Metriken ist. Aber die These ist, dass eine Produktmetrik wichtiger ist als eine technische Metrik, weil die Produktmetrik einem sagt: Was ist kaputt oder was funktioniert? Es muss nicht immer nur negativ sein, kann ja auch positiv sein. Was funktioniert gerade sehr gut? Und eine technische Metrik gibt dir mehr an: Warum funktioniert es nicht oder warum funktioniert es gerade? Wahrscheinlich gibt eine technische Metrik eher an, was gerade funktioniert oder nicht funktioniert. “Ich habe sehr gut funktioniert”. Technische Metriken sind super oft umsonst. Wenn man sich jetzt so ein Framework wie Spring Boot anschaut, dann spuckt dir das technische Metriken eigentlich out of the box aus. Da gibt es so Metriken wie Request Rates auf bestimmte Endpunkte oder Latenzen. Die kann man natürlich verwenden. Dann kann ich mir natürlich anschauen, ob mein Endpunkt benutzt wird und das kann schon auch spannend sein. Oder Fehlerraten, wenn ich zum Beispiel einen Anstieg von 500 Fehlern auf einem Endpunkt habe, kriege schon auch mit, dass da was kaputt ist. Das heißt aber noch nicht, dass irgendwie ein Feature nicht funktioniert oder für den Nutzenden nicht funktioniert. Das ist genau der Unterschied. Die sagt mir eben nicht, was. Sie sagen an der Stelle, welches Detail kaputt ist, aber sie sagen mir nicht, welches Feature nicht funktioniert.
Anja Kammer: Und ob es ein Impact von meinen Features hat. Es kann eine bestimmte Metrik total schrecklich sein, aber es hat überhaupt nichts mit der Funktionalität zu tun.
Stefan Negele: Das Problem kann natürlich sein, weil diese Metriken vielleicht umsonst sind. Übertreibe ich es vielleicht damit? Wenn ich mir ein Dashboard aufbaue, wo alle meine Metriken, die so ein Spring Boot Actuator heißt es, glaube ich, ausspuckt. Das ist vielleicht zu viel. Wahrscheinlich ist das zu viel. Das heißt, auch hier ist dann wichtig: Was interessiert mich wirklich? Und vielleicht interessiert mich so was wie eine Error Rate, weil das vielleicht so ein File Netz ist, das ich irgendwo habe, dass ich alarmiert werde, wenn mein Server nach einem Deployment kaputtgeht. Aber ja, man sollte sich eben genau Gedanken machen: Was nutzt man davon? Eine Frage oder eine These, die wir in einem Vorgespräch aufgestellt haben, war: Ist eine Produktmetrik, dann langsamer? Weil man kann zum Beispiel sagen, wenn die Nutzenden eines Features weniger werden, weiß ich jetzt noch nicht, was der Grund ist. Ich weiß jetzt nicht, ob es vielleicht an einem Bug liegt oder ob es vielleicht einfach daran liegt, weil das Feature irgendwie schlechter geworden ist oder weil es weniger beworben wird.
Anja Kammer: Ja, genau. Und ich muss die Nutzung des Features über die Zeit beobachten. Und das kann ich erst retrospektiv erahnen, ob die Nutzung runtergeht. Bei so einer Fehlerrate oder bei der Messung von Fehlern bekomme ich sofort ein Ergebnis: Da ist irgendetwas. Wenn es einen Grund gibt, weshalb dieses Feature nicht mehr verwendet wird und der Grund ist, wie du gesagt hast, ein Bug und dieser Bug zeigt sich auf keine Art und Weise. Dieser Bug produziert keine Exception, kein Fehler, ist total still, ist aber ein Bug, sodass dieses Feature nicht verwendet werden kann. Und stell dir vor, wir haben keine manuellen Tests, Szenarien oder niemand testet mal manuell durch, ob wirklich alle Features funktionieren. Dann ist mein einziger Indikator, dass es da irgendein Problem gibt, dass dieses Feature nicht mehr verwendet wird von den Nutzenden, weil die wissen, durch ihre Nutzung zeigen sie uns: Wir können es gar nicht benutzen, weil man kommt nicht durch, weil dieser Button ist gar nicht klickbar oder Ähnliches und es wird kein Fehler produziert. Das bedeutet, es dauert eine Weile, bis wir sehen, ob dieses Feature kaputt ist. Aber wir haben wenigstens die Möglichkeit zu erahnen, ob das Feature kaputt ist. Weil kann ja sein, dass keine Fehler produziert werden.
Stefan Negele: Absolut.
Anja Kammer: Und wir kriegen es auf keine andere Weise mit.
Stefan Negele: Das heißt, man kann sagen, eine Produktmetrik ist vielleicht manchmal langsamer, aber vielleicht ist sie auch wirklich die einzige Metrik, die wir haben können, um was zu erkennen.
Anja Kammer: Genau, richtig. Das ist mir ist bei diesen Jobs, bei Batch Prozessen, die regelmäßig laufen, so oft passiert. Ein Job lief, hat kein Fehler produziert, hat aber auch kein Ergebnis produziert. Und dann ist es wichtig, dass man nicht misst: Der Job lief und es gab keine Fehler. Der Job war erfolgreich. Man darf diese Annahmen nicht treffen.
Stefan Negele: Okay, ich glaube, wir sind jetzt so ein bisschen da rein reingekommen in Produktmetriken und Nutzung eines Features. Das geht so ein bisschen in die Richtung Business Metriken. Und dann muss man sich fragen: Wie grenzen sich diese Produktmetriken, die wir jetzt hier nennen, eigentlich von Business Metriken für ein BI Team ab?
Anja Kammer: So ein BI Team ist ein Team für ein gesamtes Unternehmen oder für eine Produktlinie, oder?
Stefan Negele: In unserem Kontext, der Einfachheit halber glaube ich, machen wir das mal so. Da hat ein Kollege, der Timo Loist, folgende Frage dazu gestellt: Wie grenze ich Produktmetriken von BI Reports ab, die es in der Regel zusätzlich noch gibt? Und warum stellen sie einen erheblichen Mehrwert dar? Ich glaube, grundsätzlich kann man sagen, dass BI meistens eine Betrachtung im Nachhinein ist. Es ist eigentlich immer eine Betrachtung über Zeit. Was nicht heißt, dass unsere Produkte nicht auch eine Betrachtung über Zeit sind. Und oft kann man sagen, BI ist nicht so zeitkritisch.
Anja Kammer: Ich brauche für BIs keine Alerts, weil es gibt keine Business-Analysten, die irgendwie reagieren müssen, weil die Nutzung zum Beispiel von einem Feature komplett runtergegangen ist.
Stefan Negele: Ich glaube, die Tools bieten das auch an. Bestimmt gibt es das, aber ist mir jetzt noch nicht untergekommen.
Anja Kammer: Und wenn es das gebe, dann muss man eher ein strategisches Meeting einberufen. Als einzelner Business Analyst kann man wenig machen, wenn irgendwelche Metriken nicht so aussehen, wie man es gerne hätte, weil sie sehr produktbezogen oder strategiebezogen sind. Und der Unterschied zu den Metriken, die Entwicklungsteams eigentlich interessiert. Bzw. Wenn es Alerts gibt für Entwicklungsteams, dann muss man normalerweise sofort etwas tun und jede einzelne Person kann einen Incident fixen. Das ist schon ein Unterschied.
Stefan Negele: Die Reaktion ist auf jeden Fall etwas, an der kann man es auf jeden Fall festmachen. Die Reaktion muss meistens zeitnah sein, auch nicht immer. Wobei bei einem Alert von einem Feature Team, da muss die Reaktion zeitnah sein. Wenn ein BI Team ein Alert bekommen sollte, dann ist es wahrscheinlich nichts, was sofort passieren muss. Die steile These stelle ich jetzt mal auf. Aber natürlich bewegen wir uns hier in der Grauzone. Wir haben ja vorher gesagt, wir sind als Softwareentwicklerinnen auch Produktentwicklerinnen.
Anja Kammer: Ja.
Stefan Negele: Vielleicht wollen wir eben deswegen auch Reports haben. Wie eben auch gerade gesagt im Kontext der technischen Metriken. Wir wollen halt vielleicht wissen, wie unser Feature genutzt wird und ob es sich dann lohnt, dieses Feature weiterzuentwickeln. Vor allem der Product Owner will das mit Sicherheit wissen, um zum Beispiel Priorisierungen vornehmen zu können. Dann muss ich mich irgendwie dann fragen als Entwicklungsteam: Welche Metriken will ich da im zeitlichen Verlauf sehen? Und bei welchen Metriken interessiert mich der aktuelle Wert? Und bei solchen Produktmetriken interessiert mich dann eben als Entwicklungsteam dann auch einerseits Metriken im zeitlichen Verlauf und gleichzeitig eben Metriken, die nur einen aktuellen Wert darstellen. Ich mache mal ein Beispiel, wo beides drin ist, um genau diesen Unterschied aufzuzeigen. Es geht jetzt um die Firmware von IoT Geräten. Und ich habe zum Beispiel rausgefunden im zeitlichen Verlauf, dass bei Geräten mit einer bestimmten Firmware die Fehlerrate besonders hoch ist. Das ist eben Reporting, das weiß ich, das kann ich dann irgendwie in meine Produktentwicklung einbinden. Und ich kann aber auch zum Beispiel einen Alert drauf setzen, wenn ich sehe: Oh, hier registriert sich gerade ein Produkt zur alten Firmware und das dann zum Beispiel zu einem Update zwingen oder was auch immer. Aber vielleicht sage ich auch: Oh, da registrieren sich gerade 200 Produkte mit einer alten Firmware. Vielleicht kann ich das Gerät nicht zu einem Update zwingen. Ich muss jetzt irgendwie eine andere Maßnahmen ergreifen. Ich muss da vielleicht einen Techniker hinschicken und dieses Update manuell durchführen und habe dann vielleicht eben einen Incident vermieden, weil das Problem vielleicht erst nach einer Woche aufgetreten wäre. Man kann das so ein bisschen als BI auf Domain Ebene vielleicht betrachten. Da geht es um eigenverantwortliche Produktentwicklung. Wenn ich irgendwie mein Produkt owne, wenn ich meine Domäne owne, dann ist eben eigenverantwortliche Produktentwicklung enorm wichtig. Solche Zahlen sind dann eben sehr wichtig für mich als Team.
Anja Kammer: Aber diese Zahlen sind auch sehr wichtig für das Unternehmen, oder?
Stefan Negele: Absolut. Natürlich können diese Sachen Mehrwert für andere Teams darstellen und da kann man sich dann überlegen, ob man diese Sachen eben anderen Teams zur Verfügung stellt. Ich will da jetzt nicht zu detailliert darauf eingehen, aber man könnte da eben dann so Gedanken aus dem Data Mesh Bereich nutzen oder sich überlegen, baut man vielleicht ein Data Mesh auf oder stellt man ein Tooling für Data mesh bereit?
Anja Kammer: Kannst du noch mal kurz Data Mesh erklären?
Stefan Negele: Ich will hier nicht so tief darauf eingehen, aber in einem Data Mesh hat man die Möglichkeit Datenprodukte oder Data Products zu erstellen, die man anderen Teams zur Verfügung stellt, um eine Mentalität in der Organisation einzuführen, datengetrieben zu arbeiten. Darüber reden wir jetzt gerade so ein bisschen. Wir haben Daten, wir werten die aus und arbeiten dann datengetrieben. So ein Datenprodukt kann man eben anderen Teams oder auch einem BI Team dann zur Verfügung stellen. Man kann die miteinander kombinieren. Das ist so ein Prinzip, worum es geht. Es geht noch um viel mehr. Ich würde da aber jetzt ungern weiter darüber sprechen. Wir haben vor ein paar Wochen einen Podcast dazu veröffentlicht. Hört euch den vielleicht an.
Anja Kammer: Alles klar, werden wir dann in den Shownotes verlinken.
Stefan Negele: Super, okay.
Anja Kammer: So, wir haben über viele Dinge gesprochen. Wir hatten aber auch darüber gesprochen, dass wir diese Produktmetriken nicht nur für Reporting brauchen, sondern auch, um Incidents zu erkennen. Lass uns doch über Incidents noch mal genauer sprechen, denn das ist auch das, was Entwicklungsteams besonders interessiert, weil Incidents im Grunde Fehler in dem ist, was sie produziert haben. Daten aktualisieren sich nicht oder irgendeine Einstellung in der UI, die vorgenommen wurde, ist nicht aktiv. So Sachen kriegt man schwer raus mit technischen Metriken. Oder Features nicht verfügbar, da hatten wir schon öfter gesprochen, wie man das definieren kann. Solche Dinge, alles, was irgendwie mit dem Produkt zu tun hat, mit der Funktionalität des Produkts zu tun hat, sind Incidents, die durch Produktmetriken erkannt werden können. Und wenn wir das erkennen, wollen wir Alerts haben. Und Alerts ist, finde ich immer ein sehr wichtiges Thema, denn das ist genau das nächste, worum ich mich kümmern muss. Nachdem ich es geschafft habe, wirklich sinnvolle Metriken zu finden, ist es wichtig, dass auch meine Alerts den richtigen Kontext geben. Es gibt ein Prinzip, das heißt: Alerts sollten concise, articulate, accurate, digestible und actionable sein. Aber das sind alles Worte, mit denen kann man kaum was anfangen. Deswegen erkläre ich das gerne. Ich definiere jetzt mal was, was für mich good alerts sind. Good alerts sagen mir, was das Problem ist. Und zwar nicht, dass ein Job nicht lief, sondern das Problem ist anhand von unseren Goals-Signals-Metrics, der Alert sagt mir: Der letzte tägliche PDF-Report ist zu alt bzw. wurde nicht gefunden. Das ist dieses Beispiel, was wir hatten mit dem PDF Report. Also, ein good alert sagt mir, was das Problem ist. Ein good alert sagt mir aber auch, wo genau das Problem aufgetreten ist. Und zwar, dieser Report in der Pod Umgebung war nicht zu finden, und zwar für Kundin XY. Denn dieser Report wird vielleicht für alle meine Kundinnen, für alle meine Nutzenden erstellt. Und genau für diese Kundin, in dieser Umgebung konnte der Report nicht gefunden werden. Oder der war zu alt der letzte. Good alerts sagen mir dann auch, was gemessen wurde, um diesen Alert zu produzieren. Beispielsweise steht in dieser Alert-Nachricht dann drin: Gemessen wurde zum Beispiel, das S3 bucket im Pod enthält den Report von heute nicht. Und gemessen wurde seit 12:00 Uhr mittags. Und es gibt eine automatische Messung alle fünf Minuten. Und das ist die Metrik, die entscheidet, ob dieser Alert gefeuert wird oder nicht. Und zwar seit 12:00 Uhr mittags ist dieser aktuelle Report nicht erreichbar. Und es wird alle fünf Minuten gemessen. Als Nächstes gibt mir ein good alert einen richtigen Kontext. Der Report wird täglich 1:00 Uhr nachts generiert von dem Job XY. Da ist eine ID von dem Job. Das bedeutet, ich weiß, wo ich nachschauen muss.
Stefan Negele: James Turnbull schreibt im “The Art of Monitoring” ganz explizit, dass so ein Kontext immer von einem Menschen gegeben werden muss. Das ist eben an der Stelle, glaube ich, ganz relevant zu erwähnen.
Anja Kammer: Ja, na klar. Dass seit 12:00 Uhr mittags kein Report da ist, heißt nicht, dass der Report um 1:00 Uhr nachts von Job XY produziert wird. Also was vollkommen anderes, wie es gemessen wird und was der Kontext ist. Denn es ist nicht so wichtig, ob seit 1:00 Uhr nachts bis 12:00 Uhr der Report nicht da ist. Wichtig ist, dass er ab 12:00 Uhr da ist. Warum ist das wichtig? Weil die Kundschaft ab 12:00 Uhr den Report erwartet und nicht schon um 1:00 Uhr nachts. Und daran messe ich nämlich, ob etwas schiefgelaufen ist oder nicht. Aber es kann super viele technische Fehlerquellen geben, warum dieser Report nicht da ist oder länger gebraucht hat. Wenn er länger gebraucht hat, ist es nicht so wichtig. Wenn es innerhalb des Rahmens ist, aber wenn er nicht generiert wurde. Genau, ich weiß gar nicht, ob er nicht generiert wurde. Vielleicht wurde er generiert, aber man konnte ihn nicht ablegen, weil…
Stefan Negele: Die Festplatte voll war.
Anja Kammer: Die Festplatte war voll. Oder irgendjemand hat die Firewall Einstellungen konfiguriert und zufälligerweise konnte der Job nicht auf das S3 Bucket zugreifen. Es gab ein Timeout. Vielleicht gab es einen Timeout. Das wurde nicht als Fehler erkannt, kam nicht in meinem Error Monitoring raus und dementsprechend habe ich es nicht mitbekommen, dass da nichts abgelegt wurde. So Sachen. Genau, das sind aber technische Fehlerquellen, die der Alert nicht unbedingt geben kann. Es gibt so viele Fehlerquellen, so viele mögliche Fehlerquellen, dass es eine Person braucht, um das herauszufinden. Aber man sollte versuchen, bei dieser Alert-Nachricht so viel Kontext wie möglich zu geben, woran es vielleicht liegen könnte. Welcher Job führt es aus und wann wird er generiert und wo wird er abgelegt? Das ist wichtig in dem Fall. Einige Observability Tools geben auch die Möglichkeit, Links hinzuzufügen zu dieser Alert-Nachricht. Links zu den Logs des Jobs oder einen Link zu der Cloud Console, die direkt zu den betreffenden Jobs weiterleitet. Das sind alles Dinge, die muss man einmal einstellen. Jedes Mal, wenn der Alert gefeuert wird, wird das als Link mitgegeben, um ganz schnell im Incident Fall auf diesen Link klicken zu können und schnell eine Fehleranalyse durchführen zu können. Und gute Alerts sind dringend. Und die muss ein Mensch fixen, weil sie nicht automatisiert behandelt werden können, wie beispielsweise die Festplatte noch mal aufräumen, damit doch noch ein Report draufpasst. Das ist etwas, das könnte man automatisieren, wenn man wüsste, dass das das Problem war.
Stefan Negele: Genau, da fällt mir auch noch was anderes ein, passend zum Thema Alerts vor allem, was dann eher eine menschliche Konsequenz ist als eine technische. Und zwar das Thema Alert Fatigue. Das bedeutet, dass es eben vielleicht zu viele irrelevante Alerts gibt. Und die führen dann eben zur Nichtbeachtung von Alerts oder zum Übersehen von wichtigen Alerts. Vielleicht habe ich ganz viele Alerts, die uninteressant sind, vielleicht habe ich zu einem Problem irgendwie fünf Alerts. Da muss ich Dinge zusammenfinden. Ich glaube, eine schöne Analogie ist die Fabel von dem Hirtenjungen und dem Wolf.
Anja Kammer: Erzähl!
Stefan Negele: Da geht es darum, dass es diesen Jungen gibt, der immer schreit: “Oh, Wolf! Oh Wolf!” Ich weiß es nicht genau. Aber: “Oh, Wolf! Oh Wolf!” Und alle haben Angst und rennen hin und versuchen zu retten. Und es war aber gar kein Wolf. Und irgendwann kommt dann wirklich mal ein Rudel Wölfe. Und er sagt: “Oh, Wolf! Oh Wolf!” und wird dann gefressen, weil keiner mehr kommt. Das ist eine recht alte Fabel. Ich weiß nicht, von wann die ist, aber die ist bestimmt schon älter. Das heißt, diese Problematik gibt es nicht nur in der Softwareentwicklung, sondern die ist ein altes Problem der Menschheit.
Anja Kammer: Eine typische Horrorfabel. Schrecklich.
Stefan Negele: Sorry. Vielleicht sollten wir Triggerwarnungen vorher machen.
Anja Kammer: Nee, aber das ist glaube ich sogar das schlimmste Problem, wenn man über Observability und Alerting spricht. Dass Menschen Alerts ignorieren, aber auch zurecht ignorieren. Du hast es auch gesagt, wenn 15 Alerts kommen zu dem selben Fehler, dann sieht man vielleicht den anderen Alert, der sogar noch viel wichtiger ist, gar nicht mehr dazwischen, weil der sich da versteckt hat. Und man denkt, alle Alerts beziehen sich auf den Incident, den wir eh schon auf dem Schirm haben und der ist nicht so wichtig oder wird gerade bearbeitet. Aber da ist noch was anderes und man sieht es nicht. Das kann man ganz einfach lösen durch Alert Grouping, das haben viele Observability Tools. Dass Alerts, die zu einem ähnlichen Fehler zugeordnet werden können, gruppiert werden und wenn jetzt zum Beispiel drei Alerts ein Problem mit einem Feature bezeichnen, dass man diese gruppiert. Und wenn einer dieser Metriken dann negativ ist, dass nur ein Alert kommt und wenn alle drei Metriken sagen: Achtung, hier ist ein Problem, immer noch nur eine Alert kommt. Dass man weiß: Okay, das ist jetzt ein Alert, bezieht sich auf dasselbe Feature und hier wird mein Slack Channel oder Teams Channel jetzt nicht überlastet mit total vielen Notifications. Das ist eine Möglichkeit, Alert Grouping zu machen. Oder auch sich zu überlegen: Welche Alerts sind wirklich notwendig? Welche Dinge wie beispielsweise Festplattenauslastung kann ich verschieben oder kann ich anders messen oder kann ich wegautomatisieren?
Stefan Negele: Oder wie kritisch ist ein Alert?
Anja Kammer: Genau.
Stefan Negele: Zum Beispiel von dem Report von dir gerade. Ist es denn wichtig, dass dieses Dokument wirklich exakt um 12:00 Uhr liegt? Oder ist es vielleicht auch okay, wenn er erst fünf Minuten später kommt? Sowas muss man sich überlegen.
Anja Kammer: Das habe ich auch aus der Praxis total oft. Ich habe häufig, Schande auf mein Haupt, ein Alert erstellt, der genau nach 24 Stunden erwartet hat, dass irgendwas passiert ist. Und am Ende war es eine Minute später und der Alert wurde selbstständig wiederresolved und hat aber den Slack Alerts Channel vollgespammt mit einem Alert und 5 Minuten später wurde es dann wieder resolved. Alles gut. Der Report wurde gefunden. Oder: Das Ergebnis ist jetzt da. Das fand ich total sinnfrei.
Stefan Negele: Lass mich raten, das kam jeden Tag vor und irgendwann hat keiner mehr mittags Alerts ernst genommen.
Anja Kammer: So schlimm war es nicht. Also alle paar Wochen passierte das. Aber du hast recht, das führt dazu, dass die Leute Alerts ignorieren und das sollte man auf jeden Fall vermeiden, damit Alerts auch sinnvoll sind und beachtet werden. Das hört sich komisch an, man könnte ja auch einfach sagen: Wieso? Diese Leute werden bezahlt, die sollen sich jeden verdammten Alert angucken. Aber nein, man kann es den Leuten auch einfacher machen.
Stefan Negele: Man hat ja auch andere Dinge.
Anja Kammer: Ja, natürlich.
Stefan Negele: Man sollte eigentlich am liebsten neue Features entwickeln. Oder Fehler beheben.
Anja Kammer: Genau.
Stefan Negele: Aber nicht im Slack Channel oder im Teams Channel lesen und kryptische Alerts entziffern.
Anja Kammer: Sehe ich genauso. Gut, Produktmetriken können dazu führen, dass wir sinnvolle Alerts erstellen. Aber wir können Alerts auch für was anderes benutzen, und zwar unsere Nutzenden müssen natürlich auch informiert werden, wenn es Probleme gibt, dass es ein Problem gibt.
Stefan Negele: Da haben wir natürlich mehr Möglichkeiten, wie wir das machen können. Was relativ einfach ist und was man vielleicht automatisieren kann sogar, ist, wenn man eine Webseite betreibt, das dann dort darzustellen, einfach eine Meldung hinzuschreiben, wo steht: Feature XY funktioniert gerade nicht. Oder man betreibt so was wie eine Statusseite. Man kennt das zum Beispiel von GitHub. Oder vielleicht kann man das auch über Social-Media-Kanäle machen. Das kann vielleicht auch automatisiert werden, über Bots zum Beispiel.
Anja Kammer: Genau. Und da wäre es natürlich wichtig, dass nur die Alerts zu solchen Meldungen führen, die auch etwas mit dem Produkt zu tun haben, die wirklich die Nutzer interessieren.
Stefan Negele: Ja, absolut. Und hier wäre es natürlich absolut schrecklich, wenn das voll gespammed wird. Also wenn jetzt mein mein Social Media Feed plötzlich voll ist mit irgendwelchen random Sachen. Ich glaube da ist wahrscheinlich auch schon vorgekommen, aber wahrscheinlich nicht so oft. Aber vielleicht, wenn ich jetzt zum Beispiel Mitarbeitende in Kundennähe habe, dann sollte ich denen auf jeden Fall etwas mitgeben. Oft ist ein Incident auch nichts, was ständig passiert und nichts, wo es sich wirklich lohnt, das zu automatisieren. Oder ist es was, was neu passiert? Dann habe ich wahrscheinlich noch keine Automation und dann muss ich mir auch einfach überlegen: Wer ist denn jetzt davon betroffen? Und wenn ich nicht die Personen, die betroffen sind, nicht direkt ansprechen kann, kann ich vielleicht Personen ansprechen, die Kontakt zu diesen Personen haben. Mitarbeitenden in Kundennähe, in der Filiale zum Beispiel. Oder in der Hotline. Vielleicht ist es aber auch irgendwie so was Simples, wenn ich jetzt ein Schild aufstelle in meiner Filiale und sage: Hey, meine Geräte hier, die funktionieren gerade nicht. Oder: Die haben gerade längere Reaktionszeiten. Das hilft dann Nutzenden auf jeden Fall. Und nebenbei verbessere ich auch noch mein Produkt und den Service.
Anja Kammer: Auf jeden Fall.
Stefan Negele: Die Leute sehen: Hier läuft vielleicht was schief, aber wenn sie proaktiv informiert werden, dann gibt das denen einfach ein besseres Gefühl.
Anja Kammer: Das ist total einfach. Man ist nicht sauer, wenn man proaktiv informiert wird, wie du schon sagtest. Aber wie kann ich denn die Vorort-Mitarbeitenden informieren als Entwicklungsteam? Normalerweise habe ich doch überhaupt gar keinen Kommunikationskanal zu diesen Vorort-Mitarbeitenden. Ich muss mir wirklich überlegen: Wann hatte ich zu Vorort Mitarbeitenden einen Kommunikationskanal? Eher nicht. Hattest du in deinen Projekten einmal einen direkten Kommunikationskanal?
Stefan Negele: Nee, es ist eher schwierig. Klar, wenn man jetzt weiß, in Filiale 17 funktioniert irgendwas nicht, kann man sich theoretisch bestimmt über einen Active Directory die Telefonnummer rausholen. Mit Sicherheit. Aber ich würde sagen, im Normalfall geht so was. Entweder baut man einen Kommunikationskanal auf oder man geht irgendwie über einen First Level Support oder so. Das wäre wahrscheinlich ein Weg, den man gehen kann. Einfach gucken, wer wäre eine Person, die da zuständig ist, mit der man vielleicht einen regelmäßigeren Kontakt hat?
Anja Kammer: Ja. Es ist super schwierig. Das heißt, man muss von Anfang an diesen Kommunikationskanal mitdenken. Das bedeutet, wenn von der Produktentwicklung mir ein Feature übermittelt wird für die Entwicklungsteams und diese Entwicklungsteams sich überlegen: Wie implementieren wir das Feature? Aber wie kann es auch schiefgehen und wie informieren wir unsere Kundinnen, wenn es schiefläuft? Genau in dieser Phase, also beim Refinement müsste ich theoretischer Weise mir genau diese Dinge überlegen und dann sagen: Achtung, für dieses Feature im Fehlerfall brauchen wir einen Rückkanal zu Mitarbeitenden vor Ort.
Stefan Negele: Ja, oder wir brauchen einen Ansprechpartner. Da wird dann ganz schnell ein soziales Problem oder ein organisatorisches Problem daraus.
Anja Kammer: Genau, ein organisatorisches Problem. Du musst auf einmal Strukturen schaffen, die so gar nicht vorgesehen sind. Und wenn wir schon über Refinement sprechen. Auch bei dem Refinement hatte ich schon gesagt, sollte ich nicht nur darüber sprechen, wie ein Feature funktioniert, nicht nur die Happy Path beschreiben, sondern auch: Was passiert, wenn es zum Fehlerfall kommt? Vielleicht kann ich schon bestimmte Fehlerfälle, wie beispielsweise, wenn wir jetzt wieder über diesen PDF-Report sprechen, diesen Fehlerfall. Es gibt so viele Möglichkeiten, dass dieser Report irgendwie nicht zur richtigen Zeit an der richtigen Stelle ist. Das heißt, ich muss definieren: Was passiert, egal weshalb, dieser Report nicht zur richtigen Zeit an der richtigen Stelle? Und auch das sollte ich beim Refinement besprechen, damit es in das Ticket kommt, damit die Person, die sich das Ticket nimmt, neben der Feature Implementierung auch die richtigen Metriken sammelt, sie an das Observerability Tooling anschließt und dort auch einen ordentlichen Alert erstellt, weil die Person, die dieses Feature entwickelt hat, hat den gesamten Kontext, um den richtigen Alert zu schreiben. Und da sind wir wieder bei DevOps. Bei DevOps geht es nicht darum, dass zwei Leute miteinander reden. Da geht es darum, dass die Person, die ein Feature entwickelt, auch dafür zuständig ist, dass im Betrieb, wenn etwas schief läuft, man es mitbekommt und vielleicht sogar fixen kann.
Stefan Negele: Absolut.
Anja Kammer: Ist das zu viel verlangt?
Stefan Negele: Nein, ich glaube nicht. Ich bin der Meinung, wenn ich ein Produkt entwickle und das owne, dann sollte das auch in meinem Interesse sein. Weil unterm Strich nimmt es einem dann Arbeit ab. Das ist ja, was ich vorher meinte. Wenn ich meine Zahlen habe und mit denen dann arbeiten kann, dann kann ich auch erstens schneller Probleme ausfindig machen, Probleme finden und wenn die Fehlerbehebung schnell geht, dann habe ich wieder mehr Zeit für das, was Spaß macht und das ist wahrscheinlich Features entwickeln. Und sich neue Dinge ausdenken. Von dem her glaube ich nicht, dass es zu viel verlangt ist, sondern ich glaube eher andersherum. Man sollte das fürs eigene Seelenheil tun.
Anja Kammer: Ich habe auch ein Zitat mitgebracht von Accelerate, diesem Buch. Da geht es auch um Performance von Teams, auch im DevOps Kulturgedanken. Und da steht drin, ich habe es übersetzt. “Proaktives Monitoring für mehr Transparenz und Sichtbarkeit korreliert direkt mit Team-Performance und Zufriedenheit bei der Arbeit.” Das kommt aus Kapitel sieben und zehn. Also da haben wir es wieder. Auch dieses Accelerate Buch, welches sozusagen eine Studie angestrengt hat, kommt zu dem Ergebnis, dass die Teams auch zufriedener sind, wenn sie eben proaktiv monitoren, mehr Transparenz und Sichtbarkeit haben.
Stefan Negele: Spricht mir aus der Seele.
Anja Kammer: Ja, das ist auch das, was ich überall sehe, in anderen Unternehmen, denen wir helfen oder wenn wir Architektur Reviews machen. Da gibt es sehr häufig das Problem, dass Entwicklungsteams sich beschweren, dass sie keine Sichtbarkeit haben, schlechtes Monitoring Tooling oder eigene Metriken nicht erstellen können. Und dann sagt das Management: Naja, aber ihr habt doch diesen Agenten, der automatisiert technische Metriken sammelt. Das sollte euch doch ausreichen. Nein, tut es nicht.
Stefan Negele: Nein, natürlich nicht.
Anja Kammer: Es reicht nicht.
Stefan Negele: Absolut. Und ich glaube, die Gründe dafür haben wir jetzt vorhin auch besprochen. Diese automatisierten technischen Metriken, die sind umsonst, sozusagen. Jetzt gibt es einen Agent, der macht das für einen. Ja, aber mit dem kann man nicht so viel anfangen. Bzw. mit denen macht es auch nicht unbedingt Spaß zu arbeiten. Wer quält sich gerne doch auch irgendwie in eine Log-Datei, wenn man noch nicht mal weiß, wonach man suchen muss? Wenn man dann aber irgendwie einen schönen Alert bekommt und dann eben da drinsteht: Das ist schiefgelaufen und dann vielleicht Kontext: Hey, suche doch mal danach, dann geht man vielleicht auch irgendwie ins Log Tool und sucht dann irgendwie nach einem bestimmten Keyword und findet es dann vielleicht schon.
Anja Kammer: Ich habe da eine Analogie, die ist uns eingefallen, als wir generell über dieses Thema gesprochen haben und uns überlegt haben: Wie schreibe ich denn sinnvolle Alerts für meine Produktmetriken? Und dann ist uns in den Sinn gekommen: Wir können eine Analogie ziehen zur Testpyramide. Da gibt es auch Unit-Tests, die sind billig und die sind schnell zu schreiben und man kann viele davon schreiben und sie sind immer noch billig in der Ausführung. Und dann gibt es End-to-End Tests, die sind super aussagekräftig, weil sie eben das Endergebnis messen, wie wir halt eben auch bei unseren sinnvollen Alerts für Produktmetriken auch das Endergebnis messen, ob das für die Nutzenden da ist. Genauso sind End-to-End Tests sehr ähnlich, dass sie anhand von kritischen User Journeys messen, ob die Erwartung der Nutzenden erfüllt wurde, ob deren Aufgabe erfüllt werden konnte. Die sind aber auch sehr teuer. Das heißt, man versucht so wenig End-to-End Tests wie nur möglich zu schreiben und nur anhand von wirklich kritischen User Journeys, damit nicht irgendein beliebiges Mini-Feature die größte Cashcow kaputt machen kann. Das wir wenigstens da so ein kleines Fallnetz haben. Und genauso würde ich das auch mit Produktmetriken sehen, wie wir es definiert haben. Die sind auch teuer. Warum sind sie teuer? Weil sie nicht trivial sind. Es sind nicht einfach nur technische, triviale Metriken, beispielsweise: Lief ein Job? Sondern ich muss mir überlegen: Wo messe ich das Ergebnis? Wo messe ich die Erwartungshaltung der Kundschaft? Das ist nicht trivial, das ist teuer darüber nachzudenken, zu besprechen und anzupassen. Das heißt, ich muss mit der Produktentwicklung oder mit meinem PO wirklich da Hirnschmalz reinsetzen und herauskitzeln: Was erwartet denn die Kundschaft und wie kann ich das messen? Und wie kann ich einen Fehler sinnvoll zurückgeben? Was wird da erwartet? Und da fällt man oft auf die Nase, würde ich sagen. Man muss das ausprobieren und deswegen sind sie teuer, diese Produktmetriken zu sammeln und auszuwerten. Die sind teuer, aber die sind sehr aussagekräftig, genauso wie End-to-End Tests aussagekräftig sind. Aber ich würde mich jetzt nicht darauf festlegen, dass man nur für kritische User Journeys diese Produktmetriken macht, weil sie eben so wertvoll sind.
Stefan Negele: Oft ist aber eben auch eine Kombination aus technischen Metriken. Ich definiere: Das Ergebnis meines Features ist korrekt. Zum Beispiel wäre das irgendwie so: Ich habe als IoT Gerät ein Türschloss. Mein Ergebnis soll sein, dass dieses Türschloss sich verriegelt und entriegelt. Aber wie kriege ich das denn raus? Da habe ich halt mehrere Möglichkeiten. Wenn ich jetzt zum Beispiel weiß: Dieses Türschloss muss irgendeinem Server kommunizieren, dann könnte ich zum Beispiel messen: Okay, ist es erreichbar? Wenn das nämlich nicht der Fall ist, dann weiß ich: Okay, es kann nicht funktionieren. Oder vielleicht gibt es spezielle Fehlermeldungen, die mir sagen: Oh, das funktioniert gerade nicht. Vielleicht wirft es einen Error Code und der sagt mir: Okay, nein, das funktioniert nicht. Oder was vielleicht ein bisschen komplexer wird. Der State das Schloss ist der interne, den man ausliest, der macht Sinn oder macht keinen Sinn. Das kann ja auch sein, dass man irgendwie einen Request hinschickt an dieses Schloss und man kriegt eine Antwort oder fragt irgendwas ab und das passt nicht zu dem, was man erwartet. Genau so kann ich mich wahrscheinlich auch ein bisschen vortasten von einfachen technischen Metriken, die dort mein Ergebnis messen, hin zu komplexeren Dingen, wie eben zum Beispiel den State auszuwerten. Von billig zu teuer.
Anja Kammer: Ich weiß, was du meinst. Das heißt, man braucht technische Metriken, um sozusagen eine Aussage über das Produkt zu haben. Ein Response Time zum Beispiel für ein User Request ist auch eine typische technische Metrik, die mir total viel oder auch total wenig sagen kann. Die sagt mir total viel, wenn ich die Response Time messe vom Client: Sobald dieser Button gedrückt wird, wie lange dauert es, bis die Aktion ausgeführt wird, die sich hinter diesem Button verbirgt? Dahinter sind drei, vier Services, die irgendwelche Dinge tun und wann kommt aber die die Response zurück zum Client? Das mache ich normalerweise mittels Tracing direkt am Client, im Browser zum Beispiel. Und das ist sehr sinnvoll, genau dort zu messen, wenn meine Nutzenden mit dem Browser interagieren. Es bringt mir überhaupt nichts, wenn ich den einen von den drei Servern dahinten messe und der eine super Response Time hat. Heutzutage arbeiten wir in verteilten Systemen, Microservices, Du weißt, was ich meine, irgendwelche Lambdas. Man weiß nie, wo dann die Latenz herkommen kann.
Stefan Negele: Und ob die relevant ist.
Anja Kammer: Und ob die relevant ist, genau. Das heißt, wenn ich mich wirklich um die Nutzendenerfahrungen kümmere, dann muss ich genau sehr nah an den Nutzenden messen. In dem Fall beispielsweise für die Browser Anwendung direkt im Browser messen und nicht in irgendwelchen Services. Das ist nicht so relevant. Beziehungsweise, wenn die Response Time im Browser schlecht bewertet wurde oder ich habe Tracing angestellt, dann kann ich dann bei der Fehlersuche finden. Welcher dieser Services oder welche dieser Knotenpunkte hat dann eben die höhere Latenz produziert?
Stefan Negele: Was man hier glaube ich hinzufügen muss, auch ch eine Latenz an einem Service kann natürlich eine Metrik sein, die ich messen muss, wenn dieser Service jetzt vielleicht nicht direkt von einem Browser konsumiert wird, aber vielleicht von einem anderen Service, von einem anderen Team und dann das sozusagen ist dieser Service mein Konsument und mein Feature ist es, diesem Service eben einen Endpunkt bereitzustellen. Und dann muss ich natürlich gucken, wann habe ich wahrscheinlich irgendwie da auch SLOs, SLAs definiert, mit dem anderen Team und muss die dann an der Stelle messen.
Anja Kammer: Genau, wichtig, denn diese API Konsumenten, die intern eine API konsumieren, die haben vielleicht auch andere Kundschaft, die auch Dinge erwarten. Das heißt, ich muss unter meinen Abhängigkeiten Verträge schließen, damit ich meiner eigenen Kundschaft, die auf einer anderen Ebene existiert, damit ich die bestimmte Response-Time nennen kann, wenn ich nicht meine Abhängigkeiten sozusagen abgeklärt habe. Sonst bin ich im Blindflug und weiß gar nicht, unter welchen Umständen ich vielleicht doch meine SLAs gar nicht einhalten kann gegenüber meinen eigenen Kunden.
Stefan Negele: Eine Sache, die ich immer tun würde, wenn ich einen fremden Service konsumiere. Vor allem, wenn er nicht aus meiner Organisation kommt, als dass ich da auch einen Messpunkt ansetze, weil es einfach eine typische Fehlerquelle ist. Ich will aber ein internes Team nicht dazu nötigen, das tun zu müssen.
Anja Kammer: Genau, das bedeutet wenn ich solch ein SLA zwischen zwei Teams definiert habe, dann muss irgendeiner der Parteien messen, ob diese SLA eingehalten wird. Und das macht natürlich die Partei, die diesen Service anbietet, weil die die bereitstellende Partei ist.
Stefan Negele: Ja, idealerweise.
Anja Kammer: Okay, ich hatte mal ein Projekt, da hat auch der Customer Support Statistiken gemacht und konnte den Entwicklungsteams auf die Finger klopfen, wenn sie gesehen haben, dass es in bestimmten Bereichen, beispielsweise beim Login oder bei bestimmten Features zu höheren Fehlern kam, weil eben super viele Kundinnen angerufen haben. “Das und das funktioniert nicht”. Das heißt, da hatte der Customer Support einen direkten Kommunikationskanal zu den Entwicklungsteams und hatte die Macht, wirklich Prioritäten zu ändern, um Bugs zu fixen, zum Beispiel.
Stefan Negele: Ja, das ist aber auch tatsächlich, finde ich, eine sehr, sehr legitime Anwendung, so eine nicht technische Quelle anzuwenden, also eine manuelle Meldung. Aber vielleicht bietet auch das Ticketsystem, also das Support-Ticketsystem eine API an und dann kann ich vielleicht auch an der Stelle schon Sachen messen. Zum Beispiel wird dann eben eingetragen von meinem Customer Support: Wie viel Anrufe oder Mails pro Minute eintrudeln. Die werden dann kategorisiert.
Anja Kammer: Schließfach defekt.
Stefan Negele: Schließfach defekt oder so. Und dann hat man vielleicht auf der anderen Seite aber eine technische Metrik, die hilft das einzuordnen oder zu dimensionieren. Beispiel wäre zwei Supporttickets für 5000 Requests sind was anderes als für fünf Request.
Anja Kammer: Das heißt, innerhalb eines Tages wurde nur versucht fünfmal das Schließfach zu öffnen und zweimal hat es nicht funktioniert. Das ist eine andere Aussage, als: Es wurde 5000-mal versucht zu benutzen und zweimal hat es nicht funktioniert.
Stefan Negele: Genau. Und mein Customer Support sammelt eben diese Information. Der sammelt: Hier hat irgendwas nicht funktioniert oder eine bestimmte Kategorie hat nicht funktioniert. Und am Ende des Tages schicken die das in diesem Ticket ab und dann kann ich eine technische Metrik daneben stellen und sagen: Ja, okay, ist aber jetzt nicht so ein Drama, weil das wird sowieso nicht verwendet, dieses Feature oder nur ganz selten. Das sollte sich natürlich dann auswirken auf die Priorisierung. Wenn ich parallel irgendwie ein Feature habe, das 5000-mal statt fünfmal verwendet wird. dann sollte ich das vielleicht höher priorisieren, dieses Problem zu beheben oder ein Feature umzusetzen, das vielleicht super geschäftskritisch ist.
Anja Kammer: Oder eben die Cashcow ist.
Stefan Negele: Genau.
Anja Kammer: Und wenn ich dann mein Customer Support System im Unternehmen dann ansprechen kann und über die API mir Information ziehen kann, dann könnte ich zum Beispiel alle Tickets einsehen. Und ich müsste das aber für mein Team irgendwie in Kontext setzen, welche diese Tickets überhaupt für mich relevant sind. Was bringen mir alle diese Tickets?
Stefan Negele: Ja klar,d muss das dann auch irgendwie schlaumachen. Man sollte das dann kategorisieren. Vielleicht dem Customer Support auch die Möglichkeit geben, Tags zu vergeben oder das irgendwie zu kategorisieren. Und das dann so auszuwerten, dass dann die entsprechenden Tickets dann bei mir im Team ankommen. Man muss da aber super aufpassen. Diese Kennzahlen bei so nicht technischen Metriken können super leicht verfälscht werden. Zum Beispiel so organisatorische Faktoren wie, dass ich irgendwie einen Bonus auf eine Menge von Tickets gebe.
Anja Kammer: Was ist mit dem anderen Szenario, Wenn ein Kunde anruft, ein Problem mit dem Login hat, das Schließfach nicht funktioniert und noch fünf andere Dinge hat, dann ist es total verfälscht, weil total viele Fehler unbeachtet sind, weil man kann eben nur einmal eine Kategorie verwenden und dann nimmt man die schwerstwiegenste, aber es sind noch andere Probleme in diesem Ticket drin, die vielleicht auch sehr schwerwiegend sind oder beachtet werden sollten. Und die findet man dann nicht, wenn man sie über die API sucht.
Stefan Negele: Absolut. Das ist halt die Sache, das ist quasi das Problem an der Stelle, das wird halt super schnell sehr unscharf und deswegen muss man da eben aufpassen. Aber es ist auf jeden Fall super wertvoll, diese Sachen anzuwenden und sich das anzugucken. Das Tolle, wenn man einen Support hat, sie sind direkt am Kunden, die reden wirklich vielleicht mit denen am Telefon oder vielleicht reden sie sogar persönlich mit denen. Die Info ist natürlich super wertvoll.
Anja Kammer: Aber in welchen Fällen redest du mit dem Customer Support? Eigentlich nur, wenn du schon am Kochen bist, oder? Wenn du wirklich jetzt sofort etwas gelöst haben willst. Das heißt, ich sollte vielleicht als Entwicklungsteam nicht darauf hoffen: Ja, ja, wenn es da ein Bug gibt. Es kommt dann über das Customer Support System. Das sollte nur das letzte Fallnetz sein. Ich sollte schon versuchen, so gut wie es geht, mein System zu monitoren und ordentlich Alerts einzurichten. Und wenn dann Fehler über den Customer Support kommen, dann ist das ein Ausnahmefall, aufgrund dessen ich dann mein Observerability Tooling und mein Alerting überdenken muss. Genauso wie jeder Bug, der reinkommt. Wenn ein Bug reinkommt, muss ich überlegen: Was habe ich denn falsch gemacht bei meinen Tests? Da muss irgendwas durch die Lappen gegangen sein.
Stefan Negele: Da bin ich vollkommen bei dir. Das sollte natürlich das letzte Fallnetz sein.
Anja Kammer: Und wenn sich Leute beschweren, ist es eben schon zu spät. Das sollte nicht das einzige Mittel sein, um diese Incidents zu erkennen.
Stefan Negele: Vielleicht kriege ich aber auch eben Informationen, die eben auch nicht so schwerwiegend sind. Vielleicht kriegt da auch Dinge raus.
Anja Kammer: Die zur besseren Produktentwicklung führen können.
Stefan Negele: Genau. Vielleicht ist es gar nicht: Feature XY funktioniert, sondern ich fände es toll, wenn Feature XY so funktionieren würde. Weiß ich nicht, ob das jeder Entwickler dann selbst auswertet.
Anja Kammer: Oder ob es Product Owner Tätigkeit oder Produktentwicklungstätigkeit ist. Es kommt auch immer auf die Größe des Unternehmens an, ganz ehrlich. Je kleiner ein Unternehmen ist, desto eher ist ein Entwicklungsteam wirklich hautnah an der Produktentwicklung beteiligt und je größer das Unternehmen ist, desto mehr Strukturen gibt es, die das schon für die Entwicklungsteams abfangen, vorfiltern und dann in ordentliche Häppchen verteilen in Form von Tickets. Es ist natürlich total normal, dass Entwicklungsteams nicht immer diese Möglichkeit haben, genau direkt sehr nah an der Kundschaft zu sein. Aber man sollte sich dem nicht verschließen.
Stefan Negele: Vielleicht kann man sagen, man sollte immer gucken, welche Quellen man hat und die dann nehmen.
Anja Kammer: Wir haben vieles besprochen und ich finde auch unser letztes Thema hat gezeigt, warum wir das alles machen, warum wir uns über Produktmetriken Gedanken machen also unsere eigene Wortschöpfung, diese Produktmetriken. Weil wir uns nicht einigen konnten, haben wir es einfach Produktmetriken genannt. Das heißt, wir wollen sehr nah an der Kundschaft sein, herausfinden, was die Kundschaft braucht und anhand dessen unser Observerability für unser System designen, damit wir über die richtigen Dinge informiert werden und die richtigen Dinge überwachen, die wirklich auch die Kundschaft interessiert und nicht nur irgendwelche technikaffinen Menschen. Was sind unsere Key Takeaways? Was können wir jetzt als Fazit bieten?
Stefan Negele: Die hast du dir aufgeschrieben.
Anja Kammer: Die habe ich mir aufgeschrieben. Ich gebe einen Kontext. Es ist eine Teamleistung. Die Leute, die Features entwickeln, wissen auch idealerweise, wie der Erfolg dieser Features gemessen werden kann. Aber es braucht eine Kommunikation auch mit der Fachabteilung, mit der Produktentwicklung, was überhaupt die Kundschaft erwartet, um das sinnvoll machen zu können. Man lernt dabei auch viel über das Produkt, wenn man sich Gedanken macht, was den Erfolg eines Features definiert. Was dann auch wiederum dazu führt, dass man mit sehr viel mehr Ownership und sehr viel mehr vielleicht sogar Zufriedenheit in dem eigenen Entwicklungsteam arbeitet, weil man eben nicht gefühlt für die Tonne arbeitet oder alleine irgendwelche technischen Dinge macht, ohne zu wissen, wie es am Ende verwendet wird.
Stefan Negele: Und das hilft auf jeden Fall auch, sich auf wichtige Dinge zu konzentrieren. Also nicht sinnlos Fehler suchen, sondern vielleicht sich eher darauf zu konzentrieren, dass man wichtige Probleme behebt oder eben idealerweise neue Features umsetzt.
Anja Kammer: Genau. Und wir haben besprochen, dass man dennoch technische Metriken braucht, allerdings diese als Quelle verwendet, um Produktmetriken zu definieren oder sinnvolle Metriken zu definieren. Es hat sehr viel Spaß gemacht, mit dir zu reden und ich finde es schön, dass wir aus unseren wirren Gedanken was herzaubern konnten, was vielleicht auch jemand hören möchte.
Stefan Negele: Es hat mir auch sehr viel Spaß gemacht. War sehr toll. Interessantes Gespräch, Anja. Hoffentlich quatschen wir mal wieder.
Anja Kammer: Machen wir bestimmt. Na dann, tschüss. Bis zum nächsten Mal.
Stefan Negele: Tschüss. Bis dahin.
