Názory k článku
GitLab.com dočasně offline, omylem došlo ke smazání produkční databáze
-
a-non (neregistrovaný)
"$" na zacatku signalizuje jen to, ze je to soucasti promptu a jen to, ze jsem to tam napsal protoze to mam ve zvyku z psani manualu k odliseni zacatku command-line
jini kolegove pouzivaji "#", popripade ">" nebo ":" v zavislosti na tom, kdo co preferuje ve svem PS1 a s cim vyrustal
nehledejte hlubsi smysl tam kde neni :) -
Lukáš Chmela (neregistrovaný)
Promiňte, ale připomínka nad Vaším posledním příspěvkem byla věcná a řekl bych i dost důležitá, protože takto se terminál chová standardně. Že máte ve firmě každý nastavenou jinou podobu vstupního řádku je samozřejmě každého boj, ale pokud píšete manuály takto ledabyle, přesně o problémy typu spuštěný příkaz na špatném stroji nebo disku si koledujete. Nicméně Vám děkuji pěkné vysvětlení věčně omílaného příkazu. Pro leckoho by bylo přínosné.
-
j (neregistrovaný)
Firma na to vyhradi cas ... ale ucetni chce resit to, ze ji nejde uctovat ... a zavola ti, mzdova chce resit to, jestli ji to opatchujes ted nebo za tejden, a zavola ti, dalsi se prijde zeptat, kdy dostane ten novej ntb, pak nekdo brnkne, ze posla tiskarna ... a i kdybys mel kazdymu jen rict, ze to ted resit nebudes protoze delas neco jinyho, tak si prave zapomel, kde si skoncil.
Neznam zadnou firmu, kde by se reklo "ok, zejtra zavrem, protoze ITci budou patchovat ...".
Kdyz se resej akce kvuli kterym je treba neco vypnout, tak se to resi pokud je to mozny vzdycky mimo provoz firmy, ale i kdyz delas veci kvuli kterym se nic vypinat nemusi, tak si muzes paradne nadelat do vlastniho ....
Bohate staci, kdyz treba pises nejakej nevinej update, nekdo zavola ... a ty ho pustis bez where. Nebo mas otevrenych 10x sshcko ... a command pustis jinde nez si chtel, coz je presne tenhle pripad. Takova klasika, pri ktery se zasmejes, je, ze neco hodinu confis, a pak zjistis, ze ses v testovacim systemu misto v ostrym ... jednoduse proto, ze te nekdo vyrusil, a tys na to vyruseni musel nejak reagovat.
-
Bohate staci, kdyz treba pises nejakej nevinej update, nekdo zavola ... a ty ho pustis bez where. Nebo mas otevrenych 10x sshcko ... a command pustis jinde nez si chtel, coz je presne tenhle pripad. Takova klasika, pri ktery se zasmejes, je, ze neco hodinu confis, a pak zjistis, ze ses v testovacim systemu misto v ostrym ... jednoduse proto, ze te nekdo vyrusil, a tys na to vyruseni musel nejak reagovat.
Ale jo, já to znám, jsem admin. Ale jako k vůli tomu, že jsou všichni kolem mě debilové to nebudu dělat ve 3 ráno. Nehledě na to, že nechci chcípnout ve 40 na infarkt z trvalýho stresu, jak se to povedlo již několika lidem v IT.
-
Ondra Satai NekolaZlatý podporovatelJestli on neni problem uz v tom, ze admin muze bezne spoustet update na produkci a jinak tam hmatat...
-
sinisha (neregistrovaný)
Praveze len admin moze a o to je to vecsia zodpovednost. Ale ako sa vravi "Skusenosti robia profika", nabuduce si skontroluje zalohy, neda rm -rf, ale mv alebo spravi vsade maintenance snapshot pokial mu to system dovoli. A firma nastavi zalohovaciu politiku aj s pravidelnym testovanim zaloh.
-
Ondra Satai NekolaZlatý podporovatel
A proc muze? (mimo nejake extremni situace, kdy si opravdu diky jeji vyjimecnosti da pozor)
-
Praveze len admin moze a o to je to vecsia zodpovednost.
To je právě špatně, že může jen admin. Co s tím procesem má admin společného? Na to mají být vyhrazena práva a má to dělat člověk, co má přistup jen k tomu co potřebuje a třeba u toho nemůže smazat jiná data (o zálohách ani nemluvím - už proběhly i případy, že někdo smazal ostrá data a současně i zálohy).
Ano, v praxi se to bohužel řeší tak, že "udělá admin", protože má na kde co roota, ale tohle je velmi špatný stav.
-
j (neregistrovaný)
Takze budes mi extracloveka, kterej ma prava na databaze ... budes ho extra platit ... a on ve finale udela presne stejnou botu, protoze mu zavola sef, ze pristi mesic bude treba nasadit XYZ.
Dalsiho extracloveka budes mit na zalohovani - to aby nekdo omylem nesmazal zalohy ... a takhle muzes klidne zamestnat dalsich 100 lidi, rozparcelovat jim pekne opravneni, abys ve finale byl v jeste 10x vetsi riti, protoze naprosto nijak neporesis to, ze nekdo z nich se nekde uklepne, zato naprosto dokonale vyresis to, ze tam, kde to predtim ten jeden udelal za odpoledne, se na to nejdriv bude muset udelat projekt, pak o tom 1/2 roku schuzovat, rok planovat kdy ma vsech tech 100 lidi cas, ... aby se ve finale (v den D) zjistilo, ze je to vsechno krasny, ruzovoucky ... ale ze ti jaksi chybi clovek cislo 101, protoze sice mas lidi s pravama A-E a G-Z ... ale chybi ti F.
-
No nemusíš mít na všechno extra lidi, ale stačí extra role. Nevím, zda všechno děláš jako root, ale já teda omezuju práva i sobě a všechno dělám pod minimálním uživatelem. Když už to teda z nějakého záhadného důvodu mám dělat já.
budes ho extra platit
Tak potom je to jen o tom, co je pro firmu levnější. Jestli zálohy, nebo ztráta dat.
-
Ondra Satai NekolaZlatý podporovatel
@j
Nebo tam proste nebude hrabat nikdo. Ani extra clovek. Proste nikdo.
Vsechny (=az na HODNE velke vyjimky) zmeny jako soucast scriptu a jdou pekne pres review, deploy na testovaci prostredi, automaticke testovani a QA.
Nebudes to mit hned, ale budes to mit (s o dost vetsi prvdedpobnosti) dobre.
Proste zalezi na tom, zda je pro tebe dulezitejsi to mit rychle rozbite nebo pomalu udelane.
-
j (neregistrovaný)
Jo, bez vysvetlovat majiteli nejaky firmy, ze sice ma vsude blby ceny, protoze jedna z jeho ovecek neco pomrvila, a ze si tudiz muze vybrat, ze bud to bude ovecka mesic nebo dva ... nebo vic opravovat rucne, a nebo to ty budes nejdriv tejden ladit na testovacim systemu a pak to mozna pustis do ostry. Fakt bych chtel videt, co ti na to rekne ...
-
Ondra Satai NekolaZlatý podporovatel
Hele, pokud jsi v takovem stavu, ze musis kvuli opravam cen rucne hrabat do databaze a nejsi schopen nasadit zmenu za mene nez tyden, tak je asi neco spatne i jinak.
Ale jak pisu - zalezi na tom, co te boli vic. Pokud preferujes rychle ale blbe, tak samozrejme mas moznost takovou volbu uprednostnit.
-
Kolemjdoucí (neregistrovaný)
Četl jste vůbec co se jim stalo? Neplánovaně přestala fungovat synchronizace databází na produkci a admin to řešil, v tu chvíli rozhodně už není čas na žádné tanečky s testovacím prostředím kde se navíc tento problém nevyskytuje. Přesně pro takové situace admin musí mít přístup na produkční servery. Bohužel ale místo aby smazal tu rozbitou repliku tak smazal ten živý master, to se holt občas stane, pak nastupuje obnovení ze zálohy...
-
Ondra Satai NekolaZlatý podporovatel
Všimni si, že jsem psal o hodně velkých výjimkách.
To není ale výmluva pro jovy scénáře permanentního prasení, proti kterým jsem se ohrazoval.
-
Sten (neregistrovaný)
@Kolemjdoucí: Proto se v produkci při takových zásazích nedělá rm, ale mv (nebo snapshot před rm). rm se dělá až na odsunutá data poté, co se zjistí, že to bez toho funguje. Taky se může stát, že chyba se ukáže na druhé straně nebo že v těch smazaných datech jsou nějaké klíče, bez kterých bude potřeba všechno znovu nastavovat.
-
Sten (neregistrovaný)
@lazywriter Četl jsem to a dost jasně se tam píše: YP thinks that perhaps pg_basebackup is being super pedantic about there being an empty data directory, decides to remove the directory. Stejně tak /var/opt/gitlab/postgresql/data is wiped to ensure a clean replication, nikde nic o tom, že by tam docházelo místo.
-
To máte z toho že mícháte helpdesk a administraci. Když máte jednoho admina jako "holku-na-všechno", tak sice dělá všechno, ale nic pořádně. Účetní neúčtuje, mzdová účetní nemá opatchováno, další člověk nemá notebook, a k tomu (jak jste sám psal) občas fatálně selže administrace produktivního prostředí. Výsledkem je jeden přetížený "holka-na-všechno" admin a mizerná kvalita IT ve firmě.
BTW já pracuji ve Windows vzdáleně přes RDP, na produktivních systémech mám pro jistotu červený desktop, na neproduktivních zelený. Člověk sice to sice musí vědět i bez barviček, ale je každá další úroveň upozornění pomáhá předejít incidentu.
-
j (neregistrovaný)
Tovizejo lulane, uplne bezne ma kazda firma 150 adminu, a kazdej jeden ma svuj, hermeticky uzavrenej kancl, s opancerovanejma dverma ... to aby mu tam nikdo nelez a nikdo ho nevotravoval a aby nemusel poslouchat co resej ostatni.
Jo a kdyz chtej prijmout novyho zamestnance, tak si na to musej zalozit ticket, to aby tech 50 lidi ktery se na tom budou podilet vedelo, jestli uz je hotovy to, co je prerekvizitou jejich pravomoci. Tudiz k tomu, ze dotycnej dostane notes, dojde tak mozna za 3/4 roku, to nez nejdriv nekdo napise ticket it, pak nez admin ldapu zalozi ucet, dalsi nastavi prava na fs, jeste dalsi prideli opravneni do erpcka ...
Ale rad to tem sefum firem budu tlumocit jako oficileni stanovisko k administraci M$ ... ze je na to treba nejmin 30 lidi. Jen je zajimavy, ze vsude tvrdis, jak je to easy klikaci a vsechno se vlastne samo...
-
Všechno záleží na velikosti a IT potřebách firmy. Ale i malá firma s 0-1 adminem by měla mít někoho kdo se postará o složitější věci. Větší firmy mají běžně týmy na HW infrastrukturu, networking, system support, helpdesk, databases, security atd.
Když má firma jednoho admina "holku-pro-všechno", ten člověk musí dělat všechno od výměny tonerů v tiskárnách, přes deployment a správu stanic s Windows, administraci serverů na Windows a Unixu, administraci DB, helpdesk, aplikační podporu, administraci DB atd. IT je dnes veliký obor, takže ten jeden člověk pak většině z těch věcí nerozumí do hloubky (čehož jste vy živým důkazem). K tomu se mu - jak sám píšete - míchají aktivity typu správa DB a helpdesk. Z obou těch důvodů pak dochází - jak jste sám přiznal - k závažným incidentům při správě prostředí.
Nicméně přes všechny ty nevýhody má admin "holka-pro-všechno" i jednu výhodu: je pro firmu nepostradatelný. Samozřejmě je to výhoda jen pro něj, pro firmu je to dost zásadní problém. Protože když se admin rozhodne odjet na dovolenou, tak to aby firma vyhlásila celozávodní dovolenou :). A kdyby ho na té dovolené porazil autobus, tak se zaměstnanci snad ani nemusejí vracet :D. S dokumentací se totiž takový admin většinou neobtěžuje. Přebírání prostředí bez předávky ze strany stávajícího admina je dost problém v případě firmy běžící na Windows, a u Unixů je to ještě horší. -
Naopak je věcí profesionality, aby se člověku nic podobného nikdy nestalo. Je to jako když pilot vlastní chybou havaruje, nebo když chirurg vlastní chybou přeřízne pacientovi tepnu.
Komu se stal byť jeden podobný incident, tak by si měl zatraceně rozmyslet, jestli je vůbec schopný pracovat v produktivním IT prostředí. V McDonald's prý pořád hledají brigádníky :)
-
j (neregistrovaný)
Jo tovizejo lulane, on vubec zcela kazdej pilot nehavaruje ... tisickrat, mozna milionkrat ... proc myslis ty tatare ze chodej na simulatory. Dtto doktori ...co treba spachtle zapomenuta v pacientovi? Ne, to se nikdy nestalo ...
A to jak pilot tak ten doktor maji vlastni mistnost, kam jim nikdo neleze (dokonce nesmi lizt), nikdo jim nevola a nikdo je nevotravuje s kravinama.
-
Ondra Satai NekolaZlatý podporovatel
Promluv si s nejakym realnym doktorem, jak vypada takova realna sluzba...
-
Jak už někdo psal, piloti mají simulátory a firmy mají testovací (a nejlépe i QA) prostředí. U doktorů je ta "zapomenutá špachtle" obdobou incidentu při správě produktivního systému. Nikdy by se to nemělo stát, a pokud se to stane, dotyčný by se měl vážně zamyslet, jestli takovou práci může dělat (BTW může to skončit vyhazovem a/nebo trestním stíháním). I když u těch doktorů je to komplikovanější, protože se na zákroku podílí víc lidí, a může být trochu problém určit kdo za problém vlastně může.
-
Petr M (neregistrovaný)
Těch pět metod vidím takhle:
Jedna záloha na pásce je starší než měsíc.
Druhá záloha obsahuje jenom web, PHP a systém okolo, ne produkční data.
Třetí je v čmoudu a vedení ji omezilo kvůli rychlosti a kapacitě na 1x týdně bez kopie starších dat.
Čtvrtá je na disku, co havaroval nebo je šifrovaný a smazali si klíče.
Pátá byla RAID nebo zrcadlení a šlo to do /dev/null automaticky... -
Ondra Satai NekolaZlatý podporovatel
Nemusis to videt, staci kouknout: http://checkyourbackups.work/ ;)
-
Boo (neregistrovaný)
Live stream jak restoruji https://www.youtube.com/watch?v=nc0hPGerSd4
Za zminku stoji ze jako spravni profici pouzivaji poradnej unix - macOS.
