Das Traurigste an der aktuellen Situation ist, dass die IT nach und nach zu einer Branche wird, in der es bei der Anzahl der Verantwortlichkeiten pro Person ĂŒberhaupt kein Wort âStoppâ gibt.
Beim Lesen von Stellenangeboten sieht man manchmal sogar nicht 2-3 Personen, sondern ein ganzes Unternehmen in einer Person, alle haben es eilig, die technische Verschuldung wĂ€chst, das alte Erbe sieht vor dem Hintergrund neuer Produkte wie Perfektion aus, weil es zumindest so ist verfĂŒgt ĂŒber ein Dock und Kommentare im Code, neue Produkte werden mit Lichtgeschwindigkeit geschrieben, können daher jedoch nach dem Schreiben noch ein Jahr lang nicht verwendet werden, und oft bringt dieses Jahr keinen Gewinn, auĂerdem sind die Kosten fĂŒr Die Cloud ist höher als der Umsatz des Dienstes. Das Geld der Investoren flieĂt in die Aufrechterhaltung eines Dienstes, der noch nicht funktioniert, aber bereits als Worker fĂŒr das Netzwerk freigegeben wurde.
Als Beispiel: ein bekanntes Unternehmen, dessen Remaster eines alten Spiels die niedrigsten Bewertungen in der Geschichte der Branche erhielt. Ich war einer von denen, die dieses Produkt gekauft haben, aber selbst jetzt funktioniert dieses Produkt schrecklich und hĂ€tte theoretisch noch nicht in dieser Form veröffentlicht werden dĂŒrfen. RĂŒckerstattungen, Bewertungsverluste, eine groĂe Anzahl von Benutzersperren in den Foren wegen Beschwerden ĂŒber die Arbeit von Diensten. Die Anzahl der Patches ist nicht erfreulich, sondern erschreckend, aber dennoch ist das Produkt nicht verwendbar. Wenn dieser Ansatz bei einem Unternehmen, das sich seit 91 entwickelt, zu solchen Ergebnissen fĂŒhrt, ist die Situation fĂŒr Unternehmen, die gerade erst am Anfang stehen, noch schlimmer.
Aber wir haben uns die Ergebnisse dieses Ansatzes seitens des Nutzers des Dienstes angesehen und schauen uns nun die Probleme an, die die Mitarbeiter haben.
Ich höre oft die Aussage, dass es keine DevOps-Teams geben sollte, dass dies eine Methodik usw. sei, aber das Problem ist, dass Unternehmen aus irgendeinem Grund aufgehört haben, nach Noks, DBAs, Infruktoren und Build-Ingenieuren zu suchen â jetzt ist alles ein DevOps-Ingenieur in einer einzigen Person. NatĂŒrlich gibt es in einzelnen Unternehmen immer noch solche offenen Stellen, aber es werden immer weniger. Viele nannten diese Entwicklung, ich persönlich sehe darin eine Verschlechterung, es ist unmöglich, in allen Bereichen einen guten Wissensstand aufrechtzuerhalten und gleichzeitig nicht mehr als 8 Stunden zu arbeiten. NatĂŒrlich sind das Fantasien. In der RealitĂ€t sind viele IT-Mitarbeiter gezwungen, sowohl 12 als auch 14 Stunden zu arbeiten, von denen 8 bezahlt werden. Und oft ohne freie Tage, weil âmir eine Aufgabe gegeben wurde, es keine Docks oder Kurven gibt und der Service Geld kostetâ. und fĂŒr 1 in der Cloud können Sie grundsĂ€tzlich in ein paar Monaten kein Gehalt bekommen, insbesondere wenn Sie auf IP-Basis arbeiten. TatsĂ€chlich verlieren wir in der Wirtschaft das Wort, zusammen mit der Aufgabentrennung, ich bin zunehmend mit der Tatsache konfrontiert, dass Manager in Entwicklungsprozesse einsteigen, ohne ĂŒberhaupt etwas zu verstehen, sie verwechseln GeschĂ€ftsdaten und Anwendungsbetrieb, was zu Chaos fĂŒhrt beginnt.
Wenn das Chaos beginnt, möchte das Unternehmen den Schuldigen finden, und hier braucht es einen Universalschuldigen. Es ist schwierig, die Schuld auf mehr als 10 Personen zu schieben. Daher vereinen Manager ihre Positionen, denn je mehr Aufgaben ein Spezialist hat, desto einfacher ist es seine FahrlĂ€ssigkeit beweisen. Und unter den Bedingungen von Agile ist das Finden der âSchuldigenâ und PrĂŒgel die Grundlage dieser Methodik fĂŒr die GeschĂ€ftsabwicklung im Management. Agile ist aus der IT schon lange nicht mehr wegzudenken und sein Hauptkonzept ist zur Anforderung tĂ€glicher Ergebnisse geworden. Das Problem besteht darin, dass ein hochspezialisierter Spezialist nicht immer ĂŒber ein tĂ€gliches Ergebnis verfĂŒgt, wodurch die Berichterstattung schwieriger wird. Dies ist ein weiterer Grund, warum Unternehmen âSpezialisten fĂŒr allesâ wollen. Aber der Hauptgrund ist natĂŒrlich die Gehaltsabrechnung â er ist der Hauptgrund fĂŒr alle Ănderungen, um der Zulage willen haben die Leute zugestimmt, fĂŒr sich und diesen Kerl zu arbeiten. Aber am Ende ist es, wie in anderen Bereichen auch, einfach zu einer Verpflichtung geworden, fĂŒr eine geringere Bezahlung fĂŒr eine gröĂere Anzahl erbrachter Dienstleistungen.
Nun sieht man oft sogar Artikel, dass Entwickler bereits in der Lage sein sollten, bereitzustellen, sich neben einem DevOps-Ingenieur mit der Infrastruktur befassen sollten, aber wozu fĂŒhrt das? Das ist richtig â zu einem RĂŒckgang der QualitĂ€t der Dienste, zu einem RĂŒckgang der QualitĂ€t der Entwickler. BuchstĂ€blich vor 2 Tagen habe ich dem Entwickler erklĂ€rt, dass man von verschiedenen Hosts aus schreiben und lesen kann, und sie haben mir mit Schaum vor dem Mund bewiesen, dass sie so etwas noch nie gesehen haben, hier ist es in den Einstellungen fĂŒr Host, Port, Datenbank, Benutzer, Passwort und das wars .... Aber der Entwickler weiĂ, wie man Bereitstellungen startet, Yamls schreibt ... Aber er vergisst bereits Unit-Tests und Kommentare im Code.
Als Ergebnis sehen wir Folgendes: stĂ€ndige Bearbeitung, Suche nach Lösungen fĂŒr Probleme auĂerhalb der Arbeitszeit, stĂ€ndige Schulung am Wochenende und nicht um das Einkommen zu steigern, sondern um uns ĂŒber Wasser zu halten. Entwickler sind gezwungen, einem DevOps-Ingenieur bei CI/CD zu helfen, und wenn der Entwickler keine Zeit hat, fĂ€ngt er an, den Mund zu halten, und Manager beginnen, Gehirne zu kompostieren, und wenn dies nicht dazu beitrĂ€gt, den Wunsch nach Ăberstunden zu steigern, dann bewerben Sie sich Strafen und BuĂgelder, die Person sucht einen neuen Job und hinterlĂ€sst technische Schulden in der GröĂe des Everest, wodurch die Schulden auch bei den Entwicklern zu wachsen beginnen. Sie sind gezwungen, Code mit weniger Refactoring zu schreiben, um Zeit zu haben, entweder einem alten oder einem neuen DevOps-Ingenieur zu helfen, und Manager sind mit allem ziemlich zufrieden, weil es einen Schuldigen gibt und er sofort erkannt werden kann, was bedeutet, dass dies der Fall ist Die Hauptregel im agilen Management wird eingehalten, der Schuldige wird gefunden, die Ergebnisse seiner Auspeitschung sind sichtbar.
Einmal hielt ich bei ITGM einen Vortrag zum Thema âWenn wir lernen, Nein zu sagenâ â die Ergebnisse waren sehr aufschlussreich. Viele Menschen glauben, dass dieses Wort tabu ist, und solange wir nicht damit aufhören, so zu denken, werden die Probleme nur noch gröĂer.
Hat mich teilweise dazu inspiriert, diesen Artikel zu schreiben., aber ich werde es spÀter vielleicht in weniger angenehmen Worten schreiben.
An der Umfrage können nur registrierte Benutzer teilnehmen. bitte.
Haben Sie bei der Arbeit erlebt, dass der Arbeitgeber versucht hat, mehrere Personen durch Sie zu ersetzen?
65,6%Ja, ich stoĂe regelmĂ€Ăig darauf
5,4%Ja, 1 Mal aufgetreten15
15,4%Nicht bemerkt43
13,6%Ich bin ein Workaholic, ich mache selbst Ăberstunden38
279 Benutzer haben abgestimmt. 34 Benutzer enthielten sich der Stimme.
Source: habr.com
