ProHoster > Blogs > Administrācija > Mantoto sistēmu un procesu mantoÅ”ana vai pirmās 90 dienas kā CTO

Mantoto sistēmu un procesu mantoÅ”ana vai pirmās 90 dienas kā CTO

Zināms, ka CTO kompetence tiek pārbaudÄ«ta tikai otrreiz, kad viņŔ pilda Å”o pienākumu. Jo viena lieta ir strādāt uzņēmumā vairākus gadus, attÄ«stÄ«ties lÄ«dzi un, atrodoties vienā kultÅ«ras kontekstā, pamazām uzņemties lielāku atbildÄ«bu. Un pavisam cita lieta ir nonākt tieÅ”i tehniskā direktora amatā uzņēmumā ar mantotu bagāžu un daudzām problēmām, kas glÄ«ti paslaucÄ«tas zem paklāja.

Å ajā ziņā Leona Fire pieredze, kurā viņŔ dalÄ«jās DevOpsConf, ne gluži unikāls, bet, reizinot ar viņa pieredzi un dažādo lomu skaitu, ko viņam izdevās izmēģināt 20 gadu laikā, tas ir ļoti noderÄ«gi. Zem griezuma ir redzama notikumu hronoloÄ£ija 90 dienu laikā un daudzi stāsti, par kuriem ir jautri pasmieties, kad tie notiek ar kādu citu, bet kuriem nav tik jautri saskarties klātienē.

Leons ļoti krāsaini runā krieviski, tāpēc, ja ir 35-40 minūtes, iesaku noskatīties video. Teksta versija, lai ietaupītu laiku.


Pirmā ziņojuma versija bija labi strukturēts apraksts par darbu ar cilvēkiem un procesiem, kas satur noderÄ«gus ieteikumus. Bet viņa nenodeva visus pārsteigumus, kas tika sastapti ceļā. Tāpēc es mainÄ«ju formātu un hronoloÄ£iskā secÄ«bā izklāstÄ«ju problēmas, kas manā priekŔā parādÄ«jās kā domkrats jaunajā uzņēmumā, un metodes to risināŔanai.

Pirms mēneÅ”a

Tāpat kā daudzi labi stāsti, arÄ« Å”is sākās ar alkoholu. Sēdējām ar draugiem bārā, un, kā jau IT speciālistu vidÅ« bija gaidāms, visi raudāja par savām problēmām. Viens no viņiem tikko bija mainÄ«jis darbu un runāja par savām problēmām saistÄ«bā ar tehnoloÄ£ijām, cilvēkiem un komandu. Jo vairāk klausÄ«jos, jo vairāk sapratu, ka viņam vajadzētu mani vienkārÅ”i pieņemt darbā, jo tieÅ”i Ŕādas problēmas es risinu pēdējos 15 gadus. Es viņam to pateicu, un nākamajā dienā mēs satikāmies darba vidē. Uzņēmums saucās Teaching Strategies.

Teaching Strategies ir tirgus lÄ«deris mācÄ«bu programmās ļoti maziem bērniem no dzimÅ”anas lÄ«dz trÄ«s gadu vecumam. Tradicionālajam ā€œpapÄ«raā€ uzņēmumam ir jau 40 gadi, bet platformas digitālajai SaaS versijai ā€“ 10. SalÄ«dzinoÅ”i nesen sākās digitālo tehnoloÄ£iju pielāgoÅ”anas process uzņēmuma standartiem. ā€œJaunāā€ versija tika izlaista 2017. gadā un bija gandrÄ«z tāda pati kā vecā, tikai tā darbojās sliktāk.

Pats interesantākais ir tas, ka Ŕī uzņēmuma satiksme ir ļoti paredzama ā€“ katru dienu, gadu no gada var ļoti skaidri paredzēt, cik cilvēku un kad ieradÄ«sies. Piemēram, no pulksten 13 lÄ«dz 15:XNUMX visi bērni bērnudārzos iet gulēt, un skolotāji sāk ievadÄ«t informāciju. Un tas notiek katru dienu, izņemot nedēļas nogales, jo brÄ«vdienās gandrÄ«z neviens nestrādā.

Mantoto sistēmu un procesu mantoÅ”ana vai pirmās 90 dienas kā CTO

Nedaudz paraugoties uz priekÅ”u, atzÄ«mÄ“Å”u, ka savu darbu sāku gada lielākās satiksmes laikā, kas ir interesants dažādu iemeslu dēļ.

Platformai, kas, Ŕķiet, bija tikai 2 gadus veca, bija savdabÄ«ga kaudze: ColdFusion & SQL Server no 2008. gada. ColdFusion, ja jÅ«s nezināt un, visticamāk, nezināt, ir uzņēmuma PHP, kas iznāca 90. gadu vidÅ«, un kopÅ” tā laika es par to neesmu pat dzirdējis. Bija arÄ«: Ruby, MySQL, PostgreSQL, Java, Go, Python. Bet galvenais monolÄ«ts darbojās ColdFusion un SQL Server.

Problēmas

Jo vairāk runāju ar uzņēmuma darbiniekiem par darbu un raduÅ”ajām problēmām, jo ā€‹ā€‹vairāk sapratu, ka problēmām nav tikai tehniska rakstura. Labi, tehnoloÄ£ija ir veca - un viņi pie tās nestrādāja, taču radās problēmas ar komandu un procesiem, un uzņēmums sāka to saprast.

Tradicionāli viņu tehniÄ·i sēdēja stÅ«rÄ« un darÄ«ja kādu darbu. Taču arvien vairāk uzņēmumu sāka izmantot digitālo versiju. Tāpēc pēdējā gadā pirms darba sākÅ”anas uzņēmumā parādÄ«jās jauni: direktoru padome, CTO, CPO un QA direktors. Tas ir, uzņēmums sāka investēt tehnoloÄ£iju nozarē.

Smaga mantojuma pēdas bija ne tikai sistēmās. Uzņēmumam bija mantoti procesi, mantoti cilvēki, mantota kultūra. Tas viss bija jāmaina. Es domāju, ka tas noteikti nebūs garlaicīgi, un nolēmu izmēģināt.

Divas dienas iepriekÅ”

Divas dienas pirms jauna darba sākÅ”anas es ierados birojā, aizpildÄ«ju pēdējos dokumentus, satiku komandu un atklāju, ka komanda tobrÄ«d cÄ«nās ar problēmu. Vidējais lapas ielādes laiks pieauga lÄ«dz 4 sekundēm, tas ir, 2 reizes.

Mantoto sistēmu un procesu mantoÅ”ana vai pirmās 90 dienas kā CTO

Spriežot pēc grafika, kaut kas skaidri notika, un nav skaidrs, kas. Izrādījās, ka problēma bija tīkla latentumā datu centrā: 5 ms latentums datu centrā lietotājiem pārvērtās par 2 s. Es nezināju, kāpēc tas notika, bet jebkurā gadījumā kļuva zināms, ka problēma ir datu centrā.

Pirmā diena

Pagāja divas dienas, un manā pirmajā darba dienā es atklāju, ka problēma nav pazudusi.

Mantoto sistēmu un procesu mantoÅ”ana vai pirmās 90 dienas kā CTO

Divu dienu laikā lietotāju lapas tika ielādētas vidēji 4 sekundēs. Es jautāju, vai viņi atklāja, kāda ir problēma.

ā€“ Jā, mēs atvērām biļeti.
- un?
- Nu, viņi mums vēl nav atbildējuÅ”i.

Tad es sapratu, ka viss, par ko man bija stāstīts iepriekŔ, ir tikai maza aisberga redzamā daļa, ar kuru man jācīnās.

Ir labs citāts, kas tam ļoti labi atbilst:

"Dažreiz, lai mainītu tehnoloģiju, ir jāmaina organizācija."

Bet, tā kā darbu sāku gada noslogotākajā laikā, nācās izskatÄ«t abus problēmas risināŔanas variantus: gan ātro, gan ilgtermiņa. Un sāciet ar to, kas Å”obrÄ«d ir kritisks.

TreŔā diena

Tātad, ielāde ilgst 4 sekundes, un no 13 līdz 15 lielākās virsotnes.

Mantoto sistēmu un procesu mantoÅ”ana vai pirmās 90 dienas kā CTO

TreŔajā dienā Ŕajā laika periodā lejupielādes ātrums izskatījās Ŕādi:

Mantoto sistēmu un procesu mantoÅ”ana vai pirmās 90 dienas kā CTO

No mana viedokļa nekas nedarbojās. No visu citu viedokļa tas skrēja nedaudz lēnāk nekā parasti. Bet tā vienkārÅ”i nenotiek ā€” tā ir nopietna problēma.

Mēģināju pārliecināt komandu, uz ko viņi atbildēja, ka vienkārÅ”i vajag vairāk serveru. Tas, protams, ir problēmas risinājums, taču ne vienmēr tas ir vienÄ«gais un efektÄ«vākais. Jautāju, kāpēc nav pietiekami daudz serveru, kāds ir trafika apjoms. Es ekstrapolēju datus un atklāju, ka mums ir aptuveni 150 pieprasÄ«jumu sekundē, kas principā ietilpst saprātÄ«gās robežās.

Bet mēs nedrÄ«kstam aizmirst, ka, pirms saņemat pareizo atbildi, jums ir jāuzdod pareizais jautājums. Mans nākamais jautājums bija: cik priekÅ”gala serveru mums ir? Atbilde ā€œmani nedaudz mulsinājaā€ - mums bija 17 frontend serveri!

ā€” Man ir neērti jautāt, bet 150 dalÄ«ts ar 17 dod apmēram 8? Vai jÅ«s gribat teikt, ka katrs serveris pieļauj 8 pieprasÄ«jumus sekundē, un, ja rÄ«t bÅ«s 160 pieprasÄ«jumi sekundē, mums vajadzēs vēl 2 serverus?

Protams, papildu serveri mums nebija vajadzÄ«gi. Risinājums bija paŔā kodā un virspusē:

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

Bija funkcija getCurrentClass(), jo viss vietnē darbojas klases kontekstā - tieÅ”i tā. Un Å”ai funkcijai katrā lapā bija viena funkcija Vairāk nekā 200 pieprasÄ«jumu.

Risinājums Ŕādā veidā bija ļoti vienkārÅ”s, jums pat nekas nebija jāpārraksta: vienkārÅ”i neprasiet to paÅ”u informāciju vēlreiz.

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

Es biju ļoti priecÄ«ga, jo nolēmu, ka tikai treÅ”ajā dienā esmu atradusi galveno problēmu. Lai arÄ« cik naiva es biju, Ŕī bija tikai viena no daudzajām problēmām.

Mantoto sistēmu un procesu mantoÅ”ana vai pirmās 90 dienas kā CTO

Bet, atrisinot Å”o pirmo problēmu, grafiks samazinājās daudz zemāk.

Tajā paŔā laikā mēs veicām citas optimizācijas. Bija redzamas daudzas lietas, kuras varēja labot. Piemēram, tajā paŔā treÅ”ajā dienā es atklāju, ka sistēmā tomēr ir keÅ”atmiņa (sākumā domāju, ka visi pieprasÄ«jumi nāk tieÅ”i no datu bāzes). Kad es domāju par keÅ”atmiņu, es domāju par standarta Redis vai Memcached. Bet es biju vienÄ«gais, kurÅ” tā domāja, jo Ŕī sistēma keÅ”atmiņā izmantoja MongoDB un SQL Server - to paÅ”u, no kura tikko tika nolasÄ«ti dati.

Desmitā diena

Pirmajā nedēļā es tiku galā ar problēmām, kuras bija jāatrisina tieÅ”i tagad. Kaut kur otrajā nedēļā pirmo reizi atnācu pie stand-up, lai komunicētu ar komandu, paskatÄ«tos, kas notiek un kā viss process norit.

Atkal tika atklāts kaut kas interesants. Komanda sastāvēja no: 18 izstrādātājiem; 8 testeri; 3 vadÄ«tāji; 2 arhitekti. Un viņi visi piedalÄ«jās kopÄ«gos rituālos, tas ir, vairāk nekā 30 cilvēki ik rÄ«tu nāca pie stand-up un stāstÄ«ja, ko viņi darÄ«juÅ”i. Skaidrs, ka tikÅ”anās neaizņēma 5 vai 15 minÅ«tes. Neviens nevienu neklausÄ«jās, jo visi strādā pie dažādām sistēmām. Šādā formā 2-3 biļetes stundā uz kopÅ”anas sesiju jau bija labs rezultāts.

Pirmā lieta, ko izdarÄ«jām, bija komandas sadalÄ«Å”ana vairākās produktu lÄ«nijās. Dažādām sadaļām un sistēmām mēs pieŔķīrām atseviŔķas komandas, kurās bija izstrādātāji, testētāji, produktu vadÄ«tāji un biznesa analÄ«tiÄ·i.

Rezultātā mēs saņēmām:

  • Stand-up un mÄ«tiņu samazināŔana.
  • PriekÅ”meta zināŔanas par produktu.
  • ÄŖpaÅ”umtiesÄ«bas sajÅ«ta. Kad cilvēki visu laiku čalojās ar sistēmām, viņi zināja, ka ar savām kļūdām, visticamāk, bÅ«s jāstrādā kādam citam, bet ne paÅ”iem.
  • SadarbÄ«ba starp grupām. Lieki piebilst, ka QA iepriekÅ” Ä«paÅ”i nekomunicēja ar programmētājiem, produkts darÄ«ja savu utt. Tagad viņiem ir kopÄ«gs atbildÄ«bas punkts.

Galvenokārt koncentrējāmies uz efektivitāti, produktivitāti un kvalitāti ā€“ tās ir problēmas, kuras centāmies atrisināt ar komandas pārveidi.

Vienpadsmitā diena

Komandas struktÅ«ras maiņas procesā atklāju, kā skaitÄ«t stāstsPunkti. 1 SP bija vienāds ar vienu dienu, un katrā biļetē bija SP gan izstrādei, gan kvalitātes nodroÅ”ināŔanai, tas ir, vismaz 2 SP.

Kā es to atklāju?

Mantoto sistēmu un procesu mantoÅ”ana vai pirmās 90 dienas kā CTO

Atradām kļūdu: vienā no pārskatiem, kur ir ievadÄ«ts tā perioda sākuma un beigu datums, par kuru atskaite ir nepiecieÅ”ama, pēdējā diena netiek ņemta vērā. Tas ir, kaut kur pieprasÄ«jumā nebija <=, bet vienkārÅ”i <. Man teica, ka tie ir trÄ«s stāstu punkti, tas ir 3 dienas.

Pēc tam mēs:

  • Stāstu punktu vērtÄ“Å”anas sistēma ir pārskatÄ«ta. Tagad sÄ«ku kļūdu labojumi, kurus var ātri izlaist caur sistēmu, ātrāk sasniedz lietotāju.
  • Mēs sākām apvienot saistÄ«tās biļetes izstrādei un testÄ“Å”anai. IepriekÅ” katra biļete, katra kļūda bija slēgta ekosistēma, kas nebija saistÄ«ta ne ar ko citu. TrÄ«s pogu maiņa vienā lapā varēja bÅ«t trÄ«s dažādas biļetes ar trim dažādiem kvalitātes nodroÅ”ināŔanas procesiem, nevis viena automatizēta pārbaude katrā lapā.
  • Mēs sākām strādāt ar izstrādātājiem pie pieejas darbaspēka izmaksu aprēķināŔanai. TrÄ«s dienas, lai mainÄ«tu vienu pogu, nav smieklÄ«gi.

Divdesmitā diena

Kaut kur pirmā mēneÅ”a vidÅ« situācija nedaudz nostabilizējās, sapratu, kas pamatā notiek, un jau sāku skatÄ«ties nākotnē un domāt par ilgtermiņa risinājumiem.

Ilgtermiņa mērķi:

  • PārvaldÄ«ta platforma. Simtiem pieprasÄ«jumu katrā lapā nav nopietni.
  • Paredzamas tendences. Bija periodiski satiksmes maksimumi, kas no pirmā acu uzmetiena nekorelēja ar citiem rādÄ«tājiem ā€” mums bija jāsaprot, kāpēc tas notika, un jāiemācās paredzēt.
  • Platformas paplaÅ”ināŔana. Bizness nepārtraukti aug, ienāk arvien vairāk lietotāju, un palielinās satiksme.

Agrāk bieži teica: ā€œPārrakstÄ«sim visu [valodā/ietvarā], viss darbosies labāk!ā€

Vairumā gadÄ«jumu tas nedarbojas, ir labi, ja pārrakstÄ«Å”ana vispār darbojas. Tāpēc mums bija jāizveido ceļvedis ā€“ konkrēta stratēģija, kas soli pa solim ilustrē, kā tiks sasniegti biznesa mērÄ·i (ko un kāpēc darÄ«sim), kas:

  • atspoguļo projekta misiju un mērÄ·us;
  • izvirza prioritāti galvenajiem mērÄ·iem;
  • satur grafiku to sasniegÅ”anai.

Pirms tam neviens ar komandu nebija runājis par izmaiņu mērÄ·i. Tam nepiecieÅ”ami pareizi veiksmes rādÄ«tāji. Pirmo reizi uzņēmuma vēsturē mēs iestatÄ«jām KPI tehniskajai grupai, un Å”ie rādÄ«tāji tika piesaistÄ«ti organizatoriskiem.

Mantoto sistēmu un procesu mantoÅ”ana vai pirmās 90 dienas kā CTO

Tas nozÄ«mē, ka organizācijas KPI atbalsta komandas, bet komandas KPI atbalsta atseviŔķi KPI. Pretējā gadÄ«jumā, ja tehnoloÄ£iskie KPI nesakrÄ«t ar organizatoriskiem, tad katrs velk segu uz sevi.

Piemēram, viens no organizatoriskajiem KPI palielina tirgus daļu, izmantojot jaunus produktus.

Kā jūs varat atbalstīt mērķi iegūt vairāk jaunu produktu?

  • Pirmkārt, mēs vēlamies vairāk laika veltÄ«t jaunu produktu izstrādei, nevis defektu laboÅ”anai. Tas ir loÄ£isks risinājums, ko ir viegli izmērÄ«t.
  • Otrkārt, vēlamies atbalstÄ«t darÄ«jumu apjoma pieaugumu, jo jo lielāka tirgus daļa, jo vairāk lietotāju un attiecÄ«gi arÄ« trafika.

Mantoto sistēmu un procesu mantoÅ”ana vai pirmās 90 dienas kā CTO

Tad atseviŔķi KPI, ko var izpildÄ«t grupas ietvaros, bÅ«s, piemēram, vietā, no kuras rodas galvenie defekti. Ja koncentrējaties tieÅ”i uz Å”o sadaļu, varat pārliecināties, ka tajā ir daudz mazāk defektu, un tad palielināsies laiks jaunu produktu izstrādei un atkal organizatorisko KPI atbalstam.

Tādējādi katram lēmumam, ieskaitot koda pārrakstÄ«Å”anu, ir jāatbalsta konkrētie mērÄ·i, ko uzņēmums mums ir izvirzÄ«jis (organizācijas izaugsme, jaunas iespējas, personāla atlase).

Å Ä« procesa gaitā atklājās interesanta lieta, kas kļuva par jaunumu ne tikai tehniÄ·iem, bet vispār uzņēmumā: visām biļetēm jābÅ«t vērstām vismaz uz vienu KPI. Tas ir, ja produkts saka, ka tas vēlas izveidot jaunu funkciju, pirmais jautājums ir jāuzdod: ā€œKādu KPI atbalsta Ŕī funkcija?ā€ Ja nē, tad atvainojiet - Ŕķiet, ka tā ir nevajadzÄ«ga funkcija.

Trīsdesmitā diena

MēneÅ”a beigās es atklāju vēl vienu niansi: neviens no manas Ops komandas nekad nav redzējis lÄ«gumus, kurus mēs slēdzam ar klientiem. JÅ«s varat jautāt, kāpēc jums ir jāredz kontakti.

  • Pirmkārt, tāpēc, ka SLA ir norādÄ«ti lÄ«gumos.
  • Otrkārt, SLA lÄ«gumi ir atŔķirÄ«gi. Katrs klients nāca ar savām prasÄ«bām, un pārdoÅ”anas nodaļa parakstÄ«jās, neskatoties.

Interesanta nianse ir arÄ« tā, ka lÄ«gumā ar vienu no lielākajiem klientiem ir norādÄ«ts, ka visām platformas atbalstÄ«tajām programmatÅ«ras versijām jābÅ«t n-1, proti, nevis jaunākajai, bet gan priekÅ”pēdējai.

Ir skaidrs, cik tālu mēs bijām no n-1, ja platformas pamatā bija ColdFusion un SQL Server 2008, kas jūlijā vairs netika atbalstīts.

Četrdesmit piektā diena

Ap otrā mēneÅ”a vidu man bija pietiekami daudz laika, lai apsēstos un darÄ«tu vērtÄ«baplÅ«smakartografÄ“Å”ana pilnÄ«bā visam procesam. Tie ir nepiecieÅ”amie soļi, kas jāveic, sākot no produkta izveides lÄ«dz tā piegādei patērētājam, un tie ir jāapraksta pēc iespējas detalizētāk.

JÅ«s sadalāt procesu mazos gabaliņos un redzat, kas aizņem pārāk daudz laika, ko var optimizēt, uzlabot utt. Piemēram, cik ilgs laiks nepiecieÅ”ams, lÄ«dz produkta pieprasÄ«jums tiek apstrādāts, kad tas sasniedz biļeti, ko izstrādātājs var izmantot, QA utt. Tāpēc jÅ«s detalizēti aplÅ«kojat katru atseviŔķu darbÄ«bu un domājat par to, ko var optimizēt.

Kad es to izdarīju, manu uzmanību piesaistīja divas lietas:

  • liels skaits biļeÅ”u, kas no QA tiek atgrieztas izstrādātājiem;
  • vilkÅ”anas pieprasÄ«juma pārskatÄ«Å”ana aizņēma pārāk ilgu laiku.

Problēma bija tā, ka tie bija Ŕādi secinājumi: Å Ä·iet, ka tas aizņem daudz laika, bet mēs nezinām, cik ilgi.

"Jūs nevarat uzlabot to, ko nevarat izmērīt."

Kā pamatot, cik nopietna ir problēma? Vai tas iznieko dienas vai stundas?

Lai to izmērÄ«tu, Jira procesam pievienojām dažas darbÄ«bas: ā€œgatavs izstrādeiā€ un ā€œgatavs kvalitātes nodroÅ”ināŔanaiā€, lai noteiktu, cik ilgi katra biļete gaida un cik reižu tā atgriežas uz noteiktu darbÄ«bu.

Mantoto sistēmu un procesu mantoÅ”ana vai pirmās 90 dienas kā CTO

Mēs arÄ« pievienojām ā€œpārskatāā€, lai uzzinātu, cik biļeÅ”u vidēji ir paredzēts pārskatÄ«Å”anai, un no tā jÅ«s varat sākt dejot. Mums bija sistēmas metrika, tagad mēs pievienojām jaunus rādÄ«tājus un sākām mērÄ«t:

  • Procesa efektivitāte: veiktspēju un plānoto/piegādāto.
  • Procesa kvalitāte: defektu skaits, defekti no QA.

Tas tieŔām palīdz saprast, kas iet labi un kas ne.

Piecdesmitā diena

Tas viss, protams, ir labi un interesanti, bet otrā mēneÅ”a beigās notika kaut kas, kas principā bija paredzams, lai gan es negaidÄ«ju tādus mērogus. Cilvēki sāka aiziet, jo bija mainÄ«jusies augstākā vadÄ«ba. Jauni cilvēki ienāca vadÄ«bā un sāka visu mainÄ«t, un vecie aizgāja. Un parasti uzņēmumā, kas ir vairākus gadus vecs, visi ir draugi un visi viens otru pazÄ«st.

Tas bija gaidāms, taču atlaiÅ”anas apmēri bija negaidÄ«ti. Piemēram, vienas nedēļas laikā divi komandu vadÄ«tāji pēc paÅ”a vēlÄ“Å”anās vienlaikus iesniedza atlÅ«gumu. Tāpēc man bija ne tikai jāaizmirst par citām problēmām, bet jākoncentrējas uz komandas izveidoÅ”ana. Å Ä« ir ilgstoÅ”a un grÅ«ti risināma problēma, taču ar to bija jātiek galā, jo vēlējos glābt palikuÅ”os cilvēkus (vai lielāko daļu no viņiem). Vajadzēja kaut kā reaģēt uz cilvēku aizieÅ”anu, lai saglabātu morāli komandā.

Teorētiski tas ir labi: ienāk jauns cilvēks, kuram ir pilnÄ«ga brÄ«vā izvēle, kurÅ” var novērtēt komandas prasmes un nomainÄ«t personālu. PatiesÄ«bā jÅ«s nevarat vienkārÅ”i piesaistÄ«t jaunus cilvēkus tik daudzu iemeslu dēļ. LÄ«dzsvars vienmēr ir vajadzÄ«gs.

  • Vecs un jauns. Mums ir jāsaglabā veci cilvēki, kuri var mainÄ«ties un atbalstÄ«t misiju. Bet tajā paŔā laikā mums ir jāienes jaunas asinis, par to mēs runāsim nedaudz vēlāk.
  • Pieredze. Es daudz runāju ar labiem junioriem, kuri vēlējās ar mums strādāt. Bet es nevarēju viņus uzņemties, jo nebija pietiekami daudz senioru, kas atbalstÄ«tu juniorus un darbotos kā viņu mentori. Vispirms vajadzēja savervēt virsotni un tikai tad jaunatni.
  • Burkāns un nÅ«ja.

Man nav labas atbildes uz jautājumu, kāds ir pareizais līdzsvars, kā to uzturēt, cik cilvēku saglabāt un cik daudz uzspiest. Tas ir tīri individuāls process.

Piecdesmit pirmā diena

Es sāku rūpīgi aplūkot komandu, lai saprastu, kas man ir, un atkal atcerējos:

"Lielākā daļa problēmu ir cilvēku problēmas."

Esmu atklājis, ka komandai kā tādai ā€” gan Dev, gan Ops ā€” ir trÄ«s lielas problēmas:

  • ApmierinātÄ«ba ar paÅ”reizējo lietu stāvokli.
  • AtbildÄ«bas trÅ«kums - jo neviens nekad nav nesis izpildÄ«tāju darba rezultātus, lai ietekmētu biznesu.
  • Bailes no pārmaiņām.

Mantoto sistēmu un procesu mantoÅ”ana vai pirmās 90 dienas kā CTO

Pārmaiņas vienmēr izved jÅ«s no jÅ«su komforta zonas, un, jo jaunāki ir cilvēki, jo vairāk viņiem nepatÄ«k pārmaiņas, jo viņi nesaprot, kāpēc, un viņi nesaprot, kā. VisizplatÄ«tākā atbilde, ko esmu dzirdējis, ir: "Mēs nekad to neesam darÄ«juÅ”i." Turklāt tas nonāca lÄ«dz pilnÄ«gam absurdam ā€“ mazākās izmaiņas nevarēja notikt bez kāda saÅ”utuma. Un neatkarÄ«gi no tā, cik izmaiņas ietekmēja viņu darbu, cilvēki teica: ā€œNē, kāpēc? Tas nedarbosies."

Bet jūs nevarat kļūt labāks, neko nemainot.

Man bija absolÅ«ti absurda saruna ar darbinieku, es viņam izstāstÄ«ju savas idejas optimizācijai, uz ko viņŔ man teica:
- Ak, jÅ«s neredzējāt to, kas mums bija pagājuÅ”ajā gadā!
- Nu un ko?
"Tagad tas ir daudz labāk nekā tas bija."
- Tātad, vai tas nevar būt labāks?
- PriekÅ” kam?

Labs jautājums - kāpēc? It kā tagad ir labāk nekā bija, tad viss ir pietiekami labi. Tas noved pie atbildÄ«bas trÅ«kuma, kas principā ir pilnÄ«gi normāli. Kā jau teicu, tehniskā grupa bija nedaudz malā. Uzņēmums uzskatÄ«ja, ka tiem vajadzētu pastāvēt, bet neviens nekad nav noteicis standartus. Tehniskais atbalsts nekad neredzēja SLA, tāpēc grupai tas bija diezgan ā€œpieņemamsā€ (un tas mani pārsteidza visvairāk):

  • 12 sekunžu ielāde;
  • 5-10 minÅ«Å”u dÄ«kstāve katrai izlaiÅ”anai;
  • Kritisku problēmu novērÅ”ana prasa dienas un nedēļas;
  • dežūrpersonāla trÅ«kums 24x7 / dežūras.

Neviens nekad nav mēģinājis jautāt, kāpēc mēs to nedarām labāk, un neviens nekad nav sapratis, ka tā tam nav jābūt.

Kā bonuss bija vēl viena problēma: pieredzes trÅ«kums. Vecākie aizgāja, un palikuÅ”ais jaunais kolektÄ«vs uzauga iepriekŔējā režīmā un saindējās ar to.

Turklāt cilvēki baidÄ«jās izgāzties un izrādÄ«ties nekompetenti. Tas izpaužas faktā, ka, pirmkārt, viņi nekādā gadÄ«jumā nelÅ«dza palÄ«dzÄ«bu. Cik reizes mēs esam runājuÅ”i kā grupa un individuāli, un es esmu teicis: "Uzdodiet jautājumu, ja nezināt, kā kaut ko darÄ«t." Esmu pārliecināta par sevi un zinu, ka varu atrisināt jebkuru problēmu, bet tas prasÄ«s laiku. Tāpēc, ja varÄ“Å”u pajautāt kādam, kurÅ” zina, kā to atrisināt 10 minÅ«tēs, pajautāŔu. Jo mazāka pieredze jums ir, jo vairāk baidāties jautāt, jo domājat, ka jÅ«s uzskatÄ«s par nekompetentu.

Å Ä«s bailes uzdot jautājumus izpaužas interesantā veidā. Piemēram, jÅ«s jautājat: "Kā jums veicas ar Å”o uzdevumu?" - "PalikuÅ”as pāris stundas, es jau beidzu." Nākamajā dienā jautā vēlreiz, saņem atbildi, ka viss kārtÄ«bā, bet bija viena problēma, lÄ«dz dienas beigām noteikti bÅ«s gatavs. Paiet vēl viena diena, un lÄ«dz brÄ«dim, kad esi piespiests pie sienas un spiests ar kādu runāt, tas turpinās. Cilvēks vēlas pats atrisināt problēmu; viņŔ uzskata, ka, ja viņŔ pats to neatrisinās, tā bÅ«s liela neveiksme.

Tāpēc izstrādātāji uzpūta aplēses. Tā bija tā pati anekdote, kad viņi apsprieda noteiktu uzdevumu, viņi man iedeva tādu skaitli, ka es biju ļoti pārsteigts. Uz ko man teica, ka izstrādātāja aplēsēs izstrādātājs iekļauj laiku, kad biļete tiks atgriezta no QA, jo viņi tur atradīs kļūdas, un laiku, ko prasīs PR, un laiku, kamēr cilvēki, kuriem vajadzētu pārskatīt tas būs aizņemts - tas ir, viss, kas ir iespējams.

Otrkārt, cilvēki, kuri baidās izrādÄ«ties nekompetenti pāranalizēt. Kad jÅ«s sakāt, kas tieÅ”i ir jādara, tas sākas: "Nē, ja mēs par to padomāsim Å”eit?" Å ajā ziņā mÅ«su uzņēmums nav unikāls, tā ir standarta problēma jaunieÅ”iem.

Atbildot uz to, es ieviesu Ŕādu praksi:

  • Noteikums 30 minÅ«tes. Ja nevarat atrisināt problēmu pusstundas laikā, lÅ«dziet kādam palÄ«dzēt. Tas darbojas ar mainÄ«giem panākumiem, jo ā€‹ā€‹cilvēki joprojām nejautā, bet vismaz process ir sācies.
  • Likvidējiet visu, izņemot bÅ«tÄ«bu, aplÄ“Å”ot uzdevuma izpildes termiņu, tas ir, ņemiet vērā tikai to, cik ilgs laiks bÅ«s nepiecieÅ”ams koda rakstÄ«Å”anai.
  • MūžizglÄ«tÄ«ba tiem, kas pārlieku analizē. Tas ir tikai pastāvÄ«gs darbs ar cilvēkiem.

SeŔdesmitā diena

Kamēr es to visu darÄ«ju, bija pienācis laiks izdomāt budžetu. Protams, es atklāju daudz interesantu lietu, kur mēs tērējām savu naudu. Piemēram, mums bija viss plaukts atseviŔķā datu centrā ar vienu FTP serveri, ko izmantoja viens klients. IzrādÄ«jās, ka "... mēs pārcēlāmies, bet viņŔ tāds palika, mēs viņu nemainÄ«jām." Tas bija pirms 2 gadiem.

ÄŖpaÅ”u interesi izraisÄ«ja rēķins par mākoņpakalpojumiem. Es uzskatu, ka galvenais iemesls lielajam mākoņa rēķinam ir izstrādātāji, kuriem pirmo reizi mūžā ir neierobežota piekļuve serveriem. Viņiem nav jājautā: ā€œLÅ«dzu, iedodiet man testa serveriā€, viņi to var paņemt paÅ”i. Turklāt izstrādātāji vienmēr vēlas izveidot tik forÅ”u sistēmu, ka Facebook un Netflix bÅ«s greizsirdÄ«gi.

Bet izstrādātājiem nav pieredzes serveru iegādē un prasmes noteikt nepiecieÅ”amo serveru izmēru, jo iepriekÅ” tas nebija vajadzÄ«gs. Un viņi parasti Ä«sti nesaprot atŔķirÄ«bu starp mērogojamÄ«bu un veiktspēju.

Inventarizācijas rezultāti:

  • Mēs atstājām to paÅ”u datu centru.
  • Pārtraukām lÄ«gumu ar 3 baļķu pakalpojumiem. Tā kā mums bija 5 no tiem - katrs izstrādātājs, kurÅ” sāka spēlēt ar kaut ko, paņēma jaunu.
  • Tika izslēgtas 7 AWS sistēmas. Atkal neviens neapturēja miruÅ”os projektus; viņi visi turpināja strādāt.
  • Samazinātas programmatÅ«ras izmaksas 6 reizes.

Septiņdesmit piektā diena

Gāja laiks, un pēc divarpus mēneÅ”iem man bija jātiekas ar direktoru padomi. MÅ«su direktoru padome nav ne labāka, ne sliktāka par citām; tāpat kā visas direktoru padomes, tā vēlas zināt visu. Cilvēki iegulda naudu un vēlas saprast, cik daudz tas, ko mēs darām, iekļaujas noteiktajos KPI.

Direktoru padome katru mēnesi saņem daudz informācijas: lietotāju skaits, to pieaugums, kādus pakalpojumus viņi izmanto un kā, veiktspēju un produktivitāti un, visbeidzot, vidējo lapas ielādes ātrumu.

VienÄ«gā problēma ir tā, ka es uzskatu, ka vidējais ir tÄ«rais ļaunums. Bet to ir ļoti grÅ«ti izskaidrot direktoru padomei. Viņi ir pieraduÅ”i darboties ar apkopotiem skaitļiem, nevis, piemēram, ar ielādes laiku sadalÄ«jumu sekundē.

Å ajā sakarā bija daži interesanti punkti. Piemēram, es teicu, ka mums ir jāsadala trafiks starp atseviŔķiem tÄ«mekļa serveriem atkarÄ«bā no satura veida.

Mantoto sistēmu un procesu mantoÅ”ana vai pirmās 90 dienas kā CTO

Tas ir, ColdFusion iet caur Jetty un nginx un palaiž lapas. Un attēli, JS un CSS iziet cauri atseviŔķai nginx ar savām konfigurācijām. Tā ir diezgan standarta prakse, par kuru es runāju rakstÄ«ja: pirms pāris gadiem. LÄ«dz ar to bildes ielādējas daudz ātrāk, un... vidējais ielādes ātrums pieaudzis par 200 ms.

Mantoto sistēmu un procesu mantoÅ”ana vai pirmās 90 dienas kā CTO

Tas notika, jo diagramma ir izveidota, pamatojoties uz datiem, kas tiek piegādāti kopā ar Jetty. Tas ir, ātrais saturs nav iekļauts aprēķinā - vidējā vērtība ir uzlēkusi. Tas mums bija skaidrs, mēs smējāmies, bet kā mēs varam paskaidrot direktoru padomei, kāpēc mēs kaut ko izdarījām un viss pasliktinājās par 12%?

Astoņdesmit piektā diena

TreŔā mēneÅ”a beigās es sapratu, ka ir viena lieta, ar ko es nemaz nebiju rēķinājusies: laiks. Viss, par ko es runāju, prasa laiku.

Mantoto sistēmu un procesu mantoÅ”ana vai pirmās 90 dienas kā CTO

Å is ir mans Ä«stais nedēļas kalendārs ā€“ tikai darba nedēļa, ne pārāk aizņemta. Laika visam nepietiek. Tāpēc atkal ir jāpieņem darbā cilvēki, kas palÄ«dzēs tikt galā ar problēmām.

Secinājums

Tas vēl nav viss. Å ajā stāstā es pat neesmu sapratis, kā mēs strādājām ar produktu un mēģinājām noskaņoties uz vispārējo vilni vai kā mēs integrējām tehnisko atbalstu, vai kā mēs risinājām citas tehniskas problēmas. Piemēram, pavisam nejauÅ”i uzzināju, ka uz lielākajām datubāzes tabulām mēs neizmantojam SEQUENCE. Mums ir paÅ”rakstÄ«ta funkcija nextID, un tas netiek izmantots darÄ«jumā.

Bija vēl miljons līdzīgu lietu, par kurām mēs varētu runāt ilgi. Bet svarīgākais, kas vēl jāpasaka, ir kultūra.

Mantoto sistēmu un procesu mantoÅ”ana vai pirmās 90 dienas kā CTO

Tā ir kultÅ«ra vai tās trÅ«kums, kas noved pie visām pārējām problēmām. Mēs cenÅ”amies veidot kultÅ«ru, kurā cilvēki:

  • nebaidās no neveiksmēm;
  • mācÄ«ties no kļūdām;
  • sadarboties ar citām komandām;
  • uzņemties iniciatÄ«vu;
  • uzņemties atbildÄ«bu;
  • apsveicam rezultātu kā mērÄ·i;
  • svinot panākumus.

Līdz ar to nāks arī viss pārējais.

Leons Uguns twitterī, facebook un vidējs.

Ir divas stratēģijas attiecÄ«bā uz mantojumu: izvairÄ«ties no darba ar to par katru cenu vai drosmÄ«gi pārvarēt ar to saistÄ«tās grÅ«tÄ«bas. Mēs c DevOpsConf Mēs ejam otro ceļu, mainot procesus un pieejas. Pievienojieties mums youtube, adresātu sarakstu Šø telegramma, un kopā mēs ieviesÄ«sim DevOps kultÅ«ru.

Avots: www.habr.com

Pievieno komentāru