Autonomie (bei Dev/Ops-Tools) ist nicht gleichbedeutend mit einem Verlust an Kontrolle

Warum stellen Unternehmen auf ein Dev/Ops-Arbeitsmodell um?

Meiner Meinung nach gibt es dafür einen Hauptgrund:

Die Zusammenführung von Entwicklung und Betrieb (und - wenn möglich - des Geschäfts) in einem Team hilft dem Team, sich auf seinen Beitrag zu einer bestimmten Geschäftsfunktion im Unternehmen zu konzentrieren. Es besteht keine Notwendigkeit mehr für eine Spezialisierung in dem Sinne, dass die Teams nur Dinge tun, die auf bestimmten Technologien basieren. Dev/Ops-Teams können sich jetzt wirklich auf den geschäftlichen Nutzen konzentrieren. Erstens hilft dies den Unternehmen, agiler und schlanker zu werden und dabei ständig Engpässe zu beseitigen. Zweitens können Dev/Ops-Teams  dass ihr Teil des Unternehmens so reibungslos wie möglich funktioniert.

Wie wichtig ist es dann, dass die Teams die Möglichkeit haben, ihren Teil der Geschäftskette zu unterstützen? Sollten sie alle dieselbe Art von Tools in den verschiedenen Teams verwenden, nur weil es einen Architekten gibt, der ihnen das vorschreibt? Oder sollten sie die Freiheit haben, die Technologien/Produkte auszuwählen, die sie benötigen, um ihre Akquisitionen so zu unterstützen, wie sie es für richtig halten?

Wahlfreiheit
Zunächst ein Beitrag über "Wahlfreiheit - Drei Wege, wie Dev/Ops die Unternehmenssoftware revolutioniert". Darin werden alle möglichen Tools besprochen, aber ich möchte mich auf den Teil zur Überwachung konzentrieren. Am Ende heißt es Folgendes:  "Es ist wichtiger, das zu bekommen, was Sie brauchen (maßgeschneiderte, relevante Metriken), als es in einer hübschen Verpackung zu bekommen". Der Blogpost geht sogar noch weiter und fragt, warum wir überhaupt APM-Tools brauchen. Meiner Meinung nach brauchen Sie vielleicht noch das eine oder das andere. Aber es ist viel wichtiger, dass die Teams in der Lage sind, ihre eigenen Entscheidungen zu treffen.

In einem Slidedeck"Dev/Ops", Dev/Ops heißt "ein Kulturwandel oder eine Bewegung, die eine gute Zusammenarbeit fördert, um schneller und zuverlässiger bessere Software zu entwickeln". Das grundlegendste Ziel, das es beschreibt, ist die Beseitigung von Verschwendung (Lean). Mit der Freiheit, die besten Tools zu wählen, hat ein Dev/Ops-Team die Möglichkeit, Verschwendung auf die effizienteste Weise zu beseitigen. Aus diesem Grund ist die Wahlfreiheit bei Devops-Tools so wichtig.

Warum zentralisierte Tools verwenden?

Wenn wir uns genauer ansehen und fragen, warum zentralisierte Tools (für die Überwachung) gewählt werden, sehen wir, dass es dafür zwei Hauptgründe gibt:

 
1. Es gibt nur eine kleine Anzahl von Teams, sagen wir 2 bis 3. In diesen Fällen ist es sinnvoll, das Wissen auf eine kleinere Anzahl von Tools zu konzentrieren.

2. In größeren Unternehmen besteht die Notwendigkeit, alle Geschäftsprozesse, Anwendungen und die Infrastruktur in einem einzigen Fenster zu betrachten.

In den letzten Jahrzehnten wurden viele Überwachungstools entwickelt, aber keines dieser Tools bietet Ihnen wirklich eine einzige Sichtscheibe. Keines von ihnen ist wirklich in der Lage, tiefe Einblicke in alle Geschäftsprozesse, Batch-Prozesse, Leistungsmetriken von Anwendungen, Protokolleinträge usw. zu geben.

Die Entscheidung für eine einzige Lösung zur Lösung eines Problems in einigen Teams lässt keine Wahlfreiheit zu. Ich habe schon viele Teams gesehen, die gezwungen waren, bestimmte Tools zu verwenden, nur weil sie für andere Teams gut waren. In diesen Teams waren diese Tools nicht die beste Lösung, so dass sie Verschwendung verursachten, anstatt Verschwendung zu reduzieren, indem sie die Freiheit hatten, ihre eigenen Tools zu wählen.

Der Bedarf an einheitlichen Tools
Ich habe gerade einen weiteren Artikel über"Dev/Ops und Continuous Delivery in die Tat umsetzen" gelesen. Unter am Ende ("die Notwendigkeit einheitlicher Werkzeuge für eine einheitliche Arbeit") heißt es Folgendes: "Die besten Tools spiegeln die laufenden und parallelen Entwicklungs-, Test- und Bereitstellungsaktivitäten wider, die den Kern der kontinuierlichen Bereitstellung bilden. Suchen Sie nach etwas, das die Informationen aus verschiedenen Funktionen wie Änderungsverwaltung, Versionskontrolle, Problemverfolgung und Überwachung integriert und von Entwicklern, Betreibern, Testern und anderen genutzt werden kann.

Niek Bartholomeus, ein unabhängiger Softwarearchitekt in Antwerpen, der kürzlich eine europäische Bank bei der Umstellung auf eine häufigere Lieferung unterstützt hat, sagt: "Für mich ist das ein idealer Start für ein Team, um Einblick in die Arbeit des anderen Teams zu bekommen und die Kluft zwischen ihnen zu überbrücken."

Warum wir StackState aufbauen 

Das bringt mich zu einem der Hauptgründe, warum wir StackState entwickeln. Es scheint eine Notwendigkeit zu sein, alle Arten von Überwachungs-, IT-Management- und Incident-Management-Tools wiederverwenden zu können, insbesondere für größere Unternehmen. Es gibt eine Menge guter Tools, und natürlich werden in naher Zukunft noch mehr zur Verfügung stehen. Aber einen vollständigen Überblick über den gesamten Stack zu haben, ist einfach eine andere, wahrscheinlich eine höhere Ebene von Bedeutung.  Einstein sagte einmal: "Kein Problem kann von derselben Bewusstseinsebene aus gelöst werden, die es geschaffen hat." Wir glauben daher nicht, dass es ein sogenanntes Meta-Werkzeug geben wird, das alles überwachen kann. Wir sind daher der Meinung, dass dieses Meta-Tool-Konzept durch das eines Umbrella-Tools ersetzt werden sollte. Eine 'Anwendung', die eine einheitliche Sicht auf alle Daten der verschiedenen Tools erzeugt, die in den verschiedenen Abteilungen und Dev/Ops-Teams im Einsatz sind.

 

Die Kontrolle innerhalb von Organisationen bewegt sich in Zyklen: von einer zentralisierten Befehls-/Kontrollmentalität zu verteilten, autonomen Teams und wieder zurück. "Dev/Ops zurück in die Zukunft" zeigt dieses Phänomen sehr schön auf.

Innerhalb beider Modelle (zentralisiert und dezentralisiert) bietet StackState einen Mehrwert:
Wir glauben, dass beide Ansätze einen Mehrwert bieten, aber sich gegenseitig benötigen, um wirklich zu funktionieren. Einige Teile erfordern eine Zentralisierung, andere nicht.  

 

1. StackState unterstützt einen zentralisierten Ansatz, indem es einen einheitlichen Überblick über verschiedene Arten von Tools wie APM, Protokollanalyse, Überwachung von Batch-Prozessen, IT-Management (Bereitstellung, Einsatz) und Incident Management Tools schafft. Es funktioniert wie eine einzige Glasscheibe.

2. Die Glas-Metapher beschreibt StackState jedoch am besten. Die Teams bleiben bei der Auswahl ihrer eigenen Werkzeuge autonom. StackState integriert sie einfach.

Wir konzentrieren uns darauf, eine einzige Glasscheibe für Ihren gesamten Stack zu schaffen und gleichzeitig eine dezentrale Verwaltung durch Zusammenarbeit zu ermöglichen.

Einige unserer Produktdesignprinzipien

• Behalten Sie Ihre vorhandenen Tools bei, integrieren Sie sie und nutzen Sie ihre Stärken: Auf diese Weise geben wir den Teams tatsächlich die bereits erwähnte "Wahlfreiheit" und schaffen gleichzeitig eine einzige Scheibe.
• Ermöglichen Sie Zusammenarbeit: Vermeiden Sie eine zentrale Governance: Konzentrieren Sie sich auf die Zusammenarbeit zwischen den (Dev/Ops-)Teams, die ihren Teil des Stacks meist am besten kennen.
• Eine Ansicht sagt mehr als tausend Worte. Anstatt Benutzer mit langen (seitenlangen) Listen tabellarischer Daten zu bombardieren, versuchen wir, so viel wie möglich zu visualisieren. Außerdem sollte sie so aktuell (nahezu in Echtzeit) wie möglich sein und bei Änderungen aktualisiert werden.
• Kollaboration durch ein gemeinsames Verständnis: eine gemeinsame Sicht auf den gesamten Stack zu haben, so dass alle den gleichen Inhalt haben.

Bleiben Sie dran und folgen Sie uns, indem Sie unseren Blog abonnieren. Möchten Sie mehr über StackState erfahren? Fordern Sie eine kostenlose Führung an um ein besseres Verständnis für unsere Lösung zu bekommen.