"A hosszútávú támogatás károsnak tekinthető"

OpenBSD

Az OpenBSD fejlesztő Ted Unangst a GHOST sebezhetőség kapcsán arról blogolt a minap, hogy a hosszútávú karbantartás károsnak tekinthető. Szerinte a régi kiadásokat nem támogatni, hanem dobni kellene.

Példaként az OpenBSD-t hozta, ami minden évben (hat havonta) két kiadással jelentkezik. Az utolsó két kiadás támogatott abban az értelemben, hogy azokhoz készülnek patchek és a fejlesztők általában azokkal a kiadásokkal kapcsolatos kérdésekre hajlandók válaszolni, illetve azokkal kapcsolatos hibabejelentésekkel foglalkozni. Minden régebbi kiadással kapcsolatos kérésre a válasz: "frissíts újabb kiadásra".

A gyakorlatban ez azt jelenti, hogy a legrégebbi támogatott OpenBSD kiadás soha nincs egy évesnél régebbi.

Mondandóját úgy összegezte, hogy szerintük jobb, ha a felhasználók tisztában vannak azzal, hogy magukra maradtak, ahelyett, hogy olyan üres ígéreteket tesznek nekik, hogy az összes fontos javítás backportolásra kerül majd.

A blogbejegyzés itt olvasható.

( M0Rph3U5 | 2015. 02. 01., v – 08:48 )

Szerintem meg jó az LTS :) Bár tény, hogy nem adok ki saját disztrót, csak üzemeltetek...

"üres ígéreteket tesznek nekik, hogy az összes fontos javítás backportolásra kerül majd"

ezt a részt ugye nem ugrottad át véletlenül?

Az LTS elméletben nagyon jó, csak gyakorlatban a különböző terjesztések előállítóinál a nem-LTS verzió(k) (vagy simán a következő kiadás) miatt elég hamar visszaesik az érdeklődés a *valódi* karbantartás felé. Pl. van két vállalati Linux-disztró: RedHat és Suse, mind a kettő 2.x-es GNOME-ot ad, és mind a kettőben a gyárilag adott Nautilus Webdav-képességei szarok. És lesz javítva? Nem. És nem csak ez az egy ilyen módon karbantartatlan szoftverkomponens van bennük. (Emlegethetem pl. az ékezetes fájlnevek vannak csomagolva ZIP-fájlba, FAT-fájlrendszerű forrásból c. problémát, de van még elég sok másik.)

Hehe, erről van egy jó (?) sztorim. Ősrégi, de "támogatott" RHEL5, rsyslog. Csináltam nekik egy hibajelentést arról, hogy az rsyslog imfile (fájl beolvasó) modulja nem működik jól akkor, ha nem sorvégtől-sorvégig, hanem mondjuk blokkonként írjuk a fájlt. Reprodukálható így:

Konfig:

local5.* /tmp/test_debug.log

$InputFileName /tmp/test.log
$InputFileTag test_log:
$InputFileStateFile test_log
$InputFileSeverity info
$InputFileFacility local5
$InputRunFileMonitor

Ez oké:

# echo "test1" >> /tmp/test.log ; sleep 10 ; cat /tmp/test_debug.log
Sep 16 13:04:33 admin test_log: test1

Ez tuja a rák, hogy oké-e, de legyen:

# echo -n "test2 without enter at the end" >> /tmp/test.log ; sleep 10 ; cat /tmp/test_debug.log
Sep 16 13:04:33 admin test_log: test1

Ez viszont biztosan nem oké:

# echo " - and finishing test2" >> /tmp/test.log ; sleep 10 ; cat /tmp/test_debug.log
Sep 16 13:04:33 admin test_log: test1
Sep 16 13:10:32 admin test_log: - and finishing test2

2013. szeptember 11-én jelentettem be a hibát. 2014. április 29-én ezt kaptam válaszként:

"We heard back from our engineering team regarding this issue.Unfortunately we will be unable to include this bug in RHEL5 minor release.

We want to know the business impact of this bug so we can include this bug in RHEL6.Please provide the technical importance from your side.Then we will check it with our Product team and will update you."

Megírtam nekik, hogy nem elég jó a megoldás, az érintett alkalmazás nem fut REHL6-on.

A vége 2014. május 10-én:

"Hi,
Thanks for the update. Unfortunately our engineering team will not fix this issue in RHEL5.

As per your response in the last service request I am closing this case. If you need any further assistance then feel free to reopen this case.

regards,
..."

Hozzátenném, nem jellemző ez a hozzáállás általában, a RHEL support tök sok dolgot javított-megcsinált, amire kértem őket. De ha példálózni kell, akkor tessék, itt van egy eset :-)

Az LTS verzió csak az üzemeltetőnek (tulajdonosnak) jó. A fejlesztőnek foglalkozni kell a backport-okkal, a felhasználónak meg el kell szenvedni az újabb kiadásokban lévő képességek hiányát.

Ellenben az üzemeltetőnek nem kell az új rendszert tesztelni, hogy az aktuális környezettel kompatibilis-e, valamint nem kell upgrade-elni a gépeket (szerencsés esetben tesztelés után) az új verzióra.
Viszont ez alapján meg nem is az üzemeltetőnek jó, hanem a rendszert birtoklónak, mert a kevesebb frissítés (tesztelés) kevesebb üzemeltetésben részt vevő alkalmazottal megoldható, ergo olcsóbb. Plusz ritkábban fut bele régi hardver támogatásának megszűnésébe, ami miatt hardver költséget is okoz a verzió váltás.

Szóval az LTS verzió igazából nem műszakilag jó, hanem költségek szempontjából. A disztró kiadók is ez alapján keresik a cégek kegyeit az LTS verziók fenntartásával, mert azok valójában számukra csak (felesleges) plusz munkát okoznak.

A Windows termékek ilyen téren kicsit mások, mert ott a szoftver licenc eladásából már közvetlen bevétel származik, ergo van miből finanszírozni a backport-okat. Open source rendszereknél csak a támogatási szerződések finanszírozzák ezt a munkát, ami volumenében biztosan elmarad a licenc értékesítés + támogatási szerződés felállástól.

"Szóval az LTS verzió igazából nem műszakilag jó, hanem költségek szempontjából."

Tapasztalatom szerint költségek szempontjából se jó, mert a beláthatatlan közeljövőbe (4-6 év) kerül egy tervezhetetlen upgrade hatalmas költsége és üzleti kockázata a change freeze miatt.

Plusz hozzá lehet tenni azokat a költségeket, amelyeket az elavult technológiák és az egyre drágább fejlesztések okoznak.

De rövid távon nagyon jól néz ki, hogy minimális költség van csak.

Sok cég általában a garancia lejártáig üzemelteti a gépeit, utána újat vesz. Tehát a félelem az upgrade-től némileg alaptalan, hiszen nem OS upgrade történik, hanem komplett gépcsere. A csere idején pedig futhat a kettő párhuzamosan, hogy aztán az átállás a új, de már letesztelt környezetre egy éjszaka elvégezhető legyen.

Ave, Saabi.

Megnézném azért egyszer, hogy például egy számlavezető rendszernél ezt hogy játszod le, amikor kb. 7/24 a működés... van pár bank, ahol évek óta nem frissítettek, mert támogatott a rendszer, aztán meg ott volt az extended support, aztán az extra extended support, aztán már tényleg ott van a fal, csak azóta az összes igényelt feature -- amit az újabb verzió out-of-the-box tud, azt lefejlesztették kókányolva...

...és minél később van az upgrade, annál jobban fáj, és annál kevesebb ember van már a cégnél, aki 5-10 évvel ezelőtt is ott dolgozott és még emlékszik rá, hogy miért csináltak valamit éppen úgy.

Majd vesznek új vasat is, ha szükséges az upgrade :). Ha évek óta nem fejlesztettek, akkor valószínűleg a vasak is régiek. Megy még a régi, mellette már fel van állva az új, lehet tesztelni, aztán egy hétvégi este alatt át lehet tolni az éles adatokat az új rendszerre. (Legalábbis szerintem ha van eszük, akkor így tesznek)

Ne kattints ide!

:-) Láttam számlavezető rendszer alatt frissítést. Nem állítom, hogy rutinfeladat, de azért túlmisztifikálni se kell. És nem, a 7x24 működés nem azt jelenti, hogy nincs tervezett karbantartás. Egy számlavezető rendszert is le lehet állítani, csak meg kell találni az idejét és a módját.

Ave, Saabi.

Izé... én a nyitó topik alapján pont HW és Oprendszer szinten gondokodtam, meg a szálban (saabi) is gépüzemeltetésről beszélt, amire te feltetted a kérdést, hogy számlavazető esetén mi a helyzet (feltételeztem, hogy ott is HW-ra kérdeztél).

De ha már kimondottan számlavezető rendszer cseréjéről beszélünk: igazán leírhatnád, hogy szerinted egy másik számlavezetőre átállást (élesre váltást) miért is nem lehet megtenni egy hétvége/este alatt? Az elv ugyanaz: megy az éles elavult, mellette párhuzamosan az új, majd az áttöltés idejére leáll a rendszer. Ebben sehol sem látom, hogy a leállás idejét miért befolyásolná a régi rendszer elavultsága.

Ne kattints ide!

"Izé... én a nyitó topik alapján pont HW és Oprendszer szinten gondokodtam, meg a szálban (saabi) is gépüzemeltetésről beszélt,"

...én meg előtte nem arról.

"amire te feltetted a kérdést, hogy számlavazető esetén mi a helyzet (feltételeztem, hogy ott is HW-ra kérdeztél)."

Ahha... a számlavezető rendszer ezek szerint nem szoftver, amire van support? Áh, hogyne, a vízilóverseny minden kedden este a Kings Cross-nál van.

Én csináltam pár számlavezető rendszer migrációt és merem állítani, hogy kisebb bankok vagy más pénzintézetek esetében tökéletesen megoldható a dolog egy hétvége alatt. Az lehet, hogy az OTP esetében ez nem menne, egyszerűen az adatok túl nagy mennyisége miatt, de 100-200 GB közötti méretű adatbázisok esetében működőképes a dolog.

Általában nem csak az adatok mennyisége a probléma, hanem az 5-10-15 év alatt összegyűlt mindenféle egyedi módosítások és feature hiány okán hozzáragasztott szatellit rendszerek... amelyeknek az eredeti fejlesztője már rég nincs a banknál. És persze mindez RPG vagy COBOL nyelven, amihez nem elég kiállni az utcára és beterelni pár informatikus kinézetű embert.

Ha valaki számlavezetőt cserél, hol fognak problémát okozni a régi kókányolt szatelit rendszerek? Menni fog az egész a kukába. Van egyáltalán olyan ma is folyamatosan fejlesztett számlavezető rendszer a piacon, ami mellé nincs szatelitrendszer támogatás? Ha meg házon belül készül az új rendszer, akkor tessék a teamnek megvalósítani a szatelit részt is. A szatelitmodulok (ha külön vannak) megvásárálása az új rendszerhez a számlavezető árának úgyis töredéke lenne.

Ha meg házon belül készül az új rendszer, akkor tessék a teamnek megvalósítani a szatelit részt is.

Ne kattints ide!

Az eredeti kérdésed az volt (ahol én bekapcsolódtam), hogy a pld. számlavezető rendszerek 7/24-s működése esetén hogyan játsza le a cserét az illető (ráadásul gépcserés postra reagálva hoztad fel a számlavezetőt). Erre írtuk páran, hogy párhuzamos működéssel, azaz egy éjszaka vagy hétvége alatt át lehet úgy állni az új rendszerre(akár vas, akár OS, akár számlavezetőrendszer cseréje történik), hogy az üzletmenet folytonosság ne sérüljön. Ezt meg lehet tenni kövület rendszer esetén és naprakész esetén is. Azt sehol sem írtam, hogy nincs vele munka, mint ahogy azt sem hogy next-next-finish-tesztecske lenne a munka menete. (de szerintem űberkúlra frissített számlavezető esetén sem next-next-finish a számlavezető rendszer cseréje...)

Ne kattints ide!

"Az eredeti kérdésed az volt (ahol én bekapcsolódtam), hogy a pld. számlavezető rendszerek 7/24-s működése esetén hogyan játsza le a cserét az illető (ráadásul gépcserés postra reagálva hoztad fel a számlavezetőt)."

Én ezzel kezdtem és ezt is folytattam: http://hup.hu/cikkek/20150201/a_hosszutavu_tamogatas_karosnak_tekinthet…

Hogy Te hol kapcsolódtál bele a szálba és hogy saabi egy tizenkétszerveres rendszergazda, ezért ebben a koordináta rendszerben gondolkodik, az szerintem már nem az én asztalom...

Ott, hogy a számlavezető rendszerrel egyszerre a legritkább esetben cserélődnek a kapcsolódó további "gombócok", tehát az ismert és dokumentált, valamint a szájhagyomány útján feltételezett interfészhez kell kapcsolódnia továbbra is.
Mondjuk úgy, hogy leírtad az elméletet, ami a gyakorlattal elméletileg megegyezik. De csak úgy. Számlavezető rendszerek, de bármilyen hosszabb ideje működő nagy IT-rendszer esetében is igaz, hogy az idő előrehaladtával történelmi hagyományból lesz benne a legtöbb. Az, hogy naponta jöhet szembe ilyesmi, az egyrészt kellemetlen, mert sok minden erősen szuboptimálisan működik, másrészt viszont jó, hiszen van kihívás az üzemeltetésben :-D

Bocs, a második részben kihagytam a HW mellől az OS-t.

A végéhez meg bocs, kicsi vagyok :) szóval meg vagyok kavarodva:

A miénkre van support. Ez akkor most jó vagy rossz dolog? Jobban járnánk, ha nem lenne, és kétévente komplett számlavezetőt cserélnénk?

Ne kattints ide!

Hja, mondhatjuk úgy is, hogy csináltunk már ilyet :-)

Igazából ezekben a projektekben az esetek 99%-ában nem a vas vagy az operációs rendszer megváltoztatása a kihívás, hanem az, hogy:

- az alkalmazásból egyszerűen hiányoznak azok a képességek, amelyek lehetővé tennék a migrációját
- az alkalmazásnak hosszú "története" van, ami miatt igazából senki nem ismeri, számos apró részéről fogalma sincs senkinek, hogy mit és miért csinál
- az alkalmazás régi, és senki nem reszelte hozzá azokhoz az új környezeti elemekhez, amelyek az elmúlt években megváltoztak.

Mindezek persze mind megoldhatóak, csak egy ilyen frissítéskor egyszerre jelentkezik a múltban elhanyagolt összes költség, amitől általában nagyra nyílnak a szemek, összeszorulnak az állkapcsok - és sok esetben frissítés helyett inkább további halogatás lesz a választott stratégia.

Szerintem senki nem állította, hogy egyszerű feladat, bár ahol lelkiismeretes és szakértő üzemeltetés van nem csak platform, de alkalmazás oldalon is, ott ilyen nem fordulhat elő. Más kérdés, hogy láttam-e már ilyet. :-)
Én azt mondtam, hogy az átállás régi platformról (HW+OS) újra lezavarható egy hétvége alatt. Az más kérdés, hogy az előkészületek évekig tarthatnak.

Ave, Saabi.

( saabi v | 2015. 02. 01., v – 08:54 )

Ez most azt jelenti, hogy minden OpenBSD rendszergazda rendszeresen frissíti a rendszerét, természetesen a megelőző teszteléseket nem kihagyva? Vagy hogy rengeteg elhanyagolt, sebezhető OpenBSD rendszer van a világban? Vagy hogy nem használnak vállalati környezetben OpenBSD-t?

Ave, Saabi.

( Salcay v | 2015. 02. 01., v – 09:03 )

Láttok valahol OpenBSD-t enterprise környezetben? Na, ezért nem is fogtok. :)

--
Where do you want to go today?
[nobody@salcay:~]$_

Az egyik OpenStack konferencián a CERN-től volt egy fazon, aki azt mondta, hogy mindig mindent próbálnak cutting-edge technológián tartani, mert összességében kevesebb szívás van a rendszeres frissítésekből és az új hibákra való reagálásból, mintha 4-6 évente az egész szervezet megbénul hetekre-hónapokra a change freeze miatt, mert mindenki vadul javítgatja az elavult cuccait, amelyek nem kompatibilisek az új rendszerrel, mert ugye eltelt 4-6 év.

Én pedig mélységesen egyetértek ezzel, miután sikerült végigszívni az utóbbi három év alatt három upgrade projektet is. Ha mindig minden kis minor frissítést is elvégez az ember, akkor nem fog félni a frissítéstől, illetve gyakorlata lesz a visszaállásban és a javításban is, a fejlesztési terület pedig folyamatosan naprakész technológiát tud használni.

Aki az LTS mellett kampányol, azt be kell ültetni egy Windows 2003 -> Windows 2012 R2 komplett domain migrációba.
Majd utána elmesélheti, mennyire jó, hogy az élő(nek mondott) támogatás miatt nem volt kötelező a 2003-ról 2008-ra, majd 2008 R2-re, majd 2012-re frissíteni a 2012 R2 előtt.
Ez nem egy extrém példa, hanem aktuális probléma, mert a 2003 support 2015.06.14-én jár le, ami mindenkinek kényszerpályát teremt.

De ugyan ez pont ugyan így igaz az open source vonalon is. Egyik ügyfelünknél RHEL 5 van Oracle 10g-vel, amit nem mi üzemeltetünk. Kellett volna rá adatmentést beüzemelni, de a szoftver RHEL 6-ot kér minimum lib támogatás miatt. Az üzemeltető azt mondta, hogy az RHEL 5 még támogatott, ergo nincs oka lecserélni. Mert ha ezt tenné, akkor szívhatna az Oracle cserével is, amit nem szeretne. Így szokjam meg, hogy az általam kért szoftver nem fut azon a rendszeren. Ugye milyen jó az LTS...

Számold ki, hogy mennyivel került többe mondjuk szoftverlicencileg min. 2 DC esetén a

2003->2008->r2->2012->r2

mint a

2003 -> 2012. Persze aki megteheti, annak célszerűbb az első út. Viszont a második is támogatott (csak kevésbé tesztelt és járt út szerintem).

--
trey @ gépház

felreertettel. En a mai upgrade eseteben mondom.
Elozo komment szerint egyszerubb vegigmenni az egeszen, en azt mondom, hogy akkor ne 2003>2012-re upgradeljen, hanem menjen ma vegig, eredmeny ugyan az lesz, szamara ez a kevesebb szivassal jaro a tobb migracio, mert konnyebb minor verziokon menni vegig, akkor most is megteheti. Upgrade eseten aza x napos proba/aktivalatlan verziok elegek ( FIX ME).

Igy konnyu mondani, hogy elodom csinalja meg 2008ig a migraciot, hogy nekem konnyebb legyen 2008-rol 2012re migralni.
En arra irtam, hogy 2003-rol most is lemigralhatja a koztes allapotokkal egyutt, ha szerinte ez konnyebb es gyorsabb, mint kozvetlenul migralni.
Nagy szopas 2003rol 2012re migralni, de meg mindig kevesebb munkaora, mint kozteseket (akar most akar 3 evente) vegigtolni.

openstacknel foleg fontos ez (btw, ha jarsz openstack summitokra, koszonj rank legkozelebb, egesz nepes magyar delegacio szokott lenni, kb 10 ember), mivel a regi releaseket le se szarjak. (papiron persze nagyon foglalkoznak vele, gyakorlatilag nem).

a policy egyszeru: minel tobb, ujabb technologiat beletolni. ha nem mukodik, nem baj, csak legyen ott..

Mert működik és mivel user, őt ilyenek nem érdeklik, hogy egy 1x éve halott platformon fut a programja, ami lassan semmin nem fut. (A Windowsos verzió ugyanazt tudja). Hja meg ugye a Windowsos verziót újra kell tanulni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Értem én azt, de a másik oldalról meg bizony ha a usernek ugyanazért a funkcióért át kell menni egy tanulóidőszakon, akkor azért mégsem ugyanaz. Nyilván lehet mérlegelni, hogy melyik a nagyobb / fontosabb szopás, a tied, vagy a useré, de ettől még az nem lesz ugyanaz.

Illetve pont az ilyen könyvelés és egyéb adatrögzítős szoftverek környékén azért már láttunk olyat, hogy ugyan programozó kolléga szerint tudta ugyanazt, ellenben a felhasználó (mármint az értelmesebbje, aki egyébként hajlandó volt beletanulni) azért elmesélte, hogy ja, csak 10x olyan fos benne a workflow a dososhoz képest.

Ezt is ertem, de a kokret szitunal tenyleg a drama volt a tobb. Viszont az tarthatatlan állapot volt, hogy a DOS-os programot hol sikerült rabirni, hogy nyomtasson a hálózati nyomtatora, (de inkabb) hol nem, amire volt egy kulon LPT-s nyomtató (ezzel raadasul -1 asztalhely, ami meg kellett volna), es persze a (random illetékes hivatal)-nak mindig minden azonnal es papíron kell.

Szoval azert vannak fenntarthatatlan állapotok.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Félreértés ne essék, jártam én is hosszú í-t kereseni régi dosos szaron a sarokban, átérzem a sanyart, csak mondom, hogy alapvetően az is egy érv, hogy ha nem muszáj újat tanulni, akkor minek, az is idő, pénz. Ami összevethető azzal az idő pénzzel, ami elmegy a régi fos életbentatására, meg azzal, ami elvisz egy asztalnyi helyet, meg azzal a riszkkel, hogy ha beszarik a nyomtató a holdon sincs másik, stb. stb. Általában ez utóbbi simán nyer, és érdemes átállni, de ettől még az egyenlet azon oldala is létezik.

És már csak azért is érdemes nem elfelejteni, mert az IT sokszor titulálja semminek az ennél lényegesen alaposabb megfontolásra érdemes problémákat.

Ismerek egy idősebb könyvelőt, aki még mindig DOS-os programot használ, igaz DOSBox-ban futtatva. Azt mondta, hogy bár van a programnak Windows-os változata, de kipróbálta és nem felelt meg neki. Egyszerűen mások a gyorsbillentyűk és a form-elemek bejárási sorrendje is megváltozott. A DOS-ost nagyon megszokta és megszerette így amíg az tudja a számára fontos dolgokat, addig nem tervez váltani.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

( kroozo v | 2015. 02. 01., v – 09:26 )

Opciónként esetleg felmerülhetne, hogy nem üresek az igéretek?

( Replaced | 2015. 02. 01., v – 10:13 )

nem is hasznalja senki a szarjukat

--
NetBSD - Simplicity is prerequisite for reliability

( gelei v | 2015. 02. 01., v – 12:36 )

Bár tudnék én is ilyen szélsőségesen gondolkodni, mint ezek a szakértő urak!

Én a magam kis korlátolt világában csak annyit látok, hogy valamikor a szoftver up-to-date tartása a legjobb, valamikor pedig a minél ritkább frissítés, de úgy látszik, tévedtem, és a világ mégis fekete-fehér, köztes megoldások és kompromisszumok nélkül.

A frissítések témaköre leginkább arról szól a mai magyar valóságban, hogy a kedves döntéshozó hogyan kívánja kevésbé láthatóvá tenni a költségeket: azzal, hogy néha van nagy költsége és a többi időben villoghat, hogy nem kerül a frissítés semmibe, vagy azzal, hogy sokszor van költsége, de úgyis csak kicsi, ezért el is lehet hanyagolni.

Ez egy ilyen szakma :-)

( sj | 2015. 02. 01., v – 21:44 )

legalabbis fejlesztoi oldalrol koltseges egy zsak verziot karbantartani, backportolni, stb. Viszont uzemeltetoi oldalrol van abban racio, hogy nem kellenek uj feature-ok, de a bug-ok legyenek folyamatosan javitva. A ketto kozott a penz verhet hidat :-)

--
"Pont attól akartam megkímélni magam, hogy gondolkodni kelljen ;)" (lajos22)

Mondjuk normálisabb helyeken nem cseszik szét alattad az API-t, még ha nagyobb verziókat is váltasz. Viszont van olyan, amit félúton totál átterveznek és írhatod át a programod egy jelentős részét (erre példa az AvalonDock, ott szimplán maradtam az 1.x-nél, nem váltottam a 2.0-ra, mert nincs akkora plusz üzleti értéke).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( bikmakk | 2015. 02. 01., v – 23:34 )

Az egy év túl rövid, a három év pedig túl hosszú. Egészséges kompromisszum az lenne, ha minden második évben kellene frissíteni.

+1, az újrahúzási mánia leginkább a probléma megérteni nem akarásából fakad legtöbbször. (Vagy home környezetben még jellemző a mindenféle önvédelmi mechanizmus kikapcsolásából adódó helyreállíthatatlanság.)

(De most mindjárt jön trey, hogy bezzegazmssupport...)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Nem indul, újrahúzni - Nem windózpistike esetén ez általában nem igaz."

Ez egy üzemeltetési paradigma elosztott környezetben... nem kell azzal tökölni, hogy egy node miért állt meg, ha egy aprót köhhint, már le kell állítani azt a gépet, szó nélkül bezúzni és egy új instance mehet a helyére, az adatintegritás és megfelelő szolgáltatások pedig már automatikusan helyreállnak... :)

Lásd még "pet" és "chicken" típusú üzemeltetés.

egy jo nagy adag baromsag ez a link. teljesen mindegy, hogy pet, vagy cattle, ugyanugy lehet managelni oket mindkettovel, annyi a kulonbseg, hogy a vcloud director APIja hulladek^2 az openstackhez kepest.

a legjobb pelda erre, amikor egy Triple-O szeru rendszer van (openstack on openstack), es alul csak fontos VM-ek futnak (L3 GW(k), LB-k a szolgaltatasok elott, VPN endpointok, ...).

Valóban, szinte semmi szakértelem nem kell mondjuk egy olyan rendszer üzemeltetéséhez, mely egyik részben egy hosternél, másik részben egy cloud szolgáltatónál található, felhasználóinak kis töredéke a cég hálózatáról éri el AD authentikációval, legtöbben viszont valamilyen konzumer authentikációval egy mobilappon keresztül - cloud frontenden keresztül. Az erőforrások kímélése érdekében a terheléssel arányosan, dinamikusan változtatja a lefoglalt erőforrásait. Az adatokról cloud alapú backup készül és a hosternél elhelyezett vasak a hoster hidegtartalék géptermében 15 perces késleltetéssel elérhetők...
Megy az egész magától, szakértő üzemeltetésre lassan nem lesz szükség... vagy mégis?

Merthogy ennek az egésznek a hasában is olyan nyavalyák bírnak továbbra is előjönni, hogy mitől bomlik néha a VPN? Miért nem kap Kerberos ticketet az adott user stb... Ehhez nem kéne szakértő üzemeltetés?

Véleményem szerint egyre komolyabb üzemeltetői tudás kell valójában.
Eközben persze néhány tudáselem feleslegessé válik. De mi a hozzáadott értéke annak, hogy valaki tudja, milyen kapcsolókkal kell futtatni az ESEUTIL-t, hogy kiderüljön, clean shutdown volt-e az Exchange store-on? És annak, hogy a storage-ben SCSI ID-kat tekergessen valaki a diszkeken? Utóbbi pár éve volt még, mára eltűnt nyom nélkül.
A mozdonyfűtőkkel és a lámpagyújtogatókkal együtt.

Üdv,
Marci

Szerintem amit leírtál, az nem OS üzemeltetés. Lehet, nem voltam egyértelmű, de én az OS üzemeltetésre gondoltam. Tudod, egy rendszergazda legfeljebb egy tucat gépet terelgetve. Ezeket csillogóra kifényesítve, glancolva, a legutolsó rezdüléséről is tudva, hogy mit, hogy, hol és miért csinál.

Ave, Saabi.

"egy rendszergazda legfeljebb egy tucat gépet terelgetve" Az már régebben elmúlt, szerintem.
Üzemeltetői munkám végefelé (7 éve) is inkább a 40 szerver/rendszergazda volt az arány, legalábbis felénk Windows-osoknál. A Unix-os csapat a Te arányodhoz állt közelebb, akkoriban még.
Egyébként egyetértek, az OS üzemeltetés standardizálódik valamelyest de valójában még nagyon lassan.
De a folyamat elindult.
Az Ügyfelek legtöbbje viszont még mindig telepítési kézikönyvet vár - egy script helyett, ami megcsinálja azt.

Üdv,
Marci

Az azért nyilvánvaló, hogy szükség lesz olyanokra, akik "meg tudnak csinálni dolgokat" viszont kevésbé lesz azokra szükség, akik "meg tudnak javítani dolgokat". Szükség lesz arra, aki rendszer szinten gondolkozva képes konfigurálni, viszont az elromlott dolgokat inkább cserélik, legyen szó vasról vagy OS-ről.
Azért szerencse, hogy a kisállatbarátokra valamilyen szinten azért szükség lesz. :-)

Ave, Saabi.

Egyetértek és tetszik a megfogalmazásod.
Továbbgondolva, valószínűleg az egzotikus kisállatok kihalásának vagyunk inkább szemtanúi.
Sok éve magam is szüntettem meg kéttagú Windows 2000 Server alapú aktív-aktív WINS, file- és print clustert (rajta roaming profile 1200 felhasználóra(!)), melyet a Szállító tagonként mellesleg DC-nek, DNS szervernek és TS licensing szervernek alakított ki (ha jól emlékszem).
Na ehhez aztán kellett üzemeltető... bár inkább csoda volt, ha egyáltalán ment... kezdetben 256MB RAM-mal...
Inkább Godzilla semmint kedves kisállat.

Üdv,
Marci

Ez azt jelenti, hogy van egy ismeretlen, de "pletyka" szinten ismert üzemeltetési kockázatod, amiről nem akarsz tudomást venni, de bármikor előjöhet bármelyik komponens biztonsági frissítésekor? Mert pont ezért jó a rendszeres frissítés: adott esetben a mentésből való visszaállás, a részleges újratelepítés és a hibakeresés is rutin lesz, nem fog tőle félni az üzemeltetés.

Gondold végig, hogy ha félsz egy mentésből való visszaállítástól vagy egy teljes újratelepítéstől, mert még teszt környezetben se csinálod gyakran, akkor éles üzemben, éjjel, álmosan, fáradtan, stresszesen, adrenalintól telítve és a fél vezetőséggel a hátad mögött miért lenne sikeres vagy rutinszerű a művelet?

Amitől félsz, azt csináld gyakrabban.

( Polesz v | 2015. 02. 02., h – 08:20 )

Az a fránya hibajavítás ne volna. Francnak kell mindent észrevennie a júzernek :-)

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

( _ventura_ v | 2015. 02. 02., h – 09:13 )

Lehet, hogy a fejlesztoknek nem jo, de ez legyen az Ő bajuk :D Én személy szerint áttértem CentOS-re ahol nincsen oprendszer kitétel, ugyanis ha más nem legalább az oprendszernek van 10 éves security supportja.

A mai napig fut még Debian 3.1 LAMP szerver mert a kedves ügyfél annó betákolta a rendszerét 4.x es PHP ban. Mivel sok sok pénzt ráköltött és működik minek piszkálja ? A szolgáltatásért meg fizet. Innentől patthelyzet.

Fedora 21, Thinkpad x220

( Dolphy | 2015. 02. 03., k – 17:21 )

Mondja ezt egy olyan op.rendszer fejlesztője amit a mai napig kézzel kell upgrade-elni.