Det är känt att CTO:s kompetens testas först andra gången han utför denna roll. För det är en sak att arbeta i ett företag i flera år, utvecklas med det och, i samma kulturella sammanhang, gradvis få mer ansvar. Och det är en helt annan att komma direkt in i positionen som teknisk direktör på ett företag med äldre bagage och en massa problem snyggt sopat under mattan.

I denna mening upplevelsen av Leon Fire, som han delade om DevOpsConf, inte precis unikt, men multiplicerat med hans erfarenhet och antalet olika roller som han lyckades prova på under 20 år, är det väldigt användbart. Under snittet finns en kronologi över händelser över 90 dagar och en massa historier som är roliga att skratta åt när de råkar ut för någon annan, men som inte är så roliga att möta personligen.

Leon talar väldigt färgglatt på ryska, så om du har 35-40 minuter rekommenderar jag att du tittar på videon. Textversion för att spara tid nedan.

Den första versionen av rapporten var en välstrukturerad beskrivning av arbetet med människor och processer, innehållande användbara rekommendationer. Men hon förmedlade inte alla överraskningar som möttes på vägen. Därför ändrade jag formatet och presenterade problemen som dök upp framför mig som en jack-in-the-box i det nya företaget, och metoder för att lösa dem i kronologisk ordning.

En månad innan

Som många bra historier började den här med alkohol. Vi satt med vänner i en bar och som förväntat bland IT-specialister grät alla över sina problem. En av dem hade precis bytt jobb och pratade om sina problem med teknik och med människor och med teamet. Ju mer jag lyssnade, desto mer insåg jag att han bara borde anställa mig, för det är den typen av problem jag har löst de senaste 15 åren. Jag sa det till honom och dagen efter träffades vi i en arbetsmiljö. Företaget hette Teaching Strategies.

Teaching Strategies är marknadsledande inom läroplan för mycket små barn från födseln till tre års ålder. Det traditionella "pappers"-företaget är redan 40 år gammalt och den digitala SaaS-versionen av plattformen är 10 år gammal. Relativt nyligen började processen att anpassa digital teknik till företagets standarder. Den "nya" versionen lanserades 2017 och var nästan som den gamla, bara den fungerade sämre.

Det mest intressanta är att det här företagets trafik är mycket förutsägbar - från dag till dag, från år till år kan du mycket tydligt förutse hur många människor som kommer och när. Till exempel mellan klockan 13 och 15 går alla barn på dagis och lägger sig och lärare börjar skriva in information. Och detta händer varje dag, utom helger, eftersom nästan ingen jobbar på helger.

Om jag blickar lite framåt kommer jag att notera att jag började mitt arbete under perioden med högst årstrafik, vilket är intressant av olika anledningar.

Plattformen, som bara verkade vara 2 år gammal, hade en märklig stack: ColdFusion & SQL Server från 2008. ColdFusion, om du inte vet, och förmodligen inte vet, är ett företags-PHP som kom ut i mitten av 90-talet, och sedan dess har jag inte ens hört talas om det. Det fanns också: Ruby, MySQL, PostgreSQL, Java, Go, Python. Men huvudmonoliten kördes på ColdFusion och SQL Server.

Problem

Ju mer jag pratade med företagets anställda om arbetet och vilka problem man stötte på, desto mer insåg jag att problemen inte bara var tekniska till sin natur. Okej, tekniken är gammal - och de arbetade inte med den, men det fanns problem med teamet och med processerna, och företaget började förstå detta.

Traditionellt satt deras tekniker i hörnet och gjorde något slags arbete. Men fler och fler affärer började gå igenom den digitala versionen. Därför, under det senaste året innan jag började arbeta, dök det upp nya i företaget: styrelse, CTO, CPO och QA-direktör. Det vill säga att företaget började investera i tekniksektorn.

Spåren av ett tungt arv fanns inte bara i systemen. Företaget hade legacy processer, legacy people, legacy kultur. Allt detta måste ändras. Jag trodde att det definitivt inte skulle vara tråkigt och bestämde mig för att prova.

Två dagar innan

Två dagar innan jag började på ett nytt jobb kom jag till kontoret, fyllde i de sista pappersarbetena, träffade teamet och upptäckte att teamet kämpade med ett problem vid tillfället. Det var att den genomsnittliga sidladdningstiden hoppade till 4 sekunder, det vill säga 2 gånger.

Att döma av grafen hände något tydligt, och det är inte klart vad. Det visade sig att problemet var nätverkslatens i datacentret: 5 ms latens i datacentret blev till 2 s för användarna. Jag visste inte varför detta hände, men i alla fall blev det känt att problemet låg i datacentret.

Dag ett

Två dagar gick och på min första arbetsdag upptäckte jag att problemet inte hade försvunnit.

Under två dagar laddades användarnas sidor i genomsnitt på 4 sekunder. Jag frågar om de hittat vad problemet är.

– Ja, vi öppnade en biljett.
- OCH?
– Nja, de har inte svarat oss än.

Sedan insåg jag att allt som jag hade fått höra tidigare bara var ett litet isberg som jag var tvungen att bekämpa.

Det finns ett bra citat som passar detta väldigt bra:

"Ibland för att förändra teknik måste du förändra organisationen."

Men eftersom jag började arbeta vid den mest hektiska tiden på året var jag tvungen att titta på båda alternativen för att lösa problemet: både snabbt och långsiktigt. Och börja med det som är kritiskt just nu.

Dag tre

Så laddningen varar i 4 sekunder, och från 13 till 15 de största topparna.

På den tredje dagen under denna tidsperiod såg nedladdningshastigheten ut så här:

Ur min synvinkel fungerade ingenting alls. Ur alla andras synvinkel gick det lite långsammare än vanligt. Men det händer bara inte så – det är ett allvarligt problem.

Jag försökte övertyga teamet, som de svarade att de helt enkelt behövde fler servrar. Detta är naturligtvis en lösning på problemet, men det är inte alltid den enda och mest effektiva. Jag frågade varför det inte fanns tillräckligt med servrar, vad var trafikvolymen. Jag extrapolerade uppgifterna och fann att vi har ungefär 150 förfrågningar per sekund, vilket i princip faller inom rimliga gränser.

Men vi får inte glömma att innan du får rätt svar måste du ställa rätt fråga. Min nästa fråga var: hur många frontend-servrar har vi? Svaret "förbryllade mig lite" - vi hade 17 frontend-servrar!

— Jag skäms över att fråga, men 150 delat med 17 ger ungefär 8? Menar du att varje server tillåter 8 förfrågningar per sekund, och om det imorgon finns 160 förfrågningar per sekund, kommer vi att behöva ytterligare två servrar?

Naturligtvis behövde vi inga ytterligare servrar. Lösningen fanns i själva koden och på ytan:

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

Det fanns en funktion getCurrentClass(), eftersom allt på webbplatsen fungerar i en klass - det stämmer. Och för denna en funktion på varje sida fanns det 200+ förfrågningar.

Lösningen på detta sätt var väldigt enkel, du behövde inte ens skriva om något: fråga bara inte om samma information igen.

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

Jag blev väldigt glad för jag bestämde mig för att jag bara den tredje dagen hade hittat huvudproblemet. Naiv som jag var var detta bara ett av många problem.

Men att lösa detta första problem sänkte grafen mycket lägre.

Samtidigt gjorde vi andra optimeringar. Det fanns många saker i sikte som kunde fixas. Till exempel upptäckte jag samma tredje dag att det trots allt fanns en cache i systemet (först trodde jag att alla förfrågningar kom direkt från databasen). När jag tänker på en cache tänker jag på standard Redis eller Memcached. Men jag var den enda som trodde det, eftersom det systemet använde MongoDB och SQL Server för cachning - samma som data precis lästes från.

Dag tio

Första veckan hanterade jag problem som behövde lösas just nu. Någonstans under den andra veckan kom jag till stand-upen för första gången för att kommunicera med teamet, för att se vad som hände och hur hela processen gick.

Något intressant upptäcktes igen. Teamet bestod av: 18 utvecklare; 8 testare; 3 chefer; 2 arkitekter. Och de deltog alla i gemensamma ritualer, det vill säga mer än 30 personer kom till standupen varje morgon och berättade vad de gjorde. Det är tydligt att mötet inte tog 5 eller 15 minuter. Ingen lyssnade på någon eftersom alla arbetar på olika system. I den här formen var 2-3 biljetter per timme för en grooming session redan ett bra resultat.

Det första vi gjorde var att dela upp teamet i flera produktlinjer. För olika sektioner och system tilldelade vi separata team, som inkluderade utvecklare, testare, produktchefer och affärsanalytiker.

Som ett resultat fick vi:

• Minska stand-ups och rallyn.
• Ämneskännedom om produkten.
• En känsla av ägarskap. När folk brukade mixtra med system hela tiden visste de att någon annan med största sannolikhet skulle behöva arbeta med sina buggar, men inte de själva.
• Samarbete mellan grupper. Onödigt att säga att QA inte kommunicerade mycket med programmerare tidigare, produkten gjorde sin egen sak, etc. Nu har de ett gemensamt ansvar.

Vi fokuserade främst på effektivitet, produktivitet och kvalitet – det är de problem vi försökte lösa med omvandlingen av teamet.

Dag elva

I processen med att ändra teamstrukturen upptäckte jag hur man räknar HistoriaPoäng. 1 SP var lika med en dag, och varje biljett innehöll SP för både utveckling och QA, det vill säga minst 2 SP.

Hur upptäckte jag detta?

Vi hittade en bugg: i en av rapporterna, där start- och slutdatumet för den period som rapporten behövs för anges, tas inte den sista dagen med i beräkningen. Det vill säga, någonstans i förfrågan fanns det inte <=, utan helt enkelt <. Jag fick höra att det här är tre Story Points, det vill säga 3 dagar.

Efter detta:

• Betygssystemet för Story Points har reviderats. Nu når korrigeringar för mindre buggar som snabbt kan skickas genom systemet användaren snabbare.
• Vi började slå samman relaterade biljetter för utveckling och testning. Tidigare var varje biljett, varje bugg ett slutet ekosystem, inte kopplat till något annat. Att byta tre knappar på en sida kunde ha varit tre olika biljetter med tre olika QA-processer istället för ett automatiskt test per sida.
• Vi började arbeta med utvecklare om en metod för att uppskatta arbetskostnader. Tre dagar att byta en knapp är inte roligt.

Dag tjugonde

Någonstans i mitten av första månaden stabiliserades situationen lite, jag kom på vad som i princip hände och började redan se in i framtiden och fundera på långsiktiga lösningar.

Långsiktiga mål:

• Hanterad plattform. Hundratals förfrågningar på varje sida är inte seriösa.
• Förutsägbara trender. Det fanns periodiska trafiktoppar som vid första anblicken inte korrelerade med andra mätvärden - vi behövde förstå varför detta hände och lära oss att förutsäga.
• Utbyggnad av plattformen. Verksamheten växer hela tiden, fler och fler användare kommer, och trafiken ökar.

Förr i tiden sa man ofta: "Låt oss skriva om allt i [språk/ram], allt kommer att fungera bättre!"

I de flesta fall fungerar inte detta, det är bra om omskrivningen alls fungerar. Därför behövde vi skapa en färdplan - en specifik strategi som steg för steg illustrerar hur affärsmål kommer att uppnås (vad vi kommer att göra och varför), som:

• speglar projektets uppdrag och mål;
• prioriterar huvudmålen;
• innehåller ett schema för att uppnå dem.

Innan detta hade ingen pratat med teamet om syftet med att eventuella förändringar skulle göras. Detta kräver rätt framgångsmått. För första gången i företagets historia satte vi nyckeltal för den tekniska gruppen, och dessa indikatorer var knutna till organisatoriska.

Det vill säga att organisatoriska KPI:er stöds av team och team-KPI:er stöds av individuella KPI:er. Annars, om tekniska KPI:er inte sammanfaller med organisatoriska, då drar alla täcket på sig själva.

Till exempel är en av de organisatoriska nyckeltalen att öka marknadsandelen genom nya produkter.

Hur kan du stödja målet att ha fler nya produkter?

• För det första vill vi lägga mer tid på att utveckla nya produkter istället för att åtgärda defekter. Detta är en logisk lösning som är lätt att mäta.
• För det andra vill vi stödja en ökning av transaktionsvolymen, eftersom ju större marknadsandel, desto fler användare och följaktligen mer trafik.

Då kommer enskilda KPI:er som kan utföras inom gruppen till exempel att finnas på den plats där de huvudsakliga defekterna kommer ifrån. Om du fokuserar specifikt på det här avsnittet kan du se till att det blir mycket färre defekter, och då kommer tiden att öka för att utveckla nya produkter och återigen för att stödja organisatoriska KPI:er.

Därför måste varje beslut, inklusive omskrivning av kod, stödja de specifika mål som företaget har satt upp för oss (organisationstillväxt, nya funktioner, rekrytering).

Under denna process kom en intressant sak fram, som blev en nyhet inte bara för tekniker, utan i allmänhet i företaget: alla biljetter måste fokuseras på minst en KPI. Det vill säga, om en produkt säger att den vill skapa en ny funktion, bör den första frågan ställas: "Vilken KPI stöder den här funktionen?" Om inte, så ledsen - det verkar vara en onödig funktion.

Dag trettio

I slutet av månaden upptäckte jag en annan nyans: ingen i mitt Ops-team har någonsin sett kontrakten vi ingår med kunder. Du kan fråga varför du behöver se kontakter.

• För det första eftersom SLA är specificerade i kontrakt.
• För det andra är SLA:er olika. Varje kund kom med sina egna krav och försäljningsavdelningen skrev på utan att titta.

En annan intressant nyans är att kontraktet med en av de största kunderna säger att alla mjukvaruversioner som stöds av plattformen måste vara n-1, det vill säga inte den senaste versionen, utan den näst sista.

Det är tydligt hur långt vi var från n-1 om plattformen var baserad på ColdFusion och SQL Server 2008, som inte längre stöddes alls i juli.

Dag fyrtiofem

Runt mitten av den andra månaden hade jag tillräckligt med tid att sätta mig ner och göra värdeströmkartläggning helt för hela processen. Detta är de nödvändiga stegen som måste vidtas, från att skapa en produkt till att leverera den till konsumenten, och de måste beskrivas så detaljerat som möjligt.

Du bryter processen i små bitar och ser vad som tar för mycket tid, vad som kan optimeras, förbättras osv. Till exempel, hur lång tid tar det för en produktförfrågan att gå igenom grooming, när når den en biljett som en utvecklare kan ta, QA osv. Så du tittar på varje enskilt steg i detalj och funderar på vad som kan optimeras.

När jag gjorde det här fick jag ögonen på två saker:

• hög andel biljetter som returneras från QA tillbaka till utvecklare;
• granskningar av pull-begäran tog för lång tid.

Problemet var att det här var slutsatser som: Det verkar ta mycket tid, men vi är inte säkra på hur lång tid.

"Du kan inte förbättra det du inte kan mäta."

Hur motiverar man hur allvarligt problemet är? Slösar det bort dagar eller timmar?

För att mäta detta lade vi till ett par steg i Jira-processen: "ready for dev" och "ready for QA" för att mäta hur länge varje biljett väntar och hur många gånger den går tillbaka till ett visst steg.

Vi har också lagt till "i recension" för att veta hur många biljetter som är i genomsnitt för recension, och från detta kan du börja dansa. Vi hade systemmått, nu lade vi till nya mätvärden och började mäta:

• Processeffektivitet: prestation och planerad/levererad.
• Processkvalitet: antal defekter, defekter från QA.

Det hjälper verkligen att förstå vad som går bra och vad som inte går bra.

Dag femtionde

Detta är naturligtvis allt bra och intressant, men mot slutet av den andra månaden hände något som i princip var förutsägbart, även om jag inte förväntade mig en sådan skala. Folk började lämna för att den högsta ledningen hade ändrats. Nya människor kom till ledningen och började förändra allt, och de gamla slutade. Och oftast i ett företag som är flera år gammalt är alla vänner och alla känner varandra.

Detta var väntat, men omfattningen av uppsägningarna var oväntad. Till exempel under en vecka lämnade två teamledare samtidigt in sina avskedanden av egen vilja. Därför var jag tvungen att inte bara glömma andra problem, utan fokusera på skapa ett team. Det här är ett långt och svårt problem att lösa, men det var tvungen att hanteras eftersom jag ville rädda de människor som fanns kvar (eller de flesta av dem). Det var nödvändigt att på något sätt reagera på att folk lämnade för att behålla moralen i laget.

I teorin är detta bra: en ny person kommer in som har fullständig carte blanche, som kan utvärdera lagets kompetens och ersätta personal. Faktum är att du inte bara kan ta in nya människor av så många anledningar. Balans behövs alltid.

• Gammal och ny. Vi behöver behålla gamla människor som kan förändra och stödja uppdraget. Men samtidigt måste vi få in nytt blod, det ska vi prata om lite senare.
• Erfarenhet. Jag pratade mycket med duktiga juniorer som var ivriga och ville jobba med oss. Men jag kunde inte ta mig an dem eftersom det inte fanns tillräckligt med seniorer för att stödja juniorerna och fungera som mentorer för dem. Det var nödvändigt att först rekrytera toppen och först därefter ungdomen.
• Morot och pinne.

Jag har inget bra svar på frågan om vad den rätta balansen är, hur man bibehåller den, hur många man ska behålla och hur mycket man ska pressa. Detta är en rent individuell process.

Dag femtio ett

Jag började titta noga på laget för att förstå vem jag hade, och återigen kom jag ihåg:

"De flesta problem är människors problem."

Jag har upptäckt att laget som sådant - både Dev och Ops - har tre stora problem:

• Nöjd med det aktuella läget.
• Brist på ansvar - för att ingen någonsin har fört resultatet av artisternas arbete för att påverka verksamheten.
• Rädsla för förändring.

Förändring tar dig alltid ut ur din komfortzon, och ju yngre människor är, desto mer ogillar de förändring eftersom de inte förstår varför och de inte förstår hur. Det vanligaste svaret jag har hört är "det har vi aldrig gjort." Dessutom nådde den punkten av fullständig absurditet - de minsta förändringarna kunde inte ske utan att någon blev indignerad. Och oavsett hur mycket förändringarna påverkade deras arbete, sa folk: ”Nej, varför? Det här kommer inte att fungera."

Men du kan inte bli bättre utan att ändra något.

Jag hade ett helt absurt samtal med en anställd, jag berättade för honom om mina idéer för optimering, som han sa till mig:
- Åh, du såg inte vad vi hade förra året!
- Än sen då?
"Nu är det mycket bättre än det var."
– Så det kan inte bli bättre?
- Varför då?

Bra fråga - varför? Det är som om det är bättre nu än det var, då är allt bra nog. Detta leder till bristande ansvar, vilket är helt normalt i princip. Teknikgruppen låg som sagt lite vid sidan av. Företaget ansåg att de borde finnas, men ingen har någonsin satt normerna. Teknisk support såg aldrig SLA, så det var ganska "acceptabelt" för gruppen (och detta slog mig mest):

• 12 sekunders laddning;
• 5-10 minuters driftstopp varje release;
• Att felsöka kritiska problem tar dagar och veckor;
• brist på tjänstgörande personal 24x7 / jour.

Ingen har någonsin försökt fråga varför vi inte gör det bättre, och ingen har någonsin insett att det inte behöver vara så här.

Som en bonus fanns det ytterligare ett problem: brist på erfarenhet. Seniorerna lämnade, och det återstående unga laget växte upp under den tidigare regimen och förgiftades av det.

Utöver allt detta var folk också rädda för att misslyckas och framstå som inkompetenta. Detta tar sig uttryck i att de för det första under inga omständigheter bett om hjälp. Hur många gånger har vi pratat som grupp och individuellt, och jag har sagt, "Ställ en fråga om du inte vet hur man gör något." Jag är trygg i mig själv och vet att jag kan lösa alla problem, men det kommer att ta tid. Därför, om jag kan fråga någon som vet hur man löser det på 10 minuter så frågar jag. Ju mindre erfarenhet du har, desto mer rädd är du att fråga eftersom du tror att du kommer att betraktas som inkompetent.

Denna rädsla för att ställa frågor visar sig på intressanta sätt. Till exempel frågar du: "Hur mår du med den här uppgiften?" - "Ett par timmar kvar, jag är redan klar." Nästa dag du frågar igen får du svaret att allt är bra, men det fanns ett problem, det kommer definitivt att vara klart i slutet av dagen. Ännu en dag går, och tills du klistras fast i väggen och tvingas prata med någon, fortsätter detta. En person vill lösa ett problem själv; han tror att om han inte löser det själv kommer det att bli ett stort misslyckande.

Det är därför utvecklarna blåste upp skattningarna. Det var samma anekdot, när de diskuterade en viss uppgift, gav de mig en sådan figur att jag blev mycket förvånad. Till vilket jag fick höra att i utvecklarens uppskattningar inkluderar utvecklaren den tid som biljetten kommer att returneras från QA, eftersom de kommer att hitta fel där, och den tid som PR kommer att ta, och tiden medan de personer som ska granska det kommer att vara upptaget - det vill säga allt, vad som helst som är möjligt.

För det andra människor som är rädda för att framstå som inkompetenta överanalysera. När du säger exakt vad som behöver göras börjar det: "Nej, tänk om vi tänker på det här?" I den meningen är vårt företag inte unikt, det här är ett standardproblem för unga människor.

Som svar introducerade jag följande praxis:

• Regel 30 minuter. Om du inte kan lösa problemet på en halvtimme, be någon att hjälpa till. Detta fungerar med varierande grad av framgång, eftersom folk fortfarande inte frågar, men processen har åtminstone börjat.
• Eliminera allt utom essensen, vid uppskattning av deadline för att slutföra en uppgift, det vill säga, överväg bara hur lång tid det tar att skriva koden.
• Fortsatt lärande för dem som överanalyserar. Det är bara ständigt arbete med människor.

Dag sextionde

Medan jag gjorde allt detta var det dags att räkna ut budgeten. Naturligtvis hittade jag många intressanta saker i var vi spenderade våra pengar. Till exempel hade vi ett helt rack i ett separat datacenter med en FTP-server, som användes av en klient. Det visade sig att "... vi flyttade, men han stannade så, vi ändrade honom inte." Det var 2 år sedan.

Av särskilt intresse var notan för molntjänster. Jag tror att huvudorsaken till den höga molnräkningen är utvecklarna som har obegränsad tillgång till servrar för första gången i sitt liv. De behöver inte fråga: "Snälla ge mig en testserver", de kan ta det själva. Dessutom vill utvecklare alltid bygga ett så coolt system att Facebook och Netflix kommer att bli avundsjuka.

Men utvecklarna har inte erfarenhet av att köpa servrar och förmågan att bestämma den nödvändiga storleken på servrar, eftersom de inte behövde det tidigare. Och de förstår vanligtvis inte riktigt skillnaden mellan skalbarhet och prestanda.

Lagerresultat:

• Vi lämnade samma datacenter.
• Hävde kontraktet med 3 logtjänster. Eftersom vi hade 5 av dem - varje utvecklare som började spela med något tog en ny.
• 7 AWS-system stängdes av. Återigen stoppade ingen de döda projekten, de fortsatte alla att arbeta.
• Sänkta mjukvarukostnader med 6 gånger.

Dag sjuttiofem

Tiden gick och om två och en halv månad var jag tvungen att träffa styrelsen. Vår styrelse är inte bättre eller sämre än andra, precis som alla styrelser vill den veta allt. Människor investerar pengar och vill förstå hur mycket det vi gör passar in i de uppsatta KPI:erna.

Styrelsen får mycket information varje månad: antalet användare, deras tillväxt, vilka tjänster de använder och hur, prestanda och produktivitet och slutligen den genomsnittliga sidladdningshastigheten.

Problemet är bara att jag tror att genomsnittet är ren ondska. Men det är väldigt svårt att förklara detta för styrelsen. De är vana vid att arbeta med aggregerade siffror, och inte till exempel spridningen av laddningstider per sekund.

Det fanns några intressanta punkter i detta avseende. Jag sa till exempel att vi måste dela upp trafik mellan separata webbservrar beroende på typ av innehåll.

Det vill säga ColdFusion går igenom Jetty och nginx och startar sidorna. Och bilder, JS och CSS går igenom en separat nginx med sina egna konfigurationer. Detta är en ganska vanlig praxis som jag pratar om jag skrev för några år sedan. Som ett resultat laddas bilder mycket snabbare, och... den genomsnittliga laddningshastigheten har ökat med 200 ms.

Detta hände för att grafen är byggd utifrån de data som kommer med Jetty. Det vill säga snabbt innehåll ingår inte i beräkningen - medelvärdet har hoppat. Detta var tydligt för oss, vi skrattade, men hur kan vi förklara för styrelsen varför vi gjorde något och saker blev värre med 12 %?

Dag åttiofem

I slutet av den tredje månaden insåg jag att det var en sak som jag inte hade räknat med alls: tid. Allt jag pratade om tar tid.

Det här är min riktiga veckokalender - bara en arbetsvecka, inte särskilt upptagen. Tiden räcker inte till allt. Därför måste du återigen rekrytera personer som hjälper dig att hantera problemen.

Slutsats

Det är inte allt. I den här historien har jag inte ens kommit till hur vi arbetade med produkten och försökte ställa in oss på den allmänna vågen, eller hur vi integrerade teknisk support, eller hur vi löste andra tekniska problem. Till exempel lärde jag mig helt av en slump att vi inte använder de största tabellerna i databasen SEQUENCE. Vi har en egenskriven funktion nextID, och det används inte i en transaktion.

Det fanns ytterligare en miljon liknande saker som vi skulle kunna prata om länge. Men det viktigaste som fortfarande behöver sägas är kulturen.

Det är kulturen eller bristen på sådan som leder till alla andra problem. Vi försöker bygga en kultur där människor:

• är inte rädda för misslyckanden;
• lära från sina misstag;
• samarbeta med andra team;
• ta initiativ;
• ta ansvar;
• välkomna resultatet som ett mål;
• firar framgång.

Med detta kommer allt annat.

Leon Fire på Twitter, facebook och Medium.

Det finns två strategier när det gäller arv: undvika att arbeta med det till varje pris, eller tappert övervinna de associerade svårigheterna. Vi c DevOpsConf Vi tar den andra vägen, att förändra processer och förhållningssätt. Gå med oss ​​på Youtube, e-postlista и telegram, och tillsammans kommer vi att implementera en DevOps-kultur.

Källa: will.com