{"id":89062,"date":"2020-07-18T07:41:57","date_gmt":"2020-07-18T05:41:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/devops-ili-kak-my-teryaem-zarabotnuyu-platu-i-budushhee-it-otrasli"},"modified":"2020-07-18T07:41:57","modified_gmt":"2020-07-18T05:41:57","slug":"devops-ili-kak-my-teryaem-zarabotnuyu-platu-i-budushhee-it-otrasli","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/devops-ili-kak-my-teryaem-zarabotnuyu-platu-i-budushhee-it-otrasli","title":{"rendered":"DevOps oder wie wir Geh\u00e4lter und die Zukunft der IT-Branche verlieren","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Das Traurigste an der heutigen Situation ist, dass IT langsam zu einer Branche wird, in der es \u00fcberhaupt kein \"Stop\" f\u00fcr die Anzahl der Aufgaben f\u00fcr eine Person gibt. <\/p>\n

Wenn man Stellenangebote liest, sieht man manchmal nicht nur 2-3 Personen, sondern ein ganzes Unternehmen in einer Person. Alle sind in Eile, die technische Schuld w\u00e4chst, das alte Legacy-System sieht im Vergleich zu neuen Produkten perfekt aus, weil es zumindest Dokumentation und Kommentare im Code gibt. Neue Produkte werden mit Lichtgeschwindigkeit geschrieben, aber letztendlich kann man sie ein Jahr nach ihrer Erstellung nicht nutzen, und oft bringt dieses Jahr keinen Gewinn. Dar\u00fcber hinaus sind die Ausgaben f\u00fcr \"Cloud\" h\u00f6her als die Verk\u00e4ufe des Dienstes. Das Geld der Investoren flie\u00dft in die Unterhaltung eines noch nicht funktionierenden Dienstes, der jedoch bereits als betriebsbereit in die Welt gesetzt wurde.<\/a><\/noindex>
\nEin Beispiel: Ein bekanntes Unternehmen, dessen Remaster eines alten Spiels die niedrigsten Bewertungen in der Geschichte der Branche erhalten hat. Ich war einer derjenigen, die dieses Produkt gekauft haben, aber selbst jetzt funktioniert dieses Produkt schrecklich und sollte eigentlich nicht in dieser Form verkauft werden. R\u00fcckzahlungen, sinkende Bewertungen, eine enorme Anzahl von Bans f\u00fcr Benutzer in Foren aufgrund von Beschwerden \u00fcber die Dienste. Die Anzahl der Patches ist nicht bewundernswert, sondern erschreckend, aber trotzdem \u2013 das Produkt ist nicht nutzbar. Wenn dieser Ansatz bei einem Unternehmen, das seit 1991 entwickelt, solche Ergebnisse liefert, ist die Situation bei Unternehmen, die erst anfangen, noch schlimmer.<\/p>\n

Doch nun haben wir die Ergebnisse eines solchen Ansatzes aus der Sicht des Nutzers des Dienstes betrachtet; lassen Sie uns nun die Probleme ansehen, die bei den Mitarbeitern aufgetreten sind. <\/p>\n

Ich h\u00f6re oft die Behauptung, dass es keine DevOps-Teams geben sollte, dass es sich um eine Methodik handelt und so weiter. Aber das Problem ist, dass Unternehmen anscheinend aufgeh\u00f6rt haben, nach Nocke, DBA, Infrastrukturmitarbeitern und Build-Ingenieuren zu suchen \u2013 jetzt ist das alles ein einzelner DevOps-Ingenieur. Nat\u00fcrlich gibt es in einigen Unternehmen solche Stellenanzeigen noch, aber es werden immer weniger. Viele nennen das eine Entwicklung, ich sehe pers\u00f6nlich darin eine Degression. Es ist unm\u00f6glich, in allen Bereichen ein hohes Wissensniveau aufrechtzuerhalten und dabei zu schaffen, nicht mehr als 8 Stunden zu arbeiten. Nat\u00fcrlich \u2013 das sind Fantasien. In der Realit\u00e4t sind viele ITler gezwungen, 12 oder 14 Stunden zu arbeiten, von denen 8 bezahlt werden. Oft ohne Wochenenden, weil \u201eich habe eine Aufgabe, die Dokumentation ist nicht vorhanden oder fehlerhaft, und der Service kostet noch Geld\u201c, und f\u00fcr einen Fehler in der Cloud kann man im Grunde genommen monatelang kein Gehalt bekommen, besonders wenn man als Einzelunternehmer arbeitet. Faktisch verlieren wir das Wort im Gesch\u00e4ftsleben, zusammen mit der Aufteilung der Verantwortlichkeiten. Ich stelle immer h\u00e4ufiger fest, dass Manager in die Entwicklungsprozesse eingreifen, ohne \u00fcberhaupt etwas davon zu verstehen. Sie verwechseln Gesch\u00e4ftsdaten und die Funktionweise der Anwendung, was letztendlich zu Chaos f\u00fchrt. <\/p>\n

Wenn das Chaos beginnt, m\u00f6chte das Gesch\u00e4ft den Schuldigen finden, und hier braucht man einen universellen Schuldigen. Es ist schwierig, die Schuld auf mehr als 10 Personen zu werfen, also vereinheitlichen die Manager die Positionen, denn je mehr Pflichten ein Spezialist hat, desto einfacher ist es, seine Nachl\u00e4ssigkeit nachzuweisen. Unter den Bedingungen von Agile ist das Finden eines \"Schuldigen\" und dessen Bestrafung die Grundlage dieser Methodik im Management. Agile ist l\u00e4ngst \u00fcber die IT hinaus gewachsen, und sein Hauptkonzept ist jetzt das Erfordernis nach t\u00e4glichen Ergebnissen. Das Problem ist, dass ein Spezialist mit einer engen Spezialisierung nicht immer ein t\u00e4gliches Ergebnis liefern kann, was bedeutet, dass es schwieriger wird, einen Bericht zu erstatten, und das ist ein weiterer Grund, warum das Gesch\u00e4ft \"Spezialisten f\u00fcr alles\" m\u00f6chte. Aber der Hauptgrund ist nat\u00fcrlich die Lohnkosten \u2013 sie sind der Hauptgrund f\u00fcr alle Ver\u00e4nderungen. Aus diesem Grund waren die Menschen bereit, f\u00fcr sich und f\u00fcr den anderen zu arbeiten. Am Ende ist es, wie in anderen Bereichen, einfach zur Pflicht geworden, f\u00fcr eine geringere Bezahlung eine gr\u00f6\u00dfere Anzahl von Dienstleistungen zu erbringen. <\/p>\n

Aktuell kann man oft sogar Artikel sehen, die besagen, dass Entwickler auch deployen und sich zusammen mit dem DevOps-Ingenieur um die Infrastruktur k\u00fcmmern sollten. Aber was f\u00fchrt das zu? Richtig \u2013 zu einem R\u00fcckgang der Servicequalit\u00e4t und der Qualifikation der Entwickler. Erst vor 2 Tagen habe ich einem Entwickler erkl\u00e4rt, dass man von verschiedenen Hosts aus lesen und schreiben kann, und mir wurde hitzig erkl\u00e4rt, dass sie so etwas noch nie gesehen haben. Es gibt doch die Einstellungen mit orm host, port, db, user, password und das war's\u2026 Aber daf\u00fcr kann der Entwickler Deployments starten und YAMLs schreiben\u2026 Vergisst aber bereits die Unit-Tests und Kommentare im Code.<\/p>\n

Am Ende sehen wir Folgendes: st\u00e4ndige \u00dcberstunden, die Suche nach L\u00f6sungen f\u00fcr Probleme au\u00dferhalb der Arbeitszeit, st\u00e4ndiges Lernen am Wochenende, und das nicht, um das Einkommen zu steigern, sondern um sich \u00fcber Wasser zu halten. Entwickler sind gezwungen, dem DevOps-Ingenieur bei CI\/CD zu helfen, und wenn der Entwickler keine Zeit hat, ist er \u00fcberfordert, und die Manager fangen an, ihm Druck zu machen. Wenn das nicht hilft, um die Bereitschaft zu erh\u00f6hen, \u00dcberstunden zu machen, werden Sanktionen und Strafen verh\u00e4ngt, und die Person sucht sich eine neue Arbeitsstelle, wobei sie einen technischen Schuldenberg hinterl\u00e4sst, der so hoch ist wie der Everest. Infolgedessen beginnt die Schuldenlast auch bei den Entwicklern zu wachsen, da sie gezwungen sind, Code mit weniger Refactoring zu schreiben, um dem alten oder neuen DevOps-Ingenieur rechtzeitig zu helfen. Die Manager sind damit jedoch vollkommen zufrieden, denn der Schuldige ist vorhanden und sofort sichtbar, und somit ist die Grundregel des Agile-Managements erf\u00fcllt: der Schuldige ist gefunden, die Ergebnisse seiner Bestrafung sind sichtbar. <\/p>\n

Einst habe ich auf ITGM mit einem Vortrag \u201eWann lernen wir, \u201aNein\u2018 zu sagen\u201c referiert \u2013 die Ergebnisse waren sehr aufschlussreich. Eine enorme Anzahl von Menschen betrachtet dieses Wort als Tabu, und solange wir das nicht \u00e4ndern, werden die Probleme nur zunehmen.<\/p>\n

Teilweise wurde ich zu diesem Artikel inspiriert durch diesen Artikel<\/a><\/noindex>, aber ich werde ihn m\u00f6glicherweise sp\u00e4ter in weniger umschweifenden Begriffen ausformulieren.<\/p>\n

Nur registrierte Benutzer k\u00f6nnen an der Umfrage teilnehmen. Bitte einloggen<\/a><\/noindex>.<\/p>\n

Haben Sie schon einmal erlebt, dass Ihr Arbeitgeber versucht hat, Sie durch mehrere Personen zu ersetzen?<\/h2>\n