Es ist bekannt, dass die Kompetenz des CTO erst bei der zweiten Ausübung dieser Rolle auf die Probe gestellt wird. Denn es ist eine Sache, mehrere Jahre in einem Unternehmen zu arbeiten, sich mit ihm weiterzuentwickeln und im gleichen kulturellen Kontext nach und nach mehr Verantwortung zu übernehmen. Und es ist etwas ganz anderes, direkt die Position des technischen Direktors in einem Unternehmen zu übernehmen, dessen Altlasten und eine Menge Probleme sauber unter den Teppich gekehrt wurden.

In diesem Sinne ist die Erfahrung von Leon Fire, an der er teilnahm DevOpsConf, nicht gerade einzigartig, aber multipliziert mit seiner Erfahrung und der Anzahl verschiedener Rollen, die er im Laufe von 20 Jahren ausprobiert hat, ist es sehr nützlich. Unterhalb des Ausschnitts finden Sie eine Chronologie der Ereignisse über 90 Tage und viele Geschichten, über die es Spaß macht, zu lachen, wenn sie jemand anderem passieren, die aber nicht so lustig sind, wenn man sie persönlich erlebt.

Leon spricht sehr farbenfroh Russisch. Wenn Sie also 35 bis 40 Minuten Zeit haben, empfehle ich Ihnen, sich das Video anzusehen. Textversion, um Zeit zu sparen, unten.

Die erste Version des Berichts war eine gut strukturierte Beschreibung der Arbeit mit Menschen und Prozessen und enthielt nützliche Empfehlungen. Aber sie vermittelte nicht alle Überraschungen, die sie unterwegs erlebte. Deshalb änderte ich das Format und präsentierte die Probleme, die vor mir auftauchten, wie ein Wundertüte im neuen Unternehmen, und Methoden zu deren Lösung in chronologischer Reihenfolge.

Einen Monat vorher

Wie viele gute Geschichten begann auch diese mit Alkohol. Wir saßen mit Freunden in einer Bar und wie es sich für IT-Spezialisten gehört, weinten alle über ihre Probleme. Einer von ihnen hatte gerade den Job gewechselt und sprach über seine Probleme mit der Technologie, den Menschen und dem Team. Je mehr ich zuhörte, desto klarer wurde mir, dass er mich einfach einstellen sollte, denn das sind die Art von Problemen, die ich in den letzten 15 Jahren gelöst habe. Ich sagte es ihm und am nächsten Tag trafen wir uns in einer Arbeitsumgebung. Das Unternehmen hieß Teaching Strategies.

Teaching Strategies ist Marktführer bei Lehrplänen für sehr kleine Kinder von der Geburt bis zum Alter von drei Jahren. Das traditionelle „Papier“-Unternehmen ist bereits 40 Jahre alt und die digitale SaaS-Version der Plattform ist 10 Jahre alt. Relativ kürzlich begann der Prozess der Anpassung digitaler Technologie an Unternehmensstandards. Die „neue“ Version kam 2017 auf den Markt und war fast wie die alte, nur dass sie schlechter funktionierte.

Das Interessanteste ist, dass der Verkehr dieses Unternehmens sehr vorhersehbar ist – von Tag zu Tag, von Jahr zu Jahr kann man ganz klar vorhersagen, wie viele Leute wann kommen werden. Beispielsweise gehen zwischen 13 und 15 Uhr alle Kinder im Kindergarten ins Bett und die Lehrer beginnen mit der Eingabe von Informationen. Und das passiert jeden Tag, außer am Wochenende, denn am Wochenende arbeitet fast niemand.

Wenn ich ein wenig in die Zukunft blicke, fällt mir auf, dass ich mit meiner Arbeit in der Zeit des höchsten jährlichen Verkehrsaufkommens begonnen habe, was aus verschiedenen Gründen interessant ist.

Die Plattform, die erst zwei Jahre alt zu sein schien, verfügte über einen eigenartigen Stack: ColdFusion und SQL Server aus dem Jahr 2. Falls Sie es nicht wissen, und höchstwahrscheinlich wissen Sie es auch nicht, ist ColdFusion ein Enterprise-PHP, das Mitte der 2008er Jahre auf den Markt kam, und seitdem habe ich nicht einmal mehr davon gehört. Außerdem gab es: Ruby, MySQL, PostgreSQL, Java, Go, Python. Der Hauptmonolith lief jedoch auf ColdFusion und SQL Server.

Probleme

Je mehr ich mit den Mitarbeitern des Unternehmens über die Arbeit und die aufgetretenen Probleme sprach, desto klarer wurde mir, dass die Probleme nicht nur technischer Natur waren. Okay, die Technologie ist alt – und sie haben nicht daran gearbeitet, aber es gab Probleme mit dem Team und mit den Prozessen, und das Unternehmen begann das zu verstehen.

Traditionell saßen ihre Technikfreaks in der Ecke und erledigten irgendeine Arbeit. Aber immer mehr Unternehmen begannen, die digitale Version zu nutzen. Daher traten im letzten Jahr vor meinem Arbeitsbeginn neue Personen im Unternehmen auf: Vorstand, CTO, CPO und QA-Direktor. Das heißt, das Unternehmen begann, in den Technologiesektor zu investieren.

Spuren einer schweren Hinterlassenschaft fanden sich nicht nur in den Anlagen. Das Unternehmen verfügte über veraltete Prozesse, veraltete Mitarbeiter und eine veraltete Kultur. Das alles musste geändert werden. Ich dachte, dass es definitiv nicht langweilig werden würde und beschloss, es auszuprobieren.

Zwei Tage vorher

Zwei Tage bevor ich einen neuen Job antrat, kam ich im Büro an, füllte die letzten Unterlagen aus, traf das Team und stellte fest, dass das Team zu diesem Zeitpunkt mit einem Problem zu kämpfen hatte. Die durchschnittliche Seitenladezeit stieg auf 4 Sekunden, also um das Zweifache.

Der Grafik nach zu urteilen, ist eindeutig etwas passiert, und es ist nicht klar, was. Es stellte sich heraus, dass das Problem in der Netzwerklatenz im Rechenzentrum lag: Aus 5 ms Latenz im Rechenzentrum wurden für Benutzer 2 s. Ich wusste nicht, warum das passierte, aber auf jeden Fall wurde bekannt, dass das Problem im Rechenzentrum lag.

Tag eins

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

Zwei Tage lang wurden die Seiten der Benutzer im Durchschnitt in 4 Sekunden geladen. Ich frage, ob sie das Problem gefunden haben.

- Ja, wir haben ein Ticket geöffnet.
- und?
- Nun, sie haben uns noch nicht geantwortet.

Dann wurde mir klar, dass alles, was mir zuvor erzählt worden war, nur eine kleine Spitze des Eisbergs war, gegen die ich kämpfen musste.

Es gibt ein gutes Zitat, das sehr gut dazu passt:

„Um die Technologie zu ändern, muss man manchmal die Organisation ändern.“

Da ich aber in der geschäftigsten Zeit des Jahres mit der Arbeit begann, musste ich mir beide Möglichkeiten zur Lösung des Problems ansehen: sowohl eine schnelle als auch eine langfristige. Und beginnen Sie mit dem, was gerade jetzt entscheidend ist.

Tag drei

Das Laden dauert also 4 Sekunden und die größten Spitzen liegen zwischen 13 und 15.

Am dritten Tag in diesem Zeitraum sah die Download-Geschwindigkeit so aus:

Aus meiner Sicht hat überhaupt nichts funktioniert. Aus der Sicht aller anderen lief es etwas langsamer als sonst. Aber das passiert einfach nicht – es ist ein ernstes Problem.

Ich habe versucht, das Team zu überzeugen, woraufhin sie antworteten, dass sie einfach mehr Server bräuchten. Dies ist natürlich eine Lösung des Problems, aber nicht immer die einzige und effektivste. Ich fragte, warum es nicht genügend Server gäbe und wie hoch das Verkehrsaufkommen sei. Ich habe die Daten extrapoliert und festgestellt, dass wir ungefähr 150 Anfragen pro Sekunde haben, was im Prinzip innerhalb angemessener Grenzen liegt.

Wir dürfen jedoch nicht vergessen, dass Sie die richtige Frage stellen müssen, bevor Sie die richtige Antwort erhalten. Meine nächste Frage war: Wie viele Frontend-Server haben wir? Die Antwort „verblüffte mich ein wenig“ – wir hatten 17 Frontend-Server!

— Es ist mir peinlich zu fragen, aber 150 dividiert durch 17 ergibt etwa 8? Wollen Sie damit sagen, dass jeder Server 8 Anfragen pro Sekunde zulässt, und wenn es morgen 160 Anfragen pro Sekunde sind, brauchen wir zwei weitere Server?

Natürlich brauchten wir keine zusätzlichen Server. Die Lösung lag im Code selbst und an der Oberfläche:

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

Es gab eine Funktion getCurrentClass(), weil alles auf der Website im Kontext einer Klasse funktioniert – das ist richtig. Und dafür gab es auf jeder Seite eine Funktion Über 200 Anfragen.

Die Lösung auf diese Weise war sehr einfach, Sie mussten nicht einmal etwas umschreiben: Fragen Sie einfach nicht noch einmal nach denselben Informationen.

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

Ich war sehr glücklich, weil ich bereits am dritten Tag feststellte, dass ich das Hauptproblem gefunden hatte. Naiv wie ich war, war dies nur eines von vielen Problemen.

Aber die Lösung dieses ersten Problems ließ die Grafik viel tiefer fallen.

Gleichzeitig führten wir weitere Optimierungen durch. Es waren viele Dinge in Sicht, die behoben werden konnten. Beispielsweise entdeckte ich am selben dritten Tag, dass es doch einen Cache im System gab (zuerst dachte ich, dass alle Anfragen direkt aus der Datenbank kämen). Wenn ich an einen Cache denke, denke ich an Standard-Redis oder Memcached. Aber ich war der Einzige, der das dachte, denn dieses System nutzte MongoDB und SQL Server zum Caching – dasselbe, von dem die Daten gerade gelesen wurden.

Tag zehn

In der ersten Woche beschäftigte ich mich mit Problemen, die jetzt gelöst werden mussten. Irgendwann in der zweiten Woche kam ich zum ersten Mal zum Stand-up, um mit dem Team zu kommunizieren und zu sehen, was passierte und wie der gesamte Prozess verlief.

Es wurde wieder etwas Interessantes entdeckt. Das Team bestand aus: 18 Entwicklern; 8 Tester; 3 Manager; 2 Architekten. Und sie alle nahmen an gemeinsamen Ritualen teil, das heißt, jeden Morgen kamen mehr als 30 Menschen zum Stand-up und erzählten, was sie taten. Es ist klar, dass das Treffen keine 5 oder 15 Minuten gedauert hat. Niemand hat auf irgendjemanden gehört, weil jeder auf unterschiedlichen Systemen arbeitet. In dieser Form waren 2-3 Tickets pro Stunde für eine Fellpflege bereits ein gutes Ergebnis.

Als erstes haben wir das Team in mehrere Produktlinien aufgeteilt. Für verschiedene Bereiche und Systeme haben wir separate Teams zugewiesen, zu denen Entwickler, Tester, Produktmanager und Geschäftsanalysten gehörten.

Als Ergebnis bekamen wir:

• Reduzierung von Aufständen und Kundgebungen.
• Fachliche Kenntnisse des Produkts.
• Ein Gefühl der Eigenverantwortung. Als die Leute ständig an Systemen herumbastelten, wussten sie, dass höchstwahrscheinlich jemand anderes an ihren Fehlern arbeiten musste, nicht aber sie selbst.
• Zusammenarbeit zwischen Gruppen. Unnötig zu erwähnen, dass die Qualitätssicherung vorher nicht viel mit den Programmierern kommuniziert hat, das Produkt sein eigenes Ding gemacht hat usw. Jetzt haben sie einen gemeinsamen Verantwortungspunkt.

Wir haben uns hauptsächlich auf Effizienz, Produktivität und Qualität konzentriert – das sind die Probleme, die wir mit der Transformation des Teams zu lösen versuchten.

Tag elf

Während ich die Teamstruktur veränderte, entdeckte ich, wie man zählt GeschichtePunkte. 1 SP entsprach einem Tag und jedes Ticket enthielt SP für Entwicklung und Qualitätssicherung, also mindestens 2 SP.

Wie habe ich das entdeckt?

Wir haben einen Fehler gefunden: In einem der Berichte, in dem das Start- und Enddatum des Zeitraums eingegeben wird, für den der Bericht benötigt wird, wird der letzte Tag nicht berücksichtigt. Das heißt, irgendwo in der Anfrage stand nicht <=, sondern einfach <. Mir wurde gesagt, dass es sich hierbei um drei Story Points handelt 3 Tag.

Danach haben wir:

• Das Story Points-Bewertungssystem wurde überarbeitet. Jetzt erreichen Korrekturen für kleinere Fehler, die schnell durch das System weitergeleitet werden können, den Benutzer schneller.
• Wir haben damit begonnen, verwandte Tickets für Entwicklung und Tests zusammenzuführen. Früher war jedes Ticket, jeder Bug ein geschlossenes Ökosystem, das an nichts anderes gebunden war. Das Ändern von drei Schaltflächen auf einer Seite hätte zu drei verschiedenen Tickets mit drei unterschiedlichen Qualitätssicherungsprozessen führen können, statt zu einem automatisierten Test pro Seite.
• Wir begannen mit Entwicklern an einem Ansatz zur Schätzung der Arbeitskosten zu arbeiten. Drei Tage, um einen Knopf zu wechseln, ist nicht lustig.

Tag zwanzig

Irgendwann in der Mitte des ersten Monats stabilisierte sich die Situation ein wenig, ich begriff, was im Grunde vor sich ging, und begann bereits, in die Zukunft zu blicken und über langfristige Lösungen nachzudenken.

Langfristige Ziele:

• Verwaltete Plattform. Hunderte von Anfragen auf jeder Seite sind nicht seriös.
• Vorhersehbare Trends. Es kam zu periodischen Verkehrsspitzen, die auf den ersten Blick nicht mit anderen Kennzahlen korrelierten – wir mussten verstehen, warum dies geschah, und lernen, Vorhersagen zu treffen.
• Plattformerweiterung. Das Geschäft wächst stetig, es kommen immer mehr Nutzer und der Verkehr nimmt zu.

Früher hieß es oft: „Lasst uns alles in [Sprache/Framework] neu schreiben, dann wird alles besser funktionieren!“

In den meisten Fällen funktioniert dies nicht. Es ist gut, wenn das Umschreiben überhaupt funktioniert. Deshalb mussten wir eine Roadmap erstellen – eine spezifische Strategie, die Schritt für Schritt veranschaulicht, wie Geschäftsziele erreicht werden (was wir tun werden und warum), die:

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

Zuvor hatte niemand mit dem Team über den Zweck der vorgenommenen Änderungen gesprochen. Dafür bedarf es der richtigen Erfolgskennzahlen. Zum ersten Mal in der Unternehmensgeschichte haben wir KPIs für die technische Gruppe festgelegt und diese mit organisatorischen Indikatoren verknüpft.

Das heißt, organisatorische KPIs werden von Teams unterstützt und Team-KPIs werden von einzelnen KPIs unterstützt. Andernfalls, wenn technologische KPIs nicht mit organisatorischen übereinstimmen, zieht jeder die Decke auf sich.

Einer der KPIs der Organisation ist beispielsweise die Steigerung des Marktanteils durch neue Produkte.

Wie können Sie das Ziel unterstützen, mehr neue Produkte auf den Markt zu bringen?

• Erstens wollen wir mehr Zeit in die Entwicklung neuer Produkte investieren, anstatt Fehler zu beheben. Dies ist eine logische Lösung, die leicht zu messen ist.
• Zweitens wollen wir eine Steigerung des Transaktionsvolumens unterstützen, denn je größer der Marktanteil, desto mehr Nutzer und damit auch mehr Traffic.

Dann werden einzelne KPIs, die innerhalb der Gruppe ausgeführt werden können, beispielsweise dort liegen, wo die Hauptmängel entstehen. Wenn Sie sich speziell auf diesen Abschnitt konzentrieren, können Sie sicherstellen, dass es viel weniger Fehler gibt, und dann erhöht sich die Zeit für die Entwicklung neuer Produkte und wiederum für die Unterstützung organisatorischer KPIs.

Daher muss jede Entscheidung, einschließlich der Neufassung des Codes, die spezifischen Ziele unterstützen, die das Unternehmen für uns festgelegt hat (Organisationswachstum, neue Funktionen, Rekrutierung).

Dabei kam etwas Interessantes ans Licht, das nicht nur für Technikfreaks, sondern allgemein im Unternehmen zu einer Neuigkeit wurde: Alle Tickets müssen sich auf mindestens einen KPI konzentrieren. Das heißt, wenn ein Produkt sagt, dass es eine neue Funktion entwickeln möchte, sollte die erste Frage gestellt werden: „Welchen KPI unterstützt diese Funktion?“ Wenn nicht, dann tut es mir leid – es scheint eine unnötige Funktion zu sein.

Tag dreißig

Am Ende des Monats entdeckte ich eine weitere Nuance: Niemand in meinem Ops-Team hat jemals die Verträge gesehen, die wir mit Kunden abschließen. Sie fragen sich vielleicht, warum Sie Kontakte sehen müssen.

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

Eine weitere interessante Nuance besteht darin, dass im Vertrag mit einem der größten Kunden festgelegt ist, dass alle von der Plattform unterstützten Softwareversionen n-1 sein müssen, also nicht die neueste, sondern die vorletzte Version.

Es ist klar, wie weit wir von n-1 entfernt wären, wenn die Plattform auf ColdFusion und SQL Server 2008 basieren würde, was im Juli überhaupt nicht mehr unterstützt wurde.

Tag fünfundvierzig

Ungefähr in der Mitte des zweiten Monats hatte ich genug Zeit, mich hinzusetzen und etwas zu tun WertStromMapping vollständig für den gesamten Prozess. Dies sind die notwendigen Schritte, die von der Herstellung eines Produkts bis zur Auslieferung an den Verbraucher unternommen werden müssen, und sie müssen so detailliert wie möglich beschrieben werden.

Sie zerlegen den Prozess in kleine Teile und sehen, was zu viel Zeit in Anspruch nimmt, was optimiert, verbessert usw. werden kann. Wie lange dauert es beispielsweise, bis eine Produktanfrage die Bearbeitung durchläuft, wann erreicht sie ein Ticket, das ein Entwickler annehmen kann, Qualitätssicherung usw. Man schaut sich also jeden einzelnen Schritt im Detail an und überlegt, was optimiert werden kann.

Als ich das tat, fielen mir zwei Dinge auf:

• hoher Prozentsatz der von der Qualitätssicherung an die Entwickler zurückgegebenen Tickets;
• Pull-Request-Überprüfungen haben zu lange gedauert.

Das Problem bestand darin, dass dies Schlussfolgerungen waren wie: Es scheint viel Zeit zu dauern, aber wir sind nicht sicher, wie lange.

„Man kann nicht verbessern, was man nicht messen kann.“

Wie lässt sich die Schwere des Problems rechtfertigen? Verschwendet es Tage oder Stunden?

Um dies zu messen, haben wir dem Jira-Prozess einige Schritte hinzugefügt: „Bereit für die Entwicklung“ und „Bereit für die Qualitätssicherung“, um zu messen, wie lange jedes Ticket wartet und wie oft es zu einem bestimmten Schritt zurückkehrt.

Wir haben auch „in Rezension“ hinzugefügt, um zu erfahren, wie viele Tickets durchschnittlich zur Rezension verfügbar sind, und von dort aus können Sie mit dem Tanzen beginnen. Wir hatten Systemmetriken, jetzt fügten wir neue Metriken hinzu und begannen zu messen:

• Prozesseffizienz: Leistung und geplant/geliefert.
• Prozessqualität: Anzahl der Mängel, Mängel aus der Qualitätssicherung.

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

Tag fünfzig

Das ist natürlich alles gut und interessant, aber gegen Ende des zweiten Monats geschah etwas, das im Prinzip vorhersehbar war, obwohl ich ein solches Ausmaß nicht erwartet hatte. Die Leute fingen an zu gehen, weil das Top-Management gewechselt hatte. Neue Leute kamen ins Management und begannen, alles zu ändern, und die alten gaben auf. Und normalerweise sind in einem Unternehmen, das mehrere Jahre alt ist, alle befreundet und jeder kennt jeden.

Dies war erwartet worden, das Ausmaß der Entlassungen war jedoch unerwartet. Beispielsweise reichten innerhalb einer Woche zwei Teamleiter gleichzeitig aus freien Stücken ihren Rücktritt ein. Deshalb musste ich andere Probleme nicht nur vergessen, sondern mich auf sie konzentrieren ein Team bilden. Dies ist ein langwieriges und schwer zu lösendes Problem, aber es musste gelöst werden, weil ich die verbleibenden Menschen (oder die meisten von ihnen) retten wollte. Es war notwendig, irgendwie auf die Tatsache zu reagieren, dass die Leute gegangen sind, um die Moral im Team aufrechtzuerhalten.

Theoretisch ist das gut: Es kommt eine neue Person mit völliger Vollmacht, die die Fähigkeiten des Teams bewerten und Personal ersetzen kann. Tatsächlich kann man aus so vielen Gründen nicht einfach neue Leute einstellen. Balance ist immer gefragt.

• Alt und Neu. Wir müssen alte Menschen behalten, die sich verändern und die Mission unterstützen können. Aber gleichzeitig müssen wir Nachwuchs holen, darüber reden wir etwas später.
• Erfahrung. Ich habe viel mit guten Junioren gesprochen, die gerne mit uns zusammenarbeiten wollten. Aber ich konnte sie nicht übernehmen, weil es nicht genügend Senioren gab, die die Junioren unterstützen und als Mentoren für sie fungieren konnten. Es war notwendig, zuerst die Spitze zu rekrutieren und dann erst die Jugend.
• Karotte und Peitsche.

Ich habe keine gute Antwort auf die Frage, was das richtige Gleichgewicht ist, wie man es aufrechterhält, wie viele Leute man behalten und wie viel man antreiben muss. Dies ist ein rein individueller Vorgang.

Tag einundfünfzig

Ich fing an, mir das Team genau anzuschauen, um zu verstehen, wer ich hatte, und wieder einmal fiel mir ein:

„Die meisten Probleme sind Menschenprobleme.“

Ich habe festgestellt, dass das Team als solches – sowohl Dev als auch Ops – drei große Probleme hat:

• Zufriedenheit mit dem aktuellen Stand der Dinge.
• Mangel an Verantwortung - weil noch nie jemand die Ergebnisse der Arbeit der Künstler dazu gebracht hat, das Geschäft zu beeinflussen.
• Angst vor Veränderung.

Veränderungen führen Sie immer aus Ihrer Komfortzone, und je jünger 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, ist: „Das haben wir noch nie gemacht.“ Darüber hinaus erreichte es den Punkt der völligen Absurdität – die kleinsten Änderungen konnten nicht stattfinden, ohne dass jemand empört war. Und egal wie sehr sich die Veränderungen auf ihre Arbeit auswirkten, die Leute sagten: „Nein, warum? Es wird nicht funktionieren.

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

Ich hatte ein absolut absurdes Gespräch mit einem Mitarbeiter, ich erzählte ihm meine Ideen zur Optimierung, woraufhin er mir sagte:
- Oh, Sie haben nicht gesehen, was wir letztes Jahr hatten!
- Na und?
„Jetzt ist es viel besser als es war.“
- Es kann also nicht besser werden?
- Und warum?

Gute Frage – warum? Es ist, als wäre alles gut genug, wenn es jetzt besser ist als vorher. Dies führt zu mangelnder Verantwortung, was grundsätzlich völlig normal ist. Wie gesagt, die technische Gruppe stand etwas am Rande. Das Unternehmen glaubte, dass sie existieren sollten, aber Niemand hat jemals die Standards festgelegt. Der technische Support hat das SLA nie gesehen, daher war es für die Gruppe durchaus „akzeptabel“ (und das hat mich am meisten beeindruckt):

• 12 Sekunden Laden;
• 5–10 Minuten Ausfallzeit bei jeder Veröffentlichung;
• Die Behebung kritischer Probleme dauert Tage und Wochen.
• Mangel an Dienstpersonal rund um die Uhr / Bereitschaftsdienst.

Niemand hat jemals versucht zu fragen, warum wir es nicht besser machen, und niemand hat jemals erkannt, dass es nicht so sein muss.

Als Bonus gab es noch ein weiteres Problem: Mangel an Erfahrung. Die Senioren verließen das Team, und die verbleibende junge Mannschaft wuchs unter dem vorherigen Regime auf und wurde dadurch vergiftet.

Darüber hinaus hatten die Menschen auch Angst davor, zu versagen und inkompetent zu wirken. Dies kommt darin zum Ausdruck, dass sie erstens unter keinen Umständen um Hilfe gebeten. Wie oft haben wir als Gruppe und einzeln gesprochen und ich habe gesagt: „Stellen Sie eine Frage, wenn Sie nicht wissen, wie man etwas macht.“ Ich habe Selbstvertrauen und weiß, dass ich jedes Problem lösen kann, aber es wird Zeit brauchen. Wenn ich also jemanden fragen kann, der weiß, wie man das Problem in 10 Minuten löst, werde ich fragen. Je weniger Erfahrung Sie haben, desto mehr Angst haben Sie, zu fragen, weil Sie denken, dass Sie als inkompetent angesehen werden.

Diese Angst, Fragen zu stellen, äußert sich auf interessante Weise. Sie fragen zum Beispiel: „Wie geht es Ihnen mit dieser Aufgabe?“ - „Noch ein paar Stunden, ich bin schon fertig.“ Am nächsten Tag fragt man noch einmal nach und erhält die Antwort, dass alles in Ordnung sei, aber es gab ein Problem, es wird auf jeden Fall am Ende des Tages fertig sein. Ein weiterer Tag vergeht, und bis man an die Wand gefesselt wird und gezwungen wird, mit jemandem zu reden, geht das so weiter. Ein Mensch möchte ein Problem selbst lösen; er glaubt, dass es ein großer Misserfolg sein wird, wenn er es nicht selbst löst.

Genau das ist es Die Entwickler haben die Schätzungen überhöht. Es war dieselbe Anekdote: Als sie eine bestimmte Aufgabe besprachen, nannten sie mir eine solche Zahl, dass ich sehr überrascht war. Mir wurde gesagt, dass der Entwickler in die Schätzungen des Entwicklers die Zeit einbezieht, in der das Ticket von der Qualitätssicherung zurückgegeben wird, weil dort Fehler gefunden werden, und die Zeit, die die PR in Anspruch nehmen wird, und die Zeit, in der die Leute es überprüfen sollten es wird beschäftigt sein – das heißt, alles, was auch immer möglich ist.

Zweitens Menschen, die Angst davor haben, inkompetent zu wirken überanalysieren. Wenn Sie sagen, was genau getan werden muss, beginnt es: „Nein, was wäre, wenn wir hier darüber nachdenken?“ In diesem Sinne ist unser Unternehmen kein Einzelfall, es handelt sich um ein Standardproblem junger Menschen.

Als Reaktion darauf habe ich die folgenden Praktiken eingeführt:

• Regel 30 Minuten. Wenn Sie das Problem nicht in einer halben Stunde lösen können, bitten Sie jemanden um Hilfe. Das klappt mit unterschiedlichem Erfolg, denn die Leute fragen immer noch nicht nach, aber zumindest hat der Prozess begonnen.
• Beseitigen Sie alles außer dem WesentlichenBerücksichtigen Sie bei der Schätzung der Frist für die Erledigung einer Aufgabe nur, wie lange das Schreiben des Codes dauern wird.
• Lebenslanges Lernen für diejenigen, die zu viel analysieren. Es ist einfach die ständige Arbeit mit Menschen.

Tag sechzig

Während ich das alles erledigte, war es an der Zeit, das Budget festzulegen. Natürlich habe ich viele interessante Dinge darin gefunden, wo wir unser Geld ausgegeben haben. Wir hatten beispielsweise ein ganzes Rack in einem separaten Rechenzentrum mit einem FTP-Server, der von einem Client genutzt wurde. Es stellte sich heraus: „... wir sind umgezogen, aber er ist so geblieben, wir haben ihn nicht verändert.“ Es war vor 2 Jahren.

Von besonderem Interesse war der Gesetzentwurf für Cloud-Dienste. Ich glaube, der Hauptgrund für die hohen Cloud-Rechnungen sind die Entwickler, die zum ersten Mal in ihrem Leben uneingeschränkten Zugriff auf Server haben. Sie müssen nicht fragen: „Bitte geben Sie mir einen Testserver“, sondern können ihn selbst nehmen. Außerdem wollen Entwickler immer ein so cooles System bauen, dass Facebook und Netflix neidisch sein werden.

Den Entwicklern fehlt jedoch die Erfahrung im Kauf von Servern und die Fähigkeit, die erforderliche Servergröße zu bestimmen, da sie diese zuvor nicht benötigten. Und sie verstehen den Unterschied zwischen Skalierbarkeit und Leistung meist nicht ganz.

Inventurergebnisse:

• Wir haben das gleiche Rechenzentrum verlassen.
• Wir haben den Vertrag mit 3 Protokolldiensten gekündigt. Da wir fünf davon hatten, nahm jeder Entwickler, der anfing, etwas auszuprobieren, ein neues.
• 7 AWS-Systeme wurden heruntergefahren. Auch hier stoppte niemand die toten Projekte; sie arbeiteten alle weiter.
• Reduzierte Softwarekosten um das Sechsfache.

Tag fünfundsiebzig

Die Zeit verging und zweieinhalb Monate später musste ich mich mit dem Vorstand treffen. Unser Vorstand ist nicht besser oder schlechter als andere, er will wie alle Vorstände alles wissen. Die Leute investieren Geld und wollen verstehen, inwieweit 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 wie nutzen, Leistung und Produktivität und schließlich die durchschnittliche Seitenladegeschwindigkeit.

Das einzige Problem ist, dass ich glaube, dass der Durchschnitt das pure Böse ist. Aber es ist sehr schwierig, dies dem Vorstand zu erklären. Sie sind es gewohnt, mit aggregierten Zahlen zu operieren und nicht beispielsweise mit der Streuung der Ladezeiten pro Sekunde.

Diesbezüglich gab es einige interessante Punkte. Ich habe zum Beispiel gesagt, dass wir den Datenverkehr je nach Art des Inhalts auf verschiedene Webserver aufteilen müssen.

Das heißt, ColdFusion durchläuft Jetty und Nginx und startet die Seiten. Und Bilder, JS und CSS durchlaufen einen separaten Nginx mit ihren eigenen Konfigurationen. Das ist eine ziemlich übliche Praxis, von der ich spreche писал vor ein paar Jahren. Dadurch werden Bilder viel schneller geladen und... die durchschnittliche Ladegeschwindigkeit hat sich um 200 ms erhöht.

Dies geschah, weil das Diagramm auf der Grundlage der mit Jetty gelieferten Daten erstellt wurde. Das heißt, schnelle Inhalte werden nicht in die Berechnung einbezogen – der Durchschnittswert ist sprunghaft angestiegen. Das war uns klar, wir haben gelacht, aber wie können wir dem Vorstand erklären, warum wir etwas getan haben und es um 12 % schlechter geworden ist?

Tag fünfundachtzig

Am Ende des dritten Monats wurde mir klar, dass es eine Sache gab, mit der ich überhaupt nicht gerechnet hatte: Zeit. Alles, worüber ich gesprochen habe, braucht Zeit.

Das ist mein echter Wochenkalender – nur eine Arbeitswoche, nicht sehr voll. Die Zeit reicht nicht für alles. Daher müssen Sie erneut Leute einstellen, die Ihnen bei der Bewältigung der Probleme helfen.

Abschluss

Das ist nicht alles. In dieser Geschichte bin ich noch nicht einmal darauf eingegangen, wie wir mit dem Produkt gearbeitet und versucht haben, uns auf die allgemeine Welle einzustellen, oder wie wir den technischen Support integriert haben oder wie wir andere technische Probleme gelöst haben. Ich habe zum Beispiel ganz zufällig erfahren, dass wir die größten Tabellen in der Datenbank nicht verwenden SEQUENCE. Wir haben eine selbstgeschriebene Funktion nextID, und es wird nicht in einer Transaktion verwendet.

Es gab noch eine Million weitere ähnliche Dinge, über die wir noch lange reden könnten. Aber das Wichtigste, was noch gesagt werden muss, ist die Kultur.

Es ist Kultur oder deren Fehlen, die zu allen anderen Problemen führt. Wir versuchen, eine Kultur aufzubauen, in der Menschen:

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

Damit wird alles andere kommen.

Leon Feuer in Twitter, Facebook und mittlere.

Im Umgang mit Altlasten gibt es zwei Strategien: Vermeiden Sie unbedingt die Arbeit damit oder überwinden Sie die damit verbundenen Schwierigkeiten mutig. Wir c DevOpsConf Wir gehen den zweiten Weg und verändern Prozesse und Vorgehensweisen. Machen Sie mit Youtube, Mailingliste и Telegramm, und gemeinsam werden wir eine DevOps-Kultur implementieren.

Source: habr.com