Wir bei PagerDuty legen großen Wert darauf, uns in der DevOps-Community zu engagieren, indem wir Einblicke in unsere Vergangenheit, unsere aktuelle Situation und unsere Zukunft als Community geben – und natürlich auch die Meinungen der Community einholen! Und wenn Sie diesen Blog verfolgen, haben Sie wahrscheinlich schon Folgendes gesehen: vorheriger Beitrag Zusammenfassung Prognosen und Trends im DevOps-Bereich   Webinar , in der vier führende DevOps-Experten zusammenkamen, um uns ihre Perspektive auf die Entwicklungen im Jahr 2017 und darüber hinaus zu präsentieren. Falls Sie es noch nicht gesehen haben, können Sie es sich immer noch ansehen. Jetzt auf Abruf ansehen !

In der ersten Hälfte der Diskussion haben wir Folgendes besprochen: Standardisierung von DevOps und deren Einführung im Unternehmen. Im zweiten Teil unseres Gesprächs haben wir uns mit zwei weiteren Schlüsselfragen befasst, nämlich:

• Wird Sicherheit Bestandteil des DevOps-Betriebsmodells?
• Werden die zentralen Betriebsteams näher an die Anwendungscodebasis heranrücken?

Ich lade Sie ein zu Sehen Sie sich den Original-Webcast an und/oder Lesen Sie den vorherigen Blogbeitrag Falls Sie das noch nicht getan haben. Falls Sie bereits auf dem neuesten Stand sind, begleiten Sie mich bei unserer Diskussion über folgende Punkte:

• Ilan Rabinovich, Direktor der technischen Community bei Datadog
• Chris Gervais, Vizepräsident für Ingenieurwesen bei Bedrohungsliste
• John Rakowski, Direktor für Produktmarketing von AppDynamics
• Arup Chakrabarti, Leiter der Entwicklungsabteilung PagerDuty

Los geht's!

Wird Sicherheit Bestandteil des DevOps-Betriebsmodells?

Sicherheit sollte Bestandteil jedes Produkts sein

Ilan Rabinovich von Datadog findet es seltsam, dass der Sicherheitsgedanke etwas „Neues“ sei, das erst hinzugefügt werden müsse. DevOps-Kultur Er betont, dass Sicherheit zu guter Software-Hygiene gehört und in jedes Produkt integriert sein sollte. Genauso wie Entwickler gelernt haben, früh und oft zu testen, Kontinuierliche Integration Und Kontinuierliche Bereitstellung Neben der Automatisierung weiterer QA-Arbeiten müssen DevOps-Teams auch im Bereich Sicherheit vorgehen und lernen, Sicherheit in jeden Commit zu integrieren. Er betont, dass erfolgreiche Teams Sicherheit bereits seit Jahren praktizieren. Die DevOps-Welt muss Best Practices ebenso befolgen wie führende Entwicklungsorganisationen und das Thema Sicherheit frühzeitig ansprechen.

Integrieren Sie Sicherheit in Ihre Prozesse

Chris Gervais von Threat Stack ist überzeugt, dass Sicherheit 2017 unbedingt Bestandteil des Betriebsmodells sein muss. Er merkt zwar an, dass es bei der Implementierung von Sicherheit Abhängigkeiten geben kann, doch sie ist machbar. DevOps-Teams müssen die Chance nutzen und Sicherheit in den Gesamtprozess integrieren, selbst wenn dies in ihren Organisationen noch nicht zum aktuellen DevOps-Modell gehört. Gervais schlägt vor, Sicherheit in den Software- und Produktentwicklungszyklus einzubetten, sodass jedes Teammitglied sich mit dem Thema Sicherheit auseinandersetzt. Anstatt Sicherheit als „das Team, das Nein sagt“ zu betrachten, sollte sie in Best Practices und Automatisierung integriert werden. Existiert bereits ein separates Sicherheitsteam, ist es ratsam, dieses in DevOps einzubinden. Binden Sie es frühzeitig ein, damit es nicht erst am Ende der Transaktionen zum Einsatz kommt. Wenn ihr Einfluss von Anfang an berücksichtigt wird, ist es viel wahrscheinlicher, dass die üblichen Verhandlungen und Kompromisse zwischen Entwicklung, Betrieb und Sicherheit vollständig abgedeckt sind und die resultierenden Arbeitsergebnisse auf den Unternehmenszielen in Bezug auf Agilität, Geschwindigkeit und Sicherheit basieren.

Zu diesem Zweck schlägt Gervais im Hinblick auf die Zusammenarbeit im Bereich Sicherheit vor, frühzeitig Gespräche zu führen, basierend auf der Annahme, dass die Organisation gemeinsam den DevOps-Weg beschreitet. DevOps muss daher die Voraussetzungen schaffen und Wege für die Zusammenarbeit entwickeln. Er warnt davor, dass die Nichteinbindung des Sicherheitsteams von Anfang an später zu Problemen führen und Entwicklungsprojekte unnötig verlangsamen kann. Sicherheit sollte integraler Bestandteil von DevOps werden und nicht länger nur wenigen vorbehalten sein, sondern die Aufgabe vieler sein.

Ist Sicherheit nicht bereits Bestandteil guter IT?

Auf die Frage nach Sicherheit als Bestandteil von DevOps antwortete John Rakowski von AppDynamics ziemlich frech: „Gehört Sicherheit nicht bereits zu einer guten IT und zu einer guten IT für Unternehmen?“

Er führte weiter aus, dass Sicherheit in diesem Fall sicherlich auch Teil von DevOps sei – wohl wissend, dass es in der IT mitunter zu Kommunikationsproblemen zwischen verschiedenen Abteilungen kommen kann. Rakowski betont, dass es bei „DevOps“ eigentlich um die Zusammenführung von Entwicklung und Betrieb gehe, der übergeordnete Trend aber vielmehr darin bestehe, dass Technologie für Unternehmen und den gesamten Geschäftserfolg mittlerweile so wichtig sei, dass sie jeden Beteiligten in der IT berühre. Diese Bedeutung zeige sich in neuen Begriffen wie „BizDevOps“, die über Entwicklung und Betrieb hinausgingen. Ähnliche neue Phrasen, die in den Markt eindringten, wolle er nicht hören – beispielsweise DevSecOps –, da sie den Markt nur noch mehr verwirrten. Rakowskis überzeugende Position ist, dass Sicherheit IST Die proaktive Integration weiterer wichtiger Aspekte wie Geschäfts- und Sicherheitsanforderungen ist Teil der DevOps-Kultur – oder sollte es zumindest sein. Er versteht darunter den gesamten Softwareentwicklungszyklus und die Bereitstellung dessen, was das Unternehmen benötigt.

Automatisierung im Sicherheitsbereich

Arup Chakrabarti von PagerDuty sieht eine zukünftige Verschmelzung von Sicherheit und DevOps durch neue Tools entstehen. Er verweist auf Continuous-Integration-Tools, die während der Codeentwicklung ein Sicherheitszertifikat für Software bereitstellen können, sowie auf die Möglichkeit, statische Analysetools (wie Code-Inspektionslösungen) zu nutzen, um Best Practices für Softwaretests zu fördern und somit die Konvergenz mit Sicherheitstests voranzutreiben. Er erwartet Effizienzsteigerungen durch einen höheren Automatisierungsgrad im Sicherheitsbereich, da immer mehr Tools zur Automatisierung und Erfassung von Sicherheitsdaten auf den Markt kommen. Arup begrüßt es, dass Sicherheitsprobleme früher im Softwarelebenszyklus angegangen werden. Er warnt jedoch davor, dass nachträgliches Testen zu spät sein kann: „Tests können immer früher in den Lebenszyklus integriert werden, was zu besseren Ergebnissen führt.“

Werden die zentralen Betriebsteams näher an die Anwendungscodebasis heranrücken?

Wir müssen die Bedürfnisse des anderen verstehen.

„Ja, wir müssen uns gegenseitig besser verstehen und anerkennen, was der jeweils andere tut“, kommentierte er. Rabinovich von Datadog prognostiziert für 2017 eine engere Verzahnung von Entwicklung und Infrastruktur sowie von Infrastruktur- und Anwendungsteams, um Probleme schneller zu lösen. Er betonte erneut die Bedeutung der Zusammenarbeit: „Wenn wir die Bedürfnisse des jeweils anderen nicht verstehen, können wir auch die Erwartungen nicht erfüllen.“ Er geht davon aus, dass Gespräche mit Nutzern und Produktmanagern notwendige Funktionen aufdecken, die den Kundenbedürfnissen entsprechen, und dass die engere Zusammenarbeit des Betriebs mit dem Code dazu beiträgt, Fehlentwicklungen zu vermeiden.

Rabinovich meint, dass Unternehmen, in denen der Betrieb (Ops) als zentrales Infrastrukturteam fungiert und nicht unbedingt direkt mit der Anwendung arbeitet, APIs, Tools und eine Plattform entwickeln müssen, auf der Anwendungen bereitgestellt werden – und deren reibungslosen Betrieb sicherstellen müssen. Er betont die Notwendigkeit robuster Softwarebereitstellungsdienste, die eine einfache und skalierbare Codebereitstellung ermöglichen. Laut Rabinovich reicht es nicht aus, einfach eine Komplettlösung einzusetzen; vielmehr geht es darum, die Bedürfnisse des Produktentwicklungsteams zu verstehen und gleichzeitig die Anforderungen der Entwickler genau zu kennen. Rabinovich merkt außerdem an, dass in Unternehmen, in denen Produktentwickler Code an Infrastruktur- oder Betriebsingenieure übergeben müssen, das Betriebsteam wissen muss, wie es Probleme behebt oder minimiert und die Produktionsumgebung während der Wartezeit auf das nächste Upgrade oder den nächsten Patch betreibt – denn schließlich sind sie es, die mitten in der Nacht gerufen werden!

Das werden sie, und das müssen sie auch.

Chris Gervais von Threat Stack sieht dieses Problem recht deutlich und erklärt: „Sie werden es tun, und sie müssen es tun – und die Art der Informationen, die zwischen Entwicklung und Betrieb geteilt werden können, wird deklarativer werden.“ Er nannte Teams, die … eingeführte Mikrodienste Und dann gibt es noch die ausgelagerten Konfigurationsparameter, die als Beispiele dafür dienen, wie sie Betriebsteams deutlich mehr Möglichkeiten bieten. Er meint, dass Betriebsteams „nicht unbedingt die einzelnen Codezeilen kennen müssen“, aber wenn sie Konfigurationsmanagement-Tools verwenden, um Komponenten bereitzustellen und in Betrieb zu nehmen, erhalten sie einen besseren Einblick in die Funktionsweise der Systeme. Dies hilft ihnen, Probleme schneller zu erkennen.

Gervais erklärte, dass der Betrieb durch ein besseres Verständnis der Funktionsweise verschiedener Anwendungen den Anpassungsbedarf leichter erkennen kann. Er sieht die enge Zusammenarbeit zwischen Entwicklung und Betrieb auch darin, Änderungen mithilfe eines Leitfadens zu ermöglichen und schnelle Anpassungen vorzunehmen. Zudem sieht er eine Zukunft, in der der Betrieb mit der Entwicklung zusammenarbeiten kann, um Integritäts- und Leistungsprüfungen durchzuführen, die mit Tools wie Runbooks verknüpft sind. So können Fehlerbehebungen effizienter und autonomer durchgeführt werden.

Er erklärt weiter, dass in einer Umgebung mit entsprechenden Vereinbarungen zwischen Entwicklung und Betrieb zur gemeinsamen Nutzung von Informationen Teams externe Konfigurationen und Service Discovery nutzen können, sodass Betriebsteams die Softwareeigenschaften anpassen und die Performance bedarfsgerecht optimieren können. Er sieht dies als Teil der Bemühungen, Teams zusammenzubringen, die Kommunikation zu verbessern und den Zugang zu ehemals isolierten Informationen zu demokratisieren. Denn, wie Gervais sagt: „Mitten in der Nacht hilft ein Leitfaden dem Team, von Anfang an die richtigen Maßnahmen zu ergreifen.“ Die Befähigung des Betriebs, Codeänderungen vorzunehmen, führt zu einer schnelleren Problemlösung.

Die einfache Antwort lautet: Ja.

John Rakowski von AppDynamics ist der Ansicht, dass der Umzug Die Frage, ob die Betriebsabteilungen näher am Anwendungscode arbeiten sollten, sei derzeit ein viel diskutiertes Thema, und die Antwort darauf sei schlichtweg ja. Laut Rakowski müssen Betriebsteams enger mit dem Code vertraut sein und ihn besser kennen, um Anwendungen und Services optimal bereitstellen zu können. Er sieht außerdem, dass Entwicklerteams in ähnlicher Weise enger mit den Betriebsabteilungen zusammenarbeiten müssen – denn es gehe nicht nur ums Programmieren, sondern auch darum, wie die mit diesem Code verbundenen Produkte den Geschäftserfolg in Bezug auf Umsatz, Kundenerlebnis und Kundenbindung beeinflussen.

Er fügt hinzu, dass eines der zentralen Themen von DevOps darin besteht, die Silos zwischen Entwicklung und Betrieb aufzubrechen. Daher ist das Zusammenwachsen dieser beiden Disziplinen unerlässlich. Selbst in einer Zeit, in der der Begriff „NoOps“ gelegentlich auftaucht, wird der Betrieb immer notwendig sein. Er geht davon aus, dass der Fokus des Betriebs auf der Sicherstellung von Qualität, wie beispielsweise der Performance in der Produktion, liegen wird. In den nächsten drei bis fünf Jahren werden sich Entwicklungs- und Betriebsteams transformieren und die erforderlichen IT- und Betriebskompetenzen vereinen, um Geschwindigkeit zu erreichen, mit einem Fokus auf Automatisierung und Zuverlässigkeit.

Konzentriere dich darauf, Zeit zurückzugewinnen

Arup Chakrabarti von PagerDuty ging auch auf das etwas umstrittene Konzept von „NoOps“ ein und merkte an, dass es bei der Einführung des Begriffs „einen ziemlichen Wirbel“ gegeben habe. Er sieht jedoch Einigkeit darüber, dass Teile der operativen Arbeit automatisiert werden sollen. NoOps birgt das Potenzial, Zeit für wichtigere und kritischere Aufgaben freizusetzen (z. B. die Wertschöpfung bei schwerwiegenden geschäftskritischen Problemen). Arup erklärte, dass gute Ops-Ingenieure und Systemadministratoren sich auf die Automatisierung manueller Aufgaben konzentrieren und die besten einen Ansatz verfolgen, der ihnen Zeit spart.

In dieser umfassenden Diskussion haben wir viele Aspekte von DevOps beleuchtet. Unsere vier Experten lieferten uns wertvolle Einblicke, und einige weitere werden wir demnächst mit Ihnen teilen. Wir bei PagerDuty sind gespannt, wie sich DevOps im restlichen Jahr entwickeln wird, und melden uns mit weiteren Einschätzungen zurück, sobald wir sehen, wie sich die Prognosen in diesem Jahr, 2018 und darüber hinaus bewahrheitet haben. In der Zwischenzeit freuen wir uns über Ihre Kommentare und laden Sie ein, unsere Videos anzusehen. Prognosen und Trends im DevOps-Bereich Webinar!