Entwickler kommen vom Mars, Admins von der Venus

Zufälle sind zufällig, und tatsächlich war es auf einem anderen Planeten ...

Ich möchte drei Erfolgs- und Misserfolgsgeschichten darüber erzählen, wie ein Backend-Entwickler im Team mit Administratoren arbeitet.

Die erste Geschichte.
Im Webstudio lässt sich die Anzahl der Mitarbeiter an einer Hand abzählen. Heute bist du Layout-Designer, morgen bist du Backender, übermorgen bist du Admin. Einerseits kann man enorme Erfahrungen sammeln. Andererseits mangelt es in allen Bereichen an Kompetenz. Ich erinnere mich noch an den ersten Arbeitstag, ich bin noch grün, der Chef sagt: „Spachtelmasse aufmachen“, aber ich weiß nicht, was das ist. Eine Kommunikation mit Admins ist ausgeschlossen, da Sie sind selbst Administrator. Betrachten wir die Vor- und Nachteile dieser Situation.

+ Alle Macht liegt in deinen Händen.
+ Es besteht keine Notwendigkeit, jemanden um Zugriff auf den Server zu betteln.
+ Schnelle Reaktionszeit in alle Richtungen.
+ Verbessert die Fähigkeiten gut.
+ Sie verfügen über ein umfassendes Verständnis der Produktarchitektur.

- Hohe Verantwortung.
— Gefahr von Produktionsunterbrechungen.
— Es ist schwierig, in allen Bereichen ein guter Spezialist zu sein.

Kein Interesse, lass uns weitermachen

Die zweite Geschichte.
Großes Unternehmen, großes Projekt. Es gibt eine Verwaltungsabteilung mit 5-7 Mitarbeitern und mehrere Entwicklungsgruppen. Wenn man in einem solchen Unternehmen arbeitet, denkt jeder Administrator, dass man nicht hierher gekommen ist, um an einem Produkt zu arbeiten, sondern um etwas kaputt zu machen. Weder die unterzeichnete Vertraulichkeitsvereinbarung noch die Auswahl beim Vorstellungsgespräch deuten auf etwas anderes hin. Nein, dieser Mann kam mit seinen schmutzigen kleinen Händen hierher, um unsere Kussproduktion zu ruinieren. Daher ist mit einer solchen Person ein Minimum an Kommunikation erforderlich; zumindest können Sie als Antwort einen Aufkleber werfen. Beantworten Sie keine Fragen zur Projektarchitektur. Es empfiehlt sich, den Zugriff erst dann zu gewähren, wenn der Teamleiter danach fragt. Und wenn er darum bittet, wird er es mit noch weniger Privilegien zurückgeben, als sie verlangt hatten. Fast die gesamte Kommunikation mit solchen Admins wird vom schwarzen Loch zwischen der Entwicklungsabteilung und der Verwaltungsabteilung absorbiert. Es ist unmöglich, Probleme zeitnah zu lösen. Sie können jedoch nicht persönlich vorbeikommen, da die Administratoren rund um die Uhr zu beschäftigt sind. (Was machen Sie die ganze Zeit?) Einige Leistungsmerkmale:

• Die durchschnittliche Bereitstellungszeit in der Produktion beträgt 4–5 Stunden
• Maximale Bereitstellungszeit in der Produktion 9 Stunden
• Für einen Entwickler ist eine Anwendung in der Produktion eine Black Box, genau wie der Produktionsserver selbst. Wie viele sind es insgesamt?
• Geringe Qualität der Veröffentlichungen, häufige Fehler
• Der Entwickler beteiligt sich nicht am Veröffentlichungsprozess

Nun, was habe ich erwartet, natürlich dürfen neue Leute nicht in die Produktion. Nun gut, nachdem wir Geduld gewonnen haben, beginnen wir, das Vertrauen anderer zu gewinnen. Aber aus irgendeinem Grund sind die Dinge bei Administratoren nicht so einfach.

Akt 1. Der Administrator ist unsichtbar.
Veröffentlichungstag, Entwickler und Admin kommunizieren nicht. Der Administrator hat keine Fragen. Aber später verstehen Sie, warum. Der Administrator ist ein prinzipientreuer Mensch, hat keine Messenger, gibt seine Telefonnummer an niemanden weiter und hat kein Profil in sozialen Netzwerken. Es gibt nirgendwo ein Foto von ihm. Wie siehst du aus, Alter? Wir sitzen etwa 15 Minuten fassungslos mit dem verantwortlichen Manager zusammen und versuchen, eine Kommunikation mit diesem Voyager 1 herzustellen, dann erscheint in der Unternehmens-E-Mail die Nachricht, dass er fertig ist. Werden wir per Post korrespondieren? Warum nicht? Praktisch, nicht wahr? Na gut, lass uns abkühlen. Der Prozess ist bereits im Gange, es gibt kein Zurück mehr. Lesen Sie die Nachricht noch einmal. "Ich bin fertig". Was hast du fertig gemacht? Wo? Wo soll ich nach dir suchen? Hier verstehen Sie, warum 4 Stunden bis zur Veröffentlichung normal sind. Wir bekommen einen Entwicklungsschock, aber wir beenden die Veröffentlichung. Es besteht kein Wunsch mehr, loszulassen.

Akt 2. Nicht diese Version.
Die nächste Veröffentlichung. Nachdem wir Erfahrungen gesammelt haben, beginnen wir damit, Listen der für den Server erforderlichen Software und Bibliotheken für Administratoren zu erstellen und bei einigen die Versionen anzugeben. Wie immer erhalten wir ein schwaches Funksignal, dass der Admin dort etwas erledigt hat. Es beginnt der Regressionstest, der etwa eine Stunde dauert. Alles scheint zu funktionieren, aber es gibt einen kritischen Fehler. Wichtige Funktionen funktionieren nicht. Die nächsten paar Stunden bestanden aus Tanzen mit Tamburinen, Wahrsagerei auf Kaffeesatz und einer detaillierten Durchsicht jedes einzelnen Codestücks. Der Administrator sagt, er habe alles getan. Die von betrügerischen Entwicklern geschriebene Anwendung funktioniert nicht, aber der Server funktioniert. Haben Sie Fragen an ihn? Am Ende einer Stunde bitten wir den Administrator, die Version der Bibliothek auf dem Produktionsserver in den Chat und das Bingo zu senden – es ist nicht die Version, die wir brauchen. Wir bitten den Administrator, die erforderliche Version zu installieren, erhalten jedoch als Antwort, dass er dies nicht tun kann, da diese Version im Paketmanager des Betriebssystems fehlt. Hier erinnert sich der Manager aus tiefstem Gedächtnis daran, dass ein anderer Administrator dieses Problem bereits gelöst hatte, indem er einfach die erforderliche Version von Hand zusammenstellte. Aber nein, bei uns wird das nicht passieren. Die Vorschriften verbieten es. Karl, wir sitzen hier schon mehrere Stunden, wie lange ist das Zeitlimit?! Wir bekommen einen weiteren Schock und beenden die Veröffentlichung irgendwie.

Akt 3, kurz
Dringendes Ticket, Schlüsselfunktionalität funktioniert bei einem der Benutzer in der Produktion nicht. Wir verbringen ein paar Stunden damit, herumzustöbern und nachzusehen. In einer Entwicklungsumgebung funktioniert alles. Es besteht klares Verständnis dafür, dass es eine gute Idee wäre, einen Blick in die PHP-FPM-Protokolle zu werfen. Zu diesem Zeitpunkt gab es im Projekt keine Protokollsysteme wie ELK oder Prometheus. Wir eröffnen ein Ticket für die Verwaltungsabteilung, damit diese Zugriff auf die PHP-FPM-Protokolle auf dem Server erhält. Hier müssen Sie verstehen, dass wir aus einem bestimmten Grund um Zugriff bitten. Erinnern Sie sich nicht an das schwarze Loch und die Administratoren, die rund um die Uhr beschäftigt sind? Wenn Sie sie bitten, sich die Protokolle selbst anzusehen, dann ist dies eine Aufgabe mit der Priorität „nicht in diesem Leben“. Das Ticket wurde erstellt und wir erhielten sofort eine Antwort vom Leiter der Verwaltungsabteilung: „Sie sollten keinen Zugriff auf Produktionsprotokolle benötigen, schreiben Sie ohne Fehler.“ Ein Vorhang.

Akt 4 und darüber hinaus
Wir sammeln immer noch Dutzende Probleme in der Produktion, die auf unterschiedliche Versionen von Bibliotheken, unkonfigurierte Software, unvorbereitete Serverlasten und andere Probleme zurückzuführen sind. Natürlich gibt es auch Codefehler. Wir werden die Administratoren nicht für alle Sünden verantwortlich machen, sondern nur einen weiteren typischen Vorgang für dieses Projekt erwähnen. Wir hatten ziemlich viele Hintergrundarbeiter, die über den Supervisor gestartet wurden, und einige Skripte mussten zu Cron hinzugefügt werden. Manchmal stellten dieselben Arbeiter ihre Arbeit ein. Die Belastung des Warteschlangenservers wuchs blitzschnell und traurige Benutzer blickten auf den sich drehenden Lader. Um solche Worker schnell zu reparieren, reichte es aus, sie einfach neu zu starten, aber auch dies konnte nur ein Administrator tun. Während eine solche Grundoperation durchgeführt wurde, konnte ein ganzer Tag vergehen. Hier ist natürlich anzumerken, dass korrupte Programmierer Arbeiter so schreiben sollten, dass sie nicht abstürzen, aber wenn sie doch abstürzen, wäre es schön zu verstehen, warum, was manchmal aufgrund des fehlenden Zugangs zur Produktion unmöglich ist natürlich und als Folge davon das Fehlen von Protokollen des Entwicklers.

Verklärung.
Nachdem wir das alles lange durchgehalten hatten, begannen wir gemeinsam mit dem Team, in eine für uns erfolgreichere Richtung zu steuern. Zusammenfassend: Vor welchen Problemen standen wir?

• Mangelnde Qualitätskommunikation zwischen Entwicklern und Verwaltungsabteilung
• Es stellt sich heraus(!), dass Administratoren überhaupt nicht verstehen, wie die Anwendung aufgebaut ist, welche Abhängigkeiten sie hat und wie sie funktioniert.
• Entwickler verstehen nicht, wie die Produktionsumgebung funktioniert, und können daher nicht effektiv auf Probleme reagieren.
• Der Bereitstellungsprozess dauert zu lange.
• Instabile Veröffentlichungen.

Was haben wir getan?
Für jede Version wurde eine Liste mit Versionshinweisen erstellt, die eine Liste der Arbeiten enthielt, die auf dem Server durchgeführt werden müssen, damit die nächste Version funktioniert. Die Liste enthielt mehrere Abschnitte, Arbeiten, die vom Administrator, der für die Veröffentlichung verantwortlichen Person und dem Entwickler durchgeführt werden sollten. Entwickler erhielten Non-Root-Zugriff auf alle Produktionsserver, was die Entwicklung im Allgemeinen und die Problemlösung im Besonderen beschleunigte. Entwickler haben auch ein Verständnis dafür, wie die Produktion funktioniert, in welche Dienste sie unterteilt ist, wo und wie viel Replikate kosten. Einige der Kampflasten sind klarer geworden, was sich zweifellos auf die Qualität des Codes auswirkt. Die Kommunikation während des Veröffentlichungsprozesses erfolgte im Chat eines der Instant Messenger. Erstens hatten wir ein Protokoll aller Aktionen und zweitens fand die Kommunikation in einer näheren Umgebung statt. Eine Historie von Aktionen hat es neuen Mitarbeitern mehr als einmal ermöglicht, Probleme schneller zu lösen. Es ist paradox, aber oft hat es den Administratoren selbst geholfen. Ich möchte es nicht mit Sicherheit sagen, aber es scheint mir, dass die Administratoren begonnen haben, besser zu verstehen, wie das Projekt funktioniert und wie es geschrieben ist. Manchmal haben wir sogar einige Details miteinander geteilt. Die durchschnittliche Release-Zeit wurde auf eine Stunde verkürzt. Manchmal waren wir in 30-40 Minuten fertig. Die Anzahl der Fehler ist deutlich zurückgegangen, wenn nicht sogar verzehnfacht. Natürlich haben auch andere Faktoren die Reduzierung der Release-Zeit beeinflusst, beispielsweise Autotests. Nach jeder Veröffentlichung begannen wir, Retrospektiven durchzuführen. Damit das gesamte Team eine Vorstellung davon hat, was neu ist, was sich geändert hat und was entfernt wurde. Leider kamen die Administratoren nicht immer zu ihnen, nun ja, Administratoren sind beschäftigt... Meine Arbeitszufriedenheit als Entwickler ist zweifellos gestiegen. Wenn Sie fast jedes Problem, das in Ihren Kompetenzbereich fällt, schnell lösen können, fühlen Sie sich an der Spitze. Später werde ich verstehen, dass wir bis zu einem gewissen Grad eine DevOps-Kultur eingeführt haben, natürlich nicht vollständig, aber schon der Beginn der Transformation war beeindruckend.

Dritte Geschichte
Start-up. Ein Administrator, kleine Entwicklungsabteilung. Bei meiner Ankunft bin ich eine absolute Null, weil... Ich habe nirgendwo Zugriff, außer per Post. Wir schreiben an den Admin und bitten um Zugang. Darüber hinaus gibt es Informationen darüber, dass ihm der neue Mitarbeiter bekannt ist und dass er Logins/Passwörter vergeben muss. Sie ermöglichen den Zugriff über das Repository und VPN. Warum Zugriff auf Wiki, Teamcity, Rundesk gewähren? Nutzlose Dinge für eine Person, die den gesamten Backend-Teil schreiben soll. Erst mit der Zeit erhalten wir Zugang zu einigen Tools. Die Ankunft stieß natürlich auf Misstrauen. Ich versuche, durch Chats und Leitfragen langsam ein Gefühl dafür zu bekommen, wie die Infrastruktur des Projekts funktioniert. Im Grunde erkenne ich nichts. Die Produktion ist die gleiche Blackbox wie zuvor. Darüber hinaus sind selbst die zum Testen verwendeten Bühnenserver eine Blackbox. Wir können nichts anderes tun, als dort einen Zweig von Git bereitzustellen. Wir können unsere Anwendung auch nicht wie .env-Dateien konfigurieren. Der Zugriff für solche Vorgänge wird nicht gewährt. Sie müssen darum betteln, dass in der Konfiguration Ihrer Anwendung auf dem Testserver eine Zeile geändert wird. (Es gibt eine Theorie, dass es für Administratoren wichtig ist, sich für das Projekt wichtig zu fühlen. Wenn sie nicht aufgefordert werden, Zeilen in den Konfigurationen zu ändern, werden sie einfach nicht benötigt.) Nun, wie immer, ist es nicht praktisch? Das wird schnell langweilig, nach einem direkten Gespräch mit dem Admin stellen wir fest, dass die Entwickler dazu geboren wurden, schlechten Code zu schreiben, von Natur aus inkompetente Individuen sind und es besser ist, sie von der Produktion fernzuhalten. Aber hier auch von Testservern, für alle Fälle. Der Konflikt eskaliert schnell. Es findet keine Kommunikation mit dem Admin statt. Die Situation wird dadurch verschärft, dass er allein ist. Das Folgende ist ein typisches Bild. Freigeben. Bestimmte Funktionen funktionieren nicht. Wir brauchen lange, um herauszufinden, was los ist, verschiedene Ideen von Entwicklern werden in den Chat eingeworfen, aber der Administrator geht in einer solchen Situation normalerweise davon aus, dass die Entwickler schuld sind. Dann schreibt er im Chat, warte, ich habe ihn korrigiert. Wenn wir gebeten werden, eine Geschichte mit Informationen über das Problem zu hinterlassen, erhalten wir giftige Ausreden. Stecken Sie Ihre Nase nicht dorthin, wo sie nicht hingehört. Entwickler müssen Code schreiben. Die Situation, wenn viele Körperbewegungen in einem Projekt durch eine einzige Person erfolgen und nur sie Zugriff hat, um die Operationen durchzuführen, die jeder benötigt, ist äußerst traurig. Eine solche Person ist ein schrecklicher Engpass. Wenn Devops-Ideen darauf abzielen, die Markteinführungszeit zu verkürzen, dann sind solche Leute der schlimmste Feind von Devops-Ideen. Leider schließt sich hier der Vorhang.

PS: Nachdem ich in Chats mit Leuten ein wenig über Entwickler vs. Administratoren gesprochen hatte, traf ich Leute, die meinen Schmerz teilten. Aber es gab auch diejenigen, die sagten, dass sie so etwas noch nie erlebt hätten. Auf einer DevOps-Konferenz fragte ich Anton Isanin (Alfa Bank), wie sie mit dem Problem des Engpasses in Form von Admins umgingen, worauf er sagte: „Wir haben sie durch Knöpfe ersetzt.“ Übrigens Podcast mit seiner Teilnahme. Ich würde gerne glauben, dass es viel mehr gute Admins als Feinde gibt. Und ja, das Bild am Anfang ist eine echte Entsprechung.

Quelle: www.habr.com