OOP 2012 - Udo Pracht - DevOps Einführung und Überblick
•Télécharger en tant que KEY, PDF•
6 j'aime•2,845 vues
Die DevOps-Bewegung - Einführung und Überblick OOP 2012, 24.01.2012 Uhrzeit: 14:00 - 14:45 Sprecher: Udo Pracht Die Bereiche Software-Entwicklung und IT-Betrieb in größeren Unternehmen haben meist eine sehr verschiedene Vorstellung davon, wie selbstentwickelte Anwendungen produktiv genommen und betreut werden. Diese unterschiedliche Zielsetzung führt zu geschäftsrelevanten Verzögerungen, Behinderungen oder gar Ausfällen. Um das Problem zu lösen, will DevOps die Zusammenarbeit von Entwicklern und Administratoren agil gestalten, deren Umgang miteinander verbessern. Der Vortrag stellt den Ansatz und aktuellen Stand des Themas im Überblick vor.
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (12)
Similaire à OOP 2012 - Udo Pracht - DevOps Einführung und Überblick
Similaire à OOP 2012 - Udo Pracht - DevOps Einführung und Überblick (20)
OOP 2012 - Udo Pracht - DevOps Einführung und Überblick
- 2. Probleme & Symptome Die DevOps-Bewegung Lösungsansätze Kritik & Ausblick
- 3. Probleme & Symptome Die DevOps-Bewegung Lösungsansätze Kritik & Ausblick
- 10. Monitoring
- 11. Release-Prozess
- 13. Infrastruktur-Architektur A"n"w"e"n"d"u"n"g"e"n" Infrastruktur5Komponenten" 1" 2" 3" 4" 5" 6" 1" 2" vertikale 3" 4" 5" 6" 7" 8" 9" 10" vs. A"n"w"e"n"d"u"n"g"e"n" 1" 2" 3" 4" 5" 6" 1" horizontale Komponenten" Infrastruktur6" 2" 3" 4" Optimierung
- 16. Probleme & Symptome Die DevOps-Bewegung Lösungsansätze Kritik & Ausblick
- 17. Ursprung/Historie 2009: DevOps Lean Thinking Continuous Kanban Delivery Dev2Ops Agile Sysadmin Agile Service Management Agile Infrastructure 2005 (bei Thoughtworks) Bild von Tobias Geberth unter CC-BY Lizenz
- 18. Konferenz DevOpsDays 2009: Genf 2010: Sydney Mountain View Hamburg Sao Paulo Göteburg 2011: Boston Mountain View Melbourne http://www.devopsdays.org/ Bangalore
- 19. Community Links: • http://agilesysadmin.net/ • http://dev2ops.org/ • http://www.jedi.be/blog/ • http://www.agileweboperations.com/devops-series • http://devopscafe.org/ • http://www.linkedin.com/groups?gid=2825397 • http://www.infrastructures.org/
- 20. Der Hofnarr http://twitter.com/#!/DEVOPS_BORAT
- 21. Hype(r)-Hype(r)! Siehe auch Umfrage von HP und Replay Solutions (April 2011): http://replaysolutions.com/2011-DevOpsSurveyResults
- 22. Probleme & Symptome Die DevOps-Bewegung Lösungsansätze Kritik & Ausblick
- 23. Vier Bereiche • Culture • Automation • Measurement • Sharing
- 24. Gegenseitige Ziele kennen und achten
- 25. Beispiel: Release-Frequenz Seltene&Releases& Anwendungs4Funk'onen) Häufige&Releases& Produk'v)verfügbare)) Zeit)
- 28. Collective Ownership Howto (siehe auch “Natural Planning”) ✤ Zweck und Grundsätze festlegen ✤ Überragendes Ergebnis ausdenken ✤ Brainstorming des Lösungsweges ✤ Strukturieren und Organisieren ✤ Nächste Schritte bestimmen http://www.agileweboperations.com/the-implications-of-infrastructure-as-code
- 29. Prozesse erkennen und anpassen Agile#Entwicklungsmethoden# IT#Service#Management# So*ware. Entwicklung' DevOps# IT.Betrieb' Business'
- 31. Infrastructure as Code import "apache" template "/tmp/somefile" do mode "0644" node server1 { source "somefile.erb" apache { notifies :reload, "service[apache]" version => 1, end conf => "/nfs/configs/server1.conf", user => "www-data", service "apache" do group => "www-data", supports :restart => true, :reload => true } action :enable } end Puppet Opscode Chef http://puppetlabs.com/ http://www.opscode.com/chef/
- 33. Weitere Werkzeuge und Tools • Defect Tracking (z.B. JIRA, Quality Center) • Automated Issue Resolution (z.B. BMC AppSight, ReplayDirector) • Requirements Management (z.B.VersionOne) • Source Code Control (z.B. Subversion, GiT, Team Foundation Server) • Help Desk / Ticket Tools (z.B. Remedy, CA Service Desk, HP Service Manager) • App Performance Monitoring (z.B. Introscope, NewRelic, DynaTrace)
- 34. Software-Lifecycle Agile#Entwicklungsmethoden# IT#Service#Management# So*ware. Entwicklung' DevOps# IT.Betrieb' Business'
- 35. Software-Lifecycle DevOps' Agile#Entwicklungsmethoden# IT#Service#Management# g$ Be run So*ware. re IT.Betrieb' So*ware. itst Entwicklung' ie Entwicklung'alis DevOps# IT.Betrieb' ellu Re ng $ Business' Idee$ Nutzung$ Business'
- 36. Das Versprechen ans Business ✓ Time-to-Market reduzieren ✓ Aufwand und Kosten für Produktivnahme, Betrieb und Betreuung reduzieren ✓ Proaktiv vor Betriebs- Störungen schützen und diese schnell beheben können ✓ Cloud-Computing effektiv nutzen können
- 37. Probleme & Symptome Die DevOps-Bewegung Lösungsansätze Kritik & Ausblick
- 39. Reines Technik-Thema? DevOps Tool-Suite 3.0 NOW De vOps ce rtified Pu De re vO ins ps ide
- 41. Brücken bauen? We don't need to build more bridges [between disciplines], we need to lower the sea of ignorance. Dr. Ian Hacking
- 42. Danke sagt: Udo Pracht Freier IT-Berater und Mediator E-Mail: mail@udo-pracht.de Web: http://www.pracht-mediation.de http://www.udo-pracht.de Blog: http://menschenundit.wordpress.com
Notes de l'éditeur
- ... ich hätte mit mehr spitzen Schreien gerechnet...\n... da gibt es viele Entwickler, die in ITIL nur unnötige Formalismen und Behinderung sehen ...\nUnd das ist schon der Einstieg ins Thema: Bei DevOps geht’s um Software-Entwicklung (Dev) und IT-Betrieb (Ops)! Und um das jeweils eigene und das gegenseitige Verständnis.\nIch kenne beide “Lager” ganz gut und bin sehr erfreut, dass mit DevOps genau diese schwierige Schnittstelle zwischen den beiden beleuchtet wird.\n
- Was passiert jetzt hier?\nSie können die verschränkten Arme lösen und die Geldbeutel loslassen, ich will Ihnen nichts verkaufen oder Sie von etwas überzeugen. Ich werde Ihnen einen Gesamtüberblick über das Thema geben, damit Sie einschätzen können ob und wo DevOps für Ihre Arbeit interessant bzw. relevant ist.\nFreuen würde ich mich, wenn als kleiner Nebeneffekt Ihnen die Idee kommt (oder bleibt), dass der IT-Betrieb nicht ausschließlich zur Behinderung der Software-Entwicklung da ist ;-)\nAgenda\n\n
- \n
- Das was ich Ihnen nun sage, ist die grundlegende Erkenntnis des Themas DevOps.\nWenn Ihnen das hier bewusst ist und bleibt, dann leitet sich alles folgende daraus ab. \n
- Das ist ein Thema für DevOps...\n
- Weiteres Symptom: Die Vorstellung bzgl. der Release-Frequenz zwischen Business, Entwicklung und IT-Betrieb liegen weit auseinander.\n\nIch kenne ein großes Versicherungs-Unternehmen, welches 2011 lediglich drei (!) Releases durchgeführt hat und die Frequenz noch weiter senken möchte. \n
- Cloud-Computing und Virtualisierung bieten die Chance, Rechen- und Speicher- kapazitäten dynamisch und bedarfsgenau zu nutzen und einzukaufen. \nSind die für das Unternehmen geltenden Compliance-Anforderungen erfüllt beziehungsweise erfüllbar, müssen sich Entwicklung und Betrieb auf neue Technik, andere Schnittstellen und eine veränderte Administration einstellen und ihr Vorgehen unter anderem beim Release anpassen. Nicht überall können diese Hürden erfolgreich genommen werden und es bleibt nur das diffuse Fazit: Cloud-Computing ist nichts für uns.\n
- Ein Kern-Element eines professionell geführten IT-Betriebes ist das Monitoring. Der Status der Systeme wird automatisch überwacht und ein Alarm ausgelöst, wenn definierte Fehler-Situationen eintreten. Wie oft kommt es dennoch vor, dass geschäftsrelevante Anwendungs-Probleme trotzdem erst von den Anwendern gemeldet werden? Häufig ist es doch so, dass zwar technische Kennzahlen und die grundsätzliche Verfügbarkeit von Anwendungen im Monitoring beachtet werden, nicht aber die Verfügbarkeit und Fehlerfreiheit einzelner Funktionen, die aber letztendlich erst den Nutzen des Systems für die Anwender darstellen.\n
- Wie ein Release-Prozess aussehen kann oder soll, wird von verschiedenen Konzepten beschrieben, sowohl in ITIL, in den Agilen Methoden als auch in den einschlägigen Projektmanagement-Lehren. Leider sind diese Beschreibungen und die zugehörigen Anforderungen nicht komplett deckungsgleich. Sofern eines der Vorgehen in einem Unternehmen eine stärkere Lobby hat und ohne Rücksicht auf ein Gesamtziel durchgesetzt wird oder aber erst gar kein klarer Weg gewählt wird, kann dies zu folgenden Symptomen führen: unstabile und pflege-intensive Anwendungen in der Produktion oder untragbar lange Zeiten, bis geschäftliche Anforderungen tatsächlich produktiv verfügbar sind.\n
- Im Problem Management geht es darum, die Ursachen von Fehlerserien oder schwerwiegenden Fehlern zu ermitteln und zu beseitigen. Liegen die Ursachen im Umfeld von selbst entwickelten Anwendungen, muss der Betrieb zur Behebung mit den betreffenden Projekt-Teams zusammen arbeiten. Die Entwickler sind jedoch ohnehin schon voll ausgelastet und Fehlerbehebung ist meist nicht gerade deren Lieblingstätigkeit. Bevor also der Help-Desk oder der Second-Level-Support nicht ganz klar bewiesen hat, dass es sich um einen Programmfehler handelt, gibt es keine Hilfe. \nDurch das Hin- und Herschieben der Verantwortung und andere Verzögerungen in der Zusammenarbeit verlängert sich die Zeit bis zur Behebung der Fehlerursache, mit negativen Auswirkungen auf die eigentliche Geschäftstätigkeit.\n
- Wer bestimmte die Infrastruktur-Architektur, die Software-Entwicklung oder der IT- Betrieb? Beide beanspruchen dieses Vorrecht für sich, mit jeweils durchaus validen Begründungen. Auch hier gilt: Wird dies einseitig, ohne Rücksicht und Beteiligung entschieden oder kein klarer Weg gewählt, entstehen aus gesamtgeschäftlicher Sicht Probleme: entweder organisch gewachsene, undurchschaubare und nur schwer wartbare Systemlandschaften oder aber unflexible, veraltete Umgebungen in die moderne, für das Geschäft benötigte Technik nur schwer Einzug findet.\n
- Ein weiterer Diskussionspunkt zwischen Entwicklung und Betrieb ist die Frage, welche Freiheiten Entwickler auf ihren Arbeitsgeräten oder auf den Entwicklungs-Systemen haben. Wenn eine Anwendung auf dem Entwickler-Rechner oder in der Entwicklungs-Umgebung fehlerlos läuft aber keiner mehr weiß, was dafür alles installiert und konfiguriert wurde, dann ist was schief gelaufen. Ein anderes extremes Symptom sind Entwickler, die ihre Zeit überwiegend damit verbringen müssen, Anträge zur Installation von Software zu stellen, die sie für ihre Arbeit benötigen oder die darauf warten, dass ihre beantragten Konfigurations-Änderungen auf dem Entwicklungs-Server durchgeführt werden.\n
- Zum Abschluss noch zwei - provokante - Fragen, die als Anregung zur Reflektion dienen können:\nTruck-Faktor\nWie viele Teammitglieder könnten von einem Truck überfahren werden, bevor das Projekt beziehungsweise der Betrieb ernsthafte Schwierigkeiten hat?\n10ter-Stock-Test\nKönnen Sie eine beliebige Komponente aus der Infrastruktur heraus nehmen, sie aus dem 10ten Stock werfen und die Infrastruktur innerhalb von maximal 10 Minuten wieder herstellen?\n\n
- Die hier genannten Symptome und die Erfahrungen in derartigen Umgebungen waren es, die einigen Systemadministratoren, Entwicklern und Projektleitern den Antrieb gaben, daran etwas verbessern zu wollen.\n
- Grassroots-Movement, kein Manifest (bisher)\nkein abstraktes, theorieüberladenes Framework um (wieder mal) alles abzudecken. \nkeine neue Anforderung, die es aus Compliance-Gründen oder um irgendwo dabei sein zu dürfen zu erfüllen gilt\n2005 ThoughtWorks => "Continuous Delivery" (Buchtitel) von Dan North, Jez Humble, Chris Read, David Farley und Julian Simpson \nHintergrund der Bewegung: Erkenntnisse des agilen Vorgehens. Das, was die Software-Entwicklung dadurch in der Zusammenarbeit mit den Kunden beziehungsweise den Fachbereichen erreicht und verbessert hat, will man nun in den Betriebsbereich bringen. \nBlogs, Büchern und Konferenzen \nAnsätze und Ideen aus Lean Thinking und Kanban\n
- \n
- Blogs\nPodcasts\nDiskussion\nPraxis-Tipps\n
- Der Hofnarr soll unterhalten, darf aber dabei (z.B. durch Spott, Übertreibung und Parodie) auch handfeste Kritik am Herrschenden äußern.\n
- HP hat zusammen mit Replay Solutions eine frei verfügbare Umfrage zum Stand von DevOps veröffentlicht. Aus unterschiedlichen Unternehmens-Größen haben über 1.100 englischsprachige IT-Mitarbeiter teilgenommen. Wichtige Erkenntnisse aus den Antworten sind: \n - fast 50% der Befragten integrieren bereits die DevOps-Idee\n - die Behebung von in der Produktion auftretenden Fehlern läuft deutlich schneller bei denen, die DevOps einsetzen\n - der Prozentsatz der Fehler, die erst in der Produktion entdeckt werden, ist deutlich geringer bei denen, die DevOps einsetzen\n\n
- ... keine detaillierte Vorstellung, so dass Sie anschließend alles umsetzen können ...\n\nAnsätze aufzeigen\n
- \n
- Wie im bekannten Harvard-Verhandlungskonzept geht es auch hier darum, dass alle die eigenen Interessen und die der "Gegenseite" kennenlernen und ihre Berechtigung akzeptieren. Die Entwickler lernen, warum manche restriktiven Anforderungen den Administratoren wichtig sind und Produktions-Fehler schnell behoben werden müssen. Administratoren erkennen hingegen, warum die Entwickler Releases schnell produktiv nehmen möchten, bestimmte Zugriffs- oder Konfigurations-Rechte brauchen oder eine bestimmte Architektur präferieren. Das bedeutet nicht, dass man Forderungen widerstandslos erfüllt sondern im ersten Schritt nur: gegenseitiges Verständnis. Dies soll die Grundlage bilden für eine Veränderung der Zusammenarbeit: Weg vom "Fingerzeigen", hin zum "An-einem-Strang-ziehen". \nDevOps beschreibt eine Kultur beziehungsweise die Veränderung zu dieser.\n
- Beispiel 1 für gegenseitiges Verständnis\nEin zentrales Anliegen – aus Business-Sicht und passend zur agilen Software-Entwicklung – sind häufige Releases. Der Entwicklung rät DevOps, die Sorgen ernst zu nehmen und zusammen mit dem Betrieb geeignete Mitigation-Maßnahmen sowie Vorteile einer höheren Release-Frequenz auch für den Betrieb zu erarbeiten. \nAls Argumentationshilfe weißt DevOps darauf hin, dass bei häufigeren kleineren Releases...\ndas Risiko und der Aufwand eines einzelnen Releases sinkt.\n(üblicherweise) die Differenz zum Fallback-Szenario kleiner wird.\nder Betrieb mehr Übung im Umgang mit Releases bekommt.\nConfig-Switches eine gut praktikable Lösung für das Problem bei zeitlich versetzten Releases zwischen verbundenen Systemen darstellen.\n\n
- Beispiel 1 für gegenseitiges Verständnis\nGeschäfts-, Technik-, Prozess-Metriken\nITIL: Availability Management und Event Management\nBeispiel: Integrationsmöglichkeit für Cucumber in Nagios\n
- Wie lässt sich die Kommunikation verbessern? \nDas ist schon oft beantwortet und DevOps erfindet nicht das Rad neu. \nVorschläge: \n"Collective Ownership" (kommt gleich noch)\nRegelmäßige persönliche Treffen, anfangs gegebenenfalls häufiger und dann seltener werdend\nGemeinsamer Einsatz von Kanban\nAktiver, strukturierter Wissens-Austausch\ngemeinsames Lösen von Problemen und Klären von Fragen (zum Beispiel zur Infrastruktur-Architektur)\nRetrospektiven und Post-Mortems\n
- Stephen Nelson-Smith hat einen Begriff aus der agilen Entwicklung genommen, ihn ein wenig abgewandelt und mit Elementen aus David Allens Natural Planning kombiniert. Mit "Collective Ownership" möchte er erreichen, dass zusammen arbeitende Entwickler und Administratoren jeweils das ganze Thema kennen und sich dafür verantwortlich sehen.\nStephen Nelson-Smith empfiehlt fünf Schritte für die Zusammenarbeit:\nIn einem Workshop die Grundlagen, Prinzipien und Erfolgsindikatoren für die gemeinsame Arbeit finden sowie die Frage nach dem Warum klären, bis hinunter zu den letztendlich darunter liegenden geschäftlichen Anforderungen.\nWie würde ein außergewöhnlich großer Erfolg der Zusammenarbeit aussehen? Was wäre anders und wie?\nBrainstorming zum Thema: Wie kommen wir zu dem gerade skizzierten Ergebnis unter Berücksichtigung der festgelegten Grundsätze?\nAntworten aus dem Brainstorming thematisch sortieren (clustern), zum Beispiel nach: Technologie, Ideen, mögliche Probleme, zu klärendes, benötigte Ressourcen, hinzuzuziehende Personen und so weiter.\nEine Liste mit Aufgaben erstellen und für die als nächstes anzugehenden, Zuständigkeiten und Termine festlegen. Diese Schritte sollen dann – wann immer möglich – jeweils ein Entwickler und ein Administrator gemeinsam durchführen, ähnlich dem Pair Programming.\n
- Sind die Prozesse allen klar und bekannt? Auch die “der anderen”? Auch warum diese oder jene Vorgabe gewählt wurde? => gegenseitiges Verständnis!\n\nWenn das erreicht => prüfen, ob die vorgeschriebenen Prozesse eine andere Zusammenarbeit erlauben\n\nggf. Prozesse müssen Prozesse gemeinsam angepasst werden (Beispiel: Release-Frequenz und ITIL Change Management mit CAB?)\n\nWelche Betriebs-Prozesse von der Bekenntnis zum DevOps-Gedanken berührt werden, ist sicherlich von Unternehmen zu Unternehmen unterschiedlich. Betrachten sollte man zumindest die kompletten Service Support Prozesse nach ITIL v2 beziehungsweise Service Operation und Teile aus Service Transition nach ITIL v3. \n
- Dies ist eine Maßnahme die direkt auf den Truck-Faktor zielt: KnowHow verteilen!\n\nEs soll sicher nicht Ziel sein, dass jeder alles kann und macht\nsondern, dass es möglichst wenig Kopfmonopole und daraus resultierende (potentielle) Engpässe gibt\n\nDas richtige Gleichgewicht muss jedes Unternehmen individuell finden aber das Thema sollte überall oben auf der Agenda stehen!\n
- So, jetzt gibt’s - nach dem Monitoring - nochmal etwas Technik:\nZentrales Konzept der Bewegung: "Treat Infrastructure as Code"\nTheoretisches Maximal-Ziel: Infrastruktur nur aus Blech und verlegten Kabeln sowie einem Repository aufbauen zu können (von den Switches bis hin zum SAN)\n\nAlso: Automatisierung und Scripten, was das Zeug hält...\n\nInfrastructure Management meist aber Configuration Management Tools \nDiverse Open-Source-Projekte und kommerzielle Anbieter, "Puppet" und "Opscode Chef" momentan am verbreitetsten\n
- Ein Schritt auf dem Weg zu diesem Maximal-Ziel: Continuous Build and Deployment\nAlle Veränderungen während eines Releases laufen skriptgesteuert \nsogenannte One-Click-Installationen\n\nDas ist:\nzum einen = Grundlage für hohe Release-Frequenz\nzum anderen, gepaart mit der Unterstützung von Virtualisierungs-Techniken = Voraussetzung, um die Möglichkeiten und Chancen von Cloud-Computing voll nutzen zu können \nEin großer Teil des Engagements für DevOps kommt aus Unternehmen und Projekten, die Cloud-Technologie nutzende Anwendungen erstellen und betreiben.\n\n\n\n
- Neben Infrastruktur-Management und Monitoring gibt es weitere das Thema DevOps berührende Bereiche, in denen Tools Optimierung versprechen.\n\nDies sind alles keine Anwendungen, die aus der DevOps-Bewegung heraus initiiert wurden, die aber deren Ziele unterstützen können und die zudem zunehmend von der Idee befruchtet und verändert werden.\n
- Ja nun, mag mancher nun sagen, was soll das? Cloud-Computing ist für meinen Fall überhaupt nicht passend und nur um die Zusammenarbeit zwischen zwei Bereichen innerhalb der IT zu verbessern, mach’ ich doch nicht so ein Fass auf!\n \nEs sind jedoch nicht irgendwelche Bereiche in der IT! Betrachtet man, wie eine Anwendung von der Idee zur Nutzung kommt, dann ist erkennbar, dass DevOps einen wesentlichen Schritt auf genau diesem Weg adressiert: den Übergang von der Realisierung zur Bereitstellung. \n\nMehrwert für das Unternehmen entsteht ja nicht, wenn die Entwicklung sagt: “Fertig” \nsondern erst dann, wenn das auch produktiv verfügbar ist!\n\nBeispiel von agilen Projekten im Konzern-Umfeld, die mit Sprints arbeiten, deren Ergebnisse aber nur alle vier oder fünf Monate ins Produktiv-System einfließen...\n
- Patrick Peschlow (Javamagazin 1.2012): “Es muss sich lohnen...!”\n\nAll diese Lösungsansätze sollen letztendlich einen für das Unternehmen sinnvollen wirtschaftlichen Nutzen erbringen und der lässt sich aus diesen hier genannten Aspekten ableiten! \n\n
- \n
- Das ist doch von Scrum, ITIL, PMBOK oder irgend einem anderen Konzept schon längst adressiert, längst gelöst und muss nur entsprechend und konsequent umgesetzt werden.\nWenn die eingangs geschilderten Symptome und Probleme nicht auftreten, gibt es auch keinen Grund, sich mit DevOps zu beschäftigen. PUNKT!\n\nFalls aber doch, ist wahrscheinlich genau diese Überzeugung "Ich weiß, wie ihr zu arbeiten habt!" der Grund dafür \nund DevOps bietet dann durchaus eine neue Perspektive.\n
- Ich zeige Ihnen nun etwas ganz geheimes: \nEin neues Tool, mit dem Sie komplett DevOps-compliant werden!!! Kommt nächsten Monat raus!\n\nScherz beiseite! Weiterer Kritik-Punkt: DevOps ist ein rein technisches Thema, das Hersteller als Vehikel nutzen, um neue Software-Werkzeuge und Funktionen zu verkaufen. \n\nDies mag tatsächlich eine drohende Gefahr für das Thema sein aber das Engagement, mit dem die DevOps-Community gerade die kulturellen Aspekte angeht und vorantreibt, lässt hoffen, dass die Bewegung ihr Ziel nicht verliert. \n
- Was kann noch passieren? DevOps kann ein weiteres Silo bzw. ein separater Job werden...\nMöglicherweise sogar mit der Idee, dass man dabei ja auch ein paar Leute einsparen kann, wenn man Entwickler hat, die auch Admins sind bzw. umgekehrt...\n\nStellen-Anzeigen! \nMeine Interpretation: Es werden Leute gesucht, die den DevOps-Ansatz kennen und unterstützen.\n
- DevOps bietet jetzt die Chance die Vorteile und den Schwung der agilen Methoden in den IT-Betrieb zu bringen und sich dadurch eine Vorreiter-Position bei der Bereitstellung von Anwendungen und IT-Services zu verschaffen. \n\nEin häufig zitiertes, prominentes Beispiel für eine hohe DevOps-Durchdringung ist die Foto-Plattform Flickr. Auf deren Seiten findet man eine stetig aktualisierte Information in folgender Form: "Flickr was last deployed 31 hours ago, including 5 changes by 3 people. In the last week there were 86 deploys of 669 changes by 19 people." Diese hohe Release-Frequenz geht einher mit einer Spitzenposition im Social Media Bereich, was die Verfügbarkeit beziehungsweise Uptime angeht.\nDurchsucht man die einschlägigen sozialen Netzwerke, stellt man fest, dass es auch im deutschsprachigen Raum schon einige große Unternehmen gibt, deren Mitarbeiter sich engagiert mit dem Thema beschäftigen: Deutsche Post, Axel Springer AG, Nokia ImmobilienScout24, 1&1 Internet AG, DuMont, und die Deutsche Flugsicherung sind Beispiele dafür. Dr. Johannes Mainusch, Vice President Operations bei der XING AG, schreibt auf Anfrage des Autors: "Besonders wichtig wird [DevOps] für Organisationen, die den Übergang vom Startup-Zeitalter zu einer stabilen und professionellen Organisation geschafft haben und sich nun der Herausforderung immer stärkerer Spezialisierung der Fachbereiche stellen müssen. Dabei geht häufig der gemeinsame Blick aufs Ganze verloren." Die XING AG setzt auf DevOps und schafft intern ein wachsendes Bewusstsein dafür. Dr. Mainusch: "Ich habe seit langer Zeit endlich wieder Experten euphorisch gesehen."\n\n
- \n