In der Vergangenheit gab es eine natürliche Spannung zwischen Operationen (Ops) und Entwicklern. Die Mission von Ops ist es, die Systeme stabil und funktionsfähig zu halten. Für die meisten Systeme, wenn sich nichts mit dem System ändert, wird es sich tendenziell so verhalten, wie es in der Vergangenheit war. Entwickler sind jedoch typischerweise dazu angehalten, die Nutzung des Systems zu erhöhen, was bedeutet, ob gut oder schlecht, mehr Funktionen. Neue Funktionen führen zu schnellen Änderungen am System und es wird ein gewisses Maß an Instabilität und Risiko in das System eingeführt. Diese gegensätzlichen Anreize erzeugen eine immense Spannung zwischen den beiden Teams. Dies führt dazu, dass Operationen den Zugang zu den Maschinen verhindern und somit die Freiheit haben, alle damit verbundenen Operationen durchzuführen. Dies beendet neue Ideen wie Mikroservices innerhalb des Unternehmens, da die Infrastruktur immer erforderlich ist, um neue Services bereitzustellen, und neue Infrastrukturen eine enge Zusammenarbeit mit einem anderen Team erfordern. Diese Spannung ist nicht gut und schafft eine Division innerhalb Ihrer Ingenieurteams, die zu keinem Fortschritt führt, weil sich die beiden Teams weigern, einander zu helfen. Dies schadet nicht nur der Produktivität, sondern letztlich auch dem Glück Ihrer Mitarbeiter und sie werden anfangen zu gehen. Wenn ich etwas so gelernt habe wie meine Tätigkeit als Engineering Leader, dann ist das Folgendes: Wenn Sie Ihre Mitarbeiter glücklich machen wollen, müssen Sie sicherstellen, dass sie produktiv sind. Glücklich bedeutet, mit anderen Ingenieurteams zusammenzukommen und die Kultur zu vereinen, anstatt eine spaltende zu schaffen.

"Mit großer Macht kommt große Verantwortung."

Als Team sind wir alle für die Software verantwortlich, die wir in Produktion geben, nicht nur Ops oder Entwickler. Das bedeutet, dass wir eine Anreizstruktur schaffen müssen, die sowohl Ops als auch Entwicklern ein gemeinsames Ziel gibt. Devops hat für verschiedene Leute viele Bedeutungen, aber für uns bei ShareThis bedeutet es, dass es eine hohe Überlappung zwischen den Funktionsbereichen Betrieb, Entwicklung und QA gibt. Damit Entwickler also die Macht haben, Änderungen in der Produktion vorzunehmen, müssen sie für ihre Handlungen verantwortlich sein. Aus diesem Grund glauben wir, dass es wichtig ist, dass Entwickler einen Bereitschaftsdienst haben, falls etwas schief geht. Entwickler sollten erfahren, wie es ist, alarmiert zu werden, wenn ihr Code unerwartete Probleme verursacht. Dadurch wird die Last, Probleme außerhalb der Geschäftszeiten zu lösen, auf das gesamte Team verteilt und nicht nur auf die Schultern des Betriebs oder eines einzelnen Teams.

SLA und SLA-Zulage

Eine der wichtigsten Aktivitäten ist die Definition eines SLA für Services. Dies definiert die Erwartungen an die Stabilität eines Systems an die Kunden, Entwickler und Betriebsleiter. Aber das Ziel sollte nie sein, eine 100%ige Verfügbarkeit zu haben, denn das könnte bedeuten, dass Sie sich zu langsam bewegen und nicht genügend Risiken eingehen. Bei einem Startup geht es darum, kalkulierte Risiken einzugehen und sich schnell zu bewegen. Um das Risiko quantitativer zu erfassen, verwenden wir SLA-Zertifikate. Wir können unsere Risikobereitschaft berechnen, indem wir das SLA nehmen und 1 abziehen. Wenn Sie also ein 99,9%iges Verfügbarkeits-SLA haben, können wir ein SLA-Zuschuss durch die folgenden 1 - 0,999 = .001 berechnen, was unser SLA-Zuschuss ist. Das bedeutet, dass die Website 43 m Ausfallzeit haben kann, bevor Sie die vereinbarte Betriebszeit aufgebraucht haben. Auf diese Weise können Entwickler so oft wie gewünscht einsetzen, solange sie ihre SLA-Zertifikate nicht erreichen. Sobald dies geschehen ist, können keine neuen Funktionen mehr bereitgestellt werden, sondern das Team sollte sich auf Stabilität konzentrieren. Dabei liegt der Schwerpunkt auf automatisierten Tests und Überwachungen, um sicherzustellen, dass ihre Anwendungen keine Probleme in der Produktion verursachen. Dies stellt auch ein gesundes Gleichgewicht zwischen Geschwindigkeit und Risikobereitschaft her, das vorher vereinbart werden kann. Im gesamten Büro bauen wir Dashboards, die schnell Anomalien anzeigen können, so dass wir alle Änderungen rückgängig machen können, bevor es zu SLA-Verletzungen kommt.

Die Ergebnisse

Seitdem wir in der "DevOps"-Kultur arbeiten, haben wir eine dramatische Zunahme der Zusammenarbeit zwischen Teams und eine Steigerung der Produktivität erlebt. Der gesamte Besitz von Anwendungen von der Entwicklung bis zur Produktion hat sich über das gesamte Team verteilt, und wir sind nun in der Lage, Server und Infrastruktur innerhalb von Sekunden gegenüber Wochen aufzurüsten. Für unsere Kunden bedeutet das neue Funktionen und Servicestabilität. Für unsere internen Stakeholder bedeutet dies vorhersehbare Zeitpläne. Für unser Team sind diese Veränderungen vor allem ein Gefühl der Eigenverantwortung und Produktivität.

Wenn Sie sich für diese Art von Arbeitsumfeld interessieren, besuchen Sie bitte unsere Seite mit den Möglichkeiten:
https://sharethis.com/careers/