Názory k článku Jak nám v Alze aktualizace Windows způsobila výkonové problémy databáze
Článek je starý, nové názory již nelze přidávat.
-
fd (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Na testovacim prostredi prevazne nemate sanci vygenerovat takovy provoz nebo takove podminky aby se chyba projevila v nejakem pricetnem case. Specielne u win prostredi si tak maximalne muzete overit, ze to po aktualizaci nastartuje, a pak mozna par dnu pockat, zda se na internetu neobjevi popis nejakeho prusvihu.
-
fd (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Mozna a hypoteticky muzete postavit nejaky test na odhlaleni teto konkretni chyby, ale nikoli test ktery odhali libovolnou potencileni chybu. Nemate naprosto zadnou sanci. Pokud chcete generovat nejakou zatez, muzete v optimalnim pripade proste "prehrat" provoz realny, jenze, hodlate ho prehravati den? dva? tri? tyden? Pak se chyba projevi napropsto zarucene presne minutu po te, co test ukoncite.
Pricemz pomijim celou radu dalsich aspektu, kdo si tak muze dovolit mit exaktni kopii HW i SW konfigurace a pravidelne ji udrzovati synchronni s provoznim systeme. Prevazne se testuje na HW vyrazenem pri posledni obmene provozniho. A prave na nem se chyba nemusi projevit vubec.
Cimz se dostavame k penezum, a prostemu dusledku, ze sem tam nejaky ten vypadek je zkratka zcela akceptovatelny stav.
-
O (neregistrovaný) 87.233.197.---
Ty budeš nějaký akademik, ne? Ve chvíli, kdy se ti sype produkce, tak samozřejmě nutně potřebuješ, aby to co nejrychleji zase šlapalo, ne že se v tom budeš vrtat půl dne, abys pak vítězoslavně prohlásil, že to stačí otočit. Když příčina není z běžných ukazatelů a monitoringu zřejmá, je restart celkem rozumná volba - prakticky nic to nestojí a v mnoha případech to může pomoci. Zkoumat příčinu můžeš potom.
-
Zaujímalo by ma ako to budete do budúcna riešiť. Je to kumulatívna aktualizácia za 07/2018 a budúci mesiac to tam máte zase. Jedine žeby to MS opravil, samozrejme ak sa o tom dozvie.
My sme tak čakali na opravu na opravu jádra na 2012 R2 niekoľko mesiacov. Chyba spôsobovala na špecifickom hardware že jádro otváralo stále nové Threads až sa server za 25-26 hodín reštartoval. Trvalo mi niekoľko dní kým som chybu odhlalil.
Prekvapuje ma že aktualizácie netestujete na testovacom prostredí. Aspoň to tak z články vyplýva, ináč by ste nato museli prísť pred nasadeným do produkcie. -
Dnešní systém jsou tak rozsáhlé, že nějaká analýza na úrovní řádků strojového kódu je nemožná, to by šlo někdy v době Apolla 11. Pravděpodobně by to nezjistil ani autor toho patche. Takže, společně s alzisty, můžeme být rádi, pokud někdo z internetu ukáže na daný patch prstem a my ho můžeme zpacifikovat. Více takových článků
-
Karel (neregistrovaný) ---.cust.nbox.cz
Zažil jsem několik systémů a architektur. Včetně ERP kde aplikační server byl napsaný v PL/SQL. A nějak nerozumím tomu, jak tohle souvisí s "buď všechno jede a nebo všechno spadne"?
To je tak nějak totiž obvyklé - když spadne databáze, tak teoreticky aplikační server může simulovat, jako že něco dělá, ale když ta data neuloží tak je to asi zbytečné. No a když umře aplikační server tak je taky tak nějak obecně po všem a že databáze jede vesele dál nemá vliv ani na funkci rostlináře. Nebo vás napadá něco užitečného, co by se mohlo stát po "skladník naskenuje čárový kód" i v situaci, kdy neběží databáze nebo neběží aplikační server?
Podle mého názoru tudíž vůbec nezáleží na tom, že je business logika v tisících uložených procedur přímo v databázi. Tam má tak maximálně smysl bavit se o tom, zda je důvod, aby to byl systém jeden, nebo má smysl to rozdělit na více nezávislých systémů, které si boudou jen asynchronně povídat. Mít aplikační server oddělený od databáze výhoda není, protože věci fungují beztak jen pokud jede oboje. Když byť jeden z těch serverů spadne, tak stejně nejede nic.
-
fd (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Takze vy vubec nevite proc se testuje, ale vykladate tu o tom jak se ma testovat, vskutku zabavne.
Libovolne testovani se totiz dela prave proto, aby se odhalila predem neznama chyba, odhalovat chybu znamou je tak nejak pro kocku. Stejne jako je vam naprosto prokocku i to, ze budete replikovat provoz ostreho prostredi, protoze uz jen to, ze ten provoz je treba o den zpozdeny muze ovlivnit vysledky natolik, ze jsou knicemu. Treba proto, ze dotycna chyba se projevi jen ve specificke kombinaci akci a casu. Chcete priklad? To se takhle zakaznikova aplikace pokusila zapsat aktualni cas ... xx:xx:60. Muzete testovat klidne mesice. Na zadny problem nenarazite, protoze prestupnou sekundu musel vymyslet orpavdu Mozek.
A vite jak se zajistuje provoz kde je treba opravdu vysoka spolehlivost? Predevsim se nic (a to naprosto dusledne) nepatchuje. Nikdy. Pripadna bezpecnost se zajistuje jinak.
-
Koe (neregistrovaný) 89.24.62.---
No, v updatech windows je posledni dobou dost workaroundu na ruzne varianty zranitelnosti procesoru typu Spectre, ktere nekdy snizuji vykon pro urcite druhy workloadu.. hadal bych, ze vitr vane odtud.
Tak ci tak by se meli v alze poucit, a zlepsit testovaci prostredi natolik, aby tyhle problemy odhalili driv nez v produkci.
-
Jirka (neregistrovaný) ---.net.upcbroadband.cz
Ahoj Davide, díky za názor a sdílení zkušenosti. Nenech se znechutit některými názory a pokračuj dále (znáš Čechy, polovina z nich má pocit, že je děd Vševěd, druhá, že velitel světa :-) (Kulhánek)). Je zajímavé vidět s jakými problémy se v Alze potýkáte. Já budu teď řešit upgrage SQL Serverů, máme 2012, některé naše softwary ještě oficiálně nepodporují 2017, tak asi budu muset skončit u 2016. Jaké jsou Tvoji zkušenosti s upgrady? Jak často je děláte? Jirka
-
Tom (neregistrovaný) ---.nxiii.cc
stejně tak ti ukážu firmu s 3 linux admini, kteří se starají o 10 serverů nebo 2 kteří řeší u celého nadnárodního operátora Windows servery, o technologii to není. Neobhajuji Windows, dotaz byl co přináší navíc a proč se může vybírat, to přece není o tom co preferuji nebo že linux je špatný, tohle binární vidění je někdy hodně ulétlé.
-
David Hlaváček (neregistrovaný) 213.151.83.---
Co si pamatuji, tak největší problém byl přechod mezi historickou verzí SQL 2000 na SQL 2005. Tenkrát jsem to dělal pro celou řadu zákazníků a vzpomínám si, že jsem se u toho celkem zapotil. Přechod mezi novějšími vezemi, tedy 2012+ je obvykle zcela bez problémů. Jediné větší úskalí ohledně výkonu tkví v nastavení Compatibility levelu databází a Cardinality Estimatoru. Upgrade na novou verzi SQL Serveru děláme většinou půl roku po vydání verze, nejdříve samozřejmě testujeme postup, funkčnost a kompatibilitu na různých prostředích.
-
A nové problémy vzniknou. Přecházet v produkčním prostředí na kombinaci technologií co je to s námi rok, když tu máme stabilní MS SQL Server na Windows už někdy od roku 2000...
Ale prakticky, seznam unsupported funkcí SQL serveru na Linuxu je obrovský
https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-release-notes?view=sql-server-2017#UnsupportedA nehodí se to ani pro sekundární potřebu - Alza bude potřebovat analyzovat obrovské množství dat a na Linuxu není SSAS
-
Cek (neregistrovaný) ---.112.252.2.static.b2b.upcbusiness.cz
No, clanek OK, nicmene vyrazne tu chybi nejaka dalsi komunikace s podporou MS a analyza toho, co ten patch vlastne rozbil. Takhle je to tak max info o tom, ze je nutne vest dobre admin dokumentaci....a vic testovat.
Alza uz by asi mohla mit dostatecnej level supportu na to, aby se tim u MS nekdo zabyval, ne?
-
Tom (neregistrovaný) ---.nxiii.cc
S tím souhlasím, pro mě také je Windows svět takové sci-fi a nerozumím tomu, že tomu někdo rozumí :).
Replikace je někdy samozřejmě problém, musíme také počítat s tím, že se někdo uklepne a provede nevhodný update nebo drop, pak možnost se podívat konzistentně zpět v čase je vítaná a je to scénář, který klienti požadují.
Také u klientů občas potkávám kuriózní věci a někdy nevěřím, že to může fungovat.
-
Tom (neregistrovaný) ---.nxiii.cc
Testy v aplikace přece vždy píšu na známé chyby a chování, ne?
Kdo mluvil o denním zpoždění? Vždyť data na preprod mohou posílat rovnou, či zavést hot seat, nemusím jen snapshotovat provoz.
Nevím, nikdy jsem provoz vysoké dostupnosti asi neviděl :). Nepatchuje? Důsledně? Co je v tomhle kontextu patch? Vždy se musí aktualizovat, mohu používat rolling patching, mohu postupně nasazovat, mohu dělat big bang atd. Neexistuje nejlepší řešení, ale vždy kompromis.
-
stará doba velkých mašin pořád ještě neumřela, exadata, netezza, teradata atd. pořád existují a pořád prodávají nové a nové.
O ty nové kombinace se snaží kde kdo, ale je to dost práce, ty databáze jsou zatím lehce nespolehlivé a někdy dost tupé, hlavní problém je chybějící integrace na všechny ostatní systémy, zatím špatná vzdělanost devops, malá univerzálnost (potřebuji zkombinovat několik technologii), občas chybějící placený support atd.
Logstash a spark mi tam nesedí, není to db a ani storage :).
Vyškolit vlastní lidi trvá několik let, na našem trhu je třeba pořád více lidí pro Oracle než pro Elastic. Provozovat třeba OLTP (třeba sklad a objednávky u Alzy) je při desítkách instancí dost náročná technologie, zejména když potřebuji strong a ne eventually consistent, tam v praxi stejně končím na jednotkách instancí (klidně přes shardering).
-
Tom (neregistrovaný) ---.nxiii.cc
defakto nic co nelze s Linuxem/BSD, ale je s tím méně práce.
Z hlavy mě napadá:
- vzdálený management a centrální správa s distribuovaností a HA komponentami
- obecně storage - shadow copy, replikace, performance, možnost lépe kombinovat ssd/nvme/nas
- in-place upgrades řady komponent
- kompatibilita a integrace, stačí říct supported Windows Server a funguje to, linux je v tomhle hodně rozmělněnýK provozu nahrává poměrně stabilní sestavení a ověřená funkcionalita. Nové ale už Windows tolik nepotkávám a vítězí linux, tohle vše nejspíš pochází z minulosti. Jistou roli hraje i to, že mám k dispozici Windows admiistrátory.
-
Tom (neregistrovaný) ---.nxiii.cc
i v rámci jednoho týmu ale může nastat právě podobný informační šum, který povede ke stejnému problému, kolegové z mýmu v noci plánovaně provedli aktualizaci, o dva dny později řeším problémy, ale aktualizaci jako příčinu vynechám ač jí v logu mám k dispozici.
Naopak více nezávislých týmů může vést k lepší kontrole nebo vyšší flexibilitě. Některé týmy mám 24/7, jiné jen 8/5. Či bezpečnostní aktualizace řeší security oddělení a naopak zbytek updatů provoz řeší systemáci, opět záleží na struktuře firmy a její velikosti, nelze generalizovat, že dva týmy jsou vždy špatně.
Každopádně všichni musejí sdílet stejné informace.
-
Martin Kalenda (neregistrovaný) ---.klfree.cz
Je to o moznost to zautomatizovat, nebudu jmenovat ale jsou v CR firmy ktere zamestnavaji nekolik lidi pouze na cteni performance logu z windows :-) Jako samostatnej JOB. U nas bezi cca 1500 stejnych systemu (tj provozuje se tam jednotny sw s jinym obsahem) a neumim si predstavit to peklo jak to delat automatizovane.
U OSS me napada predevsim to ze muze byt mnohem sirsi pretesting prostredi klidne i dve stage, ale hlavne muzu tam trvale drzet v clusteru diky nenutnosti resit zalicencovani klidne na logicke urovni +2 rozpustene v infrastrukture. Muzu tam mit specializovany slave ktery bezi v start-stop backup rezimu tj sotva dozene replikaci odpoji se a udela dump.
Ono spolehat na zalohu treba 10+ TB databaze 12x denne z produkce muze casto dost spatne dopadnout. Takze zvysovani poctu nod je cesta. Je to samozreme o penezich pro nejakou firemni ucetnictvi nema smysl (krome penez) resit nejake brikule s sql serverem. Ale uz jsem videl pripad kde se do pokladen replikaci nad MS sype do cca 50 db (jsou to ridici servery pokladniho systemu pobocek retezce) a uplne stabilni reseni to neni. jeste aby to misto master-slave bezelo v master-master.
U opravdu narocnych aplikaci to pak vyjde najedno, dobrej win admin nebo sql admin stoji -+ stejne jako OSS, nicmene ta pasivit kdyz najdeme nejakej bud a nejde s tim nic delat (maximalne pustit to za app proxy na oss ktera hleda ten problematickej pattern a dane spojeni zahazuje pro frontend) je ubijejici. A u korporatu casto licence nejsou problem.
-
fdsf (neregistrovaný) 109.77.64.---
Operační systém ani databázi od Microsoftu na kritické věci nepoužívat
tolik veci na tom bezi, ze jakykoli komentar k tomu by defacto popiral realitu... ale musi se to umet - jako nakonec vse... zatim jsem tohle vzdy slysel od lidi, kterych jsem si profesne nevazil a zase naopak je vice lidi, kteri zvolili konkurenci a presto si jich vazim
-
tohle jsou zajímavé věci :). A Jak tímhle chceš nahradit MSSQL? Vždyť tím řešíš, problém, který třeba ani nemají a stejně potřebuješ nějakou db na skladovou evidenci a fungování eshopu, na čem bys to tedy postavil?
Už chápu tvoje shlukování dotazů, ty chceš sdružovat pouze inkrementy do časového okna a uložit najednou, to poté ano, ale on takový eshop není jen věc inkrementů, ale složitých filtrovacích dotazů na zboží. Krom toho, co když ti zrovna spadne spark proces, který drží v paměti data za poslední sekundy, jak to uděláš, abys data neztratil (a udržel konzistenci)?
MSSQL na to má in-memory oltp s možností přes procedury to přetahovat na disk-based stored tabulky v nějakém časovém okně, mimochodem, rychlostně se to nemůže rovnat s Redisem, provozem na silném stroji to je velice schopná věc (tím neříkám, že bych to nasazoval, ale jako utopii to nevidím).
Začal jsi tím, že chceš mít spousty slabých nodů místo jednotek silných, ale zrovna kafka a spark streams s windowed aggregation se staví na velice silných strojích, aby zvládli vysokou zátěž. Spark má velkou režii na každý executory, který je spuštěný, mít jich 50, bude to neskutečně pomalé a budeš bojovat s správným balancováním dat nebo naopak výrazně zatěžovat db desítkami spojení, Kafka naopak také nemá ráda velké množství strojů a staví se, aby saturovala síť/disk.
Kombinovat více technologií do sebe s sebou nese problém tracingu, debugování a monitoringu, cenu takového řešení to může výrazně zvýšit.
Jo, jdeš na to dobře, ale chybí ti reálné zkušenosti z projektů :)
-
Karel (neregistrovaný) ---.net.upcbroadband.cz
Cely problem Alzy jsou licence. Nelze skalovat do sirky, protoze roste pocet licenci, ktere nechce platit. Dnes uz se nestavi supervykona krava s jednou zakladni deskou, ale spousta malych, snadno nahraditelnych nodu, queue a replikaci s minimem raidu, ktere umozni prezit i vypadek velke casti fyzickych serveru bez ztraty dat a hlavni funkcnosti (napr. ruzne kombinace cassandra, kafka, glusterfs, elastic, logstash, galera, maria, spark). Jde tohle na MS?
-
TakyNeregistrovaný (neregistrovaný) ---.static.masterinter.net
Myšlenka je to sice dobrá, ale u Alzy jsem už chyby 404 na webu zažil několikrát. A to ani nemluvím o jiných nefunkčnostech, když jsem si dojel vyzvednout si na jejich pobočku mé objednané zboží. Naťukal jsem na jejich terminálu mé telefonní číslo, zaplatil jsem mojí platební kartou, na mobil mi došla SMS zpráva, a při snaze do Terminálu naťukat PIN z té SMS zprávy pro vyzvednutí zboží to pořád psalo, že PIN je špatný. Jiní zákazníci, kteří pravděpodobně platili kartou On-Line, měli také smůlu, protože na terminálech nainstalovaných v ALZE, byl namontovaný nesprávný a necertifikovaný papír, tak jim žádná papírová účtenka nevylezla. Správný papír má být certifikovaný společností vyvíjející ty Platební Terminály, a nemá mít váhu větší než 40mg. Takže jsme všichni museli čekat ve frontě, a prodavači museli obsloužit jednotlivé zákazníky. Asi to nebylo pro ně úplně příjemné, tím spíše, že zákazníků bylo na té pobočce celkem dost. Takže bych to nutně nesváděl jen na záplaty. Chyb se na webu Alzy a také na pobočkách objevuje vícero, a ne všechny mají co do činění s Operačním Systémem, resp. jeho záplatami.
Pozn. Zkušenost z pobočky Praha 5-Anděl, ale už mám i zkušenost z centrály v Holešovicích, kde jsem nakonec odešel na pult s pokladnami, kde jsem zaplatil svojí kartou ručně.
-
Tom (neregistrovaný) ---.nxiii.cc
ale no tak :). Je možné udělat slepý odklon části provozu a zjistit korelace. Preprod prostředí je běžné prostředí u systému s HA. Tady se jedná o web, není problém generovat zátěž na webu vč. objednávek, pravděpodobně takové testy i mají. Z článku není ani patrné, že by se chyba projevovala až při vysoké zátěži.
Každopádně chápu, že alza má určitou infrastrukturu a nemůže si dovolit dělat změnu každý rok a současný stav vychází z určitých omezení v historii.
-
Petr M (neregistrovaný) ---.145.broadband16.iol.cz
K tomu bodu 1 bych dodal, že starat se o black box na produkci je vždycky o hubu. Asi tak, jako když v nejmenované atomové elektrárně neřekli operátorům, že na konci regulačních tyčí je palivo a jak blbě se to díky tomu chová při nízkým výkonu... Spolu s pár dalšíma "drobnostma" z toho pak byl opravdu velký průšvih.
-
fd (neregistrovaný) 2a01:8d00:4000:----:----:----:----:----
Ehm ... muze to fungovat jako ty windows, ktere vas prihlasi do docasneho profilu (protoze ten vas se z neznameho duvodu nepodarilo nacist) a vsechny vase pripadne zmeny po odhlaseni .... proste smazou. Takovy ERP by jiste kupovali nadsene zakaznici po celem svete ;D.
Apropos, aplikacni sever a databaze se oddeluji jednak kvuli vykonu, a pak take kvuli tomu, ze aplikacni server muze komunikovat s nekolika servery databazovymi, stejne jako i tech aplikacnich serveru muzete mit nekolik. Ovsem v prostredi MS rozhodne zadnym zpusobem nic z toho neudelate bez toho, aby to prislusna aplikace na vsech urovnich umela. Jinak receno, vas system musi byt naprogramovan tak, ze neco takoveho umozni. V opacnem pripade si drive nebo pozdeji nabehnete na nejakou obzvlaste vypecenou chybu, ktera muze pachat skody i mesice, nez se projevi. MS cluster totiz neni transparentni, chova se jinak nez samostatny server.
-
Tom (neregistrovaný) ---.nxiii.cc
kdo mluvil o libovolné potenciální chybě? Psal jsi, že na testu nemáš jak vygenerovat takový provoz, na to ale existují strategie s pre-prod a duplikováním provozní zátěže, může být kontinuální a o tom jak dlouho to chci testovat rozhoduje pouze testovací strategie a míra rizik.
Dovolit si to může firma, které záleží na tom, aby chyby nebyl v produkci, spousta infrastrukturních prvků se takhle testuje, některé banky takhle fungují, dokonce i pojišťovny, je toho spousta.
Jasně, je to o penězích, ale netvrď, že není možné generovat na testovacím prostředí produkční provoz, je to možné a děje se to, ne všichni jsou takoví kaskadéři, aby si z produkce dělali testing. Existuje i u nás spousta čtyř, pěti devítkových služeb a ty to jinak dělat nemohou.
-
Martin Šoch (neregistrovaný) ---.net.upcbroadband.cz
U Alzy je hlavní problém v tom, že jejich produkt je monolit, který používá MS SQL jako hlavní komponentu.
Všechna business logika je v tisících uložených procedur a to až do úrovně: skladník naskenuje čárový kód -> spouští se procedura v MS SQL
Buď všechno jede anebo všechno spadne. Nic mezi.
-
madloki (neregistrovaný) ---.alfservis.cz
Vzdaleny management lepsi na windows ? To ma byt vtip ?
HA ? No tak tam se skutecne nema MS moc cim chlubit. Kdyz si vezmu jak jednoduse muzu totez rozbehnout na linuxu ...
Storage - co treba zfs, nebo drbd ? Jen skoda, ze Hans zapichl Ninu.
Upgrade komponent na MS ? Mne uplne staci MS aktualizace ovladacu. Marne si vzpominam, kdy bych kvuli aktualizaci na linuxu musel nekolikrat marne restartovat server, nebo mel problem vratit aktualizaci zpet v radech jednotek minut.
Kompatibilita - zazil jsem problemy pri prostem pokusu provozovat software MS na OS MS, a stacilo jen zmenit
jazykovou mutaci SW nebo OS, aby to byl "zazitek" na nekolik noci. Dekuji, jiz nikdy vice.Jedine, co lze na linuxu srovnavat s Windows, je systemd. A to bohuzel pro linux.
-
Honza (neregistrovaný) 94.230.146.---
Poučení z krizového vývoje:
1. Operační systém ani databázi od Microsoftu na kritické věci nepoužívat
2. Admini s programátory spolu musí lépe komunikovat
3. Testovat se má na prostředí co nejpodobnějším produkci a mají se tam provádět i výkonnostní testyBod jedna mi přijde naprosto zjevný. Snad bych to pochopil u nějakého miniprojektu, ze kterého se postupně vyvine velká firma. (I proto je dobré trochu přemýšlet už při návrhu miniprojektů, i když windowsovému klikači se to bude jevit jako overkill.) Bod dva je věčný problém ve spoustě firem. Tam, kde to nefunguje samo by to měl vynutit šéf. Bod tři je samozřejmě práce navíc a stojí to prachy. Na druhou stranu se tím opravdu předejde nepříjemným překvapením.
-
Karel (neregistrovaný) ---.cust.vodafone.cz
Staci cist sipky spravne. Nikde se o vystupu z db pres spark nic nepise. Spark je tam na ukladani a to seskupovani, agregace, zahazovani duplicitnich dotazu v casovem okne. Logstash zase treba zajisti davkove vkladani misto solo dotazu, nevykonavani duplicitnich dotazu. Vystup z db se naopak poresi shardovanim, cachovanim, kaskadou slave apod.
Proc by to ty technologie meli delat nativne, kdyz to podle vyznamu dat stejne musi mit nejakou vyssi logiku? Napr. sledovani aktivity uzivatele: nepotrebuji do db udelat 100x update, ze videl stejny produkt behem minuty. Staci jednou ulozit +100 a now() a to pres spark+kafku udelate snadno. MSSQL to vyresi jak? -
MS produkty sa dajú testova't úplne rovnako ako produkty iných firiem.
Všimnite si čo sa píše v článku "Monitorování nám ukázalo, že některé operace databázového systému trvají na produkčním hardwaru zhruba jednu sekundu, zatímco na mnoho let starém vývojovém serveru nula milisekund."
Stačí mať pripravenú sadu dotazov a otestovať to pred a po nasadení aktualizácie. A konkrétne u databáze vygenerovať veľkú záťaž nie je žiadny problém. -
hbsfdas (neregistrovaný) 89.39.107.---
"Snažili jsme se korelovat počátek výskytu problémů s dalšími událostmi. V pondělí nedošlo k žádnému významnému release aplikace, nenastaly žádné změny v architektuře."
Pokud vám windows nainstaluje aktualizaci pod nosem, vy to neberete jako významný release aplikace a musíte dělat xx prověrek, kde je chyba, tak ta chyba nebude v aktualizaci, ale v neschopnosti hlídat jakkéékoliv změny v aplikaci.
-
hbsfdas (neregistrovaný) 46.166.142.---
Restart na produkci, kde jsou každou chvili nové objednávky, je fakt nesmysl.
Co by si dělal, kdyby daná aktualizace způsobila nenaběhnutí nějakého prvku a celé by to nenaběhlo. Řekl bys ups a rozesílal CV, ne?
Tyhle věci mají být podchycené tak, že když ti něco začne haprovat, máš vzít papíry se záznamy o změnách a vracet vše postupně zpět do doby, kdy to nehabrovalo.
Což v alze evidentně nemají v procesu, protože by nekontrolovali xx věci. -
Ravise (neregistrovaný) ---.102.wms.cz
> Pro příklad uvádím dva obrázky grafů níže, ze kterých jsem z bezpečnostních důvodů odstranil legendu.
A taky popis osy ypsilon. Vážně - k čemu je pak takový graf? To tam už rovnou může být obrázek spoře oděné ženy. Informační hodnota stejná a věřím, že by přitáhl víc prokliků.
> zlaté IT pravidlo restartu počítače
Myslel jsem si, že restartem můžu řešit problémy u sebe doma, ale že firma velikosti alzy bude chtít vědět proč a prosté "už to přešlo" stačit nebude... Podělíte se o čas restartu? :)
-
Ravise (neregistrovaný) ---.102.wms.cz
> Ty budeš nějaký akademik, ne?
Správně, jen mě onálepkuj! Na zádi mám ještě trochu místa, určitě se vejdeš.
> prakticky nic to nestojí
No, on taky restart může trvat pět minut nebo hodinu. Proto jsem se ptal, jestli se autor článku nepodělí, jak rychle jim stroje restartují.
-
- Senior PHP Developer
- VMWARE System Engineer, part-time
- Senior Cloud Native Designer
- PHP programátor enterprise e-shopů
- FrontEnďák - práce z domu!
- Manažer přípravy zakázek Smart Home systémů LOXONE
-
- Seznamy na SharePointu 2: vychytávky pro práci s položkami a seznamem
- Jak hacknout rozhodování - intuice vs. algoritmy
- Plánování projektu II: rizika a komunikace
- Mediální gramotnost a fact-checking
- Leadership III: Jak nastartovat vítěznou strategii?
- Jak na český pravopis
-
- Senior PHP Developer
- Sales Manager IT Security
- VMWARE System Engineer, part-time
- FrontEnďák - práce z domu!
- Manažer přípravy zakázek Smart Home systémů LOXONE
- Front-end developer s vášní pro high-end code
-
- Seznamy na SharePointu 2: vychytávky pro práci s položkami a seznamem
- Jak hacknout rozhodování - intuice vs. algoritmy
- Prezentační dovednosti a veřejný projev
- Plánování projektu II: rizika a komunikace
- Mediální gramotnost a fact-checking
- No More Czenglish I
