Schlagwort-Archive: fehlerkultur

Artikelbild: Frau SRE-DevOps-Expertin angestrahlt mit Code

SRE oder DevOps: Rivalen oder Alliierte?

Die immer schneller werdende Geschäftswelt ist schon seit geraumer Zeit von dem Wort „Agilität“ besessen, wenn es um die Entwicklung von IT-Produkten geht. Und es ist nicht schwer zu verstehen, warum: Die Aussicht, die lang ersehnte Lösung zur Behebung von Problemen so schnell wie möglich zu erhalten, ist und bleibt verlockend.

Die COVID-19-Pandemie hat jedoch gezeigt, dass es nicht mehr ausreicht, einfach nur agil zu sein: Aus dem Transposit-Bericht geht hervor, dass die MTTR (mittlere Reparaturzeit) gestiegen ist (93,6 %), seit die Welt gezwungen ist, ein Remote-Arbeitsmodell einzuführen, wobei die Ausfallzeiten sogar um 68,4 % gestiegen sind!

Wie kann man nun sicherstellen, dass die Agilität nicht länger die Zuverlässigkeit beeinträchtigt? Das sind DevOps und Site Reliability Engineering (SRE). Diese Konzepte gibt es schon seit geraumer Zeit, und angesichts der Herausforderungen, die sich insbesondere im Zuge der Pandemie stellen, sind sie aktueller denn je.

DevOps und SRE wurden in den frühen 2000er Jahren entwickelt, um ein Gleichgewicht zwischen Entwicklungsagilität und Systemstabilität zu finden. Die Begriffe werden jedoch oft falsch verwendet: Manche denken, es handele sich um dasselbe, andere halten sie für konkurrierende Ideen. Die meisten glauben, dass sich ein Unternehmen immer zwischen beiden entscheiden muss. Gehen wir also der Frage auf den Grund, was DevOps und SRE sind und ob eine Debatte zwischen DevOps und SRE überhaupt Sinn macht.

DevOps ist im Kern eine Methodik, die Silos zwischen Entwicklungs-, Test-, Qualitätssicherungs- und Betriebsteams abbaut, um die Anwendungsentwicklung zu beschleunigen, die Softwarequalität zu verbessern, die Verfügbarkeit der Infrastruktur zu erhöhen, die Anwendungsleistung zu maximieren und die Kosten zu senken. All das klingt großartig. Allerdings gibt es ein Problem. DevOps ist im Grunde eine Reihe von abstrakten Prinzipien, von denen viele Unternehmen Schwierigkeiten haben, sie in die Praxis umzusetzen. Um diesen Kampf zu beenden, hat Google 2016 ein Buch mit dem Titel „Site Reliability Engineering“ veröffentlicht, das die internen DevOps-Praktiken beleuchtet, aber vor allem leicht verständliche praktische Ratschläge gibt, wie DevOps funktioniert.

Kurz gesagt: DevOps ist eine Philosophie, und SRE ist eine gute Möglichkeit, diese Philosophie umzusetzen.
Wie trägt SRE zur DevOps-Methodik bei?

Wenn Sie sich das DevOps-Manifest ansehen, werden Sie wahrscheinlich feststellen, dass es 5 Schlüsselkategorien gibt, in die DevOps unterteilt ist, die Mantras der Methodik, wenn Sie so wollen:

  • Beseitigung organisatorischer Silos
  • Akzeptieren von Fehlern als normal
  • Kleine inkrementelle Änderungen einführen
  • Nutzen von Werkzeugen und Automatisierung
  • Alles messen

All diese Punkte sind zweifellos für den Erfolg eines Teams bei der Suche nach einem ausgewogenen Verhältnis zwischen Agilität und Zuverlässigkeit von entscheidender Bedeutung, und wir werden gleich herausfinden, warum. Aber so schön sie auch klingen, sie sehen nicht wie konkrete Anweisungen aus („Alles messen“? Natürlich!). Gehen wir also diese Grundsätze nacheinander durch und sehen wir, wo der Unterschied zwischen DevOps und SRE wirklich liegt.
DevOps-Ideen und SRE-Implementierung
Aufhebung der organisatorischen Silos

DevOps-Idee: Die Kommunikation zwischen den Personen, die für die Programmierung zuständig sind (Entwickler), und den Personen, die die Wartungsdienste erbringen (Betreiber), muss nahtlos sein, um zu verhindern, dass schnelle Änderungen am Code die Infrastruktur beschädigen und die Stabilität des Systems ernsthaft gefährden. Ursprünglich sollte DevOps die Mauer zwischen Entwicklungs- und Betriebsteams durchbrechen, hat sich aber schnell über die Softwarebereitstellungspipeline hinaus auf Bereiche wie Sicherheit, Finanzen, HR, Marketing, Vertrieb usw. ausgebreitet, in denen eine Zusammenarbeit unerlässlich ist.

SRE-Implementierung: Sie müssen ein engmaschiges, funktionsübergreifendes Team aufbauen, indem Sie nicht nur Entwickler und Operatoren zusammenbringen, sondern auch synergiefördernde Praktiken auf die Bereiche Finanzen, Personalwesen, Führungsteams usw. ausweiten. Die Kultur der besseren Kommunikation und des Wissensaustauschs, die DevOps und SRE von Natur aus erfordern, kann durch häufige Stand-ups geschaffen werden, während Integration und Automatisierung mit speziellen Toolsets umgesetzt werden sollten.
Scheitern als normal akzeptieren

DevOps-Gedanke: Kein von Menschen geschaffenes System kann zu 100 % zuverlässig sein, daher sollte ein Ausfall des besagten Systems von keinem Unternehmen als Katastrophe empfunden werden, sondern als Normalität behandelt werden… solange daraus eine Lehre gezogen wird.

SRE-Implementierung: Sie müssen sich intern darauf einigen, wie viel Ausfallzeit unter den gegebenen Umständen akzeptabel ist, und darauf vorbereitet sein, Systemausfälle schnell zu bewältigen (da sie unvermeidlich sind und nicht überraschend kommen sollten); eine Möglichkeit, dies zu tun, ist die Durchführung so genannter „schuldloser Post-Mortems“, bei denen keine Zeit damit verschwendet wird, die Schuldigen für den Ausfall zu suchen. Stattdessen sucht das Team routinemäßig nach Möglichkeiten zur Verbesserung des Systems und konzentriert sich dabei auf die Zukunft, nicht auf die Vergangenheit.

DevOps-Idee: Häufige, aber kleine Änderungen am Code helfen, schneller auf Probleme zu reagieren und Fehler einfacher zu beheben. Und warum? Das ist ganz einfach. Die Suche nach einem Fehler in 100 Codezeilen ist viel einfacher als in 100.000 Codezeilen. Außerdem ist der Entwicklungsprozess dadurch generell viel flexibler und kann auf plötzliche Änderungen reagieren.

SRE-Implementierung: Sie müssen beachten, dass es nicht auf die tatsächliche Anzahl der Deployments pro Tag ankommt. Das Streben nach einer übermäßigen Anzahl von Deployments nur um der Deployments willen ist vergebliche Mühe. Sie sollten in der Tat häufig deployen, aber auch dafür sorgen, dass diese Deployments sinnvoll sind – je sinnvoller die Art des Deployments ist, desto einfacher ist es, einen potenziellen Fehler zu beheben, und desto geringer sind die Kosten für Fehlschläge.
Von Tools und Automatisierung profitieren

Die DevOps-Idee: Es liegt in der menschlichen Natur, dass wir monotone Aufgaben nicht effizient ausführen können. Genauso wie es viel Zeit und Energie kostet, wichtige Arbeitsabläufe manuell zu erledigen, können Unternehmen, die Tools und Automatisierung nutzen, diese Prozesse exponentiell verbessern.

SRE-Implementierung: Sie sollten sich überlegen, welche langfristigen Verbesserungen am System vorgenommen werden müssen, und die Aufgaben automatisieren, die in einem Jahr oder in ein paar Jahren regelmäßig anfallen werden (SRE nennt dies „die Arbeit von diesem Jahr weg automatisieren“). Auf diese Weise vermeiden Sie Investitionen in kurzfristige Gewinne und konzentrieren sich auf die langfristige Automatisierung.

DevOps-Idee: Konkrete Metriken, die verschiedene Aspekte Ihres Entwicklungsprozesses messen, helfen nicht nur dabei, festzustellen, ob das Unternehmen erfolgreich an einem bestimmten Projekt arbeitet, sondern liefern auch eine Rechtfertigung für diese oder jene Geschäftsentscheidung.

SRE-Implementierung: Sie sollten Service-Level-Agreements (SLA), Service-Level-Ziele (SLO) und Service-Level-Indikatoren (SLI) verwenden, die mittlere Zeit zwischen zwei Ausfällen (MTBF) und die mittlere Wiederherstellungszeit (MTTR) des Systems verfolgen und ein Fehlerbudget festlegen. So können Sie Ihr Projekt wesentlich effizienter gestalten.

Wir werden in Kürze näher darauf eingehen, was einige der Begriffe im obigen Absatz tatsächlich bedeuten, aber der Rest des Bildes sollte inzwischen mehr als deutlich sein. DevOps wurde geschaffen, um die IT-Entwicklung besser zu machen. In der Zwischenzeit sollte SRE zeigen, WIE genau wir das tun sollten. Wie viele SRE-Spezialisten zu sagen pflegen, „SRE implementiert DevOps“.

SRE als Konzept ist ohne Service-Level Agreement (SLA), Service-Level Objective (SLO), Service-Level Indicator (SLI) kaum vorstellbar. Wie bereits erwähnt, handelt es sich hierbei um die zentralen Begriffe, die sich in vielerlei Hinsicht auf die Messung des Erfolgs Ihrer SRE-Implementierung beziehen. Und genau wie die Namen dieser Konzepte sind auch ihre Eigenschaften einander sehr ähnlich, allerdings mit einigen entscheidenden Unterschieden:

  • SLA wird als Vereinbarung zwischen dem Service Provider und dem Kunden über Kennzahlen wie Betriebszeit, Ausfallzeit, Reaktionsfähigkeit, Verantwortlichkeiten usw. bezeichnet. Mit anderen Worten, es handelt sich um eine Reihe von Versprechen an den Kunden, die durch verschiedene Messgrößen dargestellt werden, sowie um eine Reihe von Konsequenzen, wenn diese Versprechen nicht eingehalten werden;
  • SLO wird wiederum als Vereinbarung innerhalb eines SLA über eine bestimmte Kennzahl bezeichnet, z. B. Betriebszeit oder Antwortzeit. Im Grunde ist ein SLO ein individuelles Versprechen an den Kunden. In dieser Hinsicht kann man ein SLA also als eine bestimmte Gruppe von SLOs betrachten;
  • Der SLI schließlich ist ein Indikator, der anzeigt, ob das System in Übereinstimmung mit diesem oder jenem SLO funktioniert.

Ein typisches Beispiel für das Zusammenspiel dieser drei Begriffe wäre etwas in dieser Art: Ein SLA, das Sie mit Ihrem Kunden abgeschlossen haben, besagt, dass das System 99,9 % der Zeit verfügbar sein wird (die so genannten „drei Neunen der Verfügbarkeit“), es würde also die SLO enthalten, die 99,9 % Betriebszeit bedeuten würde, und die SLI wäre die tatsächliche Messung der Betriebszeit des Systems.
Welche Arten von Unternehmen brauchen SRE und DevOps?

In Anbetracht der Tatsache, dass DevOps und SRE dazu da sind, Entwicklungsteams bei der Sicherstellung einer hohen Systemstabilität zu unterstützen und gleichzeitig sehr agil zu sein, kann man relativ sicher sagen, dass jedes Entwicklungsunternehmen bis zu einem gewissen Grad wissen sollte, was DevOps/SRE-Techniken sind und wie man sie implementiert. Sie sind das A und O der modernen Softwareentwicklung.

In unseren früheren Beiträgen haben wir uns bereits mit den Vorteilen von DevOps für große Produktionsunternehmen und den massiven Auswirkungen auf die Finanzdienstleistungsriesen befasst, aber die Genialität von DevOps und SRE liegt in ihrer universellen Anwendbarkeit – Ihr Unternehmen muss KEIN Softwareentwicklungsunternehmen sein, um von diesen Praktiken zu profitieren; solange Sie mit Update-Rollouts, Infrastrukturänderungen, Wachstum und Upscaling zu tun haben, können Sie sich mit dieser Philosophie beschäftigen.

Und tatsächlich ist kein Team zu klein für DevOps/SRE. Wenn Sie ein kleines Unternehmen sind, brauchen Sie nicht einmal einen speziellen SRE-Spezialisten. In diesem Fall kann es sich lohnen, eines Ihrer Teammitglieder in der Anwendung der SRE-Methode zu schulen, da die Lernkurve nicht so hoch ist.

Wenn man all dies berücksichtigt, kann man leicht zu dem Schluss kommen, dass die Ideen und Konzepte hinter DevOps und SRE für jedes Unternehmen interessant sind – ob Großunternehmen oder kleines StartUp, ob IT oder Nicht-IT, sie sind für jeden geeignet.

Bei dem Versuch, die Debatte zwischen Site Reliability Engineering und DevOps zu klären, können wir nun mit Sicherheit sagen, dass es keinen Sinn hat, entweder oder zu sagen. Wie können wir hier überhaupt von einer Debatte sprechen, wenn die beiden Dinge, die wir verzweifelt versuchen, einander gegenüberzustellen, praktisch dasselbe sind, wobei das eine ein wesentlicher Bestandteil des anderen ist?

Wenn Sie sagen, dass Sie DevOps gut machen können, ist es wahrscheinlich, dass Sie das mit Hilfe von SRE-Prinzipien tun.

Wenn Sie sagen, dass Sie SRE gut machen können, sollten Sie wissen, dass wir technisch gesehen über DevOps sprechen.

Es handelt sich also keineswegs um ein „rote Pille-blaue Pille“-Szenario. Sowohl DevOps als auch SRE sind zu begrüßen, und wir sind sehr gespannt, wie sich beide in den kommenden Jahren entwickeln werden.

Interessieren Sie sich für SRE und DevOps? Sprechen Sie mit unseren DevOpsExperten, um herauszufinden, wie DevOps und SRE Ihnen helfen können, neue Geschäftsmöglichkeiten zu erschließen.

Artikelbild: Zeigt emotionales Teammitglied

Fehlerkultur im Team: So kritisiert man richtig

Wenn Sie jemals in einem Unternehmensteam gearbeitet haben, wissen Sie, dass die meisten Mitarbeiter eine Meinung haben. Ein kluger Umgang mit konstruktiver Kritik ermöglicht es einem Teamleiter, den Beitrag aller Mitarbeiter am Arbeitsplatz zu maximieren. Menschen, die keine konstruktive Kritik annehmen, ignorieren kritische Informationen, die ihr Wachstum und ihre Entwicklung fördern können. Wenn man es versäumt, Grundregeln für das Geben und Empfangen von Feedback in einem Team aufzustellen, kann dies zu Verstimmungen, anhaltenden Konflikten und geringerer Produktivität führen.

Einzelnes Thema

Beschränken Sie sich jeweils auf ein Thema, wenn Sie Feedback geben müssen. Gönnen Sie sich etwas Zeit, um zu formulieren, was Sie Ihrer Mitarbeiterin sagen wollen, bevor Sie Einzelheiten über ihre Leistung mitteilen. Bieten Sie Ihren Rat in objektiver Weise an. Vermeiden Sie es, Ihre Autorität geltend zu machen oder Ihre persönliche Meinung einzubringen. Auch wenn Sie vielleicht versucht sind, auf die Fehler einer anderen Person hinzuweisen, um Ihre eigene Karriere voranzutreiben, erkennt der kluge Mitarbeiter, dass es normalerweise besser ist, zu kooperieren und andere zu unterstützen.

Akzeptanz

Erkennen Sie an, dass Ihre Arbeit analysiert wird und nicht Sie persönlich, wenn Sie diejenige sind, die das konstruktive Feedback erhält. Nehmen Sie eine Kritik an Ihrer Arbeit nicht als Ausdruck Ihrer langfristigen Fähigkeit, im Job erfolgreich zu sein. Das Ziel eines konstruktiven Beitrags ist es, die Arbeit zu verbessern. Ein kollaboratives Umfeld fördert den Austausch und die kontinuierliche Verbesserung. Vermeiden Sie es, sich defensiv zu fühlen, indem Sie die Verantwortung für Ihr Verhalten übernehmen und Maßnahmen ergreifen, wenn Sie können. Sie können sich zwangsläufig auf die negativen Aspekte des Feedbacks konzentrieren und sich angegriffen fühlen, aber versuchen Sie, gemeinsam an der Lösung von Problemen zum Wohle des Teams zu arbeiten. Wenn Sie beständiges Feedback aus verschiedenen Quellen erhalten, wissen Sie, dass Sie etwas haben, woran Sie in Zukunft arbeiten können.

Dokumentation

Sowohl Arbeitnehmer als auch Arbeitgeber müssen die geäußerte und erhaltene konstruktive Kritik dokumentieren. Mitarbeiter sollten Aufzeichnungen über jedes Feedback führen, das sie für ungerechtfertigt halten. Schriftliche Korrespondenz dient als Protokoll. Führen Sie zum Beispiel ein Tagebuch über den mündlichen Austausch und Kopien von E-Mails oder Berichten, die die Leistung in einem schlechten Licht darstellen. Weder ein Arbeitnehmer noch ein Arbeitgeber sollte versuchen, sich auf unprofessionelle Weise an einem Kontrahenten zu rächen.

Verbesserung

Konstruktive Kritik an der Teamleistung am Arbeitsplatz ermöglicht es den Mitarbeitern zu erkennen, dass sie nicht perfekt sind. Vergangene Teamkonflikte sollten die aktuelle Projektarbeit nicht beeinträchtigen. Wenn nötig, vereinbaren Sie ein Treffen, um die Situation zu klären. Jeder Mensch macht Fehler. Um die Teamleistung zu maximieren, sollten Sie jeden Mitarbeiter dazu ermutigen, die Verantwortung für seine Arbeit zu übernehmen, die Ergebnisse doppelt zu überprüfen und sich zu vergewissern, dass er die beste Arbeit leistet, bevor er sie abgibt. Dadurch werden Flüchtigkeitsfehler, dumme Fehler und peinliche Probleme vermieden. Durch die Schaffung eines Umfelds, in dem jeder erwartet, Feedback zu erhalten, schafft ein Teamleiter einen Arbeitsplatz, der übermäßig kritische Kommentare auf ein Minimum reduziert und sich auf kontinuierliche Verbesserungen konzentriert.