Gewohnheit #3: Wir konzentrieren uns zu 100% auf die Betriebszeit für alles

Obwohl es auf den ersten Blick nach einer guten Idee aussieht, gibt es einige Gewohnheiten, die Ihr DevOps-Team zum Entgleisen bringen können. In dieser Blogserie packen wir sieben dieser Szenarien aus, damit Unternehmen lernen können, wie man DevOps richtig umsetzt. In diesem Beitrag gehen wir darauf ein, warum "wir konzentrieren uns zu 100 % auf die Betriebszeit für alles" die schlechte Angewohnheit Nr. 3 ist.

Wenn Sie diese Gewohnheit zum ersten Mal sehen, denken Sie vielleicht: "Ja, das macht Sinn! Denn wer möchte nicht eine 100%ig verfügbare Website?

Eine 100%ige Betriebszeit zu erreichen ist sehr schwierig und teuer. Die technischen Details, um dies zu erreichen, erfordern enorme Investitionen - z.B. um sicherzustellen, dass Sie auf anderen Servern oder in anderen Rechenzentren arbeiten können, oder um Backups oder Disaster Recovery oder vollständige Backups oder Replikationen durchzuführen. Das ist alles machbar, aber der Aufwand und die Kosten, die damit verbunden sind, sind enorm.

Wenn Sie zum Beispiel eine Website auf einem Server betreiben, können Sie auch zwei Ausweichserver einrichten. Wenn einer ausfällt, übernimmt der andere. Aber die Anfangsinvestition dafür ist recht hoch, und wenn Sie Änderungen vornehmen müssen, müssen Sie dies für alle Server wiederholen. Die Erstellung oder Änderung Ihrer Anwendung ist also viel langsamer.

Und selbst wenn Sie zu 100% verfügbar sind, gibt es immer noch Dinge, die Sie nicht kontrollieren können, was es fast unmöglich macht, zu 100% verfügbar zu sein. Daher ist es eine gute Sache, Anwendungen hochverfügbar zu machen. Aber es kann eine Verschwendung sein, Anwendungen hochverfügbar zu machen und sie ständig am Laufen zu halten.

Es gibt fast keine Anwendung, die eine 100%ige Betriebszeit benötigt.

Nicht jede Anwendung ist gleich. Wenn Sie eine Anwendung haben, die während der Geschäftszeiten benötigt wird, müssen Sie keine 100%ige Betriebszeit haben. Sie müssen sich Ihre SLAs ansehen. Was ist für eine Einzelhandelsanwendung angemessen? Das Schlimmste, was passieren kann, wenn Sie ausfallen, ist, dass Sie Geld verlieren. Wenn es sich um eine Bankanwendung handelt, ist es wahrscheinlich etwas wichtiger, dass sie zu 99,99% verfügbar ist. Und wenn es sich um eine medizinische Anwendung handelt, die z.B. Herzschrittmacher überwacht, ist es vielleicht entscheidend, dass sie 100 % der Zeit verfügbar ist. "Angemessen" ist hier das Schlüsselwort. Sie müssen nicht für jede Anwendung die ganze Zeit erreichbar sein. Treffen Sie eine bewusste Entscheidung.

Wir hatten einen Kunden, der eine Weihnachtskartenanwendung hatte. Damit wurden Weihnachtskarten verschickt. Sie musste 99,9 % der Zeit verfügbar sein, was erstaunlich ist, denn von Januar bis Mitte Dezember brauchte niemand diese Anwendung.

Die erste Frage, die wir uns stellen, lautet also: "Müssen Sie zu 100% bereit sein?" Denn wenn Sie mit neuen Funktionen experimentieren oder Ihre Software häufiger ausliefern wollen, brauchen Sie Spielraum, um zu wackeln.

[embed]https://www.youtube.com/watch?v=8LfTkV1eaMc[/embed]

Es ist eine strategische Entscheidung.

Wie viel Betriebszeit Sie benötigen, ist eine geschäftliche Entscheidung - und Betriebszeit ist mit Kosten verbunden. Jeder Prozentsatz bedeutet mehr Arbeit und Kosten. Selbst eine Erhöhung von 99,9 % auf 99,999 % könnte die Kosten und die Komplexität Ihrer Implementierung verdoppeln. Braucht die gesamte Anwendung eine einzige Nummer oder können verschiedene Teile der Anwendung unterschiedliche Nummern haben? Wenn Sie alles mit einer Nummer versehen, werden mehrere Teile unnötig komplex.

Nehmen wir ein Beispiel für einen Webshop wie Amazon. Der Bereich, in dem Kunden suchen, klicken und Produkte bestellen, muss die ganze Zeit über funktionieren, sonst verlieren Sie Geld. Menschen, die etwas auf Ihrer Website kaufen möchten, gehen zu Ihrem Konkurrenten. Aber sobald sie ihre Bestellung aufgegeben und bezahlt haben, wird diese Bestellung irgendwo verarbeitet, und Sie haben Zeit, sie in den nächsten Tagen zu versenden. Wenn das Bearbeitungssystem 10 Minuten lang ausfällt, wird die Bestellung 10 Minuten später bearbeitet - was für den Kunden nicht wirklich von Bedeutung ist. Wenn er die E-Mail-Bestätigung nicht sofort, sondern erst 10 Minuten später erhält, spielt das keine Rolle. Das System könnte eine geringere Verfügbarkeit haben, was es billiger und leichter zu ändern macht.

Mit anderen Worten: Sie können eine Zahl angeben: 100% Betriebszeit für die gesamte Anwendung, oder Sie können verschiedene Versionen untersuchen - vielleicht sind es nicht 100%, vielleicht sind es 99,9 und vielleicht ist es nicht alles. Vielleicht sollten einige Teile, die mit dem Benutzer interagieren, wirklich hochverfügbar sein und einige Hintergrundprozesse vielleicht nicht so sehr. Es ist eine viel klügere Entscheidung, alles aufzuteilen, anstatt alles zu 100% verfügbar zu machen.

Fangen Sie an zu reden.

In der Praxis sagen viele Ingenieurteams, dass sie etwas zu 99,999% verfügbar machen müssen, weil sie das Unternehmen nicht überzeugen können, die Zahl zu senken. Aber das liegt daran, dass sie nicht die richtigen Gespräche führen. Wie hoch soll die Verfügbarkeit dieser Anwendung sein? Wenn die Unternehmensseite einfach schreit, dass die Anwendung zu 100 % oder 99,9 % verfügbar sein muss, hat diese Zahl einen großen Einfluss. Das Hauptziel sollte darin bestehen, das Gespräch zwischen dem technischen Team und dem Unternehmen zu führen, damit das Unternehmen weiß, welche Auswirkungen diese Zahl hat. Das Unternehmen muss mit einbezogen werden - es muss verstehen, welche Auswirkungen die Betriebszeit auf das Ingenieurteam hat. Je höher Sie diese Zahl ansetzen, desto höher sind die Kosten für die Implementierung und den Betrieb. Diese Diskussion ist also von entscheidender Bedeutung.

Haftungsausschluss: Ändern ist eine größere Herausforderung als das Lesen eines Blogbeitrags!

Wir möchten, dass Unternehmen, die DevOps nicht richtig umsetzen, verstehen, warum. Unser Team kann Ihnen dabei helfen, herauszufinden, was Ihr Team tun kann, um das Beste aus einer DevOps-Arbeitsweise herauszuholen. Kontaktieren Sie uns!

Bis dahin hoffen wir, dass Sie in unserem nächsten Beitrag erfahren, warum "wir haben einen Release Manager" die vierte Angewohnheit eines höchst ineffektiven DevOps-Teams ist.