Site Reliability Engineering (SRE) ist eine Disziplin, die das tiefe Verständnis von Softwareengineering mit einer ausgeprägten Fokussierung auf Zuverlässigkeit und Betriebsstabilität verbindet. Ursprünglich von Google entwickelt, zielt SRE darauf ab, die Lücke zwischen der Entwicklung und dem Betrieb von Software zu schließen, indem es Prinzipien des Engineerings auf Betriebsaufgaben anwendet. SRE-Teams sind dafür verantwortlich, Skalierbarkeit, Performance und Ausfallsicherheit von Services zu gewährleisten und dabei auch die schnelle Entwicklung und Bereitstellung neuer Features zu unterstützen. Sie nutzen eine Reihe von Methoden, wie Automatisierung und kontinuierliche Integration/Delivery, um manuelle Arbeit zu reduzieren und Fehlerquellen zu minimieren.
Genau über diese Methoden und SRE an sich spreche ich heute mit Alex Lichtenberger.
Der Copilot von Microsoft kann uns, die wir täglich mit Word, Excel, Teams und den Unternehmensdaten arbeiten, viel Zeit sparen. Schätzungen liegen aktuell bei 30 %. Wenn Du Dir überlegst, was das für Dein Unternehmen bedeutet, dann lohnt sich auf jeden Fall die Beschäftigung damit. Diesen Produktivitätszuwachs kannst Du zu einem sehr geringen Preis realisieren. Zumindest, wenn Du nur die Lizenzkosten betrachtest. An der Formulierung merkst Du schon, da ist ein Haken. Genau über den und natürlich Copilot an sich, spreche ich heute mit Alexander Eggers. Als Produzent der deutschen Videos zu Copilot die beste Quellen für uns neugierige Servicenerds.
Ab einer gewissen Größe braucht Deine IT-Abteilung oder Dein Systemhaus eine Struktur. Wächst Du weiter, kann es sein, dass Deine Organisation eine andere Struktur braucht. Mit Struktur meine ich die Aufbauorganisation und damit verwandte Elemente. Genau darüber spreche ich heute mit Olaf Kaiser. Wir diskutieren darüber, warum es wichtig ist, die passende Aufbauorganisation zu finden.
SLAs sind von der Intension her, ein wunderbares Instrument. Die Umsetzung in vielen Unternehmen und von Providern ist einfach grottig. Sie sind aus Sicht des Unternehmens irrelevant und somit haben wir selten welche. Verständlich, es steht ja meist irrelevantes Zeug drin. Zumindest aus Sicht des Unternehmens.
Das Problem ist, dass der Begriff damit verbrannt ist. Dementsprechend muss ein neuer her: XLA – Experience-Level-Agreement. Genau darüber reden wir heute.
Produktteams, Product-Owner, Produktentwicklung – langsam könnte man den Eindruck gewinnen, dass sich die IT zum Produktionsunternehmen wandelt. Wenn da nicht die Services wären. Am besten beides in einem Unternehmen, damit die Verwirrung komplett wird. Heute beschäftigen wir uns mit dem Unterschied zwischen Produkt und Service und ich plädiere für eine klare Festlegung.
Wissen ist Macht. Ein Satz, der sich vielleicht so stark eingeprägt hat, dass Menschen ihr Wissen ungern teilen. Denn wenn keiner weiß, was ich weiß, dann bin ich unersetzlich. Ich bin mir sicher, keiner von uns hat seinen Job, weil etwas weiß. Wir haben unseren Job, weil wir das Wissen anwenden können und entsprechend schnell die richtigen Ergebnisse liefern.
Wissen ist heute auf Knopfdruck im Internet verfügbar. Dieses zu vernetzen und sinnvoll anzuwenden, das ist unsere Aufgabe. Dazu kommt, dass Wissen wächst, wenn wir es teilen. Wie das konkret funktioniert, kannst Du beim Servicenerds.Camp erleben.
Ich spreche heute mit Dir darüber, wie Du das Wissensmanagement am Leben erhältst.
Wir haben viel zu tun. Wir haben viel zu viele Vorgänge zur gleichen Zeit. Projekte, Projekte, Tickets und was alles nicht noch. Es wird nicht weniger. Dem begegnen wir vielfach mit der Arbeitsweise und den Vorgehensmodellen von vorn 2, 5 und 10 Jahren. Also so, wie wir es schon immer gemacht haben. Wir alle wissen, dass es anders und besser geht. Manchmal schaffen wir es, so viel Aufmerksamkeit für die notwendige Änderung zu erzeugen, dass wir dazu ein Projekt starten. Mit Überzeugung, Begeisterung und der Unterstützung des Chefs. Und dennoch enden viele dieser Vorhaben mit: im Tagesgeschäft keine Zeit. Darüber spreche ich heute mit Olaf Kaiser.
Dafür sind wir nicht zuständig. Ein Satz, der auf jeden Fall gelogen ist. Zumindest, wenn er im Rahmen einer Serviceerbringung fällt. Warum das so ist, schildere ich Dir heute an einem Beispiel. Das ist kein Phänomen der internen IT oder speziell von IT-Services, sondern leider bei ganz vielen Services – egal aus welchem Lebensbereich. Insbesondere dann sehr beliebt, wenn ein Teil der Leistung nicht im eigenen Hause erbracht wird. Warum das problematisch ist, darüber spreche ich in dieser Folge.
Wollen wir nicht alle der Trusted Adivisor in Sachen IT bei uns im Unternehmen oder bei unseren Kunden sein? Der Wunsch ist verständlich, allerdings muss es nicht das Ziel sein. Eine alternative Positionierung ist zumindest für MSPs sinnvoll. Interne ITs dürfen schon dieses Ziel anstreben und müssen eigentlich noch weiter auf die nächste Stufe kommen. Olaf Kaiser und ich sprechen darüber, was es braucht, um Trusted Advisor zu werden und welche Alternativen es dazu gibt. Natürlich erfährst Du auch, was ein Trusted Advisor überhaupt ist.
Eine klare Definition von Verantwortung, Aufgaben und Rechten ist für das Funktionieren einer serviceorientierten IT von grundlegender Bedeutung. Das bietet es sich natürlich an, Rollen zu definieren. Schaust Du Dir die Frameworks an, suchst Du im Internet danach, findest Du eine Unmenge von Rollen. Für manche IT-Organisationen mehr Rollen als Mitarbeitende. Das ist nicht Sinn der Sache. Daher skizziere ich Dir heute einen Weg, der zu passgenauen Rollen für Deine IT führt.
Ich erlebe immer wieder heiß geführte Diskussion, ob ein Service nun ein Business- oder ein technischer Service ist. Es werden Kriterien gesucht und verworfen. Ohne die Definition, was nun genau ein Business-Service ist, geht es nicht weiter. Das lähmt und bindet anderweitig benötigte Energie. Warum ich nicht mehr über verschiedene Arten von Services spreche und was ich anstatt dessen meinen Kunden und Schulungsteilnehmern vermittel, erzähle ich Dir heute in der 200 (!) Episode.
