Köztudott, hogy egy CTO kompetenciáját csak a második alkalommal teszik próbára, amikor betölti a szerepet. Egy dolog évekig egy cégnél dolgozni, azzal együtt fejlődni, és miközben továbbra is ugyanabban a kulturális kontextusban maradsz, fokozatosan egyre nagyobb felelősséget vállalni. Egészen más dolog egyenesen CTO-szerepkörbe lépni egy olyan cégnél, amelynek problémái vannak a múltban, és egy sor gondot elsöpörtek a szőnyeg alá.

Ebben az értelemben Leon Fayer tapasztalata, amelyet megosztott DevOpsConfNem teljesen egyedi, de a tapasztalatával és a 20 év alatt betöltött számos különböző szerepével együtt nagyon hasznos. Az alábbiakban egy kronológiai sorrendet találunk az elmúlt 90 nap eseményeiről, valamint számos anekdotát, amelyeken jó nevetni, ha mással történnek meg, de személyesen már nem annyira.

Leon nagyon élénken beszél oroszul, ezért ha van 35-40 perced, ajánlom a videó megtekintését. Az időmegtakarítás érdekében a szöveges verzió alább található.

A jelentés első változata egy jól strukturált leírás volt az emberekkel és a folyamatokkal való együttműködésről, hasznos ajánlásokat tartalmazva. De nem tartalmazott minden meglepetést, amivel találkoztam a folyamat során. Ezért megváltoztattam a formátumot, és az új vállalatnál felmerült problémákat, mint egy kakukktojás, és azok kezelésének módszereit időrendi sorrendben mutattam be.

Egy hónappal korábban

Mint sok jó történet, ez is az alkohollal kezdődött. Egy bárban ültünk néhány barátunkkal, és ahogy az az IT-s körökben jellemző, mindenki a problémáira panaszkodott. Az egyikük éppen akkor váltott munkahelyet, és a technológiával, az emberekkel és a csapattal kapcsolatos problémáiról mesélt. Minél jobban hallgattam, annál inkább rájöttem, hogy egyszerűen fel kellene vennie engem, mert pontosan ilyen problémákat oldottam meg az elmúlt 15 évben. El is mondtam neki, és másnap találkoztunk egy munkahelyi környezetben. A cég neve Teaching Strategies volt.

A Teaching Strategies piacvezető a nagyon kisgyermekek – születéstől hároméves korig – számára készült oktatási szoftverek terén. A hagyományos papír alapú vállalat 40 éves, míg a platform digitális SaaS-verziója 10 éves. A digitális technológia vállalati szabványokhoz való igazításának folyamata viszonylag nemrég kezdődött. Az „új” verzió 2017-ben jelent meg, és szinte azonos volt a régivel, csak kevésbé funkcionális.

A legérdekesebb az, hogy ennek a cégnek a forgalma nagyon kiszámítható – napról napra, évről évre pontosan meg lehet jósolni, hogy hányan és mikor fognak jönni. Például délután 13 és 15 óra között az összes óvodai gyerek lefekszik, és a tanárok elkezdik bevinni az információkat. És ez minden nap megtörténik, kivéve hétvégén, mert hétvégén szinte senki sem dolgozik.

Kicsit előretekintve megjegyzem, hogy a munkámat a legnagyobb éves forgalom időszakában kezdtem, ami több okból is érdekes.

A platform, ami látszólag mindössze kétéves volt, egyedi stackkel rendelkezett: a ColdFusionnal és az SQL Serverrel 2008-ból. A ColdFusion, ha nem ismered (és valószínűleg nem), egy vállalati PHP nyelv, ami a 90-es évek közepén jelent meg, és azóta nem is hallottam róla. Volt rajta Ruby, MySQL, PostgreSQL, Java, Go és Python is. De a monolit mag ColdFusionon és SQL Serveren futott.

Problémák

Minél többet beszélgettem a cég alkalmazottaival a munkájukról és az előttük álló kihívásokról, annál inkább rájöttem, hogy a problémák nem csak technikai jellegűek. Oké, a technológia régi volt – dolgoztak már rosszabbal is –, de voltak problémák a csapattal és a folyamatokkal, és a cég kezdte ezt megérteni.

Hagyományosan a tech-szakemberek a sarokban ültek, és a saját dolgukkal foglalkoztak. De egyre több vállalkozás kezdett digitálisan áttérni. Így az utolsó évben, mielőtt ott kezdtem dolgozni, a cég új tagokkal bővült: egy igazgatótanács, egy CTO, egy CPO és egy QA igazgató. Más szóval, a cég elkezdett befektetni a technológiába.

A nehéz örökség nyomai nemcsak a rendszerekben voltak láthatóak. A vállalatnak hagyományos folyamatai, hagyományos emberei és hagyományos kultúrája voltak. Mindezt meg kellett változtatni. Úgy gondoltam, nem lesz unalmas, ezért úgy döntöttem, kipróbálom.

Két nappal korábban

Két nappal az új munkám megkezdése előtt megérkeztem az irodába, kitöltöttem az utolsó papírmunkát, találkoztam a csapattal, és kiderült, hogy egy problémával küzdenek. A probléma az volt, hogy az átlagos oldalbetöltési idő 4 másodpercre ugrott, ami a duplája.

A grafikon alapján ítélve valami egyértelműen félresikerült, és nem volt világos, hogy mi. Kiderült, hogy hálózati késleltetési probléma volt az adatközpontban: az adatközpontban az 5 ms késleltetés 2 másodpercet jelentett a felhasználók számára. Nem tudtam, miért történt ez, de legalább világossá vált, hogy a probléma az adatközpontban volt.

Day 1

Két nap telt el, és az első munkanapomon rájöttem, hogy a probléma nem múlt el.

Két napig átlagosan 4 másodperc alatt töltöttek be a felhasználók oldalai. Megkérdeztem, hogy megtalálták-e a problémát.

- Igen, nyitottunk egy jegyet.
- ÉS?
- Nos, még nem válaszoltak nekünk.

Akkor jöttem rá, hogy mindaz, amit korábban mondtak nekem, csak a jéghegy csúcsa volt, ami ellen meg kell küzdeni.

Van egy jó idézet, ami nagyon illik erre az esetre:

„A technológia megváltoztatásához néha meg kell változtatni a szervezetet.”

De mivel az év legforgalmasabb időszakában kezdtem dolgozni, mind az azonnali, mind a hosszú távú megoldásokat figyelembe kellett vennem. És azzal kellett kezdenem, ami most kritikus volt.

Day 3

Tehát a betöltési idő 4 másodperc, a legnagyobb csúcsok pedig 13 és 15 között vannak.

Ezen időszak harmadik napján a letöltési sebesség így nézett ki:

Az én szemszögemből semmi sem működött. Mindenki más szemszögéből nézve egy kicsit lassabban működött a szokásosnál. De ez nem csak úgy megtörténik – ez egy komoly probléma.

Megpróbáltam meggyőzni a csapatot, de azt mondták, hogy egyszerűen több szerverre van szükségük. Ez kétségtelenül egy megoldás, de korántsem az egyetlen vagy a leghatékonyabb. Megkérdeztem, miért nincs elég szerver, és mekkora a forgalom. Extrapoláltam az adatokat, és azt találtam, hogy másodpercenként körülbelül 150 kérésünk volt, ami általában az ésszerű határokon belül van.

De nem szabad elfelejtenünk, hogy mielőtt megkapnánk a helyes választ, fel kell tennünk a megfelelő kérdést. A következő kérdésem az volt: hány frontend szerverünk van? A válasz kissé „megdöbbentett” – 17 frontend szerverünk volt!

– Szégyellem megkérdezni, de a 150 osztva 17-tel az körülbelül 8? Azt mondod, hogy minden szerver másodpercenként 8 kérést dolgoz fel, és ha holnap 160 kérésünk lesz másodpercenként, akkor még két szerverre lesz szükségünk?

Természetesen nem volt szükségünk további szerverekre. A megoldás magában a kódban volt, ott a felszínen:

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

Volt egy funkció getCurrentClass(), mert a webhelyen minden az osztály kontextusában működik – helyesen. És ehhez az egy függvényhez minden oldalon, 200+ kérés.

A megoldás így nagyon egyszerű volt, még csak át sem kellett írni semmit: csak ne kérd újra ugyanazt az információt.

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

Nagyon örültem, mert azt hittem, hogy már a harmadik napon megtaláltam a fő problémát. Milyen naiv voltam, ez csak egy volt a sok probléma közül.

De az első probléma megoldása sokkal lejjebb vitte a grafikont.

Ezzel egy időben más optimalizációkon is dolgoztunk. Rengeteg dolgot lehetett azonnal javítani. Például azon a harmadik napon felfedeztem, hogy a rendszernek van gyorsítótára (először azt hittem, minden kérés közvetlenül az adatbázisból érkezik). Amikor gyorsítótárra gondolok, a szokásos Redis vagy a Memcached jut eszembe. De ez csak én voltam így, mert abban a rendszerben a gyorsítótárazás MongoDB-t és SQL Servert használt – ugyanazt, amelyikről az előbb olvastuk az adatokat.

Tizedik nap

Az első hetet az azonnal megoldandó problémákkal töltöttem. A második hét környékén először vettem részt egy álló megbeszélésen, hogy beszélgessek a csapattal, megnézzem, mi történik, és hogyan halad az egész folyamat.

Ismét felmerült valami érdekes. A csapat a következő tagokból állt: 18 fejlesztő; 8 tesztelő; 3 menedzser; 2 architect. És mindannyian részt vettek közös rituálékban, ami azt jelentette, hogy minden reggel több mint 30 ember jött el a stand-up gyűlésre, és beszámolt arról, hogy mit csinál. A megbeszélés egyértelműen nem tartott 5 vagy 15 percig. Senki sem hallgatott meg senkit, mert mindenki más rendszeren dolgozott. Ebben a formátumban óránként 2-3 jegy egy grooming ülés során már jó eredménynek számított.

Az első dolog, amit tettünk, az volt, hogy a csapatot több termékvonalra osztottuk. A különböző részlegekhez és rendszerekhez külön csapatokat hoztunk létre, beleértve a fejlesztőket, tesztelőket, termékmenedzsereket és üzleti elemzőket.

Az eredmény a következő volt:

• Az állórendezvények és gyűlések számának csökkentése.
• A termékkel kapcsolatos tárgyi ismeretek.
• A tulajdonlás érzése. Amikor az emberek korábban folyamatosan váltogatták a rendszereket, tudták, hogy a hibáikat valószínűleg valaki más fogja kijavítani, nem ők maguk.
• Csapatok közötti együttműködés. Mondani sem kell, hogy a minőségbiztosítás és a programozók korábban nem sokat kommunikáltak egymással; a termékmenedzser a saját dolgával foglalkozott stb. Most már közös a felelősségi körük.

Fő hangsúlyt fektettünk a hatékonyságra, a termelékenységre és a minőségre – ezeket a problémákat próbáltuk megoldani a csapat átalakításával.

Tizenegyedik nap

A csapatstruktúra átalakításának folyamata során rájöttem, hogyan kell kiszámítani TörténetPont1 SP egy napnak felelt meg, és minden jegy tartalmazott SP-t mind a fejlesztéshez, mind a minőségbiztosításhoz, azaz legalább 2 SP-t.

Hogyan fedeztem fel ezt?

Hibát találtunk: az egyik jelentésben, ahol meg kell adni a jelentéshez szükséges időszak kezdő és befejező dátumát, az utolsó napot nem veszi figyelembe a rendszer. Vagyis valahol a lekérdezésben nem <= volt, hanem egyszerűen <. Azt mondták, hogy ez három történetpont, ami azt jelenti, hogy 3 nap.

Ezután mi:

• Felülvizsgáltuk a történetpont-rendszert. Mostantól a rendszeren keresztül gyorsan feldolgozható kisebb hibajavítások gyorsabban eljutnak a felhasználókhoz.
• Elkezdtük összevonni a kapcsolódó fejlesztési és tesztelési jegyeket. Korábban minden jegy, minden hiba egy zárt ökoszisztéma volt, amely semmi máshoz nem kapcsolódott. Három gomb megváltoztatása egyetlen oldalon három különböző jegyet eredményezhetett három különböző minőségbiztosítási folyamattal, ahelyett, hogy oldalanként egyetlen automatizált tesztet végeztünk volna.
• Elkezdtünk a fejlesztőkkel dolgozni egy megközelítésen a munkaköltségek becslésére. Három nap egyetlen gomb cseréjére nem vicces.

Huszadik nap

Valahol az első hónap közepe táján a helyzet kissé stabilizálódott, rájöttem, hogy mi is történik alapvetően, és elkezdtem a jövőbe tekinteni, valamint hosszú távú megoldásokon gondolkodni.

Hosszútávú célok:

• Felügyelt platform. Az, hogy minden oldalon több száz lekérdezés van, nem komoly.
• Kiszámítható trendek. Voltak időszakos forgalmi csúcsok, amelyek első pillantásra nem tűntek korrelációban más mutatókkal – meg kellett értenünk, hogy miért történt ez, és meg kellett tanulnunk előre jelezni.
• Platformbővítés. A vállalkozás folyamatosan növekszik, egyre több felhasználó érkezik, és a forgalom is növekszik.

Régebben gyakran mondták: "Írjunk át mindent a [nyelvben/keretrendszerben], minden jobban fog működni!"

A legtöbb esetben ez nem működik; jó dolog, ha az átírás egyáltalán működik. Ezért kellett létrehoznunk egy ütemtervet – egy konkrét stratégiát, amely lépésről lépésre bemutatja, hogyan fogjuk elérni üzleti céljainkat (mit fogunk tenni és miért), és amely:

• tükrözi a projekt küldetését és céljait;
• rangsorolja a fő célokat;
• tartalmazza a megvalósításukhoz szükséges ütemtervet.

Ezt megelőzően senki sem beszélte meg a csapattal a változtatások célját. Ehhez megfelelő sikermutatókra van szükség. A vállalat történetében először határoztunk meg KPI-okat a műszaki csapat számára, és ezeket a mutatókat szervezeti mutatókhoz kötöttük.

Más szóval, a szervezeti KPI-kat csapatok támogatják, a csapatok KPI-jait pedig egyéni KPI-k. Ellenkező esetben, ha a folyamat KPI-jai nem illeszkednek a szervezetiekhez, mindenki a saját kezében marad.

Például az egyik szervezeti KPI a piaci részesedés növelése új termékek révén.

Hogyan tudjuk támogatni azt a célt, hogy több új termékünk legyen?

• Először is, több időt szeretnénk új termékek fejlesztésére fordítani a hibák javítása helyett. Ez egy logikus döntés, amely könnyen mérhető.
• Másodszor, támogatni szeretnénk a tranzakciós volumen növekedését, mivel minél nagyobb a piaci részesedés, annál több a felhasználó, és ennek következtében annál nagyobb a forgalom.

Ezután a csoporton belül megvalósítható egyedi KPI-k például ott lesznek elhelyezve, ahol a fő hibák keletkeznek. Ha kifejezetten erre a szakaszra összpontosítunk, jelentősen csökkenthetjük a hibákat, növelhetjük az új termékek fejlesztésére fordított időt, és ismét támogathatjuk a szervezeti KPI-kat.

Ezért minden döntésnek, beleértve a kód átírását is, támogatnia kell a vállalat által kitűzött konkrét célokat (szervezeti növekedés, új funkciók, toborzás).

A folyamat során egy érdekes dolog merült fel, ami nemcsak a műszaki csapat, hanem az egész vállalat számára is újdonság volt: minden ticketnek legalább egy KPI-ra kell összpontosítania. Tehát, ha egy termékmenedzser azt mondja, hogy új funkciót szeretne létrehozni, az első kérdésnek így kell lennie: "Melyik KPI-t támogatja ez a funkció?" Ha egyet sem, akkor sajnálom – felesleges funkciónak tűnik.

Harmincas nap

A hónap végén felfedeztem egy újabb apróságot: az operatív csapatomban senki sem látta soha azokat a szerződéseket, amelyeket az ügyfelekkel kötünk. Felmerülhet a kérdés, hogy miért akarná bárki is látni a kapcsolattartókat?

• Először is, mivel az SLA-k a szerződésekben vannak rögzítve.
• Másodszor, minden SLA más. Minden ügyfél a saját követelményeivel érkezett, és az értékesítési csapat anélkül írta alá azokat, hogy megnézte volna őket.

Egy másik érdekes részlet: az egyik legnagyobb ügyfelünkkel kötött szerződés kimondja, hogy a platform által támogatott összes szoftververziónak n-1-nek kell lennie, ami nem a legújabb, hanem az utolsó előtti verziót jelenti.

Egyértelmű, milyen messze voltunk az n-1-től, ha a platform ColdFusion és SQL Server 2008 alapú lett volna, amelyet júliusban már egyáltalán nem támogattak.

Negyvenötödik nap

Valamikor a második hónap közepe körül volt elég időm leülni és csinálni értékfolyamtérképészet A teljes folyamat. Ezek a szükséges lépések, amelyeket meg kell tenni, a termék létrehozásától a fogyasztóhoz való kiszállításig, és ezeket a lehető legrészletesebben kell leírni.

A folyamatot apró részekre bontod, és megvizsgálod, mi tart túl sokáig, mit lehet optimalizálni, javítani stb. Például mennyi időbe telik, amíg egy termékkérelem átmegy a feldolgozáson, mikor jut el egy olyan tickethez, amelyet egy fejlesztő kezelni tud, minőségbiztosítás stb. Részletesen megvizsgálod az egyes lépéseket, és átgondolod, hogy mit lehet optimalizálni.

Miközben ezt csináltam, két dolog ragadta meg a figyelmemet:

• a minőségbiztosítási részleg által a fejlesztőknek visszaküldött jegyek magas százaléka;
• A pull requestek elbírálása túl sokáig tartott.

A probléma az volt, hogy ezek a következtetések olyanok voltak, mint: úgy tűnik, soká időbe telik, de nem tudjuk pontosan, hogy mennyi időbe telhet.

"Amit nem tudsz mérni, azt nem tudod fejleszteni."

Hogyan tudod igazolni, hogy mennyire súlyos egy probléma? Napok vagy órák elvesztegetéséről van szó?

Ennek mérésére hozzáadtunk néhány lépést a Jira folyamathoz: a „fejlesztésre kész” és a „minőség-ellenőrzésre kész”, hogy megmérjük, mennyi ideig várakozik az egyes jegyek, és hányszor térnek vissza egy adott lépéshez.

Hozzáadtuk az „ellenőrzés alatt” funkciót is, hogy nyomon kövessük a jegyek átlagos ellenőrzési idejét, és onnantól kezdve elkezdhessük a mérést. Már voltak rendszermetrikáink, de most újakat adtunk hozzá, és elkezdtük mérni:

• A folyamat hatékonysága: teljesítmény és a tervezett/megvalósított.
• Folyamatminőség: hibák száma, minőségbiztosítási hibák.

Nagyon sokat segít megérteni, hogy mi megy jól, és mi rosszul.

Ötvenedik nap

Ez mind szép és jó, persze, de a második hónap vége felé történt valami, ami alapvetően kiszámítható volt, bár ilyen mértékűre nem számítottam. Az emberek elkezdtek távozni, mert a felső vezetés megváltozott. Új emberek jöttek a vezetőségbe, és elkezdtek mindent megváltoztatni, a régiek pedig felmondtak. És általában egy néhány éve működő cégnél mindenki barát, és mindenki ismeri egymást.

Ez várható volt, de a leépítések mértéke váratlan volt. Például egy hét alatt két csapatvezető is benyújtotta egyszerre a felmondását. Így nemcsak más problémákról kellett megfeledkeznem, hanem arra is kellett koncentrálnom, hogy csapat létrehozásaEz egy hosszú és nehéz probléma, de meg kellett oldani, mert meg akartuk tartani a maradt embereket (vagy legalábbis a legtöbbjüket). Valahogy reagálnunk kellett a távozók igényeire, hogy fenntartsuk a csapat morálját.

Elméletben ez jó dolog: egy új ember teljes felhatalmazással érkezik, felmérheti a csapat képességeit, és lecserélheti a meglévő személyzetet. A valóságban azonban lehetetlen egyszerűen új embereket behozni különféle okokból. Mindig szükség van az egyensúlyra.

• Régiek és újak. Meg kell tartanunk a régi embereket, akik képesek változtatni és támogatni a küldetést. De ugyanakkor új vért kell hoznunk, amiről kicsit később beszélünk.
• Tapasztalat. Sokat beszéltem jó fiatalokkal, akik lelkesen vártak ránk. De nem tudtam őket felvenni, mert nem volt elég végzős, aki támogatta volna és mentorálta volna őket. Először a legjobbakat kellett felvennünk, és csak utána a fiatalokat.
• Sárgarépa és bot.

Nincs jó válaszom arra a kérdésre, hogy mi a megfelelő egyensúly, hogyan lehet fenntartani, hány embert kell megtartani, és mekkora nyomást kell gyakorolni. Ez egy tisztán egyéni folyamat.

Ötvenegyedik nap

Elkezdtem nézegetni a csapatot, hogy lássam, kik vannak, és ismét eszembe jutott:

„A legtöbb probléma az emberek problémája.”

Azt tapasztaltam, hogy a csapatnak egészében, mind a fejlesztőknek, mind az operátoroknak, három nagy problémával kellett szembenézniük:

• Elégedettség a jelenlegi helyzettel.
• Felelősség hiányában — mert még senki sem fordította le az előadóművészek munkájának eredményeit az üzleti életre gyakorolt ​​hatásukra.
• A változástól való félelem.

A változás mindig kimozdít a komfortzónádból, és minél fiatalabbak az emberek, annál kevésbé szeretik a változást, mert nem értik, miért vagy hogyan. A leggyakoribb válasz, amit hallottam, az volt, hogy „Mi még soha nem csináltuk így.” Ez a teljes abszurditás pontjáig fajult – még a legkisebb változás sem ment volna át anélkül, hogy valaki panaszkodott volna. És függetlenül attól, hogy mennyire befolyásolta a változás a munkájukat, az emberek azt mondták: „Nem, minek erőlködni? Nem fog működni.”

De nem lehetsz jobb anélkül, hogy bármit is megváltoztatnál.

Teljesen abszurd beszélgetést folytattam egy alkalmazottal, elmondtam neki az optimalizálási ötleteimet, amire azt mondta:
- Á, nem láttad, mi volt tavaly!
- És akkor mi van?
- Most sokkal jobb, mint volt.
- Szóval, már nem lehet jobb?
- Miért?

Jó kérdés – miért? Mintha ha a dolgok most jobban mennek, mint régen, akkor minden rendben van. Ez elszámoltathatóság hiányához vezet, ami teljesen normális. Ahogy mondtam, a tech csapat kissé tétlenül hallgatott. A cég úgy gondolta, hogy ott kellene lenniük, de senki sem állított fel szabványokatA technikai támogatás még soha nem látott SLA-t, így a csoport számára tökéletesen "elfogadható" volt (és ez ragadta meg a legjobban):

• 12 másodperces betöltés;
• 5-10 perc leállási idő kiadásonként;
• A kritikus problémák megoldása napokig, sőt hetekig is eltarthat;
• nincs 24 órás/ügyeletes személyzet.

Senki sem próbálta megkérdezni, hogy miért nem lehet jobban csinálni, és senki sem jött rá, hogy ennek nem így kellene lennie.

Ráadásként adódott még egy probléma: tapasztalat hiányaAz idősebbek elmentek, a megmaradt fiatal csapat pedig az előző rezsim alatt nőtt fel, és az megmérgezte őket.

Mindezen felül az emberek féltek a kudarctól és az alkalmatlannak tűnéstől is. Ez abban tükröződött, hogy először is, semmilyen körülmények között nem kért segítségetHányszor beszélgettünk már csoportosan és egyénileg is, és azt mondtam: „Tegyél fel egy kérdést, ha nem tudod, hogyan kell csinálni valamit?” Magabiztos vagyok, és tudom, hogy bármilyen problémát meg tudok oldani, de időbe telik. Szóval, ha megkérdezhetek valakit, aki 10 perc alatt tudja, hogyan kell megoldani, akkor megteszem. Minél kevesebb tapasztalatod van, annál jobban félsz megkérdezni, mert azt hiszed, hogy alkalmatlannak fognak tartani.

Ez a kérdések feltevésétől való félelem érdekes módokon nyilvánul meg. Például megkérdezed: „Hogy halad ez a feladat?”, és azt mondják: „Már csak pár óra múlva, majdnem kész vagyok.” Másnap újra megkérdezed, és azt mondják, hogy minden rendben van, de csak egy probléma van, és az biztosan megoldódik a nap végére. Eltelik még egy nap, és amíg sarokba nem szorítod őket, és rá nem kényszeríted őket, hogy beszéljenek valakivel, a dolgok így folytatódnak. Maguk akarják megoldani a problémát, abban a hitben, hogy ha nem oldják meg maguk, az hatalmas kudarc lesz.

Ezért a fejlesztők felfújták a becsléseketElég vicc volt: amikor egy konkrét feladatról beszélgettünk, mondtak egy számot, amin nagyon meglepődtem. Azt mondták, hogy a fejlesztő a becslésében beleszámítja azt az időt is, amíg a hibajegyet visszaküldik a minőségbiztosítástól (QA), a talált hibák miatti hibajegy-ellenőrzés (PR) idejét, valamint a felülvizsgálatért felelős személyek elfoglaltságát – vagyis mindent, ami lehetséges.

Másodszor, azok az emberek, akik félnek attól, hogy alkalmatlannak tűnnek, túlanalizálAmikor elmondod nekik, hogy pontosan mit kellene tenni, elkezdik azt mondani: „Nem, mi lenne, ha itt gondolkodnánk el rajta?” Ebben az értelemben a mi cégünk nem egyedülálló; ez egy gyakori probléma a fiatalok körében.

Válaszul a következő gyakorlatokat vezettem be:

• A 30 perces szabály. Ha fél óra alatt nem tudod megoldani a problémát, kérj segítséget valaki mástól. Ez változó sikerrel működik, mert az emberek úgysem kérdeznek, de legalább a folyamat elkezdődött.
• Szüntess meg mindent, kivéve a lényegetegy feladat elvégzéséhez szükséges idő becslésénél, azaz csak azt vegye figyelembe, hogy mennyi ideig tart a kód megírása.
• Folyamatos tanulás Azoknak, akik túlanalizálnak. Ez csak állandó munka az emberekkel.

Hatvanadik nap

Miközben mindezt csináltam, ideje volt a költségvetést is átnézni. Természetesen sok érdekes dolgot fedeztem fel a pénzköltésünkkel kapcsolatban. Például egy külön adatközpontban egy egész rackünk volt, amelyben egyetlen FTP-szerver volt, amit egyetlen kliens használt. Kiderült, hogy "...elköltöztünk, de ott maradt, nem cseréltük ki." Ez két évvel ezelőtt történt.

A felhőalapú szolgáltatásról szóló törvény különösen érdekes volt. Biztos vagyok benne, hogy a magas felhőalapú szolgáltatási díj fő oka az, hogy a fejlesztők életükben először korlátlan hozzáféréssel rendelkeznek a szerverekhez. Nem kell megkérdezniük, hogy „Kérem, adjanak egy tesztszervert” – maguk is kipróbálhatják. Ráadásul a fejlesztők mindig olyan menő rendszert akarnak építeni, amit a Facebook és a Netflix is ​​megirigyelne.

A fejlesztőknek azonban nincs tapasztalatuk a szerverbeszerzésben, és nincsenek meg a képességeik a megfelelő szerverméret meghatározásához, mivel korábban nem volt rá szükségük. És gyakran nem értik teljesen a skálázhatóság és a teljesítmény közötti különbséget.

Leltár eredményei:

• Ugyanabból az adatközpontból jött.
• Három naplózó céggel bontottunk fel szerződést. Mivel öt naplózó cégünk volt, minden fejlesztő, aki elkezdett valamivel kísérletezni, újat vett fel.
• Hét AWS rendszert állítottak le. A halott projekteket ismét nem állították le; azok továbbra is működtek.
• A szoftverköltségek hatszorosára csökkentek.

Hetvenötödik nap

Telt az idő, és két és fél hónap múlva találkoznom kellett az igazgatótanáccsal. A mi igazgatótanácsunk nem jobb vagy rosszabb, mint bármelyik másik; mint minden tanács, ez is mindent tudni akar. Az emberek pénzt fektetnek be, és meg akarják érteni, hogy a munkánk hogyan illeszkedik a KPI-jainkhoz.

Az igazgatótanács minden hónapban rengeteg információt kap: a felhasználók számáról, növekedésükről, az általuk használt szolgáltatásokról és azok használatáról, a teljesítményről és a termelékenységről, végül pedig az átlagos oldalbetöltési sebességről.

Az egyetlen probléma az, hogy szerintem az átlag a tiszta gonosz. De ezt nagyon nehéz elmagyarázni az igazgatótanácsnak. Hozzászoktak, hogy összesített számokkal dolgoznak, nem például a másodpercenkénti betöltési idők eloszlásával.

Volt ezzel kapcsolatban néhány érdekes szempont. Például azt mondtam, hogy a forgalmat a tartalom típusától függően külön webszerverek között kell felosztani.

Tehát a ColdFusion a Jettyn ​​és az nginxen keresztül futtatja az oldalakat. A képek, a JS és a CSS pedig egy különálló nginxen keresztül futnak, saját konfigurációkkal. Ez egy meglehetősen bevett gyakorlat, amiről beszélek. írtam Alig néhány évvel ezelőtt. Ennek eredményeként a képek sokkal gyorsabban töltődnek be, és... az átlagos betöltési sebesség 200 ms-mal nőtt.

Ez azért történt, mert a grafikon a Jetty-től származó adatokon alapul. Vagyis a gyors tartalom nem szerepel a számításban – az átlagos érték megugrott. Megértettük ezt, és elnevettük, de hogyan magyarázhattuk volna el az igazgatótanácsnak, hogy miért tettünk valamit, ami 12%-os csökkenést okozott?

Nyolcvanötödik nap

A harmadik hónap végére rájöttem, hogy egy dologra egyáltalán nem számítottam: az időre. Minden, amiről beszéltem, időt igényel.

Ez a tényleges heti naptáram – egy egyszerű munkahét, nem túl zsúfolt. Nincs elég idő mindenre. Szóval, ismét embereket kell toboroznom, akik segítenek a problémák kezelésében.

Következtetés

Ez még nem minden. Ebben a történetben még arra sem tértem ki, hogyan dolgoztunk együtt a termékkel, és hogyan próbáltunk közös nevezőre jutni, hogyan integráltuk a technikai támogatást, vagy hogyan oldottunk meg más technikai problémákat. Például teljesen véletlenül fedeztem fel, hogy nem használjuk a SEQUENCEVan egy saját magunk által írt függvényünk nextID, és ezt nem használják tranzakcióban.

Milliónyi hasonló dologról lehetne hosszasan beszélni. De a legfontosabb, amit érdemes megemlíteni, a kultúra.

A kultúra, vagy annak hiánya, az, ami minden más problémához vezet. Olyan kultúrát próbálunk építeni, ahol az emberek:

• nem félnek a kudarctól;
• tanulni a hibákból;
• együttműködni más csapatokkal;
• kezdeményezőkészséget mutatni;
• vállalni a felelősséget;
• üdvözöld az eredményt gólként;
• ünnepelni a sikert.

Ezzel együtt minden más is jönni fog.

Leon Tűz a Twitteren, Facebook és tovább közepes.

Két stratégia létezik a hagyatékkal való bánásmódra: mindenáron elkerülni, vagy bátran legyőzni a vele járó nehézségeket. DevOpsConf Mi a második utat járjuk, folyamatokat és megközelítéseket változtatunk. Csatlakozzon hozzánk! youtube, levelezőlista и távirat, és együtt fogjuk megvalósítani a DevOps kultúrát.

Forrás: will.com