Lade Inhalt...

Analyse eines Softwareentwicklungsprozesses und Konzipierung einer Monitoring-Lösung unter den Gesichtspunkten von DevOps

Bachelorarbeit 2012 40 Seiten

Informatik - Software

Leseprobe

INHALTSVERZEICHNIS

I Eigenständigkeitserklärung

II Zusammenfassung

III Danksagung

1 Einleitung
1.1 Motivation
1.2 Problemstellung
1.3 Zielsetzung
1.4 Gliederung der Arbeit

2 Grundlagen
2.1 DevOps
2.1.1 Der Begriff DevOps
2.1.2 Was DevOps nicht ist
2.1.3 Der Kern von DevOps
2.1.4 Unterschiedliche Ziele
2.1.5 Blame Game
2.1.6 Culture
2.1.7 Automation
2.1.8 Measurement
2.1.9 Sharing
2.2 Monitoring
2.2.1 Hardware
2.2.2 Betriebssystem
2.2.3 Laufzeitumgebung
2.2.4 Anwendung
2.3 Nagios
2.3.1 Hosts
2.3.2 Services
2.3.3 Contacts
2.3.4 Plugins
2.3.5 Eskalationsstufen

3 Stand der Technik

4 Analyse der aktuellen Situation im Wilken SmartBusiness Bereich
4.1 Grundlegendes
4.2 Culture
4.3 Automation
4.4 Sharing
4.5 Measurement

5 Monitoring-Lösung
5.1 Testumgebung
5.2 Testanwendung
5.3 Spring Web MVC
5.4 Test der Webanwendung
5.5 MBeans implementieren
5.6 Test der Remote Method Invocation (RMI) Sebastian Strissel
5.7 Verbindung zu Nagios
5.8 Graphische Darstellung
5.9 Gesamtübersicht

6 Zusammenfassung und Ausblick

V Abbildungsverzeichnis

VI Tabellenverzeichnis

VII Literaturverzeichnis

VIII Glossar

Sebastian Strissel

II. ZUSAMMENFASSUNG

Thema: Analyse eines Softwareentwicklungsprozesses und Konzipierung einer

Monitoring-Lösung unter den Gesichtspunkten von DevOps

Bachelorand: Sebastian Strissel

Unternehmen: Wilken GmbH

Abgabedatum: 14. September

Diese Bachelorarbeit setzt sich mit dem Vorgehensmodell DevOps auseinander. Dazu werden Begrifflichkeiten erklärt und Differenzen anhand einer Analyse der aktuellen Situation der Bereiches SmartBusiness der Firma Wilken aufgezeigt

Ein Schwerpunkt wird hierbei auf den Teilprozess Monitoring gelegt. Es werden in der Arbeit mögliche Monitoring-Lösungen aufgezeigt. Eine Monitoring-Lösung, die den Ansätzen von DevOps entspricht, und welche an die Vorgänge der Abteilung SmartBusiness angepasst ist, wird vorgestellt

Sebastian Strissel

III Danksagung

Mein Dank gilt den beiden Betreuern, Prof. Dr. Rüdiger Lunde, von der Hochschule Ulm, sowie Jens Gohrke, von der Firma Wilken, die es mir ermöglicht haben diese Bachelorarbeit durchzuführen Des weiteren möchte ich dem gesamten Team der Abteilung SmartBusiness für die offene und herzliche Aufnahme danken Besonderer Dank gilt Prof. Dr. Rüdiger Lunde, Jens Gohrke und Michael Nahler, aus der Abteilung SmartBusiness, Marina Stumpp sowie Gloria Gessinger die mich mit Anregungen zur Gestaltung der Bachelorarbeit unterstützt haben Zuletzt danke ich meinen Freunden und der Familie, die mich besonders zur letzten Phase der Bachelorarbeit unterstützt, getragen und ertragen haben

Sebastian Strissel

1 Einleitung

1.1 Motivation

Sobald eine Firma wächst und immer mehr Menschen dazu stoßen, bleibt es nicht aus, dass sich die Firma organisiert, indem sie Abteilungen schafft und Kompetenzen verteilt. Dadurch kommt es zu Kapselungen und Spezialisierungen. Die Kommunikationswege werden länger und das Verständnis für die Arbeiten in anderen Abteilungen schwindet. Bei abteilungsübergreifenden Projekten, deren Devise ”release early and often” lautet, wirkt sich dies negativ aus. DevOps ist der Begriff für eine Bewegung, mit Prinzipien, Methoden und Werkzeugen, welche die Kluft zwischen Entwicklung und Administration schließt, um so den Anforderungen an immer schnellere und flexiblere Änderungen gerecht werden zu können. Mit Hilfe von DevOps soll die Grundidee von agilen Methoden auch auf die Administration ausgeweitet werden, und damit ein nahtloser Prozess, von der Entwicklung, bis hin zum Nutzer, entstehen. Durch die verstärkte Zusammenarbeit von Entwicklung und Administration wird die Produktivität und Qualität gesteigert.

1.2 Problemstellung

Innerhalb der Firma Wilken besteht die Abteilung SmartBusiness, die sich unter anderem mit der Entwicklung von Softwarelösungen für Kartensysteme beschäftigt. Die Abteilung setzt auf häufige Releases und kurze Zyklen und stößt dabei an ihre Grenzen. DevOps soll hier nun Abhilfe schaffen indem Teilprozesse analysiert und den Ansätzen von DevOps angepasst werden.

1.3 Zielsetzung

Ziel dieser Bachelorarbeit ist es, Differenzen zwischen dem Vorgehensmodell der Abteilung Smart- Business bei der Firma Wilken, und DevOps aufzuzeigen. Vertiefend soll der Teilprozess Monito- ring unter Berücksichtigung der Ansätze aus DevOps angepasst werden. Dazu soll eine DevOps- konforme Monitoring Lösung mit Nagios konzipiert werden, indem Schnittstellen zu den Schichten Appliance, Application-Server, Java Virtual Machine und Java-Anwendung ermittelt und bewertet werden.

1.4 Gliederung der Arbeit

In Kapitel 1 (Einleitung) wird auf die Motivation, Problemstellung und die Zielsetzung, sowie die Gliederung dieser Bachelorarbeit eingegangen.

In Kapitel 2 (Grundlagen) werden die, in den folgenden Kapiteln eingesetzten und für die Bear- beitung der Bachelorarbeit zu Grunde liegenden Begrifflichkeiten DevOps, Nagios und Monitoring erklärt.

In Kapitel 3 (Stand der Technik) wird anhand von Umfrageergebnissen aufgezeigt, wie bekannt DevOps in Firmen ist und wie es in diesen realisiert und betrieben wird.

In Kapitel 4 (Analyse der aktuellen Situation im Wilken SmartBusiness Bereich) werden die grundlegenden Vorgänge bei der Entwicklung von Software, in der Abteilung SmartBusiness der Firma Wilken, betrachtet und Differenzen zu DevOps aufgezeigt.

1.4. GLIEDERUNG DER ARBEIT

In Kapitel 5 (Monitoring-Lösung) wird ausgehend von den, in der Analyse ermittelten, Ergebnissen eine Monitoring-Lösung in einer Testumgebung aufgebaut.

In Kapitel 6 (Zusammenfassung und Ausblick) findet eine selbstkritische Beurteilung der beschriebenen Monitoring Lösung sowie möglicher Verbesserungen statt.

2 Grundlagen

2.1 DevOps

2.1.1 Der Begriff DevOps

DevOps ist ein Begriff, der sich aus den zwei englischen Wörtern Developers und Operators zusammen setzt. Zu deutsch, Entwickler und Administratoren. Er wurde zum ersten mal 2009, während der ”DevOps Days” in Belgien, öffentlich verwendet und steht sowohl für eine Bewegung, die sich innerhalb der IT-Branche gebildet hat, als auch für die Ziele, die diese verfolgen. Welche Ziele das sind, wird in den folgenden Kapiteln erläutert.

2.1.2 Was DevOps nicht ist

Um zu beschreiben was DevOps ist, ist es sinnvoll erst einmal aufzuzeigen was DevOps nicht ist.

Abbildung 1: We want you! [Hü12]

Abbildung in dieser Leseprobe nicht enthalten

Das obige Bild, aus dem Buch ”DevOps for Developers” von Michael Hüttermann, ist eine überspitzt ausgeführte Stellenanzeige für einen DevOps Ingenieur. Anhand einiger Punkte können die größten Falschannahmen zu DevOps aufgezeigt werden.

-”Shuttle service between departments” Die Trennung zwischen Entwicklung und Administration ist nicht nur eine Ideelle, sondern

2.1. DEVOPS

meistens auch eine Räumliche. Um effektiv arbeiten zu können, müsste ein DevOps Ingenieur stets zwischen den beiden Abteilungen pendeln, da jede ihre eigenen Aufgaben und Problemstellungen hat. Bei DevOps geht es aber nicht darum, eine Person zu haben, die zwischen den Abteilungen pendelt und vermittelt, sondern vielmehr um zwei Abteilungen, die stark mit einander kollaborieren.

-”Excellent knowledge of DevOps tool suites”

Es gibt keine Tool-suites um DevOps zu betreiben. Vielmehr gibt es eine Anzahl von Werkzeugen die idealerweise einem gegebenen Prozess angepasst sind und sowohl von Entwicklern, als auch Administratoren gleichermaßen genutzt werden.

-”average anti-silo thinking”

Sowohl die Entwicklung, als auch die Administration sind eigenständig arbeitende Abteilungen (engl. silos). Diese benutzen unterschiedlichste Werkzeuge um sich die tägliche Arbeit zu erleichtern. Ein DevOps Ingenieur muss sie alle kennen und beherrschen.

2.1.3 Der Kern von DevOps

DevOps steht für Prinzipien, Methoden und Werkzeuge, die es Softwareentwicklern und Admini- stratoren ermöglichen sollen, den Anforderungen von immer schneller entwickelte Software gerecht zu werden. DevOps legt dabei auf vier Gebiete einen Schwerpunkt. Culture, Automation, Measu- rement und Sharing.

Abbildung 2: Grundpfeiler von DevOps

Abbildung in dieser Leseprobe nicht enthalten

Culture (dt. Kultur) setzt sich mit der zwischenmenschlichen Beziehung von Entwicklung und Administration mittels richtigem Umgang auseinander. ”Menschen kommen vor Prozessen und Werkzeugen. Software ist von Menschen und für Menschen gemacht.” [Hü12]

Automation ist essentiell für DevOps um schnelles Feedback zu erhalten.

Measurement (dt. Messung) ”If you can’t measure, you can’t improve.” Eine erfolgreiche Implementierung von DevOps misst alles, so oft es geht: Leistungsmetriken, Prozessmetriken und sogar Metriken von Personen.

2.1. DEVOPS

Sharing (dt. das Teilen) erzeugt eine Kultur, in der Menschen Ideen, Prozesse und Werkzeuge teilen.

2.1.4 Unterschiedliche Ziele

Entwicklung und Administration verfolgen un- terschiedliche Ziele. Für die Erfüllung der Ziele wird die jeweilige Gruppe mit Lob, Anerken- nung oder Geld ”belohnt”. Das Problem ist, dass diese Ziele miteinander konkurrieren. Die Entwicklung setzt beispielsweise für ei- ne Software neue Features um, fügt Bugfixes ein oder arbeitet Anfragen ab. Diese Tätig- keiten kann man unter dem Begriff ”Änderun- gen” zusammenfassen. Diese Änderungen sol- len schnellstmöglich dem Kunden verfügbar ge- macht werden.

Administratoren dagegen, wollen ein stabiles Produktivsystem sicher stellen. Daher möchten sie, wenn eine Software einmal an den Kunden

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Unterschiedliche Ziele

geliefert wurde, Änderungen vermeiden, um die Stabilität des Produktivsystems nicht zu gefährden. ”Stabilität” ist das erklärte Ziel der Administratoren.

2.1.5 Blame Game

”In der Regel treffen Devs und Ops unter Zeitdruck aufeinander, zum Beispiel beim Deployment eines neuen Releases oder wenn es ein Problem, wie einen Systemausfall, gibt.”, so Peschlow [Pes12]. Dann beginnt das typische Blame-Game, bei dem beide Lager (Entwicklung und Administration) sich gegenseitig die Schuld an der Situation geben.

Die Entwicklung tadelt die Administratoren, weil sie die Software nicht live stellen können oder wollen. Die Administration dagegen ta- delt die Entwickler wegen ihrer Unfähigkeit pro- duktionsreife Software zu entwickeln. Hütter- mann [Hü12] geht davon aus, dass die Ursa- chen für die auftretenden Probleme divergie- rende Ziele, Prozesse und Werkzeuge der bei- den Lager sind. Nehmen wir an, dass eine auf dem Entwicklungssystem funktionierende Soft- ware auf dem Produktivsystem nicht lauffä- hig gemacht werden kann. Weder die Entwick- ler, noch die Administratoren sind sich einer Schuld bewusst. Nun könnte es passieren, dass

Abbildung 4: Blame Game [Hü12] sich die beiden gegenseitig beschuldigen. Nach

Abbildung in dieser Leseprobe nicht enthalten langwierigen Diskussionen fällt auf, dass das Entwicklungs- und das Produktivsystem sich voneinander in einer kleinen Einstellung unterscheiden. Anstatt sich gegenseitig die Schuld am Problem zu geben wäre es sinnvoller die Zeit zu nutzen und gemeinsam an der Lösung des Problems zu arbeiten.

2.1.6 Culture

Im Anschluss an die ersten DevOpsDays veröffentlichte Patrick Debois auf seinem Blog ”And remember it’s all about putting the fun back to IT!” [Deb09]. Dieser Satz, so kurz er auch ist, gibt sehr gut wieder, worum es bei dem kulturellen Aspekt von DevOps geht. Laut Patrick Peschlow [Pes12] kommt es dabei auf den gegenseitigen Respekt an. Dieser sei eine Voraussetzung für Vertrauen und eine gute Zusammenarbeit. Er zählt hierbei folgende kulturelle Bausteine auf:

- Selbstverpflichtung der Beteiligten auf Ziele
- aufmerksames Zuhören
- gegenseitige Weiterbildung
- Etablierung gemeinsamer Ziele

Mit einer respektvollen und vertrauensvollen Zusammenarbeit ließe sich das Blame-Game vermei- den.

Michael Hüttermann [Hü12] führt in seinem Buch auf, dass es bei der Kultur in DevOps um Vertrauen und ein Zusammengehörigkeitsgefühl geht. Seiner Ansicht nach, kommt der Mensch vor dem Prozess und der Prozess vor den Werkzeugen. Das heißt, dass zuallererst das Verhältnis zwischen Entwicklern und Administratoren stimmen muss, bevor man sich Gedanken über Prozesse oder gar Werkzeuge machen kann.

Hüttermann meint, dass DevOps zu Teams führen würde, die Experten zusammen bringt, welche ihre Fähigkeiten und Erfahrungen miteinander teilen. Alle Experten hätten zumindest ein grundlegendes Verständnis über das Geschäftsgebiet der anderen. Bei DevOps ginge es um Teamplay und den Ansatz einer kooperativen Problemlösung.

Abbildung 5: DevOps-Teams [Hü12]

Abbildung in dieser Leseprobe nicht enthalten

2.1.7 Automation

Die Automation von Vorgängen durch geeignete Werkzeuge ist einer der zentralen Gedanken von DevOps. Dieser lässt sich aber nur umsetzen, wenn alle an einem Strang ziehen. Das soll heißen, dass man sich erst Gedanken über die Automation von Vorgängen machen sollte, wenn eine Kultur der Zusammenarbeit zwischen Entwicklung und Administration herrscht.

Durch die Automatisierung sollen laut Peschlow [Pes12] Vorgänge transparent und nachvollziehbar gemacht werden.

Der wichtigste Bestandteil ist seiner Meinung nach ”Infrastructure as Code”. Serverkonfigurationen, Installationen von Paketen, Beziehungen zwischen Servern und vieles mehr werden dabei in Code modelliert.

Dadurch kann erreicht werden, dass die Konfiguration der Entwicklungs-, Test- und Produktivumgebung automatisiert auf den selben Stand gebracht wird. Ein mit Infrastrucutre as Code in Zusammenhang gebrachtes Werkzeug ist Puppet von der Firma Puppet Labs1.

Daraus erzielte Vorzüge sind:

- Zentrale Verwaltung des Quellcodes unter Nutzung von Versionskontrolle
- Hohe Transparenz und Vermeidung von Wissensinseln
- Automatisiertes Testen der Konfiguration von Servern und virtuellen Maschinen
- Automatisiertes Testen von Deployments und der anschließenden Verfügbarkeit von beteiligten Systemen und geschäftskritischen Softwarefunktionen
- Gemeinsame Nutzung von Konfigurations- und Deployment-Vorschriften durch Entwicklung und Administration

2.1.8 Measurement

Ein weiterer, wichtiger Bestandteil der Softwareentwicklung ist laut Hüttermann [Hü12] zu messen was man tut. Dabei könne eine Vielzahl von Metriken verwendet werden.

- Mean Time Between Failure (MTBF)
- Mean Time To Repair (MTTR)
- Mean Time to Rollback
- Wie viele offenen Fragen konnten in einer Periode x gelöst werden?
- Kosten durch die Entwicklung
- Länge eines Entwicklungszyklus
- Anzahl der umgesetzten Features innerhalb einer Periode
- Zeit die für die Umsetzung eines Features verwendet wurde

Für die erfolgreiche Einführung von DevOps sei es wichtig, dass Metriken benutzt werden, die sowohl den Entwicklern als auch den Administratoren nutzen. Entwickler sollen sich nicht nur auf das Messen während des Softwareentwicklungsprozesses beschränken, sondern darüber hinaus, auch Daten zum Betrieb der Software sammeln. Ein schnelles Feedback ermögliche es, das Risiko von auftretenden Probleme zu minimieren indem sie frühzeitig erkannt würden.

2.1.9 Sharing

Ein weiterer, grundlegender Eckstein von DevOps ist das Sharing. Der Blick über den eigenen Tellerrand soll gewagt werden. Je mehr ein Team aus Entwicklern und Administratoren sowohl untereinander, als auch in der Gruppe selbst teilt, desto mehr Verständnis entsteht für die Sicht- weise der anderen. Damit dies funktionieren kann, ist eine Kollaboration zwischen beiden Parteien notwendig.

Wissen

Das Teilen von Wissen, in einer Gruppe und über diese hinaus, vermeidet Wissensinseln. Die gesamte Gruppe soll durch das eingebrachte Wissen der Einzelnen lernen. Bei einer Gruppe aus Spezialisten, die ihr Wissen nicht untereinander teilen, ist der Einzelne unentbehrlich. Ein Ausfall eines Einzigen könnte ein ganzes Projekt gefährden. Wird das Wissen aber geteilt, so ist es möglich einen Ausfall teilweise, oder sogar komplett zu kompensieren. Zudem ermöglicht neues Wissen neue Sichtweisen auf bestehende Probleme.

Werkzeuge

Sowohl die Entwicklung, als auch die Administration, setzt für die Erleichterung ihrer tägliche Arbeit Werkzeuge ein. Diese Werkzeuge sind meist so spezialisiert, dass nur eine dieser Gruppen damit umgehen kann. Für eine Zusammenarbeit zwischen beiden ist es sinnvoll gemeinsame Werkzeuge zu benutzen. Entwicklung und Administration schaffen sich damit eine gemeinsame Basis.

Tabelle 1: Dev-, Ops- und DevOps-Tools

Abbildung in dieser Leseprobe nicht enthalten

Ziele

Wie bereits in Kapitel 2.1.4 (Entwicklung vs. Administration) erwähnt, haben Entwicklung und Administration unterschiedliche, miteinander konkurrierende Ziele. Das führt laut Hüttermann [Hü12] zu einem Graben zwischen diesen beiden Gruppen. Einige für Änderungen und andere für Stabilität zu belohnen erzeugt Konflikte. Sinnvoller wäre es ein gemeinsames Ziel zu definieren. Dieses könnte beispielsweise ”Entwicklung von stabilen Änderungen” sein. Alleine schon das definieren von gemeinsamen Zielen erleichtert es zwei Gruppen einander näher zu bringen.

Probleme

”Geteiltes Leid ist halbes Leid”. Dieser Satz gibt sehr gut wieder, worum es beim Teilen von Problemen geht. Manchmal ergeben sich mit einer anderen Sichtweise auf ein Problem Lösungen, die man übersehen hat. Das Teilen von Problemen, über eine Gruppe hinaus, soll nicht als Schwäche der Gruppe angesehen werden, sondern als offenes Kommunizieren. Ein Problem innerhalb der Gruppe zu lösen ist schwierig, wenn sich diese auf eine Sichtweise eingefahren hat. Die dafür verschwendete Zeit kann vermieden werden, wenn ein dritter von diesem Problem erfährt (vielleicht schon erfolgreich gelöst hat) und seine seine Sichtweise einbringen kann.

[...]


1 http://www.puppetlabs.com/

Details

Seiten
40
Jahr
2012
ISBN (eBook)
9783656685555
ISBN (Buch)
9783656685548
Dateigröße
1.7 MB
Sprache
Deutsch
Katalognummer
v269400
Institution / Hochschule
Hochschule Ulm – Informatik
Note
1,7
Schlagworte
DevOps Monitoring

Autor

Teilen

Zurück

Titel: Analyse eines Softwareentwicklungsprozesses und Konzipierung einer Monitoring-Lösung unter den Gesichtspunkten von DevOps