Sziasztok!
Segítsetek kérlek, nem jövök rá mit rontok el. Az összeállítás:
Központi switch: ZyXel XGS1930-28
LAG2: 27/28 port - LACP - a másik oldalon egy Linux szerver, sima bond
LAG3: 23/24 port - LACP - a másik oldalon az régi iroda Netgear GS724Tv4 switch port 25/26
Mindkét LAG esetén: src-dst-mac a hash type
LACP system priority: 32768
Régi iroda switch: Netgear GS724Tv4
LAG1 - 25/26 port - LACP - Admin mode: Enable; STP Mode: Enable; Link Trap: Enable; LACP Priority: 128; Timeout: Long
LAG2 - 23/24 port - LACP - Admin mode: Enable; STP Mode: Enable; Link Trap: Enable; LACP priority: 32768; Timeout: Short
LACP System Priority: 32768
A LAG1 megy a központi ZyXel switch-be, a LAG2 a következő, FS eszközbe a 9/10 portba
Harmadik switch: FS IES3110-8TF-R
Port 7/8: LACP Enabled; Key: 102; Role: Active; Timeout: Fast; Prio: 32768
Port 9/10: LACP Enabled; Key: auto; Role: Active; Timeout: Fast; Prio: 32768
Nos. Amíg a ZyXel és a Netgear vannak ketten addig minden oké. Gyönyörűen összebeszélnek, felépül a link, hibátlan a működés. Abban a pillanatban hogy rákötöm a harmadik switch-et, a központi ZyXel switch loop protect-je letiltja a Netgear felé menő portokat. Mit nem veszek észre, hol a hiba?
Az Ai-t megkérdeztem, adott tippeket (STP, prioritások, stb), de szeretném érteni amit csinálok, nem vakon állítgatni.
Nagyon köszi!
- 1036 megtekintés
Hozzászólások
Mi az eredeti cél? Tudsz egy skiccet/rajzot betenni? Vizuálsan hamarabb kijöhet a hiba.
FS-ben hova megy a másik LACP?
Ha a Zyxel tilt, akkor jó eséllyel csináltál egy hurkot azt pedig az ethernet szabvány nem igazán szereti. A csillag topológia lenne a megfelelő.
Ha lesz rá lehetőség a jövőben, akkor cseréld az összes switchet aznos márkájúra, mert egyszerűbb az üzemeltetés.
- A hozzászóláshoz be kell jelentkezni
A központi ZyXel 23/24 portból elindul két CAT6 kábel egy másik emeletre. Itt fogadja a Netgear a 25/26 portokon. Eddig rendben van, összeállnak, működik. Innen kell tovább vinni a hálózatot, ipari környezetbe, ahova a költséghatékonyság miatt FS termék került. A Netgear 23/24 portjából elindul szintén kettő CAT6 egy másik épületbe, ahol az FS fogadja a 9/10 portokon. (Azt most nem keverem ide hogy innen tovább fog menni még a 7/8 portokból egy másik ugyanilyen FS felé, egyelőre eddig legyen jó). Nincs lehetőség a kábelezés módosítására, így kaptuk, oldd meg jeligére...
- A hozzászóláshoz be kell jelentkezni
Az mindegy, hogy fizikailag hogy megy tovább. Rajzold fel a topológiát, felejtsd el az ipari környezetet, mindent, úgy rajzold fel, mintha a 3 switch egymás mellett lenne és a kábelek öt centisek lennének.
- A hozzászóláshoz be kell jelentkezni
Köszi, közben megoldódott, jelenleg is stabil. Hiányzott pár (R)STP beállítás és egy kábelt rosszul feliratoztak a kollégáim...
- A hozzászóláshoz be kell jelentkezni
Király. Viszont, tapasztalatból mondom, tessék holnap felskiccelni egy Paintbe, és elmenteni valahova. Két év múlva, amikor majd megint hozzá kell nyúlni, a rák se fog emlékezni rá, hogy most akkor mi hova megy.
- A hozzászóláshoz be kell jelentkezni
"Minden fel lett jegyezve." :D Betesszük egy alkalmas szoftverbe is a teljes hálózatot, dokumentálunk!
- A hozzászóláshoz be kell jelentkezni
Az LACP key auto nem hozhat rá bajt?
- A hozzászóláshoz be kell jelentkezni
Próbáltam fixen 1-es értékkel, ugyanez volt a hiba. Tegyem 3-asra, mint "group ID" a másik oldalon? Az FS GUI-n egyáltalán nincs group ID beállítási lehetőség, ezt már kerestem. (Ez szempont lesz amikor majd fűzöm tovább a következőbe, ha eljutok addig.)
- A hozzászóláshoz be kell jelentkezni
Szerintem lehet más az LACP key a link két oldalán, annak csak lokálisan van jelentősége. Mielőtt szétkonfigurálnád, azért adódik a kérdés hogy LACP nélkül, vagy akár LACP-vel, de csak egy kábellel összedugva nem vágja le a loop guard? :)
- A hozzászóláshoz be kell jelentkezni
Egy kábellel minden oké, most is így fut ideiglenesen (a nyitó hozzászólásban leírt beállításokkal, LACP-vel).
- A hozzászóláshoz be kell jelentkezni
Ezt mondja a Gemini, van benne igazság? Ész nélkül nem állok neki állítgatni semmit:
- A hozzászóláshoz be kell jelentkezni
Nézz meg minden LACP-t, hogy rendben felépül-e két linken. A system-priority-nak értelmezésem szerint itt semmi jelentősége, mert az LACP-nek egy switchen van mindkét portja.
Nézd meg az STP topológiát, ki a root, melyik switch melyik porton látja a root-ot. Azt is ellenőrizd, hogy minden switchen ugyanaz az STP protokoll legyen használatban, az alapértelmezettben lehetnek eltérések. Ettől függetlenül egy láncban nem kellene, hogy hurok legyen, de ha látod az STP topológiát, akkor talán meglesz a hiba oka is.
Illetve a napló is célszerű lenne megnézni, hátha kiderül a blokkolás oka.
Linuxon mit jelent a "sima bond"?
- A hozzászóláshoz be kell jelentkezni
Oké, az STP a gyanús nekem is, ezzel folytatom ma.
A "sima Linux bond" alatt ezt a felállást értem:
auto ens1f0
iface ens1f0 inet manualauto ens1f1
iface ens1f1 inet manualauto bond0
iface bond0 inet manual
bond-slaves ens1f0 ens1f1
bond-miimon 100
bond-mode 802.3ad
bond-xmit-hash-policy layer2+3
- A hozzászóláshoz be kell jelentkezni
Úgyis nézd meg az STP topológiát mindhárom switchen, amikor a Zyxel letiltja a Netgeart, illetve párosával is nézd meg: Zyxel + Netgear (Netgear-FS nem csatlakozik), Netgear + FS (Zyxel-Netgear nem csatlakozik).
Illetve azt is próbáld ki, hogy Zyxel-Netgear 2 link, Netgear-FS 1 link, valamint fordítva: Zyxel-Netgear 1 link, Netgear-FS 2 link.
Mindig ellenőrizd az LACP linkeket is. Az eredményeket írd le (STP root port, STP priority).
Azt is nézd meg, hogy port szinten milyen STP beállítások vannak, nincs-e letiltva/kikapcsolva valamely porton az STP, beleértve az LACP portokat (az ilyen LAG-ok kezelése switchenként eltérő lehet, van, ahol LAG szinten kell kezelni egyes beállításokat, van, ahol port szinten).
Normál STP helyett próbáld meg az RSTP-t is.
Elég furcsa helyzet a leírás alapján, némely tesztnek nem látom értelmét, de mikor sötétben tapogatózik az ember, jobb minden sarkot megnézni, hátha úgy kiderül valami.
- A hozzászóláshoz be kell jelentkezni
Úgy néz ki az RSTP / FastLink / Edge beállításoknál lesz a kutyus elásva, ez ugye mindháromban máshol van, "öröm kibogozni". Nem kiabálom el, most összeállt, megy a tesztelés, össze-vissza kihúzogatás, újraindítás, valós élethelyzetek tesztelése.
- A hozzászóláshoz be kell jelentkezni
Amíg nem működik rendesen, addig semmi ne legyen Edge/Fast.
- A hozzászóláshoz be kell jelentkezni
Én megnézném az eszközök doksijait: milyen LACP módokat, STP üzemmódokat támogatnak. Továbbá ez lehet akár fw hiba is valamelyik eszközben.
- A hozzászóláshoz be kell jelentkezni
A firmware hibára gondoltam én is, lefrissítettem mindent a legújabbra tegnap este, ma megyek a helyszínre, kipróbálom.
- A hozzászóláshoz be kell jelentkezni
Nos, eddig jutottam, bízom benne hogy másnak is segítség lesz a jövőben. Ezekkel a beállításokkal működik:
ZyXel (a "root" switch):
- LACP hashing: src-dst-mac
- LACP Timeout: 30s
- RSTP bridge priority: 4096
- RSTP hello time: 2s
- RSTP max age: 20s
- RSTP forwarding delay: 15s
- Érintett portok prioritása: 128
- Érintett portok Edge mód: kikapcsolva
Netgear switch:
- LAG type: LACP
- Admin mode: Enable
- STP mode: Enable
- Érintett portok LACP priority: 128
- Érintett portok LACI timeout: Long
- STP: Enable
- STP type: RSTP
- Bridge priority: 32768
- Bridge Max Age (secs): 20
- Bridge Hello Time (secs): 2
- Bridge Forward Delay (secs): 15
- Spanning Tree Maximum Hops: 20
- LACP portok STP Status: Enable
- LACP portok Fast Link: Enable
- LACP portok BPDU forwarding: Enable
- LACP portok Auto Edge: Enable
FS switch a Netgear felé:
- LACP key: auto
- LACP role: auto
- LACP timeout: fast
- LACP port prio: 32768
- RSTP priority: 32768
- Az összes többi paraméter ugyanaz mint a Netgear-nél
- CIST Aggregated Port Configuration: Admin Edge: Non-Edge
- CIST Aggregated Port Configuration: Auto Edge: Disable
- Az érintett portokon STP Enabled, Priority 128, Admin Edge: Non-Edge, Auto Edge: Disable
A két FS között csak az LACP key-t állítottam be, auto helyett a két oldalon megegyezőre.
Köszönöm mindenkinek aki segített, próbált segíteni!
- A hozzászóláshoz be kell jelentkezni
12 racknyi S5850-el nem volt gondom
- A hozzászóláshoz be kell jelentkezni
Azért az egy kicsit más liga. :)) Félretéve a viccet: esetemben, mint ma kiderült a kollégák is közrejátszottak ebben a sztoriban. Az egyik kábelt rosszul feliratozták, így nem jó portba került csatlakoztatásra. Emiatt volt a loop... Hofit idézem: "a nyomott agyammal nem értem", hogy ha elírod a kábelen a feliratot, majd arrébb mellé írod a jót, akkor mi a lókukiért nem húzod át vagy törlöd le a rosszat róla... Nem volt rendes kábel jelölés, én kis "naiv" azt gondoltam 4-5 kábelre elég ha felírják filccel. Na ja, vagy nem... Attól függetlenül hogy az RSTP most lett "rendesen" beállítva, lehet működött volna, ha nem tesznek bele nekem egy nem aggregált portot is a LAG-ba... Már kibosszankodtam magam miatta...
- A hozzászóláshoz be kell jelentkezni
ment volna rendesen, ha nincs ott a loop. a loop protect meg tette a dolgát.
- A hozzászóláshoz be kell jelentkezni
Igen, én is így gondolom. Ebben a projektben nem az első hogy más malackodása miatt én szívok. Kezd betelni a pohár azzal hogy már mindenki "informatikus" meg "rendszergazda", közben meg alap dolgok elvégzésébe is sokszor hiba kerül. Mostanában sorozatosan ez van a környezetemben, többek által hátrahagyott trágyát kell nekem ellapátolnom. És még békítsem meg az ügyfeleket is. Nem könnyű, szó se' róla.
- A hozzászóláshoz be kell jelentkezni
Az IT munka a 21. század trágyalapátolása.
- A hozzászóláshoz be kell jelentkezni
Ez esetben a kérdés az, hogy aki ezt félrecímkézte, vajon ott van-e még a csapatban. Egyáltalán lehet tudni, hogy ki csinálta? Mindegyik esetben érdemes összeülni (virtuálisan vagy fizikailag), és kielemezni, hogy mi történt, mindez mit okozott, mennyi időveszteség volt megtalálni a problémát, esetleg még azt kitalálni - ha lehetséges -, hogy hasonló esetet hogyan lehet megelőzni. Nem büntetési, hanem tanulási céllal (lessons learned).
- A hozzászóláshoz be kell jelentkezni
Hát, lehet, de ezeknek a hasznos vége kb annyi, hogy "mindenki figyeljen oda, senki ne bassza el a kábelezést, mert orbitális szopás lesz".
A haszontalanból természetesen kijöhet egy köbkilóméter meddő beszélgetés arról, hogy a felnyomkódós számos, vagy a táblicskus bilincses a jó kábeljelölő-e, és hogy mit kell ráírni arra a jelölőre, esetleg arról, hogy a dokumentáció nagyon fontos, és azt mindig meg kell csinálni, természetesen beleírjuk a processz checklistbe is (közben még egy kör meddő vita arról, hogy külön nyilvántartás van-e, vagy a switchport descriptionba kell-e írni, illetve hogy kurva sok pénzért fejlesszünk szinkront a kettő közé). Ezek valamennyit talán segítenek, egy darabig tényleg kevesebb faszkodás lesz talán, de in reality úgyis lesz olyan, ami kimarad onnan, vagy elbaszódik, szóval elég meddő cselekvés valójában.
- A hozzászóláshoz be kell jelentkezni
Ok , de stp -nek nem pont az a lényege, hogy bekapcsolom, elbaltázzom a kábelezést , de megvéd, minden külön állitgatás nélkül ?
- A hozzászóláshoz be kell jelentkezni
Kb de. Meg is védte, nem ment az egész L2 a levesbe, "csak" szétszakadt a domain.
Azon, hogy nem oda van dugva a kábel, ahova gondolom, hogy dugva van, ezért konfigurálok lelkesen, azon nem segít semmi xTP.
- A hozzászóláshoz be kell jelentkezni
"mindenki figyeljen oda, senki ne bassza el a kábelezést, mert orbitális szopás lesz".
Akkor ott nem jól csinálják ezt. Sem. Mert et nem ad választ a felmerülő, kérdésekre, amiket megválaszolva elkerülhető a jövőben a hasonló probléma:
-Mi volt a hiba oka (root cause)?
-Hogyan lehetett volna elkerülni?
-Mire lett volna szükség ahhoz, hogy elkerülhető legyen (pl. jobb dokumentálás, a kábelezés ellenőrzése (4 szem?) az összekötés előtt, sb.)?
-Milyen eljárásrendet, munkautasítást, "sillabusz"-t kell javítani/módosítani/megírni és mikorra?
-Hogyan csináljuk legközelebb?
De ezt egyébként egy korrekt, az eseményt/problémát, illetve annak javítását részletesen leíró post mortem jelentés alapján is össze lehet szedni. A "sz@r volt, de megjavítottuk" mondat egy hibajegyben semmit, de tényleg semmit nem ér. Legyen benne az ok, a következmény, a hiba nyomozása, és a javítás mikéntje is.
- A hozzászóláshoz be kell jelentkezni
Értem én az elméletet, a gyakorlatban is végigcsináltam már többször, mint hogy egyáltalán számon tartani való dolognak nézném. Épp ezért gondolom, hogy ezen hosszasan rugózni nagyjából felesleges, a helyzet elég egyértelmű, a felsejlő megoldások leginkább csak arra jók, hogy a manager nagyon boldog lehessen, persze majd mostantól jobban doksizunk, meg majd minden kábelbedugás mellé odaállítunk egy felügyelőbizottságot, meg ráírjuk a checklistre 132. elemnek... A gyakorlatban ez még mindig mérnöki munka, nem lehet minden egyes apró részletét amit valaha valaki beszopott formális processzel megoldani, mert akkor a formális processz egy élhetetlen valami lesz, amit csak papíron fog létezni, és így alig ad hozzá bármit. Azért van a mérnök, hogy lesz kedves gondolkodni.
Ahol meg egyébként sincs lószar se, és nincs például semmiféle bevett módszertan egymás munkájának ellenőrzésére, vagy a projektek levezénylésére, ott nem egy ilyen piszlicsálé ügy miatt lesz majd rend.
Félreértés ne essék, nyilván érdemes ebből tanulni, de ehhez az ilyen nagyon leülünk bizottságis... hát izé, azt a kolléga lendületből tudja prezentálni: az volt a baj, hogy basztunk rendesen STP-t konfigurálni, és valaki szarul dugta be a kábelt. Javítanivaló: ezentúl konfiguráljuk be az STPt akárhol is vagyunk. Ha van listánk, ahol az ilyesmi van, akkor azt abba a wikibe lendületből bele is lehet írni hosszas meetingelés helyett, Zsoltit megkérjük, hogy ugyan legközelebb nézze már meg mit csinál, Bélát a főnököt meg, hogy találjon már valahol egy tízezrest egy zacskó normális kábeljelölőre, ne kelljen már filctollal bohóckodni.
Szépen megfogalmazva bruttó fél óra, és nem basztunk el RCAval meg meetingeléssel több időt szummában, mint amennyire egyébként a kolléga ideje fájt.
- A hozzászóláshoz be kell jelentkezni
Senki sem mondta, hogy ennek hosszas, több órán át tartó megbeszélésnek kéne lennie. Adott esettől függően lehet ez öt-tíz perc, ami inkább lényeges, hogy lehetőleg ott legyenek az érintettek, legjobb esetben az is, aki elrontotta, de azok igen, akiknél ez potenciálisan előfordulhat (nyilván egy kisebb teamet feltételezve).
- A hozzászóláshoz be kell jelentkezni
Hát, a dedikáltan emiatt leülünk és kielemezzük nekem eléggé úgy hangzott :) Zeller kolléga meg már kifejezetten még úgyabban hangzott. Imho ezt max valami egyébként is rendszeres infocsere meetingen, vagy egy mailben bőven elég.
- A hozzászóláshoz be kell jelentkezni
Nem mondtam, hogy egy külön dedikált meetinget kell rá összerántani, de a projekt/miniprojekt/feladat lezárása után mindenképp célszerű egy összefoglaló, tanulságokat levonó megbeszélést tartani - ahol a "mit kell másképp csinálni, hogy..." mondatokat is meg kell fogalmazni, és akár a meglévő folyamatleírásokba, munkautasításokba, tervezési elveket/előírásokat tartalmazó doksikba is belerakni. Mindenképp célszerű interaktív, beszélgetős megoldásban gondolkodni, egy levélfolyam kifejezetten szuboptimális szerintem ilyen célra - összefoglaló mehet levélben mindenkinek, ez természetes.
- A hozzászóláshoz be kell jelentkezni
hogy egy külön dedikált meetinget kell rá összerántani, de a projekt/miniprojekt/feladat lezárása után mindenképp célszerű egy összefoglaló, tanulságokat levonó megbeszélést tartani
Egyrészt a két mondatrészt direktben üti egymást, de most is mondod.
Másrészt nem, nem feltétlen kell minden munka után ilyet tartani. Akkor kell ilyet tartani, ha van miről beszélni. Itt (megint, feltételezve, hogy egyébként vannak használható processzek), nem nagyon van miről beszélni, aki beszopta, össze tudja foglalni, le tudja vonni a tanulságokat.
- A hozzászóláshoz be kell jelentkezni
Attól, hogy dedikáltan leülünk, még nem kell egy fél/egyórás meetinget tartani. Az aktuális működési formától függően ha pl. van valami rendszeres meeting, ahhoz hozzá lehet csapni, ha meg nincs ilyen, team-mérettől függően akár informálisan is össze lehet rántani egy gyors találkozót online vagy offline.
- A hozzászóláshoz be kell jelentkezni
Attól, hogy dedikáltan leülünk, még nem kell egy fél/egyórás meetinget tartani. Az aktuális működési formától függően ha pl. van valami rendszeres meeting, ahhoz hozzá lehet csapni, ha meg nincs ilyen, team-mérettől függően akár informálisan is össze lehet rántani egy gyors találkozót online vagy offline.
- A hozzászóláshoz be kell jelentkezni
Javítanivaló 2:
"Ha van listánk, ahol az ilyesmi van"
Legyen ilyen listánk, legyen ott a telepítőknél, hogy mi, hova, hogyan, és legyen,aki a dugdosás után átveszi és minimum szemmel veri :) a késznek mondott installációt.
"Bélát a főnököt meg, hogy találjon már valahol egy tízezrest egy zacskó normális kábeljelölőre"
Legyen elvárás a normális kábejelölés minden esetben, és az legyen is rendesen használva, legyen a tervezett kialakításnak megfelelően jelölve az összes(!) kábel (ehhez az kell, hogy a terveken is szerepeljenek jelölések), illetve csatlakozó, és a mit hova kell dugni táblázat is jó, ha elkészül - annak birtokában egy idomított csimpánz is el tudja végezni a kábelezést ugye...
A bruttó fél óra stimmel.
- A hozzászóláshoz be kell jelentkezni
Hát, egyrészt ezek teljesen esetfüggőek, hogy adott esetben van-e értelmük (milyen gyakran csinálunk ilyet pl), de pontosan ezekre mondtam, hogy ott, ahol kéne lenni listának, meg kéne lenni processznek, hogy hogyan ellenőrzünk, de nincs, ott tök fölösleges ezen rugózni, nem ettől fog hirtelen megjavulni minden, eddig se volt ott kompetens management meg akarat, nem ettől lesz.
És egyébként meg igen jól hozod azt is, hogy valójában csináljunk megnyugtató processzt, mert akkor majd örül a manager, hogy hát itt minden nagyon meg lett tervezve, és csinálva, és előre lerajzolva. Igaz ugyan, hogy 5x annyi idő az egész, mintha a netwörkös lemenne, és on-the-fly felkonfigurálná a switchet mikor megjön (természetesen előtte a lényegi részt átgondolva, de ez egy ilyen esetben kb annyi, hogy hova dugom fel), aztán a többit megcsinálná tisztességesen, aztán ha elbassza, hogy hova kell bedugni, azon továbbra se fog fost se segíteni az előzetes tervezés.
Én híve vagyok a processzeknek, csak az van, hogy processzből is ugyanolyan könnyű szart engineerelni, mint bármi másból. Pont ugyanúgy legacy posfányfos lesz belőle, mint a kódból, ha minden szart is beledobálunk még menet közben.
- A hozzászóláshoz be kell jelentkezni
Alapvetően teljesen igazad van: van, ahol ez nem is működhet(ne) másként, de gyanítom, hogy ez hely a Zyxel/Netgear alapján nem olyannak tűnik. Amivel még gond sincs feltétlenül, tudni kellene a körülményeket.
Másrészt az nem hibázik, aki nem dolgozik. Persze, kábelezés után vissza lehetett volna követni minden porton, hogy megfelelő Mac cím látszik-e stb, de ez nem feltétlenül az az erőforrás, amit jelen esetben megérne. Igen, hasznos és kell a dokumentáció, de tegye fel a kezét, aki Zyxel/Netgear helyen kellően vaskossal találkozott. Még olyan helyeken sem feltétlenül van, ahol nemcsak illene, hanem kellene is, hogy legyen.
LACP beállítás esetén alapvető ellenőrzés, hogy minden linken összeáll-e, ha nem, akkor keresni kell az okát. Itt kicsit bonyolította a helyzetet, hogy az STP rögtön levágott valamit, de ez nem kellene indokolná az LACP ellenőrzésének elhagyását, amiből rögtön kijött volna a hiba oka. Azaz nekem úgy tűnik, hogy ez leginkább a felvető kolléga tanuló "pénze" volt LACP/STP témakörben. Amivel szintén nincs gond, valamivel valamikor el kell kezdeni, senki nem úgy lépett pályára, hogy minden tudás és fogás birtokában lenne.
Gond akkor lenne, ha ezzel valamilyen explicit kárt okozott volna, mely esetben felmerül a felelősség kérdése, de ez esetben sem feltétlenül a téma felvető a felelős, de túl sok lehetőség lehet, melyeket szerintem felesleges találgatni.
- A hozzászóláshoz be kell jelentkezni
Alapvetően egyetértek persze. Így kéne csinálni.
Sokszor azon bukik el egy ilyen próbálkozás hogy egymástól nem függő csapatok dolgoznak egymás után.
És akkor az első csapat megcsinálta a melót, azt a megrendelő átvette (úgy ahogy) aztán jön a következő csapat aki szív a szarral.
Mint egy átlagos építkezés ...
- A hozzászóláshoz be kell jelentkezni
Igen. Ebben az esetben az átvétel módja (ha egyáltalán befolyásolható) az egyik kérdés, a következő pedig az, hogy ha ilyen ismeretlen dolgot veszel át, akkor mit érdemes átnézni a tényleges munkakezdés előtt (pl. hogy legalább a gerinchálózati pontok helyükön vannak-e). Persze ez a felvetés most gonoszság részemről, mert már ismert a root cause, de akkor is.
- A hozzászóláshoz be kell jelentkezni
Lessons learned-ben az ilyennek simán helye van. Következő hasonló projektnél erre is lehet és kell időt szánni.
El is lehet hagyni persze csak akkor a rizikó nagyobb.
- A hozzászóláshoz be kell jelentkezni
+sok. A retro nem csak a szoftverfejlesztés "működését" tudja pozitívan befolyásolni, az üzemeltetési, infrastruktúra projektek minőségbiztosításában is fontos szerepe lehet.
- A hozzászóláshoz be kell jelentkezni
Tapasztalatom szerint a legnagyobb baj az RCA-nál, hogy nem merik igazán felásni, nem csak kapargatni a felszínt.
1. Nincs kiviteli dokumentáció / terv. Semmi. "Minek az?" címszóval.
2. Mindig utólag, a kivitelezéshez képest jelentős késéssel (napok, hetek) próbálják meg fejből összerakni, hogy ki mit csinált. Így jön össze egy a valóságtól távol álló "dokumentáció". Kilóra azért megvan.
- A hozzászóláshoz be kell jelentkezni
Egyetértek. És akkor jön logikailag a következő lépés: a "kilóra azért megvan" azért tud átmenni a középvezetői rétegen mert abban a rétegben nincs se szakértelem se tulajdonosi szemlélet.
- A hozzászóláshoz be kell jelentkezni