„Technologien zu entwickeln, ohne darüber nachzudenken, wer sie einsetzt, ist völlig sinnlos“: ein großes Interview mit Anton Weiss

Dieser Habrapost ist ein Interview mit Anton Weiss, Mitinhaber der Technologieberatung Otomato Software, dem Inhaber von mehr als 15 Jahren Erfahrung auf dem Gebiet der Hochtechnologie. Er ist Experte für technische Lehre, Initiator und Mitautor des ersten israelischen DevOps-Zertifizierungskurses. Anton nimmt an internationalen Konferenzen teil und gilt als cooler Redner.

Wir werden über folgende Themen sprechen:

• Der Unterschied in der Arbeit zwischen Russland und Israel;
• Der Unterschied zwischen Startups und Giganten, insbesondere in Bezug auf DevOps;
• Der Trend geht dahin, die Komplexität zu erhöhen und was dagegen zu tun ist.
• Kombination von technischen und nichttechnischen Fähigkeiten;
• Schnelle Schulung und Implementierung;
• Die nützlichsten Praktiken und Technologien aus der Welt von DevOps;
• Welche Berichte sind einen Besuch wert?

Der Unterschied zwischen Russland und Israel

Oleg: Bitte sag mir, wer du bist und was du tust.

Anton: Ich bin Anton, ich wurde in St. Petersburg geboren, bin aber im Alter von 15 Jahren nach Israel gezogen und lebe seitdem dort. In den letzten zwanzig Jahren habe ich mich in Israel mit IT in verschiedenen Formen beschäftigt. Von diesen zwanzig Jahren haben sich die letzten zehn auf alles rund um die Softwarebereitstellung spezialisiert: Integration, was früher als Konfigurationsmanagement bezeichnet wurde, und was heute als DevOps bezeichnet wird. Ich habe in großen Unternehmen gearbeitet - in internationalen Unternehmen wie AT & T, BMC. Er arbeitete in Startups. In den letzten vier Jahren hatte ich mein eigenes Beratungsunternehmen namens Otomato Software, in dem wir Unternehmen bei der Optimierung von Lieferprozessen und der Beherrschung neuer Tools unterstützen. Das heißt, wir übernehmen den technischen Teil und alles, was dazugehört.

Oleg: Gibt es einen Unterschied zwischen Russland und Israel in Bezug auf die Arbeit?

Anton: Ich habe kaum mit russischen Kunden gearbeitet. Die Tatsache, dass mich die letzten 3 Jahre mit Russland verbunden haben, sind Konferenzen. Und in mehreren russischen Unternehmen haben wir so etwas wie ein Audit durchgeführt: Wir sind angekommen, haben nachgesehen, haben es sortiert, haben einige Empfehlungen herausgegeben und sind gegangen. Das heißt, es gab keine solche tägliche Arbeit, daher fällt es mir schwer, genau zu sagen, wie sie sich unterscheidet. Ich denke, dass es viele verschiedene Dinge gibt. Das heißt, im gleichen Israel haben wir so schwere Unternehmensorganisationen, in denen die Menschen seit 15 Jahren arbeiten, und alles bewegt sich sehr hart. Und egal, wie sie versuchen, eine Art Transformation durchzuführen, Prozesse zu verbessern: Sie werden reden, sie werden reden, aber ... Wir haben einen Kunden, mit dem wir vor zwei Jahren alles getan und alle Entscheidungen getroffen haben, alle Programme entwickelt haben und in denen In dem Moment, in dem alles ins Stocken geriet, kamen wir da raus. Vor ein paar Tagen habe ich von dort aus die Chefs getroffen, mit denen wir zusammengearbeitet haben. Ich sage:

- Und wie?

- So. Es ist schwer, sagen sie, wir machen es, jetzt beginnt etwas zu passieren.

Zwei Jahre später. Es gibt Politik, es gibt Einflusszonen. Es gibt Menschen, die diese Einflusszonen nicht freigeben wollen bzw. in einer solchen Situation ist es sehr schwierig, etwas zu verändern. Nun, das Toolkit selbst entwickelt sich irgendwie weiter. Auf der anderen Seite gibt es in Israel Start-ups, bei denen sich alles sehr schnell ändert, es einfach ist, einen neuen Zeitplan aufzustellen, und alle sind Cloud-native und sitzen vollständig in der Cloud. Dies kann übrigens einer der greifbaren Unterschiede zwischen Russland und Israel sein. In Israel ist eine öffentliche Cloud viel einfacher. Nach dem, was ich gesehen habe. In Russland scheint es zum Beispiel für alle, mit Ausnahme von Startups, sehr schwierig zu sein, in die öffentliche Cloud zu gelangen, in Israel ist es jedoch immer noch einfacher. Selbst Banken und Versicherungen haben heute schon ein gewisses Verständnis dafür, dass zumindest ein Teil ihrer Dinge in die Public Cloud ausgerollt werden kann. Und hier machen Verträge mit Google und Amazon niemandem Angst. Nach dem, was ich auf Konferenzen in Russland gehört habe, ist es dort immer noch komplizierter, auch unter dem Gesichtspunkt der Sanktionen, nicht der Sanktionen und einiger rechtlicher Fragen.

Der Unterschied zwischen Startups und Giganten

Oleg: Ich verstehe. Wo ist es für Sie übrigens interessanter und angenehmer zu arbeiten: in Startups oder in großen Organisationen?

Anton: Bei Startups ist es natürlich angenehmer, weil große Organisationen ... nun ja, nur das Material bewegt sich sehr schwer. Natürlich gibt es auch Vorteile. Wenn Sie sich große Organisationen ansehen, dann haben sie zum Beispiel viel mehr als das, was man Vielfalt nennt. Große Unternehmen, einfach weil sie eine Menge Leute brauchen oder weil es eine Art Organisationskultur ist, die sich im Laufe der Jahre entwickelt hat, sind bereit, verschiedene Leute einzustellen. Insbesondere in Israel, zum Beispiel, werden Sie in Startups fast keine Araber finden, sie sind fast abwesend. In großen Organisationen ist dies viel einfacher. Aber Startups wachsen bereits aus einem kulturellen Hintergrund heraus, in dem die meisten Teilnehmer zumeist dieselben Weißen sind. Es gibt eine Kultur von dem, was richtig zerrissen werden muss, und es ist ratsam, 10-12 Stunden am Tag zu arbeiten, und dies ist auch nicht genug. Es scheint, als ob Moskau (dh Tel Aviv) hinter uns ist, es gibt keinen Rückzug, und deshalb sollte es hier und jetzt bluten.

Oleg: Und was ist mit der unterschiedlichen Herangehensweise an DevOps in kleinen und großen Unternehmen? Wenn Sie beispielsweise für zwei Personen arbeiten, können Sie kein eigenes CI / CD konfigurieren, sondern Artefakte aus SCP kopieren.

Anton: Zum einen. Andererseits bedeutet das Einrichten von CI / CD heute nicht, dass Sie wirklich eine kontinuierliche Lieferung durchführen. Das Einrichten einer Pipeline ist jedoch sehr, sehr einfach, wenn Sie ein Unternehmen mit zwei Mitarbeitern sind. Wenn Sie früher irgendwie verwirrt sein mussten, dann haben Sie heute viele Cloud-Dienste. YAML geschrieben - und los geht's. Das ist einfacher. In der Tat ist die Herausforderung Start-ups. Diejenigen, die mehr als 20 Menschen waren, und hier fangen sie an, mit Schuppen zu schmerzen, weil es keine Prozesse gibt. Früher hat alles irgendwie geklappt, aber dann fängt das ganze Durcheinander an, und es ist unklar, wie wir diese frühere Dynamik aufrechterhalten und gleichzeitig Prozesse durchführen und entscheiden können, wer sonst all dies tun wird.

Und dann fangen alle Dinge an, wie zum Beispiel "Wir werden ein DevOps-Team haben, das für DevOps verantwortlich ist", wir wissen, was dies in den meisten Fällen zur Folge hat. Es entsteht ein Engpass, und nach und nach wachsen sie dort an, wo sich die großen Unternehmen gerade befinden. Große Unternehmen haben ein ganz anderes Unglück, sie haben nicht einmal einen Engpass, sondern nur ein mächtiges Tor, das sich einmal am Tag öffnet, und den Rest der Zeit fällt dort eine riesige Menge Müll an. Und so denken sie: „Wie machen wir aus diesem Gateway nun viele kleine Gateways, die sich viel einfacher öffnen lassen?“ Das sind ganz andere Probleme. Startups haben ein Problem mit der Tatsache, dass „wir in den Trichter gesaugt werden, wie können wir rausschwimmen?“, Und für große Unternehmen - sie sind bereits im Trichter, sie sind bereits in der Unterwelt, jetzt überlegen sie, wie sie wieder nach oben schwimmen sollen.

Der Trend ist eine zunehmende Komplexität und was ist dagegen zu tun?

Oleg: Nun, plus den technischen Teil: Wenn Sie nur wenige Leute haben, einfache Technologien, müssen Sie einige grundlegende Linux-Kenntnisse haben, und das war's. Und mit der geringsten Skalierung müssen Sie einige Kubernetes lernen, und dies scheint das Problem zu sein.

Anton: Und das ist zweifellos ein Problem. Wir hatten erst vor zwei Tagen eine Konferenz und es war sehr auffällig, dass fast jeder, der dort etwas sagte, ein Wort erwähnte: „Komplexität“ (Komplexität). Dies ist heute eine Art definierendes Wort für den gesamten DevOps-Diskurs.

Oleg: War das vor einem Jahr?

Anton: In dem Versuch, alles schnell und dynamisch zu erledigen, um die notorische Flexibilität zu erreichen, haben wir uns mit dieser Komplexität abgefunden. In der Tat gibt es viele kleine Pipelines, die wunderbar getrennt funktionieren, und dann versuchen wir, ein Bild der Welt von all dem zu sammeln, und hier entsteht plötzlich Komplexität. Weil wir jetzt einen Prozess aus all diesen kleinen Pipelines bauen, damit das gesamte Unternehmen als Mensch arbeitet.

Oleg: Und was ist die Antwort? Wie geht man mit dieser Komplexität um?

Anton: Nun, es gibt keine Antworten, sie werden dabei geboren. In meinem Bericht ging es um eine dieser Lösungen. Wird das alles im Großen und Ganzen gehen? Ich war einmal mit systemischem Denken infiziert, in DevOps wird viel darüber erwähnt. Ich interessierte mich, las die Bücher von Peter Senge, Russell Ackoff und Donella Meadows - Menschen, die zu einem bestimmten Zeitpunkt auf irgendeine Weise systemische Überlegungen anstellten und im Großen und Ganzen ihre wichtigsten Postulate formulierten. Eines der Hauptprismen, durch die das systemische Denken die Welt betrachtet, sind Rückkopplungsschleifen. Mit dieser Komplexität entstehen nun diese Rückkopplungsschleifen, das heißt, die Komplexität wird sehr, sehr hoch, wir beginnen nach Werkzeugen zu suchen, um diese Komplexität irgendwie zu berücksichtigen. Ich sage nicht reduzieren - zügeln, um nicht auszurollen.

Zentralisierte Lösungen erscheinen, im Großen und Ganzen ist sogar Kubernetes so etwas. Sie haben eine zentrale Steuerungsebene, die zum Zeitpunkt der Steuerung die Komplexität der Dienste steuert, die ausgeführt werden. Das Service-Sieb, das gleiche Service-Sieb, ist die gleiche Art von Lösung. Wir sagen: "Wir haben eine Reihe von Diensten, es ist notwendig, dass sie irgendwie miteinander reden können, weil sie nicht verstehen, wo sie sitzen und es nicht klar ist, ob sie darauf antworten oder nicht, und sie werden es nicht schaffen." Also lass es uns jetzt tun, in der Mitte werden wir einen universellen Verstand einfügen, der ihnen sagt, mit wem du reden kannst, mit wem du nicht reden kannst und sie beschützt, wenn sie plötzlich etwas Unhöfliches als Antwort sagen. " Und es gibt viele Fragen. Einerseits ist dies eine Art Notwendigkeit, weil Organisationen nicht damit umgehen können. In den letzten Jahren haben wir mehreren Unternehmen dabei geholfen, in die neue kühne Welt von Cloud Native einzusteigen, insbesondere wenn es um Unternehmenswachstum, Skalierung und den Verlust von Mitarbeitern geht. Mittendrin steht ein kleines Team der sogenannten DevOps, die Tausende von YAML-Zeilen schreiben müssen, um das irgendwie zu bewältigen, und alles platzt aus allen Nähten.

Cloud native

Oleg: Können Sie ein wenig erklären, was Cloud Native ist? Weil es zu einer Art Modewort geworden ist, schreibt es jetzt jeder an jede Wand. Wie siehst du das

Anton: Im Großen und Ganzen begann alles mit dem Aufkommen des Ansatzes „Plattform als Service“, das heißt, wir mussten viel mehr Software und viel mehr Webservices ausführen als zuvor. Wir haben festgestellt, dass es nicht mehr möglich ist, jeden Dienst einzeln als Lieblingshaustier einzuführen, das wir namentlich kennen und unser ganzes Leben lang pflegen. Wir müssen mit ihnen wie mit einer Art Herde umgehen. Dazu benötigen wir eine Art homogene Plattform, auf der wir diesen Code ablegen können, und die Plattform ist intelligent genug, um ihn bereitzustellen. Autotrinker, kurz ein Autotrinker-Feeder für den Service.

Die Pioniere dieses Ansatzes waren Heroku. Sie sagten, damit diese Dienste unsere Infrastruktur nutzen können, müssen sie auch Kühe sein. Das heißt, sie müssen bestimmte Eigenschaften haben. Es gab also eine 12-Faktor-Anwendung, die möglichst wenig stabilen Zustand haben sollte. Eine solche Anwendung wird notwendigerweise von einer bestimmten Pipeline zusammengestellt, in der ihre Kompatibilität mit der Plattform überprüft wird. Es sollte in der Lage sein, belastbar (stabil) zu sein - um zu wissen, dass wenn etwas schief geht, es nicht sofort herunterfällt. Auf der anderen Seite sollten Sie sich in gewisser Weise auf die Plattform verlassen. Im Allgemeinen ist ein solcher Hybrid. Verstehen Sie, dass Sie nicht alleine sind, dass es eine Plattform gibt und dass Sie deren Einschränkungen respektieren müssen. Im Großen und Ganzen fing alles von dort an.

Aber aus irgendeinem Grund hat sich dieser Ansatz der „Plattform als Service“ nicht gerechtfertigt, und der versprochene Boom ist nicht eingetreten. Das heißt, ja, es war Heroku, und gleich nach ihnen haben alle großen Jungs ihre Analoga angesprochen: Google App Engine, Amazon - Elastic Beanstalk. Ich musste viel mit Firmen zusammenarbeiten, die damit anfingen. Aber in dem Moment, in dem Sie etwas tun, das leicht über die von der Plattform erlaubten Grenzen hinausgeht, wird es zu schrecklichen Kopfschmerzen. Weil du anfängst auf Wände zu stoßen, die überall sind. Und wenn Menschen dazu neigen, über Wände zu stolpern, beginnen sie nach einem Weg zu suchen, wie sie die Wand durchtrennen können.

Der moderne Cloud Native ist von da an gewachsen: Wie lässt er sich weiterhin in der Cloud ausführen, verwendet einige Plattformdienste, bietet aber auch erstaunliche Flexibilität für alles, was passiert. Wir balancieren ständig zwischen Flexibilität und Einfachheit. Flexibilität verursacht Komplexität, während die Vereinfachung und Schaffung einer übersichtlichen Plattform immer Einschränkungen mit sich bringt. Cloud Native findet offenbar ein gewisses Gleichgewicht zwischen den Einschränkungen der Cloud-Plattform und der Flexibilität, die Ihnen die Cloud mit ihrer automatischen Skalierung bietet, und all dies hat einen Preis.

Oleg: Wahrscheinlich sollte die Organisation selbst lernen, prozessual mit all diesen Dingen umzugehen.

Anton: Natürlich natürlich! Das alles hinterlässt Spuren. Dazu gehören auch Microservices. Im Großen und Ganzen ist dies die Idee, dass wir über kleine Services, kleine Anwendungen, die über die Cloud verstreut sind und jederzeit und überall verfügbar sind, und dass es heute und morgen 10 Replikate geben kann - 1.500 davon sind ebenfalls Teil der Cloud Eingeborener Die Idee, dass wir nicht an die physischen Grenzen des Rechenzentrums gebunden sind. Im Großen und Ganzen ist die ganze Welt meine Wolke, es ist eine sehr wunderbare Vision, ein wundervoller Wunsch, aber es hat einen Preis, und dieser Preis ist Komplexität. Der Preis ist, dass im Großen und Ganzen niemand im Kopf passen kann, was passieren wird. Wenn unsere Anwendung plötzlich von 10 auf 1500 Instanzen anwächst. Niemand kann sich das vorstellen, und alle Skalierungsartefakte beginnen zu erscheinen. Als Menschen, als Betreiber, können wir nichts damit anfangen, außer auf das Chaos zu reagieren, das sich ereignet. Und so beginnen wir zu überlegen: „Aber wie können wir unsere Anwendung und unsere Infrastruktur so aufbauen, dass diese Artefakte, wenn sie entstehen, erstens vorausgesehen werden können und zweitens, irgendwie können wir mit diesen Artefakten fertig werden und fortfahren funktionieren? "

Kombination von technischen und nichttechnischen Fähigkeiten

Oleg: Haben Sie Berichte über technische Dinge, zum Beispiel über ein Service-Sieb, und es gibt Berichte über Führung, über Management, all das? Sind Sie eher eine technische Person oder sind Sie ein Manager oder ist Ihre Arbeit irgendwie anders?

Anton: Ich habe sogar irgendwann angefangen, über diesen Beitrag zu schreiben. Ich bin noch nicht fertig damit. In gewisser Weise bin ich rein persönlich zwischen diesen beiden Dingen hin- und hergerissen, weil ich einerseits gerne verstehe, wie Dinge funktionieren, und mich gerne mit ihnen befasse. Wenn es möglich ist, ein technisches Problem zu lösen, vermittelt es ein erstaunliches Gefühl für die eigenen Fähigkeiten, was als sofortige Befriedigung, sofortige Belohnung und Dopaminfüllung bezeichnet wird: "Oh, cool, ich kann, ich habe entschieden." Und es ist schwer abzulehnen, es ist schwer auszusteigen. Und da es so ist, mache ich weiterhin technische Dinge. Neue Technologien begeistern mich: Es ist cool, etwas auszuwählen, etwas zu verstehen. Aus diesem Grund stellt sich heraus, dass die Leute dieses Wissen kaufen möchten, da es vorhanden ist, und ich verkaufe es weiterhin.

Andererseits verstehe ich, dass dies nur ein kleiner Teil des Gesamtbildes ist, ich habe lange in der Branche gearbeitet und ich kann nicht anders, als zu sehen, dass Technologie nur eine Ecke eines großen Systems ist, nur eine der Komponenten. Ich habe die Teams geleitet und verstehe, wie wichtig es ist, das Zusammenspiel von Technologien und Tools mit denjenigen Personen zu berücksichtigen, die sie verwenden. Letztendlich gibt es Informationstechnologie, in der Tat jede Technologie, die Menschen nutzen können. Und Technologien zu entwickeln, ohne darüber nachzudenken, wer sie einsetzt, ist völlig sinnlos. Die Technologie selbst ist überhaupt nicht interessant, es sei denn, Sie denken über ihre Anwendung nach, und die Anwendung ist immer mit Personen verbunden, die irgendwie davon profitieren. Und so interessiert mich auch alles rund um die Technik. Ich fühle, dass es notwendig ist, darüber zu sprechen, ich verstehe, dass ohne das alles wirklich keinen Sinn ergibt. In dem Maße, wie ich manchmal hoch zum Sitzen komme, etwas, um dort zwei bis drei Tage, manchmal Wochen zu schnüffeln. Ich kann mit einer Art Problem mitreißen, das ich nicht lösen kann, ich kann es lösen, eine erstaunliche Gemeinde daraus machen. Aber dann hebe ich den Kopf von der Tastatur, schaue mich um und verstehe, dass etwas passiert, das ich in keiner Weise ignorieren kann. Und dann werden der Code und die Auswahl in Linux für mich völlig uninteressant und unwichtig, und ich möchte anfangen, Probleme auf einer anderen Ebene zu lösen, auf menschlicher Ebene.

Wie man DevOps schnell herausfindet

Oleg: Hören Sie, können Sie Leuten, die sich jetzt gleichzeitig mit dem Engineering und dem Studium von DevOps-Praktiken beschäftigen, etwas raten? Wie schiebe ich alles in und in welcher Reihenfolge? Relativ gesehen, wie planen Sie vielleicht Ihre Karriere, um in kurzer Zeit erfolgreicher zu werden?

Anton: Eh ... Nun, aus eigener Erfahrung gibt es wieder keine allgemeingültigen Tipps. Für eine lange Zeit, wahrscheinlich die ersten 10 Jahre meiner Karriere, war ich mit meinem Platz unzufrieden. Ich suchte nach dem, was mir nicht gefiel, ich konzentrierte mich darauf, ich suchte nach dem, was für mich interessanter wäre. Aber im Großen und Ganzen tat er nichts dagegen. Der Hauptratschlag ist ... Wann ist meine Karriere meiner Meinung nach bergauf gegangen? In dem Moment, als ich anfing, über Dinge zu sprechen, die für mich interessant waren. Das Gebiet des technischen Wissens, auch nicht nur des technischen, im Allgemeinen ist das Gebiet der Informationstechnologie sehr breit, das heißt, Sie können ein Technikfreak sein: ein Entwickler, ein Tester, ein Integrator und ein Systemadministrator - all dies sind verschiedene Dinge, jeder kann dort seine eigene Nische finden. Sie möchten kein absoluter Technikfreak sein, interessieren sich für technische und gleichzeitig geschäftliche Dinge? Engagieren Sie sich für ein Produkt, ein Projekt. Nische ist voll, finden Sie Ihre Nische, die Sie interessieren wird.

Nun wird viel über Profis in Form von "T" gesagt. Sie müssen verstehen, wo sich Ihr T-Fuß befindet, eine Sache auswählen und an dieser Stelle anfangen zu graben. Beim Graben werden enorme Tiefen zu finden sein. Aber Sie können überall graben. Und mir ist klar, dass es viele Bereiche gibt, in denen ich nicht tief gegraben habe, weil ich versucht habe zu schauen und gemerkt habe, dass dies nicht meine war. Und hier, wo Sie am Graben interessiert sind - graben Sie weiter, und hier ist es sehr wichtig, darüber zu sprechen. Das heißt, ich verstehe wieder, dass dies nicht jedermanns Sache ist. : -, , , — , Gist' GitHub. - — .

. DevOps — . , , . , , , , - , - , , - . , . , , , , , , , . , . . ? — , , . , , . , . Irgendwie so. .

: , , DevOps', , . , , . , -, , … , . - , ? . , , : « ». , ?

: -, , , : « ». - , , , , . , , : « ».

: ?

: , , , , , . , — . , , «, , », - . , - , . - , - . , Agile: , , , , , .

, . . , — , - — , , — , , , , , . : « — , . , , . , . , , , -, , , ». , , , .

, - , , continuous integration … , , , . , , . , 10 : , , - , , , , , , , , . — . : , , , , . E - , , .

: . , - , , - , , , , DevOps -. ?

: , , , , . , , , , ? , , . . - , , .

, , . , , .

DevOps

: , : Google, Netflix, . , ?

: , , ( ) , — , , , . , , lean management — value stream mapping. . , , , - : , , , , , , , , . , , , .

: ? - — - , , — . , , , , . , , , Java, , , . , :

— , .
— , ? ?
— , , .

, , , , — , . — , .

, :
— .

:
— , , . .

, , :
— .

:
— . ?

:
— , .

, — , , . . . , CI/CD — . , . , , . , , .

: , ? , CI/CD . ?

: -, , . - , , , , . Kubernetes: , — Kubernetes. VMware , Kubernetes . , Google . , , .

: Google ?

: , , Swarm Kubernetes, Docker. Docker , . , Microsoft, Amazon — « Docker». Docker! Docker . , , , , Google, Microsoft, Amazon? , . , , , . , . .

Also. . — . — « Kubernetes , ». . Kubernetes . Kubernetes — - API, , . API . — , , , , : « API, , Kubernetes, Kubernetes , ».

— , Continuous Delivery Foundation, - , , Google, CloudBees, GitLab. Tekton, — API continuous delivery-. , continuous integration / continuous delivery- Kubernetes, , , . , . Microsoft , , SMI Spec. , , - .

Kubernetes . , , - , , Kubernetes — .

Oleg: Zu welchen Berichten gehst du selbst, was findest du interessant?

Anton: Erstens, wenn es ein neues technologisches Feature gibt, einen Streuner, den ich einfach noch nicht sehen kann, und es einen Sprecher gibt, der verständlich darüber spricht, dann halte ich das für einen wilden Vorteil, denn stattdessen Um jetzt zu lesen und zu graben, und vielleicht mit Schwierigkeiten beim Verstehen, können Sie in einer halben Stunde kommen und hören, wie eine Person Ihnen zeigt, sagt. Auch dafür braucht man eine gewisse Fähigkeit und den Wunsch, über Technologie sprechen zu können. Und ich verstehe, dass dies auch nicht von irgendwo herkommt, wir müssen daran arbeiten. Ich habe auch viel Zeit gebraucht. Übrigens hat mir die Tatsache, dass ich im technischen Unterricht tätig bin, sehr geholfen. Wenn Sie eine Klasse vor sich haben, müssen Sie den Leuten etwas erklären, und Sie verstehen, dass sie, egal wie Sie es erklären, dumm sind - Sie erkennen, dass das Problem anscheinend darin besteht, wie Sie es erklären, und nicht, dass die Leute dumm sind .

Oleg: Und welche Art von technischer Lehre? Was machst du?

Anton: Ich unterrichte seit ungefähr 7-8 Jahren rein technische Disziplinen. Es begann damit, dass ich ein Jahr lang Dinge wie Maven und Shell-Scripting unterrichtete. Da ich mit Jenkins sehr beschäftigt war und ihn sehr gut kannte, brachte ich den Leuten bei, wie man mit Jenkins, der Verwaltung, arbeitet. In den letzten Jahren gab es alles, was mit Cloud Native zu tun hatte: Kubernetes, Container und alles, was damit zu tun hat. Ich gehe bald nach London, ich werde eine Meisterklasse über Istio machen. Dies ist nicht der Hauptteil meiner Tätigkeit, aber irgendwann in ein oder zwei Monaten führe ich Meisterkurse durch.

Oleg: Gehen Sie hauptsächlich zu einem Bericht, zu einem Thema oder zu einer Person?

Anton: Wenn ich weiß, dass der Sprecher gut ist, dann gehe ich zu einer Person, einfach weil es für mich immer noch sehr wichtig ist, von anderen Menschen zu lernen, wie man gut erzählt. Lernen ist immer wichtig. Wenn es ein Thema gibt, ich den Sprecher aber nicht kenne, dann werde ich es mir ansehen, aber wie üblich, wie man zum Aufstehen geht: Ich habe mir die ersten 10-15 Minuten angesehen, bin nicht reingegangen - links. Oder es gibt Redner, die ich wirklich in irgendeiner Weise ansprechen werde, weil sie immer interessant erzählen, auch wenn die Dinge, die Sie aus ihrer Sicht zeigen können, nur für Sie sind und die ganze Frage aus einer neuen Perspektive drehen. Von denen, die ich in letzter Zeit mag ... Erstens gibt es Simon Wardley - ein Berater, der einen eigenen Chip zum Kartenziehen hat, er erklärt mit Hilfe von Karten, wie Unternehmen ihre Strategie richtig aufbauen können, das war er einmal dann CTO, CEO von Startups, spricht er viel darüber, über Technologie. Übrigens ertrinkt er ständig für serverlos und sagt, dass diejenigen, die heute nicht serverlos sind, große Probleme haben.

Oleg: Ist das der Kamerad, der das Medium-Buch hat ? Er hat es in Form von Posten gemacht. Ungewöhnliches Format.

Anton: Er redet wirklich sehr cool. An seine Vorlesungen in den letzten 2-3 Jahren erinnere ich mich am meisten. Nun, John Willis, der letztes Jahr zu DevOops kam - einfach, weil er wirklich weiß, wie man es erzählt . Es gibt ein Problem mit ihm, weil er viel über die amerikanische Realität spricht, Dinge, die manchmal einfach nicht auf die russische oder israelische Realität zutreffen. Jetzt haben sie eine Art Krieg mit einigen Änderungsgenehmigungsgremien, über die sie ständig sprechen. Dies ist anscheinend eine bestimmte Sache, die es in amerikanischen Unternehmen gibt, es gibt einen solchen Prozess für die Durchführung und Genehmigung von Änderungen in der IT, eine Art von Verpflichtungen, die durchlaufen werden müssen.

Oleg: Aber das haben wir nicht - ich verstehe nicht einmal, wovon du gerade sprichst.

Anton: Also ich verstehe das auch nicht wirklich, so etwas gibt es auch in Israel nicht. Und da reden sie darüber. Wenn Sie all diesen Genossen wie DORA zuhören, die den State of DevOps Report erstellen , schreiben sie auch viel darüber. Im Allgemeinen meine ich, dass die Leute über irgendeine Art von Problem sprechen, das nur sie haben, und dass Sie überhaupt nicht daran interessiert sind.

Oleg: Du warst bei den letzten DevOops. Welche Berichte sind es wert, gelesen zu werden und die Aufnahmen zu überprüfen?

Anton: Alle sehen . Leicht interessiert an dem Thema - los.

Oleg: Meiner Meinung nach gibt es einige Anton Weiss. Wahrscheinlich einen Blick wert.

Anton: Nein, mach nicht so langweilige Sachen :-)

Oleg: Nun, vielen Dank. Das war cool! Ich sehe, dass Sie bereits einen Bericht für die nächste Konferenz eingereicht haben. Wir sehen uns auf der nächsten DevOops!

Die DevOops 2020 Moskau Konferenz findet vom 29. bis 30. April dieses Jahres in Moskau statt. Wir haben die Essenz der Konferenz über Habré in der Ankündigung "DevOps-Ingenieure gibt es nicht" beschrieben. Das Programm wird aktiv gestaltet (es gibt noch viele Monate vor der Konferenz), aber die ersten Redner sind bereits vor Ort zu sehen . Dort können Sie Tickets kaufen .