Mit hasznaltok szerver programok futasanak/mukodesenek ellenorzesere es ujrainditasara?

Linux-haladó

vagy 20 eve irtam ra scriptet, ami cronban megnezi, hogy pl. 25-os tcp porton van-e valami, es ha nincs, akkor ujrainditja az eximet.

ezt csinalja meg magatol, kuldjon rola emailt hogy volt ilyen.

hatha van mar jobb, amire le tudnam cserelni.

update:

ugy latom akivel meg nem fordult elo, hogy egy nem mukodo szolgaltatas miatt hajnal 6-kor telefonalgatnak neki, az nem foglalkozik ezzel. :)

ha az ilyen problemak 99.99%-at megoldja az, hogy automatikusan ujrainditom a szolgaltatast, akkor pont ennyi meg is oldodik magatol.

systemd:

barcsak tenyleg alapbol megoldana azt, hogy ha a szolgaltatas elpusztul, akkor magatol ujrainditja. probald ki ezt:

# systemctl is-active exim4.service   
active

# killall -9 exim4

# systemctl is-active exim4.service   
active

pedig nem.

persze ha az /etc/systemd/system/exim4.service.d/local.conf-ba beledobom, hogy
[Service]                                                                                                                                                                                                       
Restart=on-failure                                                                                                                                                                                              
RestartSec=5s  
 

az ujraindithatna, de nem teszi.

  • 3258 megtekintés

( peterson v | 2023. 10. 09., h – 14:32 )

Szerkesztve: 2023. 10. 09., h – 14:34

Ezeket én zabbixból kezelem.

De megmondom őszintén, nem gyakorlat újraindítani egy leállt szolgáltatást, mert:

1. nem tudod miért állt meg, és az újraindítási kísérleted végtelen ciklusba eshet

2. az nem normális, hogy egy szolgáltatás "csak úgy" leáll. Annak oka van, amit meg kell keresni, és meg kell szüntetni.

[szerk:] ha ez az ok netán egy élő ember, akkor azt kell megszüntetni. :D

"A megoldásra kell koncentrálni nem a problémára."

( eff | 2023. 10. 09., h – 14:57 )

Szerkesztve: 2023. 10. 09., h – 14:59

systemd service? :)
ha leall, akkor annak illik error code-dal leallnia.
Systemd service eleg sok parametert tud restart esetere (hanyszor, mekkora delay legyen, error code-ok, stb).

https://www.freedesktop.org/software/systemd/man/systemd.service.html#R…

https://www.freedesktop.org/software/systemd/man/systemd.service.html#W…

stb.

szerk: OnFailure notification pelda: https://www.baeldung.com/linux/systemd-service-fail-notification

( pirate | 2023. 10. 09., h – 14:57 )

systemd v. supervisord (ezek nem hiszem hogy kuldenek email-t, de biztos bele lehet hekkelni, a cron szerintem tovabbra is jo erre a celra)

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

( carlcolt | 2023. 10. 09., h – 15:19 )

Szerkesztve: 2023. 10. 09., h – 15:19

pgrep, curl :)

Ennyikeh :D

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

( Friczy v | 2023. 10. 09., h – 15:29 )

Sok-sok évvel ezelőtt a runit-et használtam hasonlóra.

( golgota | 2023. 10. 09., h – 15:36 )

barmelyik monitoring rendszer ami tud reaktivan mukodni? 

Check->alert->fix_action

Azaz kb mindegyik ami github/gitlab/akarhol megtalalhato

( Zs | 2023. 10. 10., k – 10:10 )

Anno ismerős a monit nevű csodát használta.

Nekem a Zabbix jött be action scripttel.

Ugyanakkor egyetértek a korábban már elhangzottakkal: ha valamiért leállt a szolgáltatás, azt meg kell nézni, miért tette és nem minden esetben az az optimális, hogy gondolkodás nélkül restart.

( persicsb | 2023. 10. 10., k – 10:13 )

Pontosan erre való a systemd, inetd vagy más hasonló service manager.

Egyébként igen, de a kérdezőnek volt egy ilyenje "pl. 25-os tcp porton van-e valami". Most hogy ez azért van, mert rosszul nézi, vagy azért, mert nem bízik abban, hogy a szolgáltatás nem pörög az arcán, miközben még fut, tehát tényleg kell a monitoring jellegű működés, az nem egyértelmű.

Régi szabály már, hogy ami mindenre jó, az igazából semmire sem jó.

Jó lenne ha a systemd eljutna oda, hogy visszajelzi a szolgáltatás inditásának/leállításának sikerét/kudarcát, vagy hogy ír a naplókba, és ha ír akkor nem semmitmondó bullshit-eket, hanem a problémát, és a legfontosabb: naplóba csak az igazat, a színtiszta igazat! Na ezek a systemd-nek még nem nagyon mennek. Kaptam már rajta, hogy belehazudott a logba. Ez megbocsáthatatlan.

De ha sikerül megugrania ezeket az eretnek vágyaimat (van több is, de most csak hsz-t írok nem könyvet :) ), akkor majd beleszeretek.

 

[szerk:] Amúgy nem haragszom, amiért alig burkoltan lehülyéztél. Megbocsátok. :)

"A megoldásra kell koncentrálni nem a problémára."

Jó, akkor nem "hazudott", de a logban az igazságtól lényegesen eltérő tévedés szerepelt a szolgáltatás NEM elindulásának okaként. Miközben a `systemctl start ... ` parancs hibaüzenet nélkül adta vissza a promtot.

Így kimosdattuk a szerecsent? :)

"A megoldásra kell koncentrálni nem a problémára."

 Miközben a `systemctl start ... ` parancs hibaüzenet nélkül adta vissza a promtot.

Ez simán a service hibája. Sok service hibásan reportolja az állapotát a systemd felé. 
Példa: https://github.com/fluent/fluent-bit/issues/5120

Nehogymás a systemd hibája legyen az, hogy egy service azt jelzi, hogy sikeresen elindul, miközben nem. A service hazudik, nem a systemd. Mint amikor egy program hibával leáll, de 0-s visszatérési értéke van.

Ha hagynánk, hogy a szolgáltatás maga logoljon, jelezzen, és nem mindent is a systemd-re bíznánk, akkor lehet hogy az üzemeltető elsőkézből jutna igaz információkhoz, ahelyett, hogy valami (a systemd) beleáll a kommunikáció közepébe, és azt közöl az üzemeltetővel amit ő (gyakran tévesen) gondol.

Többszáz fejlesztőnek kell alkalmazkodnia a systemd azon logikájához, amit annak fejlesztői önhatalmúlag döntöttek el, és kötelezővé tették mindenki számára. Mert szerintük ez jó.

"A megoldásra kell koncentrálni nem a problémára."

Ha hagynánk, hogy a szolgáltatás maga logoljon, jelezzen, és nem mindent is a systemd-re bíznánk

Azon ez nem segit, ha az alkalmazas hulyeseget ir a logba, akkor ezutan is azt fog. 

Egyebkent hacsak nem akarod vadaszni a mindenfele szetszort logokat, akkor valamifele middleware ugyis kelleni fog, aminek a fejlesztoi eldontottek, hogy hogy mukodjon. Oke, ne a systemd legyen az, hanem egy masik, de akkor csak masik fejlesztok hoznak masmilyen donteseket.

 ahelyett, hogy valami (a systemd) beleáll a kommunikáció közepébe

Most akkor elvárod, hogy a systemd ismerje a szolgáltatás státuszát? Akkor valahogy tudnai kell róla. És ha az alkalmazás hülyeséget mond a systemd-nek, akkor a systemd sem fogja tudni az igazságot.

A logolásba meg miért is szólna bele a systemd? Egy alkalmazás oda logol, ahova akar. Logolhat rotált fájlba, graylogba, bárhova, senki nem mondja meg, hogy mit csináljon.

Többszáz fejlesztőnek kell alkalmazkodnia a systemd azon logikájához, amit annak fejlesztői önhatalmúlag döntöttek el, és kötelezővé tették mindenki számára. 

Mivan? A más által küldött dolog exim4-es dolog is arról szól, hogy a systemd meg tudja hajtani a sysv init alá készült szolgáltatásokat, anélkül, hogy a szolgáltatásnak bármit kéne módosítania. Milyen systemd-specifikus logika van itt, amihez a fejlesztőnek igazodnia kell?

Itt egy kicsit mindenkinek igaza van, meg egy kicsit nem.

Disclaimer: nem vagyok egy pottering fan (és ez egy erős understatement), de...

Igen abszolút meg tudom erősíteni, hogy az emberek (és itt nem az egyszeri linux userre, hanem az egyes service-ek fejlesztőire gondolok) nem értenek a systemd-hez ÉS lusták elolvasni a service file man oldalát. Rengeteg upstream service jön kishibás service file-al, ami kinda-sorta működik, de igazából nem jól. Az szinte teljesen alap, hogy "aszinkron" indulnak, a systemctl start nem vár be semmit, azonnal visszatér. Ez pont így kííváló, ha dependsOn-t akarnál használni... meg ha mondjuk ansible-el akarnál felhúzni dolgokat, mert minden azonnal szalad tovább. Nem várja meg, hogy mondjuk a DB feljöjjön, mielőtt az appszervert ráindítod stb. És persze nem derülnek ki a hibák sem. Nyomogathatod utólag a status-t, hogy észrevedd, hogy a service valójában azonnal le is állt valami hibával. Kivéve, ha a systemctl statusban sem látod, mert a service fileban a type rosszul van megadva.

Szóval általában első dolgom, ha ansible-el valami service installját kell megírnom, hogy override service file-t csinálok, amiben kijavítom az upstream service file hülyeségeit. Ha nagyon nincs más megoldás, berakok egy ExecStartPost-ot for ciklusban futó netcat paranccsal, ami addig várakozik, míg a service portja el nem kezd listen-elni. Kicsit undormányul néz ki, de megoldja:

ExecStartPost=/bin/bash -c 'for ((I=30;I>0;I--)); do echo "waiting for {{ servicename }} to start listening on port {{ servicename_port }}: $$I s"; nc -z localhost {{ servicename_port }} && exit 0; sleep 1; done; echo "wait timed out"; exit 1'

Persze ez nem ideális, megvan a maga baja, ha Restart= -t állítasz be akkor az ExecStartPost hibájára is restartol, ami szar ha túl kicsi timeoutot adtál meg, és a RestartPreventExitStatus= sajnos csak a fő ExecStart= parancs visszatérési értékére hat. Szóval vannak azért hiányosságai a systemd-nek (másik kapcsolódó problémám az örök-broken sd-notify, amit most nem fogok végigmesélni), de az ilyen service indítási problémák, meg "hazudik a systemd" döntő többsége a rosszul megírt service file, vagy patologikusan rosszul viselkedő (saját magának init rendszert játszó) daemon hibája.

Régóta vágyok én, az androidok mezonkincsére már!

Az adott keretek között nem, nyilván ha nem lehet sehogy megcsinálni normálisan egy daemonnál, akkor marad ez. Csak felrémlett előttem a csodálatos compose, amiben kb az a dep kezelés, hogy milyen sorrendben hívja meg gondolkozás nélkül a startot a konténerekre (és semmi más nincs), aztán ha bármit bele akartál tenni egy ilyen archba, ami nem volt eleve felkészítve arra, hogy retrryol a végtelenségig, akkor mehetett a startupba valamelyik inkarnációja ennek a csodának. Tudom, hogy annak idején sírva röhögtem rajta, hogy mire -- ugyan peterson és golgota lelki békéjének súlyos meggyalázásával -- de eljutunk oda, hogy kb mindenhol van systemd, amiben van használható dependencia kezelés, akkor gyorsan mindent átteszük dockerbe, ahol meg ez a fos van, és még egy rohadt init sincs, ami annyit megcsinál, hogy nem zombizza tele a (pl a wait-for-it.sh behelyezése miatt) odakerült rengeteg csodálatos entrypoint.sh a processz táblát.

Aztán megmutattad, hogy a világ már megint körbeért, és felsírtam :D

Nagyon roviden, most hirtelen ezt a leirast talaltam meg: https://systemd-devel.freedesktop.narkive.com/FXALdRi2/systemd-notify-ready-is-not-reliable

Lennart by-design egy versenyhelyzetet epitett bele az sd notify feldolgozasba, ezert bizonyos valoszinuseggel elveszit notification-oket.

De egeszen biztos vagyok benne, hogy ez _boven_ tobb, mint 9 eve nyitott issue, kb a systemd kezdetei ota ~15 eve megvan a bugreport ra. Tudtommal mind a mai napig nincs megoldva es Lennart ugy all hozza, hogy majd a kernel fejlesztok megoldjak. Emiatt erre az interfeszre nem nagyon mer senki sem epiteni, pedig amugy hasznos lenne. Peldaul (hogy ontopic legyek) a topicindito problemajara jo volna a watchdog feature a systemd-ben, ami restartolja a szolgaltatast, ha az abbahagyja WATCHDOG=1 uzenet periodikus kuldozeset a systemd socketjebe. Nyilvan ezt az alkalmazasnak is implementalnia kellene, de szinte senki nem tamogatja (az okairol tovabbi hosszu kitero lenne a fejtegetes, megint egy jo adag Poetteringizmus van mogotte).

Lehet amugy (csunyan, de megbizhatoan) workaroundolni, ha sajat magad irsz egy kb 3 soros python scriptet, es a unix socketbe READY=1 irasa utan beleteszel egy sleep 1-et, mielott kilepnel. :)

Régóta vágyok én, az androidok mezonkincsére már!

danke schon, nálunk 1-2 javas dologban  van SDNotify bekötve, elrakom a fejembe, hogy ez lehet nyűgös. hála égnek nem kellett még vele szenvedni (és hála égnek nagyon kevés dolgunk van, amit egy VM-en futtatunk, a terhelésünk nagyrésze (~90+%?) k8s felett van)

Ez konkretan jol fog mukodni, mert singleton instance-ban megtartja a socket connection-t a futas vegeeig. Akkor van baj, ha pl a systemd-notify command line toolt hasznalod, ami azonnal becsukja es socketet es ki is lep.

A baj ezzel a libraryvel az... nem is. A library azt csinalja, aminek kezdettol fogva a hivatalosan javasolt megoldasnak kellett volna lennie.
A baj Lennart-tal :) az volt, hogy a hivatalos doksikban ezt a unix domain socket interfeszt ugy jelolte meg, hogy ne hasznald direktben, mert nem stabil interfesz, elvileg barmikor valtozhat. Az elmult 15 evben amugy csak hozzatettek dolgokat, vegig backward kompatibilis maradt. Hivatalosan csak a C-s sd_notify() vagy command line systemd-notify wrappert volna szabad hasznalni. Nyilvan java-bol, Go-bol, barmi masbol, "ki vagy segitve" a C-s libraryvel. A command line tool meg kiprovokalja a versenyhelyzetes bugot.

Régóta vágyok én, az androidok mezonkincsére már!

Szoval miutan a szerverben az osszes scsi vezerlo meg minden faszom az elso 5 percben elmolyol az oprendszer nem 17 masodperc alatt indul el, hanem 8. Wow! Le a kalappal, csokkent a bootido 3%-al !!! Koronazzuk meg a systemd-t :D !!!

A felhoszolgaltatas eseteben meg jobb ha nem Iaas-t hasznal az ember hanem PaaS-t vagy SaaS-t (vagy eppen FaaS-t). De ha mar millio gepet kell felhuzni autoscalinggel akkor is kb mindegy mert maga a scaleing monitoring ideje is minimum egy perc de ugye altalaban 5 (spin and cooldown). Szoval szignifikans elonye nincs. Ha meg mar tenyleg ennyire problema az autoscaleing akkor at kell terni a cloudprovider megoldasaira. Azaz megint nem segit a systemd 8 masodperces boot ideje. 

De mondok egy peldat. 100 node-os spark cluster scalingje burst eseten 500-ra es vissza. Ebbol a systemd kb semmit sem segit. Mire a spark driver szepen osszefutyul mindennel es eldonti hogy tenyleg kell e annyi worker a jobokhoz elegge sok idot vesz igenybe. ezen nem segit a systemd. Lefele meg megint szep lassan fogja lebontani a workereket. az a 8 masodperc kb lofaszt nem szamit. Nem az fogja a koltsegek nagyjat adni, megha masodperc alapu a szamlazas es 500*8 masodpercrol is beszelunk. A teljes koltseg 0.5%-at fogja adni. Ha runit vagy openrc-vel csinalnak kb ugynennyi lenne, szoval a systemd itt nem selling point. Ha meg sysV inittel akkor a 0.5% helyett lehet 0.6% lenne. Szoval ennyit a systemd-rol

Biztos van olyan use-case aminel milliardokat lehet sporolni a systemd-vel, csak en meg lehet nem olvastam rola, igy nem tudom. Johet a pelda.

Nem a systemd védelmében írom, mert rühellem, mint ördög a tömjénfüstöt: Nagy cég, 5000 fizikai vassal és 20000 virtuális géppel. Mivel nagy, így mindenhol megy a költségelszámolás. Az üzemeltetés / cloud provider szépen leszámláz mindent a részlegek / ügyfelek felé.

Számold ki, hogy ha minden gép csak havi 1x indul újra patchelés miatt és újraindításonként nyernek csak 5 másodpercet, akkor az ~27,7 óra. Ha ezt le akarod fordítani költségre, akkor nyugodtan vedd hozzá a patchelő kollégák idejét is pluszban, mert ennyivel több időt kell a gép előtt töltenie (manuális patchelés). Ha van SCCM, Ansible stb., akkor meg ott "eurosodik" az elveszett gépidő.
Egyszerűség kedvéért €10 /órával számolva €277 /hó, €3324 /év. Természetesen a számokkal lehet tovább játszani, akár €30e-50e-s megtakarítást elérve. Az meg már elég jól látható összeg.

Tehat szamoljunk, 20K geo megy 7/24-ben ami osszesen 14400000 ora, amibol sporoltunk (kerekitsunk felfele mert gavaller vagyok 30 orat. Ez a koltsegek 0.0002 %-a annyit sporoltunk meg a systemd-vel. 

Ha csak ez merul fel mint koltsegcsokkentes egy ekkora infranal az is valami, de en azert megrpobalnek lefaragni inkabb 1-2%-ot itt-ott mondjuk service-ek cloud service-ekre migralasaval per request alapon, hatha tobbet sporolunk veluk, mint 0.0002%. Bar feltetelezem hogy ez korbe van jarva rendesen. 

De nekem a 0.0002% meg mindig nem selling point. De ha nektek igen akkor az szuper. Ha ennyit szamit az 5 masodperc indulasi ido, akkor inkabb celszeru k8s vagy folyton futo servicek iranyaba menni, API+func. Ott nem 5 masodpercet de akar az osszes masodpercet is megsporolhtjatok.

BigData workloadok eseten meg a systemd-vel kb semmit nem sporolsz. A szazalekos aray meg ennel is kevesebb lesz.

Nekem ellenpéldának eszembejutottak az AIX-os emlékek. Ott valahogy nem a 17 vs 8 másodperces oprendszer indulás volt a jellemző nagyságrend... :)

(Ettől függetlenül igen, a brand szervergyártóknak - tisztelet a kivételnek - méretes f/szkorb^cs jár, hogy percekig eltököl a gépük Initializing UEFI firmware, majd kis text mode init képernyő után a céglogós grafikus splash screen, majd kis ikonkák az inicializálódó perifériákkal, majd pár milliszekundumig felvillan hogy milyen billentyűkombóval lehetett volna belépni a setupba, ha nem késel le róla és végül indul az OS bootloader.)

Régóta vágyok én, az androidok mezonkincsére már!

( gabrielakos v | 2023. 10. 10., k – 13:22 )

Az első kérdés az hogy "belülről" akarod-e nézni, akkor pl. a systemd jó lehet neked (ha megbízol benne)
Ha kívülről akarod nézni akkor zabbix, librenms, nagios és hasonló monitoring cuccok.
Nekem librenms van itthon, 95%-ban tetszik.

zászló, zászló, szív

( hnsz2002 v | 2023. 10. 10., k – 13:28 )

Szerkesztve: 2023. 10. 10., k – 17:55

A systemd alapból tudná, de mivel a default unitok kb. egyik sincs alapból úgy beállítva, így nem sok értelme: vagy mindre csinálsz override-ot (nem lehet globálisan), vagy hagyod az egészet a francba, és megoldod a monitoring rendszerrel.

Nálunk zabbix csinálja ügyesen. Csak nem szabad elfelejteni amikor debuggolsz vagy direkt állítod le... :)

A systemd annyival lenne jobb, hogy nyilván tudja hogy leállítottad és azért nem kell elindítani. A zabbix meg csak azt látja, hogy enabled, szóval futnia kéne, de nem fut.

"Sose a gép a hülye."

bocs azt feltetelezem, mindenkinel ugyanaz. :)

=====

# systemctl cat exim4   
# /run/systemd/generator.late/exim4.service
# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/exim4
Description=LSB: exim Mail Transport Agent
Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=remote-fs.target
After=nss-lookup.target
After=network-online.target
After=time-sync.target
After=postgresql.service
After=mysql.service
After=clamav-daemon.service
After=greylist.service
After=spamassassin.service
Wants=network-online.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/exim4 start
ExecStop=/etc/init.d/exim4 stop
ExecReload=/etc/init.d/exim4 reload

# /etc/systemd/system/exim4.service.d/restart-on-failure.conf
[Service]
Restart=on-failure
RestartSec=5s

=====

# systemctl status exim4
● exim4.service - LSB: exim Mail Transport Agent
    Loaded: loaded (/etc/init.d/exim4; generated)
   Drop-In: /etc/systemd/system/exim4.service.d
            └─restart-on-failure.conf
    Active: active (running) since Wed 2023-10-11 00:59:10 CEST; 11h ago
      Docs: man:systemd-sysv-generator(8)
   Process: 443245 ExecStart=/etc/init.d/exim4 start (code=exited, status=0/SUCCESS)
     Tasks: 1 (limit: 1124)
    Memory: 8.7M
       CPU: 1.044s
    CGroup: /system.slice/exim4.service
            └─443502 /usr/sbin/exim4 -bd -q30m

okt 11 00:59:09 host systemd[1]: Starting exim4.service - LSB: exim Mail Transport Agent...
okt 11 00:59:10 host exim4[443245]: Starting MTA: exim4.
okt 11 00:59:10 host systemd[1]: Started exim4.service - LSB: exim Mail Transport Agent.

=====

# killall -9 exim4

=====

# systemctl status exim4
● exim4.service - LSB: exim Mail Transport Agent
    Loaded: loaded (/etc/init.d/exim4; generated)
   Drop-In: /etc/systemd/system/exim4.service.d
            └─restart-on-failure.conf
    Active: active (exited) since Wed 2023-10-11 00:59:10 CEST; 11h ago
      Docs: man:systemd-sysv-generator(8)
   Process: 443245 ExecStart=/etc/init.d/exim4 start (code=exited, status=0/SUCCESS)
       CPU: 1.046s

okt 11 00:59:09 host systemd[1]: Starting exim4.service - LSB: exim Mail Transport Agent...
okt 11 00:59:10 host exim4[443245]: Starting MTA: exim4.
okt 11 00:59:10 host systemd[1]: Started exim4.service - LSB: exim Mail Transport Agent.

 

neked aztan fura humorod van...

RemainAfterExit=

Takes a boolean value that specifies whether the service shall be considered active even when all its processes exited. Defaults to no.

GuessMainPID=

Takes a boolean value that specifies whether systemd should try to guess the main PID of a service if it cannot be determined reliably. This option is ignored unless Type=forking is set and PIDFile= is unset because for the other types or with an explicitly configured PID file, the main PID is always known. The guessing algorithm might come to incorrect conclusions if a daemon consists of more than one process. If the main PID cannot be determined, failure detection and automatic restarting of a service will not work reliably. Defaults to yes

 

Mind a kettő okozhatja a fenti problémát.

hany eve is van systemd a debianban? hany verzio volt mar azota?

miert nem lehet vegigcsinalni egy sysv->systemd atallast ugy, hogy minden szerver program service fajljat megirjak?

regebben - talan debian 11-nel - panaszkodtam, hogy a systemd naplozza ha a service fajlban /var/run van /run helyett vagy valami ilyesmi, ez is egy atallas. meg mindig latok ilyet, persze mar joval kevesebbet a debian 12-ben. nem lehet rakeresni, hogy hol van meg /var/run aztan modositani?

neked aztan fura humorod van...

szerintem mar tul vagyunk ezen, de azert valaszolok, mert vetted a faradtsagot. ez a sima sysv-s exim4 init fajl, amibol a generator megprobalja kitalalni milyen systemd service fajlt csinaljon. a fajl futtathato tartalmat feltetelezesem szerint nem ertelmezi, csak az init infot, de hogy a GuessMainPID es RemainAfterExit erteket miert ilyenre allitotta be, az szamomra rejtely.

### BEGIN INIT INFO
# Provides:          exim4
# Required-Start:    $remote_fs $syslog $named $network $time
# Required-Stop:     $remote_fs $syslog $named $network
# Should-Start:      postgresql mysql clamav-daemon greylist spamassassin
# Should-Stop:       postgresql mysql clamav-daemon greylist spamassassin
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: exim Mail Transport Agent
# Description:       exim is a Mail Transport agent
### END INIT INFO

neked aztan fura humorod van...

kiprobaltam ezt is, de igy sem:

https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/

"If systemd doesn't know which PID is the main PID of a service, it will not be able to track its runtime, and hence a service exiting on its own will not make systemd consider it stopped. Use the Red Hat "pidfile:" syntax in the SysV script header comment block to let systemd know which PID file (and hence PID) belongs to your service. Note that systemd cannot know if a SysV service is one of the kind where the runtime is defined by a specific process or whether it is one where there is none, hence the requirement of explicit configuration of a PID file in order to make systemd track the process lifetime. (Note that the Red Hat "pidfile:" stanza may only appear once in init scripts.)"

neked aztan fura humorod van...

( peterson v | 2023. 10. 11., sze – 05:57 )

Szerkesztve: 2023. 10. 11., sze – 06:19

ugy latom akivel meg nem fordult elo, hogy egy nem mukodo szolgaltatas miatt hajnal 6-kor telefonalgatnak neki, az nem foglalkozik ezzel. :)

ha az ilyen problemak 99.99%-at megoldja az, hogy automatikusan ujrainditom a szolgaltatast, akkor pont ennyi meg is oldodik magatol.

Ez pont az az eset, amikor a problémával foglalkozol, és nem a megoldással. A problémát nem kezelni kell, hanem megoldani.
A hajnali 6kor csörgő telefon pedig nem egy rontás, vagy átok, hanem a készenlét egyik velejárója. És (helyesen) rákényszerít arra, hogy megoldást keress a "hagyjatok aludni" című autorestart script-ek helyett.

Ráadásul, ha már az exim van a példádban, az pont nem az a szolgáltatás ami "csak úgy" leállna. Szerintem a logba sem azt írja hogy "leállok, mert csak". ;)

"A megoldásra kell koncentrálni nem a problémára."

Nem feltétlen az van, hogy ezzel le van szarva a probléma, de ha utána újraindul és megy még valameddig, akkor nincs annyi leállás, és neked sem kell feltétlen (és nem is mindig tudsz 3 percen belül) azonnal gépnél lenni. Aztán majd megnézed ha odaérsz.

"Sose a gép a hülye."

(és nem is mindig tudsz 3 percen belül) azonnal gépnél lenni.

De igen! Ezt hívják készenlétnek. Fizetik. És ha készenlétben nyugodtan szeretnél aludni (ezzel pedig ingyen pénzt szerezni), akkor megcsinálod úgy, hogy jó legyen.
BTW: és ha az automata restart script végtelen ciklusba esik? Vasárnap hajnali 2-kor? És lerántja az egész server-t?

Én nyugodtabban alszom készenlétesként egy működő szolgáltatással, mint egy patkolt instant restarttal. De lehet hogy bennem van a hiba...

"A megoldásra kell koncentrálni nem a problémára."

Nem arról van szó, hogy nem csinálod meg úgy, hogy jó legyen. Hanem arról, hogy lehetnek problémák, rajtad kívül álló események. És ugye ami "majom munka", automatizálható, azt automatizáld.

Ha van egy service leállás és pl. hív az ügyfél hogy megállt, és húú milyen fontos, áll mindenki, akkor neked nem az az első, hogy megpróbálod restartolni? Aztán ha elindult, utána megnézed hogy mi volt... Akkor nem mindegy, ha a zabbix csapja újra?

Nem kerül végtelen ciklusba. A zabbixnak egy systemctl restart van adva mint action script. Ezt nyomja service-re 10 perc után (amikor 10 perce down) ha nem Acknowledged a probléma és nincs maintenanceben, küld róla egy emailt. Ha újabb 5 perc után sem megy, akkor mégegyszer, email. Újabb 5 perc, mégegyszer, email... És ennyi, utána nem csinálja többet. Nyilván ami 3 restartra nem indult el, annak más baja is van, úgyis meg kell nézni.

De ettől függetlenül előfordul olyan, hogy leáll egy service: out of memory pl., de pl. javas appnál láttam simán segfaultot az "in akarmi.java:5672 (és kilométeres dump...)", de olyat is láttam már, hogy update közben abba hasalt el valami (amiben nem kéne, de ezzel te nem nagyon tudsz mit kezdeni), hogy lefrissült alatta a lib. És attól függetlenül, hogy pl. nálunk az updatet mindig gép restart követi, közben nem rossz, ha újra lesz indítva.

Modernebb meg biztonságosabb autót sem azért veszel, mert minden nap használni akarod a légzsákot, meg az ABS-t, meg a vészfék asszisztenst. De ha kell akkor jó ha van. Meg tűzjelzőt, füstérzékelőt sem azért, mert mindig meg akarod hallgatni.

Szóval ne mondd nekem, hogy nem jó hogy van ilyen és ez nem kell.

"Sose a gép a hülye."

De ettől függetlenül előfordul olyan, hogy leáll egy service: out of memory pl., de pl. javas appnál láttam simán segfaultot az "in akarmi.java:5672 (és kilométeres dump...)",

Na, itt is pont a programozónak kéne átnézni a kódot, és nem az üzemeltetőnek restartolgatni. Értem én, hogy "nincs szar kód, csak gyenge vas", de nekem üzemeltetőnek az oomkiller a barátom. A java fejlesztőnek meg az ellensége. De ez egy ilyen világ... :D

"A megoldásra kell koncentrálni nem a problémára."

A mi világunkban igazad van.
Egy tökéletes világban azt kellene mondani, hogy a java foshalom mindaddig állni fog, amíg a fejlesztő nem jut megegyezésre az oomkillerrel. ;)
És ez nem az üzemeltető problémája, aki allokált neki már 64GB RAM-ot. Hanem a fejlesztőé. Akinek 4GB-ban is illene elférnie, mert nem az Androméda galaxis feltérképezését kapta feladatul, csak egy tyúkszaros intarface-t. De továbbra is elfogadom, hogy biztosan velem van a probléma...

"A megoldásra kell koncentrálni nem a problémára."

Ezért van az instant restart. A logok alapján meg utólag, reggel megnézed, hogy éjjel 2-kor miért volt restart. Tök nyugodtan lehet aludni üzemeltetőként is, nincs belőle gond.

A valóban reziliens rendszerek ugyanis a folyamatos restartot normál üzemnek tartják. Így működnek az autók ECU-i, így működnek az űrhajók rendszerei, mindegyik biztonságkritikus rendszer számára normális az, ha akár másodpercenként többször újraindul valami miatt.

így működnek az űrhajók rendszerei, mindegyik biztonságkritikus rendszer számára normális az, ha akár másodpercenként többször újraindul valami miatt.

Ja, az más... Akkor ezért nem megy minden héten egy járat a Holdra... :D
Én kérek elnézést!

"A megoldásra kell koncentrálni nem a problémára."

Jah, ideális világban igen.

A valóság meg olyan, hogy valamelyik library közepén van memleak, amire közvetlenül nincs dependency, gyakorlatilag semmi ráhatásod nincs, mert a környezetből jön. Az életem legnagyobb szopása amúgy egy ilyen library esetén egy viszonylag ritka race condition okozta memleak volt, amit hárman nyomoztunk kb. egy hétig, a reprodukálása se volt egyszerű, nemhogy az okának a megkeresése. Ha nem zabálta volna fel hirtelen és előjel nélkül a szabad memóriát, akkor sose lett volna kijavítva, egyszerűen sokszor olcsóbb cégszinten egy ütemezett újraindítás.

A világ nem egyszerű és nem körülötted forog, kapaszkodj meg: cégek akár illegális dolgokat is bevállalnak, ha a sorozatos büntetés olcsóbb, mint rendesen megcsinálni. Egyszerű üzleti racionalitás, vannak játékszabályok és azok határozzák meg a játékot, nem az elvek és az ideák.

https://iotguru.cloud

Értem, és megértem, csak nem értek egyet vele.

Pont ez szokott a bajom lenni több fejlesztővel amit írtál:
mindenféle libeket töltögetnek be mindenhonnan, gyakran azt sem tudják mi mindenre képes (csak gondolkodni ne kelljen, mert az drága). De példálul betöltenek egy kamion méretű matematikai libet ami derivál, integrál, és kiszámítja a marsszonda ideális röppályáját ha kell, pedig csak két integert fog összeadni vele. És eljutunk oda, hogy a javaban írt alapműveletes számológép nem fér el 16GB RAM-ban, aztán az üzemeltető lesz a hülye amiért az oomkiller megöli a java process-t.

Igen, durván sarkítottam. Szándékos volt. :D Reducatio ad absurdum.

"A megoldásra kell koncentrálni nem a problémára."

mindenféle libeket töltögetnek be mindenhonnan, gyakran azt sem tudják mi mindenre képes (csak gondolkodni ne kelljen, mert az drága).

Igen, gondolkodni drága. És feltalálni a meleg vizet is drága. Java esetén a legtöbb memleak oka olyan dolog, ami nem a fejlesztő hatásköre, hanem a környezet együtthatása.

És eljutunk oda, hogy a javaban írt alapműveletes számológép nem fér el 16GB RAM-ban, aztán az üzemeltető lesz a hülye amiért az oomkiller megöli a java process-t.

Az üzemeltető azért hülye, mert ilyeneket ír, ahelyett, hogy üzemeltetne. Ezért cseréljük le az ilyen üzemeltetőt egyre inkább Kubernetes-re, mert ott az OOM egy szimpla újraindulási ok sok egyéb újraindulási ok mellett, amit vagy megéri megjavítani vagy nem, szimpla üzleti döntés, ha tetszik, ha nem.

Igen, durván sarkítottam. Szándékos volt. :D Reducatio ad absurdum.

Nem körülötted forog a világ, hogy neked kényelmes legyen.

https://iotguru.cloud

 De példálul betöltenek egy kamion méretű matematikai libet ami derivál, integrál, és kiszámítja a marsszonda ideális röppályáját ha kell, pedig csak két integert fog összeadni vele. És eljutunk oda, hogy a javaban írt alapműveletes számológép nem fér el 16GB RAM-ban, aztán az üzemeltető lesz a hülye amiért az oomkiller megöli a java process-t.

Őszintén szólva annak az üzemeltetőnek, aki szerint azért nem szabad behúzni libet, mert attól nő meg a szolgáltatás memóriaigénye, annak érdemes volna felsőbbségének kevésbé biztos tudatában nyilatkozni fejlesztési kérdésekről ;) 

Egy tökéletes világban azt kellene mondani, hogy a java foshalom mindaddig állni fog, amíg a fejlesztő nem jut megegyezésre az oomkillerrel. ;)

Ha eltekintunk tole, hogy a fejleszto fizeteset, a te fizetesedet, de meg a portas fizeteset is az a "java foshalom" termeli ki, akkor igen, hadd pihenjen :)

Egy tökéletes világban azt kellene mondani, hogy a java foshalom mindaddig állni fog, amíg a fejlesztő nem jut megegyezésre az oomkillerrel. ;)

A tökéletes világban az ilyen habitusú fejlesztő és üzemeltető ki van baszva a cégtől és mehetnek vissza a balettbe ugrálni.

És ez nem az üzemeltető problémája, aki allokált neki már 64GB RAM-ot. Hanem a fejlesztőé.

Az üzemeltetésnek a dolga az, hogy üzemben tartsa a szolgáltatásokat, illetve az igényeiről és problémáiról visszajelzést adjon. Ha az adott szoftver hibás, akkor is ez a feladata. Igen, ez néha azt jelenti, hogy oda kell neki adni plusz erőforrásokat ideiglenesen, sőt, akár folyamatosan is, ha például az üzlet azt mondja, hogy nincs egymillió forint megjavítani a szoftvert, viszont 64 GB memória meg ott hever a raktárban vagy meg kell venni és olcsóbb, mint egymillió forint.

Nem körülötted forog a világ, hogy neked kényelmes legyen.

https://iotguru.cloud

Nem körülötted forog a világ, hogy neked kényelmes legyen.

De nem is a fejlesztő urak körül forog, akik imádnak magas lóról beszélni. Két kezemen (5 ujj/kéz) meg tudom számolni, hogy hány szakmailag kompetens és vállalható személyiségű fejlesztővel találkoztam eddig.

Üzemben tartani csak azt lehet, amihez a fejlesztés biztosította az átadás-átvétel lebonyolításához szükséges entitásokat. Csak amíg OMM ("oldd meg magad!") szituáció van, addig szívni fog az üzemeltetés is. Végeredményben az ügyfél is.

De nem is a fejlesztő urak körül forog, akik imádnak magas lóról beszélni. Két kezemen (5 ujj/kéz) meg tudom számolni, hogy hány szakmailag kompetens és vállalható személyiségű fejlesztővel találkoztam eddig.

Na, ugyanezt tudom mondani üzemeltetésről... a többsége magas lóról beszélő balfasz. :D

Üzemben tartani csak azt lehet, amihez a fejlesztés biztosította az átadás-átvétel lebonyolításához szükséges entitásokat. Csak amíg OMM ("oldd meg magad!") szituáció van, addig szívni fog az üzemeltetés is. Végeredményben az ügyfél is.

Üzemben tartani bármit is lehet, a kérdés mindig az, hogy megéri-e üzletileg a befektetett plusz munka és erőforrás üzemben tartani. Ha igen, akkor üzemben lesz tartva, legyen ott bármi is. A fő probléma az szokott lenni, amikor az üzemeltetés úgy tekint a vasra, mint saját cuccára, pedig az a cég cucca, amit ő azért kapott meg kezelésre, hogy azon fussanak a dolgok és ha nem futnak jól, akkor eszkalálja a problémákat. És igen: kaphat olyan választ az eszkaláció során, hogy ez így marad, mert üzletileg ez éri meg.

https://iotguru.cloud

A fejlesztőknek is kicsit maguknak kellene érezni a rendszert és nem pazarolni az erőforrásokat ész nélkül.
1-2 esetben találkoztam eddig csak, hogy fentről jött a kérdés: Miért kell ennek ennyi erőforrás? Miért kerül ez ennyibe? El kellene jutnunk oda, hogy több felsővezető merje feltenni ezt a kérdést a fejlesztés irányába is.

Persze nyilván vannak végletek, jó és rossz példák mindenhol. Csak amit üzleti szinten 40 éve megoldottunk X-nyi erőforrással, arra lehet, hogy most 10*X vagy 100*X erőforrást költünk. Jó ez így? Szerintem nem feltétlen...

A fejlesztőknek is kicsit maguknak kellene érezni a rendszert és nem pazarolni az erőforrásokat ész nélkül.

1, Jelenleg a fejlesztők kb. 95-99 százaléka egy framework-öt használ, amiben alig van ráhatása arra, hogy mennyi erőforrást használ.

2, Be kell árazni az erőforrást. Ha a fejlesztők óradíja szignifikánsan több, mint a hardver, akkor hardvert kell a rendszer alá tenni.

1-2 esetben találkoztam eddig csak, hogy fentről jött a kérdés: Miért kell ennek ennyi erőforrás? Miért kerül ez ennyibe? El kellene jutnunk oda, hogy több felsővezető merje feltenni ezt a kérdést a fejlesztés irányábais.

Én gyakran találkozom ezzel, csak a legtöbb esetben, amikor kiderül, hogy 16 GB lefaragása 8 GB igényre vagy például átlagos terhelésnél 10 CPU lefaragása 5 CPU-ra 2-6 emberhónap fejlesztés, a 8 GB memóra és/vagy az 5 CPU meg szó szerint gombokba kerül, akkor nincs az a felsővezető, amelyik ilyenkor azt a döntés hozza, hogy basszon el a fejlesztés 2-6 emberhónapot arra, hogy pár dollárral kisebb számok legyenek az üzemeltetésnél.

Persze nyilván vannak végletek, jó és rossz példák mindenhol. Csak amit üzleti szinten 40 éve megoldottunk X-nyi erőforrással, arra lehet, hogy most 10*X vagy 100*X erőforrást költünk. Jó ez így? Szerintem nem feltétlen...

Az van, hogy megöregedtél és nem érted vagy nem akarod érteni a világot. Egyrészt nem ugyanazt oldottad meg 40 éve X erőforrással, hanem töredékét se tudtad akkor megoldani, másrészt nem költesz többet, hanem kevesebbet költesz jóval nagyobb tudású erőforrásra. 1980-ban egy IBM PC mai áron ~100 ezer USD körül volt kapható, 4 MHz, 64 kB memória, floppy lemez. Ma a zsebedben van 100 dollárért egy olyan számítógép, ami négy magos 2 GHz, GPU, 2GB memóra, 32 GB storage és olyan dolgokat tud, amit a 40 éves IBM PC sose tudott... hidd el, hogy jó ez így, te se sírod vissza igazán a 40 évvel ezelőtti dolgokat.

https://iotguru.cloud

Az van, hogy megöregedtél....

Direkt aláhúztam és kiemeltem, hogy üzleti szintről beszélek. A világ nem IT-ból áll. Egy élelmiszer gyárban, egy logisztikai cégnél, egy autókereskedelmi cégnél stb. alapvetően ugyanazokat az üzleti problémákat kell megoldani, mint 40 éve. Az IT csak támogatást nyújt, nem az IT oldja meg a problémákat. Nem az IT körül forog a világ - bár sokan azt hiszik.

Direkt aláhúztam és kiemeltem, hogy üzleti szintről beszélek. A világ nem IT-ból áll. [...] Az IT csak támogatást nyújt, nem az IT oldja meg a problémákat. Nem az IT körül forog a világ - bár sokan azt hiszik.

Ezzel kezdtem: https://hup.hu/comment/2976836#comment-2976836. Jó reggelt! :D

https://iotguru.cloud

Egy élelmiszer gyárban, egy logisztikai cégnél, egy autókereskedelmi cégnél stb. alapvetően ugyanazokat az üzleti problémákat kell megoldani, mint 40 éve.

Negyven éve tudott olyat a magyar posta, hogy megrendelem a kulapapírt, és ~30 percen belül a küszöbön van? Ha nem, akkor ma más problémákat old meg a logisztika.

(Ahogy jóesetben a merkúrnál sem állsz már éveket sorba, bár az utóbbi évek kicsit bekavartak itt is, trú dat)

Ide is érvényes:

https://hup.hu/comment/2977111#comment-2977111

Továbbá:

Az üzemeltetésnek a dolga az, hogy üzemben tartsa a szolgáltatásokat, illetve az igényeiről és problémáiról visszajelzést adjon

De milyen áron? Nyilván mindenáron. Az üzemeltetésnek nincsenek igényei, problémái (legalábbis a fejlesztők felé), az üzemeltetésnek erőforrásai vannak, amiket allokálnia kell. És nem csak egy fejlesztő számára, hanem külső és belső szolgáltatások, másik 3 tucat fejlesztő, és még egy csomó minden számára. És el kell szomorítsalak: ezek az erőforrások végesek, és nem csak egy darab fejlesztő kiszolgálására vannak.

"A megoldásra kell koncentrálni nem a problémára."

De milyen áron? Nyilván mindenáron.

Az ár üzleti döntés. Akkor is, ha nem értesz egyet vele.

Az üzemeltetésnek nincsenek igényei, problémái (legalábbis a fejlesztők felé), az üzemeltetésnek erőforrásai vannak, amiket allokálnia kell.

Ha így gondolod, akkor rossz helyen dolgozol vagy rosszul dolgozol. Az üzemeltetésnek nincsenek erőforrásai, amelyeket allokálnia kell. Az üzemeltetést kap dedikált vagy elosztott erőforrásokat arra, hogy egy-egy szolgáltatást üzemeltessen. Ha ez a kapott erőforrás kevés, akkor eszkalálja a problémát, mindegy, hogy ez memória, tárhely vagy emberi erőforrás többlet.

És el kell szomorítsalak: ezek az erőforrások végesek, és nem csak egy darab fejlesztő kiszolgálására vannak.

Ezek az erőforrások nem a tieid, hanem a cég erőforrásai, amelyeket az üzlet fizet azért, hogy a cég tevékenységei pénz hozzanak vagy kevesebb pénzbe kerüljenek. Neked hiába fáj, hogy valaminek kell 16 GB memória, ha egy r3.large instance például 0.04 USD óránként és hoz 1000 dollárt a szolgáltatás, ha épp megy. És hiába indul újra óránként OOM miatt, ha az OOM okát kideríteni, megjavítani, letesztelni, éles üzemig eljuttatni például négy ember egyheti munkája, vagyis egy emberhónap lenne, amiből 20-30 évig lehetne fizetni azt a nyomorult r3.large instance-t.

Az üzlet ilyenkor ezt állítja egymás mellé:

a, egy hétig áll a szolgáltatás: ~168000 dollár közvetlen veszteség + üzleti reputáció veszteség,
b, egy hétig javítják: ~10000 dollár költség, gyakorlati előny nélkül,
c, plusz erőforrás a szolgáltatás alá: ~30 dollár havonta.

Nem kérdés, hogy mi lesz a racionális üzleti döntés. Akkor is, ha ezzel se a fejlesztők, se az üzemeltetők nem értenek egyet. Az a cég, amelyik ilyenkor megállítja az üzleti folyamatait, hogy ilyen marginális faszságokat tudjanak dolgozni az IT-n, az csődbe fog menni és/vagy a versenytársai olcsóbbak lesznek.

https://iotguru.cloud

Nyilván a valós életből vannak ezek a számok. Ja, nem.

A 0,04 USD/h az valós. A 10000 USD emberhónap költség mindennel együtt az valós EU viszonylatban. Az vélhetően a legtöbb cégnél alábecslés, hogy egy core szolgáltatás állása óránként csak 1000 USD pénzbe kerül, ennél jóval több kár szokott lenni ebből. Melyiket vitatod?

https://iotguru.cloud

Semmi. Mivel nincs kiinduló adat, bedobtál egy hasraütéses instance-ot és két szintén hasraütéses egyéb adatot. Hiteles, valóban.

Mivel 16 GB memóriáról volt szó a szálban (lásd "nem fér el 16GB RAM-ban, aztán az üzemeltető lesz a hülye amiért az oomkiller megöli a java process-t"), ez egy 16 GB memórát tartalmazó instance, ami ennyibe kerül.

Persze nem az, de legalább jól hangzik. Az biztos, hogy egy ilyen tartalmatlan vitába nem fogsz behúzni.

Már belehúztad magad minden jel szerint...

https://iotguru.cloud

Ez nettó faszság. A legfontosabb erőforrás az idő.

Aham, az ugyanúgy erőforrás. Ahogy a fejlesztők ideje is.

Az egyszerű munkavállalónak is van munkaideje, mint erőforrás, amelyet fel kell osztania valakinek a munkák, feladatok között.

Így van. És könnyen lehet, hogy azért van még munkája az adott üzemeltetőnek, mert ma még ő a legolcsóbb certified reboot engineer, de holnap már elveszik a munkáját.

https://iotguru.cloud

Az az üzemeltető küldött már a fejlesztőknek heap dumpot, a betelt 64GB-ról? Általánosságban nem árt partnerként kezelni a fejlesztőt és segíteni neki megtalálni a hibát. A megfogalmazásból én úgy érzem, hogy legalább _van_ fejlesztője annak service-nek és nem egy megörökölt legacy-t kell életben tartani, amihez senki bottal sem tud hozzányúlni.

Régóta vágyok én, az androidok mezonkincsére már!

Általánosságban nem árt partnerként kezelni a fejlesztőt és segíteni neki megtalálni a hibát.

Maximálisan egyetértek. Gyakran működik is. Komolyan!

De volt már, hogy élőben kaptam azt a fejlsztőtől amit fentebb írtak: olcsóbb a RAM mint az ő órabére kódrevizióra. Ne várjam el hogy gondolkodjon.
Ilyenkor az üzemeltető zsebében kinyilík egy pici bicskácska... ;)

Értem, hogy gazdaságilag logikus. De szakmai hozzáállásként a legalja.

"A megoldásra kell koncentrálni nem a problémára."

Értem, hogy gazdaságilag logikus. De szakmai hozzáállásként a legalja.

Ha ez tenyleg  elhangzott igy, es nem csak olyan csusztatott pelda, mint a fenti, akkor a kollegad egy fasz, de szakmailag igy is lehet igaza.

Imho itt haromfele problema van osszemosva:

  1. Bugfix, ha pl. memleaket okoz valami hiba. Ezzel erdemes lehet foglalkozni, mert altalaban relativ konnyen megjavithato. Vagy ha eppen van egy sok node-os architekturad, es ujra lehet inditani benne gond nelkul a rendetlenkedo node-ot, akkor hagyhatod a fenebe.
  2. Mikrooptimalizacio, amikor a 16 GB-t igenylo alkalmazasbol csinalunk 15.5 GB RAM-ot igenylo alkalmazast. Ez altalaban draga es ertelmetlen, hacsak nincs valami konkret megoldando problema.
  3. Alien (mert a foldon nem el ilyen :)), amikor a 16 GB igenyt leszoritjuk mondjuk a felere, funckiovesztes nelkul. Ilyen gyakorlatilag nincs, vagy ha van, akkor annyi melo van vele, hogy a PO gyomra nem veszi be a fejlesztesi igenyt (nagyon helyesen!). 

Nem. Az oomkiller nem a barátod. Utolsó utáni védvonal, rengeteg durva kompromisszummal. Olyan, mint az automata elárasztásos tűzoltórendszer. Nem ég porig a ház, de ami berendezést a tűz nem tett tönkre, azt tönkreteszi a víz.

Én úgy érzem, hogy itt az a probléma, hogy valójában az a bizonyos java-s service nincs jól üzemeltetve. Az üzemeltetőnek lenne dolga, hogy bemonitorozza rendszert, gyűjtse az adatokat. Felkonfigurálja a futtatókörnyezetnek megfelelően a JVM heap size paramétereit (a java-nál megadatott az üzemeltetőnek az a "luxus", hogy már runtime szinten tudja korlátozni a memóriát). Bekapcsoljon JMX-et, gyűjtse hogy mi történik a memóriával, mit csinál a GC. Összeszedje a szűkséges parancsokat - ad absurdum akár automatizálja - heap és stack dump készítéshez ha baj van, vagy akárcsak "baj közeli állapot" áll elő.

Ha a java-s service prodban bármi miatt leáll, akkor az üzemeltető dolga, hogy kiszedje belőle azt a debug infót, amit a fejlesztőknek oda tud adni a bug ticketben. Már csak azért is, mert normális helyen compliance miatt csak az üzemeltetőnek szabad, hogy egyáltalán hozzáférése legyen a prod rendszerhez. Ezt a munkát nem akkor kell elvégezni, amikor éppen az éjszaka közepén bejön az alert, hanem normál munkaidőben, megelőző jelleggel. Ez egy befektetés, ami az éjszaka közepén térül meg. Meg, amikor nem kell kötbért fizetned az ügyfélnek az outage miatt. Sok esetben a monitoring rendszerben már bőven azelőtt látszik a baj (pl memory leak), hogy a tényleges outage megtörténne.

Régóta vágyok én, az androidok mezonkincsére már!

Az üzemeltető akkor tud bármit is jól felkonfigurálni, ha megkapja hozzá a támogatást az üzlettől (igénylik) és a fejlesztéstől is. Ha a fejlesztő alapvető kérdésekre se tud válaszolni, akkor nincs miről beszélni.

Amiket írsz, azokkal alapvetően egyetértek. TMK. Viszont amíg az az álláspont, hogy "Működik, nem?" (általában PO/PM/üzleti oldalról), addig felesleges a proaktivitás. Sajnos.

Ok, azért egy JVM-et fel lehet paraméterezni a fejlesztők közreműködése nélkül is. :) Lehet, hogy elsőre nem lesznek jók a számok, de erre való a monitoring, hogy tudjad finomhangolni. Amiket leírtam annak a túlnyomó többsége standard upstream cucc, szerencsére. Végeredményben az üzemeltető a saját dolgát könnyíti meg vele.

Nyilván, ha az üzemeltető hozza a grafikont a nyilvánvaló memory leakről és a management leszarja ("csak a feature fejlesztés menjen") a bugfix nem kap prioritást, akkor relative gyorsan érdemes elkezdeni a linkedin profilt frissíteni. :)

Szerencsére sok esetben nem ennyire szélsőséges a helyzet. Persze van olyan hely is, amit te írsz, de szerintem a leggyakoribb, amikor a zsák megtalálja a foltját. A management sem tartja túl fontosnak, az ops-osok se törik össze magukat. Eldagonyázgatnak a manuális processzeikben. Morognak a fejlesztőkre, hogy milyen szar kódot írtak, de semmi effortot nem tesznek bele, hogy megcsinálják a rendes visszacsatolást a fejlesztőknek. Akik így kb nem is tudnak róla, hogy ami náluk lokálban látszólag jól megy, az élesben döglődik. Vagy kapnak semmitmondó "megint elcrashelt ez a szar" típusú bug ticketet, amiben semmi konkrétum nincs amin el tudnának indulni. Persze, hogy ők is morogni fognak az ops-ra.

Amiket én eddig tapasztaltam (felvásárolt startup cégektől megörökölt borzalmak), ott jellemzően ez volt. Ahogy a mi kezünkbe került a dolog, feltártuk a problémákat és letettünk valami tervet arra, hogy miket kéne megcsinálni, valahogy a management hozzáállása is megváltozott a témához. Amint konkrét adatot mutattunk róla, hogy miért esik-kel a szolgáltatás egész nap (amiért egyébként nem kicsit panaszkodtak az ügyfelek és valószínűleg a cégnek kezdett anyagilag is fájni), hirtelen ki tudtuk járni, hogy legyen fejlesztő allokálva a megoldásra. A másik meg az ISO és hasonló auditok. Amikor a cég eléri azt a szintet, hogy muszáj megszerezni a plecsnit, akkor hirtelen fontossá válik, hogy rend legyen az üzemeltetés oldalán. Nyilván egy darabig lehet smoke and mirrors-t játszani az auditor előtt, sok startup csinálja is, de ez nem fenntartható éveken keresztül.

Régóta vágyok én, az androidok mezonkincsére már!

Nem az a kérdés, hogy fel tudom-e paraméterezni a JVM-t, hanem az, hogy jól tudom-e felparaméterezni, milyen irányelveket kapok a fejlesztőktől, tesztelőktől. Pl: 1500 konkurrens userhez milyen memória beállítások kellenek. Ha ezt nem tudja valaki megmondani az üzemeltetőknek, akkor ezt ők honnan találják ki? Nyilván rossz esetben semmilyen érdemi teszt nem készült, ami a rendszer méretezését segíti az üzemeltetőnek. A property fájlok már csak hab a tortán.
Üzemeltetési dokumentációt is jó lenne valakinek prezentálni.... Nem az üzemeltetés feladata az (induló) üzemeltetési dokumentáció elkészítése. Részt vehet benne, tanácsokat adhat a már meglévő alkalmazások és a használat/frissítés alapján.
Tapasztaltam már jó párszor "itt van ez a war/ear/stb., csak deployolni kell és menni fog". Aha, ahogy Móricka elképzeli....

Sokszor az üzleti oldal nem hiszi el, hogy nem az üzemeltető a hibás / felelős. Szerintük a fejlesztők mind tökéletes munkát végeznek. Ez szítja a feszültséget. Ha a program jól fut a fejlesztők gépén, akkor élesben is jól fog menni. Hát nem. Persze tisztelet a kevés kivételnek.

Kisebb cégeknél nagyon nem világos, hogy ki a felelős a KPI-okért, SLA-ért. Cégvezető? CIO? Üzemeltetés? Fejlesztés? Tud menni az egymásra mutogatás és várakozás, amíg ki nem borul a bili annyira (pl: elmegy egy nagy ügyfél, súlyosan leesik a bevétel), ami felébreszti a céget.

Auditok, plecsnik
Voltam már részese pár auditnak (ISO, CC, TÜV, eIDAS)  - politikai befolyással érintettnek is -, ami alapján bátran ki merem jelenteni, hogy nem az üzemeltetéssel szokott lenni a probléma. És nem is a fejlesztéssel. Mindig a fejétől bűzlik a hal. CxO. Ha ők nem akarnak rendszert, folyamatokat, átláthatóságot, követhetőséget, elszámoltathatóságot, minőséget, akkor a kishangyák a végeken fejükön is állhatnak. Majd megunják, belefásulnak vagy elmenekülnek a kishangyák. Jéé, a magas fluktuáció egyik oka.

Szerintem.

Hogy az alaptémához is hozzá tegyek kicsit:
Monitorozni olyasvalamit lehet, amiről tudom, hogy milyen határok között kell mozogni. Más szavakkal: milyen állapotban stabil a rendszer.
Ezt mindig az üzleti oldalnak kell tudnia megmondania előre. Majd utána ezt le lehet fordítani technikai paraméterekre. Amíg az üzlet nem mond semmit, addig piszok nehéz belőni a technikai paramétereket.

Idejétmúlt szemlélet. A megfelelő helyen kell meghúzni a határvonalat, és a "X ember fejlesztett egy JAR-t és átadja Y-nak üzemeltetni" az nem megfelelő. Akkor megy ez jól, ha a fejlesztő(k egy része) ért az üzemeltetéshez és vice versa.

Mi hatalmas infrákat üzemeltetünk, SRE/SWE elkülönülés van néhány csapatban, de néhányban csak SWE van, és számunkra a rendszergazdák/üzemeltetők láthatatlanok. Ők adnak virtuális gépeket, mi meg futtatunk rajta konténereket, sose lépünk egymás lábára.

Csak, hogy értsd a kontextust: a thread indító rantelésből (64giga ramot evő java service), azt nyilván feltételezem, hogy a kollégaúrnak ahhoz azért van elég infója a fejlesztőktől, hogy legalább funkcionálisan képes legyen elindítani a szolgáltatást. Vagyis van egy működő állapota, ami nem optimális. Innentől kezdve, ha tudna mérni és adatot gyűjteni a rendszerről amíg az működik, máris tudna egy jó kezdő közelítést arra, hogy miket állítson be JVM heap paramétereknek. Azért ez egy sokkal konkrétabb szituáció, mint amiről teljesen általánosan írsz. Nem az általános megállapításaiddal vitatkozom.

Tekintve, hogy ráadásul OOM killert emleget, nekem erős a gyanúm, hogy egyáltalán nincs bekorlátozva a heap használat és a JVM esetleg defaultból valami teljesen elszállt limitet választott (régebben konténerekben futtatott java process-ek jellemzően nem tudták megállapítani, hogy mennyi memóriájuk van és addig növelték a heap-et, amíg az oprendszer hard limitjebe bele nem futottak). Simán el tudom képzelni, hogy ha kezdetnek felparaméterezné [amennyi ram van a gépben] / 2-re (a GC átmenetileg szeret valamennyi extra ramot használni a heap limit fölött), akkor hirtelen elkezdene lényegesen kulturáltabban viselkedni a service-e. Az OOM-et biztosan elkerülné. Ettől még kifogyhat a memóriából a JVM, ettől még lehet tényleg memory leak, saját maga házon belül dobhat OutOfMemoryError exceptiont, de erről már lehet heap dumpot készíteni. Innentől máris van valami, amit oda lehet adni a fejlesztőknek.

Aztán, hogy ő most olyan cégben dolgozik-e ahol vevők lesznek erre és a bug reportját odaadják fejlesztőnek, avagy olyanban, ahol "kuss és nyomogasd a restartot" van, az már egy következő kérdés.

Én az ő szavaiból eléggé úgy éreztem, hogy azt képzeli, hogy a fejlesztőknek "illett volna" maguktól rájönni és megtalálni a hibát. Nem kíván ő nekik debuggolni vagy bármi módon segíteni - legalábbis a szóhasználata nagyon erre utal. Persze, illene a fejlesztőknek kiszűrni a hibákat, erre való a tesztelés, csak az olyan tesztelést még nem találták fel, aminek tökéletes a coverage-e és nem csúszik át rajta semmi hiba (biztonságkritikus rendszerek fejlesztői mit meg nem adnának érte...). Ennek híján viszont az ops-osnak igenis meg kell próbálnia együttműködő partnerként viselkednie a fejlesztők fele, próbálni segíteni nekik megfogni a hibákat, ha már prodba kicsúsztak. Kb mindenki jól jár vele.

Nyilván az együttműködés ideális esete, ha a management eleve úgy szervezi a folyamatokat, hogy ez működjön. Ha a management nem szervezi, akkor még mindig meg lehet próbálni alulról építkezve. Hátha bejön. Hátha a management csak nem ismerte fel, hogy ez mennyire szükséges, de ha látják, hogy működik nem állnak az útjába. Aztán, ha az derül ki, hogy a management kifejezetten akadályozza (pl úgy érzi, hogy belezavarsz, lelassítod az ő feature fejlesztési törekvéseit), akkor menni kell onnan. Kb ennyi.

Régóta vágyok én, az androidok mezonkincsére már!

Először is szerencsére ez a jelenség egy korábbi munkahelyemen volt. A jelenleginél tudunk összedolgozni. :)

De:

azt képzeli, hogy a fejlesztőknek "illett volna" maguktól rájönni és megtalálni a hibát

Nem. A fejlesztőnek rendesen kellett volna tesztelni a cuccot, hogy ne élesben bukjanak ki alapvető hibák.

Nem kíván ő nekik debuggolni

Így van.

vagy bármi módon segíteni

Nem igaz. Szívesen segítek, ha tudom mire van szüksége, és nem elrugaszkodott lehetetlenséget kér (pl 4TB RAM :D . Kértek már ilyet tőlem és komolyan gondolta! :D :D :D)

az ops-osnak igenis meg kell próbálnia együttműködő partnerként viselkednie

IGEN!

lehet próbálni alulról építkezve. Hátha bejön.

Sok helyen csak ezért működnek dolgok. :D

"A megoldásra kell koncentrálni nem a problémára."

Nem. A fejlesztőnek rendesen kellett volna tesztelni a cuccot, hogy ne élesben bukjanak ki alapvető hibák.

A fejlesztő rendelkezésére áll egy, az éles környezet karakterisztikáival megfelelő tesztkörnyezet? Élesnek megfelelő terheléssel, élesre jellemző hívási láncokkal, éles környezeti erőforrások mentén? Mert ha nem, akkor ő csak a logikai helyességet tudja tesztelni, a nemfunkcionális (tipikusan: teljesítmény) követelményeket nem.

Illetve kérdés még, hogy ha reprodukálni kell egy éles üzemi teljesítményhibát, az üzemeltetés tud-e adni olyan használati információt az éles üzemből, ami alapján a fejlesztők reprodukálni tudják a hibát. Mert anélkül nagyon nehéz teljesítményhibát javítani, hogy elő tudnánk állítani. Jellemzően nem szoktak tudni adni, mert nincs olyan szintű monitoring és naplózás, amiből a hiba előfordulása körüli rendszerterhelést rekonstruálni lehetne.

Hát... ezt az oomkiller dolgot én is csak kamillázom - azt hittem, hogy lemaradtam valamiről -, hogy egy java appnak minek, amikor van (kiindulásként) az -Xmx... Mondjuk lehet natív dolgokat használó app és azok is szállhatnak el. Azt hogy az üzemeltetés "nyekergését" (látszólag) nem hallgatja meg a fejlesztő az a jellemhibák helyett legtöbbször inkább kapacitás- és pénz hiány. Ez van. :)

Az ops munkaideje is elég drága tud lenni. Tévhit, hogy minden fejlesztő drágább, mint az ops.

Az ops munkaideje is be van osztva. Ha egy X szolgáltatás a munkaidejéből 2% helyett 10%-nyit visz el, akkor az keményen forintosítható. Ilyenkor szokott lenni 2 véglet:
- Minden aprósággal megy az ops az üzlethez, hogy most foglalkozzon ezzel a problémával vagy sem (megéri / nem éri kérdés). Mikromenedzsmenthez vezet, nem hatékony és idegesítő is.
- Házon belül megoldja, elintézi, ahogy tudja. Csak a jövedelmezőbb feladatokra nem marad ideje. A végén meg a szőnyeg szélén kell riportolnia, hogy mit csinált a havi 170 órában. Ez se hatékony és az ops ezután totál kiég, fásult lesz.

Az, hogy a cégnél / projekten nincsenek szeparált környezetek, nincsenek betartva a szoftverfejlesztés és üzemeltetés alapvető szabályai se, az a vezetés / üzlet hibája. Igénytelenek.

Ha egy X szolgáltatás a munkaidejéből 2% helyett 10%-nyit visz el, akkor az keményen forintosítható. Ilyenkor szokott lenni 2 véglet:

Vagy, elengeded a hatredet nyelvek/frameworkök irányába, és odarakod alá azt a plusz erőforrást fillérekért, és marad rengeteg időd szabadon. 

Szerinted minden üzemeltetési szinten megjelenő probléma / incidens megoldható pusztán plusz cpu/ram/disk hozzáadásával? Akkor te egy zseni vagy! Megoldottad a világ összes IT üzemeltetési problémáját! Nobel díjat neked! (szarkazmus)

Az a plusz erőforrás hozzáadása piszkosul nem fillérekbe kerül. Csak pár apróság, amik enterprise környezetben előfordulnak:
- Reboot kellhet hozzá. Jó esetben BAU megcsinálja. Csak change-t kell nyitni, végigmenni a céges processen, beszerezni az approve-okat, change windowt kérni a service manageren keresztül stb.
- Eszközbeszerzést indikál. Ez semmilyen esetben nem megy egyik napról a másikra. Tudod, költséghely, beszerzés jóváhagyása stb.
- CMDB módosítás.
- Monitoring alertek módosítása, ha szükséges.
- Alkalmazás konfigurálás, hogy a plusz erőforrásokat ki tudja használni a rendszer.
- Licencelés változtatás. Ez ordas nagy szívás tud lenni. Pl: CPU-nál OS-hez is kellhet plusz licence, a middleware-hez is kellhet.

KKV és cloud szinten igen, 5 perc alatt odaadom a plusz cpu/ram/disk-t technikailag. De nem csak technikai része van egy erőforrás bővítésnek, hanem adminisztrációs is.
A cloud native dolgokat felejtsük el. Ott nem ekkora gond az erőforrás bővítés/csökkentés. Csak a világ szoftvereinek nagy része nem cloud native. Még.

Szerinted minden üzemeltetési szinten megjelenő probléma / incidens megoldható pusztán plusz cpu/ram/disk hozzáadásával?

Nem, de a legtöbb probléma bizony megoldható ezzel.

Az a plusz erőforrás hozzáadása piszkosul nem fillérekbe kerül. Csak pár apróság, amik enterprise környezetben előfordulnak:

Ezek jelentős része üzleti döntés, amelyeket üzemeltetőként akarsz kezelni. Nem a te dolgod, eszkaláld. Két tétel üzemeltetési feladat, azt csináld, ne sírj.

--

A másik oldal ugyanúgy fel tud sorolni pont ennyi érvet, hogy miért nem 5 perc felére csökkenteni egy szoftver erőforrás igényét. Eszkalálni kell és majd az üzlet eldönti, hogy inkább 16 GB memórát adjanak pluszban vagy szopjon négy szenior fejlesztő heteket-hónapokat azzal, hogy a cég core szolgáltatása 32 GB memória helyett 16 GB memóriával tudja ugyanazt a teljesítményt.

Komolyan, baszki, kimegyek a kínai piacra és a legolcsóbb telefonban is lassan 8 GB memória van, itt meg elvileg egy core szolgáltatás 16 GB plusz memóriaigényén megy a rugózás már két napja. Tudomásul kell venni, hogy 32 GB memória manapság lófasz se. Aki ezt nem képes tudomásul venni, menjen el birkapásztornak.

https://iotguru.cloud

Két tétel üzemeltetési feladat, azt csináld, ne sírj.

Én nem sírok. Inkább röhögök csak - tudod, öreg vagyok (:)). Tudod, amikor egy szervert / szolgáltatást heti/havi szinten kell így tutujgatni, akkor előbb-utóbb kiveri a biztosítékot. Elsőként általában a SDM-nél, másodiknak a change mgmt-nél, harmadiknak az incident/problem mgmt-nél, hogy "Mi a frászkarikáért kell ezt már megint piszkálni? Múlt héten már csináltátok, nem!?"

Kicsiben igen, kimegyek a boltba, veszek RAM-t, beleteszem a gépbe. Öröm és boldogság.
Engem az se zavar, ha 1 TB RAM kell egy adott alkalmazáshoz. Amíg nem az én pénzemből megy az üzlet.

Miért ne lehetnék tulajdonos, befektető is a vállalkozásban?

Lehetsz, de igen kevéssé hiszem... :)

Netalán prémiumon keresztül érdekelt lehetek?

Akkor nem kardoskodnál ennyire, hogy igenis oldja meg a fejlesztési terület, hogy kevesebb memóriát használjon a szoftverük, kerül-amibe-kerül, mert erőteljesen csökkenne a prémiumod. Túlságosan csak az üzemeltetés oldaláról nézed a dolgokat.

https://iotguru.cloud

itt meg elvileg egy core szolgáltatás 16 GB plusz memóriaigényén megy a rugózás

Nem egy szolgáltatáson, hanem az összesen. Ha minden fejlesztő minden projektjére nyakló nélkül öntöm a hardware-t, vigyázva a fejlesztő agyára nehogy elhasználja, akkor a vezetés engem állít majd falhoz, hogy miért igenyeltem köbméternyi ECC RAM-ot csilliárdokért.

A felesztő a saját projektjét látja csak? Mert akkor értem miért nem jelent semmit pát giga RAM. De több fejlesztő van. Sokuknak több projektjük is van. És még ki kell szolgálni a levelezést, ticketinget, ftp-t, meg csomó olyan szolgáltatást, amit a fejlesztő is használ. Csak észre sem veszi mert működik. Mert valakik működtetik. Abból az erőforrásból ami néhány fejlesztő szerint végtelen mennyiségben van, ingyen.

"A megoldásra kell koncentrálni nem a problémára."

Nem egy szolgáltatáson, hanem az összesen. Ha minden fejlesztő minden projektjére nyakló nélkül öntöm a hardware-t, vigyázva a fejlesztő agyára nehogy elhasználja, akkor a vezetés engem állít majd falhoz, hogy miért igenyeltem köbméternyi ECC RAM-ot csilliárdokért.

Tied a cég? Ha nem, akkor nem te öntöd rá a köbméter ECC RAM-ot csilliárdokért, hanem a cég. És a cég eldönti, hogy inkább vesz csilliárdokért ECC RAM-ot vagy vesz csilliárdokért fejlesztői kapacitást, hogy az üzemeltetésnek jó legyen.

Amúgy konkretizáljuk már: mennyi RAM-ról beszélünk és mekkora cégről?

https://iotguru.cloud

Mondd, tulajdonosi, gondos (rendszer)gazda szemléletről hallottál már? Kicsi cégeknél sokszor elvárás szokott lenni.

Az a szemlélet nem arról szól, hogy a tulajdonos üzleti döntései felől közelítsd meg a cég működését, hanem arról, hogy a rád bízott dolgokra úgy vigyázz, mintha a tied lenne. Nem azt jelenti, hogy úgy őrizd a raktárban vagy a gépekben az oda nem adott memóriát, mint Smaug az aranyat és drágaköveket, hanem azt, hogy ha a cég működéséhez szükséges, akkor zokszó és panasz nélkül aláteszed a rendszereknek, mert tudod, hogy abból lesz jövő hónapban is fizetésed, ha működnek a dolgok.

https://iotguru.cloud

odarakod alá azt a plusz erőforrást fillérekért, és marad rengeteg időd szabadon

Amúgy igen sok üzemeltetővel találkoztam, akiknek kb. fájt, ha használták a rendszert és időnként 5-10-15 évvel múltban éltek CPU/memória igény kapcsán, olyan dolgokon rugózva, hogy miért nem elég x CPU és y GB memória, minek kell a cuccnak 4x CPU és 4y GB memória, mint amennyire az adott üzemeltető _gondol_, hogy elég kellene legyen. Nem elég.

https://iotguru.cloud

Valószínűleg onnan eredeztethető az üzemeltetők nyavalygása, hogy jobb helyeken mindennek van költséghelye (cost center). Ez minden cégen belül használt alkalmazásra, eszközre is igaz.
Na most ha van a cégben egy általánosan, mindenki által használt rendszer (pl: levelezés, intranet, célszoftver stb.), akkor pár helyen szeretik ezt ráterhelni az üzemeltetésre, mint költséghelyre. Ergo a kimutatásokban az fog szerepelni, hogy milyen drága az üzemeltetés, mennyire viszi az erőforrásokat. Aztán ezt amikor elmagyarázzák a CFO-nak, akkor vagy megérti vagy sem. Jó esetben elindul egy reform, ami általában gyorsan el is hal - túl sok mindent kell hozzá átalakítani.
Sajnos láttam már pár ilyen helyet.

Elég más elképzeléseink vannak a jobb helyekről, de: szerintem az biztosan nem tartozik ide, ahol ilyen gyüjtőkategóriák léteznek cost centerként, mint üzemeltetés, függetlenül az általuk szállított terméktől.

Kb mintha az irodatakarítás egy olyan dolog lenne, ami csak viszi a pénzt, de a cégvezetés elfelejti, hogy egy szemétdobon se munkaerő, se ügyfél nem lesz.

Szerverszoba klímát, annak fenntartását, áramfogyasztását melyik költséghelyre tudod betenni? Kétlem, hogy BTU / áramfogyasztás alapon elkezded szétosztani eszközökre és az eszközök által futtatott alkalmazások alapján arányosítani.

Az irodatakarítás is bekerül egy költséghelyre. Pénzügyön múlik, hogy ezt hová szeretné számolni.

Szerverszoba klímát, annak fenntartását, áramfogyasztását melyik költséghelyre tudod betenni?

Itt jonne be a fent megidezett tulajdonosi szemlelet, amikor az IT megmondja, mennyibe kerul uzemeltetni valamit, es azt vissza lehet osztani a user oldali CC-kre. Valamit az accountok szama szerint, valamit az eszkozok szerint, stb. Mintha berelnel valamit a felhoben, ott sem az aramot fizeted, meg a klimat, hanem van az eroforrasnak egy ara, azt fogjak kiszamlazni.

Szerinted a konyhai kavekapszulat hova koltsegelik el? Szamoljak, hogy ki mennyit iszik? :) Vagy fogjak az iroda teljes koltseget, es a facilities visszaosztja per fo a megfelelo koltseghelyekre.

mert te világéletedben csak ott jártál...

ROTFLMAO. :D :D :D

Semmi gond, ha még neked sose kellett foglalkozni a költséghelyekkel. Tudom, fejlesztőként nem ez a dolgod. Csak ne írj olyat, hogy "Egyrészt jobb helyeken nem így működnek a dolgok", mert láthatóan nem értesz hozzá, sose találkoztál ezzel.
Egyszer beszélj a pénzügyi vezetővel, hogy nálatok hogyan működnek ezek a folyamatok, elszámolások.

Semmi gond, ha még neked sose kellett foglalkozni a költséghelyekkel.

ROTFLMAO. :D :D :D

Tudom, fejlesztőként nem ez a dolgod.

Több mint 10 éve nem fejlesztőként dolgozom, hanem architect pozícióban, több pár milliárdos projekt is "átment" már rajtam, CAPEX és OPEX költségek tervezésével is... ezen túl sose volt távol tőlem az üzemeltetés, az utóbbi időben site reliability engineer, cloud engineer és platform engineer szerepkörben is szoktam jelen lenni cégeknél, és messziről megérzem, amikor az üzemeltetés nettó faszásgokra hivatkozik, mint te is.

Csak ne írj olyat, hogy "Egyrészt jobb helyeken nem így működnek a dolgok", mert láthatóan nem értesz hozzá, sose találkoztál ezzel.

Különb dolgokkal is találkoztam, és?

Egyszer beszélj a pénzügyi vezetővel, hogy nálatok hogyan működnek ezek a folyamatok, elszámolások.

Nálam nincs olyan, hogy "nálatok". Szakértőként és konzultánsként dolgozom egy ideje, a legultolsó "nálunk" esetén se úgy ment, ahogy leírtad. Amit leírtál, az a rosszul működő cégek sajátossága és ez a rossz működés amúgy sejthető abból, ahogy és amit írsz a munkádról.

https://iotguru.cloud

Na most ha van a cégben egy általánosan, mindenki által használt rendszer (pl: levelezés, intranet, célszoftver stb.), akkor pár helyen szeretik ezt ráterhelni az üzemeltetésre, mint költséghelyre.

De akkor (tipikus XY problema) nem az a gond, hogy az levelezesnek mennyi RAM kell, hanem hogy a CFO es a brigadja, elen a kontrollinggal hasznavehetetlen, mert az egyetlen feladatukat (budgeting) sem tudjak megcsinalni. Azert nem olyan nagy kunszt visszaosztani az alap infra koltsegeit a cost centerekre, ha mas nem, akkor az accountok szama alapjan. Lenne ennel kifinomultabb modszer is, de igy megcsinalni fel napos melo, es egy kozepiskolasnak is menne.

Így van. Nem Az üzemeltetés, meg a takarítás stb. az én értelmezésem szerint nem költséghely olyan költségeknél, amik másokra vonatkoznak. Azok olyan költséget jelentenek, amelyet valamelyik más, cégen belüli aktivitás indukál - azok a költségek generálói, a költséghelyek. Ha azok az aktivitások nem lennének, akkor kevesebb IT, takarítás stb. költség lenne.

Az IT mint költséghely olyan aktivitásoknál értelmezhető, minthogy el kell küldeni tanfolyamra az üzemeltetőt, meg kell újítani a certjeiket, kell nekik is munkalaptopot venni, kell nekik is parkolóhelyet venni, kell  kell számukra is irodát biztosítani. És ez akkor is így van, ha az IT-nek 0, vagy 100 szervert kell üzemeltetnie.

Ugyanígy, a felhasználói licencköltségek sem az IT-t kéne, hogy terheljék. Ha mondjuk a sales üzletág felvesz 10 embert, és 10-zel több Office 365 licenc kell, akkor azt a sales üzletzág gazdálkodja ki magának, az az ő költsége. Nyilván a sales üzletágnak meg nem kell Visual Studio Enterprise subscription, az nem az ő költségük, de nem is az üzemeltetésé.

Ugyanúgy, az, hogy ők másoknak szolgáltatnak valamit, az nem az ő költséghelyükre tartozik, hanem annak a másnak, akiknek szolgáltat. Akkor is, ha az éppen azt egész cég számára szolgáltatás (pl. munkaidő-nyilvántartás, és hasonló HR szoftverek). A projektjeink tesztkörnyezeteit, szervereit is a projektekhez számoljuk el, nem az IT költségvetésébe. Ugyanis ha nem lenne projekt, ez a költség se lenne.

Ha egy X szolgáltatás a munkaidejéből 2% helyett 10%-nyit visz el, akkor az keményen forintosítható.

Látod, csak visszaérünk oda, hogy ez az egész szimplán üzleti döntés. Ha megéri a cégnek azt a +8% időt kifizetni, akkor ki fogják fizetni. Ha nem éri meg, akkor változtatnak rajta. Teljesen felesleges nyígni ezek miatt és egymásra mutogatni, hogy a lusta fejlesztő miért nem oldja meg, ugyanúgy be van osztva a munkaideje.

https://iotguru.cloud

Csak mint döntés-előkészítő, fel kell tudni vázolni az üzletnek, hogy minek milyen vonzata van/lehet.

Itt nem erről van szó, onnan indultunk, hogy "a java foshalom mindaddig állni fog, amíg a fejlesztő nem jut megegyezésre az oomkillerrel". Mindezt azért, mert az üzemeltetés nem eszkalál, hanem úgy dönt, saját határkörben, hogy nem kap annyi memóriát az adott szolgáltatás, amennyire szüksége van.

Az a +8% valahonnan hiányozni fog. Ha ezt kimozogja a cég, akkor oké.

Miért, a fejlesztésnél nem fog hiányozni?

https://iotguru.cloud

Eszkalálni meg kell tanulni. Sok ember nem képes rá emberileg. És ez IT-tól teljesen független.

Miért, a fejlesztésnél nem fog hiányozni?

Itt lehet oda-vissza pattogtatni, hogy kinek fontosabb a +8%. Lehet, hogy ez az üzemeltetésen +8%, fejlesztésen meg csak +5%. Helyzetfüggő.

Láttam már olyat is, hogy a fejlesztőt is személyesen zavarta a hiba (lassú memória zabálás). Üzlet nem tartotta fontosnak. Fejlesztő megcsinálta fusiban 2-3 óra időbefektetéssel - amúgy is azt a részét piszkálta a kódnak és ment ki új release. A fejlesztő idejébe is belefért ez az apróság. Mindenki boldog volt.
Szóval nem minden memória szivárgáshoz kell 2-3 emberhónapnyi munka. Lehet több és kevesebb is.

Eszkalálni meg kell tanulni. Sok ember nem képes rá emberileg. És ez IT-tól teljesen független.

És?

Itt lehet oda-vissza pattogtatni, hogy kinek fontosabb a +8%. Lehet, hogy ez az üzemeltetésen +8%, fejlesztésen meg csak +5%. Helyzetfüggő.

Bocsánat, de a téma, amin rugózunk (vagyis faszé' kell ennek a szarnak 16 GB, miért nem elég 8 GB vagy faszé' kell hozzá írni script, ami újraindítja), az általában úgy néz ki, hogy üzemeltetésen egyszeri x forint vagy egyszeri ~2 óra, fejlesztésen meg egyszeri ~200 óra.

Nagyon-nagyon-nagyon ritka az a helyzet, amikor ténylegesen a megéri a fejlesztésnek durván optimalizálnia a szoftverét, mert szinte 99+ százalékban olcsóbb alátenni több erőforrást és/vagy időnként újraindítani. Ez egy ilyen világ, sírhatsz, hogy 40 éve elég volt 64 kB memória és most miért kell 64 GB, de teljesen felesleges.

Alapíts egy céget, ahol olyan fejlesztőket veszel fel, akik memóriatakarékosan dolgoznak és olyan üzemeltetőket, akiknél a fő szempont az, hogy minél kevesebb erőforrásra legyen szükség. Aztán menj csődbe gyorsan.

Üzlet nem tartotta fontosnak. Fejlesztő megcsinálta fusiban 2-3 óra időbefektetéssel - amúgy s azt a részét piszkálta a kódnak és ment ki új release. A fejlesztő idejébe is belefért ez az apróság. Mindenki boldog volt.

Ez a ritka eset. Java esetén tipikusan nagyon durva rendszeridegen dolgokat kell tenni ahhoz, hogy memleak jöjjön létre, ha az adott framework keretein belül maradsz, akkor gyakorlatilag nem tudsz memleak-et okozni.

https://iotguru.cloud

Köszönöm, van vállalkozásom.

One man show?

Nem mentem csődbe még.

Szerintem nem is úgy dolgozol, ahogy leírod. Ha ügyfélnek szolgáltatnál úgy, hogy minden apró szar faszságot kiadnál a fejlesztőidnek megjavításra, mert pár éve tized annyi memória is elég volt, akkor bizony csődbe mennél.

https://iotguru.cloud

az üzemeltetés nem eszkalál, hanem úgy dönt, saját határkörben, hogy nem kap annyi memóriát az adott szolgáltatás, amennyire szüksége van.

De hát nincs hatásköre dönteni. Saját magadnak is ellentmondasz:

nem te öntöd rá a köbméter ECC RAM-ot csilliárdokért, hanem a cég

Így van, az üzemeltetés addig nem ad, amíg nem engedik meg neki, hogy adjon. Hiszen nem a sajátjából ad -- nincs is neki sajátja. (Ennek megfelelően pedig nem az üzemeltetés baszkodja a filléreket, hanem aki az adásról, ill. nem adásról dönt.)

Tévhit, hogy minden fejlesztő drágább, mint az ops.

Szerintem nem annyira tévhit, talán a "minden" szócska hibádzik kicsit.
De ha már a fejlesztő ideje ennyire drága, mint amennyire az itt jelen lévő fejlesztők is hivatkoznak rá, akkor igenis elvárható, hogy azért a pénzért őfelsőbbrendűsége gondolkodjék is.

Mert ha a korábbi példánál maradva két integer összeadása a cél, akkor ahhoz nem a bazinagy felsőbb matematikai tudományos libet érdemes választani, hanem egy kissebb egyszerűt (bármely OOP esetén, nem szorítva java-ra a kérdést). Ez olyan nagy kérés?

"A megoldásra kell koncentrálni nem a problémára."

De ha már a fejlesztő ideje ennyire drága, mint amennyire az itt jelen lévő fejlesztők is hivatkoznak rá, akkor igenis elvárható, hogy azért a pénzért őfelsőbbrendűsége gondolkodjék is.

Szoktak gondolkodni. Amire te gondolsz, az vélhetően az, hogy mindent találjanak ki és implementáljanak házon belül, ne legyen se framework, se library, se egyéb használva, mert ezzel talán meg lehet spórolni valamennyi hardvert.

Mert ha a korábbi példánál maradva két integer összeadása a cél, akkor ahhoz nem a bazinagy felsőbb matematikai tudományos libet érdemes választani, hanem egy kissebb egyszerűt (bármely OOP esetén, nem szorítva java-ra a kérdést). Ez olyan nagy kérés?

Mondj már konkrét és megtörtént példát a való életből, mert ez így ebben a formában még sarkítva is faszság.

https://iotguru.cloud

Amint konkrét adatot mutattunk róla, hogy miért esik-kel a szolgáltatás egész nap (amiért egyébként nem kicsit panaszkodtak az ügyfelek és valószínűleg a cégnek kezdett anyagilag is fájni), hirtelen ki tudtuk járni, hogy legyen fejlesztő allokálva a megoldásra.

+1, amit meg kellene erteni fejlesztoknek es uzemeltetoknek is, hogy az uzletet a penz erdekli, nem az, hogy hany ticket van. Ha ez magatol nem megy, akkor kell egy ember a ket vilag koze, aki fordit, de ket dolog minden tickethez szukseges:

  1. mennyibe kerul megcsinalni
  2. mennyibe kerul nem megcsinalni

Amig ezt a kettot nem ismerjuk, addig felesleges dolgozni rajta.

Lazán kapcsolódik: Van olyan gyár, ahol az üzemcsarnokban papíron adminisztrálnak, majd a papírokat néhány olcsón fizetett adminisztrátor rögzítik elektronikus rendszerbe, utólag.

Annyiba kerülne megcsinálni azt, hogy legyen on-line, azonnali adminisztráció, akár tabletekkel (amik kibírják az üzemcsarnok hőmérséklet, pára stb. tulajdonságait), akár érintőkijelzőkkel, hozzá illeszteni a hálózatot (akár Wifi, 5G, vagy Ethernet), meg mögé rakni a szoftvert, ami felhasználóbarát és interfészel az ERP-vel, hogy a megtérülési költsége 10 év körül lenne. Senki neki sem áll emiatt ezt megcsinálni.

Oh, erről most eszembe jutott korán megboldogult :(((((, programozó vénával rendelkező villamosmérnök jóbarátom, aki valami hasonló problémára (teszterek adatgyűjtése) barkácsolt a cégénél a "szabad" idejében webes felületet TCL-ben, aztán Python-ban. Működött. :)

  1. mennyibe kerul megcsinalni
  2. mennyibe kerul nem megcsinalni

Jogos, de van egy hiba benne: a fejlesztő meg tudja mondani mennyi munkaóra megcsinálni, a bérével számolva ez forintra pontosan megvan.

Azt viszont kinek a dolga/képessége kiszámolni, hogy a nem megcsinálásból mekkora kár fog származni rövid/közép/hosszútávon ügyfélvesztéssel, HW-el, ops órával? Forintra pontosan!

Itt jön az, hogy az első egy konkrét szám, amit sokallanak a vezetők (és gyorsan adnak is egy puszit a fejlesztésnek hogy "nem a te hibád!"), a másodikra tippelni sem lehet, és gyorsan eldől, hogy az ops öntse a RAM-ot, és restartolgasson.

"A megoldásra kell koncentrálni nem a problémára."

Jogos, de van egy hiba benne: a fejlesztő meg tudja mondani mennyi munkaóra megcsinálni, a bérével számolva ez forintra pontosan megvan.

A hibakeresős és optimalizálós munkák esetén a fejlesztő bizony nem tudja megmondani, hogy mennyi munkaóra megcsinálni. Egy hiba megtalálása önmagában lehet 1 óra és 100 óra is, mert általában nem tudod, mi okozza, főleg, ha tesztkörnyezeten nem is jön elő vagy nem sikerül reprodukálni és éles környezetből kell valahogy közvetetten kikövetkeztetni, hogy mi okozza. Ezt követi az, hogy ki kell javítani, viszont a hibákat többnyire a framework vagy valamelyik library okozza, amit frissíteni kellene, és jó esetben a frissítés csak egy komplett validációs tesztet von maga után, rossz esetben hozzá kell nyúlni a forráskódokhoz, ami üzleti funkcionalitást érint, tehát komplett üzleti teszteket is le kell tolni, még rosszabb esetben úgy, hogy a tesztrendszeren ugye nem volt reprodukálható a hiba, tehát élesben fog kiderülni, hogy megoldotta-e a problémát. Mindebből ez egyszeri üzemeltető annyit lát, hogy a fejlesztőnek nincs öt perce, hogy megoldja, pedig a problémával az üzemeltetést leszámítva kb. a teljes IT területnek dolga van.

Ehhez hozzájön, hogy az üzlet ott áll tengernyi ötlettel, amelyeket le kellene fejleszteni, hogy még több pénzt tudjon keresni és a legutolsó dolog, amire vágynak, az az, hogy az IT kompletten megáll pár hétre, hogy valami marginális faszságon javítsanak, hogy a szolgáltatás kevesebb memóriát igényeljen, mint amennyi a CFO egy éves telefonjában van. Nem is igazán tudod elmondani a CFO-nak, hogy mi a faszé' nem teszel inkább oda több memóriát, ha az megoldja a problémát.

Azt viszont kinek a dolga/képessége kiszámolni, hogy a nem megcsinálásból mekkora kár fog származni rövid/közép/hosszútávon ügyfélvesztéssel, HW-el, ops órával? Forintra pontosan!

Az üzemeltetés általában pontosabban meg tudja mondani (feltéve, ha rendesen mérnek), hogy mennyi plusz erőforrást kell a rendszer alá tenni, hogy a vállalt SLA tartható legyen, ami általában pontosan forintosítható. Én elhiszem, hogy frusztráló dolog, de tényleg az a helyzet, hogy a hardver olcsó: konkétan a három hobbiprojektem alatt több erőforrás van (36 CPU, 128 GB RAM és 2,5 TB storage), mint egy-egy 50-100 fős cég core szolgáltatása alatt, mert az ottani üzemeltetés minden egyes fillért külön-külön meg akar baszni. És nem fizetek csilliókat érte, viszont nem vagyok annyira hülye, hogy pénzt hozó szolgáltatások fejlesztése helyett azon motorozzak, hogy legyen elég 64 GB RAM, mert ez ~60 dollár megtakarítás lenne havonta, ami egy-másfél mérnökóra.

Meg kellene érteni, hogy az üzleti felfogás nem az, hogy kevés költségből legyen megoldva, hanem az, hogy a hónap végén a profit magasabb legyen, mint az előző hónapban.

https://iotguru.cloud

Az SLA mindkettőnk SLA-ja. Te felelsz a java processed SLA-jáért, én pedig az OS SLA-jáért.

Itt kezdődik az, hogy kooperálnunk kell. Nem szeretetből, hanem üzembiztosságból, és üzleti érdekből.

Én nem mondhatom neked, hogy 2048MB RAM a jussod, és azzal kell működnöd. Te pedig nem mondhatod, hogy 4TB RAM alatt nem tudsz működni.

Ezt kompromisszumnak hívják. De ahhoz mindenkinek le kell szállni a magas lóról. ;)

"A megoldásra kell koncentrálni nem a problémára."

Ha a kettő fényévekre van egymástól, akkor eszkalálnunk kell. De ha csak annyi kell, hogy te kicsit többet gondolkodsz, én meg kicsit másként tervezem az erőforrás-allokációt, akkor még működhet is. 

Feltéve, hogy lecseréljük a magas lovainkat pónikra... :D

"A megoldásra kell koncentrálni nem a problémára."

Az SLA mindkettőnk SLA-ja. Te felelsz a java processed SLA-jáért, én pedig az OS SLA-jáért.

Lehet, hogy meglepő dolgot mondok, de mind a kettő SLA az üzemeltetés felelőssége.

Itt kezdődik az, hogy kooperálnunk kell. Nem szeretetből, hanem üzembiztosságból, és üzleti érdekből.

Szerintem te nem érted, hogy mi az üzemeltetés dolga és az üzemeltetés egy részfeladatát gondolod annak.

Én nem mondhatom neked, hogy 2048MB RAM a jussod, és azzal kell működnöd. Te pedig nem mondhatod, hogy 4TB RAM alatt nem tudsz működni.

Ha a fejlesztés azt mondja, hogy 4 TB RAM kell, akkor az üzemeltetés kap 4 TB RAM-ot, hogy tegye a szolgáltatás alá.

Ezt kompromisszumnak hívják. De ahhoz mindenkinek le kell szállni a magas lóról. ;)

Szerintem azzal kellene kezdeni, hogy elkezded megérteni, hogy hol van az IT-n belül a Dev és az Ops határa és miért ott van. Mert a jelek szerint halvány segédkiegészítő pótfogalmad nincs erről.

https://iotguru.cloud

Szerintem te nem érted, hogy mi az üzemeltetés dolga és az üzemeltetés egy részfeladatát gondolod annak.

Szerintem pedig te nem érted. De úgy látom ebben sosem fogunk dűlőre jutni.

Nem sikerült leszállnod a ki...ott magas lovadról. Pedig én próbáltam nyitni.

Sajnos véget ért a meddő beszélgetésünk. Mert részedről meddő...

Bye

"A megoldásra kell koncentrálni nem a problémára."

Szerintem pedig te nem érted. De úgy látom ebben sosem fogunk dűlőre jutni.

Szerintem olvass több ITIL, ITSM, ITAM, TOGAF és egyéb szakmai anyagot, ha hozzáférsz, akkor ISO 20000 is olvasandó, mert ha röhögés nélkül le tudod írni, hogy "Te felelsz a java processed SLA-jáért, én pedig az OS SLA-jáért.", azt azt jelenti, hogy tényleg halvány fogalmad nincs arról, hogy mi az üzemeltetés feladata...

Pedig én próbáltam nyitni.

Ja, leírsz valami alap nélküli faszságot, amit el kellene hinni, aztán az a nyitás. :D

https://iotguru.cloud

Egy fenét. Az ügyelet dolga, hogy ha megdöglik valami, akkor azt életre keltse, hogy ne álljon a szolgáltatás, szép magyarul, hogy kezelje az incidenst. A problémát, ha van, majd megoldjuk tiszta fejjel, munkaidőben, a normális processzeink mentén.

Igazából ha nap közben döglik meg valami, akkor "normális*" helyen akkor is azzal kezd az ember, hogy feléleszti, aztán már ha megy, majd csinál RCAt, meg kitalálja, hogyan kell megoldani a problémát (amit egyáltalán nem is biztos, hogy annak kell, aki újraindította).

Tanult kollégát idézve (ITIL tanfolyamon oktatáson hangzott el :): az üzemeltetés dolga, hogy ha kell, a fülénél fogva porban húzva üzemelő állapotra hozza a cuccot.

*Valójában normális helyen ma már leginkább lehet nézegetni, ha megdöglött egy, mert nem okoz nagy bajt (illetve, hát csak lehetne, mert többnyire gondolkozás nélkül basz az automata oda egy másikat). De hát ez az "ideális" világ nem annyira létezik, olyan, mint a gyökkető, közelíteni lehet :)

Egy fenét. Az ügyelet dolga, hogy ha megdöglik valami, akkor azt életre keltse, hogy ne álljon a szolgáltatás, szép magyarul, hogy kezelje az incidenst.

Így van. De ha ezt automatizálod, akkor megkövesítetted a problémát, és rögzítetted a leszarás tényét. :)

"A megoldásra kell koncentrálni nem a problémára."

Vagy, várok a javításra. Vagy workaroundot csinálok. Vagy minimalizálom az incidensek idejét egy plusz üzembiztonsági réteg beépítésével, amíg meg nem oldódik a probléma. Vagy rájövök, hogy így tulajdonképpen belefér, és csináltatok az emberekkel valami hasznosabbat. vagy....

( joco01 v | 2023. 10. 11., sze – 17:37 )

Szerkesztve: 2023. 10. 11., sze – 17:37

K8S liveness probe (nem üzemeltetek olyan cuccot, amiből csak egy fut, és egyedileg kellene vigyázni rá)