Keresés

Új hozzászólás Aktív témák

  • vzozo

    senior tag

    válasz bambano #51 üzenetére

    Amikor a szakmai érvelést azzal akarod pótolni, hogy te ki vagy

    A PDF-es sértésre valamit írnom kellett.

    egyébként örülök, hogy ilyen kis projekteken gyakoroltál, így van még hová fejlődnöd.

    Célom is, hogy fejlődjek.:)

    Ráadásul ahogy látom, itt nálam csak tapasztaltabb emberek vannak, ezért is kértem, hogy jöhetnek a beszámolók, szeretnék tanulni. :U

  • vzozo

    senior tag

    válasz bambano #46 üzenetére

    meg olyanról is hallottunk, amikor valamelyik főnök úgy érzi, hogy neki alapos indoka van belepofázni a menetrendbe, amitől végül felborul minden.

    És akkor az kinek-minek a hibája? Az IT üzemeltetési szabályoké? A szoftverkomponenseké? Az üzemeltetésen ülő embereké?

    Vagy a (kis)főnöké, aki okosnak gondolta magát? Na akkor az majd szépen elszámol a főnökei / board / részvényesek / tulajdonosok felé.

    Egyébként ügyesen hajlítgatod a beszélgetés menetét, mert kb. onnan indultunk, hogy vérpistike ad-hoc módon telepíti a frissítéseket, és emiatt lehal az egész cég IT rendszere. A válaszom az volt, hogy ilyen nincs.

    Ahol van, ott ez lesz a legkisebb probléma, mert szervezetileg-működésileg sokkal komolyabb problémák húzódnak a háttérben.

    #47 fordfairlane Veled ellentétben, aki már sok PDF-et olvasott erről, és ha kell, képes végig bullshitelni egy teljes előadást.

    Jah, csak végignyomtam már jó pár millió euró feletti projektet az elmúlt ~10 évben, ahol érdekes módon betartva az üzemeltetési best practice-eket, nem döntöttük be sohasem a rendszereket.

    De sebaj, kíváncsian várom a valós beszámolókat, na nem a vérpistike ad-hoc telepít frissítéseket, hanem azokat a katasztrófákat, ahol tisztességesen megvolt(ak) a tesztelési kör(ök) és megfontoltan álltak neki a bevezetéseknek.

  • vzozo

    senior tag

    válasz bambano #40 üzenetére

    Nincs itt semmiféle mellébeszélés. Számos IT üzemeltetési keretrendszer létezik, amelyben van release / change management, illetve tervezett leállási ablakok.

    A change / release management része kell legyen a teszt, UAT, Staging, you-name-it rendszer(ek)en való tesztelés az éles bevezetés előtt. Ezen felül az éles bevezetés általában lépcsőzetesen, több hullámban zajlik. Természetesen rollback / contingency plan szintén létezik, és ezek kellően dokumentáltak, ismertek és begyakoroltak az üzemeltetők számára.

    Ennek ellenére ezen folyamatok megléte és teljeskörű betartása sem képes 100%-osan garantálni a sikert. Bárhol előfordulhat nem várt hiba. A cél a kockázatok minél teljeskörűbb minimalizálása, és ez működik is - egyébként senki sem tartaná be, és vérpistike módjára frissítgetne össze-vissza.

    Srácok, egyébként nem baj, hogy nem hallottatok még ezekről. Csak akkor nem kellene beeleugatni olyanba, amihez nem értetek.

  • vzozo

    senior tag

    válasz vlevi #36 üzenetére

    Mondom, hogy fogalmad sincs hogyan működik ez a valóságban, ahol mondjuk 5-10 gépnél nagyobb rendszerekről beszélünk. Különösen, ha munkavégzésre használt produktív környezetről van szó.

    Szerintem olvasd újra a hozzászólásomat, mert semmit sem értettél meg belőle.

  • vzozo

    senior tag

    válasz vlevi #33 üzenetére

    aztán egyszercsak hétfő reggel a végfelhasználók várhatnak 1-2 órát, míg frissül az új buildre a rendszer

    Figyi, te láttál már igazi számítógépet vagy azt is csak fotón? Mert igen, eddig is nyilván úgy volt, hogy minden szoftverfrissítés hétfő reggel munkaidőben települt, tesztelés nélkül, éles rendszeren, csak úgy bele a vakvilágba. A céges nagy rendszerek már csak ilyenek, ad-hoc módon működnek.

    Na ugorjunk...

Új hozzászólás Aktív témák

Hirdetés