Üzemeltetés, másra mutogatás

10+ évnyi fejlesztés után úgy érzem, hogy kimondhatom:
Az üzemeltetésnél bevett gyakorlat, hogy elsőnek másra kell mutogatni ahelyett, hogy megkeresnék/elismernék a hibát.

Jobb esetben egy másik üzemeltetői csoportra mutogatnak, de rosszabb esetben a fejlesztőre, hogy biztos a script/program a szar. Igaz, a fejlesztett cucc 2 éve fut folyamatosan változtatások nélkül, de igen tuti elromlott. Nem cseréltem benne a kopó alkatrészeket :D

Linuxos rendszergazdai oldalon is jellemző, hogy mindig az a szar szerintük amihez ők nem nyúltak.
Még kezdő koromban volt poén amikor a rendszergazda egy hibabejelentés során minden válasz helyett az adott fejlesztőnek elküldte a php doksiját (az offline verziót). Az adott fejlesztő amúgy se volt egy nyugodt ember, de akkor aztán tombolt is rendesen.

Eszembe jutott az állatorvosunk (mármint aki a macskákat szokta oltani), megmondta, hogy az egyetemen elsőnek a nagyképűséget tanítják meg nekik.

Vajon az üzemeltetőknek is tanítanak ilyesmiket?

( gelei v | 2018. 08. 03., p – 11:07 )

> Az üzemeltetésnél bevett gyakorlat, hogy elsőnek másra kell mutogatni ahelyett

ftfy

Saját fejlesztésű rendszernél nem teheted meg, hogy azonnal másra mutogatsz. Ha hibázik, ki kell vizsgálni.
Nagyon könnyen kiderül, hogy munka helyett másra akarod hárítani a felelősséget, mert a végén úgyis kiderül, hogy a te cuccod volt a szar. Így nem éri meg próbálkozni.

Amikor zárt forrású cuccokból van összerakva egy hatalmas szerver parkod (pl MS cuccok), akkor úgy vettem észre, hogy sokszor fingjuk nincs arról, hogy mi miért történik. A legjobb, hogy rendszeres mostanában, hogy a winfosomon lévő alkalmazások hibáznak, erre max adnak az üzemeltetésről egy update-t. A hiba megy tovább. A végén meg azt mondják, hogy ez sajnos MS gond és nem ő írta a rendszert.

A gondom azzal van amikor a fejlesztésem találkozik az ő rendszereikkel és az én időmet rabolják azzal, hogy én kutatgassak a saját cuccaim között mert nekik nincs kedvük maguk körül söprögetni kicsit. És a végén még nekik áll feljebb amikor kiderül, hogy náluk van a gond.

kell egy healthcheck tool, ami vegignez minden szoba joheto dolgot. Nalam pl. a df, free, ps kimenetektol kezdve az osszes binaris, konfig file, dir, etc. jogosultsagok, crontab entry-k, stb. benne vannak. Ez kb. pre-flight check alapon sok hibat ki tud szurni...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

hahaha, csak annyit mondok: rosszulfogodvaze.
De pl, ha nem a fejlesztő felhős kiszolgálóján üzemeltetnek valamit, hanem a megrendelőnél, simán ráfogják, hogy szar a környezet, vacakol a hálózat, ésatöbbi.
Külön vicces, ha egy olyan rendszerre mondják, hogy rossz a hálózat, amit elvileg wifi-n keresztül PDA-knak is tudnia kellene használni, nem csak vezetékes eszközöknek (elvileg fel kellene készíteni átmeneti leszakadásokra valamint ugyanazon a hálózaton más meg hibátlanul megy).

( neutrino v | 2018. 08. 03., p – 11:07 )

Nem, magunktól fejlesztjük ki ezt a tudást, miután első körben mindig megkapjuk másoktól, hogy a rendszerünk a szar.
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház

( kroozo v | 2018. 08. 03., p – 11:08 )

> Eszembe jutott az állatorvosunk (mármint aki a macskákat szokta oltani), megmondta, hogy az egyetemen elsőnek a nagyképűséget tanítják meg nekik.

> Vajon az üzemeltetőknek is tanítanak ilyesmiket?

mivel hasonló helyeken oktatják őket, mint a fejlesztőket, ezért bizonyára :)

Nincs annál jobb érzés a világon, mint amikor egy egoista fejlesztő tákolmányában üzemeltetőként kiszúrom a hibát és belenyomom az orrát, hogy
"Nesze bazdmeg, itt a hiba a spagettikódban amit összeraktál. Javithatod.... Szivesen, hogy elvégeztem a munkádat"

-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház

Semmi szivesen, level vegere odairom hogy mennyi idot toltottem vele, X oraber, majd nyugodtan utaljak vagy nekem, vagy kliensnek ( sokat dolgozzom szabaduszokent ). Igy kovetkezo alkalommal megnezzik a sz@rukat eloszor, nem csak csipobol haritannak hogy valami a szerveren.
2 dolgot ruhelek nagyon :
- ilyen olyan CMS/CMR akarmi fejlesztoket akik amikor hiba van varjak hogy kuldjem az error logot, amit az applikacio inteligensen amugy osszeszed nekik egy fileban ( pl magento es az var/log/system.log , var/log/exception.log )
- Es akik kovetelik a logokat elmult napokra, de a legelso sor az index.php-ben hogy ini_set(display|akarmi_errors,off)

Nézd, én ültem mindkét (sőt, mindhárom, mert irányítottam is) oldalon, és az van, hogy az mindkét oldalra jellemző viselkedésforma, hogy (szerinte) ő mindent megtesz, a másik meg semmit sem, ő nagyon okos, a másik meg nagyon hülye.

Ennek fő oka a relativizálás (pont mint kocsivezetés közben): a saját szuboptimális dolgaid meg tudod magyarázni magadnak, hogy miért így van, a másikéból viszont csak azt látod, hogy szar. Ehhez hozzá jön még, hogy mivel a másik területét csak érintőlegesen érted, ezért azt gondolod, hogy ott minden probléma sokkal egyszerűbb, és nem igaz, hogy ennyit sem tudnak megcsinálni.

El kell keserítselek, mind a két banda egy híján 20.

( sj | 2018. 08. 03., p – 11:23 )

Vajon az üzemeltetőknek is tanítanak ilyesmiket?

nem, ez egy basic human skill: ha az ember eloszor magaban keresi a hibat, akkor a vegen meg meg is talalja. Oszt az meg nagyon kellemetlen. Meg az elozo munkahelyemen ugyanabban a csoportban is volt egy csavo, aki reflexbol ram mutogatott, aztan persze, hogy kiderult, o volt a futyi...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

( sevil | 2018. 08. 03., p – 12:11 )

Nekem, mint fejlesztőnek azt tanították meg az egyetem, hogy ne kérdezd, hogy ennek mi értelme. Csináld meg és kész.
Csak megerősíteni tudom, hogy egy tegnap még hibátlanul futó program ma már nem jól működik problémára az üzemeltetés első válasza: Forduljon a program fejlesztőjéhez.

Azért megvan ennek a másik oldala is.. Például kubernetes-novice channelen (https://kubernetes.slack.com) pont tegnap dobtak be egy hasonlót:

"One of the developers deploying apps on my kubernetes cluster decided he was too special to provision storage for his pods. He ended up doing a lot of reads/writes to disk which ends up using the docker container's storage. Well for us that happens to be the root volume (We use TwinBlade's for this cluster. Drive 1 is the root drive, drive 2 is a 2TB SSD thats part of a storage cluster). Super high I/O on the root drive ended up slowing the system down, slowing down Docker responding to Kubelet health checks causing Kubernetes to mark the node down. The issue cascaded though, because the trouble-maker pod in question would then get moved to another "Ready" node by the scheduler."
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Miért, ha limitálja, hogy 1-1 POD mennyi I/O-t forgalmazhat másodpercenként, és az miatt hasal össze a POD, attól még a dev mindent rendben csinált?

Related configuration parameters: 

--device-read-bps        Limit read rate (bytes per second) from a device
--device-read-iops       Limit read rate (IO per second) from a device
--device-write-bps       Limit write rate (bytes per second) to a device
--device-write-iops      Limit write rate (IO per second) to a device

____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Ott van a leírásban: "We use TwinBlade's for this cluster. Drive 1 is the root drive, drive 2 is a 2TB SSD thats part of a storage cluster"
Most azon lehet vitatkozni, hogy ez jó design e vagy sem, de az látszik, hogy volt lehetőség gyors és relatíve nagy tárhelyet (2 TiB) elérni, ha a fejlesztő vette volna a fáradtságot, hogy provision-öl magának ilyen storage space-t.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Teljesen jogos a kérdés.. Operational szempontból a fent említett I/O QoS szabályokat be kellett volna lőni és akkor (az elvárásnak megfelelően) a POD haldokolt volna csak. De ettől még szerintem a fejlesztő hibája ugyan olyan valid.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Kis follow up - Eredetileg úgy gondoltam, hogy ez a design is elfogadható, ha teszi azt amire ki van találva..
Viszont most utána olvasva az a megoldás se működne jól ahogy látom, mivel a cgroup v1 támogatott limitek csak O_DIRECT hívások esetén működnek.
Bővebben: https://andrestc.com/post/cgroups-io/
Majd talán cgroup v2-vel..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

man 2 open
BUGS
"The thing that has always disturbed me about O_DIRECT is that the whole interface is just stupid, and was probably designed by a deranged monkey on some serious mind-controlling substances." -- Linus

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

A "tegnap" hibátlanul működő még valóban nem elég indok, de az 1 éven keresztül jók működő, az azért már igen.
Főleg, hogy legutóbb ugyanezzel a programmal volt gond, és a fent említett üzemeltető akkor ködösen előadta, hogy hm, minden jól működik, felsőbb döntés miatt változott a policy, és nincs vele dolgotok. Nem mondta, hogy miről van szó, mi változott, igaz nem is érdekelt.

( trey | 2018. 08. 03., p – 12:12 )

Érdekes, az elmúlt 15-20 évre visszamenőleg ticketetekkel tudnám igazolni ennek a szöges ellenkezőjét. Mármint, hogy a fejlesztette szarban van inkább a hiba, nem a vasban/üzemeltetésben. :D

--
trey @ gépház

Félreértés ne essék, nem azt mondom, hogy nincs szar kód, szar fejlesztés és tonnányi bug, hanem azt, hogy gyakran tapasztalom, hogy az üzemeltetés egy hibát áthárítana máshova :)
És itt nem csak a fejlesztők a résztvevők.
Rendszeresen tapasztalom nálunk, hogy a belső üzemeltetés folyamatosan mutogat kifelé külsős üzemeltető cég felé és az pedig vissza.
Amikor nálunk fejlesztői oldalon van szar a palacsintában, akkor is előfordulhat a szarkavarás (x tudja, y írta stb), de házon belül maradunk és a másik hibáját is hajlandóak vagyunk kijavítani, mert a munka az munka.
Ezzel szemben üzemeltetői (főleg MS cuccokkal kapcsolatos oldalon) egymásra mutogatnak rendszeresen, megoldás nélkül. Tehát az üzemeltető üzemeltetőnek is a farkasa.

Megjegyzem, van olyan hibám amit évek óta nem képesek kijavítani. (pl VPN-en csatlakozás után egy belső szerver időnként nem érhető el)
Nem tudja egyik se, hogy mi lehet a gond, a linuxos gazda a windowsoshoz küld, a windows-os a linuxoshoz. (halál komolyan, mindkettő a másikat okolja).
Ugyebár a VPN MS, a szerver linuxos. (openvpn is van, de egyéb okokból nem tudom használni)

( p2pking | 2018. 08. 03., p – 13:13 )

Uzemeltetesnel azt tanitjak meg elsonek, hogy

"Mas munkaja neked a legolcsobb. avagy soha sem draga"

Ezert csak a legutolso esetben keressuk a hibat helyben, es a vicces, hogy 99.99% eseteben mukodik is az eljaras jol.

Fejlesztoknel fokent, mivel ugyis mindig hibas a kod. Sokszor untam meg, hogy debuggolgatom a vacakjukat es amikor visszakuldom, hogy mit szabtak el, meg megsertodnek es sikoltoznak a pm fele, aki meg jon az uv hoz, hogy mekkora bumburnyakok vannak itt. Btw igazuk is volt, egy ido utan, ha en kaptam a ticketet es megtudodott akkor mar onkent neztek csapatban, hogy mit faktak el, nehogy atsetaljak amikor meguntam mar pornot nezni.

Script/Program igen el tud szrodni, mert a fejlesztok fejlesztenek, ha nem te akkor a masik. Minden valtozik, az is ami meghalt.

( Huncraft v | 2018. 08. 03., p – 13:15 )

Nem új-keletű hiba ez amúgy..
A DevOps-nak pont az egyik alapköve az, hogy a Developereket meg az Operational team(ek)et eresszük össze, hogy lássák a másik oldalt is és tanuljanak egymástól, mert általánosan elmondható, hogy egyik se ismeri a másik, de néha még a saját területét se eléggé.

Példa:
- Operational team magyarázza el a programozónak, hogy az ő feltételezése miért nem állja meg a helyét esetenként
- Dev magyarázza el az Ops-osnak, hogy neki performancia szempontból igen is fontos az affinity, és qrvára örülne, ha az 1 szál adaptert amit használnia kell át tudnák rakni egy másik PCI slotba, hogy minden erőforrása ugyan abban a NUMA node-ban legyen)

Amúgy én már rég megtanultam, hogy a "tegnap/múlt {héten|hónapban|évben} még működött, azóta nem nyúltam hozzá, most meg már nem megy" sosem elfogadható indok egyik oldalról se, mert nem 1 olyan issue-t kellett már debugoljak ahol az adott hiba csak hosszú idő után jön elő (memory leak, cache feltelítődés, belsőleg használt int32 számláló, ami csak hosszú idő után léptetődik át -1-be), vagy több dolog közös együttállása során (CI-ban elég sok ilyen van). És akkor még a külsős hatásokról szó se esett..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Sehogy..
Csapatokat akkor tudsz összeereszteni ha azok felett van valami kontrollod is céges szinten (ha mondjuk adott csapatok adott cégen belül vannak).
A te általad felvázolt helyzetre a megoldás az, hogy adott céggel (MS) kötsz egy support contractot, és ha felmerül a gyanú, hogy esetleg ők baxtak el valamit, akkor a contract részeként eszkalálod az issue-t feléjük amire ők vagy adnak egy patchet, vagy elmagyarázzák, hogy a fejlesztő(d) mit kellett volna csináljon, hogy ez működjön is.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

memory leak a kedvencem nekem is, masik a "Mekkora heap kellene?" "Amekkorat csak tudsz adni!". Uj buildeknel mondjatok mar valamit a fejlesztesrol, hogy legalabb saccolni tudjunk mit kellene ala tenni. Nem mondanak, csinalunk valamit, majd reszelunk hogy jo legyen.

Szoval vannak bajok dev oldalon is am. Olyan ez mint egy rossz hazassag, csak nem lehet elvalni ;)
____________________
echo crash > /dev/kmem

Előző projecten külön volt választva a fejlesztői és üzemeltetői csapat. Az egyik kedvenc hibám az volt, amikor egy javaban írt webapp időnként hibát dobott mert elérte a process open file handle limitjét. Az üzemeltetés átdobta a labdát a fejlesztőknek, a fejlesztők a logokból pedig arra következtettek, hogy indokolatlanul alacsony a limit, ezért megemeltették azt az üzemeltetéssel. Persze ez nem oldotta meg a problémát, csak elodázta. A végén kiderült, hogy az egyik közvetett függőség volt a hibás, az leakelte a file handle-eket, amiket aztán a garbage collection során futó finalize felszabadított. Ezért ezzel lokálisan soha senki nem találkozott, stressz tesztek meg nem voltak (most nem részletezném hogy miért nem). Végül fejlesztőként összeraktunk egy linux vm-et, abban sikerült reprodukálni a hibát, a nyitott fájlok listázása után már nem volt nehéz megtalálni a hiba forrását. A történet tanulsága számomra az, hogy egyik csapat sem volt hibás, viszont sokat segített volna, ha a hiba nyomozásában segítséget kapunk egy üzemeltetőtől.

A történet tanulsága számomra az, hogy egyik csapat sem volt hibás

hat de: a fejlesztok. Egyszer en is beleszaladtam egy ilyesmi hibaba, hogy az egyik open()-hez nem volt close() (ehehe), de feltettem a kezem, hogy enyem a fault, majd fixaltam a bug-ot...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Így is a fejlesztők a hibásak, ők választották és emelték be függőségnek az adott libet.

Nagyon sok fejlesztő gondolkodás és válogatás nélkül emel be libeket, nem gondol arra, hogy:
1. ezzel beemel egy csomó lehetséges security hibát, kockázatot,
2. egy csomó program hibát,
3. függeni fog a lib fejlesztésétől, változásaitól,
4. függeni fog a lib függőségeitől és azok függőségeitől (minden mélységben).

Azért ennek megvan az oka. Minek találjuk fel a kereket újra? Az érveid rendben vannak, de ha mindig mindent külön implementálnánk akkor az elkészült szoftverek irgalmatlan redundanciát tartalmaznának értelmetlenül. Ráadásul minden egy kicsit másképp lenne szar... De nem is ez a fő oka. Mert ha van egy lib aminek a funkcionalitását lefejleszteni napokba vagy hetekbe telne, akkor azt ki fogja kifizetni? Amikor a projekt tegnap előtt legyen kész és sokszor még a saját cuccokat sem lehet rendesen tesztelni, akkor szerinted milyen erőforrásból lehetne fedezni egy lib pótlását?

ha mindig mindent külön implementálnánk akkor az elkészült szoftverek irgalmatlan redundanciát tartalmaznának értelmetlenül

Arra akartam felhívni a figyelmet, hogy nagyon sokan nem látják a lib-ek hátrányait, "gondolkodás és válogatás nélkül" emelik be ezeket.
Ez nem azt jelenti, hogy soha ne használjunk semmilyen libet!

ha van egy lib aminek a funkcionalitását lefejleszteni napokba vagy hetekbe telne, akkor azt ki fogja kifizetni?

Legtöbbször egy-egy libnek csak nagyon kis részét használjuk. Találkoztam olyannal, hogy a joda-time libet egyetlen funkciójáért emelték be. Ugyanezt a beépített, standard java.time-mal sem több vagy nehezebb megoldani.
Annak a kis résznek a beemelésével egy csomó terhet veszünk magunkra.
Nem az a kérdés, hogy az egész lib kifejlesztése mennyibe kerülne, hanem az, hogy az abból használt részek kifejlesztése mennyibe kerülne. A fenti példánál kb. 1 percbe került volna, kevesebb idő, mint a lib beemelése.

Azt is érdemes tisztázni, hogy prototípust készítünk, ami gyorsan kész kell legyen vagy egy olyan programot, amit sok-sok éven át kell karbantartani.

Még azt is érdemes szem előtt tartani, hogy a saját fejlesztéseket más projektekben is fel lehet később használni, nem kell mindent elölről kifejleszteni.

Lásd: https://hup.hu/node/160334?comments_per_page=9999#comment-2253679

A saját szarod meg tudod magyarázni, a másikét meg nem, mert azt ő tudja megmagyarázni. Ez egyértelműen a fejlesztés sara. Ki másé lenne, mint aki beemelte oda azt a kódrészletet. (Ráadásul még stressz teszt sem volt) Azt nem értem, hogy ez miért fáj? Such is life, emberek hibáznak, vagy egyszerűen csak egy tudatosan vállalt risk beüt, akkor leülünk, aztán megcsináljuk. Az én számat nem kevésszer hagyta már el a "Miért van ez?" kérdésre válaszul az, hogy "Mert elbasztam" és még élek. Ráadásul az első meghökkenés után általában kapsz egy jópontot attól, akinek mondod.

"Such is life, emberek hibáznak, vagy egyszerűen csak egy tudatosan vállalt risk beüt, akkor leülünk, aztán megcsináljuk."

Pontosan erről van szó.

"Ez egyértelműen a fejlesztés sara."

De ezt miért állítod be úgy, mintha valakinek a hibája lenne? Egy 3rd party lib bugja nálam a tudatosan vállalt risk kategória ugyanúgy, ahogy egy meghibásodó switch is az.

Én csak abban nem értek egyet, hogy minden hibához azt keressük, hogy ki okozta. Nem az lenne a fontosabb, hogy a hiba a lehető leghamarabb ki legyen javítva? Persze nem azt mondom, hogy post mortem ne vizsgáljuk meg, mit lehetett volna tenni a hiba elkerülése érdekében, amibe belefér felelős megnevezése is, ha arra szükség van. De az sokkal hatékonyabb szerintem, ha a hiba elhárításához összeadjuk a csapattagok tudását, tapasztalatát ahelyett, hogy rásóznánk az egészet egyetlen emberre, a többiek meg felraknák a kezüket, mert nem ők a hibásak.

A masik - amit mar parszor csinaltam, hogy elkuldod felfele a hasznalni kivant lib parametereit es elonyeit, es dontson az, aki feletted van/megrendelo.

pl. A kert funkcio a libbel 4 ora, anelkul 5 nap.. a lib BSD licences/fizetos (5cent/user)/LGPL(ennek minden elonyevel es hatranyaval), elegge szeles korben hasznalt (szoval valoszinuleg kevesebb bug van benne, mint amit 0-rol irsz), stb.. ezeket leirod, es a valasz fuggvenyeben implementalod. Ugyanugy, mint ha beszerzesnel megirnad, hogy vehetsz noname switchet x-ert, vagy Ciscot 10x aron, es melyiknek mi az elonye-hatranya.

--
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin

> Egy 3rd party lib bugja nálam a tudatosan vállalt risk kategória ugyanúgy, ahogy egy meghibásodó switch is az.

Hát, ennyiből a tudatos még nem derült ki, csak hogy vállalt. (Rádásul messziről is látszik, hogy itt nem csak a 3rd party lib volt felelős a kialakult helyzetért, hanem pl "stressz tesztek meg nem voltak (most nem részletezném hogy miért nem)".

> De ezt miért állítod be úgy, mintha valakinek a hibája lenne?

> Én csak abban nem értek egyet, hogy minden hibához azt keressük, hogy ki okozta. Nem az lenne a fontosabb, hogy a hiba a lehető leghamarabb ki legyen javítva

A felelős keresésének nem az a fő oka, hogy picsán lehessen rúgni, mint ez az első idézett mondatomból is látszik. Ezen a ponton két fő oka van annak, hogy ilyenkor megkeressük a felelőst.

Az egyik az, hogy problémákat ha lehet, a gyökerüknél oldunk meg. Általában nem az a végcél, hogy a hiba minél gyorsabban, hanem az hogy minél jobban javuljon meg, ehhez szükség van arra, hogy kiderüljön, az hol van. Mindenhol máshol ugyanis csak körbetaknyolni lehet. Természetesen van az, hogy "bocs, de ezt ott nem tudjuk javítani, vagy nagyon drága, uh csináljunk vele valahol máshol valamit", de ez legyen konszenzus, amit mindenki tud, ne pedig implicit csinálja meg az egyik fél, mert muszáj.

A másik hogy tapasztalataim szerint a másra mutogatás elkerülésében, és ehelyett a probléma megoldásában sokat segít, ha a probléma ügygazdája tudatában van annak, hogy ennek ő a gazdája, és neki kell valamit tenni. A megfelelő relativzálós szemüvegen keresztül ugyanis ezt a sztorit az üzemeltetés érezheti ám úgy, hogy "a balfasz fejlesztés kitolt valamit a kapun, azt nem tesztelte normálisan, aztán meg minket tornáztatott a prodban".

+1 ha tudatosan vállalt a risk, akkor annak ugye szokott lenni valami plan B-je, hiszen attól tudatos. A "látom hogy ebből baj lehet, uh összeszorítom a seggem, és összekulcsolom az ujjaim a hátam mögött" eléggé feszegetni a tudatosan vállalt risk definíciójának határait. Ha meg van ilyen B terv, akkor jó, ha tudjuk, hogy kinek a vállalt riskje ütött be ugy

> hogy rásóznánk az egészet egyetlen emberre, a többiek meg felraknák a kezüket, mert nem ők a hibásak.

Ilyet természetesen nem csinálunk, erre még csak utalást sem tettem, csak a szokásos félreértése visszhangzik belőle ennek az egész "ki a hibás" dolognak. Az viszont továbbra is igaz, hogy általában a hiba okozója van a legjobb helyen a hiba megoldásához, de legalábbis a teljes problématér feltárásához elengedhetetlen a részvétele, első körben érdemes lehet hagyni, hogy saját maga driveolja a megoldást.

( MrSealRD v | 2018. 08. 03., p – 15:12 )

Ez egy parttalan vita...Egyik kutya másik eb. Az sem mindegy melyik kutyaólban mazsolázunk mert van ahol az egyik a trehány banda van ahol a másik...

( csfeco | 2018. 08. 03., p – 17:41 )

Ennek a hozzáállásnak is meg van az alapja.
Réges-régen, terveztem egy 16 bites ISA kártyát, és én írtam hozzá a programot is. A HW kivitelezést nem én csináltam.
A hadweres kolléga "letesztelte" a kártyát, sőt ki is javította a 16 bitesre tervezett DMA-t 8 bitesre, mer ő azt ismerte.
Ezek után én megírtam a programot hozzá, és teszteltem, hol HW hol SW hiba volt, ha megtaláltam a hibát kijavítottam (és vissza csináltam a HW kolléga "javítását" is). Tettem a dolgomat, és nem pampogtam amiatt, hogy HW-s kolléga belemókolt, és a többi (prototípusnál előjövő) HW hibák miatt sem.
A kártya programostul elkészült, és mint kiderült, egy hajszál választott el attól hogy kirúgjanak, mivel a HW "tökéletesen volt kivitelezve", én meg tököltem/bénáztam a programmal. Ami nem volt igaz, de így jött le, mivel nem szidtam senkit.

Persze a szart másra tolókat ezzel nem védeni akarom, mert sokan ezt a viselkedést nem tanulják, hanem vele születnek, és a szakértelmüket (ill. annak hiányát) próbálják ezzel kompenzálni.

ne csodald, hogy ki akartak rugni, mert elszabtad nagyon a dolgot.

Eloszor is a termek atvetelenel le kellett volna ellenorizned, hogy a specifikaciodnak megfeleloen lett-e elkeszitve? Ha nem, akkor hibajegyet kellett volna nyitni a kollega fele, hogy ez sajnos garancialis lett.

Aztan vermerseklettol fuggoen egy lebaszas is siman elfert volna, hogy kerdes/elozetes egyeztetes nelkul modosit a terveden, mert hogy o ugyis jobban tudja. Lehet az is a konkluzio, hogy te javitod ki, de amint ez kiderult, ertesitened kellett volna a sajat fonokodet, akitol a melot kaptad, hogy mi a harci helyzet. A felreertesek elkerulese vegett ez egyaltalan nem pampogas, hanem a sajat segged vedesejol felfogott erdeked...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

+1

Hozzátenném, hogy környezettől függően sokszor azért is lecsesznek, ha megcsinálod mások munkáját.
Saját tapasztalat, hogy egy jó nagy projekt leadásának a határideje volt, mentek a tesztek, de a partner cég egyik - amúgy opensource - komponense rendszeresen ledöglött. Mikor már komolyan veszélyeztette a munkát és a határidőt, fogtam magam és jól megcsináltam a dolgot. Ugye ott voltak a fórumok, dokumentációk, kód, szóval minden adott volt a megoldás megtalálására.

A partner cég hálás volt, a megrendelőhöz közel álló kapcsolatunk is hálás volt. A saját amerikai-indiai/pakisztáni főnököm cseszett le, hogy átléptem a hatásköröm és hogy merészeltem. Képtelen volt projekt szinten gondolkodni és belátni hogy közös érdekünk hogy jó legyen.

A saját amerikai-indiai/pakisztáni főnököm cseszett le, hogy átléptem a hatásköröm és hogy merészeltem. Képtelen volt projekt szinten gondolkodni és belátni hogy közös érdekünk hogy jó legyen.

balfasz fonokod volt :-)

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

( _ventura_ v | 2018. 08. 04., szo – 08:36 )

Ahogy szoktam mondani, lassú gép nincsen, csak szar kód ;>

Fedora 27, Thinkpad x220