Es ist bekannt, dass die Kompetenz des CTOs erst nach der zweiten Amtszeit dieser Rolle überprüft wird. Denn es ist eine Sache, mehrere Jahre in einem Unternehmen zu arbeiten, mit ihm zu evolvieren und im selben kulturellen Kontext allmählich mehr Verantwortung zu übernehmen. Und etwas völlig anderes ist es, sofort als Technischer Direktor in ein Unternehmen mit einem Erbe an Altsystemen und vielen Problemen zu kommen, die sorgfältig unter den Teppich gekehrt wurden.

In diesem Sinne ist die Erfahrung von Leon Fire, die er auf DevOpsConf, nicht unbedingt einzigartig, aber in Verbindung mit seiner Dienstzeit und der Anzahl verschiedener Rollen, die er in 20 Jahren übernommen hat, sehr hilfreich. Im Folgenden finden Sie eine Chronologie der Ereignisse innerhalb von 90 Tagen und viele Anekdoten, über die man lachen kann, wenn sie jemand anderem passieren, aber die nicht so lustig sind, wenn man ihnen selbst begegnet.

Leon erzählt sehr farbenfroh auf Russisch, daher kann ich, wenn Sie 35-40 Minuten Zeit haben, empfehlen, sich das Video anzusehen. Eine textliche Version zur Zeitersparnis finden Sie unten.

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 auf dem Weg auftauchten. Daher habe ich das Format geändert und die Probleme, die mir in dem neuen Unternehmen wie ein Geist aus der Tabakdose entgegenkamen, sowie die Methoden zu ihrer Lösung chronologisch dargelegt.

Einen Monat vor

Wie viele gute Geschichten begann diese mit Alkohol. Wir saßen mit Bekannten in einer Bar, und wie es sich für ITler gehört, klagte jeder über seine Probleme. Einer von ihnen hatte gerade seinen Job gewechselt und erzählte von seinen Schwierigkeiten sowohl mit Technologien als auch mit Menschen und dem Team. Je länger ich zuhörte, desto mehr erkannte ich, dass er mich einfach einstellen sollte, denn genau solche Probleme hatte ich in den letzten 15 Jahren gelöst. So habe ich es ihm gesagt, und am nächsten Tag trafen wir uns bereits in einer beruflichen Umgebung. Die Firma hieß Teaching Strategies.

Teaching Strategies ist führend auf dem Markt für Bildungsprogramme für Kleinkinder im Alter von der Geburt bis drei Jahre. Das traditionelle "Papierunternehmen" besteht seit etwa 40 Jahren, während die digitale SaaS-Version der Plattform seit 10 Jahren verfügbar ist. Vor kurzem begann der Prozess, die digitale Technologie an die Standards des Unternehmens anzupassen. Die "neue" Version wurde 2017 gestartet und war fast wie die alte, nur dass sie schlechter funktionierte.

Das Interessanteste ist, dass der Verkehr 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 beginnen, Informationen einzugeben. Und so geschieht es jeden Tag, außer am Wochenende, da fast niemand arbeitet.

Um etwas vorzugreifen, möchte ich anmerken, dass ich meine Arbeit in der Zeit des höchsten jährlichen Verkehrs begonnen habe, was aus verschiedenen Gründen interessant ist.

Die Plattform, die angeblich erst 2 Jahre alt war, hatte einen eigenartigen Stack: ColdFusion & SQL Server aus dem Jahr 2008. ColdFusion, falls Sie es nicht wissen — und wahrscheinlich wissen Sie es nicht — ist eine Art Enterprise-PHP, das Mitte der 90er Jahre auf den Markt kam, und seitdem habe ich nichts mehr davon gehört. Außerdem waren da: Ruby, MySQL, PostgreSQL, Java, Go, Python. Aber das Hauptmonolith arbeitete mit ColdFusion und SQL Server.

Die Probleme

Je mehr ich mit den Mitarbeitern des Unternehmens über die Arbeit und die auftretenden Probleme sprach, desto mehr verstand ich, dass die Probleme nicht nur technischer Natur waren. Okay, die Technologie ist alt — wir haben nicht auf so etwas gearbeitet, aber es gab Probleme mit dem Team und den Prozessen, und das Unternehmen begann, dies zu erkennen.

Traditionell saßen die Techniker in der Ecke und beschäftigten sich mit ihrer eigenen Arbeit. Aber immer mehr Geschäfte begannen, über die digitale Version abzuwickeln. Daher gab es im Unternehmen im letzten Jahr vor meinem Eintritt neue Positionen: einen Vorstand, einen CTO, einen CPO und einen QA-Direktor. Das heißt, das Unternehmen begann, in den Technologiebereich zu investieren.

Die Spuren eines schweren Erbes waren nicht nur in den Systemen sichtbar. Im Unternehmen gab es Legacy-Prozesse, Legacy-Personen und eine Legacy-Kultur. All das musste geändert werden. Ich dachte mir, dass es bestimmt nicht langweilig werden würde, und beschloss, es zu versuchen.

Zwei Tage vor

Zwei Tage vor Beginn der neuen Arbeit kam ich ins Büro, füllte die letzten Dokumente aus, lernte das Team kennen und stellte fest, dass das Team gerade mit einem Problem kämpfte. Es ging darum, dass die durchschnittliche Ladezeit der Seiten auf 4 Sekunden gestiegen war, also auf das Doppelte.

Anhand des Diagramms war deutlich, dass etwas passiert war, aber es war unklar, was. Es stellte sich heraus, dass das Problem in der Netzwerkverzögerung im Rechenzentrum lag: 5 ms Latenz im Rechenzentrum verwandelten sich in 2 Sekunden für die Nutzer. Warum das passierte, wusste ich nicht, aber es wurde jedenfalls klar, dass das Problem im Rechenzentrum lag.

Tag eins

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

Zwei Tage lang luden die Seiten bei den Nutzern im Durchschnitt über 4 Sekunden. Ich fragte, ob sie herausgefunden hätten, was das Problem sei.

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

Da wurde mir klar, dass alles, was mir zuvor erzählt worden war, nur die kleine Spitze des Eisbergs war, mit dem ich es zu tun hatte.

Es gibt ein passendes Zitat für diesen Fall:

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

Da ich jedoch zur geschäftigsten Zeit des Jahres angefangen habe, musste ich beide Lösungsansätze in Betracht ziehen: sowohl kurzfristig als auch langfristig. Und ich musste mit dem beginnen, was jetzt kritisch war.

Tag drei

Die Ladezeit betrug also 4 Sekunden, wobei von 13 bis 15 Uhr die größten Spitzen lagen.

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

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

Ich versuchte, das Team zu überzeugen, woraufhin mir gesagt wurde, dass wir einfach mehr Server benötigten. Das ist natürlich eine Lösung, aber lange nicht immer die einzige und effektivste. Ich fragte, warum es an Servern mangelt und wie hoch das Verkehrsvolumen ist. Ich extrapolierte die Daten und stellte fest, dass wir etwa 150 Anfragen pro Sekunde haben, was im Prinzip innerhalb vernünftiger Grenzen liegt.

Aber man darf nicht vergessen, dass man die richtigen Fragen stellen muss, um die richtigen Antworten zu erhalten. Meine nächste Frage war: Wie viele Frontend-Server haben wir? Die Antwort hat mich "ein wenig verblüfft" - wir hatten 17 Frontend-Server!

— Darf ich fragen, ob 150 durch 17 ungefähr 8 ergibt? Sie wollen sagen, dass jeder Server 8 Anfragen pro Sekunde bearbeitet, und wenn morgen 160 Anfragen pro Sekunde kommen, wir dann 2 weitere Server benötigen?

Natürlich benötigten wir keine zusätzlichen Server. Die Lösung lag im Code selbst, und zwar ziemlich offensichtlich:

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

Es gab eine Funktion getCurrentClass(), weil alles auf der Website im Kontext der Klasse funktioniert - richtig. Und für diese eine Funktion musste auf jeder Seite 200+ Anfragen.

Die Lösung war also sehr einfach, es musste nichts neu geschrieben werden: einfach nicht die gleiche Information erneut anfordern.

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

Ich war sehr froh, weil ich dachte, dass ich am dritten Tag das Hauptproblem gefunden hatte. Wie naiv ich war, das war nur eines von sehr vielen Problemen.

Aber die Lösung dieses ersten Problems senkte den Graphen deutlich.

Gleichzeitig haben wir an anderen Optimierungen gearbeitet. Es gab viele offensichtliche Dinge, die man reparieren konnte. Zum Beispiel entdeckte ich am dritten Tag, dass es doch einen Cache im System gab (zunächst dachte ich, dass alle Anfragen direkt aus der Datenbank kommen). Wenn ich an Cache denke, stelle ich mir standardmäßig Redis oder Memcached vor. Aber so dachte nur ich, denn für das Caching in diesem System wurden MongoDB und SQL Server verwendet — genau der, von dem gerade die Daten gelesen wurden.

Der zehnte Tag

In der ersten Woche beschäftigte ich mich mit Problemen, die sofort angegangen werden mussten. Irgendwann in der zweiten Woche kam ich zum ersten Mal zum Stand-up, um mit dem Team zu sprechen, zu sehen, was los ist und wie der gesamte Prozess abläuft.

Wieder gab es interessante Entdeckungen. Das Team bestand aus: 18 Entwicklern; 8 Testern; 3 Managern; 2 Architekten. Und alle nahmen an den gemeinsamen Ritualen teil, das heißt, mehr als 30 Personen kamen jeden Morgen zum Stand-up und berichteten, was sie gemacht hatten. Es ist klar, dass das Treffen nicht fünf oder fünfzehn Minuten dauerte. Niemand hörte den anderen zu, weil alle an verschiedenen Systemen arbeiteten. In dieser Form waren 2-3 Tickets pro Stunde in der Grooming-Session bereits ein gutes Ergebnis.

Zuerst haben wir das Team entlang der Produktlinien aufgeteilt. Für verschiedene Abschnitte und Systeme haben wir separate Teams gebildet, die Entwickler, Tester, Produktmanager und Business-Analysten umfassten.

Das Ergebnis war:

• Kürzere Stand-ups und Meetings.
• Fachwissen über das Produkt.
• Eigenverantwortung. Früher wechselten die Leute ständig zwischen den Systemen und wussten, dass jemand anderes wahrscheinlich mit ihren Bugs arbeiten würde, aber nicht sie selbst.
• Zusammenarbeit zwischen den Gruppen. Es ist unnötig zu erwähnen, dass QA und Programmierer zuvor nicht viel kommunizierten, der Produktmanager machte sein eigenes Ding usw. Jetzt gibt es einen gemeinsamen Verantwortungsbereich.

Unser Hauptfokus lag auf Effizienz, Leistung und Qualität — genau diese Probleme haben wir durch die Transformation des Teams angegangen.

Tag elf

Im Zuge der Umstrukturierung des Teams habe ich herausgefunden, wie sie StoryPoints. 1 SP entsprach einem Tag, und jedes Ticket beinhaltete sowohl SP für die Entwicklung als auch für QA, das heißt mindestens 2 SP.

Wie ich das herausgefunden habe?

Wir haben einen Fehler gefunden: In einem der Berichte, in dem das Start- und Enddatum des zu erstattenden Zeitraums eingegeben wird, wird der letzte Tag nicht berücksichtigt. Das bedeutet, dass irgendwo in der Abfrage nicht <= sondern einfach < stand. Mir wurde gesagt, dass das drei Story Points entspricht, also 3 Tage.

Danach haben wir:

• Das System zur Bewertung von Story Points überarbeitet. Jetzt kommt die Behebung kleiner Fehler, die man schnell über das System laufen lassen kann, schneller beim Nutzer an.
• Begonnen, verwandte Tickets für die Entwicklung und Test zusammenzufassen. Früher war jedes Ticket, jeder Fehler ein geschlossener Mikrokosmos, der mit nichts anderem verbunden war. Die Änderung von drei Schaltflächen auf einer Seite konnte drei verschiedene Tickets mit drei unterschiedlichen QA-Prozessen statt einem automatisierten Test auf der Seite bedeuten.
• Begonnen, mit den Entwicklern an der Einschätzung des Arbeitsaufwands zu arbeiten. Drei Tage für die Änderung einer Schaltfläche – das ist nicht lustig.

Der zwanzigste Tag

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

Langfristige Ziele:

• Die verwaltete Plattform. Hunderte von Anfragen auf jeder Seite – das ist nicht ernsthaft.
• Vorhersehbare Trends. Es gab sporadische Traffic-Spitzen, die auf den ersten Blick nicht mit anderen Metriken korrelierten — wir mussten herausfinden, warum das passiert und lernen, vorherzusagen.
• Erweiterung der Plattform. Das Geschäft wächst ständig, es kommen immer mehr Nutzer, der Traffic steigt.

Früher sagte man oft: „Lass uns alles auf [Sprache/Framework] umschreiben, dann wird alles besser funktionieren!“

In den meisten Fällen funktioniert das nicht, es ist schon gut, wenn das Geschriebene überhaupt funktioniert. Deshalb mussten wir einen Fahrplan erstellen — eine konkrete Strategie, die Schritt für Schritt zeigt, wie die Geschäftsziele erreicht werden (was wir tun werden und warum), die:

• die Mission und Ziele des Projekts widerspiegelt;
• die Hauptziele priorisiert;
• einen Zeitplan für deren Erreichung enthält.

Bis dahin hatte niemand mit dem Team darüber gesprochen, zu welchem Zweck Änderungen vorgenommen werden. Dafür braucht es die richtigen Erfolgskennzahlen. Erstmals in der Unternehmensgeschichte haben wir KPIs für die technische Gruppe festgelegt, und diese Kennzahlen wurden an die organisatorischen Ziele gebunden.

Das heißt, organisatorische KPIs werden von Teams unterstützt, während teambezogene KPIs bereits individuell unterstützt werden. Andernfalls, wenn die technologischen KPIs nicht mit den organisatorischen übereinstimmen, zieht jeder das Bein auf sich.

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

Was kann helfen, das Ziel zu erreichen, mehr neue Produkte zu entwickeln?

• Erstens möchten wir mehr Zeit für die Entwicklung neuer Produkte aufwenden, anstatt Fehler zu beheben. Das ist eine logische Entscheidung, die leicht messbar ist.
• Zweitens möchten wir das Transaktionsvolumen steigern, denn je größer der Marktanteil, desto mehr Benutzer und folglich mehr Traffic.

Dann wären individuelle KPIs, die innerhalb der Gruppe umgesetzt werden können, beispielsweise dort, wo die meisten Fehler auftreten. Wenn man sich auf diesen Bereich konzentriert, kann man die Anzahl der Fehler erheblich reduzieren, was wiederum die Zeit für die Entwicklung neuer Produkte erhöht und erneut die organisatorischen KPIs unterstützt.

Jede Entscheidung, auch das Neuschreiben von Code, sollte spezifische Ziele unterstützen, die das Unternehmen uns setzt (Wachstum, neue Funktionen, Personalaufbau).

Während dieses Prozesses kam etwas Interessantes ans Licht, das nicht nur für Techniker, sondern für das gesamte Unternehmen eine Neuigkeit war: Alle Tickets müssen mindestens auf einen KPI ausgerichtet sein. Wenn der Produktmanager sagt, dass er eine neue Funktion implementieren möchte, sollte die erste Frage lauten: "Welchen KPI unterstützt diese Funktion?" Wenn es keinen gibt, tut mir leid – das scheint eine überflüssige Funktion zu sein.

Tag dreißig

Am Ende des Monats stellte ich einen weiteren Punkt fest: Keiner aus meinem Ops-Team hatte jemals die Verträge gesehen, die wir mit unseren Kunden abschließen. Sie fragen sich vielleicht, wozu man die Verträge sehen sollte.

• Erstens, weil in den Verträgen die SLAs festgelegt sind.
• Zweitens sind die SLAs unterschiedlich. Jeder Kunde kam mit seinen eigenen Anforderungen, und die Verkaufsabteilung unterschrieb, ohne hinzuschauen.

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, als die Plattform auf ColdFusion und SQL Server 2008 basierte, dessen Unterstützung im Juli komplett eingestellt wurde.

Der fünfundvierzigste Tag

Irgendwann in der Mitte des zweiten Monats hatte ich genug Zeit, um mich hinzusetzen und zu machen valueWennMapping vollständig für den gesamten Prozess. Das sind die notwendigen Schritte, die man von der Produktentwicklung bis zur Auslieferung an den Kunden unternehmen muss, und sie sollten so detailliert wie möglich beschrieben werden.

Du zerlegst den Prozess in kleine Abschnitte und schaust, was zu viel Zeit in Anspruch nimmt, was optimiert und verbessert werden kann usw. Zum Beispiel, wie viel Zeit es dauert, eine Anfrage vom Produkt durch das Grooming zu schicken, bis sie zu einem Ticket wird, das der Entwickler übernehmen kann, QA usw. Du schaust so detailliert auf jeden einzelnen Schritt und überlegst, was verbessert werden kann.

Als ich das tat, fielen mir zwei Dinge auf:

• der hohe Rückgabeanteil von Tickets aus QA an die Entwickler;
• Pull-Request-Überprüfungen dauerten zu lange.

Das Problem war, dass es sich um Schlussfolgerungen handelte wie: 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? Geht es um Tage oder Stunden?

Um dies 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 jeder 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 im Durchschnitt in der Überprüfung sind, und darauf basierend weitere Schritte zu unternehmen. Wir hatten bereits systematische Metriken, jetzt haben wir neue Metriken hinzugefügt und begannen zu messen:

• Die Effektivität des Prozesses: Produktivität und geplante/lieferte Ergebnisse.
• Die Qualität des Prozesses: Anzahl der Defekte, Defekte von QA.

Das hilft wirklich zu verstehen, was gut läuft und was nicht.

Der fünfzigste Tag

Das ist alles natürlich gut und interessant, aber gegen Ende des zweiten Monats geschah das, was eigentlich vorhersehbar war, obwohl ich nicht mit diesem Ausmaß gerechnet hatte. Die Leute begannen zu gehen, weil sich das Management geändert hatte. Neue Leute kamen in die Führung, die alles zu verändern begannen, und die alten wurden entlassen. Normalerweise in einem Unternehmen, das mehrere Jahre besteht, sind alle miteinander befreundet und kennen sich.

Es war zu erwarten, aber das Ausmaß der Entlassungen war unerwartet. Zum Beispiel haben in einer Woche zwei Teamleiter gleichzeitig gekündigt. Daher musste ich nicht nur die anderen Probleme vergessen, sondern mich auf die Teambildung. Das ist ein langwieriges und schwieriges Problem, das angegangen werden musste, denn ich wollte die verbliebenen Mitarbeiter (oder die meisten von ihnen) halten. Es war notwendig, auf die Abgänge zu reagieren, um die Moral im Team zu unterstützen.

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

• Von Alt und Neu. Es ist wichtig, die alten Mitarbeiter zu behalten, die sich ändern können und die Mission unterstützen. Aber gleichzeitig muss neues Blut hineingebracht werden, darüber werden wir gleich sprechen.
• Erfahrung. Ich habe viel mit guten Junioren gesprochen, die begeistert waren und bei uns arbeiten wollten. Aber ich konnte sie nicht einstellen, weil es nicht genug erfahrene Kollegen gab, die die Junioren unterstützen und für sie Mentoren sein konnten. Zuerst mussten wir die Spitze aufbauen und erst dann die Jüngeren.
• Zuckerbrot und Peitsche.

Ich habe keine gute Antwort darauf, wie das richtige Gleichgewicht aussieht, wie man es aufrechterhält, wie viele Leute man behalten sollte und wie stark man Druck ausüben kann. Das ist ein rein individueller Prozess.

Tag einundfünfzig.

Ich habe begonnen, das Team zu beobachten, um zu verstehen, wen ich habe, und erinnerte mich erneut:

„Die meisten Probleme sind Probleme mit Menschen.“

Ich habe entdeckt, dass es im Team, sowohl bei den Entwicklern als auch beim Ops, drei große Probleme gibt:

• Zufriedenheit mit dem aktuellen Zustand.
• Mangel an Verantwortung — weil nie die Ergebnisse der Arbeit der Mitarbeiter mit deren Einfluss auf das Geschäft in Verbindung gebracht wurden.
• Angst vor Veränderungen.

Veränderungen bringen immer Unbehagen, 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 soweit, dass die kleinsten Änderungen nicht ohne Aufruhr blieben. Unabhängig davon, wie sehr die Veränderungen ihre Arbeit betrafen, sagten die Leute: „Nein, warum? Das wird nicht funktionieren.“

Aber man kann sich nicht verbessern, ohne etwas zu ändern.

Ich hatte ein völlig absurdes Gespräch mit einem Mitarbeiter, dem ich meine Optimierungsideen vorstellte, woraufhin er mir antwortete:
— Ach, hast du nicht gesehen, was wir letztes Jahr hatten!
— Und was ist damit?
— Jetzt ist es viel besser als zuvor.
— Also kann es nicht noch besser werden?
— Warum denn?

Gute Frage – warum? Als ob es, wenn es jetzt besser ist als vorher, genug gut wäre. Das führt zu einem Mangel an Verantwortung, was grundsätzlich absolut normal ist. Wie gesagt, die technische Gruppe war ein wenig im Abseits. In der Firma glaubte man, dass sie da sein sollten, aber nie stellte jemand Standards auf.. In der technischen Unterstützung wurde SLA nie gesehen, daher war es für die Gruppe ziemlich "akzeptabel" (und das hat mich am meisten überrascht):

• 12 Sekunden Ladezeit;
• 5-10 Minuten Ausfallzeit bei jedem Release;
• das Beheben kritischer Fehler dauert Tage und Wochen;
• kein 24/7 Notdienst / Bereitschaft.

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 im alten Modus gewachsen und wurde dadurch vergiftet.

Darüber hinaus hatten die Leute auch Angst, zu scheitern und inkompetent zu wirken. Das äußert sich darin, dass sie erstens unter keinen Umständen um Hilfe baten. Wie oft haben wir in der Gruppe und individuell gesprochen, und ich habe gesagt: "Stellt Fragen, wenn ihr nicht wisst, wie man etwas macht." Ich bin mir sicher und weiß, dass ich jedes Problem lösen kann, aber das wird Zeit in Anspruch nehmen. Also, wenn ich jemanden fragen kann, der es in 10 Minuten lösen kann, frage ich. Je weniger Erfahrung du hast, desto mehr hast du Angst zu fragen, weil du denkst, dass man dich für inkompetent hält.

Diese Angst, Fragen zu stellen, äußert sich auf interessante Weise. Zum Beispiel fragst du: „Wie steht es um diese Aufgabe?“ — „Es bleibt ein paar Stunden, ich mache schon fertig.“ Am nächsten Tag fragst du wieder und bekommst die Antwort, dass alles gut sei, aber ein kleines Problem aufgetaucht ist; bis zum Ende des Tages wird es sicher fertig sein. Ein weiterer Tag vergeht, und solange du nicht gegen die Wand drängst und jemanden zwingst, darüber zu reden, bleibt alles beim Alten. Die Person möchte die Aufgabe selbst lösen und denkt, dass es eine große Niederlage wäre, wenn sie es nicht selbst schafft.

Deshalb Die Entwickler haben die Schätzungen überhöht.. Das war schon ein Witz, als wir über eine bestimmte Aufgabe sprachen und ich eine Zahl zu hören bekam, die mich sehr überrascht hat. Mir wurde gesagt, dass der Entwickler in die Schätzungen auch die Zeit einbezieht, die das Ticket von QA zurückgebracht wird, weil sie dort Fehler finden werden, und die Zeit, die ein PR in Anspruch nimmt, sowie die Zeit, während die Leute, die es überprüfen sollten, beschäftigt sein werden — also alles, was möglich ist.

Zweitens analysieren Menschen, die Angst haben, inkompetent zu erscheinen, übermäßig.. Wenn man sagt, was konkret zu tun ist, beginnt es: „Nein, was ist, wenn wir hier darüber nachdenken?“ In diesem Sinne ist unser Unternehmen nicht einzigartig, es ist ein übliches Problem der Jugend.

Als Antwort führte ich folgende Praktiken ein:

• Das 30-Minuten-Regel. Wenn Sie innerhalb von 30 Minuten das Problem nicht lösen können, bitten Sie jemanden um Hilfe. Das funktioniert mit unterschiedlichem Erfolg, da die Leute trotzdem nicht um Hilfe bitten, aber zumindest hat der Prozess begonnen.
• Alles außer dem Wesentlichen ausschließen, bei der Bewertung der Aufgabendauer, also nur die Zeit zählen, die die Programmierung erfordern wird.
• Ständiges Lernen für diejenigen, die überanalysieren. Es ist einfach ständige Arbeit mit Menschen.

Am sechzigsten Tag

Während ich all das tat, war es an der Zeit, das Budget zu klären. Natürlich fand ich vieles Interessante darüber, wofür wir Geld ausgegeben haben. Zum Beispiel hatten wir eine ganze Rack in einem separaten Rechenzentrum, auf 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.

Besondere Aufmerksamkeit erhielt die 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 Zugang zu Servern haben. Sie müssen nicht mehr fragen: „Geben Sie mir bitte einen Testserver“ – sie können selbst darauf zugreifen. Außerdem wollen die Entwickler immer so ein cooles System erstellen, dass Facebook und Netflix neidisch werden.

Aber die Entwickler haben keine Erfahrung im Servereinkauf und das nötige Wissen, um die richtige Servergröße zu bestimmen, da sie das zuvor nicht benötigten. Und meistens verstehen sie nicht ganz den Unterschied zwischen Skalierbarkeit und Performance.

Ergebnisse der Bestandsaufnahme:

• Haben ein Rechenzentrum verlassen.
• Haben Verträge mit 3 Log-Services gekündigt. Denn wir hatten 5 – jeder Entwickler, der mit etwas experimentierte, nahm sich einen neuen.
• Haben 7 AWS-Systeme abgeschaltet. Wieder einmal wurden tote Projekte nicht gestoppt; sie liefen einfach weiter.
• Die Softwarekosten wurden um das 6-fache reduziert.

Tag fünfundsiebzig

Die Zeit verging, und nach zweieinhalb Monaten musste ich mich mit dem Vorstand treffen. Unser Vorstand ist nicht besser und nicht schlechter als andere, er möchte, wie alle Vorstände, alles wissen. Die Menschen investieren Geld und wollen verstehen, wie das, was wir tun, in die festgelegten KPIs passt.

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

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

In diesem Zusammenhang gab es interessante Punkte. Zum Beispiel sagte ich, dass der Traffic je nach Art des Inhalts zwischen einzelnen Web-Servern aufgeteilt werden sollte.

Das heißt, ColdFusion läuft über Jetty und nginx und lädt die Seiten. Bilder, JS und CSS gehen über ein separates nginx mit eigenen Konfigurationen. Das ist eine ziemlich gängige Praxis, über die ich schrieb Vor ein paar Jahren. Infolgedessen laden sich Bilder viel schneller, und die durchschnittliche Ladegeschwindigkeit hat sich um 200 ms erhöht.

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

Fünfundachtzigster Tag

Am Ende des dritten Monats wurde mir klar, dass ich mit einer Sache überhaupt nicht gerechnet hatte – der Zeit. Für alles, was ich erzählt habe, benötigt man Zeit.

Das ist mein echter Wochenkalender – einfach eine Arbeitswoche, nicht zu überladen. Es fehlt an Zeit für alles. Daher muss ich 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 versucht haben, uns auf eine gemeinsame Welle einzustellen, oder wie wir den 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, und sie wird nicht in der Transaktion verwendet.

Es gab noch eine Million ähnlicher Dinge, über die man lange sprechen könnte. Aber das Wichtigste, was noch zu sagen ist, ist die Kultur.

Genau diese Kultur oder ihr Fehlen führt zu all den anderen Problemen. Wir versuchen, eine Kultur aufzubauen, in der Menschen:

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

Damit kommt alles andere.

Leon Feuer auf Twitter, facebook und auf der medium.

Im Hinblick auf Legacy gibt es zwei Strategien: Alles daran setzen, die Arbeit damit zu vermeiden, oder mutig die damit verbundenen Herausforderungen angehen. Wir gehen den zweiten Weg, indem wir Prozesse und Ansätze ändern. Schließt euch uns an in DevOpsConf Telegram youtube, Newsletter und , und lasst uns gemeinsam die DevOps-Kultur einführen., и будем вместе внедрять культуру DevOps.

Quelle: habr.com