Názory k článku Jak nám v Alze aktualizace Windows způsobila výkonové problémy databáze

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.

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.

Děkuji za takovýto článek že života. Rád si přečtu další.

No to samozrejme je, synteticky si muzes udělat set čeho chceš ale reálně třeba pro backend ti to tam bude chodit uplně jinak.

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.

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.

Díky za článek,
kouknu jak je to u nás.

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.

Tak je to prostě špatně. Nelze mít 2 na sobě nezávislé týmy, které spravuji jeden systém. To je prostě cesta k problémům, což alza už ví.

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.

A já myslel, že ten graf ukazuje zájem o jejich další super cool akci

Ignorujete, že to májí v HAčku. žádné translace by neměly být dotčeny.

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

o aktualizace se často stará úplně jiný tým než, který řeší dozor nebo vývoj.

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é.

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.

Myslite, ze MS SQL bude nad linuxem stabilnejsi? Rekl bych ze to bude "fungovat" uplne stejne (od v 2k17 je to mozne) jako windows bez GUI - aneb prochazka minovym polem bude mene adrenalinova zabava.

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?

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.

Stále stejná písnička? Jen dva databázové servery na celou ALZU, řek bych že to není špatná vizitka. Jak pro WIN tak pro SQL.

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.

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.

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.

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.

Zelenej skřet si za to řvaní produkty od M$ zaslouží.

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

včera se mi nechtělo hledat info o možnostech/ome­zeních sql serveru na linuxu, když na to koukám, tak to neni az tak zlé, povětšinou jde o věci vázané na windows os.

predchozi clanek o predchozim padu databaze ukazoval, ze nemaji prave ani premium support

coz se ale mozna uz zmenilo?

Resit problem na enterprise urovni "zlatym pravidlem restartu" je opravdu hodne smutny pribeh..

jakt o ale ctu, to issue cubec nebylo o OS a aktualizaci..

tady jde o procesni problem spravy prostredi

RedHat a Oracle nemaji aktualizace :D?

Vyznam rozdelit to rozhodne ma. Protoze licence za mssql neni levna, zvlast kdyz alza ma enterprise. Mit aplikacni server na stejnem hw znamena, ze platite draze vykon aplikace, protoze pocet jader na danem hw je o to vyssi :)

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?

To proste nemuze dobre dopadnout..

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ě.

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.

Takže aktualizujete jen tak bez testování a dokonce automaticky?

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.

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.

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.

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.

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.

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í testy

Bod 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.

Logstash i spark jsou prave soucast tech front, pres ktere tecou data do ruznych db a zvysuji propustnost diky agragacim nebo seskupovanim podobnych dotazu. (app->log->filebeat->logstash->elastic, app->kafka->spark->db apod)

"'Neměly", pořád to nhení 100%-tní jistota.

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?

Možná hloupá otázka, pro Alzu.
Co přejít na SQL server na linuxu?
Problémy s děravostí windows a neprůhlednými aktualizacemi pak budou pase.

Jsou profíci a profíci. Holt markleting je přednější.

To zase ano.

Mě prostě udívuje, že si Alza není schopná pohlídat celý systém od A do Z. Resp. když já dělám úpravy na systémech, tak si vždy píšu bokem co, jak, kde a kdy. Párkrát se mi to vyplatilo, když to začlo habrovat - to nemám budget v miliónech.

"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.

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.

> 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? :)

Což odpovídá (vzhledem k časovém uinterválu) spíše stylu "došla na něj řada" než "máme to odzkoušeno".

> 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í.