Izstrādes process: ātrs pret pakāpenisku
Paraugprakses izmantošanas aspekti decentralizētā pasaulē
2001. gadā viens no mūsu izstrādātājiem ar nosaukumu Filips mēģināja klienta vietnē instalēt savu uzņēmuma programmatūru. Secinājums ir tāds, ka tad Oracle datu bāze avarēja, tāpēc, lai atrisinātu problēmu, viņam nācās atcelt pāris lidojumus uz mājām un pāris dienas strādāt par administratoru (DBA), lai to atjaunotu. Starp citu, tad viņš 14 stundas pēc kārtas nepārtraukti nodrošināja tehnisko atbalstu klientiem no Indijas, Anglijas un Kalifornijas, un tikai tad varēja sākt programmatūras instalēšanu. Pabeidzis darbu, viņam bija jāsaprot, kā viss darbojas, un jāidentificē visas iespējamās problēmas, ar kurām var saskarties potenciālie lietotāji, lai ātri reaģētu uz attiecīgajiem klienta pieprasījumiem.
Nedaudz vēlāk, 2010. gadā, es pieņēmu lēmumu ieviest pāris jaunas funkcijas vietnē, kurā toreiz strādāju. Es pievienoju jaunu reklāmkarogu, kas informē apmeklētājus par visiem jauninājumiem, un pēc 5 minūtēm es attālināti pieteicos serverī un palaidu visus skriptus. Acīmredzot pēc pusminūtes viss sāka darboties, un vietnes lietotāji sāka sniegt atsauksmes. Tiesa, viņi sastapās pēc tam ar vienu kļūdu, kuru stundu vēlāk man izdevās novērst pēc visiem “svilpieniem”.
Paātrināts attīstības temps
Pēdējo 20 gadu laikā programmatūras izstrādes segmentā ir notikušas būtiskas izmaiņas. Periodiska vietņu skenēšana ir pašreizējā mūsu laika tendence, kuru pastāvīgi izmanto tādi uzņēmumi kā Facebook vai GitHub, katru dienu desmitiem reižu pielāgojot savas vietnes. Šādi procesi notiek uzreiz — viens klikšķis un visa funkcionalitāte jau ir pārdalīta starp dažādām lietotāju grupām. Un tā rezultātā joprojām parādās dažādas kļūdas, lai gan saskaras tikai daži. Cita lieta, ka tie ir nenozīmīgi, tos ir viegli salabot, tikai daži cilvēki tos redz, un arī tad agrīnā stadijā, jo pats attīstības process notiek pakāpeniski. Visbiežākā šo kļūdu novēršanas blakusparādība ir attīstības tempa palēnināšana.
Tā kā mākoņpakalpojumi un rīki ir kļuvuši par mūsu ikdienas sastāvdaļu, un nepārtrauktas integrācijas un izvietošanas procesi ir kļuvuši pieejamāki, regulāra QA testēšana ir kļuvusi retāka, un pat tad tā ir populāra mazo komandu vidū agrīnā attīstības stadijā. Tāpēc šodien, tā vietā, lai ieviestu ieviešanu tūlīt pēc pilnīgas veselības pārbaudes, mazas izstrādes komandas izvēlas izmantot pēc kļūdu novēršanas stratēģiju, jo process ir pietiekami ātrs. Šāda pieeja apvienojumā ar identificēto kļūdu kompetentu klasifikāciju nodrošina nepārtrauktu darba produktivitāti, attīstības tempus, ļaujot mums piedāvāt tirgum joprojām efektīvu produktu.
Nepārtrauktu jauno uzņēmumu attīstību mūsdienās galvenokārt nodrošina spēja organizēt stingru automātisko kontroli pār infrastruktūru un izmantoto programmatūras kopumu: piemēram, tērzēšanas robots var pārsūtīt informāciju uz CI serveri, kas pats uzsāks noteiktu būvējumu un nodrošinās izvietošanu vairākos uzņēmuma serveros. Atkal ienākošā trafika tiek sadalīta saskaņā ar iepriekš definētiem noteikumiem, novirzot konkrētus lietotājus uz atsevišķiem serveriem. Neiesaiņotais kods spēj iekļaut telemetriju, kas ļauj savlaicīgi atklāt atritināšanas kļūdas un atcelt šo procesu automātiskajā vai manuālajā režīmā.
Šādas lietas mūsdienās ir parasta norma, jo jebkurš uzņēmums izmanto savas sistēmas, neatkarīgi kontrolē katras kodu un konfigurāciju, kā arī savlaicīgi saņem visu nepieciešamo telemetriju no visām infrastruktūrā pieejamajām iekārtām, ieskaitot virtuālo programmatūru.
Decentralizācija
Tagad aplūkosim decentralizētos tīklus, kas kopumā neatbilst jēdzienam “kontrole”. Izstrādes procesa organizēšana, kā rezultātā tiek iegūts labi konfigurēts decentralizēts tīkls, labākajā gadījumā kontrolē tikai visus esošos mezglus. Tajā pašā laikā pati vadība notiek manuālā režīmā, jo tikai dzīvie cilvēki uzrauga tīkla infrastruktūru. Kad visi tīkla dalībnieki vienlaikus izmanto dažādus mezglus, viņu uzvedība ir līdzīga neatkarīgiem dalībniekiem, un pašu slaucīšanas procesu kļūst grūtāk kontrolēt. Pareizi konfigurētā decentralizētā tīklā to galveno privātuma nodrošināšana, kuri pārvalda tā mezglus, kļūst par galveno punktu, jo telemetrija tiek pārraidīta paralēli, ko lielākā daļa tīkla dalībnieku var nemaz nepārsūtīt izstrādātājiem.
Arī varbūtība atrast kļūdas, kas ietekmē noteiktas lietotāju kategorijas, ir maza. Bet pat tad, ja tas bija veiksmīgs, nav tik viegli tos ātri izslēgt no visiem dalībniekiem uzreiz.
Savā ziņā šajā posmā mēs esam spiesti atgriezties pie šī raksta sākuma, jo mēs runājam par koda instalēšanu vienā noteiktā sistēmā bez iespējas to attālināti atjaunināt tiešsaistē. Šīs pieejas rezultāts mums ir zināms jau iepriekš — ir kļūdas, kas ļauj uzbrucējiem nozagt miljoniem dolāru ēterā (ETH), vai kļūdas, kas neļauj miljoniem lietotāju izveidot savienojumu ar tīklu. Centralizējot pamatpakalpojumus, var mēģināt apiet arī decentralizācijas nosacījumus. Dažos gadījumos kopiena pati var novērst šādas kļūdas, taču ideoloģisku iemeslu dēļ vai tāpēc, ka nav iespējams operatīvi koordinēt savu rīcību, tas ne vienmēr ir iespējams.
Pagātne, tagadne..Iepazīstieties ar nākotni
Tātad, kā tieši decentralizēto tīklu izstrādātājiem būtu jārīkojas ar šo jauno situāciju? Vai tiešām viņiem ir jāatsakās no pakāpeniskas, nepārtrauktas attīstības principiem, vai ir kāds vidusceļš? Mums šķiet, ka tomēr dažas efektīvas iespējas šādu problēmu risināšanai, kas saistītas ar decentralizēto tīklu attīstību, joprojām pastāvēja agrāk, un mēs tos varam uzzināt no pagātnes. Tomēr mums joprojām vajadzētu paturēt prātā nepārtrauktas attīstības pieredzi, kuras dēļ pat decentralizētās sistēmās ir iespējams nodrošināt drošību.
Tīkla palaišana testa režīmā patiešām ļauj nedaudz eksperimentēt ar dažiem jauninājumiem, jo ar to jūs varat simulēt mezglu pārtraukumu, tipiskus darījumus un visus citus pašreizējai realitātei raksturīgos apstākļus, kas ļauj palielināt pašu tīklu drošības līmeni, veiktspēju un stabilitāti. Diemžēl nav iespējams pilnībā simulēt reālos apstākļus, tāpēc testa tīklus var uzskatīt tikai par papildu rīku, taču dzīviem cilvēkiem joprojām būs jāatbild par realitāti.
Ilgtermiņa projekti, kuriem nepieciešama periodiska atjaunināšana, ir nepilnīgi un nepabeigti, jo pēc to uzsākšanas gandrīz noteikti būs nepieciešami darbības pielāgojumi. No otras puses, decentralizētiem projektiem nepieciešama rūpīgāka pieeja arī pēc to uzsākšanas, it īpaši attiecībā uz drošības aspektiem. Praksē tas nozīmē, ka sākumā šādu projektu funkciju kopumam jābūt minimālam. Šajā ziņā ir lietderīgi atgādināt par minimāli dzīvotspējīgā produkta (MVP) teoriju, kas šajā gadījumā ir saprātīga, jo provizoriskās izmaksas pilnvērtīga produkta ieviešanai vienmēr ir lielākas, un tāpēc mazāk dzīvotspējīga projekta sākotnējā izlaišana ar spēju novērtēt “tiešraides” reālās vajadzības un prasības. apstākļi ir piemērotāki.
Priekšrocība ir arī patiesu entuziastu kopienas atbalsts decentralizēta projekta izstrādes sākumposmā, jo šādi uzņēmēji operatori labprāt testēs jaunas versijas un sniegs ātru atgriezenisko saiti. Attīstoties šādai kopienai, iesaistīšanās pakāpe projektā pieaugs, kas ievērojami vienkāršos pilnīgu ieviešanu. Šādos apstākļos liela uzmanība jāpievērš kopienas veidošanai, kas uzticēsies izstrādātājiem un iet pareizajā virzienā, kas ļaus atrast optimālo līdzsvaru starp projekta infrastruktūras neatkarīgu pārvaldīšanu un pārvaldīšanu ar visas kopienas palīdzību. Augstu uzticēšanos pēdējiem var nodrošināt, izmantojot visveiksmīgākās prakses un augstas kvalitātes kodu, kas savukārt neitralizēs iespējamos riskus un vairāk motivēs jebkādu jauninājumu rašanos.
Ir daudz veidu, kā izmantot pašreizējo un iepriekšējo pieredzi decentralizētā pasaulē. Mēs ticam, ka nākamajās pāris nedēļās mēs arī dalīsimies ar jums ar jaunām idejām šajā sakarā, kā arī apspriedīsim savus plānus un pastāstīsim, ko mēs darām, pirms prezentējat projekta Keep Network pirmo versiju.
Paldies Džeimsam Prestvičam un Braitonam Viljamsam par ieguldījumu šī raksta agrīnā pārskatīšanā.
