36 órás leállás után indult újra a termelés a Toyota japán gyáraiban

HUP cikkturkáló

14 gyáregység 28 gyártósora állt több-kevesebb ideig, ami - ha valaki ismeri az autógyárakat és képben van a 0 raktározás rendszerükkel - rettentően szerencsétlen helyzet ... A Toyota nem tudja pontosan mi történhetett, szerintük nem cybertámadás ... de még nyomozzák ...

Részletek itt.

( trey | 2023. 08. 30., sze – 08:53 )

Nekem ez nem úgy hangzik, mint amikor pánikban nagy hajlongások közepette futnak Bitcoin-ért, hogy a ransomware váltságdíjat ki tudják fizetni.

trey @ gépház

Whatever the cause of the glitch, it's another embarrassment for Toyota which in recent times has endured multiple data leaks. And who could forget that time it left they key to customer info on a public GitHub page for five years? Or the 20 years of faked emissions data?

 🤔

PS: biztos nem ment át az irónia

trey @ gépház

Volt szerencsem komoly root cause analizishez tavolkeletiekkel. Nem ket perc, es nem kicsit faj az erintetteknek.

A "leallt a gepsor, mert Toshikane San megnyomta a piros gombot" nem a vegso valasz. Lesz ott meg 15-20 melysegu "miert?" kerdessor (lepesenkent sok nyomozassal), ahol nagyon sokan megizzadnak.

Ez sok penz, sok konny, es lehet jopar fej is vegul. Valoban sokkal egyszerubb a melyhangut elohozni.

Ez a post-mortem jelentés.
Aminek a végén lehet hogy hullanak fejek a porba, de jobb helyeken nem az a célja.
A célja az, hogy rávilágítson a folyamatokban rejlő hibákra amik az incidenshez vezettek, és infot adjon azok kijavításához, hogy többet ne forduljon elő.

"A megoldásra kell koncentrálni nem a problémára."

"Többet ne forduljon elő"

Az összes helyen ahol megfordultam (és ahol most is vagyok) gyártják a lesszönz-lörnd ekszeleket tonnaszám, mer' az kell az ITIL v. ISO-tökömtudja komplájensz miatt. Aztán valami teljesen idejétmúlt változata, teljesen kiferdített nem is a részleteket mutató, egyenesen megvezető tartalonmal megy a serpojntra. Oszt ez is letudva, mindenki leszarja onnét. Mert senki nem akar tanulni. Mire előszedné valaki, már senki nem dolgozik a cégnél egy éve azok közül akik belehányták a munkájukat. Így aztán az elkövetők nem is vannak kényszerítve h. értelmesen használjál a lesszönz lörnd-öt. Az utánuk jövők meg kb. mindig 0-ról kezdik a tanulást, mert a tapasztalt project menedzsert mind kibaszták mert meg kéne fizetni, vagy önként lépett le ebből a kuplerajból, az utódja meg 0 kilométeres azon a területen. Így sosem marad aki a leckét megtanulta volna, és kamatoztatni tudná a következő hasonló szopó projecten.

Aztán rendszeresen vannak 2-3 havonta a fellángolós bazdmegek. Amikor 1 valaki hibája miatt szopik másik vétlen ártatlan 1000 ember hónapokig. Mert ilyenkor maximumra van tekerve az alkalmazottak indokolatlan baszogatása, vegzálása. Kollektívan nyakukba basznak ilyenkor a szociopata felsővezetők még több papírmunkát még több rivjú, még több cséndzskontrol processz. Persze az idióták fent nem látják át, h. az egész munkahelyi légkör az okozója a hibázásoknak: a felesleges papírtöltögetés azon az oldalon aki nem is tehet róla, hogy a végén egy másik részlegben a frusztrált szarokbele a melómba netwörkös elbasz egy BGP rule-t és fejreáll a teljes kibaszott hálózata az ügyfélnek. Mi ilyenkor a megoldás: a vétlen oldal (aki a biznisz egy teljesen másik végében ül), az szopjon még több rivjúval ami ugyanúgy nem deríti fel a másik oldalon elkövetett faszságokat.

Autógyártók sem különbbek! Egymással nem beszélő elszeparált emberek kupacai. Nem feltétlenül a legalsó szintű melósdroid hibája, h. a feje fölött hoznak döntéseket amik miatt olyan lesz a cégkultúra, amilyen. Pl a szekuriti. Szekurity-re cégszinten szarunk magasról, főleg ha 100 automotive programozóból jó ha 5-nek van fogalma az SSL, PKI, crypto mélyebb dolgairól, holott kb. itt áll vagy bukik a biztonság jelentős része.

Persze, fontos a szekuriti, amíg nem kényelmetlen az ott hozott változtatasok a gyártásnak. Mert a szent tehenet nem szabad érintenie a változtatasoknak.

A japánok amúgy is hülyék: agyatlan ázsiai módjára nem ésszel javítanak a hibákon, hanem tízszeres túlóra és erőforrás elégetésével csinálnak alig látványos előrelépéseket. Mert gobdolkozni azt nem tudnak.

Igen. Ez olyan, hogy egyszer mar hallottak rola, hogy szoktak ilyet csinalni, igy most ok is csinalnak. Csak pont a lenyeg veszik el. Illetve a lenyeg, hogy lehessem maszatolni, es papirt lobogtatni.

Egy rendes RCA nem ilyen. De azt egy atlagos kontraszelektalt manager (jobb, ha) nem hivja magara.

A japánok amúgy is hülyék

Nem tudom, hogy kiket fogtal ki, de nekem eddig pont nem ez a tapasztalatom sem a japan, sem a koreai kollegakkal. Dolgozni valoban sokat dolgoznak, de baromira atgondoltak eddig mindent mind mernoki, mint business oldalon. A bizalmukat nehez elnyerni (foleg, ha sokat pofazol, es nem hallgatsz), de ha bekerulsz a belso korukbe, akkor megosztjak veled is a gondolataikat.

"A japánok amúgy is hülyék: agyatlan ázsiai módjára nem ésszel javítanak a hibákon, hanem tízszeres túlóra és erőforrás elégetésével csinálnak alig látványos előrelépéseket. Mert gobdolkozni azt nem tudnak."

Biztos vannak olyanok is, de az atlagmagyarnal joval tobb japantapasztalattal nekem nem ez jut roluk az eszembe.

Sok igazság van abban, amit írsz.

Mindezek mellett láttam én is már jó, rossz és nagyon rossz gyakorlatot ezen a téren.
Tapasztalatom szerint minél régebbi egy multi, minél nagyobbra nőtt, annál jobban látja, hogy ITIL / ISO / TOGAF / XYZ dolgokban mennyi felesleges bürökratizmus van. Persze felülről valahogy "le kell nyomni", meg ügyfelek is elvárják. Csak a valóság sokszor a papírforma közelében sincs.

A nagy fluktuáció nem csak itt érezteti a hatását. Ezért is vallom, hogy baromság azt kijelenteni, hogy bárki lecserélhető bármikor másra. Igen, lecserélhető, csak milyen áron. De ez már menedzsment kérdés kellene, hogy legyen.

A japánok egy külön sztori. Más munkakultúra jellemzi őket. Én inkább "túlanalizáló-elemezgető-processz követő" típusnak látom őket.

>A japánok amúgy is hülyék: agyatlan ázsiai módjára nem ésszel javítanak a hibákon, hanem tízszeres túlóra és erőforrás elégetésével csinálnak alig látványos előrelépéseket. Mert gobdolkozni azt nem tudnak.

Ennek némileg ellentmond, hogy a Just In Time rendszert úgy implementálta a Toyota, hogy nagyjából az egyik legnagyobb gyártóvá nőtt úgy, hogy közben az autóik a megbízhatóság szinonímái lettek. Oké, most becsúszott egy baki, de az eddigi teljesítményük szép volt.

A just in time rendszer munkaszervezési metódus. A DSP-ben meg brute forsz-al körbegányolni valamit többnapos-hetes izzasztó munkával, amire jobb képességű programozónak van fél óra nyugodt gondolkodás után ugyanerre 1 gyors JAVÍTÁSA, ez meg műszaki problémamegoldás.

( p2pking | 2023. 08. 30., sze – 15:27 )

...a te hangod melyebb...

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

Nekem ez nem áll össze, hogy lehet IT infrát üzemeltetni monitoring nélkül? Ha volt monitoring, senki se olvasta el a leveleket, sms-eket? Senki sem nézi a dashboardot?

Ezt a magyarázatot legfeljebb a laikusok veszik be, szerintem más állt a háttérben, csak nem merik bevallani.

A storage miatt leálló összes szerver gyanúsan egy elbaszott thin provision lehet, azzal meg tényleg sec perc alatt be lehet mindent is dönteni....

Ha ezerrel zabálja fel a helyet az adatmásolás (vagy egy hirtelen nagy méretű allokáció), akkor pár perc alatt betelik. Ilyenkor a  riasztást kb. csak arra jó, hogy vegyen egy nagy levegőt az operátor mielőtt pause állapotba megy át a  teljes infra....

 

Szerk:

Ez mondjuk Darwin díj esélyes, de minimum epic fail:

"A vállalat szerint a szerverek ugyanazon a rendszeren futottak, mint a biztonsági mentésük, ezért nem tudták egyből megoldani a problémát."

Ezért nem használunk ilyen prod. környezetben thin provision-t. Amatőrök. Komolyan rá van szorulva egy Toyota? A thin provision-t nem egy autógyárnak találták ki, ahol évekre előre tervezhetők az adatigények.

Én utoljára akkor láttam ilyet, amikor a kezdő devops-os elfelejtette korlátozni az erőforrásokat és fejre állt a Docker környezete, amikor elfogyott a hely.

trey @ gépház

Azért ez nem trivi. Thin provisioning arra is jó, hogy az évekre előre betervezett kapacitást ne ma kelljen megvenni. A folyamatos fájlrendszer nővelgetés egyrészt szintén kockázatos művelet, másrészt több rétegben igényel üzemeltetőt. Ügyesen összerakott TP mellett meg csak "egy" storage üzemeltető nézi a trendet és rendeli a diszkeket, a többiek meg a tudatlanság nyugodt álmát alusszák. Én sem annyira szeretem élesben, de full megértem aki igen, brutál pénzek spórolhatók vele

Tudom mire jó a thin provisioning. Meg azt is, hogy miért kerüli, akinek esze van. Egyszer nézik be, a kötbéren többet buknak, mint amit ezzel a bohóckodással spórolnak. Ott van értelme, ahol a szolgáltatásra nincs kemény kötbér rakva, de ez nem az autóipar, arra mérget vehetsz. Számos autó- és gépjárműgyártási vállalatnál szolgáltatunk, óránként 10 000+ euró kötbérrel fenyegetett szolgáltatásnál nem cigánykodnak ilyesmikkel.

trey @ gépház

Pedig ez a thin módi tökéletesen illik a fizikai gyártás beszállítóinál alkalmazott just-in-time ellátási lánchoz. Addig spórolnak vele, amíg mindenütt hiba nélkül, időre megérkezik mindenn. De ha jön egy járvány vagy keresztbe áll egy hajó a Szuezi-csatornában vagy kitör a háború egy távoli országban... akkor máris megy a rinya, hogy nem tudnak gyártani. Biztosan sok manager kapott pár cent spórolásért szép bónuszokat korábban. Aztán csak ők látják, hogy több év alatt spóroltak-e annyit, amennyit buknak egy-egy ilyen időszakban.

Ehhez annyit, hogy akár a Vmware, akár a Microsoft leírta doksikban, hogy thin provisioning nem ajánlott production rendszerben.

Mondjuk ha valaki olyan "zseni", hogy Vmware szinten és storage szinten is bekapcsolja a thin provisioninget egyszerre, akkor adjuk neki az "IT arany málna" díjat.

Abban igazad van, hogy beruházást lehet elhalasztani TP alkalmazásával. Viszont lehet, hogy egy ilyen beszerzés nem fut le napok alatt vagy lemezeken kívül fiókok, plusz kábelek is kellhetnek, hanem csak hónapok alatt. Az meg óriási kockázat mindenkinek.

Egyrészt nekem még 2007-2008 magasságában Vmware oktatáson verték a fejembe. A thick disk kisebb IO overheadet és latencyt okoz az új blokk allokációjának szükségtelensége miatt. Ergo kisebb storage és host terhelést is.

Amiket most találtam hirtelen: https://www.bdrsuite.com/blog/vmware-virtual-disk-provisioning/
Idézet: "If a workload requires low latency, high-performance storage, thick eager zeroed virtual disks are the best option because both thin and thick lazy zeroed disks add latency to the I/O path. "

Továbbá: https://www.delltechnologies.com/asset/en-us/products/storage/industry-…
12. oldal: "The best practice is to use the default virtual disk format unless specific needs dictate the use of thick provisioned eager zeroed for performance or availability needs including Microsoft Cluster Service (MSCS) and VMware Fault Tolerance (FT)."

Hyper-V:
Link: https://learn.microsoft.com/en-us/windows-server/administration/perform…
Idézet: "Space for the VHD is first allocated when the VHD file is created. This type of VHD file is less likely to fragment, which reduces the I/O throughput when a single I/O is split into multiple I/Os. The fixed file type has the lowest CPU overhead of the three options because Reads and Writes don't need to look up the mapping of the block."

Screenshot Hyper-V Managerből:
link: https://infohub.delltechnologies.com/l/dell-powerstore-microsoft-hyper-… (2. kép)

Köszi a linkeket, de ezeken én nem azt olvasom, hogy nem ajánlott produktív környezetben, hanem azt, hogy nagyobb terheléssel jár a lemez alrendszerre vonatkozóan (nyilván). Természetesen van, amikor átfedés van a kettő között, de nem mindig, simán vannak esetek, amikor a megtakarítás előbbre való, mint a teljesítmény. Például emiatt is van az, hogy NFS-en a VMware thin VMDK-kat hoz létre, mert az a feltételezés, hogy NFS-en az NFS szerver jobban meg tudja oldani a zárolást/kölcsönös kizárást. (ettől függetlenül NFS-en sem szeretem a TP-t)

A Dell EMC szövegben ez van: "Thin provisioning ... This ability reduces upfront storage costs in many cases, and allows for a more manageable and predictable storage growth over time."

A teljesítmény szempont mellett nyilván nem mellékes, hogy a monitorozás megfelelő legyen, hiszen ha a tároló telik meg (és ahogy Zwei írja, ez akár nagyon gyorsan be tud következni bizonyos esetekben), akkor nem csak VM/rendszer érintett, hanem mindegyik, ami adott köteten fut.

Például ahol a pillanatkép ugyanoda dolgozik, mint ahol maga a kötet van, ott különösen oda kell figyelni, hiszen ha sok változás történik, akkor nagyon gyors tárhely fogyás tud bekövetkezni, mint például pillanatképes virtuális gép esetén.

Amikor ismert problemakat meg lehetne oldani azzal, hogy +2 dollarert jobb minosegu csavart hasznalnak az az auto arahoz kepest a vevonek nem ertheto dolog. Aztan amikor ez autonkent 30 dollar pluszt jelent es felszorzod mennyi autot gyartanak egybol elkezd fajni a segge a gyartonak. Sporolas sporolas sporolas...

Már csak emiatt sem gondolnám, hogy ez volt a baj.

Nyilvan nem. Viszont mondani kellett valamit. A "semmi kozod hozza"  (es tenyleg) miatt persze sok negativ kritika erne oket az okoskodok reszerol.

Az eves jelentesben majd kap fel mondatnyi helyet az IT infrastruktura. Vagy majd nem, ahogyan eddig se nagyon.

az a balfasz üzemeltető, amelyik egy thin prov. környezetben elfogyó helyből fakadó leállást 36 órás kieséssel tud csak abszolválni, az egy lamer fasz.

Ez így van.
Ha most felidézem miket rottyantottam meg pályafutásom során (szerencsére nem sokat, de azokat alaposan, és legendásak a cégnél :D ), akkor nem rémlik olyan, hogy bármely szolgáltatás állt volna sok-sok órán keresztül.

Amúgy a hosszú down time akkor is szokott előfordulni, ha a balfasz megpróbálja elsunnyogni mit csinált, és a jobbfasznak még azt is ki kell nyomoznia mi történhetett, hogy meg tudja szerelni.
De ez már nyilván csak alaptalan találgatás. :)

"A megoldásra kell koncentrálni nem a problémára."

Főleg azért, mert ahol ilyen baromsághoz ragaszkodnak (csakazértis'), ott az ember csinál egy jóra méretű spaceholder diszkfoglalást valamivel (pl. ISO telepítők felmásolva, egy semmire sem használt vdisk stb.), amit egy ilyen megszorult helyzetben egyszerűen letöröl és ott a szabad hely.

Problem solved. Ehhez kell kb. 1 perc, meg az érintett virtuális gépek újraindítása.

De, ha valaki rám hallgat, akkor éles környezetben hagyja a picsába a thin provisioning-et. Hacsak nem a GMail-t vagy hasonló kurván overbookolt rendszert üzemeltet és folyamatosan dolgozik 3 műszakban csillió embere, amelyik on-demand lapátolja befele a diszkeket, ha az szükséges.

De, ez nem a járműipar.

trey @ gépház

Nem biztos h. kell ISO-kat másolni terabájtos mennyiségben.

pl. 

fsutil file [createnew] <filename> <length>

ahol:

 

createnew Creates a file of the specified name and size, with content that consists of zeroes.
<length> Specifies the file's valid data length.

 

Kérdés h. van-e olyan okos a vmware thin provision h. az ilyen nullás fájlokat kioptimalizálva képes tárolni.

Ehhez nem kell terabájtos mennyiség, gigabájtok elegek szoktak lenni. Az ISO-k meg úgyis szoktak kelleni. 2-3 darab már 10-15 GB. Otthagyja az ember, aztán ha megszorul, törli. Ezt még a legkekecebb helyi IT "szakértőnek" is meg lehet indokolni. Szerencsére, nem igen találkozunk ilyenekkel, ahol mi szolgáltatunk, ott nincs thin provision. Játszós, tesztelős, fejlesztős, homokozós gépeken max.

trey @ gépház

hogy lehet IT infrát üzemeltetni monitoring nélkül?

Úgy, hogy valami olyan kétbalkezes üzemelteti, aki még csak nem is hallott ilyesmiről. És miért az üzemeltet? Mert vakok között félszemű a király alapon az egyébként nem IT-s cégnek fogalma sincs arról, hogy lehet a kétbalkezes üzemeltetőt megkülönböztetni a valóban kompetenstől.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

hogy lehet a kétbalkezes üzemeltetőt megkülönböztetni a valóban kompetenstől

Szerintem nem csak nem IT-s cégeknél létezik ez a probléma. Nem triviális elválasztani az ocsút a jó szakembertől. A képzés, papírok, tanfolyamok, sőt, még az előző munkahelyek se adnak teljes és valós képet. Esetleg a korábbi kollégák, vezetők adhatnak valami valós képet. De ott meg megjelenik a rosszindulat, irigység, sértettség.  Szerintem.

Toyota sem IT-s ceg es sajnos lattom mashol is, hogy olyan vezeti az IT reszleget aki elotte porszivot adott el. Sztem nem minden esetben a sor vegen az IT-s a hulye, mert hiaba mondja/mondana mi lenne a helyes, azonnal jo a porzivo ugynokbol atkeztett IT-s vezeto es megmondja mi a tutti.
 

Pedig van ám ilyen, láttam is személyesen, ahol az adott gyártó cég helyi IT részlege egész egyszerűen kifelejtette a monitoringból a gyártósorokhoz tartozó adatbázis szervert, ami az elfogyott storage miatt megállt.

Ezt onnan vették észre, hogy az összes gyártósor megbénult, természetesen vasárnap hajnalban...