Es ist bekannt, dass die Kompetenz eines CTOs nur beim zweiten Mal, dass er diese Rolle übernimmt, geprüft wird. Denn es ist etwas ganz anderes, mehrere Jahre in einem Unternehmen zu arbeiten, mit ihm zu evolvieren und im gleichen kulturellen Kontext allmählich mehr Verantwortung zu übernehmen. Und etwas ganz anderes ist es, direkt als Technischer Direktor in ein Unternehmen mit einem Erbe von Legacy-Problemen und vielen Herausforderungen zu kommen, die sorgfältig unter den Teppich gekehrt wurden.

In diesem Sinne ist die Erfahrung von Leon Feier, die er geteilt hat, DevOpsConf, nicht unbedingt einzigartig, aber multipliziert mit seiner Erfahrung und der Anzahl der verschiedenen Rollen, die er in 20 Jahren angenommen hat, sehr nützlich. Im Folgenden finden Sie die Chronologie der Ereignisse in den letzten 90 Tagen und viele Geschichten, über die man lächeln kann, wenn sie jemand anderem widerfahren, aber die nicht so lustig sind, wenn man ihnen selbst gegenübersteht.

Leon erzählt sehr lebhaft auf Russisch, daher empfehle ich, das Video anzuschauen, wenn Sie 35-40 Minuten Zeit haben. Die Textversion finden Sie unten zur Zeitersparnis.

Die erste Version des Berichts war eine gut strukturierte Beschreibung der Arbeit mit Menschen und Prozessen, die nützliche Empfehlungen enthielt. Aber sie gab nicht alle Überraschungen wieder, die während des Weges auftraten. Daher habe ich das Format geändert und die Probleme, die in der neuen Firma vor mir auftauchten, wie ein Geist aus der Dose und die Methoden zu deren Lösung in chronologischer Reihenfolge dargelegt.

Einen Monat vor

Wie viele gute Geschichten begann diese mit Alkohol. Wir saßen mit Bekannten in einer Bar, und wie es in der IT-Branche üblich ist, klagte jeder über seine Probleme. Einer von ihnen hatte gerade den Job gewechselt und erzählte von seinen Schwierigkeiten sowohl mit der Technik als auch mit den Menschen und dem Team. Je länger ich zuhörte, desto mehr wurde mir klar, dass er mich einfach anheuern müsste, denn genau solche Probleme hatte ich in den letzten 15 Jahren gelöst. Das sagte ich ihm, und am nächsten Tag trafen wir uns bereits in einem Arbeitsumfeld. Die Firma hieß Teaching Strategies.

Teaching Strategies ist führend auf dem Markt für Bildungsprogramme für sehr kleine Kinder — von der Geburt bis zu drei Jahren. Die traditionelle „Papier“-Firma besteht seit etwa 40 Jahren, und die digitale SaaS-Version der Plattform gibt es seit 10 Jahren. Relativ neu war der Prozess der Anpassung der digitalen Technologie an die Standards des Unternehmens. Die „neue“ Version wurde 2017 gestartet und war fast wie die alte, nur dass sie schlechter funktionierte.

Das Interessanteste ist, dass der Traffic bei diesem Unternehmen sehr vorhersehbar ist - Tag für Tag, Jahr für Jahr kann man sehr genau vorhersagen, wie viele Menschen kommen und wann. Zum Beispiel gehen zwischen 13 und 15 Uhr alle Kinder in den Kindergärten schlafen, während die Lehrer anfangen, Informationen einzugeben. Und das passiert jeden Tag, außer am Wochenende, denn am Wochenende arbeitet fast niemand.

Um ein wenig vorzugreifen, ich begann meine Arbeit in der Zeit des größten jährlichen Traffics, was aus verschiedenen Gründen interessant ist.

Die Plattform, die wie aus dem Nichts nur zwei Jahre alt war, hatte einen eigenartigen Tech-Stack: ColdFusion & SQL Server 2008. ColdFusion, falls Sie es nicht wissen, das wohl kaum jemand weiß, ist eine Art Enterprise-PHP, das in den mittleren 90er Jahren herauskam, und seitdem habe ich nicht mehr davon gehört. Außerdem waren Ruby, MySQL, PostgreSQL, Java, Go und Python im Spiel. Aber das Hauptmonolith lief auf ColdFusion und SQL Server.

Probleme

Je mehr ich mit den Mitarbeitern des Unternehmens über die Arbeit und die aufgetretenen Probleme sprach, desto mehr wurde mir klar, dass die Probleme nicht nur technischer Natur waren. Okay, die Technologie war alt – und wir haben auch nicht auf so etwas gearbeitet, aber es gab Probleme im Team und in den Prozessen, und das Unternehmen begann es zu verstehen.

Traditionell saßen die Techniker in der Ecke und arbeiteten an irgendetwas. Doch immer mehr Geschäfte begannen, genau über die digitale Version zu laufen. Deshalb gab es im Unternehmen im letzten Jahr vor meinem Arbeitsbeginn neue: einen Vorstand, einen CTO, einen CPO und einen QA-Direktor. Das Unternehmen begann also, in den technologischen Bereich zu investieren.

Die Spuren des schweren Erbes waren nicht nur in den Systemen zu finden. Im Unternehmen gab es Legacy-Prozesse, Legacy-Menschen und Legacy-Kultur. All das musste geändert werden. Ich dachte, dass mir bestimmt nicht langweilig werden würde, und entschied mich, es auszuprobieren.

Zwei Tage vor

Zwei Tage vor dem Beginn meiner neuen Arbeit kam ich ins Büro, füllte die letzten Unterlagen aus, stellte mich dem Team vor und stellte fest, dass das Team gerade ein Problem hatte. Es bestand darin, dass die durchschnittliche Ladezeit der Seiten auf 4 Sekunden gestiegen war, also doppelt so hoch.

Laut dem Diagramm war offensichtlich etwas passiert, doch was unklar blieb. Es stellte sich heraus, dass das Problem in der Netzwerkverzögerung im Rechenzentrum lag: 5 ms Verzögerung im Rechenzentrum wurden für die Benutzer zu 2 Sekunden. Warum das passiert ist, wusste ich nicht, aber jedenfalls war klar, dass das Problem im Rechenzentrum lag.

Tag Eins

Zwei Tage sind vergangen, und an meinem ersten Arbeitstag stellte ich fest, dass das Problem nicht verschwunden war.

Zwei Tage lang luden die Seiten für die Benutzer im Durchschnitt vier Sekunden lang. Ich fragte, ob man das Problem gefunden hatte.

— Ja, wir haben ein Ticket eröffnet.
— Und?
— Nun, sie haben uns noch nicht geantwortet.

Hier wurde mir klar, dass alles, was mir zuvor erzählt wurde, nur die kleine Spitze des Eisbergs war, mit dem wir kämpfen mussten.

Es gibt ein gutes Zitat, das in diesem Fall sehr passend ist:

„Manchmal muss man die Organisation verändern, um die Technologie zu ändern.“

Da ich jedoch zur geschäftigsten Zeit des Jahres angefangen hatte, musste ich beide Lösungsmöglichkeiten in Betracht ziehen: die schnelle und die langfristige. Und anfangen mit dem, was gerade jetzt kritisch ist.

Dritter Tag

Also, die Ladezeit beträgt vier Sekunden, und von 13 bis 15 Uhr gibt es die größten Spitzen.

Am dritten Tag sah die Ladegeschwindigkeit in diesem Zeitraum so aus:

Aus meiner Sicht funktionierte überhaupt nichts. Aus der Sicht aller anderen funktionierte es etwas langsamer als gewöhnlich. Aber so einfach ist es nicht – das ist ein ernsthaftes Problem.

Ich versuchte, das Team zu überzeugen, doch sie sagten mir, dass einfach mehr Server nötig seien. Das ist natürlich eine Lösung des Problems, aber nicht immer die einzige und effektivste. Ich fragte, warum die Server nicht ausreichen und welches Verkehrsvolumen wir haben. Ich extrapolierte die Daten und erhielt, dass wir etwa 150 Anfragen pro Sekunde haben, was im Prinzip im vernünftigen Rahmen liegt.

Aber man darf nicht vergessen, dass man, bevor man die richtige Antwort bekommt, die richtige Frage stellen muss. Meine nächste Frage war: Wie viele Frontend-Server haben wir? Die Antwort überraschte mich ein wenig – wir hatten 17 Frontend-Server!

— Ich möchte nicht unhöflich sein, aber 150 geteilt durch 17 ergibt etwa 8? Wollt ihr sagen, dass jeder Server 8 Anfragen pro Sekunde verarbeitet, und wenn wir morgen 160 Anfragen pro Sekunde haben, brauchen wir dann noch 2 Server?

Natürlich brauchten wir keine zusätzlichen Server. Die Lösung lag im Code selbst und war offensichtlich:

var currentClass = classes.getCurrentClass();
return currentClass;

Es gab eine Funktion getCurrentClass(), denn alles auf der Website arbeitet im Kontext der Klasse – das ist richtig. Und auf diese eine Funktion kamen auf jeder Seite über 200 Anfragen.

Die Lösung war also sehr einfach, man musste nichts umschreiben: einfach nicht dieselbe Information mehrfach anfordern.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

Ich war sehr erfreut, denn ich dachte, dass ich am dritten Tag das Hauptproblem gefunden hätte. Wie naiv von mir, es war nur eines von vielen Problemen.

Die Lösung dieses ersten Problems hat den Zeitplan jedoch viel weiter nach unten verzogen.

Gleichzeitig haben wir an anderen Optimierungen gearbeitet. Es gab viel, was repariert werden konnte. Zum Beispiel entdeckte ich am selben dritten Tag, dass es tatsächlich einen Cache im System gab (zuerst dachte ich, alle Anfragen kämen sofort aus der Datenbank). Wenn ich an einen Cache denke, stelle ich mir normalerweise Redis oder Memcached vor. Aber nur ich dachte so, denn für die Cache-Speicherung in diesem System wurden MongoDB und SQL Server verwendet – die gleiche Datenbank, aus der wir gerade die Daten gelesen hatten.

Tag zehn

In der ersten Woche kümmerte ich mich um Probleme, die sofort gelöst werden mussten. Irgendwann in der zweiten Woche kam ich zum ersten Mal zu einem Stand-up, um mit dem Team zu sprechen, zu sehen, was vor sich ging und wie der gesamte Prozess verlief.

Wieder gab es interessante Neuigkeiten. Das Team bestand aus: 18 Entwicklern; 8 Testern; 3 Managern; 2 Architekten. Und alle nahmen an den gemeinsamen Ritualen teil, also kamen jeden Morgen mehr als 30 Personen zum Stand-up und erzählten, was sie gemacht hatten. Offensichtlich dauerte das Treffen nicht 5 oder 15 Minuten. Niemand hörte einander zu, weil alle an verschiedenen Systemen arbeiteten. In dieser Form waren 2-3 Tickets pro Stunde bei der Grooming-Session bereits ein gutes Ergebnis.

Das erste, was wir taten, war, das Team in mehrere Gruppen nach Produktlinien aufzuteilen. Für verschiedene Sektionen und Systeme bildeten wir separate Teams mit Entwicklern, Testern, Produktmanagern und Business Analysts.

Das Ergebnis war:

• Reduzierung der Stand-ups und Meetings.
• Produktwissen.
• Eigenverantwortung. Früher, als die Leute ständig zwischen den Systemen herumwechselten, wussten sie, dass sie wahrscheinlich nicht selbst an ihren Bugs arbeiten würden, sondern jemand anderes.
• Zusammenarbeit zwischen den Gruppen. Es ist nicht zu leugnen, dass QA und Programmierer zuvor nicht viel kommuniziert hatten, der Produktmanager machte sein eigenes Ding usw. Jetzt hatten sie einen gemeinsamen Verantwortungspunkt.

In erster Linie konzentrierten wir uns auf Effizienz, Leistung und Qualität – genau diese Probleme versuchten wir durch die Transformation des Teams zu lösen.

Tag elf

Im Prozess der Umstrukturierung des Teams entdeckte ich, wie man zählt StoryPunkte. 1 SP entsprach einem Tag, und jedes Ticket enthielt sowohl SP für die Entwicklung als auch für QA, also mindestens 2 SP.

Wie habe ich das entdeckt?

Wir fanden einen Fehler: In einem der Berichte, in dem das Start- und Enddatum des benötigten Berichts eingegeben wird, wurde der letzte Tag nicht berücksichtigt. Das heißt, irgendwo in der Abfrage stand nicht <=, sondern einfach <. Mir wurde gesagt, dass dies drei Story Points entspricht, also 3 Tage.

Daraufhin haben wir:

• Das Bewertungssystem für Story Points überarbeitet. Jetzt erreichen kleine Bugfixes, die schnell durch das System geschleust werden, schneller den Benutzer.
• Begonnen, verwandte Tickets für Entwicklung und Test zusammenzufassen. Zuvor war jedes Ticket, jeder Fehler ein geschlossenes Ökosystem, das an nichts anderes gebunden war. Die Änderung von drei Buttons auf einer Seite konnte drei verschiedene Tickets mit drei unterschiedlichen QA-Prozessen statt eines automatischen Tests auf der Seite sein.
• Begannen, mit den Entwicklern an der Einschätzung des Arbeitsaufwands zu arbeiten. Drei Tage für die Änderung eines Buttons – das ist nicht lustig.

Tag zwanzig

Irgendwann zur Mitte des ersten Monats hatte sich die Situation ein wenig stabilisiert, ich hatte herausgefunden, was hauptsächlich geschah, und begann bereits, in die Zukunft zu schauen und über langfristige Lösungen nachzudenken.

Die Sicherstellung der Kompatibilität mit dem Festplattenformat des git-Repositories (ohne die Kompatibilität mit den Werkzeugen zu gewährleisten);

• Plattform im Management. Hunderte von Anfragen auf jeder Seite – das ist nicht ernsthaft.
• Vorhersehbare Trends. Es gab sporadische Verkehrsspitzen, die auf den ersten Blick nicht mit anderen Metriken korrelierten – es musste herausgefunden werden, warum dies geschah und wie man es vorhersagen kann.
• Plattformerweiterung. Das Geschäft wächst ständig, immer mehr Benutzer kommen, der Verkehr nimmt zu.

Früher wurde oft gesagt: „Lass uns alles auf [Sprache/Framework] neu schreiben, dann wird alles besser funktionieren!“

In den meisten Fällen funktioniert das nicht, gut, wenn das Neu Geschriebene überhaupt funktioniert. Daher mussten wir einen Fahrplan erstellen – eine konkrete Strategie, die Schritt für Schritt erläutert, wie die Geschäftsziele erreicht werden (was wir tun werden und wozu), die:

• die Mission und Ziele des Projekts widerspiegelt;
• die Hauptziele priorisiert;
• enthält eine Grafik ihrer Erreichung.

Bis zu diesem Zeitpunkt hatte niemand mit dem Team darüber gesprochen, zu welchem Zweck Änderungen vorgenommen werden. Dafür sind die richtigen Erfolgskriterien erforderlich. Zum ersten Mal in der Unternehmensgeschichte haben wir KPIs für das technische Team festgelegt, und diese Kriterien sind an die organisatorischen angekettet.

Das heißt, die organisatorischen KPIs werden von den Teams unterstützt, während die Team-KPIs dann von individuellen KPIs unterstützt werden. Andernfalls, wenn die technologischen KPIs nicht mit den organisatorischen übereinstimmen, zieht jeder das Bettlaken an sich.

Ein Beispiel für einen organisatorischen KPI ist die Erhöhung des Marktanteils durch neue Produkte.

Wie können wir das Ziel unterstützen, mehr neue Produkte zu haben?

• Erstens wollen wir mehr Zeit für die Entwicklung neuer Produkte aufwenden, anstatt Defekte zu beheben. Das ist eine logische Entscheidung, die leicht messbar ist.
• Zweitens wollen wir das Volumen der Transaktionen erhöhen, denn je größer der Marktanteil, desto mehr Nutzer und somit mehr Traffic.

Die individuellen KPIs, die innerhalb der Gruppe umgesetzt werden können, werden beispielsweise dort angesiedelt, wo die Hauptdefekte auftreten. Wenn wir uns auf diesen Bereich konzentrieren, können wir die Anzahl der Defekte erheblich reduzieren, was wiederum die Zeit für die Entwicklung neuer Produkte und die Unterstützung der organisatorischen KPIs erhöht.

Somit sollte jede Entscheidung, einschließlich der Neuprogrammierung von Code, bestimmte Ziele unterstützen, die das Unternehmen uns gesetzt hat (Wachstum der Organisation, neue Funktionen, Personalaufstockung).

Während dieses Prozesses wurde eine interessante Tatsache festgestellt, die nicht nur für die Techniker, sondern für das gesamte Unternehmen neu war: Alle Tickets sollten mindestens auf einen KPI ausgerichtet sein. Das heißt, wenn ein Produktmanager sagt, dass er eine neue Funktion einführen möchte, sollte die erste Frage lauten: „Welchen KPI unterstützt diese Funktion?“ Wenn es keinen gibt, tut mir leid – das scheint eine unnötige Funktion zu sein.

Der dreißigste Tag

Am Ende des Monats stellte ich noch einen weiteren Aspekt fest: Niemand aus meinem Ops-Team hatte jemals die Verträge gesehen, die wir mit unseren Kunden abschließen. Sie können fragen, warum man die Verträge sehen sollte.

• Erstens, weil in den Verträgen die SLAs festgelegt sind.
• Zweitens, SLA sind alle unterschiedlich. Jeder Kunde brachte seine eigenen Anforderungen mit, und die Vertriebsabteilung unterzeichnete ohne hinzusehen.

Ein weiterer interessanter Punkt – im Vertrag mit einem der größten Kunden steht, dass alle Softwareversionen, die die Plattform unterstützt, n-1 sein müssen, also nicht die neueste Version, sondern die vorletzte.

Es ist klar, wie weit wir von n-1 entfernt waren, wenn die Plattform auf ColdFusion und SQL Server 2008 lief, der im Juli überhaupt nicht mehr unterstützt wurde.

Tag fünfundvierzig

Irgendwann Mitte des zweiten Monats hatte ich genug Zeit, um mich hinzusetzen und zu machen valuestreamMapping vollständig für den gesamten Prozess. Das sind die notwendigen Schritte, die unternommen werden müssen, vom Produkt zu seiner Auslieferung an den Verbraucher, und es müssen sie so detailliert wie möglich aufgeschrieben werden.

Du zerlegst den Prozess in kleine Teile und schaust, was zu viel Zeit in Anspruch nimmt, was optimiert oder verbessert werden kann usw. Zum Beispiel, wie viel Zeit benötigt eine Anfrage vom Produkt, der Durchlauf durch das Grooming, bis sie zu einem Ticket wird, das der Entwickler übernehmen kann, QA usw. Du betrachtest jeden einzelnen Schritt im Detail und überlegst, was optimiert werden kann.

Als ich das machte, fielen mir zwei Dinge auf:

• eine hohe Rücklaufquote von Tickets aus QA zurück zu den Entwicklern;
• Pull-Request-Reviews dauerten zu lange.

Das Problem war, dass es mehr oder weniger Schätzungen waren: Es scheint viel Zeit in Anspruch zu nehmen, aber wir sind uns nicht sicher, wie viel genau.

"Man kann nichts verbessern, was man nicht messen kann."

Wie lässt sich begründen, wie ernst das Problem ist? Verschwinden damit Tage oder Stunden?

Um das zu messen, haben wir ein paar Schritte im Jira-Prozess hinzugefügt: "bereit für die Entwicklung" und "bereit für QA", um zu messen, wie lange jedes Ticket wartet und wie oft es zu einem bestimmten Schritt zurückkehrt.

Außerdem haben wir "in Überprüfung" hinzugefügt, um zu wissen, wie lange Tickets durchschnittlich in der Überprüfung sind, und darauf basierend weiterzuarbeiten. Wir hatten Systemmetriken, jetzt haben wir neue Metriken hinzugefügt und begannen zu messen:

• Prozesseffizienz: Produktivität und geplant / geliefert.
• Prozessqualität: Anzahl der Defekte, Defekte von QA.

Das hilft wirklich zu verstehen, was gut funktioniert und was nicht.

Tag fünfzig

Das ist alles natürlich gut und interessant, aber gegen Ende des zweiten Monats geschah etwas, das im Grunde vorhersehbar war, obwohl ich das Ausmaß nicht erwartet hatte. Die Leute fingen an zu gehen, weil sich die Führungsebene geändert hatte. Neue Leute kamen in die Geschäftsleitung, die alles verändern wollten, und die alten Leute wurden entlassen. In einem Unternehmen, das mehrere Jahre besteht, sind in der Regel alle Freunde und kennen sich gegenseitig.

Das war zu erwarten, aber das Ausmaß der Entlassungen war unerwartet. Zum Beispiel kündigten in einer Woche zwei Teamleiter gleichzeitig ihre Kündigung aus eigenem Wunsch an. Deshalb musste ich nicht nur die anderen Probleme vergessen, sondern mich auf die Teambildung. Das ist ein langwieriges und schwer lösbares Problem, aber es musste angegangen werden, weil ich die Leute, die geblieben waren (oder die meisten von ihnen), erhalten wollte. Man musste irgendwie reagieren auf die Tatsache, dass Leute gegangen sind, um die Moral im Team zu unterstützen.

In der Theorie ist das gut: Ein neuer Mensch kommt, der einen Freibrief hat, die Fähigkeiten des Teams zu bewerten und das Personal zu ersetzen. In der Praxis kann man jedoch aus vielen Gründen nicht einfach neue Leute bringen. Es braucht immer ein Gleichgewicht.

• Alt und neu. Man muss die alten Leute behalten, die sich ändern und die Mission unterstützen können. Aber gleichzeitig muss man frisches Blut bringen, darüber werden wir gleich sprechen.
• Erfahrung. Ich habe viel mit guten Junioren gesprochen, die begeistert waren und zu uns arbeiten wollten. Aber ich konnte sie nicht einstellen, weil es nicht genug Seniors gab, um die Junioren zu unterstützen und Mentoren für sie zu sein. Zuerst musste man die Führungsebene aufbauen und erst danach die jungen Leute.
• Die Peitsche und das Zuckerbrot.

Ich habe keine gute Antwort auf die Frage, welches Gleichgewicht richtig ist, wie man es aufrechterhält, wie viele Leute man behalten sollte und wie stark man Druck ausüben sollte. Das ist ein rein individueller Prozess.

Tag einundfünfzig

Ich begann, das Team zu beobachten, um zu verstehen, wer mich umgibt, und erinnerte mich einmal mehr daran:

„Die meisten Probleme sind Probleme mit Menschen.“

Ich stellte fest, dass es im Team, sowohl bei den Entwicklern als auch bei den Ops, drei große Probleme gab:

• Zufriedenheit mit dem aktuellen Zustand.
• Mangelnde Verantwortung – weil niemand jemals die Ergebnisse der Arbeit der Ausführenden mit Auswirkungen auf das Geschäft in Verbindung brachte.
• Angst vor Veränderungen.

Veränderungen bringen immer aus der Komfortzone, und je jünger die Menschen sind, desto weniger mögen sie Veränderungen, weil sie nicht verstehen, warum und wie. Die häufigste Antwort, die ich gehört habe, war: „So haben wir das noch nie gemacht.“ Es ging sogar so weit, dass selbst geringste Änderungen nicht ohne Protest akzeptiert wurden. Dabei war es irrelevant, wie sehr die Änderungen ihre eigene Arbeit betrafen, die Leute sagten: „Nein, warum? Das wird nicht funktionieren.“

Aber man kann nicht besser werden, ohne etwas zu verändern.

Ich hatte ein absolut absurdes Gespräch mit einem Mitarbeiter, ich habe ihm meine Optimierungsideen vorgestellt, worauf er mir sagte:
„Ach, hast du nicht gesehen, was wir im letzten Jahr hatten!“
„Na und?“
„Jetzt ist es viel besser als früher.“
„Also kann es nicht noch besser werden?“
„Warum denn?“

Eine gute Frage – warum? Als wäre alles, was jetzt besser ist als zuvor, ausreichend gut. Das führt zu einem Mangel an Verantwortung, was im Grunde genommen absolut normal ist. Wie ich gesagt habe, stand die Technikgruppe ein wenig im Hintergrund. Im Unternehmen dachte man, sie sollten präsent sein, aber niemand hat jemals Standards festgelegt. Der Support hat nie SLA gesehen, weshalb es für die Gruppe völlig "akzeptabel" war (und das hat mich am meisten überrascht):

• 12 Sekunden Ladezeit;
• 5-10 Minuten Ausfallzeit pro Release;
• die Behebung kritischer Fehler dauert Tage und Wochen;
• fehlende 24/7-Bereitschaft / On-Call.

Niemand hat jemals versucht zu fragen, warum wir das nicht besser machen könnten, und niemand hat jemals verstanden, dass es so nicht sein sollte.

Als Bonus gab es ein weiteres Problem: fehlende Erfahrung.Die Senior-Mitarbeiter sind gegangen, und das verbleibende junge Team ist unter den alten Bedingungen gewachsen und wurde dadurch beeinträchtigt.

Zusätzlich hatten die Leute Angst, zu versagen, um nicht inkompetent zu wirken. Das äußert sich darin, dass sie erstens unter keinen Umständen um Hilfe bitten.Wie oft wir auch in Gruppen- und Einzelgesprächen gesprochen haben, und ich sagte: „Stellt eine Frage, wenn ihr nicht wisst, wie man etwas macht.“ Ich bin zuversichtlich und weiß, dass ich jedes Problem lösen kann, aber das dauert Zeit. Also, wenn ich jemanden fragen kann, der es in 10 Minuten lösen kann, werde ich fragen. Je weniger Erfahrung man hat, desto mehr fürchtet man zu fragen, weil man denkt, dass man für inkompetent gehalten wird.

Diese Angst, eine Frage zu stellen, zeigt sich in interessanten Formen. Zum Beispiel fragt man: „Wie steht es mit dieser Aufgabe?“ — „Es sind noch ein paar Stunden übrig, ich mache schon fertig.“ Am nächsten Tag fragt man wieder, man bekommt die Antwort, dass alles gut aussieht, aber es gibt ein kleines Problem, bis Ende des Tages wird es sicher fertig sein. Ein weiterer Tag vergeht, und solange man nicht gegen die Wand drängt und ihn zwingt, mit jemandem zu sprechen, geht es einfach so weiter. Die Person möchte die Aufgabe selbst lösen, sie glaubt, dass es eine große Niederlage wäre, wenn sie es nicht selbst schafft.

Genau deshalb die Entwickler überschätzen die Bewertungen. Das war ein echter Witz, als wir an einer bestimmten Aufgabe diskutierten, gab man mir eine Zahl, die mich sehr überrascht hat. Woraufhin mir gesagt wurde, dass der Entwickler in die Schätzungen auch die Zeit einbezieht, die das Ticket aus QA zurückkommt, weil sie dort Fehler finden werden, und die Zeit, die PR in Anspruch nimmt, und die Zeit, währenddessen die Personen, die es überprüfen sollen, beschäftigt sind — also alles, was nur möglich ist.

Zweitens, Menschen, die Angst haben, inkompetent zu erscheinen, analysieren übermäßig. Wenn man sagt, was konkret gemacht werden muss, geht es los: „Nein, was ist, wenn wir hier darüber nachdenken?“ In dieser Hinsicht ist unser Unternehmen nicht einzigartig, es ist ein Standardproblem der Jugend.

Als Antwort habe ich folgende Praktiken eingeführt:

• Regel von 30 Minuten. Wenn Sie das Problem in einer halben Stunde nicht lösen können, bitten Sie jemanden um Hilfe. Das funktioniert mit variablem Erfolg, weil die Leute sich trotzdem nicht melden, aber zumindest hat der Prozess begonnen.
• Alles andere außer dem Wesentlichen ausschließen, bei der Einschätzung der Aufgabenzeit, das heißt, nur die Zeit zu berechnen, die das Codieren in Anspruch nehmen wird.
• Kontinuierliches Lernen für diejenigen, die übermäßig analysieren. Es ist einfach eine ständige Arbeit mit Menschen.

Der sechsundsechzigste Tag

Während ich mich mit all dem beschäftigte, war es an der Zeit, den Haushalt zu überprüfen. Natürlich fand ich viele interessante Dinge darüber, wo wir Geld ausgaben. Zum Beispiel hatten wir einen gesamten Rack in einem separaten Rechenzentrum, in dem ein FTP-Server stand, der von einem einzigen Kunden genutzt wurde. Es stellte sich heraus, dass „... wir umgezogen sind, und er blieb einfach, wir haben ihn nicht gewechselt“. Das war vor 2 Jahren.

Ein besonderes Interesse bestand an der Rechnung für Cloud-Dienste. Ich bin mir sicher, dass der Hauptgrund für die hohe Rechnung für Cloud-Dienste die Entwickler sind, die zum ersten Mal in ihrem Leben unbegrenzten Zugriff auf Server haben. Sie müssen nicht fragen: „Bitte gib mir einen Testserver“, sie können ihn selbst nehmen. Darüber hinaus wollen die Entwickler immer ein so cooles System bauen, dass Facebook neidisch auf Netflix wäre.

Aber die Entwickler haben keine Erfahrung im Einkauf von Servern und kein Gespür dafür, welche Servergröße erforderlich ist, da sie das vorher nicht benötigten. Und normalerweise verstehen sie nicht richtig den Unterschied zwischen Skalierbarkeit und Leistung.

Ergebnisse der Bestandsaufnahme:

• Wir haben einen Datacenter verlassen.
• Wir haben Verträge mit 3 Log-Diensten gekündigt. Denn wir hatten 5 – jeder Entwickler, der mit etwas experimentierte, nahm einen neuen.
• Wir haben 7 AWS-Systeme abgeschaltet. Auch hier wurden tote Projekte nicht gestoppt; sie liefen einfach weiter.
• Wir haben die Softwareausgaben um das 6-fache reduziert.

Der fünfundsiebzigste Tag

Die Zeit verging, und nach zweieinhalb Monaten sollte ich mich mit dem Vorstand treffen. Unser Vorstand ist nicht besser und nicht schlechter als andere; er ist wie alle anderen Vorstände daran interessiert, alles zu wissen. Die Menschen investieren Geld und wollen verstehen, wie das, was wir tun, mit den festgelegten KPIs übereinstimmt.

Der Vorstand erhält jeden Monat viele Informationen: die Anzahl der Benutzer, ihr Wachstum, welche Dienste sie nutzen und wie, die Leistung und Produktivität schließlich die durchschnittliche Ladegeschwindigkeit der Seite.

Das Problem ist nur, dass ich glaube, dass der Durchschnitt reines Übel ist. Aber es ist sehr schwierig, dem Vorstand das zu erklären. Sie sind daran gewöhnt, mit aggregierten Zahlen zu operieren und nicht mit beispielsweise der Streuung der Ladezeiten in Sekunden.

In diesem Zusammenhang gab es interessante Momente. Zum Beispiel habe ich gesagt, dass der Verkehr zwischen einzelnen Webservern je nach Art des Inhalts aufgeteilt werden muss.

Das heißt, ColdFusion läuft über Jetty und nginx und erstellt die Seiten. Bilder, JS und CSS gehen über einen separaten nginx mit seinen eigenen Konfigurationen. Das ist eine ziemlich gängige Praxis, über die ich geschrieben vor ein paar Jahren gesprochen habe. Infolgedessen werden die Bilder viel schneller geladen, und … die durchschnittliche Ladezeit hat sich um 200 ms erhöht.

Es geschah, weil das Diagramm auf Daten basiert, die von Jetty kommen. Das heißt, schneller Inhalt wird nicht berücksichtigt – der Durchschnittswert ist gestiegen. Das war uns klar, wir haben darüber gelacht, aber wie erklärt man dem Vorstand, warum wir etwas gemacht haben und es sich um 12 % verschlechtert hat?

Fünfundachtzigster Tag

Am Ende des dritten Monats wurde mir klar, dass ich auf eine Sache überhaupt nicht vorbereitet war – die Zeit. Für alles, was ich erzählt habe, braucht man Zeit.

Das ist mein echter Kalender für die Woche – einfach eine Arbeitswoche, nicht besonders belastet. Es fehlt an Zeit für alles. Deshalb müssen wir wieder Leute einstellen, die helfen, die Probleme zu bewältigen.

Fazit

Das ist noch lange nicht alles. In dieser Erzählung bin ich noch nicht einmal dazu gekommen, wie wir mit dem Produkt gearbeitet haben und versuchten, auf einen gemeinsamen Nenner zu kommen, oder wie wir den technischen Support integriert haben oder wie wir andere technische Probleme gelöst haben. Zum Beispiel habe ich zufällig erfahren, dass wir bei den größten Tabellen in der Datenbank nicht nutzen SEQUENZ. Wir haben eine selbstgeschriebene Funktion nextID, die nicht in der Transaktion verwendet wird.

Es gab noch eine Million solcher Dinge, über die man lange sprechen könnte. Aber das Wichtigste, was man noch erwähnen sollte, ist die Kultur.

Gerade die Kultur oder deren Fehlen führt zu all den anderen Problemen. Wir versuchen, eine Kultur aufzubauen, in der die Menschen:

• keine Angst vor Misserfolgen haben;
• aus Fehlern lernen;
• mit anderen Teams zusammenarbeiten;
• Initiative zeigen;
• Verantwortung übernehmen;
• das Ergebnis als Ziel willkommen heißen;
• Erfolge feiern.

Mit diesem wird alles andere kommen.

Leon Feuer auf twitter, facebook und auf medium.

In Bezug auf Legacy gibt es zwei Strategien: alles zu vermeiden, was damit zu tun hat, oder mutig die damit verbundenen Schwierigkeiten zu überwinden. Wir gehen DevOpsConf den zweiten Weg, ändern Prozesse und Ansätze. Schließen Sie sich uns an in youtube, Newsletter und Telegram, und lassen Sie uns gemeinsam die DevOps-Kultur einführen.

Quelle: habr.com