Es geht natürlich um . Wenn Sie nicht ins Detail gehen, dann veranstalten wir am 30. September und 1. Oktober eine Konferenz zur Zusammenführung der Prozesse Entwicklung, Test und Betrieb, und wenn Sie ins Detail gehen, bitte unter Kat.
Beim DevOps-Ansatz sind alle Teile der technologischen Entwicklung des Projekts miteinander verknüpft, laufen parallel ab und beeinflussen sich gegenseitig. Von besonderer Bedeutung ist dabei die Schaffung automatisierter Entwicklungsprozesse, die in Echtzeit verändert, simuliert und getestet werden können. Dies hilft Ihnen, sofort auf Veränderungen im Markt zu reagieren.
Auf der Konferenz wollen wir zeigen, wie dieser Ansatz die Produktentwicklung beeinflusst. Wie die Zuverlässigkeit und Anpassungsfähigkeit des Systems für den Kunden sichergestellt wird. Wie DevOps die Struktur und den Ansatz eines Unternehmens zur Organisation seines Arbeitsprozesses verändert.
hinter den Kulissen
Für uns ist es wichtig, nicht nur zu wissen, was verschiedene Unternehmen im Rahmen des DevOps-Ansatzes tun, sondern auch zu verstehen, warum dies alles getan wird. Deshalb haben wir nicht nur Experten in das Programmkomitee eingeladen, sondern auch Spezialisten, die den DevOps-Diskurs aus unterschiedlichen Positionen betrachten:
- leitende Ingenieure;
- Entwickler;
- Gruppenführer;
- CTO.
Dies führt einerseits zu Schwierigkeiten und Konflikten bei der Erörterung von Berichtsanfragen. Wenn ein Ingenieur daran interessiert ist, einen schweren Unfall zu analysieren, ist es für einen Entwickler wichtiger zu verstehen, wie man Software erstellt, die in Clouds und Infrastrukturen funktioniert. Aber indem wir zustimmen, schaffen wir ein Programm, das für alle wertvoll und interessant ist: vom Ingenieur bis zum CTO.
Das Ziel unserer Konferenz besteht nicht nur darin, die am meisten Hype-Berichte auszuwählen, sondern das Gesamtbild zu präsentieren: wie der DevOps-Ansatz in der Praxis funktioniert und auf welche Kosten Sie bei der Umstellung auf neue Prozesse stoßen können. Gleichzeitig bauen wir den Inhaltsteil auf, indem wir vom Geschäftsproblem bis hin zu spezifischen Technologien gehen.
Die Konferenzabschnitte bleiben die gleichen wie in .
- Infrastrukturplattform.
- Infrastruktur als Code.
- Kontinuierliche Lieferung.
- Feedback.
- Architektur in DevOps, DevOps für CTO.
- SRE-Praktiken.
- Schulung und Wissensmanagement.
- Sicherheit, DevSecOps.
- DevOps-Transformation.
Call for Papers: welche Art von Berichten wir suchen
Wir haben das potenzielle Publikum der Konferenz bedingt in fünf Gruppen eingeteilt: Ingenieure, Entwickler, Sicherheitsspezialisten, Teamleiter und CTO. Jede Gruppe hat ihre eigene Motivation, zur Konferenz zu kommen. Und wenn Sie DevOps aus diesen Blickwinkeln betrachten, können Sie verstehen, wie Sie Ihr Thema fokussieren und wo Sie Schwerpunkte setzen sollten.
Für Ingenieure, Für diejenigen, die eine Infrastrukturplattform erstellen, ist es wichtig, die bestehenden Trends zu verstehen und zu verstehen, welche Technologien derzeit am weitesten fortgeschritten sind. Sie werden daran interessiert sein, mehr über reale Erfahrungen beim Einsatz dieser Technologien zu erfahren und Meinungen auszutauschen. Ein Ingenieur hört sich gerne einen Bericht an, in dem ein schwerer Unfall analysiert wird, und wir wiederum werden versuchen, einen solchen Bericht auszuwählen und zu verbessern.
Für Entwickler Es ist wichtig, ein solches Konzept zu verstehen Cloud-native Anwendung. Das heißt, wie man Software so entwickelt, dass sie in Clouds und verschiedenen Infrastrukturen funktioniert. Der Entwickler muss ständig Feedback von der Software erhalten. Hier möchten wir Fälle darüber hören, wie Unternehmen diesen Prozess aufbauen, wie die Softwareleistung überwacht wird und wie der gesamte Lieferprozess funktioniert.
Spezialisten für Cybersicherheit Es ist wichtig zu verstehen, wie man den Sicherheitsprozess so gestaltet, dass er die Entwicklungs- und Änderungsprozesse im Unternehmen nicht blockiert. Interessant werden auch Themen rund um die Anforderungen sein, die DevOps an solche Spezialisten stellt.
Teamleiter wollen es wissen, wie der Continuous-Delivery-Prozess in anderen Unternehmen funktioniert. Welchen Weg haben Unternehmen eingeschlagen, um dies zu erreichen, wie haben sie Entwicklungs- und Qualitätssicherungsprozesse innerhalb von DevOps aufgebaut? Teamleiter sind auch an Cloud Native interessiert. Und auch Fragen zur Interaktion innerhalb des Teams und zwischen Entwicklungs- und Engineering-Teams.
für CTO Das Wichtigste ist, herauszufinden, wie alle diese Prozesse miteinander verbunden und an die Geschäftsanforderungen angepasst werden können. Er stellt sicher, dass die Anwendung sowohl für das Unternehmen als auch für den Kunden zuverlässig ist. Und hier müssen Sie verstehen, welche Technologien für welche Geschäftsaufgaben geeignet sind, wie der gesamte Prozess aufgebaut ist usw. Der CTO ist auch für die Budgetierung verantwortlich. Er muss beispielsweise verstehen, wie viel Geld für die Umschulung von Spezialisten ausgegeben werden muss, damit diese in DevOps arbeiten können.
Wenn Sie zu diesen Themen etwas zu sagen haben, schweigen Sie nicht, . Die Frist für den Call for Papers endet am 20. August. Je früher Sie sich anmelden, desto mehr Zeit haben Sie für die Fertigstellung Ihres Berichts und die Vorbereitung Ihrer Präsentation. Also zögern Sie nicht.
Nun, wenn Sie kein Bedürfnis haben, öffentlich zu sprechen, dann einfach und kommen Sie am 30. September und 1. Oktober, um mit Kollegen zu kommunizieren. Wir versprechen, dass es interessant und inspirierend wird.
Wie wir DevOps sehen
Um genau zu verstehen, was wir unter DevOps verstehen, empfehle ich, meinen Bericht zu lesen (oder noch einmal zu lesen)." Als ich durch die Wellen des Marktes ging, beobachtete ich, wie sich die Idee von DevOps in Unternehmen unterschiedlicher Größe veränderte: von einem kleinen Startup bis hin zu multinationalen Unternehmen. Der Bericht basiert auf einer Reihe von Fragen. Durch deren Beantwortung können Sie nachvollziehen, ob sich Ihr Unternehmen in Richtung DevOps bewegt oder ob es irgendwo Probleme gibt.
DevOps ist ein komplexes System, es muss Folgendes umfassen:
- Digitales Produkt.
- Geschäftsmodule, die dieses digitale Produkt entwickeln.
- Produktteams, die Code schreiben.
- Kontinuierliche Lieferpraktiken.
- Plattformen als Service.
- Infrastruktur als ein Service.
- Infrastruktur als Code.
- Separate Praktiken zur Aufrechterhaltung der Zuverlässigkeit, integriert in DevOps.
- Eine Feedback-Praxis, die alles beschreibt.
Am Ende des Berichts befindet sich ein Diagramm, das einen Eindruck vom DevOps-System im Unternehmen vermittelt. So können Sie erkennen, welche Prozesse in Ihrem Unternehmen bereits optimiert wurden und welche noch aufgebaut werden müssen.
Sie können sich das Video des Berichts ansehen .
Und jetzt gibt es einen Bonus: mehrere Videos von RIT++ 2019, die die allgemeinsten Themen der DevOps-Transformation ansprechen.
Unternehmensinfrastruktur als Produkt
Artyom Naumenko leitet das DevOps-Team bei Skyeng und kümmert sich um die Entwicklung der Infrastruktur seines Unternehmens. Er erklärte, wie sich die Infrastruktur auf die Geschäftsprozesse bei SkyEng auswirkt: wie man den ROI dafür berechnet, welche Kennzahlen für die Berechnung ausgewählt werden sollten und wie man an deren Verbesserung arbeiten kann.
Auf dem Weg zu Microservices
Das Unternehmen Nixys bietet Unterstützung für ausgelastete Webprojekte und verteilte Systeme. Sein technischer Direktor, Boris Ershov, erklärte, wie man Softwareprodukte, deren Entwicklung vor fünf Jahren (oder noch länger) begann, auf eine moderne Plattform übersetzt.
In der Regel handelt es sich bei solchen Projekten um eine besondere Welt, in der es so dunkle und alte Ecken der Infrastruktur gibt, dass die heutigen Ingenieure nichts davon wissen. Und die einmal gewählten Architektur- und Entwicklungsansätze sind veraltet und können dem Unternehmen nicht das gleiche Tempo bei der Entwicklung und Veröffentlichung neuer Versionen bieten. Dadurch wird jede Produktveröffentlichung zu einem unglaublichen Abenteuer, bei dem ständig etwas abfällt, und das an der unerwartetsten Stelle.
Manager solcher Projekte stehen zwangsläufig vor der Notwendigkeit, alle technologischen Prozesse zu transformieren. In seinem Bericht sagte Boris:
- wie man die richtige Architektur für das Projekt auswählt und die Infrastruktur in Ordnung bringt;
- Welche Werkzeuge sind zu verwenden und auf welche Fallstricke stößt man auf dem Weg zur Transformation?
- Was macht man als nächstes.
Automatisierung von Releases oder wie man schnell und schmerzlos liefert
Alexander Korotkov ist ein führender Entwickler des CI/CD-Systems bei CIAN. Er sprach über Automatisierungstools, die es ermöglichten, die Qualität zu verbessern und die Zeit für die Übergabe des Codes an die Produktion um das Fünffache zu verkürzen. Mit der Automatisierung allein konnten solche Ergebnisse jedoch nicht erreicht werden, daher achtete Alexander auch auf Veränderungen in den Entwicklungsprozessen.
Wie helfen Unfälle beim Lernen?
Alexey Kirpichnikov implementiert seit 5 Jahren DevOps und Infrastruktur bei SKB Kontur. Im Laufe von drei Jahren ereigneten sich in seinem Unternehmen etwa 1000 Fakaps unterschiedlicher Epik. Davon waren beispielsweise 36 % auf die Einführung eines minderwertigen Releases in die Produktion zurückzuführen und 14 % auf Hardware-Wartungsarbeiten im Rechenzentrum.
Ein Archiv von Berichten (Post-Mortems), das die Ingenieure des Unternehmens seit mehreren Jahren in Folge führen, ermöglicht es, solch genaue Informationen über Unfälle zu erhalten. Die Obduktion wird vom diensthabenden Ingenieur verfasst, der als erster auf das Notsignal reagierte und begann, alles zu reparieren. Warum quälen Ingenieure, die sich nachts mit Facaps abmühen, das Schreiben von Berichten? Mithilfe dieser Daten können Sie das Gesamtbild überblicken und die Infrastrukturentwicklung in die richtige Richtung lenken.
In seiner Rede erläuterte Alexey, wie man eine wirklich nützliche Obduktion erstellt und wie man die Praxis solcher Berichte in einem großen Unternehmen umsetzt. Wenn Sie Geschichten darüber mögen, wie jemand Fehler gemacht hat, schauen Sie sich das Video der Aufführung an.
Wir verstehen, dass Ihre Vision von DevOps möglicherweise nicht mit unserer übereinstimmt. Es wird interessant sein zu erfahren, wie Sie die DevOps-Transformation sehen. Teilen Sie Ihre Erfahrungen und Vision zu diesem Thema in den Kommentaren.
Welche Berichte haben wir bereits in das Programm aufgenommen?
Diese Woche hat der Programmausschuss vier Berichte angenommen: über Sicherheit, Infrastruktur und SRE-Praktiken.
Das vielleicht schmerzhafteste Thema der DevOps-Transformation: Wie stellt man sicher, dass die Leute aus der Informationssicherheitsabteilung die bereits aufgebauten Verbindungen zwischen Entwicklung, Betrieb und Verwaltung nicht zerstören? Manche Unternehmen kommen ohne eine Abteilung für Informationssicherheit aus. Wie kann in diesem Fall die Informationssicherheit gewährleistet werden? Darüber Mona Arkhipova von sudo.su. Aus ihrem Bericht erfahren wir:
- was muss geschützt werden und vor wem;
- Was sind die routinemäßigen Sicherheitsprozesse?
- Wie sich IT- und Informationssicherheitsprozesse überschneiden;
- Was ist CIS CSC und wie wird es implementiert?
- wie und anhand welcher Indikatoren regelmäßige Informationssicherheitsprüfungen durchgeführt werden sollen.
Der nächste Bericht befasst sich mit der Entwicklung von Infrastructure as Code. Ist das möglich, den manuellen Routineaufwand zu reduzieren und nicht das gesamte Projekt ins Chaos zu stürzen? Zu dieser Frage Maxim Kostrikin von Ixtens. Sein Unternehmen nutzt Terraform für die Arbeit mit der AWS-Infrastruktur. Das Tool ist praktisch, aber die Frage ist, wie man vermeiden kann, bei der Verwendung einen großen Codeblock zu erstellen. Die Pflege eines solchen Erbes wird von Jahr zu Jahr teurer.
Maxim zeigt, wie Codeplatzierungsmuster funktionieren, um die Automatisierung und Entwicklung zu vereinfachen.
Noch eins Wir werden von der Infrastruktur hören Vladimir Ryabov von Playkey. Hier werden wir über die Infrastrukturplattform sprechen und lernen:
- Wie erkennt man, ob der Speicherplatz effektiv genutzt wird?
- wie mehrere hundert Benutzer 10 TB Inhalte erhalten können, wenn nur 20 TB Speicher genutzt werden;
- wie man Daten fünfmal komprimiert und den Benutzern in Echtzeit bereitstellt;
- wie man Daten im laufenden Betrieb zwischen mehreren Rechenzentren synchronisiert;
- So beseitigen Sie jeglichen Einfluss von Benutzern aufeinander, wenn Sie eine virtuelle Maschine nacheinander verwenden.
Das Geheimnis dieser Magie ist die Technologie ZFS für FreeBSD und seine frische Gabel ZFS unter Linux. Vladimir wird Fälle von Playkey teilen.
Matvey Kukuy von Amixr.IO bereit mit Beispielen aus dem Leben , was SRE und wie es beim Aufbau zuverlässiger Systeme hilft. Amixr.IO leitet Kundenvorfälle über sein Backend weiter; Dutzende diensthabende Teams auf der ganzen Welt haben bereits 150 Fälle bearbeitet. Auf der Konferenz wird Matvey die Statistiken und Erkenntnisse teilen, die sein Unternehmen durch die Lösung von Kundenproblemen und die Analyse von Fehlern gesammelt hat.
Ich fordere Sie noch einmal auf, nicht gierig zu sein und Ihre Erfahrungen als DevOps-Samurai zu teilen. Aufschlag für einen Bericht, und Sie und ich haben 2,5 Monate Zeit, um eine hervorragende Rede vorzubereiten. Wenn Sie Zuhörer sein wollen, Lesen Sie den Newsletter mit Programmaktualisierungen und denken Sie ernsthaft darüber nach, Tickets im Voraus zu buchen, da diese mit zunehmender Nähe der Konferenztermine teurer werden.
Source: habr.com