Ir jau visādi projekti.   Kādreiz strādāju pie sistēmas, kur dažādos metro/būvlaikumos utt mēra trokšņu/vibrācijas līmeņus reālajā laikā. Tas viss tiek sūtīts uz serveriem, kalkulēts, vizualizēts utt uzreiz. Ja kautkas aiziet greizi, tad klienti jau saņēmuši notifikācijas, viņu serveri veikuši kautkādas darbības utt. Kautkāda beckupu atgriežāna, tik visu vēl vairāk sajauktu. Ja kautkas saiet greizi, tad reizēm diezgan sarežģiti 'salabot' un pat ar vienu dienu nepietiek lai 'atpiņķerētu' sekas. Vai vispār neviens nedēļu neievēro, ka kautkas cits neiet vai kalkulē ko nepareizi, ši upgreida pēc.

Pricedrop 70 eur

Tādēļ, ka sistēma pēc būtības nav izolēta, atomāra vienība? Tādēļ, ka problēmas reizēm atrod nevis apgreida laikā, bet kādu brīdi pēc apgreida pabeogšanas? Iemesli jau var būt dažādi.   Mūsu gadījumā "menedžeri" arī visos apgreidos piedalījās un procesa laikā arī varēja pieņemt lēmumus, kas attiecās uz biznesu.

Stulbs jautājums, bet kāpēc jālaiž dati no sistēmas, kas nav vēl pacelta? Ja tas ir ar downtime, tad norubī visu, ko var norubīt. Ja bez downtime, tad nu jā, cits stāsts. Feisbuku tiešām neesmu menedžējis. Toties esmu redzējis kā notiek projektu piegādes citos globālos uzņēmumos, nu, stress tur ir, bet contingency plāni arī. Nebūtu jāgaida uz meņeģeri līdz pirmdienai, jo meņeģeri visu laiku pieejami.

Nu tak mutes un mēles ir visiem. Ko tad tu domā kāds 24+ stundas pavadīs kautko labojot? Pienāks rīts un visi būs prom. Ja man kāds prasītu pa nakti kautko 'upgreidot' un pēctam vēl nākamajā dienā palikt uz vietas un turpināt, tad nu sorry, neesu nekāds robots. It īpaši ja ir citi cilvēki, kas var turpināt. Pēc definīcijas jau ja kāds piekrīt strādāt pa nakti, tad vismaz 2 brīvdienas pēctam 😂

Un kādus jēdzīgus lēmumus var sagaidīt no tiem, kam nav ne jausmas, kas un kāpēc nogāja greizi? Tas, kurš naktī bija klāt, varbūt tai problēmai jau stundu, divas veltīja un varbūt pat jau zina risinājumu, kamēr tas, kurš nebija klāt, neko vairāk par "kaut kas nestrādā" nezina un nemaz nevar zināt.

Svaigā galva domāta, ka atnāk tie kas pa nakti tur nemaz nebij. (jo kādus jēdzīgus lēmumus tu vari sagaidīt no tiem, kas bij iespējams augšā visu dienu un nakti, tur var sagaidīt vēl vairāk problēmas)

Nu es uz šito visu nemācēšu atbildēt. Nav nekādas pieredzes ar mūsdienu šāda veida iekārtām (kā jau iepriekš rakstīju: man bija WDTV) un nav arī bijis laika baigi smalki visu izpētīt. Pagaidām tikai parliecinājos, ka viss man vajadzīgais strādā.

Nu sistēmas ir dažādas. Tā pati pacelšana no backupa var būt neiespējama. Nu ko tu "pacelsi", ja jaunās sistēmas dati jau skraida pa ārējām sistēmām? Ko pacelsi no apgreida, ja sistēms "salauztā" sistēmas daļa savu darbu dara nevis katru sekundi, bet reizi mēnesī, nedēļu pēc apgreida?   Potenciālās problēmas apgreida laikā var būt neparedzamas. Vēl foršāk - principā pat bez jebkādiem apgreidiem jebkurā brīdī var iestāties kaut kāda šaize, kas testa vidē ar daudziem terrabaitiem datu nav bijusi atklāta. Ne tur visu paredzēt var, nedz arī "iepriekš saskaņot ar biznesu".   Ja reiz ir paredzēts, ka apgreida laikā var rasties kāda konkrēta (paredzama) problēma, tad pirms apgreida to atrisina vai izplāno, kā to risināt apgreida laikā. Pēc būtības tas nozīmē, ka tā vairs nav "problēma apgreida laikā", bet pilnīgi normāla apgreida procesa daļa.   Runājot par to svaigo galvu piektdienas rītā pēc apgreida… Esmu piedalījies apgreidā, kurš sākās kaut kad pievakarē (ap pl.21, pl.22) un beidzās no rīta, ap pl7., pl.8. Man kā developerim bija nevis aktīvi jāpiedalās, bet jāpaseko līdzi, lai nesavāra pārāk lielas ziepes, un problēmu gadījumā jānokonsultē vai jādebago un jāatrisina problēmas, kas procesā varētu rasties. Gulēt nedrīkstēja, bija jābūt klāt, lai jebkurā brīdī varētu pateikt "pagaidi, pārbaudīšu šito, pēc tam varēsi turpināt" vai atbildēt uz jautājumiem. Par kādu svaigu galvu piektdienas rītā pēc tāda procesa var būt runa? A ja nu apgreidam jānotiek konkrētā datumā? Un apgreida pārcelšana nozīmē, ka apgreids būs iespējams ne agrāk kā pēc 3 mēnešiem (ja paveiksies), bet funkcionalitāti vajag "šeit un tagad"?   Tie scenāriji ir daudzi un dažādi… Neviens no tiem nav ne ideāls, ne "vienīgais pareizais".   Jau sākās - "strādā, *ja* izpildās šāds, tāds un vēl kaut kāds nosacījums".   Saku tak, ka nestrādā variants "visiem lēmumiem jābūt saskaņotiem ar tiem, kas var tos pieņemt, jau iepriekš [neatkarīgi no sistēmas]".  

Jaa. Shie ir paarbaudiiti kanaali. https://youtube.com/@5.1musicchannel https://youtube.com/@surround2821  

Arī lielā sistēmā tam kokam ir jābūt skaidram un procedūrai aprakstītai. Īpaši tāpēc, ka kļūda var izmaksāt miljardus. Nu nevar gaidīt nākamās darba dienas rītu, paņemt pa ceļam kapiju, un gaitenī satiktam kolēģim pateikt - ā, hei, mums tur šaizīte, davaj, ieliekam uz 1iem mītiņu, ja priekšniekam brīvs.

Strādā, ja sīka sistēma un visu var izdomāt un paredzēt.

Tas tā nestrādā.

Tie upgreidi jau var būs dažnedažādos apmēros, no vienas weblapas servera rūtera nomaiņas, līdz bankas sistēmas upgreidam, kur kļūda var izmaksāt miljardus.  

Kādu svaigu galvu, kad gatavi nolinčot visi, kam nav slinkums?   Skaidrs, ka ne visu var atgriezt atpakaļ, bet visiem lēmumiem jābūt saskaņotiem ar tiem, kas var tos pieņemt, jau iepriekš. Lai visām pusēm ir skaidrs, kas notiek. Protams, ka var gadīties, ka brīdī, kad viena sistēma nonesta, otra vēl nav uzlikta, aizdegas servertlepa un applūst vieta, kur glabājas backupi, bet nu parasti tās tomēr bijušas vai nu dzelziskas problēmas, kur kaut kāds risinājums ir atrodams (ja tiek maksāts par supportu un garantiju), vai softiskas, kur paceļ no backupa.   Ja sistēma var gaidīt dienu uz lēmumiem, tad tā nav kritiska sistēma.

Ne vienmēr tas ir izdarāms. Un daudzkas var aiziet greizi, kas nav paredzēts ka varētu aiziet greizi. Ne visus lēmumus var pieņemt tie kas veic to upgreizdu. Plus ar svaigu galvu 5dienā var izdomāt rīcības plānu.

Nu man to sistēmu bija jāizstrādā, nevis jāuztur. Gadījās, protams, pa kādai "emergency" situācijai, bet varēju telefoniski atbildēt "neesmu pie datora, vēlāk paskatīšos, ja bez manis nebūsiet tikuši galā".   Runājot par haļavu - garlaicīga, apnikusi, gribas beidzot kaut kādu darbu, kur būtu jādomā, jāmācās, jāstrādā, nevis tikai "jāatsēž". Gadās arī tā... Un reizēm tie biznesa daļas pieņemtie un devopsu izpildītie lēmumi ir tādi, ka pēc tam developeriem diezgan ilgi jārisina savārītās ziepes   Maziņa sistēmiņa... Ne vienmēr tas ir izdarāms.

Pieņemtu lēmumus?! 😮  Manā pieredzē, pie nopietnām izmaiņām infrastruktūrā, notika tā: Ir paredzamie darbi X, aptuveni zināms ilgums Ir aptuveni zināms ilgums, cik prasa atgriezt visu sākotnējā stāvoklī. Y Ir skaidrs plāns - cikos sākam, cikos pabeidzam katru soli un visu procesu. Ja Y+xx stundas pirms visa procesa beigām darbi X nav pabeigti, sākam atgriezt visu, kā bija.

Parastā prakse ir no ceturdienas uz piektdienu naktī, tad ja kautkas aiziet šķībi, tad ir viena darbadiena, lai pieņemtu lēmumus un setdiena/svētdiena, lai salabotu.

Jums no Youtubes kaut kā daudzkanālu skaņu ir izdevies dabūt?