ProHoster > Blogs > Administrācija > Infrastruktūra kā kods: kā pārvarēt problēmas, izmantojot XP

Infrastruktūra kā kods: kā pārvarēt problēmas, izmantojot XP

Sveiks, Habr! IepriekÅ” sÅ«dzējos par dzÄ«vi InfrastruktÅ«rā kā koda paradigmā un neko nepiedāvāju, lai atrisinātu esoÅ”o situāciju. Å odien es atgriezÄ«Å”os, lai pastāstÄ«tu, kādas pieejas un prakses palÄ«dzēs jums izkļūt no izmisuma bezdibeņa un virzÄ«t situāciju pareizajā virzienā.

Infrastruktūra kā kods: kā pārvarēt problēmas, izmantojot XP

IepriekŔējā rakstā "InfrastruktÅ«ra kā kods: pirmā iepazÄ«Å”anās" Es dalÄ«jos savos iespaidos par Å”o jomu, mēģināju pārdomāt paÅ”reizējo situāciju Å”ajā jomā un pat ierosināju, ka varētu palÄ«dzēt visiem izstrādātājiem zināma standarta prakse. Varētu Ŕķist, ka par dzÄ«vi bija daudz sÅ«dzÄ«bu, bet priekÅ”likumu par izeju no esoŔās situācijas nebija.

Kas mēs esam, kur mēs atrodamies un kādas problēmas mums ir

Å obrÄ«d esam Sre Onboarding Team, kurā ir seÅ”i programmētāji un trÄ«s infrastruktÅ«ras inženieri. Mēs visi cenÅ”amies rakstÄ«t infrastruktÅ«ru kā kodu (IaC). Mēs to darām, jo ā€‹ā€‹pamatā zinām, kā rakstÄ«t kodu, un esam bijuÅ”i ā€œvirs vidējā lÄ«meņaā€ izstrādātāji.

  • Mums ir virkne priekÅ”rocÄ«bu: noteikta pieredze, zināŔanas par praksi, spēja rakstÄ«t kodu, vēlme apgÅ«t jaunas lietas.
  • Un ir nokarenā daļa, kas ir arÄ« mÄ«nuss: zināŔanu trÅ«kums par infrastruktÅ«ras aparatÅ«ru.

Tehnoloģiju kopums, ko izmantojam savā IaC.

  • Terraforma resursu radÄ«Å”anai.
  • Iepakotājs attēlu salikÅ”anai. Tie ir Windows, CentOS 7 attēli.
  • Jsonnet, lai izveidotu jaudÄ«gu bÅ«vējumu vietnē drone.io, kā arÄ« Ä£enerētu pakotnes json un mÅ«su terraform moduļus.
  • Azura.
  • Iespējams, gatavojot attēlus.
  • Python palÄ«gpakalpojumiem un nodroÅ”ināŔanas skriptiem.
  • Un tas viss VSCode ar spraudņiem, ko koplieto komandas dalÄ«bnieki.

Secinājums no mana pēdējais raksts bija Ŕāds: es centos (pirmkārt sevÄ«) iedvest optimismu, gribēju teikt, ka izmēģināsim mums zināmās pieejas un prakses, lai tiktu galā ar grÅ«tÄ«bām un sarežģījumiem, kas pastāv Å”ajā jomā.

PaÅ”laik mēs cÄ«nāmies ar Ŕādām IaC problēmām:

  • Koda izstrādes rÄ«ku un lÄ«dzekļu nepilnÄ«bas.
  • Lēna izvietoÅ”ana. InfrastruktÅ«ra ir daļa no reālās pasaules, un tā var bÅ«t lēna.
  • Pieeju un prakses trÅ«kums.
  • Mēs esam jauni un neko daudz nezinām.

Ekstrēmā programmÄ“Å”ana (XP) glābÅ”anai

Visi izstrādātāji ir iepazinuÅ”ies ar ekstrēmo programmÄ“Å”anu (XP) un ar to saistÄ«to praksi. Daudzi no mums ir strādājuÅ”i ar Å”o pieeju, un tā ir bijusi veiksmÄ«ga. Tātad, kāpēc neizmantot tur noteiktos principus un praksi, lai pārvarētu infrastruktÅ«ras problēmas? Mēs nolēmām izmantot Å”o pieeju un redzēt, kas notiks.

XP pieejas pielietojamības pārbaude jūsu nozarēTālāk ir sniegts apraksts par vidi, kurai XP ir labi piemērota, un kā tā ir saistīta ar mums:

1. Dinamiski mainÄ«gas programmatÅ«ras prasÄ«bas. Mums bija skaidrs, kāds ir gala mērÄ·is. Bet detaļas var atŔķirties. Mēs paÅ”i izlemjam, kur mums jātakso, tāpēc prasÄ«bas periodiski mainās (galvenokārt paÅ”i). Ja ņemam SRE komandu, kas pati veic automatizāciju un pati ierobežo prasÄ«bas un darba apjomu, tad Å”is punkts labi iederas.

2. Riski, ko rada noteikta laika projekti, izmantojot jaunas tehnoloÄ£ijas. Mēs varam saskarties ar riskiem, lietojot dažas mums nezināmas lietas. Un tas ir 100% mÅ«su gadÄ«jums. Viss mÅ«su projekts bija tādu tehnoloÄ£iju izmantoÅ”ana, kuras mēs lÄ«dz galam nebijām pazÄ«stami. Kopumā tā ir pastāvÄ«ga problēma, jo... InfrastruktÅ«ras sektorā visu laiku parādās daudzas jaunas tehnoloÄ£ijas.

3,4. Maza, lÄ«dzās izvietota paplaÅ”ināta izstrādes komanda. JÅ«su izmantotā automatizētā tehnoloÄ£ija ļauj veikt vienÄ«bu un funkcionālos testus. Å ie divi punkti mums nav Ä«sti piemēroti. Pirmkārt, mēs neesam saskaņota komanda, otrkārt, esam deviņi, ko var uzskatÄ«t par lielu komandu. Lai gan saskaņā ar dažām ā€œlielasā€ komandas definÄ«cijām daudz ir 14+ cilvēki.

Apskatīsim dažas XP metodes un to, kā tās ietekmē atgriezeniskās saites ātrumu un kvalitāti.

XP atsauksmju cilpas princips

Manā izpratnē atgriezeniskā saite ir atbilde uz jautājumu, vai es daru pareizi, vai mēs tur ejam? XP tam ir dieviŔķa shēma: laika atgriezeniskās saites cilpa. Interesanti ir tas, ka jo zemāk esam, jo ā€‹ā€‹Ätrāk spējam panākt, lai OS atbild uz nepiecieÅ”amajiem jautājumiem.

Infrastruktūra kā kods: kā pārvarēt problēmas, izmantojot XP

Å Ä« ir diezgan interesanta tēma diskusijai, ka mÅ«su IT nozarē ir iespējams ātri iegÅ«t OS. Iedomājieties, cik sāpÄ«gi ir seÅ”us mēneÅ”us taisÄ«t projektu un tikai pēc tam uzzināt, ka paŔā sākumā ir bijusi kļūda. Tas notiek projektÄ“Å”anā un jebkurā sarežģītu sistēmu bÅ«vniecÄ«bā.

MÅ«su IaC gadÄ«jumā atsauksmes mums palÄ«dz. Es nekavējoties veicu nelielu korekciju iepriekÅ” redzamajā diagrammā: izlaiÅ”anas plānā nav mēneÅ”a cikla, bet tas notiek vairākas reizes dienā. Ir dažas prakses, kas saistÄ«tas ar Å”o OS ciklu, kuras mēs aplÅ«kosim sÄ«kāk.

SvarÄ«gi: atsauksmes var bÅ«t visu iepriekÅ” minēto problēmu risinājums. Apvienojumā ar XP praksēm tas var izvilkt jÅ«s no izmisuma bezdibeņa.

Kā izvilkt sevi no izmisuma bezdibeņa: trīs prakses

Testi

XP atgriezeniskās saites cilpā testi ir minēti divreiz. Tas nav tikai tā. Tie ir ārkārtīgi svarīgi visai Extreme Programming tehnikai.

Tiek pieņemts, ka jums ir vienÄ«bas un pieņemÅ”anas testi. Daži sniedz jums atsauksmes dažu minÅ«Å”u laikā, citi dažu dienu laikā, tāpēc to rakstÄ«Å”ana prasa ilgāku laiku un tiek pārskatÄ«ta retāk.

Ir klasiska testÄ“Å”anas piramÄ«da, kas parāda, ka testu vajadzētu bÅ«t vairāk.

Infrastruktūra kā kods: kā pārvarēt problēmas, izmantojot XP

Kā Ŕī sistēma attiecas uz mums IaC projektā? PatiesÄ«bā... nemaz.

  • VienÄ«bas testu, neskatoties uz to, ka tiem vajadzētu bÅ«t daudz, nevar bÅ«t pārāk daudz. Vai arÄ« viņi kaut ko ļoti netieÅ”i pārbauda. PatiesÄ«bā mēs varam teikt, ka mēs tos vispār nerakstām. Bet Å”eit ir daži pieteikumi Ŕādiem testiem, ko mēs varējām veikt:
    1. Jsonnet koda pārbaude. Tas, piemēram, ir mūsu dronu montāžas cauruļvads, kas ir diezgan sarežģīts. Jsonnet kods ir labi aptverts ar testiem.
      Mēs izmantojam Å”o VienÄ«bu testÄ“Å”anas sistēma Jsonnet.
    2. Pārbauda skriptus, kas tiek izpildīti, kad resurss sākas. Skripti tiek rakstīti Python, un tāpēc uz tiem var rakstīt testus.
  • Konfigurāciju ir iespējams pārbaudÄ«t testos, bet mēs to nedarām. Ir iespējams arÄ« konfigurēt resursu konfigurācijas noteikumu pārbaudes, izmantojot tflints. Tomēr pārbaudes tur vienkārÅ”i ir pārāk vienkārÅ”as terraformai, taču daudzi testa skripti ir rakstÄ«ti AWS. Mēs izmantojam Azure, tāpēc tas atkal neattiecas.
  • Komponentu integrācijas testi: tas ir atkarÄ«gs no tā, kā jÅ«s tos klasificējat un kur tos ievietojat. Bet pamatā viņi strādā.

    Šādi izskatās integrācijas testi.

    Infrastruktūra kā kods: kā pārvarēt problēmas, izmantojot XP

    Å is ir piemērs, veidojot attēlus Drone CI. Lai tos sasniegtu, jums ir jāgaida 30 minÅ«tes, lÄ«dz tiek izveidots pakotnes attēls, un pēc tam vēl 15 minÅ«tes, lÄ«dz tie pazÅ«d. Bet viņi pastāv!

    Attēla pārbaudes algoritms

    1. Iepakotājam vispirms ir pilnībā jāsagatavo attēls.
    2. Blakus testam ir terraforma ar vietējo stāvokli, ko mēs izmantojam Ŕī attēla izvietoÅ”anai.
    3. Atlokot, tiek izmantots neliels modulis, kas atrodas blakus, lai atvieglotu darbu ar attēlu.
    4. Kad VM ir izvietots no attēla, var sākties pārbaudes. BÅ«tÄ«bā pārbaudes tiek veiktas ar automaŔīnu. Tas pārbauda, ā€‹ā€‹kā skripti darbojās startÄ“Å”anas laikā un kā darbojas dēmoni. Lai to izdarÄ«tu, izmantojot ssh vai winrm, mēs piesakāmies jaunizveidotajā maŔīnā un pārbaudām konfigurācijas statusu vai pakalpojumu darbÄ«bu.

  • LÄ«dzÄ«ga situācija ir ar integrācijas testiem terraform moduļos. Å eit ir Ä«sa tabula, kurā izskaidrotas Ŕādu testu Ä«paŔības.

    Infrastruktūra kā kods: kā pārvarēt problēmas, izmantojot XP

    Atsauksmes par cauruļvadu ir aptuveni 40 minūtes. Viss notiek ļoti ilgu laiku. To var izmantot regresijai, bet jaunai attīstībai tas kopumā ir nereāls. Ja esat tam ļoti, ļoti sagatavojies, sagatavojiet palaistos skriptus, tad varat to samazināt līdz 10 minūtēm. Bet tie joprojām nav vienības testi, kas veic 5 gabalus 100 sekundēs.

VienÄ«bu pārbaužu trÅ«kums attēlu vai terraformu moduļu montāžas laikā mudina darbu pārcelt uz atseviŔķiem pakalpojumiem, kurus var vienkārÅ”i palaist, izmantojot REST, vai uz Python skriptiem.

Piemēram, mums bija jāpārliecinās, ka, startējot virtuālo maŔīnu, tā reÄ£istrē sevi pakalpojumā MērogsFT, un, kad virtuālā maŔīna tika iznÄ«cināta, tā pati izdzēsās.

Tā kā mums ir ScaleFT kā pakalpojums, mēs esam spiesti strādāt ar to, izmantojot API. Tur bija rakstÄ«ts iesaiņojums, ko var pavilkt un teikt: "Ieej un izdzēsiet to un to." Tas saglabā visus nepiecieÅ”amos iestatÄ«jumus un piekļuves.

Par to jau varam rakstīt parastus testus, jo tas ne ar ko neatŔķiras no parastās programmatūras: kaut kāda apiha tiek izsmieta, tu to pavelc un skaties, kas notiek.

Infrastruktūra kā kods: kā pārvarēt problēmas, izmantojot XP

Pārbaužu rezultāti: VienÄ«bas testÄ“Å”ana, kurai vajadzētu dot OS minÅ«tē, to nedod. Pārbaudes veidi, kas atrodas augstāk piramÄ«dā, ir efektÄ«vi, taču aptver tikai daļu no problēmām.

Pāru programmÄ“Å”ana

Pārbaudes, protams, ir labas. JÅ«s varat tos rakstÄ«t daudz, tie var bÅ«t dažāda veida. Viņi strādās savā lÄ«menÄ« un sniegs mums atsauksmes. Bet problēma ar sliktiem vienÄ«bas testiem, kas nodroÅ”ina ātrāko OS, paliek. Tajā paŔā laikā es joprojām gribu ātru OS, ar kuru ir viegli un patÄ«kami strādāt. Nemaz nerunājot par iegÅ«tā risinājuma kvalitāti. Par laimi, ir metodes, kas var nodroÅ”ināt pat ātrāku atgriezenisko saiti nekā vienÄ«bas testi. Å Ä« ir pāra programmÄ“Å”ana.

Rakstot kodu, vēlaties pēc iespējas ātrāk saņemt atsauksmes par tā kvalitāti. Jā, jÅ«s varat rakstÄ«t visu funkciju zarā (lai nevienam neko nesabojātu), Githubā veikt izvilkÅ”anas pieprasÄ«jumu, pieŔķirt to kādam, kura viedoklim ir nozÄ«me, un gaidÄ«t atbildi.

Bet jÅ«s varat gaidÄ«t ilgi. Cilvēki visi ir aizņemti, un atbilde, pat ja tāda ir, var nebÅ«t kvalitatÄ«vāka. Pieņemsim, ka atbilde nāca uzreiz, recenzents uzreiz saprata visu domu, bet atbilde tomēr nāk novēloti, pēc fakta. Es vēlos, lai tas bÅ«tu agrāk. TieÅ”i uz to ir vērsta pāru programmÄ“Å”ana ā€“ uzreiz, rakstÄ«Å”anas laikā.

Tālāk ir norādÄ«ti pāru programmÄ“Å”anas stili un to pielietojamÄ«ba darbā ar IaC:

1. Klasika, Pieredzējis+Pieredzējis, maiņa pēc taimera. Divas lomas ā€“ Å”oferis un navigators. Divi cilvēki. Viņi strādā ar vienu un to paÅ”u kodu un maina lomas pēc noteikta iepriekÅ” noteikta laika.

Apsvērsim mūsu problēmu saderību ar stilu:

  • Problēma: koda izstrādes rÄ«ku un rÄ«ku nepilnÄ«bas.
    Negatīvā ietekme: tas attīstās ilgāk, mēs palēnināmies, darba temps/ritms zūd.
    Kā mēs cÄ«nāmies: mēs izmantojam atŔķirÄ«gus rÄ«kus, kopÄ«gu IDE un arÄ« apgÅ«stam saÄ«snes.
  • Problēma: lēna izvietoÅ”ana.
    Negatīva ietekme: palielina laiku, kas nepiecieŔams, lai izveidotu darba koda daļu. Gaidot mums kļūst garlaicīgi, rokas stiepjas, lai gaidot paveiktu ko citu.
    Kā mēs cīnāmies: mēs to nepārvarējām.
  • Problēma: pieejas un prakses trÅ«kums.
    NegatÄ«vā ietekme: nav zināŔanu par to, kā to izdarÄ«t labi un kā to izdarÄ«t slikti. Pagarina atsauksmju saņemÅ”anu.
    Kā mēs cīnāmies: savstarpēja viedokļu un prakses apmaiņa pāru darbā gandrīz atrisina problēmu.

Galvenā problēma, izmantojot Å”o stilu IaC, ir nevienmērÄ«gais darba temps. Tradicionālajā programmatÅ«ras izstrādē jums ir ļoti vienveidÄ«ga kustÄ«ba. JÅ«s varat pavadÄ«t piecas minÅ«tes un rakstÄ«t N. Pavadiet 10 minÅ«tes un rakstiet 2N, 15 minÅ«tes - 3N. Å eit jÅ«s varat pavadÄ«t piecas minÅ«tes un rakstÄ«t N, un pēc tam pavadÄ«t vēl 30 minÅ«tes un uzrakstÄ«t desmito daļu no N. Å eit jÅ«s neko nezināt, jÅ«s esat iestrēdzis, stulba. IzmeklÄ“Å”ana prasa laiku un novērÅ” uzmanÄ«bu no paÅ”as programmÄ“Å”anas.

Secinājums: tīrā veidā tas mums nav piemērots.

2. Ping-pongs. Å Ä« pieeja paredz, ka viena persona raksta testu, bet cita veic tā ievieÅ”anu. Ņemot vērā to, ka ar Unit testiem viss ir sarežģīti, un ir jāraksta integrācijas tests, kura programmÄ“Å”ana prasa ilgu laiku, visa pingponga vienkārŔība pazÅ«d.

Varu teikt, ka mēs mēģinājām nodalÄ«t atbildÄ«bu par testa skripta izstrādi un tā koda ievieÅ”anu. Viens dalÄ«bnieks izdomāja scenāriju, Å”ajā darba daļā viņŔ bija atbildÄ«gs, viņam piederēja pēdējais vārds. Un otrs bija atbildÄ«gs par ievieÅ”anu. Tas izdevās labi. Ar Å”o pieeju palielinās skripta kvalitāte.

Secinājums: diemžēl darba temps neļauj izmantot galda tenisu kā pāru programmÄ“Å”anas praksi IaC.

3. SpēcÄ«gs stils. Sarežģīta prakse. Ideja ir tāda, ka viens dalÄ«bnieks kļūst par direktÄ«vu navigatoru, bet otrs uzņemas izpildes virzÄ«tāja lomu. Å ajā gadÄ«jumā tiesÄ«bas pieņemt lēmumus ir tikai navigatoram. VadÄ«tājs tikai drukā un var ietekmēt notiekoÅ”o ar vārdu. Lomas nemainās ilgu laiku.

Piemērots mācībām, bet prasa spēcīgas mīkstās prasmes. Lūk, kur mēs klibojām. Tehnika bija grūta. Un tas pat nav par infrastruktūru.

Secinājums: to potenciāli var izmantot, mēs nepametam mēģinājumus.

4. Mobings, spietoÅ”ana un visi zināmie, bet neuzskaitÄ«tie stili Mēs to neuzskatām, jo Mēs to neesam mēģinājuÅ”i, un par to nav iespējams runāt mÅ«su darba kontekstā.

VispārÄ«gi pāru programmÄ“Å”anas rezultāti:

  • Mums ir nevienmērÄ«gs darba temps, kas rada apjukumu.
  • Mēs saskārāmies ar nepietiekami labām mÄ«kstajām prasmēm. Un priekÅ”metu joma nepalÄ«dz pārvarēt Å”os mÅ«su trÅ«kumus.
  • Ilgi testi un problēmas ar rÄ«kiem apgrÅ«tina izstrādi pārÄ«.

5. Neskatoties uz to, bija panākumi. Mēs nācām klajā ar savu metodi ā€œKonverÄ£ence - DiverÄ£enceā€. Es Ä«si aprakstÄ«Å”u, kā tas darbojas.

Mums ir pastāvīgi partneri uz dažām dienām (mazāk par nedēļu). Mēs kopā veicam vienu uzdevumu. Kādu laiku pasēžam kopā: viens raksta, otrs sēž un vēro atbalsta komandu. Pēc tam kādu laiku izklīdinām, katrs veic kādas patstāvīgas lietas, tad atkal sanākam kopā, ļoti ātri sinhronizējamies, kaut ko darām kopā un atkal izklīdinām.

PlānoŔana un komunikācija

Pēdējais prakÅ”u bloks, caur kuru tiek risinātas OS problēmas, ir darba organizācija ar paÅ”iem uzdevumiem. Tas ietver arÄ« pieredzes apmaiņu, kas notiek ārpus pāru darba. ApskatÄ«sim trÄ«s prakses:

1. MērÄ·i caur mērÄ·a koku. Mēs organizējām kopējo projekta vadÄ«bu caur koku, kas bezgalÄ«gi sniedzas nākotnē. Tehniski izsekoÅ”ana tiek veikta Miro. Ir viens uzdevums ā€“ tas ir starpmērÄ·is. No tā aiziet vai nu mazāki mērÄ·i, vai uzdevumu grupas. PaÅ”i uzdevumi nāk no viņiem. Visi uzdevumi tiek izveidoti un uzturēti Å”ajā dēlÄ«.

Infrastruktūra kā kods: kā pārvarēt problēmas, izmantojot XP

Å Ä« shēma nodroÅ”ina arÄ« atgriezenisko saiti, kas notiek reizi dienā, kad sinhronizējamies mÄ«tiņos. KopÄ«gs plāns visiem priekŔā, bet strukturēts un pilnÄ«gi atklāts, ļauj ikvienam apzināties notiekoÅ”o un to, cik tālu esam progresējuÅ”i.

Uzdevumu vizuālā redzējuma priekÅ”rocÄ«bas:

  • CēloņsakarÄ«ba. Katrs uzdevums ved uz kādu globālu mērÄ·i. Uzdevumi tiek grupēti mazākos mērÄ·os. Pats infrastruktÅ«ras domēns ir diezgan tehnisks. Ne vienmēr ir uzreiz skaidrs, kāda konkrēta ietekme uz biznesu ir, piemēram, runbook rakstÄ«Å”ana par migrÄ“Å”anu uz citu nginx. Ja mērÄ·a karte atrodas tuvumā, tas kļūst skaidrāks.
    Infrastruktūra kā kods: kā pārvarēt problēmas, izmantojot XP
    CēloņsakarÄ«ba ir svarÄ«ga problēmu Ä«paŔība. Tas tieÅ”i atbild uz jautājumu: "Vai es daru pareizi?"
  • Paralēlisms. Mēs esam deviņi, un ir vienkārÅ”i fiziski neiespējami visus mest vienā uzdevumā. Ne vienmēr var pietikt arÄ« ar vienas jomas uzdevumiem. Mēs esam spiesti paralēli strādāt starp mazām darba grupām. Tajā paŔā laikā grupas kādu laiku sēž uz savu uzdevumu, tās var pastiprināt kāds cits. Dažreiz cilvēki atkrÄ«t no Ŕīs darba grupas. Kāds dodas atvaļinājumā, kāds veido atskaiti DevOps konf., kāds raksta rakstu par Habr. Ä»oti svarÄ«gi kļūst zināt, kādus mērÄ·us un uzdevumus var veikt paralēli.

2. RÄ«ta sanāksmju vadÄ«tāju nomaiņa. Pie stāvÄ“Å”anas mums ir tāda problēma ā€“ cilvēki daudzus uzdevumus veic paralēli. Dažreiz uzdevumi ir brÄ«vi saistÄ«ti, un nav izpratnes par to, kurÅ” ko dara. Un vēl viena komandas biedra viedoklis ir ļoti svarÄ«gs. Å Ä« ir papildu informācija, kas var mainÄ«t problēmas risināŔanas gaitu. Protams, parasti kāds ir lÄ«dzi, bet padomi un padomi vienmēr noder.

Lai uzlabotu Å”o situāciju, mēs izmantojām paņēmienu ā€œChanging the Leading Stand-Upā€. Tagad tie tiek pagriezti saskaņā ar noteiktu sarakstu, un tam ir sava ietekme. Kad pienāk jÅ«su kārta, jÅ«s esat spiests ienirt un saprast, kas notiek, lai novadÄ«tu labu Scrum sanāksmi.

Infrastruktūra kā kods: kā pārvarēt problēmas, izmantojot XP

3. IekŔējā demonstrācija. PalÄ«dzÄ«ba problēmas risināŔanā no pāru programmÄ“Å”anas, vizualizācijas problēmu kokā un palÄ«dzÄ«ba scrum sanāksmēs no rÄ«ta ir laba, bet ne ideāla. Kā pāris jÅ«s ierobežo tikai jÅ«su zināŔanas. Uzdevumu koks palÄ«dz globāli saprast, kas ko dara. Un vadÄ«tājs un kolēģi rÄ«ta sanāksmē neiedziļinās jÅ«su problēmās. Viņi noteikti varētu kaut ko palaist garām.

Risinājums tika rasts, demonstrējot viens otram paveikto un pēc tam pārrunājot to. Mēs tiekamies reizi nedēļā uz stundu un parādām detalizētu informāciju par pēdējās nedēļas laikā paveikto uzdevumu risinājumiem.

Demonstrācijas laikā ir jāatklāj uzdevuma detaļas un noteikti jādemonstrē tā darbība.

Ziņojumu var veikt, izmantojot kontrolsarakstu.1. Ieejiet kontekstā. No kurienes radās uzdevums, kāpēc tas vispār bija vajadzīgs?

2. Kā problēma tika atrisināta iepriekÅ”? Piemēram, bija nepiecieÅ”ams masveida peles klikŔķis, vai arÄ« nebija iespējams kaut ko darÄ«t.

3. Kā mēs to uzlabojam. Piemēram: ā€œSkatieties, tagad ir skriptosik, Å”eit ir lasÄ«t mani.ā€

4. Parādiet, kā tas darbojas. Ir ieteicams tieÅ”i ieviest kādu lietotāja scenāriju. Es gribu X, es daru Y, es redzu Y (vai Z). Piemēram, es izvietoju NGINX, izsmēķēju URL un saņemu 200 OK. Ja darbÄ«ba ir ilga, sagatavojiet to iepriekÅ”, lai varētu to parādÄ«t vēlāk. Ja tas ir trausls, stundu pirms demonstrācijas ir ieteicams to pārāk nesalauzt.

5. Paskaidrojiet, cik veiksmīgi problēma tika atrisināta, kādas grūtības saglabājas, kas nav pabeigts, kādi uzlabojumi iespējami nākotnē. Piemēram, tagad CLI, tad CI būs pilna automatizācija.

Katram runātājam ieteicams to paturēt lÄ«dz 5-10 minÅ«tēm. Ja jÅ«su runa ir acÄ«mredzami svarÄ«ga un prasÄ«s ilgāku laiku, iepriekÅ” saskaņojiet to sre-takeover kanālā.

Pēc klātienes daļas pavedienā vienmēr notiek diskusija. Å eit parādās atgriezeniskā saite, kas mums nepiecieÅ”ama par mÅ«su uzdevumiem.

Infrastruktūra kā kods: kā pārvarēt problēmas, izmantojot XP
Rezultātā tiek veikta aptauja, lai noskaidrotu notiekoŔā lietderību. Tā ir atgriezeniskā saite par runas būtību un uzdevuma nozīmi.

Infrastruktūra kā kods: kā pārvarēt problēmas, izmantojot XP

Gari secinājumi un kas tālāk

Var Ŕķist, ka raksta tonis ir nedaudz pesimistisks. Tas ir nepareizi. Darbojas divi zemāki atgriezeniskās saites lÄ«meņi, proti, testi un pāru programmÄ“Å”ana. Nav tik ideāls kā tradicionālajā attÄ«stÄ«bā, taču tam ir pozitÄ«va ietekme.

Testi to paÅ”reizējā formā nodroÅ”ina tikai daļēju koda pārklājumu. Daudzas konfigurācijas funkcijas netiek pārbaudÄ«tas. To ietekme uz faktisko darbu, rakstot kodu, ir zema. Tomēr integrācijas testiem ir ietekme, un tie ļauj bezbailÄ«gi veikt pārstrukturÄ“Å”anu. Tas ir liels sasniegums. Turklāt, pārejot uz attÄ«stÄ«bu augsta lÄ«meņa valodās (mums ir python, go), problēma pazÅ«d. Un jums nav nepiecieÅ”ams daudz pārbaudÄ«t ā€œlÄ«miā€, pietiek ar vispārēju integrācijas pārbaudi.

Darbs pāros vairāk atkarÄ«gs no konkrētiem cilvēkiem. Ir uzdevuma faktors un mÅ«su mÄ«kstās prasmes. Ar dažiem cilvēkiem tas izdodas ļoti labi, ar citiem sliktāk. No tā noteikti ir ieguvumi. Skaidrs, ka pat tad, ja netiek pietiekami ievēroti pāru darba noteikumi, pats uzdevumu kopÄ«gās izpildes fakts pozitÄ«vi ietekmē rezultāta kvalitāti. PersonÄ«gi man Ŕķiet, ka strādāt pāros ir vieglāk un patÄ«kamāk.

Augstāka lÄ«meņa OS ietekmÄ“Å”anas veidi - precÄ«za uzdevumu plānoÅ”ana un darbs ar tiem rada efektus: kvalitatÄ«va zināŔanu apmaiņa un uzlabota izstrādes kvalitāte.

ÄŖsi secinājumi vienā rindā

  • HR praktiÄ·i strādā IaC, taču ar mazāku efektivitāti.
  • Nostipriniet to, kas darbojas.
  • Izstrādājiet savus kompensācijas mehānismus un praksi.

Avots: www.habr.com

Pievieno komentāru