Ismeretes, hogy a CTO kompetenciáját csak akkor tesztelik, amikor ezt a szerepet másodszor látja el. Mert egy dolog több évet egy cégnél dolgozni, vele együtt fejlődni, és ugyanabban a kulturális környezetben fokozatosan nagyobb felelősséget kapni. Az pedig egészen más, ha egy cég műszaki igazgatói posztjára kerül sor, ahol örökölt poggyászok vannak, és egy rakás problémát szépen a szőnyeg alá söpörtek.

Ebben az értelemben Leon Fire tapasztalata, amelyet megosztott DevOpsConf, nem éppen egyedi, de megsokszorozva tapasztalataival és a 20 év alatt felpróbált különböző szerepekkel, nagyon hasznos. A vágás alatt a 90 napon át tartó események kronológiája látható, és sok olyan történet, amelyen szórakoztató nevetni, ha valaki mással történik, de nem olyan szórakoztató személyesen szembesülni velük.

Leon nagyon színesen beszél oroszul, így ha van 35-40 perced, ajánlom a videó megtekintését. Szöveges verzió az időmegtakarítás érdekében lent.

A jelentés első változata az emberekkel és folyamatokkal végzett munka jól strukturált leírása volt, amely hasznos ajánlásokat tartalmazott. De nem közvetített minden meglepetést, amivel az út során találkoztak. Ezért formátumot változtattam, és az új cégnél jack-in-the-boxként felbukkanó problémákat, azok megoldási módjait időrendi sorrendben mutattam be.

Egy hónappal korábban

Mint sok jó történet, ez is az alkohollal kezdődött. Barátokkal ültünk egy bárban, és ahogy az informatikusok körében várható volt, mindenki sírt a problémái miatt. Egyikük éppen munkahelyet váltott, és a technológiával, az emberekkel és a csapattal kapcsolatos problémáiról beszélt. Minél többet hallgattam, annál inkább rájöttem, hogy fel kellene vennie, mert ilyen típusú problémákat oldottam meg az elmúlt 15 évben. Elmondtam neki, és másnap munkakörnyezetben találkoztunk. A cég neve Teaching Strategies.

A Teaching Strategies piacvezető a nagyon kisgyermekek születésétől három éves korukig szóló tananyagában. A hagyományos „papír” cég már 40 éves, a platform digitális SaaS változata pedig 10 éves.Viszonylag nemrég indult meg a digitális technológia vállalati szabványokhoz való igazítása. Az „új” verzió 2017-ben jelent meg, és majdnem olyan volt, mint a régi, csak rosszabbul működött.

A legérdekesebb dolog az, hogy ennek a cégnek a forgalma nagyon kiszámítható - napról napra, évről évre nagyon egyértelműen megjósolhatja, hány ember fog eljönni és mikor. Például délután 13 és 15 óra között az óvodában minden gyerek lefekszik, és a tanárok elkezdik beírni az információkat. És ez minden nap megtörténik, kivéve a hétvégéket, mert hétvégén szinte senki sem dolgozik.

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

A mindössze 2 évesnek tűnő platformnak volt egy sajátos stackje: ColdFusion & SQL Server 2008-ból. A ColdFusion, ha nem ismeri, és nagy valószínűséggel nem is tudja, egy vállalati PHP, amely a 90-es évek közepén jelent meg, és azóta nem is hallottam róla. Voltak még: Ruby, MySQL, PostgreSQL, Java, Go, Python. De a fő monolit ColdFusion és SQL Server rendszeren futott.

Problémák

Minél többet beszéltem a cég alkalmazottaival a munkáról és a felmerülő problémákról, annál inkább rájöttem, hogy a problémák nem csak technikai jellegűek. Oké, a technológia régi – és nem dolgoztak rajta, de problémák akadtak a csapattal és a folyamatokkal, és a cég ezt kezdte megérteni.

Hagyományosan a technikusaik a sarokban ültek, és valamilyen munkát végeztek. De egyre több üzlet kezdett átmenni a digitális változaton. Ezért a munkába állásom előtti utolsó évben újak jelentek meg a cégnél: igazgatóság, CTO, CPO és QA igazgató. Vagyis a cég elkezdett befektetni a technológiai szektorba.

A súlyos örökség nyomai nemcsak a rendszerekben voltak. A vállalat örökölt folyamatokkal, örökölt emberekkel, örökölt kultúrával rendelkezett. Mindezen változtatni kellett. Úgy gondoltam, hogy biztosan nem lesz unalmas, és úgy döntöttem, hogy kipróbálom.

két nappal előtte

Két nappal az új munka megkezdése előtt megérkeztem az irodába, kitöltöttem az utolsó papírokat, találkoztam a csapattal, és rájöttem, hogy a csapat akkoriban problémával küzd. Volt, hogy az átlagos oldalbetöltési idő 4 másodpercre, azaz 2-szeresére ugrott.

A grafikonból ítélve egyértelműen történt valami, és nem világos, hogy mi. Kiderült, hogy a probléma a hálózati késleltetés volt az adatközpontban: az 5 ms-os késleltetés az adatközpontban 2 másodpercre változott a felhasználók számára. Nem tudtam, miért történt ez, de mindenesetre ismertté vált, hogy a probléma az adatközpontban van.

Day 1

Eltelt két nap, és az első munkanapomon rájöttem, hogy a probléma nem szűnt meg.

Két nap alatt a felhasználók oldalai átlagosan 4 másodperc alatt töltődnek be. Megkérdezem, hogy megtalálták-e, mi a probléma.

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

Aztán rájöttem, hogy mindaz, amiről korábban meséltek, csak a jéghegy kis csúcsa, amivel meg kell küzdenem.

Van egy jó idézet, ami nagyon illik ehhez:

"Néha a technológia megváltoztatásához meg kell változtatni a szervezetet."

Ám mivel az év legforgalmasabb időszakában kezdtem el dolgozni, mindkét lehetőséget meg kellett vizsgálnom a probléma megoldására: gyors és hosszú távú. És kezdje azzal, ami most kritikus.

Day 3

Tehát a betöltés 4 másodpercig tart, és 13-tól 15-ig a legnagyobb csúcsok.

A harmadik napon ebben az időszakban 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 a szokásosnál kicsit lassabban futott. De ez nem így történik – ez egy komoly probléma.

Megpróbáltam meggyőzni a csapatot, amire azt válaszolták, hogy egyszerűen több szerverre van szükségük. Ez természetesen megoldás a problémára, de nem mindig az egyetlen és a leghatékonyabb. Megkérdeztem, miért nincs elég szerver, mekkora a forgalom. Extrapoláltam az adatokat, és megállapítottam, hogy körülbelül 150 kérésünk van másodpercenként, ami elvileg az ésszerű határok közé esik.

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

- Szégyellem megkérdezni, de 150 osztva 17-tel körülbelül 8-at ad? Azt akarod mondani, hogy minden szerver 8 kérést engedélyez másodpercenként, és ha holnap 160 kérés lesz másodpercenként, akkor szükségünk lesz még 2 szerverre?

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

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

Volt egy funkció getCurrentClass(), mert az oldalon minden egy osztály keretében működik – ez így van. És ehhez minden oldalon egy funkció volt 200+ kérés.

A megoldás így nagyon egyszerű volt, nem is kellett semmit átírni: csak ne kérdezd ú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 boldog voltam, mert úgy döntöttem, hogy csak a harmadik napon találtam meg a fő problémát. Bármilyen naiv is voltam, ez csak egy probléma volt a sok közül.

De ennek az első feladatnak a megoldása sokkal lejjebb dobta a grafikont.

Ezzel egyidőben egyéb optimalizálásokat is végeztünk. Rengeteg olyan dolog volt látható, amit meg lehetett javítani. Például ugyanazon a harmadik napon fedeztem fel, hogy mégis van egy gyorsítótár a rendszerben (először azt hittem, hogy minden kérés közvetlenül az adatbázisból érkezik). Amikor a gyorsítótárra gondolok, a szabványos Redis vagy a Memcached jut eszembe. De csak én gondoltam így, mert az a rendszer a MongoDB-t és az SQL Servert használta a gyorsítótárazáshoz – ugyanazt, amelyről az adatokat éppen kiolvasták.

Tizedik nap

Az első héten olyan problémákkal foglalkoztam, amelyeket most kellett megoldani. Valahol a második héten jöttem először a stand-uphoz, hogy kommunikáljak a csapattal, lássam, mi történik és hogyan zajlik az egész folyamat.

Megint kiderült valami érdekes. A csapat a következőkből állt: 18 fejlesztő; 8 tesztelő; 3 vezető; 2 építész. És mindannyian részt vettek a közös rituálékon, vagyis minden reggel több mint 30 ember jött el a stand-uphoz, és mesélte el, mit csinált. Nyilvánvaló, hogy az ülés nem 5 vagy 15 percig tartott. Senki nem hallgatott senkire, mert mindenki más rendszeren dolgozik. Ebben a formában óránként 2-3 jegy ápolásra már jó eredménynek számított.

Az első dolgunk az volt, hogy a csapatot több termékvonalra osztottuk. A különböző szekciókhoz és rendszerekhez külön csapatokat jelöltünk ki, amelyekben fejlesztők, tesztelők, termékmenedzserek és üzleti elemzők voltak.

Ennek eredményeként a következőket kaptuk:

• A stand-upok és a gyűlések csökkentése.
• A termék tantárgyi ismerete.
• A tulajdonosi érzés. Amikor az emberek állandóan bütykölték a rendszereket, tudták, hogy nagy valószínűséggel valaki másnak kell dolgoznia a hibákkal, de nem saját maguknak.
• Csoportok közötti együttműködés. Mondanom sem kell, hogy a QA korábban nem nagyon kommunikált a programozókkal, a termék megtette a magáét stb. Most közös a felelősségük.

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

Tizenegyedik nap

A csapatstruktúra megváltoztatása során rájöttem, hogyan kell számolni TörténetPont. 1 SP egyenlő volt egy nappal, és minden jegy tartalmazott SP-t mind a fejlesztésre, mind a minőségbiztosításra, azaz legalább 2 SP-t.

Hogyan fedeztem fel ezt?

Hibát találtunk: az egyik jelentésben, ahol annak az időszaknak a kezdő és záró dátuma van megadva, amelyre a jelentésre van szükség, az utolsó napot nem veszi figyelembe. Vagyis valahol a kérésben nem <= volt, hanem egyszerűen <. Azt mondták nekem, hogy ez három történetpont 3 nap.

Ezek után mi:

• A Story Points értékelési rendszerét felülvizsgálták. Mostantól a rendszeren gyorsan átvihető kisebb hibák javításai gyorsabban eljutnak a felhasználóhoz.
• Elkezdtük a kapcsolódó jegyek összevonását fejlesztés és tesztelés céljából. Korábban minden jegy, minden hiba zárt ökoszisztéma volt, semmi máshoz nem kötve. Három gomb megváltoztatása egy oldalon három különböző jegyet jelenthetett volna három különböző minőségbiztosítási folyamattal az oldalankénti egy automatikus teszt helyett.
• Elkezdtünk dolgozni a fejlesztőkkel a munkaerőköltségek becslésének módszerén. Három nap egy gomb megváltoztatása nem vicces.

Huszadik nap

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

Hosszútávú célok:

• Felügyelt platform. Minden oldalon több száz kérés nem komoly.
• Megjósolható trendek. Voltak időszakos forgalmi csúcsok, amelyek első pillantásra nem korreláltak más mutatókkal – meg kellett értenünk, miért történt ez, és meg kellett tanulnunk előre jelezni.
• Platform bővítés. Az üzlet folyamatosan növekszik, egyre több felhasználó érkezik, a forgalom pedig növekszik.

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

A legtöbb esetben ez nem működik, jó, ha az átírás egyáltalán működik. Ezért létre kellett hoznunk egy ütemtervet – egy konkrét stratégiát, amely lépésről lépésre bemutatja az üzleti célok elérését (mit és miért teszünk), amely:

• tükrözi a projekt küldetését és céljait;
• prioritást ad a fő céloknak;
• ütemtervet tartalmaz ezek elérésére.

Ezt megelőzően senki nem beszélt a csapattal a változtatások céljáról. Ehhez megfelelő sikermutatókra van szükség. A cég történetében először a technikai csoporthoz határoztunk meg KPI-ket, és ezeket a mutatókat szervezetihez kötöttük.

Vagyis a szervezeti KPI-ket csapatok, a csapat KPI-ket pedig az egyes KPI-k támogatják. Egyébként, ha a technológiai KPI-k nem esnek egybe a szervezetiekkel, akkor mindenki magára húzza a takarót.

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

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

• Először is, több időt szeretnénk tölteni új termékek fejlesztésével a hibák kijavítása helyett. Ez egy logikus megoldás, amely könnyen mérhető.
• Másodsorban a tranzakciós volumen növekedését szeretnénk támogatni, mert minél nagyobb a piaci részesedés, annál több a felhasználó és ennek megfelelően a forgalom is.

Ekkor a csoporton belül végrehajtható egyedi KPI-k például azon a helyen lesznek, ahonnan a fő hibák származnak. Ha kifejezetten erre a részre koncentrál, megbizonyosodhat arról, hogy sokkal kevesebb a hiba, és így megnő az idő az új termékek fejlesztésére és ismét a szervezeti KPI-k támogatására.

Így minden döntésnek, beleértve a kód átírását is, támogatnia kell azokat a konkrét célokat, amelyeket a cég kitűzött elénk (szervezeti növekedés, újdonságok, toborzás).

A folyamat során egy érdekességre derült fény, ami nemcsak a technikusok, hanem általában a cégnél is hírré vált: minden jegynek legalább egy KPI-re kell koncentrálnia. Vagyis ha egy termék azt mondja, hogy új funkciót szeretne létrehozni, akkor az első kérdést fel kell tenni: „Milyen KPI-t támogat ez a funkció?” Ha nem, akkor elnézést – felesleges funkciónak tűnik.

Harminc nap

A hónap végén egy újabb árnyalatot fedeztem fel: az Ops csapatomból soha senki nem látta az ügyfelekkel kötött szerződéseket. Megkérdezheti, hogy miért kell látnia a névjegyeket.

• Először is azért, mert az SLA-kat a szerződések határozzák meg.
• Másodszor, az SLA-k különbözőek. Minden ügyfél a saját igényeivel érkezett, és az értékesítési osztály anélkül írt alá, hogy megnézte volna.

További érdekesség, hogy az egyik legnagyobb klienssel kötött szerződésben az szerepel, hogy a platform által támogatott összes szoftververziónak n-1-esnek kell lennie, vagyis nem a legfrissebbnek, hanem az utolsó előttinek kell lennie.

Jól látszik, milyen messze voltunk az n-1-től, ha a platform ColdFusion és SQL Server 2008 alapú, amelyet júliusban már egyáltalán nem támogatott.

Negyvenötödik nap

A második hónap közepe táján volt elég időm leülni és csinálni értékfolyamtérképészet teljesen az egész folyamatra. Ezek a szükséges lépések, amelyeket meg kell tenni a termék létrehozásától a fogyasztóhoz való eljuttatásáig, és ezeket a lehető legrészletesebben le kell írni.

A folyamatot apró darabokra bontja, és meglátja, mi az, ami túl sok időt vesz igénybe, mit lehet optimalizálni, javítani stb. Például, mennyi ideig tart, amíg egy termékkérelem átmegy az ápoláson, mikor éri el a jegyet, amelyet a fejlesztő vehet igénybe, minőségbiztosítás stb. Tehát minden egyes lépést részletesen megvizsgál, és átgondolja, hogy mit lehet optimalizálni.

Amikor ezt megtettem, két dolog ragadta meg a figyelmemet:

• a QA-ból visszaküldött jegyek nagy százaléka a fejlesztőknek;
• lekérési kérés felülvizsgálata túl sokáig tartott.

A probléma az volt, hogy ezek olyan következtetések voltak, mint: Úgy tűnik, sok időt vesz igénybe, de nem tudjuk, mennyi ideig.

"Amit nem tudsz mérni, azt nem tudod javítani."

Hogyan indokolható a probléma súlyossága? Napokat vagy órákat pazarol?

Ennek mérésére néhány lépést adtunk a Jira folyamathoz: „készen áll a fejlesztőre” és „készen áll a minőségbiztosításra”, hogy mérjük, mennyi ideig várnak az egyes jegyek, és hányszor térnek vissza egy bizonyos lépéshez.

Hozzáadtuk az „in review”-t is, hogy megtudjuk, átlagosan hány jegy van az áttekintésre, és innen indulhat a tánc. Voltak rendszermutatóink, most új mutatókat adtunk hozzá, és elkezdtük a mérést:

• A folyamat hatékonysága: teljesítmény és tervezett/átadott.
• A folyamat minősége: hibák száma, hibák a minőségbiztosítástól.

Valóban segít megérteni, mi megy jól és mi nem.

Ötvenedik nap

Mindez persze jó és érdekes, de a második hónap vége felé történt valami, ami elvileg kiszámítható volt, bár ekkora léptékre nem számítottam. Az emberek elkezdtek távozni, mert megváltozott a felső vezetés. Új emberek kerültek a vezetőségbe, és elkezdtek mindent megváltoztatni, a régiek pedig felmondtak. És általában egy több éves társaságban mindenki barátkozik és mindenki ismeri egymást.

Ez várható volt, de az elbocsátások mértéke váratlan volt. Például egy hét alatt két csapatvezető egyszerre nyújtotta be szabad akaratából lemondását. Ezért nem csak az egyéb problémákat kellett elfelejtenem, hanem azokra is koncentrálnom kellett csapat létrehozása. Ez egy hosszú és nehezen megoldható probléma, de foglalkozni kellett vele, mert meg akartam menteni a megmaradt embereket (vagy többségüket). Valahogy reagálni kellett arra, hogy az emberek elmentek, hogy fenntartsák a morált a csapatban.

Elméletileg ez jó: jön egy új ember, aki teljes carte blanche-val rendelkezik, aki fel tudja mérni a csapat képességeit és helyettesíteni tudja a személyzetet. Valójában nem lehet csak úgy új embereket behozni annyi okból. Az egyensúly mindig kell.

• Régi és új. Meg kell tartanunk az idős embereket, akik képesek változtatni és támogatni a missziót. De ugyanakkor új vért kell bevinnünk, erről majd egy kicsit később.
• Tapasztalat. Sokat beszélgettem jó juniorokkal, akik lelkesek voltak és szerettek volna velünk dolgozni. De nem tudtam felvenni őket, mert nem volt elég idős, hogy támogassa a juniorokat és mentorként szolgáljon számukra. Először a csúcsot kellett toborozni, és csak azután a fiatalokat.
• Répa és bot.

Nincs jó válaszom arra a kérdésre, hogy mi a helyes egyensúly, hogyan kell fenntartani, hány embert kell megtartani, és mennyit kell nyomni. Ez tisztán egyéni folyamat.

Ötvenedik nap

Elkezdtem alaposan szemügyre venni a csapatot, hogy megértsem, ki vagyok, és ismét eszembe jutott:

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

Azt tapasztaltam, hogy a csapatnak – mind a Devnek, mind az Opsnak – három nagy problémája van:

• Elégedettség a jelenlegi állapottal.
• Felelősség hiányában - mert soha senki nem hozta az előadóművészek munkájának eredményét az üzlet befolyásolására.
• A változástól való félelem.

A változás mindig kivezet a komfortzónádból, és minél fiatalabbak az emberek, annál inkább nem szeretik a változást, mert nem értik, miért, és nem értik, hogyan. A leggyakoribb válasz, amit hallottam: "Soha nem csináltunk ilyet." Sőt, a teljes abszurditásig jutott – a legkisebb változtatások sem történhettek meg anélkül, hogy valaki fel ne háborodna. És bármennyire is befolyásolták a változások a munkájukat, az emberek azt mondták: „Nem, miért? Ez nem fog működni."

De nem lehet jobb anélkül, hogy semmit sem változtatna.

Teljesen abszurd beszélgetést folytattam egy alkalmazottal, elmondtam neki az optimalizálási ötleteimet, mire ő azt mondta:
- Ó, nem láttad, mi volt tavaly!
- És akkor mi van?
– Most sokkal jobb, mint volt.
- Szóval nem lehet jobb?
- Minek?

Jó kérdés – miért? Mintha most jobb lenne, mint volt, akkor minden elég jó. Ez a felelősség hiányához vezet, ami elvileg teljesen normális. Mint mondtam, a technikai csoport egy kicsit a pálya szélén állt. A cég úgy gondolta, hogy létezniük kell, de soha senki nem szabta meg a mércét. A technikai támogatás soha nem látta meg az SLA-t, így teljesen „elfogadható” volt a csoport számára (és ez döbbent meg a legjobban):

• 12 másodperces betöltés;
• 5-10 perc leállás minden kiadásonként;
• A kritikus problémák hibaelhárítása napokat és heteket vesz igénybe;
• ügyeletes személyzet hiánya 24x7 / ügyelet.

Soha senki nem próbálta megkérdezni, hogy miért nem csináljuk jobban, és soha senki nem vette észre, hogy ennek nem kell így lennie.

Bónuszként volt még egy probléma: tapasztalat hiánya. Az idősebbek elmentek, a megmaradt fiatal csapat pedig az előző rendszerben nőtt fel, és megmérgezték.

Mindezeken felül az emberek attól is féltek, hogy elbuknak, és alkalmatlannak tűnnek. Ez abban nyilvánul meg, hogy először is ők semmi esetre sem kért segítséget. Hányszor beszélgettünk csoportban és egyénileg, és azt mondtam: „Tegyen fel egy kérdést, ha nem tudja, hogyan kell csinálni valamit.” Bízom magamban, és tudom, hogy minden problémát meg tudok oldani, de ehhez idő kell. Ezért ha megkérhetek valakit, aki tudja, hogyan oldja meg 10 perc alatt, akkor megkérdezem. Minél kevesebb tapasztalatod van, annál jobban félsz megkérdezni, mert úgy gondolod, hogy alkalmatlannak fogják tekinteni.

Ez a kérdezéstől való félelem érdekes módon nyilvánul meg. Például megkérdezi: „Hogy haladsz ezzel a feladattal?” - "Még pár óra, már végzek." Másnap újra kérdezel, azt a választ kapod, hogy minden rendben, de egy probléma volt, a nap végére biztosan kész lesz. Eltelik egy újabb nap, és amíg nem szorítanak a falhoz, és nem kényszerülsz arra, hogy beszélj valakivel, ez folytatódik. Az ember maga akar megoldani egy problémát; hisz abban, hogy ha nem ő maga oldja meg, az nagy kudarc lesz.

Ezért a fejlesztők felfújták a becsléseket. Ugyanez az anekdota volt, amikor megbeszéltek egy feladatot, olyan alakot adtak nekem, hogy nagyon meglepődtem. Erre azt mondták, hogy a fejlesztő becsléseibe beleszámítja azt az időt, ameddig a jegyet visszaküldi a QA-tól, mert ott hibákat talál, és azt az időt, ameddig a PR-nek el kell telnie, és azt az időt, amíg az embereknek ellenőrizniük kell. elfoglalt lesz – vagyis minden, ami csak lehetséges.

Másodszor, azok az emberek, akik félnek, hogy alkalmatlannak tűnnek túlelemezni. Amikor azt mondod, hogy pontosan mit kell tenni, ez így kezdődik: „Nem, mi lenne, ha itt gondolnánk rá?” Ebben az értelemben cégünk nem egyedülálló, ez a fiatalok szokásos problémája.

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

• Szabály 30 perc. Ha nem tudja fél óra alatt megoldani a problémát, kérjen meg valakit, hogy segítsen. Ez változó sikerrel működik, mert az emberek még mindig nem kérdeznek, de legalább elkezdődött a folyamat.
• Távolítson el mindent, kivéve a lényeget, a feladat elvégzésének határidejének becslésénél, vagyis csak azt vegyük figyelembe, hogy mennyi ideig tart a kód megírása.
• Folyamatos tanulás azoknak, akik túlságosan elemzik. Ez csak állandó munka az emberekkel.

Hatvanadik nap

Amíg mindezt csináltam, ideje volt kitalálni a költségvetést. Természetesen sok érdekességet találtam abban, hogy hová költöttük a pénzünket. Például volt egy teljes rack egy külön adatközpontban egy FTP szerverrel, amelyet egy kliens használt. Kiderült, hogy "... elköltöztünk, de ő így maradt, nem változtattuk meg." 2 éve volt.

Különösen érdekes volt a felhőszolgáltatások számlája. Úgy gondolom, hogy a magas felhőszámla fő oka azok a fejlesztők, akik életükben először férhetnek hozzá korlátlanul a szerverekhez. Nem kell megkérdezniük: „Kérem, adjon egy tesztszervert”, ők maguk is elvihetik. Ráadásul a fejlesztők mindig olyan menő rendszert akarnak építeni, hogy a Facebook és a Netflix féltékeny lesz.

De a fejlesztőknek nincs tapasztalatuk a szerverek vásárlásában és a szükséges szerverméret meghatározásában, mert korábban nem volt rá szükségük. És általában nem egészen értik a skálázhatóság és a teljesítmény közötti különbséget.

Leltári eredmények:

• Ugyanazt az adatközpontot hagytuk el.
• 3 rönkszolgálattal szerződést bontottunk. Mert nálunk 5 db volt – minden fejlesztő, aki elkezdett játszani valamivel, vett egy újat.
• 7 AWS rendszert leállítottak. Ismét senki sem állította le a halott projekteket, mind tovább dolgoztak.
• 6-szorosára csökkentett szoftverköltség.

Hetvenötödik nap

Telt-múlt az idő, és két és fél hónap múlva találkoznom kellett az igazgatósággal. Igazgatóságunk sem jobb, sem rosszabb, mint mások; mint minden igazgatótanács, ez is mindent tudni akar. Az emberek pénzt fektetnek be, és szeretnék megérteni, hogy az, amit csinálunk, mennyi belefér a beállított KPI-kbe.

Az igazgatóság minden hónapban rengeteg információt kap: a felhasználók száma, növekedése, milyen szolgáltatásokat vesznek igénybe és hogyan, teljesítmény és termelékenység, végül pedig az oldalak átlagos betöltési sebessége.

Csak az a baj, hogy szerintem az átlag tiszta gonosz. De ezt nagyon nehéz elmagyarázni az igazgatóságnak. Megszokták, hogy összesített számokkal kell operálni, és nem például a betöltési idők másodpercenkénti terjedésével.

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

Vagyis a ColdFusion átmegy a Jetty-n és az nginx-en, és elindítja az oldalakat. És a képek, a JS és a CSS külön nginx-en mennek keresztül, saját konfigurációkkal. Ez egy meglehetősen általános gyakorlat, amelyről beszélek írtam 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-al nőtt.

Ez azért történt, mert a grafikon a Jetty-hez mellékelt adatok alapján készült. Vagyis a gyors tartalom nem szerepel a számításban - az átlagérték megugrott. Ez világos volt számunkra, nevettünk, de hogyan magyarázzuk el az igazgatóságnak, hogy miért tettünk valamit, és a dolgok 12%-kal rosszabbra fordultak?

Nyolcvanötödik nap

A harmadik hónap végén rájöttem, hogy van egy dolog, amivel egyáltalán nem számoltam: az idő. Minden, amiről beszéltem, időbe telik.

Ez az igazi heti naptáram – csak egy munkahét, nem túl elfoglalt. Nincs mindenre elég idő. Ezért ismét olyan embereket kell toboroznia, akik segítenek megbirkózni a problémákkal.

Következtetés

Ez nem minden. Ebben a történetben még arra sem jutottam el, hogyan dolgoztunk a termékkel és próbáltunk ráhangolódni az általános hullámra, hogyan integráltuk a technikai támogatást, vagy hogyan oldottunk meg egyéb technikai problémákat. Például teljesen véletlenül tudtam meg, hogy az adatbázis legnagyobb tábláit nem használjuk SEQUENCE. Van egy önállóan írt funkciónk nextID, és nem használják tranzakciókban.

Millió hasonló dolog volt még, amiről még sokáig beszélhetnénk. De a legfontosabb, amit még el kell mondani, az a kultúra.

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

• nem félnek a kudarcoktól;
• tanulni a hibákból;
• együttműködni más csapatokkal;
• kezdeményezzen;
• vállalj felelősséget;
• Üdvözöljük az eredményt célként;
• sikert ünnepelni.

Ezzel minden más jön.

Leon Fire Twitteren, Facebook és tovább közepes.

A hagyatékkal kapcsolatban két stratégia létezik: mindenáron kerülni kell vele a munkát, vagy bátran leküzdeni a kapcsolódó nehézségeket. Mi c DevOpsConf A második utat választjuk, megváltoztatjuk a folyamatokat és a megközelítéseket. Csatlakozz hozzánk youtube, levelezőlista и távirat, és együtt megvalósítjuk a DevOps kultúrát.

Forrás: will.com