Erfahrung in Multithread-Arbeit oder Wie man DevOps für viele Entwicklungsteams ist

Hey Habr! In diesem Artikel möchte ich meine Erfahrungen mit der Teilnahme am Digitalisierungsprozess eines großen Unternehmens teilen. Im Folgenden erzähle ich Ihnen von den Funktionen, auf die ich bei der Interaktion mit einer großen Anzahl von Entwicklungsteams gestoßen bin. Auf ihrer Grundlage werden wir im zweiten Teil des Artikels überlegen, welche Prinzipien dazu beigetragen haben, die Arbeit unter solchen Bedingungen zu bewältigen und zu optimieren.

Einführung

Obwohl Nixys hauptsächlich im Outsourcing-Format arbeitet oder Designarbeiten durchführt, arbeiten wir in diesem Fall seit mehr als einem Jahr mit dem Kunden – einem großen Produktionsunternehmen – im Outstaff-Format zusammen.

Die Produktion im großen Maßstab besteht aus vielen verschiedenen Phasen, und jede hat eine separate Werkstatt oder ein eigenes Team. Um die Digitalisierung durchzuführen, ist es notwendig, für jede einzelne Stufe eine eigene spezielle Anwendung mit einer einzigartigen internen Logik zu erstellen.

Daher verfügte das Unternehmen des Kunden über viele Entwicklungsteams sowie ein separates Team von DevOps-Ingenieuren, die Anwendungen in einem gemeinsamen Cluster bereitstellten. Im Kontext dieses Artikels kann der Begriff „Projekt“ mit dem Begriff „Anwendung“ gleichgesetzt werden. Jeder der Ingenieure, einschließlich mir, hatte seine eigene Projektliste. Daher die Notwendigkeit, mit einer großen Anzahl von Teams zu interagieren. Zu einer Zeit überstieg die Anzahl der Projekte, für die ich verantwortlich war, 20, aber im normalen Modus musste ich mit durchschnittlich 10 Teams interagieren. Oft ist die Arbeit intensiv und sehr interessant aufgrund der vielen Kommunikationen mit verschiedenen Menschen.

Es gibt viele und sie sind alle so unterschiedlich.

Eine große Zahl ist Vielfalt, eine große Vielfalt ist Chaos.

Was wir Chaos nennen, sind nur Muster, die wir nicht erkannt haben. (c) Chuck Palahniuk, „Überlebender“

Es waren die vielen unvermeidlichen Unterschiede zwischen den Entwicklungsteams, die am Anfang unserer Zusammenarbeit für die größte Verwirrung sorgten. Ich werde weiter über diese “Unterschiede zwischen” sprechen.

  • Verbindung.

    Teammitglieder können völlig unterschiedlich sein. Manche sind Entwicklungsspezialisten, andere Shopfloor Manager, die viel über den Produktionsprozess wissen, aber wenig Verständnis für den von ihnen geleiteten Entwicklungsprozess haben. Ich reproduziere eine Frage zum Einrichten von cronJob, die sich in meine Seele eingegraben hat:

Dasselbe gilt für Entwickler. Sie können sowohl erfahren sein als auch einige der grundlegenden Dinge für ein DevOps-Team nicht verstehen.

  • Rollenverteilung.

    Einige Teams haben möglicherweise eine klar definierte Führungsrolle. Dann stimmen alle Entscheidungen damit überein, und es gibt keine Verwirrung, bei anderen übernimmt einer der Entwickler die Verantwortung oder der Prozess wird vom RP verwaltet. In einem Team gewöhnt man sich an eine Interaktionsregel, in anderen ist alles ganz anders. Es ist schwierig vorherzusagen, bevor Sie auf eine bestimmte Situation stoßen. Bleibt nur, flexibler zu sein und jeweils eigene Ansätze zu suchen.

  • Kohärenz der Arbeit, Interaktion.

    Wenn die Arbeit am Projekt vereinbart ist und aktiv vorangetrieben wird und der RP Fragen hat, warum „bisher nichts funktioniert“, dann liegt das Problem in der Kommunikation. Manchmal erfährt man davon aus einer Beschwerde an das Management.

    Eine meiner (jetzt) ​​liebsten Erinnerungen ist, als mich in den ersten Arbeitstagen ein Fremder anrief. Mit erhobener Stimme beschwerte er sich, dass ihnen „immer etwas kaputt geht“ und verlangte zu erklären, warum alles so schlimm sei. Dann fand ich heraus, dass dies der Projektmanager ist.

    Aber im Gegensatz zu diesem Fall gibt es immer Teams mit völligem gegenseitigem Verständnis, jeder sieht seine Aufgaben und den Fortschritt des Prozesses. Es ist sehr angenehm, unter solchen Bedingungen zu arbeiten.

  • Unterschiedliches Tempo und Aktivität bei Projekten.

    Manchen Teams ist es wichtig, eine bestimmte Deadline einzuhalten, deshalb nutzen sie auch das Wochenende als Arbeitszeit (Hallo, Sonntagseinsätze!). Andere hingegen sind bereit, Inspektionen um mehrere Tage zu verschieben, um sich qualitativ Zeit dafür zu nehmen, nachdem sie die geplanten Aufgaben zuvor erledigt haben.

  • Anzahl der Messenger und Chats.

    Es gibt unglaublich viele davon. Einige Projekte werden geschlossen, andere geöffnet, Entwickler schreiben private Nachrichten, während sich Chats häufen. Oft blättern Sie zunächst einige Minuten durch die Korrespondenz mit einer Person, um zu verstehen, wer an welchem ​​​​Projekt schreibt. Wenn Sie jemandem schreiben müssen, besteht die Gefahr, dass Sie viel Zeit damit verbringen, sich daran zu erinnern, in welchem ​​​​Messenger Sie mit ihm kommuniziert haben.

    Das Hauptmerkmal besteht darin, einen Ansatz zu finden und effektiv mit jedem Team zu kommunizieren. Und dazu müssen Sie alle diese Parameter auswählen und durchlaufen. Allmählich fangen Sie an, all diese Punkte im Kopf zu behalten. Manchmal beschleunigt die Verwendung aller Feinheiten die Lösung des Problems erheblich.

Wie geht man mit der Arbeit in diesem Modus um?

Natürlich war das erste Mal (wie bei jedem neuen Projekt) hart.

Eine häufige Situation ist beispielsweise eine Unterbrechung der Kommunikation mit einer Person. Während dieser Zeit finden mehrere andere Dialoge statt. In dem Moment, in dem Sie zum ersten Chat zurückkehren, verstehen Sie nicht mehr, was passiert, wer das schreibt und was Sie hier im Allgemeinen tun.

Die folgenden Prinzipien haben mir geholfen, die Arbeit in diesem Modus zu optimieren. Sie tauchten nicht sofort auf. Jeder hat zu seiner Zeit dazu beigetragen, den Arbeitsablauf zu verbessern. Mal ging es um die Lösung von Konfliktsituationen, mal um eine Beschleunigung des Verständnisses des Geschehens, um eine Steigerung der Kommunikationsqualität oder einfach um die Organisation des eigenen Seelenfriedens.

  • Schreiben Sie alles auf, was Sie tun.

    Da die Kommunikation mit den Entwicklern in Dialogen stattfindet, kann man in einem riesigen Stream leicht verlieren, was genau man am aktuellen Tag gemacht hat. Vor allem am Anfang. Solche Details sollten aufgezeichnet werden. Dies hilft später bei zukünftigen Aufgaben:

    • Beschreiben Sie detailliert die Arbeitskosten am Ende des Tages;

    • keine einzige Aufgabe zu verlieren, auch wenn sie sich über mehrere Tage oder Wochen (Wochen) erstreckt;

    • Erstellen Sie eine detaillierte Projekthistorie.

  • Pflegen Sie eine Aufgabenhistorie für jedes Projekt.

    Fortsetzung des vorherigen Absatzes. Status für 10 Projekte im RAM zu halten ist unrealistisch (in den ersten Monaten). Warum könnte das nützlich sein?

    Da mehrere Ingenieure an dem Projekt arbeiten, gab es Situationen mit ungleichmäßiger Arbeitsbelastung, in denen sich die Kollegen langweilten und mein Rückstand voll war (oder umgekehrt). An dieser Stelle fällt es ihnen leicht, sich mit meiner Hilfe zu verbinden, wenn es eine detaillierte Beschreibung der Geschichte des Projekts gibt.

  • Verwenden Sie Ihr eigenes Aufgabensystem.

    Ich habe selten darüber nachgedacht, da es keinen solchen Bedarf gab, die Kommunikation mit den Teams fand hauptsächlich außerhalb unseres Task-Trackers statt, in verschiedenen Chats. Aber nachdem auch meine anderen Kollegen von Nixys in die Projekte dieser Firma eingestiegen waren, änderte sich die Situation. Für unsere Zwecke entstand ein Board in Trello. Sie half, die beiden oben beschriebenen Punkte bequem zu organisieren. Ganz zu Beginn des Projekts wurde eine Liste mit Namen und Beschreibung zum Zeitpunkt des Starts erstellt. Wenn ich eine Aufgabe von einem Projekt erhalten habe, habe ich eine Karte in meiner persönlichen Liste erstellt, und nachdem ich sie gelöst habe, habe ich sie an das Ende der Liste eines bestimmten Projekts verschoben, um eine Geschichte zu bilden. Darüber hinaus war es praktisch, Links zu ständig aktualisierten wichtigen Ressourcen im gemeinsamen Arbeitsbereich zu sammeln.

    Dieser Punkt, zusammen mit den vorherigen, erlaubte 4-5 Stunden pro Woche, die für die Organisation aufgewendet wurden. Momente auf 1 Stunde verkürzen.

  • Eingaben immer validieren.

    Ein Punkt, über den ich und Kollegen schon oft gestürzt sind. Wenn die Aufgabe “Diesen Wert in diesen ändern” lautet, ist die schlechteste Entscheidung, genau das zu tun, was gefragt wurde. Aufgrund unterschiedlicher Eintauchtiefe, technischer Vertrautheit und schlichter Unaufmerksamkeit werden bei solchen Anfragen häufig falsche Daten angegeben. Russische Schriftzeichen im lateinischen Text, ein Fehler in der Schreibweise des Hosts, fehlende Zahlen in der IP-Adresse – die Liste kann endlos sein. Um den Prozess zu beschleunigen, sollten Sie vor der eigentlichen Aufgabe überprüfen, ob Sie die richtigen Daten erhalten haben. Sonst kann man nachträglich sehr lange und fieberhaft an ganz anderen Stellen nach einem Fehler suchen.

    Diese Regel sparte am Ende mindestens 2 Stunden pro Woche, um nach selbst erstellten Fehlern zu suchen.

  • Bestehen Sie auf einfachen und transparenten Lösungen.

    In den Momenten, in denen es darum geht, eine atypische Lösung zu implementieren, ist es wichtig, auf ihre detaillierte Begründung zu achten und klärende Fragen zu stellen. Wie oben beschrieben, haben Entwickler manchmal unvollständige Informationen, insbesondere bezüglich des CI / CD-Prozesses. Oft gibt es eine einfachere und kompetentere Lösung, es ist wichtig, diese einfach vorzuschlagen und zu begründen.

    Und die Hauptsache an dieser Stelle ist, darauf zu bestehen. Selbst wenn Sie eine komplexe Art der Arbeit an einem Projekt sehr gut verstehen, wird es für einen Kollegen schwierig sein, seine Funktionen zu verstehen (denken Sie an das Übertragen von Aufgaben aus dem Backlog) und sich selbst nach einigen Monaten wieder zu verstehen. Wenn es also gängigere Alternativen gibt, ist es besser, diese zu nutzen, um sich und anderen in Zukunft mit Unterstützung des Projekts das Leben zu erleichtern.

  • Fristen im Voraus festlegen.

    Oben habe ich das Auftreten von Situationen mit vollem Rückstand beschrieben. In dieser Hinsicht kann eine einfache Aufgabe (15-30 Minuten) viel länger dauern. Und in einer solchen Situation ist es besser, im Voraus anzugeben, nach welcher Zeit ungefähr es gelöst wird. Denn beim zweiten Mal können verärgerte RP direkt zum Management gehen und sich darüber beschweren, dass sie ihr wichtigstes Projekt ignorieren! Auf diese Weise vermitteln wir den Problemautoren sofort ein Verständnis der Situation und reduzieren die Wahrscheinlichkeit zukünftiger Konflikte.

  • Beschreiben Sie Statussachen in einem allgemeinen Chat.

    Auch wenn die Diskussion der Entscheidung während des Telefonats mit dem Entwickler stattfand, sollte eine Zusammenfassung über die getroffene Entscheidung geschrieben werden. Das hilft sehr dabei, Kollegen (und insbesondere RPs) über alles auf dem Laufenden zu halten, auch wenn sie nicht direkt an der Entscheidung beteiligt sind. Auch wenn die Lösung jemand anderen betrifft, kann sie ihre Meinung äußern, Fragen stellen und Anpassungen vornehmen, bevor sie implementiert wird und das nächste Problem auftritt.

  • Nimm an täglichen Meetings von Großprojekten teil.

    Für aktive und große Projekte müssen Sie täglich gehen. Dadurch wird das Verständnis für den Status des Projekts und die Priorität der Aufgaben bei allen Beteiligten erheblich verbessert. Kriterien für die Notwendigkeit hierfür sind wiederkehrende Situationen mit Unverständnis im Projektteam sowie das Vorhandensein vieler paralleler Aufgaben von unterschiedlichen Autoren.

Fazit

Alle oben beschriebenen Prinzipien haben sich allmählich in Kollisionen mit realen Situationen herausgebildet, und ich habe es geschafft, ihre Wirksamkeit vollständig zu erfahren. Einige davon konnte ich selbst ableiten, andere – Tipps und Empfehlungen von älteren Kollegen, für die ich ihnen danke.

Meine Erfahrung mit der Arbeit in diesem Modus war sehr interessant und intensiv. Zunächst geht es um Interaktion und die Entwicklung von Kommunikationsfähigkeiten. Wenn Sie mich gefragt haben, ob ich empfehlen würde, so etwas zu erleben, definitiv ja. Und wenn Sie es eines Tages wirklich erleben sollten, helfen Ihnen die hier beschriebenen Tipps hoffentlich dabei, nicht mit dem Kopf in den Pool zu stürzen, sondern besser vorbereitet an die Situation heranzugehen und zu wissen, was auf Sie zukommt und wie Sie handeln müssen.

Jetzt, nach einiger Zeit, ist mir die Erkenntnis gekommen, dass ich an der Digitalisierung – einem riesigen, ressourcenintensiven Prozess – mitgewirkt und zur Entwicklung der Bequemlichkeit und Effizienz der Arbeitsumgebung der Produktion beigetragen habe. Wie riesige Bauwerke begeistern und faszinieren auch große Prozesse.

Abonnieren Sie übrigens unseren Telegram-Kanal DevOps FMwo wir nicht nur Originalartikel veröffentlichen, sondern auch die neuesten Nachrichten aus der DevOps-Welt.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *