Fórumok
Toyota Japan back on the road after probably-not-cyber attack halted production https://t.co/h5PNxor3YH
— The Register (@TheRegister) August 30, 2023
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.
Hozzászólások
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
Hát vannak akik a hiba okát, míg mások a mélyebb hangút keresik.
🤔
PS: biztos nem ment át az irónia
trey @ gépház
Van egy olyan erzesem, hogy itt nyal vissza, hogy meg mindig a faxmasinak korat elik. Akinek kellene, annak eszebe sem jut, hogy dikma, kene futtatni secret checket legalabb a publikus repokon, mert biztos ami tuti. Meg meg millio mas dolog sem.
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.
De, hát ott a TISAX :D :D :D
trey @ gépház
Értelek, ezért helyesbítek:
- a célja az
+ a célja az lenne egy tökéletes világban
Így már pontosabb? :)
"A megoldásra kell koncentrálni nem a problémára."
Egy tokeletes vilagban nem kell ilyet futtatni, mert minden organizacio es processz jo, es jol is alkalmazzak :)
Kodgepnek is lehet hasznalni. De ha veletlenul egyszer komolyan veszik, akkor kideritik, hogy eddig miert is nem volt eredmenye.
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.
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.
...a te hangod melyebb...
Every single person is a fool, insane, a failure, or a bad person to at least ten people.
🤔
trey @ gépház
A karbantartás során kitörölték a Lomtárat, erre elfogyott a hely.
trey @ gépház
Kutyaütők kezében van a popszakma :(
Ezért írtam, hogy ilyen hozzáállású gyártók akarnak Tesla szintű EV ökoszisztémát építeni, meg EV töltőt üzemeltetni...
Bár a Toyota magát az EVt sem érti látva a bz4x-et...
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.
BINGO!
trey @ gépház
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.
Akkor legalább workaroundolnák a dilettáns vezetői döntést ...
trey @ gépház
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.
Ez hol vagyon leírva?
Azért is kérdezem, mert például VMware esetén NFS-en TP az alapértelmezett a VMDK-k számára és kifejezetten oda kell figyelni, ha valaki nem azt szeretne.
Nem, mintha TP rajongó lennék (sőt), csak kíváncsi.
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
andWrites
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...
Végüli is lényegtelen, 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.
Már csak emiatt sem gondolnám, hogy ez volt a baj.
trey @ gépház
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.
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:
<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
Ú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.
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...
Mert nem a lomtarat kell torolni, hanem a fileokat.
Sokat segit, ha nem a kukat dobod ki, hanem a szemet.