Het is bekend dat de competentie van de CTO pas wordt getest wanneer hij deze rol voor de tweede keer vervult. Omdat het één ding is om meerdere jaren in een bedrijf te werken, mee te evolueren en, in dezelfde culturele context, geleidelijk meer verantwoordelijkheid te krijgen. En het is iets heel anders om meteen de functie van technisch directeur te bekleden bij een bedrijf met oude bagage en een heleboel problemen netjes onder het tapijt geveegd.

In die zin de ervaring van Leon Fire, waarover hij deelde DevOpsConf, niet bepaald uniek, maar vermenigvuldigd met zijn ervaring en het aantal verschillende rollen dat hij in de loop van twintig jaar heeft weten uit te proberen, is het erg nuttig. Onder de afbeelding staat een chronologie van gebeurtenissen gedurende 20 dagen en een heleboel verhalen die leuk zijn om te lachen als ze iemand anders overkomen, maar die niet zo leuk zijn om persoonlijk onder ogen te zien.

Leon spreekt heel kleurrijk Russisch, dus als je 35-40 minuten de tijd hebt, raad ik je aan de video te bekijken. Tekstversie om tijd te besparen hieronder.

De eerste versie van het rapport was een goed gestructureerde beschrijving van het werken met mensen en processen, met daarin bruikbare aanbevelingen. Maar ze bracht niet alle verrassingen over die ze onderweg tegenkwamen. Daarom veranderde ik het format en presenteerde ik de problemen die voor me opdoken als een soort duveltje in het nieuwe bedrijf, en de methoden om ze op te lossen in chronologische volgorde.

Een maand eerder

Zoals veel goede verhalen begon deze met alcohol. We zaten met vrienden in een bar en zoals verwacht onder IT-specialisten huilde iedereen over hun problemen. Een van hen was net van baan veranderd en had het over zijn problemen met de technologie, met de mensen en met het team. Hoe meer ik luisterde, hoe meer ik besefte dat hij mij gewoon moest inhuren, omdat dit het soort problemen is dat ik de afgelopen vijftien jaar heb opgelost. Ik vertelde het hem, en de volgende dag ontmoetten we elkaar in een werkomgeving. Het bedrijf heette Teaching Strategies.

Teaching Strategies is marktleider op het gebied van leerplannen voor zeer jonge kinderen vanaf de geboorte tot drie jaar. Het traditionele “papieren” bedrijf bestaat al 40 jaar en de digitale SaaS-versie van het platform is 10 jaar oud. Relatief recent is het proces van aanpassing van digitale technologie aan bedrijfsstandaarden begonnen. De “nieuwe” versie werd gelanceerd in 2017 en leek bijna op de oude, alleen werkte deze slechter.

Het meest interessante is dat het verkeer van dit bedrijf zeer voorspelbaar is: van dag tot dag, van jaar tot jaar kun je heel duidelijk voorspellen hoeveel mensen zullen komen en wanneer. Tussen 13 en 15 uur gaan bijvoorbeeld alle kinderen op de kleuterscholen naar bed en beginnen leraren informatie in te voeren. En dit gebeurt elke dag, behalve in het weekend, omdat bijna niemand in het weekend werkt.

Als ik een beetje vooruitkijk, merk ik dat ik met mijn werk ben begonnen tijdens de periode met het hoogste jaarlijkse verkeer, wat om verschillende redenen interessant is.

Het platform, dat nog maar 2 jaar oud leek, had een bijzondere stack: ColdFusion & SQL Server uit 2008. ColdFusion, als je het niet weet, en hoogstwaarschijnlijk weet je het niet, is een zakelijke PHP die halverwege de jaren negentig uitkwam, en sindsdien heb ik er niet eens van gehoord. Ook waren er: Ruby, MySQL, PostgreSQL, Java, Go, Python. Maar de belangrijkste monoliet draaide op ColdFusion en SQL Server.

Problemen

Hoe meer ik met medewerkers van het bedrijf sprak over het werk en welke problemen er tegenkwamen, hoe meer ik besefte dat de problemen niet alleen technisch van aard waren. Oké, de technologie is oud - en ze hebben er niet aan gewerkt, maar er waren problemen met het team en met de processen, en het bedrijf begon dit te begrijpen.

Traditioneel zaten hun techneuten in de hoek en deden ze wat werk. Maar steeds meer zaken begonnen via de digitale versie te gaan. Daarom verschenen er in het laatste jaar voordat ik begon te werken nieuwe mensen in het bedrijf: raad van bestuur, CTO, CPO en QA-directeur. Dat wil zeggen, het bedrijf begon te investeren in de technologiesector.

Sporen van een zware erfenis zaten niet alleen in de systemen. Het bedrijf had oude processen, oude mensen en een oude cultuur. Dit alles moest veranderd worden. Ik dacht dat het zeker niet saai zou zijn en besloot het eens te proberen.

Twee dagen voor

Twee dagen voordat ik aan een nieuwe baan begon, arriveerde ik op kantoor, vulde het laatste papierwerk in, ontmoette het team en ontdekte dat het team op dat moment met een probleem kampte. Het was dat de gemiddelde laadtijd van de pagina steeg naar 4 seconden, dat wil zeggen 2 keer.

Afgaande op de grafiek is er duidelijk iets gebeurd, en het is niet duidelijk wat. Het bleek dat het probleem de netwerklatentie in het datacenter was: een latentie van 5 ms in het datacenter werd voor gebruikers 2 seconden. Ik wist niet waarom dit gebeurde, maar in ieder geval werd bekend dat het probleem in het datacenter zat.

Dag een

Twee dagen gingen voorbij en op mijn eerste werkdag ontdekte ik dat het probleem niet was verdwenen.

Twee dagen lang laadden de pagina's van gebruikers gemiddeld in 4 seconden. Ik vraag of ze hebben gevonden wat het probleem is.

- Ja, we hebben een ticket geopend.
- EN?
- Nou, ze hebben ons nog geen antwoord gegeven.

Toen besefte ik dat alles waar ik eerder over was verteld slechts een klein topje van de ijsberg was waar ik tegen moest vechten.

Er is een goed citaat dat hier heel goed bij past:

“Om de technologie te veranderen, moet je soms de organisatie veranderen.”

Maar aangezien ik in de drukste tijd van het jaar begon te werken, moest ik naar beide opties kijken om het probleem op te lossen: zowel op de snelle als op de lange termijn. En begin met wat op dit moment cruciaal is.

Dag drie

Het laden duurt dus 4 seconden, en van 13 tot 15 zijn de grootste pieken.

Op de derde dag gedurende deze periode zag de downloadsnelheid er als volgt uit:

Vanuit mijn oogpunt werkte helemaal niets. Vanuit het oogpunt van alle anderen liep het iets langzamer dan normaal. Maar zo gebeurt het gewoon niet: het is een serieus probleem.

Ik probeerde het team te overtuigen, waarop ze antwoordden dat ze gewoon meer servers nodig hadden. Dit is uiteraard een oplossing voor het probleem, maar het is niet altijd de enige en meest effectieve oplossing. Ik vroeg waarom er niet genoeg servers waren, wat het verkeersvolume was. Ik heb de gegevens geëxtrapoleerd en vastgesteld dat we ongeveer 150 verzoeken per seconde hebben, wat in principe binnen redelijke grenzen valt.

Maar we mogen niet vergeten dat voordat je het juiste antwoord krijgt, je eerst de juiste vraag moet stellen. Mijn volgende vraag was: hoeveel frontend-servers hebben we? Het antwoord "verbijsterde me een beetje" - we hadden 17 frontend-servers!

– Ik schaam me om het te vragen, maar 150 gedeeld door 17 geeft ongeveer 8? Bedoel je dat elke server 8 verzoeken per seconde toestaat, en als er morgen 160 verzoeken per seconde zijn, hebben we dan nog 2 servers nodig?

Natuurlijk hadden we geen extra servers nodig. De oplossing zat in de code zelf en aan de oppervlakte:

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

Er was een functie getCurrentClass(), omdat alles op de site werkt in de context van een klas - dat klopt. En hiervoor was er op elke pagina één functie 200+ verzoeken.

De oplossing op deze manier was heel eenvoudig, je hoefde niet eens iets te herschrijven: vraag gewoon niet opnieuw om dezelfde informatie.

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

Ik was erg blij omdat ik besloot dat ik pas op de derde dag het grootste probleem had gevonden. Naïef als ik was, dit was slechts een van de vele problemen.

Maar door dit eerste probleem op te lossen, daalde de grafiek veel lager.

Tegelijkertijd waren we bezig met andere optimalisaties. Er waren veel dingen in zicht die gerepareerd konden worden. Zo ontdekte ik op dezelfde derde dag dat er toch een cache in het systeem zat (in eerste instantie dacht ik dat alle verzoeken rechtstreeks uit de database kwamen). Als ik aan een cache denk, denk ik aan standaard Redis of Memcached. Maar ik was de enige die dat dacht, omdat dat systeem MongoDB en SQL Server gebruikte voor caching - hetzelfde systeem waaruit de gegevens zojuist waren gelezen.

Dag tien

De eerste week heb ik problemen aangepakt die nu opgelost moesten worden. Ergens in de tweede week kwam ik voor het eerst naar de stand-up om met het team te communiceren, om te zien wat er gebeurde en hoe het hele proces verliep.

Er werd weer iets interessants ontdekt. Het team bestond uit: 18 ontwikkelaars; 8 testers; 3 beheerders; 2 architecten. En ze namen allemaal deel aan gemeenschappelijke rituelen, dat wil zeggen dat er elke ochtend meer dan 30 mensen naar de stand-up kwamen en vertelden wat ze deden. Het is duidelijk dat de bijeenkomst geen 5 of 15 minuten duurde. Niemand luisterde naar iemand omdat iedereen op verschillende systemen werkt. In deze vorm was 2-3 kaartjes per uur voor een trimsessie al een goed resultaat.

Het eerste wat we deden was het team opsplitsen in verschillende productlijnen. Voor verschillende secties en systemen hebben we aparte teams toegewezen, waaronder ontwikkelaars, testers, productmanagers en bedrijfsanalisten.

Als resultaat kregen we:

• Het verminderen van stand-ups en rally’s.
• Vakkennis van het product.
• Een gevoel van eigenaarschap. Toen mensen de hele tijd aan systemen sleutelden, wisten ze dat iemand anders hoogstwaarschijnlijk met hun bugs zou moeten werken, maar niet zijzelf.
• Samenwerking tussen groepen. Onnodig te zeggen dat QA voorheen niet veel met programmeurs communiceerde, het product deed zijn eigen ding, enz. Nu hebben ze een gemeenschappelijk verantwoordelijkheidspunt.

We hebben ons vooral gericht op efficiëntie, productiviteit en kwaliteit - dit zijn de problemen die we probeerden op te lossen met de transformatie van het team.

Dag elf

Tijdens het veranderen van de teamstructuur ontdekte ik hoe ik moest tellen VerhaalPunten. 1 SP was gelijk aan één dag, en elk ticket bevatte SP voor zowel ontwikkeling als QA, dat wil zeggen minimaal 2 SP.

Hoe heb ik dit ontdekt?

We hebben een bug gevonden: in een van de rapportages, waar de begin- en einddatum van de periode waarvoor de rapportage nodig is, wordt ingevuld, wordt geen rekening gehouden met de laatste dag. Dat wil zeggen dat er ergens in het verzoek niet <= stond, maar eenvoudigweg <. Er is mij verteld dat dit drie Story Points zijn 3 dagen.

Hierna:

• Het Story Points-beoordelingssysteem is herzien. Reparaties voor kleine bugs die snel door het systeem kunnen worden doorgegeven, bereiken de gebruiker nu sneller.
• We zijn begonnen met het samenvoegen van gerelateerde tickets voor ontwikkeling en testen. Voorheen was elk ticket en elke bug een gesloten ecosysteem, niet aan iets anders gebonden. Het veranderen van drie knoppen op één pagina had kunnen neerkomen op drie verschillende tickets met drie verschillende QA-processen in plaats van één geautomatiseerde test per pagina.
• We zijn met ontwikkelaars gaan werken aan een aanpak voor het schatten van de arbeidskosten. Drie dagen om één knop te veranderen is niet grappig.

Dag twintigste

Ergens halverwege de eerste maand stabiliseerde de situatie zich een beetje, ik ontdekte wat er feitelijk aan de hand was en begon al in de toekomst te kijken en na te denken over langetermijnoplossingen.

Langetermijndoelen:

• Beheerd platform. Honderden verzoeken op elke pagina zijn niet serieus.
• Voorspelbare trends. Er waren periodieke verkeerspieken die op het eerste gezicht niet correleerden met andere statistieken. We moesten begrijpen waarom dit gebeurde en leren voorspellen.
• Platformuitbreiding. Het bedrijf groeit voortdurend, er komen steeds meer gebruikers en het verkeer neemt toe.

Vroeger werd vaak gezegd: “Laten we alles in [taal/framework] herschrijven, alles zal beter werken!”

In de meeste gevallen werkt dit niet, het is goed als het herschrijven überhaupt werkt. Daarom moesten we een routekaart opstellen – een specifieke strategie die stap voor stap illustreert hoe de bedrijfsdoelstellingen zullen worden bereikt (wat we zullen doen en waarom), die:

• weerspiegelt de missie en doelstellingen van het project;
• geeft prioriteit aan de hoofddoelen;
• bevat een schema om deze te bereiken.

Voordien had niemand met het team gesproken over het doel van eventuele wijzigingen. Dit vereist de juiste successtatistieken. Voor het eerst in de geschiedenis van het bedrijf hebben we KPI's vastgesteld voor de technische groep, en deze indicatoren waren gekoppeld aan organisatorische indicatoren.

Dat wil zeggen dat organisatie-KPI's worden ondersteund door teams, en team-KPI's worden ondersteund door individuele KPI's. Anders, als de technologische KPI's niet samenvallen met de organisatorische, trekt iedereen de deken over zichzelf heen.

Eén van de organisatorische KPI’s is bijvoorbeeld het vergroten van het marktaandeel door middel van nieuwe producten.

Hoe kunt u het doel van meer nieuwe producten ondersteunen?

• Ten eerste willen we meer tijd besteden aan het ontwikkelen van nieuwe producten in plaats van aan het oplossen van defecten. Dit is een logische oplossing die eenvoudig te meten is.
• Ten tweede willen we een toename van het transactievolume ondersteunen, want hoe groter het marktaandeel, hoe meer gebruikers en dus hoe meer verkeer.

Dan komen individuele KPI’s die binnen de groep uitgevoerd kunnen worden bijvoorbeeld op de plek waar de belangrijkste gebreken vandaan komen. Als je je specifiek op dit onderdeel concentreert, kun je ervoor zorgen dat er veel minder defecten zijn, en dan zal de tijd voor het ontwikkelen van nieuwe producten en opnieuw voor het ondersteunen van organisatorische KPI's toenemen.

Elke beslissing, inclusief het herschrijven van de code, moet dus de specifieke doelen ondersteunen die het bedrijf voor ons heeft gesteld (organisatiegroei, nieuwe functies, werving).

Tijdens dit proces kwam er iets interessants aan het licht, dat niet alleen nieuws werd voor techneuten, maar in het algemeen voor het bedrijf: alle tickets moeten op minstens één KPI gericht zijn. Dat wil zeggen, als een product zegt dat het een nieuwe functie wil toevoegen, moet de eerste vraag worden gesteld: “Welke KPI ondersteunt deze functie?” Zo niet, sorry dan, het lijkt een onnodige functie.

Dag dertig

Aan het eind van de maand ontdekte ik nog een nuance: niemand in mijn Ops-team heeft ooit de contracten gezien die we met klanten sluiten. U kunt zich afvragen waarom u contacten wilt zien.

• Ten eerste omdat SLA’s vastgelegd zijn in contracten.
• Ten tweede zijn SLA's allemaal verschillend. Elke klant kwam met zijn eigen eisen en de verkoopafdeling tekende zonder te kijken.

Een andere interessante nuance is dat in het contract met een van de grootste klanten staat dat alle softwareversies die door het platform worden ondersteund, n-1 moeten zijn, dat wil zeggen niet de nieuwste versie, maar de voorlaatste.

Het is duidelijk hoe ver we van n-1 verwijderd waren als het platform gebaseerd was op ColdFusion en SQL Server 2008, dat in juli helemaal niet meer ondersteund werd.

Dag vijfenveertig

Rond het midden van de tweede maand had ik genoeg tijd om te gaan zitten en dingen te doen waardestreamin kaart brengen volledig voor het hele proces. Dit zijn de noodzakelijke stappen die moeten worden genomen, van het creëren van een product tot het leveren ervan aan de consument, en ze moeten zo gedetailleerd mogelijk worden beschreven.

Je deelt het proces op in kleine stukjes en kijkt wat te veel tijd kost, wat geoptimaliseerd, verbeterd kan worden, etc. Hoe lang duurt het bijvoorbeeld voordat een productverzoek door de verzorging gaat, wanneer komt het tot een ticket dat een ontwikkelaar kan nemen, QA, enz. Je bekijkt dus elke afzonderlijke stap gedetailleerd en denkt na over wat er geoptimaliseerd kan worden.

Toen ik dit deed, vielen mij twee dingen op:

• hoog percentage tickets dat via QA teruggaat naar ontwikkelaars;
• Het beoordelen van pull-aanvragen duurde te lang.

Het probleem was dat dit conclusies waren als: het lijkt veel tijd te kosten, maar we weten niet zeker hoe lang.

"Je kunt niet verbeteren wat je niet kunt meten."

Hoe rechtvaardig je de ernst van het probleem? Verspilt het dagen of uren?

Om dit te meten hebben we een aantal stappen aan het Jira-proces toegevoegd: ‘ready for dev’ en ‘ready for QA’ om te meten hoe lang elk ticket wacht en hoe vaak het terugkeert naar een bepaalde stap.

We hebben ook ‘in beoordeling’ toegevoegd om te weten hoeveel tickets er gemiddeld ter beoordeling zijn, en van daaruit kun je beginnen met dansen. We hadden systeemstatistieken, nu hebben we nieuwe statistieken toegevoegd en zijn we begonnen met meten:

• Procesefficiëntie: prestaties en gepland/geleverd.
• Proceskwaliteit: aantal defecten, defecten van QA.

Het helpt echt om te begrijpen wat er goed gaat en wat niet goed gaat.

Dag vijftig

Dit is natuurlijk allemaal goed en interessant, maar tegen het einde van de tweede maand gebeurde er iets dat in principe voorspelbaar was, hoewel ik zo'n omvang niet had verwacht. Mensen vertrokken omdat het topmanagement was veranderd. Nieuwe mensen kwamen in het management en begonnen alles te veranderen, en de oude stopten. En meestal is in een bedrijf dat al enkele jaren bestaat iedereen vrienden en kent iedereen elkaar.

Dit was verwacht, maar de omvang van de ontslagen was onverwacht. In één week tijd dienden bijvoorbeeld twee teamleiders tegelijkertijd uit eigen vrije wil hun ontslag in. Daarom moest ik niet alleen andere problemen vergeten, maar me ook concentreren het creëren van een team. Dit is een lang en moeilijk probleem om op te lossen, maar het moest worden aangepakt omdat ik de mensen die achterbleven (of de meeste van hen) wilde redden. Het was nodig om op de een of andere manier te reageren op het feit dat mensen vertrokken om het moreel in het team te behouden.

In theorie is dit goed: er komt een nieuwe persoon binnen die volledige carte blanche heeft, die de vaardigheden van het team kan beoordelen en personeel kan vervangen. Sterker nog, je kunt om zoveel redenen niet zomaar nieuwe mensen binnenhalen. Er is altijd evenwicht nodig.

• Oud en nieuw. We moeten oude mensen behouden die kunnen veranderen en de missie steunen. Maar tegelijkertijd moeten we nieuw bloed binnenhalen, daar zullen we later over praten.
• Ervaring. Ik heb veel gesproken met goede junioren die enthousiast waren en graag bij ons wilden werken. Maar ik kon ze niet aannemen omdat er niet genoeg senioren waren om de junioren te ondersteunen en als mentor voor hen op te treden. Het was noodzakelijk om eerst de top te rekruteren en pas daarna de jeugd.
• Wortel en stok.

Ik heb geen goed antwoord op de vraag wat de juiste balans is, hoe je die in stand kunt houden, hoeveel mensen je moet behouden en hoeveel je moet pushen. Dit is een puur individueel proces.

Dag eenenvijftig

Ik begon goed naar het team te kijken om te begrijpen wie ik had, en opnieuw herinnerde ik me:

“De meeste problemen zijn mensenproblemen.”

Ik heb ontdekt dat het team als zodanig – zowel Dev als Ops – drie grote problemen heeft:

• Tevredenheid over de huidige stand van zaken.
• Gebrek aan verantwoordelijkheid - omdat niemand ooit de resultaten van het werk van de artiesten heeft gebruikt om het bedrijf te beïnvloeden.
• Angst voor verandering.

Verandering haalt je altijd uit je comfortzone, en hoe jonger mensen zijn, hoe meer ze een hekel hebben aan verandering, omdat ze niet begrijpen waarom en niet hoe. Het meest voorkomende antwoord dat ik heb gehoord is: "Dat hebben we nog nooit gedaan." Bovendien bereikte het het punt van volledige absurditeit: de kleinste veranderingen konden niet plaatsvinden zonder dat iemand verontwaardigd was. En hoezeer de veranderingen ook hun werk beïnvloedden, mensen zeiden: “Nee, waarom? Dit zal niet werken."

Maar je kunt niet beter worden zonder iets te veranderen.

Ik had een absoluut absurd gesprek met een medewerker, ik vertelde hem mijn ideeën voor optimalisatie, waarop hij mij vertelde:
- Oh, je hebt niet gezien wat we vorig jaar hadden!
- Dus?
“Nu is het veel beter dan het was.”
- Dus het kan niet beter worden?
- Waarvoor?

Goede vraag - waarom? Het is alsof het nu beter is dan het was, dan is alles goed genoeg. Dit leidt tot een gebrek aan verantwoordelijkheid, wat in principe volkomen normaal is. Zoals ik al zei, stond de technische groep een beetje aan de zijlijn. Het bedrijf geloofde dat ze zouden moeten bestaan, maar niemand heeft ooit de normen bepaald. Technische ondersteuning heeft de SLA nooit gezien, dus het was behoorlijk “acceptabel” voor de groep (en dit viel mij het meest op):

• 12 seconden laden;
• 5-10 minuten downtime per release;
• Het oplossen van kritieke problemen duurt dagen en weken;
• gebrek aan dienstdoend personeel 24x7 / oproepbaar.

Niemand heeft zich ooit afgevraagd waarom we het niet beter zouden doen, en niemand heeft zich ooit gerealiseerd dat het niet zo hoeft te zijn.

Als bonus was er nog een probleem: gebrek aan ervaring. De senioren vertrokken en het overgebleven jonge team groeide op onder het vorige regime en werd erdoor vergiftigd.

Bovendien waren mensen ook bang om te falen en incompetent over te komen. Dit komt tot uiting in het feit dat ze in de eerste plaats onder geen beding om hulp gevraagd. Hoe vaak hebben we niet als groep en individueel gesproken, en heb ik gezegd: “Stel een vraag als je niet weet hoe je iets moet doen.” Ik heb vertrouwen in mezelf en weet dat ik elk probleem kan oplossen, maar het zal tijd kosten. Daarom, als ik iemand kan vragen die weet hoe ik het in 10 minuten moet oplossen, zal ik het vragen. Hoe minder ervaring je hebt, hoe banger je bent om vragen te stellen, omdat je denkt dat je als incompetent wordt beschouwd.

Deze angst om vragen te stellen manifesteert zich op interessante manieren. Je vraagt ​​bijvoorbeeld: “Hoe gaat het met deze taak?” - “Nog een paar uur, ik ben al klaar.” De volgende dag vraag je het opnieuw en krijg je het antwoord dat alles in orde is, maar er was één probleem: het zal zeker aan het eind van de dag klaar zijn. Er gaat weer een dag voorbij, en totdat je aan de muur vastzit en gedwongen wordt met iemand te praten, gaat dit door. Iemand wil een probleem zelf oplossen; hij gelooft dat als hij het niet zelf oplost, het een grote mislukking zal zijn.

Het is precies dat de ontwikkelaars hebben de schattingen opgeblazen. Het was diezelfde anekdote, toen ze een bepaalde taak bespraken, gaven ze me zo'n cijfer dat ik zeer verrast was. Waarop mij werd verteld dat de ontwikkelaar in de schattingen van de ontwikkelaar rekening houdt met de tijd dat het ticket wordt geretourneerd door QA, omdat ze daar fouten zullen vinden, en de tijd die de PR zal duren, en de tijd waarin de mensen die moeten beoordelen het zal druk zijn - dat wil zeggen, alles, wat maar mogelijk is.

Ten tweede mensen die bang zijn om incompetent over te komen overanalyseren. Als je zegt wat er precies moet gebeuren, begint het: “Nee, wat als we er hier eens over nadenken?” In die zin is ons bedrijf niet uniek; het is een standaardprobleem bij jongeren.

Als reactie hierop heb ik de volgende praktijken geïntroduceerd:

• Regel 30 minuten. Als u het probleem niet binnen een half uur kunt oplossen, vraag dan iemand om u te helpen. Dit werkt met wisselend succes, omdat mensen nog steeds niet vragen, maar het proces is tenminste begonnen.
• Elimineer alles behalve de essentie, bij het schatten van de deadline voor het voltooien van een taak, dat wil zeggen, houd er alleen rekening mee hoe lang het zal duren om de code te schrijven.
• Continu lerende voor degenen die overanalyseren. Het is gewoon voortdurend met mensen werken.

Dag zestig

Terwijl ik dit allemaal deed, was het tijd om het budget te bepalen. Natuurlijk heb ik veel interessante dingen gevonden over waar we ons geld aan uitgeven. Zo hadden we een heel rack in een apart datacenter met één FTP-server, die door één klant werd gebruikt. Het bleek dat “... we zijn verhuisd, maar hij bleef zo, we hebben hem niet veranderd.” Het was 2 jaar geleden.

Van bijzonder belang was de rekening voor clouddiensten. Ik geloof dat de belangrijkste reden voor de hoge cloudrekening de ontwikkelaars zijn die voor het eerst in hun leven onbeperkte toegang hebben tot servers. Ze hoeven niet te vragen: “Geef me alsjeblieft een testserver”, ze kunnen het zelf doen. Bovendien willen ontwikkelaars altijd zo'n cool systeem bouwen dat Facebook en Netflix jaloers zullen zijn.

Maar de ontwikkelaars hebben geen ervaring met het kopen van servers en de vaardigheid om de vereiste grootte van servers te bepalen, omdat ze deze eerder niet nodig hadden. En ze begrijpen meestal niet helemaal het verschil tussen schaalbaarheid en prestaties.

Voorraadresultaten:

• We verlieten hetzelfde datacenter.
• We hebben het contract met 3 logdiensten beëindigd. Omdat we er vijf hadden, nam elke ontwikkelaar die ergens mee begon te spelen een nieuwe.
• 7 AWS-systemen werden afgesloten. Nogmaals, niemand stopte de dode projecten; ze bleven allemaal werken.
• Softwarekosten zes keer verlaagd.

Dag vijfenzeventig

De tijd verstreek en binnen twee en een halve maand moest ik de raad van bestuur ontmoeten. Onze raad van bestuur is niet beter of slechter dan anderen; net als alle raden van bestuur wil hij alles weten. Mensen investeren geld en willen begrijpen in hoeverre wat wij doen binnen de gestelde KPI’s past.

De raad van bestuur ontvangt elke maand veel informatie: het aantal gebruikers, hun groei, welke diensten ze gebruiken en hoe, prestaties en productiviteit, en tot slot de gemiddelde laadsnelheid van pagina's.

Het enige probleem is dat ik geloof dat het gemiddelde puur kwaadaardig is. Maar het is heel moeilijk om dit aan de raad van bestuur uit te leggen. Ze zijn gewend om met geaggregeerde aantallen te werken, en niet bijvoorbeeld met de spreiding van laadtijden per seconde.

Er waren in dit verband enkele interessante punten. Ik zei bijvoorbeeld dat we het verkeer moeten verdelen over afzonderlijke webservers, afhankelijk van het type inhoud.

Dat wil zeggen, ColdFusion doorloopt Jetty en nginx en lanceert de pagina's. En afbeeldingen, JS en CSS doorlopen een aparte nginx met hun eigen configuraties. Dit is een vrij standaardpraktijk waar ik het over heb ik schreef een paar jaar geleden. Als gevolg hiervan laden foto's veel sneller en... is de gemiddelde laadsnelheid met 200 ms toegenomen.

Dit gebeurde omdat de grafiek is gebouwd op basis van de gegevens die bij Jetty worden geleverd. Dat wil zeggen dat snelle inhoud niet in de berekening is opgenomen - de gemiddelde waarde is gestegen. Voor ons was dit duidelijk, we lachten, maar hoe kunnen we aan de raad van bestuur uitleggen waarom we iets hebben gedaan en de situatie met 12% is verergerd?

Dag vijfentachtig

Aan het einde van de derde maand besefte ik dat er één ding was waar ik helemaal niet op had gerekend: tijd. Alles waar ik over sprak, kost tijd.

Dit is mijn echte weekkalender - gewoon een werkweek, niet erg druk. Er is niet genoeg tijd voor alles. Daarom moet u opnieuw mensen rekruteren die u zullen helpen de problemen het hoofd te bieden.

Conclusie

Dat is niet alles. In dit verhaal ben ik nog niet eens ingegaan op de manier waarop we met het product werkten en probeerden af ​​te stemmen op de algemene golf, of hoe we technische ondersteuning integreerden, of hoe we andere technische problemen oplosten. Ik heb bijvoorbeeld heel toevallig geleerd dat we de grootste tabellen in de database niet gebruiken SEQUENCE. We hebben een zelfgeschreven functie nextIDen wordt niet gebruikt in een transactie.

Er waren nog een miljoen soortgelijke dingen waar we nog lang over konden praten. Maar het belangrijkste dat nog gezegd moet worden is cultuur.

Het is de cultuur, of het gebrek daaraan, die tot alle andere problemen leidt. We proberen een cultuur op te bouwen waarin mensen:

• zijn niet bang voor mislukkingen;
• leer van fouten;
• samenwerken met andere teams;
• initiatief nemen;
• verantwoordelijkheid nemen;
• verwelkom het resultaat als doel;
• succes vieren.

Hiermee zal al het andere komen.

Leon Vuur twitter, facebook en Medium.

Er zijn twee strategieën met betrekking tot erfenis: vermijd er ten koste van alles mee te werken, of overwin moedig de daarmee samenhangende moeilijkheden. Wij c DevOpsConf Wij volgen het tweede pad, waarbij we processen en benaderingen veranderen. Wordt lid van ons op youtube, nieuwsbrief и telegram, en samen zullen we een DevOps-cultuur implementeren.

Bron: www.habr.com