Rückblick DevOpsDays Moskau: Einblicke aus 6 Berichten

Am 7. Dezember organisierte die Moskauer DevOps-Community mit Unterstützung von Mail.ru Cloud Solutions die dritte DevOpsDays- Konferenz in Moskau. Zusätzlich zu den Berichten führender DevOps-Praktiker konnten die Teilnehmer an kurzen, motivierenden Lightning Talks, Workshops und Chats im Freien teilnehmen.

Wir haben wichtige Erkenntnisse aus sechs Präsentationen gesammelt und Interviews mit mehreren Rednern geführt, um herauszufinden, was in den Berichten noch übrig war.

Innen:

1. Baruch Sadogursky, JFrog: „Lassen Sie die Software wie eine Flüssigkeit vom Anbieter zum Benutzer fließen“
   
2. Pavel Selivanov, Southbridge: "Dev und Ops haben eine gemeinsame Aufgabe - ein Produkt herzustellen, das funktioniert"
   
3. Vladimir Utratenko, X5 Retail Group: „DevOps in Enterprise ist Entwicklung ohne Schmerzen und Brände“
   
4. Sergey Puzyrev, Facebook: „Der Produktionsingenieur kümmert sich um den gesamten Service: Damit sich Benutzer und Entwickler wohlfühlen.“
   
5. Mikhail Chinkov, AMBOSS: „Eine Einheit kann dem DevOps-Pfad nicht folgen, das gesamte Unternehmen sollte ihm folgen.“
   
6. Rosbank DevOps-Enthusiasten: „1000 Tage, um DevOps im blutigen Unternehmen umzusetzen“
   

1. Baruch Sadogursky, JFrog: „Lassen Sie die Software wie eine Flüssigkeit vom Anbieter zum Benutzer fließen.“

Fehler beim Aktualisieren der Software treten stündlich und für jedermann auf. Hier ist nur eine Gruselgeschichte aus der Rede: Knight Capital verlor nach einem erfolglosen Update 440 Millionen USD pro Stunde.

Baruch sprach über DevOps-Muster kontinuierlicher Aktualisierungen, die helfen, Benutzerfehler und Hass zu vermeiden:

Lokales Rollback - Bewahren Sie die vorherige Version der Software auf dem Gerät auf, um bei Problemen ein Rollback durchzuführen. Dies schützt Sie, wenn alles so schlecht ist, dass Sie den Patch nicht durch die Luft senden können.

Luftaktualisierungen sind besser kontinuierlich. Es wird anders sein, wie bei den Jaguar-Entwicklern: Wegen eines Fehlers im Bremssystem, der nicht per Flugzeug aktualisiert werden konnte, war es notwendig, Autos vom Verkauf zurückzurufen. Es war schmerzhaft und teuer.

Kontinuierliche Updates - Aktualisieren Sie die Software kontinuierlich, sobald eine neue Funktion verfügbar ist. Bei seltenen Updates werden Funktionen gruppiert. Ein kritisches Update kann auf unkritische warten. Wie in Tesla wartete ein Update, das zufälliges Bremsen beheben sollte, auf die Aktualisierung des Schachspiels.

Automatisierte Bereitstellung - Ersetzen Sie Mitarbeiter durch Computer, da Mitarbeiter nicht wissen, wie Routineaktionen auszuführen sind.

Häufige Updates - helfen Sie dabei, eine Gewohnheit zu entwickeln und die Angst loszuwerden. Seltene Updates werden zu einem Notfallereignis.

Kenntnis des Gerätezustands - Updates testen, nicht Neuinstallation. Dies ist wichtig, da sich Aktualisierungen je nach Gerätestatus unterschiedlich verhalten können.

Kanarische Veröffentlichungen - Aktualisierungen für eine kleine Anzahl von Benutzern bereitstellen und ansehen. Dies reduziert den Schaden, wenn etwas schief geht.

Aktualisierungen ohne Unzugänglichkeit - Lassen Sie Kunden nur neue Funktionen bemerken und warten Sie nicht mehrere Wochen, bis Sie die Aktualisierung einführen.

Wir haben mit Baruch Sadogursky darüber gesprochen, wie sich die Aussichten auf DevOps in der russischen und westlichen IT unterscheiden, ob Cloud bald alles für uns tun wird und ob alle Softwaredienste in ein AS-Schema einfließen werden - siehe Interview:

2. Pavel Selivanov, Southbridge: "Dev und Ops haben eine gemeinsame Aufgabe - ein Produkt herzustellen, das funktioniert"

Die Implementierung von Kubernetes wird nicht dazu beitragen, DevOps zu erreichen, und sogar umgekehrt - es kann alles kaputt machen. Pavel erklärte, warum Technologien (auch die coolsten) nicht alle Ihre Probleme lösen können:

Die Komplexität des Projekts ist über den Code hinausgegangen . Bisher gab es eine komplexe Anwendung: Interaktion innerhalb des Projekts und komplexe Entwicklung, aber eine einfache Struktur - der Administrator hat eingesetzt, alles funktioniert. Wir sind auf Microservices umgestiegen: Jeder Service ist eine einfache Anwendung, Kommunikation über Standardprotokolle und schnelle Entwicklung, aber die Projektstruktur ist komplizierter geworden. Die Komplexität des Projekts mit der Microservice-Architektur hat sich nicht verringert - es ist über den Code hinausgegangen. Jetzt ist der DevOps-Ingenieur dafür verantwortlich.

Entwickler möchten nach der Implementierung von DevOps keine Änderungen mehr . Folglich sieht der Workflow mit Kubernetes weiterhin so aus, als würden Aufgaben von Dev zu Ops durch eine Wand geworfen, aber nicht mehr metaphorisch - Git wird zu einer solchen Wand. Der Entwickler legt den Code dort ab und arbeitet wie zuvor, und die Administratoren haben Kubernetes, CI / CD und alles andere.

Entwickler müssen die Änderungen jedoch akzeptieren . Die Situation, in der Entwickler nicht wissen, was Administratoren tun, und Administratoren nicht wissen, was mit Entwicklern geschieht, führt zu Problemen.

Wenn die Entwickler nichts geändert haben, wissen sie nicht, dass die Arbeit der Anwendung in ihrer Verantwortung liegt - andere technische Tricks funktionieren nicht.

Mit dem Aufkommen von DevOps und Kubernetes wird sich in der Entwicklung viel ändern. Dev muss in Ops kompetent sein und umgekehrt. Diese Spezialisten haben ihre eigenen spezifischen Fähigkeiten, müssen sich jedoch gegenseitig ihrer Arbeit bewusst sein. Dev und Ops müssen befreundet sein, bevor Kubernetes implementiert werden kann.

Pavel Selivanov sprach darüber, was in 5 Jahren mit Kubernetes passieren wird und wie ein technologischer Stack für ein modernes Startup aufgebaut werden kann - siehe Interview:

3. Vladimir Utratenko, X5 Retail Group: „DevOps in Enterprise ist Entwicklung ohne Schmerzen und Brände“

Unternehmen kommen zur DevOps-Transformation, wenn sie feststellen, dass die Entwicklung zu langsam ist und nicht der Realität entspricht. Sie haben den Wunsch, sich besser zu entwickeln und schneller einzuführen.

Vladimir erzählte, wie das passiert und was der Haken ist:

1. Zunächst stellen Unternehmen einen DevOps-Ingenieur ein. Als Senior System Administrator ist er mit der Bereitstellung des Releases in der Produktion, der Standardisierung der Entwicklungsumgebung, der Konfiguration der Infrastruktur, der Erkennung und Behebung verschiedener Probleme, der Prozessautomatisierung und anderen technischen Aufgaben befasst.
   
2. Dann reicht ein DevOps-Ingenieur nicht mehr aus, und das Unternehmen stellt ein DevOps-Team ein. Dies ist ein Kompetenzzentrum, das die Bemühungen unterschiedlicher Ingenieure organisiert und es Ihnen ermöglicht, sie in eine Richtung zu fokussieren.
   
3. Tatsächlich sind der DevOps-Ingenieur und die DevOps-Teams die Antimuster der DevOps-Transformationen. Da es bei DevOps um Praktiken und Kultur geht, gibt es auch Implementierungen von DevOps in Technologieunternehmen (SRE, Production Engineering).
   

Was zu tun Wenn Sie ein temporäres DevOps-Team einstellen, um die Umsetzung der DevOps-Transformation zu unterstützen, werden die Praktiken fortgesetzt und eine Entwicklungs- und Technologiekultur gepflegt.

Wenn ein Unternehmen ins Spiel kommt und in DevOps investiert, sind verschiedene Szenarien möglich: Alles wird beim Start auseinanderfallen; verbleibt als SRE / Production Engineering oder Embedded Ops; wechselt zu BizOps, wenn Prozesse auf Geschäftsmetriken basieren.

Vladimir Utratenko erzählte uns, wie „blutig“ DevOps im Unternehmen sind und wie Praktiken in großen Einzelhandelsgeschäften umgesetzt werden - siehe Interview:

4. Sergey Puzyrev, Facebook: „Der Produktionsingenieur kümmert sich um den gesamten Service: Damit sich Benutzer und Entwickler wohlfühlen.“

Facebook ist ein riesiges Unternehmen mit vielen Komponenten, Servern, Mitarbeitern und Rechenzentren. Trotz seiner Größe ist es sehr schnell - Entwickler können Services mehrmals am Tag einführen. Facebook wächst ebenfalls rasant und es geht nicht nur um die Erhöhung der Anzahl der Benutzer und Server, sondern auch um die Erhöhung der Anzahl der Entwickler, was die Prozesse verkompliziert.

Sergey erzählte, was der Produktionsingenieur auf Facebook macht:

1. Production Engineer kodiert viel, es sollte Systemkenntnisse haben: Betriebssysteme, Dateisysteme, Datenbanken, Netzwerke und dergleichen. Muss Erfahrung mit verteilten Systemen und Zuverlässigkeitstechnik haben, dh die Zuverlässigkeit des Produkts unterstützen. Er muss jederzeit erreichbar sein.
   
2. Der Production Engineer unterscheidet sich vom Software Engineer durch seine fortgeschrittenen Fähigkeiten im Betrieb, ist jedoch eine Unterart des Software Engineer. Software Engineer Code mehr, können sie zusätzliche Fähigkeiten haben, zum Beispiel im Zusammenhang mit der Datenverarbeitung. Auf Facebook sollten solche Spezialisten auch auf Abruf sein, was für viele eine unangenehme Überraschung ist.
   
3. Die Bedarfspyramide des Produktionsingenieurs im Unternehmen beginnt mit der Überwachung der Server und ihres Lebenszyklus, dh dem Empfang neuer Hardware, deren Einrichtung und Inbetriebnahme. Die nächste Stufe ist die gleiche auf der Serviceebene: Überwachung der Services und ihres Lebenszyklus. Dann kommt nahtlose Skalierung und erweiterte Überwachung. Sie schalten auf automatische Skalierung um, nachdem der Lebenszyklus automatisiert wurde. Und am Ende müssen Sie eine Optimierung vornehmen, damit die Skalierung effektiv ist und das Unternehmen Geld und Ressourcen spart.
   

5. Mikhail Chinkov, AMBOSS: „Eine Einheit kann dem DevOps-Pfad nicht folgen, das gesamte Unternehmen sollte ihm folgen.“

Michael glaubt, dass DevOps eine kontinuierliche Entwicklung ist. Sie können keine Werkzeuge einführen und dort anhalten. Welche Probleme hindern Unternehmen daran, DevOps zu werden, und wie lassen sich Praktiken umsetzen?

Unterschied im Verständnis von DevOps . Die kanonischen Devops ruhen, wie es die Evangelisten sehen, auf 5 Säulen:

• Kultur - Fokus auf Menschen und Zusammenarbeit;
  
• Automatisierung - Übertragung der Routine auf den Workflow;
  
• Lean - Betonung der Wertschöpfung für den Nutzer;
  
• Austausch - kontinuierlicher Wissensaustausch;
  
• Metriken und Feedback mit ihrer Hilfe bekommen.
  

Unternehmen konzentrieren sich in der Regel nur auf die Automatisierung und die Bereitstellung von Wert für den Benutzer. Die Kennzahlen für Kultur, Wissensaustausch und DevOps, anhand derer Sie die Entwicklung verfolgen können, bleiben jedoch auf der Strecke.

Probleme DevOps-Standardisierung . Die Produktziele sind für alle Unternehmen unterschiedlich und können nicht standardisiert werden. Der Status von DevOps im Unternehmen hängt vom Unternehmen selbst ab, aber viele verstehen dies nicht und glauben, dass es ausreicht, einen DevOps-Ingenieur einzustellen.

Warum sind wir noch keine DevOps? Es gibt zwei Hauptprobleme. In Enterprise - die langsame Entwicklung der Organisation, die Schwierigkeit, den Vektor in den Köpfen von Tausenden von Mitarbeitern zu ändern. In Startups mangelt es an Wissensquellen, ein Problem bei der Allokation von Ressourcen für die Transformation.

Entwicklungsstufen von DevOps im Unternehmen :

• Die erste ist die Infrastruktur in der Cloud, aber außer einem oder zwei Administratoren weiß niemand, wie sie funktioniert.
  
• das zweite - die Infrastruktur ist für alle Ingenieure transparent und verständlich, aber die Prozesse werden nicht in Betrieb genommen;
  
• der dritte - Ingenieure starten und reparieren selbständig Live-Dienste;
  
• Der vierte - Ingenieure, wenn sie es wünschen, tragen zur Kerninfrastruktur bei: transparenter Code in der Cloud, Tastenbereitstellung.
  

Das ideale Schema - jeder hat den gleichen Zugang zur Infrastruktur, alle Ingenieure erhalten Zugang zum Produkt und verstehen, was sie tun.

Die DevOps-Transformation des Unternehmens schließt alle kulturellen und technischen Aspekte ab und berücksichtigt das Feedback von Geschäftsmetriken und Plattformmetriken.

6. DevOps-Enthusiasten von Rosbank: "1000 Tage, um DevOps im blutigen Unternehmen umzusetzen"

Yuri Bulich, Dina Maltseva und Eugene Pankov von Rosbank erzählten, wie sie in drei Jahren zu DevOps gekommen sind. Es gab zwei Ziele: bestimmte Probleme in bestimmten Teams zu lösen und zentralisierte Tools zu implementieren.

Hier sind die erzielten Ergebnisse:

Ergebnisse für Produktteams : 30-mal schnellere Montage, 6-mal schnellere Installation, bis zu 30% Einsparung bei vollem Zyklus. Wir hatten die Möglichkeit, den Knopf ins Produktive zu rollen

Ergebnisse für Plattformteams : Montage und Installation sind zehnmal schneller, die Anzahl der Installationen ist um 87% gestiegen, die Abdeckung mit Autotests beträgt 46%. Integrationsteam hat aufgehört, ein Engpass zu sein

Wie kann man DevOps-Praktiken in einem blutigen Unternehmen implementieren?

Stellen Sie zunächst ein Pilotprojekt vor : Wählen Sie Teams aus, entscheiden Sie, wie die Architektur implementiert werden soll, und wählen Sie Tools aus. Wir entschieden uns für Tools mit einer offenen Lizenz, mit der Installation in der Bank und dem Know-how in der Arbeit mit ihnen. Bei Rosbank wurde zusammen mit der DevOps-Plattform eine private Cloud bereitgestellt, was zu Beginn hilfreich war. In der Cloud war es in 15 Minuten per Knopfdruck möglich, die benötigten Ressourcen zu beschaffen, was früher eine Woche dauern konnte.

In Banken und anderen Unternehmen müssen Sie die Einschränkungen im Voraus mit dem Informationssicherheitsteam erarbeiten und eine Lösung finden, mit der Sie die Änderungen implementieren können.

Nach dem Pilot muss eine erfolgreiche Lösung skaliert werden .

1. Es ist wichtig, das Förderband so weit wie möglich zu „begradigen“, um unnötige Verbindungen zu vermeiden, Wertanbieter hervorzuheben und die verbleibenden Komponenten zu entfernen. Zwischenprodukte sind Antimuster. In Rosbank zum Beispiel hatten einige Teams keine interne Entwicklung, nur externe blieben übrig. Dies führte zur Gründung eines dedizierten DevOps-Teams, das den Code-Transfer von externen Entwicklern zu internen Entwicklern ermöglichte. Das Problem wurde durch die Integration der externen Entwicklung in CI / CD gelöst, sodass diese den Code nicht nur von sich aus an die Bank übertragen, sondern auch für den Erfolg verantwortlich sind.
   
2. Elemente der DevOps-Praxis wurden in das Reifegradmodell aufgenommen, Tools aufgelistet und Merkmale der Zusammenarbeit mit externen Lieferanten berücksichtigt - dies trug in Zukunft dazu bei, den Auftragsstau bei der Implementierung in neuen Teams schnell abzubauen.
   
3. Governance ist in Form von Soft Control und Empfehlungen erforderlich. Das DevOps-Handbuch funktioniert gut - es besteht aus einer Reihe von organisatorischen und instrumentellen Merkmalen, die den Teams helfen, die Plattform korrekt zu nutzen.
   
4. Es lohnt sich, sofort auf die Kultur zu achten, dann werden viele Änderungen schneller und einfacher. Bauen Sie die interne Community auf, veranstalten Sie Meetings, technische Workshops, Schulungen und unterhaltsame Aktivitäten. Es bringt Früchte: Menschen teilen ihre Praktiken, sehen, wer was getan hat, wissen, wohin sie sich wenden müssen, es herrscht Hype und ein gesunder Wettbewerb im Unternehmen.
   
5. Es macht keinen Sinn, mit denjenigen zusammenzuarbeiten, die nicht in den Prozess involviert sind, mit Teams, die nicht reif sind. Es ist besser, in interessierte Teams und treue Leute zu investieren.
   
6. Die ausgewählte Lösung sollte für die Ingenieure, die sie verwenden, geeignet sein.
   
7. Externe Entwicklung ist kein Blocker, man kann dort auch Praktiken umsetzen, Hauptsache das Team selbst hat einen Wunsch.
   

Ein bisschen mehr gut

Die Liste der Bücher, die für diejenigen, die in DevOps sind, von Alexander Chistyakov, vdsina.ru gelesen werden sollten:

1. Irina Yakutenko "Wille und Selbstbeherrschung".
   
2. Daniel Kahneman "Denken, schnell und langsam."
   
3. Barbara Oakley "Ein Geist für Zahlen".
   
4. Maxim Dorofeev "Jedi-Techniken".
   
5. Viktor Frankl "Die Suche nach dem Sinn des Menschen".
   

Bleib dran

Wir lieben auch DevOps. Befolgen Sie die Ankündigungen der Serien @DevOps und @Kubernetes sowie anderer Mail.ru Cloud Solutions-Ereignisse in unserem Telegrammkanal: t.me/k8s_mail