Mi az, amit semmiképp nem hagynál ki a céges rendszergazdai irányelvekből?

Fórumok

Ha céges irányelveket kellene kialakítani a rendszergazdáknak, mik azok az irányelvek, amiket semmiképp nem hagynál ki?

Hozzászólások

"A fejleszto supportalasa nem nyug, hanem kotelesseg"

A fejlesztonek a sysadminnal egyuttmukodni nem opcio, hanem kotelesseg.
A fejlesztonek nincs root acc.
A fejlesztonek nincs prod acc., nem ott kell reszelni a kodot.
A fejlesztonek nincs modja beleszolni uzemeltetesi kerdesekbe, pl. nem mond olyat hogy ne legyen log rotation, mert neki ugy kenyelmesebb.
A fejleszto nem piszkalja az infrat.
A fejleszto idoben szol, ha kell neki valami (Pl. penteken 15:57, tudnal maradni par orat? Tesztelunk.)
A fejleszto elfogadja ha a vacak kodja miatt pampogsz, mert ha outage / barmi van miatta, az uzemeltetes sziv vele.
A fejleszto elfogadja, hogy nem mindent erobol kell megoldani (memory leak pl.)

Ugy tunik mindket oldal sorolhatna napestig :)

echo crash > /dev/kmem

Pedig sajnos rendszeresen beleszólás jön és nem arról van szó, hogy leültünk, egyeztettünk és visszautasítok bármilyen a "szent adminisztrátori elvek"-re hivatkozva mindent. Becsöppen a kedves fejlesztő a projektbe, hogy mennyire nem volt doksijuk, arról csak tippjeim vannak, aztán minden kutyafülére beszól, miközben többször világosan leírtam, hogy mi és hogy van és hogy ezek az előző fejlesztők kifejezett kérései voltak vagy egyeztettük és ez lett. Az külön csodálatos, amikor összevissza követel szoftver telepítést vagy update-et, majd tök mást kezd használni, mert "más utakra mentünk", közben pedig ott tartunk, hogy akkor annak kéne működnie. Valóban együtt kéne dolgozni, de mindkét oldalnak. Sajnos egyáltalán nem egyedi eset és persze minden azonnal tegnapra készüljön el, mert az 5 perc. Aztán amit ő tud 5 perces megoldást, az rendre beborítja az éles rendszert vagy csak többórás javítást igényel, természetesen munkaidőn kívül, hiszen akkor működnie kell. Az a szomorú, hogy más helyett is tudtam válaszolni.

Ott a pont. A végső kód kiadása előtt leülni és specifikalni, és igenis az üzemeltetés fontos szempont. A projektnek része kell az üzemi dolgoknak is lenni és vezetői szinten is, azaz az üzem oldali managernek képviselnie kellene a területe érdekeit. Na ez szokott hiányozni, amikor beesik a sz@r kód az ajtón éles üzemben. 

PROD-ért az üzemeltető (sysadmin) a felelős, ezért vannak jogköri szabályok (ahogy chx is írta):

Dev-nek nincs root acc. Olyan nincs hogy kódban bármit változtasson.  Ami TEST-ről és UAT-ról nem került le és nincs a tesztelők által jóváhagyva az úgyse  kerülhet fel.

Persze hiba kereséshez megkapja a logokat és összedolgozunk.

Munkaszervezés és vállalti kultúra, hogy a túlmunkát hogy kezelik le:

Projekt határidőknél vagy új release -nél ügyeleti rend kialakítása , váltott műszak stb..

For Whites Only meeting room!

Fordítsuk meg egy kicsit...

  • A fejlesztőnek adni kell sandboxot, ahol tud tesztelni és te is megnézheted, hogy minden a te szád íze szerint van beállítva
  • Élesítés előtt/fejlesztés közben együtt menjetek végig a fejlesztett cucc paraméterein, mire van szüksége, mire nem, hogy befejezze azt a toolt és neked se legyen szenvedés később
  • A céges policy-kat érdemes példával is szemléltetni, akár doksiban. Sok fejlesztő nem fogja tudni, hogy A-B rendszer nálatok hogy működik. Nem felelőssége, nem kötelessége ezt tudnia, neked kell megfogni a kezét és megmondani neki, hogy ehhez azt keresd ott és nem lesz gond.
  • Ha dolgozott már nálatok fejlesztő csapat akkor meséljétek el nekik, hogy velük mit hogyan oldottatok meg, mit lehetne másképp.
  • Persze a fejlesztő is adjon egy listát miket kell használnia a projekt megvalósításához, ezt össze kell egyeztetnie az IT-val. A legtöbbször azért kérnek admint, mert nem tud egy sima gitet feltenni, mert nincs a céges repóban, pedig van céges git szerver...

Nálunk szerencsére nagyon rendes(ek) az IT csapat(ok), tényleg jó velük dolgozni. Persze le is ültünk velük minden alkalommal, hogy ne lépjünk a tyúkszemükre, cserébe ők is normálisak velünk, betartjuk a játékszabályokat, nincs mutyi. A fentiekben kaptunk segítséget és nincs is semmi gond...

Szóval azért ezt meg lehet ezt oldani, ha normálisan, emberként állunk egymáshoz és nem egy ilyen kőbe vésett tízparancsolattal, mint amit leírtál...

Nah, ezt is kiadtam magamból... de nagyon egyoldalúnak éreztem a témát...

A fejlesztő lehet egy külső cég/alvállalkozó is minek adjak neki sandboxot ?

Én "átveszem" a kódot pontosabban VPN-en keresztül a feltölti a git-re a fejlesztő és átadja a release notes -ot abban minden beállítandó paraméter benne van. A kódhoz hozzá vannak csapva egyéb szkriptek pl. sql

Én "lebuildelem" és felrakom a saját tesz környezetünkre, amit a saját tesztelőink átnéznek.

Ha rendben van, akkor mehet az UAT-ra - ott a megrendelő nézi át szintén VPN-n hozzáféréssel.

És ha az is OK, akkor az előre meghatározott időablakban mehet a PROD-ra.

Szóval a fejlesztők nem férnek hozzá. Ha gond van "nálunk ment" nálatok miért nem szitu van, akkor logokat, konfigokat (jelszavak nélkül) és adatbázis dump-ot (anonimizálva) adok át. A következő lépés, amikor képernyő megosztással - közösen keressük a hibát..

Persze a fenti dolog akkor működik, hogy pontos relase notes-ot kapunk, sok idő telt el, mire a külsős vagy a belsős fejlesztők le tudtak tenni olyat, hogy az alapján meg lehetett csinálni a telepítést. Mindig kimaradt egy lépés, akkor még a tesz telepítésre kellett infó - és bekerült pótlólag a release notes-ba.

A rendszert meg az elején architect dolgozta ki - megrendelő igényei/lehetőségek/best practice alapján. Későbbi módosítást is csak az ő írásos engedélyével..

For Whites Only meeting room!

" Én "lebuildelem" és felrakom a saját tesz környezetünkre, amit a saját tesztelőink átnéznek. "

Ebben a mondatban csak 3 probléma van:
- kézzel "buildeled"
- kézzel rakod fel
- és, hogy azt sugallja az egész, hogy automatizált teszt sincs. (Nyilván nem helyettesíti azt, hogy egy humanoid is ránézzen.)

" az alapján meg lehetett csinálni a telepítést. "

Mármint úgy érted, hogy azt az egy gombnyomást, ami valamilyen deployment toolban kell megtenni.

Bocs nem voltam pontos és részletes - nem volt célom egy step by step leírás a munkámról.

Csak arra reflektált a az írásom, hogy a fejlesztőnek nincs dolga UAT - PROD környezeten..

Nem irigység vagy önzés miatt csak - igenis el kell különülnie a fejlesztésnek és az üzemeltetésnek.. (CISO nem is adna engedélyt..)

És ha gond van nekem kell megoldani - ezt várják el tőlem - persze lehet igénybe venni fejlesztői támogatást, sőt

nagyobb release deploynál van kijelölt online támogató  - hallom hogy fogja vissza lélegzetét a fülesemben amikor indul az

alkalmazás és szakad fel a levegő vétel, ha hiba nélkül elindul... -  na ez kellően drámai volt :-)

A fejlesztők  is tesztelik saját teszt adatbázissal.

Nekem a Jenkins buildel automatán - és abban is vannak tesztek.

A teszt csapat több napig (Sopui stb.) Van teljesítmény tesztelés nagyobb változások után. És külső cég auditálja a rendszert

átadáskor és majd évente..

Vannak telepítő saját szkriptjeim, használunk ansible-t stb..

DE tényleg van olyan projekt, ami még most kezdődött, hogy majdnem mindent kézzel csinálok..

igen, kézzel buildelem - összerakom a buildelő jobot és kézzel scp-zem fel a war file-t .

For Whites Only meeting room!

Szerencsére ez a fajta lekezelő, beképzelt "én vagyok az admin, mindenki másnak kuss a neve" mentalitás kihalófélben van és az ilyen emberek cserélődnek le devopsokra.

Ha supportálni kell a prodot, akkor igenis legyen oda accom, különben hogy a tökbe supportáljam? És de, ha valami fos az infrán, igenis bele fogok nyúlni. Majd a code reviewen úgy is megköpködöd az infrás pull requestet, ha valami nem tetszik és nem előre leugatod az összes dev fejét.

Az admin-t csereld le pokhendi troger szuperhos-rocksztar-ninja-magus fejlesztore, es akkor nagyjabol igaz amit irtal.

> És de, ha valami fos az infrán, igenis bele fogok nyúlni.
Leginkabb a deploy-olt kod szokott extra fos lenni.

Mondjuk en reszemrol kezdem elengedni ezt az egeszet. Jon valami fofutykos, jol megmondja hogy uzleti dontes miatt ez lesz, vagy az lesz. Jobbara kitolnak valami instabil fost, mert hat rapidsag van, meg a milestone-ok stb-stb. Valaki vallalja erte a felelosseget, lehuzom a keszenletem (jol fizetik), azon meg a munkaidon kivul pedig elfelejtem mi van bent. Egyre surubben jot rohogok mikor osszeborul valami, amit siman meg lehetett volna elozni.

echo crash > /dev/kmem

Az admin-t csereld le pokhendi troger szuperhos-rocksztar-ninja-magus fejlesztore,

Mondtam én bárhol, hogy elfogadható? Csapatmunka van, nincs helye a pökhendi tróger szuperhősöknek és a pökhendi tróger "én vagyok az isten a rendszer felett, mindenki másnak kuss a neve" adminoknak sem a csapatban.

Egyre surubben jot rohogok mikor osszeborul valami, amit siman meg lehetett volna elozni.

Ahhoz meg normál esetben elég sok szinten kell elbaszásnak történnie. DEV? UAT? TEST? Nincs több környezet? Miért nincs?

DEV: fejlesztők bactatják. UAT/TST: fejlesztő adja a release_candidate csomago(kat)t, admin felrakja, user/üzlet teszteli, support hozzáfér a támogatáshoz szükséges mértékben. PROD: UAT-on "kipipált" release_candidate motyó release-ként mehet rá, admin telepít, ideiglenesen(!) r/o hozzáférést kaphat kifejezetten hibakeresési céllal az, aki "támogatói" szerepkörben dolgozik.

Vicc ez a környezet hiszti. Én még nem láttam olyat, hogy az élessel 100%-osan egyező környezetet tudtak volna valahol produkálni. Ha másért nem, akkor azért, mert a vas és az azon futó oprendszer gyengébb/más verziójú....de legtöbbször több, különféle fejlesztés megy egy dev környezetben, esetleg több, különféle fejlesztett cuccot tesztelnek azonos tesztkörnyezetben és így máris bukott a mantra, miszerint a tesztben megy, akkor tuti megy az élesen is. :D Rugalmasság elvtársak! Ez az éberség, stréberség, héberség dolog, amit nyomtok, már nem divat, mert az eredménye nem a produktum, hanem csak a veszekedés, szar kenegetése másra, stb.

miszerint a tesztben megy, akkor tuti megy az élesen is. :D Rugalmasság

Nyilván nem, mert a tesztadat is számít. Bár erre lehet pl. UAT-ot használni.

Ha másért nem, akkor azért, mert a vas és az azon futó oprendszer

Normális infrastructure-as-a-service esetén hogy is fordulhat ilyen elő? :) Jó, nem vagyok naív, nyilván megvannak azok az esetek. Csakhogy pont az ilyen esetek a múlt, amikor valamit kézzle tesz fel az admin.

Például úgy, hogy vannak vasak, amelyeknek darabja milliárdos nagyságrendbe kerül. Érthető, ha egy nagyvállalat ebből nem vesz kettőt a fejlesztés és tesztelés miatt. Az élesen ilyenkor frissítik az oprendszert, amennyire a ktgvetés engedi, a fejlesztő/tesztelő vason meg akkor, ha olyan új funkcionalitást akarnak használni, ami a régiben nincs benne. Hát így. A PC az it világ kis szeletében uralkodik. Vannak más hw-ek is. Többen.

De amikor ott a kvazi ingyen CentOS kornyezet? Olcso infran? Nix testing, nincs ra ido.
Nagyvasnal is ott van azert a particionalas/zonazas (ugy sejtem Z, i, esetleg AIX, Solaris amire gondolsz). Nyilvan ott minden centit/centet kifacsarnak beloluk, en megis azt latom hogy minel olcsobb az infra, annal spurabbak a tesztelesekkel, patchelesekkel, tervezessel.
De ertem es elfogadom hogy nem az en picsogasom fogja meghatarozni a trendet. Business as usual, vagy mi :)

echo crash > /dev/kmem

Igen Z, i és AIX a környezet, amiről beszélek. :) Lehet particionálni, igen, de nem a végtelenségig és kb. naponta születik új környezet, mert ezt is ki kell tesztelni, azt is...paralell fut 10-30 téma fejlesztése és tesztelése, ezek közül egyesek élesbe is mennek és máris eltér az éles és a még fejlesztés/tesztelésen lévő újdonságok környezete. Persze figyeljük, hogy összefügg-e a két fejlesztés valamilyen szinten, de nem lehet ezt maradéktalanul tudni akkor, amikor számos 3rd party szoftverbe vagy köré fejleszted a magyar jogszabályiságot. Számtalanszor futottunk bele abba, hogy élesedő dolog az élesen elhasalt, mert egy másik dev ágon olyasmi ment felfelé két nap előnnyel, ami olyasmit okozott, amiről az elhasaló csak az élesben értesült. Vagy mindjárt ott a háttértár kérdése. A játszós gépre több került, mert az élesen könnyen tervezhető a diszk kapacitás és a trendje is jósolható jó közelítéssel, de a játszós gépen/partíción nem...és akkor az elbaltázott program/SQL/temporary LF a játszós környezetben gyönyörűen megy, mert van diszkterülete, átkerül az élesre és ott pislogás van, mert jönnek a warningok, hogy 80%-ig tele a diszk, valamit csinálj, mert baj lesz.

Én éppen ezért nem tudom elhinni, amikor azt mondja valaki, hogy a fejlesztőinek/tesztelőinek bitre azonos környezetet ad. Egyszerűen lehetetlen ott, ahol nem csak egy szubrutint fejlesztenek egy időben.

100%-os egyezes a kornyezetek kozott soha nem is volt jarhato ut meg a nagyobbaknal sem.
Tehat QA-ig altalaban VM, utana HW. Ami 100%-ban ugyanaz: OS, csomagok, egyeb kivanalmak a Ticket alapjan. Mi altalaban a hagyomanyos uzemeltetesnel ezt Puppettel garantaljuk. A HW Resource tervezes pedig csak fel ora Meeting a Fejlesztokkel/Managerrel.

Nem annyira hagyomanyos terepen pedig Kubernetes Docker image-vel. Ott mindenhol egyforma lesz minden, ha eltekintunk a resourceok kulonbozosegeitol.

Ami fontos, hogy egy kornyezetben sem fejlesztunk/uzemeltetunk parhuzamosan tobb dolgot, egy kornyezet egy szerviz.
Ez mind x86 vonalon, a tobbi nalunk nem standard.

zolo

Masik jo pelda egy enterprise telco kornyezet.

Nyilvan van lab es teszt instance-ok, de eleg nehez azonosnak lennie a production-nel, ahol 50-60k telefon es felhasznaloi profil van, nem egy es nem ket telefonkozponttal, meglehetosen osszetett kapcsolatokkal... szoval vannak esetek, amiknel a teszteles bizony nem lesz/lehet abszolut teljes..

Szerintem te élsz buborékban...még. De majd ha lenyomtál negyven évet az IT-ban úgy, hogy végig nagy rendszerekért feleltél, módosulni fog az álláspontod. Vagy nem éled meg a negyven évet ebben az iparban. Persze az sem mindegy, miben gondolkodunk. Szakadjunk el az egyszerű LAMP/WAMP környezettől kicsit néha.

Standard X86 világban, rendes virtualizációval elég sok dolgot láttam már, meg néhány nagyobb motyó is volt a kezem alatt -igaz, akkoriban még nem volt ez a fejlesszünk k.gyorsan és toljuk ki a félkész sz@rt, amit majd egy-két óra múlva új verzióban tákolunk tovább, mert az üzlet azt igányli, hogy száguldjon a fejlesztés...
Volt a kezem alatt néhány rednesenfelépített SAP is (az monduk épp Power+AIX alapon ment), ott pl. természetes volt, hogy az UAT és az éles teljesen azonosan lett kialakítva... Igen, a nagyon nagy rendszereknél nem volt teljesen azonos a fejlesztői és azéles környezet, sőt a teszt is kifejezetten csak a funkcionális tesztelésre volt megvalósítva, de az esetek döntő többségében bizony megvolt az, hogy OS és "függelékei", futtatókörnyezet, hardver (CPU, RAM, diszk), DB-tartalom tökéletesen azonos volt az éles és az UAT alatt. Hogymiért? Mert olcsóbb volt "benyelni" ennek a költségét, mint az eltérések miatt esetleg bekövetkező leállások üzleti veszteségét viselni.

Ja, LAMP/WAMP környezethez maximum játszósan volt szerencsém, üzletileg kritikus rendszer alatt nem. (Oké, Zabbix, Moodle, céges webportál igen, de egyik sem az a kategória, hogy ha megáll/összeborul, akkor csilliós veszteséget termel).

A tesztkörnyezeteket jól kell tudni tervezni, UAT-nál a teljes integrált tesztelést is meg kell tudni csinálni - ez persze néha kemény meló, ha a kapcsolódó rendszerből/külső szolgáltatásból nincs teszt, csak éles, de ez a szép benne, ezeket a problámákat megoldani :-)

Akkor el kéne jönnöd megnézni egyszer a LAMP (mondjuk Nginx, de mindegy, a LNMP olyan vacakul hangzik) webshopokat, amikkel épp foglalkozom. Nem akarsz kifizetni az élessel azonos méretű UAT-ot, mert nem ugyanannyi vas kell 50 tesztelőnek, mint 50 millió felhasználónak. :-)

Nem azt mondtam, hogy minden méretben 100%-ban azonos UAT kell, hanem azt, hogy a legtöbb esetben azt kell megcélozni, hogy lehetőleg azonos legyen, minden létfontosságú komponens ott legyen az UAT-ban is, az élessel azonos felépítésben. (Ha élesben F5 az LB, akkor ne csinálj UAT-ot haproxy-val). Az UAT _méretezés_ más kérdés: ezres nagyságrendű node-ból összerakott prod mögé természetesen nem 1000+ node-os UAT kell, hanem a tervezett tesztek okozta terhelésre méretezett, de felépítésében az élessel azonos környezet.

Van tobb kornyezet, jobbara disznek.
Ez volt: az uzemeltetes megkapta a specifikaciokat, teszt jegyzokonyveket stb. Elobbi megbeszeles targya volt, utobbi alapjan pl. jogunk volt nemet mondani a deploymentre. A full infra lepesrol-lepesre volt patch-elve, elokeszitve, szintenkent. Ertsd pl.: egy sima yum update, ami mondjuk patchelt httpd-t es perl-t, szintenkent szepen le volt tesztikezve. Minden ok (infra, kod, teljesitmeny)? Mehet feljebb.
Ez van most: az uzemeltetes megkapja a specifikaciokat, teszt jegyzokonyveket nem. Elobbi nem megbeszeles targya, utobbi ketseges hogy szokott-e letezni. Ha a dev azt mondja hogy go akkor go. Ha esetleg a core sw verziok (Apache httpd, Perl, Percona, Java, mostanaban .Net, de akarmi is) szet vannak csuszva egymastol a kiadasi szinteken, nem baj, go azt' majd jon a ninja dev es haxol amit er. Kulcsolt root-tal, Administratorral ofkoz, mert ugy hatekony.

Na es ilyenkor kell ott allni, mindenfele eroforrasokat ide-oda alatologatni, ezt-azt hegeszteni, konfigolni, reszelni, patchelni, downgrade-elni, ujra es ujra deployolni stb. Segiteni a ninja-t tuzet oltani, hogy vegul menjen aminek mennie kell.

Nagyjabol.

echo crash > /dev/kmem

Szerencsere a lekezelo, bekepzelt "en vagyok a fejleszto, mindenki masnak kuss a neve" mentalitas is visszaszoruloban van :)

 

Amugy dev oldalnak legyen nyilvan prod hozzaferese, mondjuk eseti alapon aktivalhatoan, prod oldal altal jovahagyva (nalunk peldaul ez van, aktivitas/role alapjan lebontva).

 

A devops meg.. hat.. szerintem egyszer ez a hullam is lemegy, es lesz helyette egy masik buzzword, mint mindig.

Ezzel én mélyen egyetértek, azzal a kiegészítéssel, hogy a fejlesztő nem hibakeres és pláne nem hibaelhárít az éles rendszerben.

Ha áll az ország, hát áll az ország.

Ja hogy a tesztben nem jelentkezik a probléma, ami az élesben igen? Kellemetlen.

Valamit gyorskapkodással kellene fejleszteni, hogy visszaálljon a működés? Majd valamelyik következő sprintbe agilisen beillesztjük.

A "tud pörgetni magának egy vm-et" addig oké, amíg a fejlesztői "szemétdombon" csinálja - UAT/prod részen viszont coki, ott nem ő tervezi az erőforrásfelhasználást, úgyhogy ott csak ne pörgessen vm-et "csak úgy". Ahogy az üzemeltetőnek sem biztos, hogy kell commit jog a verziókezelőben :-P

Dehogynem. A sysadminnak jo esetben kb. addig terjed a dolga, ameddig elkesziti azt a rendszert, ami kornyezetet a fejlesztonek, aminek a keretein belul az azt csinalhasson, "amit akar".

Regen rossz, ha 2019-ben olyan rendszereken fut barmi is, amit barkinek is kezzel kell buvolnie, konfigot kell irnia, stb. 

Egy normalisan elkeszitett (megtervezett! letesztelt!) config management kornyezetben a fejleszto akkor, es arra kuld PR-t, amire akar, legfeljebb az infrastruktura mernok nem mergeli be, hanem visszakuldi javitasra. 

Es hat 2019-ben nem nyulunk olyan rendszerhez, ami nem valami verziokezelt konfiguraciomenedzsment kornyezetben van definialva. 

Az az uzemelteto pedig, aki meg mindig besshzik gepekre, es ott konfiguracios allomanyokat szerkeszt... nos o kepezze magat tovabb, mert emellett elment a szakma mondjuk 8-10 eve. 

A fejlesztők a saját trágyadombjukon azt csinálnak, ami jólesik. Az UAT/prod környezetben, mivel _nem_ ők tervezik/menedzselik az erőforrások allokálását, maximum kér_hetnek_ az üzleti területen keresztül újabb gépeket, több erőforrást valamely szolgáltatás alá. Pontosabban jelezhetik, jelezniük kell, hogy adott fejlesztési igény megvalósításához milyen erőforrásokat kell biztosítani az éles üzemben.

És 2019-ben elvileg valóbanminden (minden is!) konfigmenedzsmentből megy, de ettől még nagyon-nagyon messze áll a világ (Egységes konfigmenedzselj három-néyg féle alkalmazásszervert, 4-5 különbőző OS-t, legalább három virtualizációs platformon, hálózati határvédelemmel, kapcsolatok auditált rögzítésével, tok-vonó.  Ja, hogy ez értelmes költségkeretből nem megy? hát ez az...)

Amikor van 50-100 gép, mind egyedi beállításokkal, akkor nemk. mindegy, hogy az adott gépen történik meg egy xml/yaml/akármi fájl módosítása, vagy egy (pontosabban több, mert a teszt/éles rendszereket konfigmenedzsmentben sem kezelhetem egyben!) gépen egybeömlesztve? Ha valamit ilyen környezetben újra kell építeni, mert összerosálta magát, akkor sokkalta egyszerűbb a legutóbbi (napi) mentést visszarakni, mint nulláról felépíteni/bekonfigolni egy vadi új gépet. Persze, ha adott funkcióból kell csillió+1, akkor lehet f...ni a vm-eket szakmányban, de ez a helyzet nem mindenütt áll fenn.

Egy normalisan osszerakott (mondjuk) puppetes kornyezetben az altalad felhozott peldak pont nem eloek. Tokmindegy, hogy vm vagy bare metal felrantasz egy alap os-t (kickstart, cobbler, preparalt image amit akarsz), amin van egy beallitott puppet agent, megfuttatod, es ott a geped, osszeallitva, uzemkeszen harminc percen belul. Ha csak a puppet reszt nezed, akkor legyen tiz.

Ha van 50-100 geped mind egyedi beallitasokkal, akkor el van rontva a tervezes.

Teszt/staging/eles rendszerek mind mehetnek ugyanabbol a konfigmenedzsment redszerbol, legfeljebb mas branchekbol csinalod.

Mi az, hogy 'ertelmes koltsegkeret'? Ami ehhez kell az mind free software. Ha ido nincs ra, akkor nem ert hozza a menedzsment, hogy adjon. 

Vajon mekkora meretben kell tolni ezt a devops fele dolgot, hogy az emberek rajojjenek, hogy ez egy letezo megoldas egy letezo problemara?? Fura, itt a huppon megy a buzzwordozes, meg allatorvosi lo, mikozben a vilag masik felen komoly cegek alapoznak ra, es gyakorlatilag a modern microservice architektura alapja, hogy vannak emberek, akik mindket oldalt kepesek tamogatni. Vajon a Spotify, X, Y, Z (iszonyat hosszu a lista) mernokei nem vesznek eszre valamit vagy a (hogy helyi kifejezessel eljek) fôsodratú huppos elvtarsak??

En is gondolom, csak lehet 20 evente erdemes felulvizsgalni az ilyen eszmeket :D Mert a vilag kozben valtozik. Pl sokan fujjogtak a telefon fenykepezogepre, es mondtak, hogy "ha telefonalni akarok, akkor telefont veszek, ha fenykepezni, akkor meg fenykepezot". Manapsag meg kb imax filmet lehet forgatni egy komolyabb keszulekkel, ami kozben 15 masik dologra is tokeletes. Kevesen hordanak a taskajukban fenykepezot, gps navigaciot, wifi hotspotot, telefont, menedzser kalkulatort, taskaradiot, szotarat, diktafont, iranytut, walkmant, stb. Lehet, hogy egyes cel eszkozok verik a telefon ugyanazon funkcionalitasat, de a) azok altalaban dragabbak (foleg ha mindenre kulon megveszi a delikvens) b) a userek 80%-anak tok felesleges.

A DevOps is egy kicsit hasonlo. Nem lehet mindenhez erteni, aki azt allitja hazudik, de lehet erteni a programozashoz meg uzemelteteshez egyszerre annyira, hogy hitelt erdemloen tudjon valaki nyilatkozni egyes kerdesekben, es ne nezzek madarnak egyik oldalon sem a mernok holgyet/urat. Szorgalom es erdeklodes kerdese. Altalaban az utobbi hianyzik, sot inkabb a hata kozepere sem kivanjak az emberek, hogy beletanuljanak a masik munkajaba, es akkor marad az egymassal szemben allas es az onos erdekvedelem. Azt viszont mar lattuk az hova vezetett. Most lassuk meg ez hova vezet :)

LOL! Ez biztos nem lesz benne, mert itt most fontos irányelvekről van szó, amelyekkel lehet meetingen vagizni :)

De hogy ON is legyek:

A raid nem backup. 

A user nem ellenség. Ismétlem: a user NEM ellenség. Most írd fel 100x ezt a táblára!

Ha hülyeséget beszél a user, akkor csak nézz üveges szemmel és ne mondd el róla a véleményedet, főleg ne valami külső jegy említésével (pl. "szőke")! 

A cloud nem ördögtől való és érdemes érteni hozzá, mert nem a cloud veszi el a munkádat, hanem a cloud ismeretének a hiánya :) 

chmod +x nemellenseg.sh
./nemellenseg.sh

0. a user NEM ellenség
1. a user NEM ellenség
2. a user NEM ellenség
.
.
.
.
95. a user NEM ellenség
96. a user NEM ellenség
97. a user NEM ellenség
98. a user NEM ellenség
99. a user NEM ellenség
100. a user NEM ellenség

101-lett, maradhat?

Hivatásos pitiáner - Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @

Ha kérdeznek, válaszolsz.

“Any book worth banning is a book worth reading.”

10 elott nincs hiba, te vagy a hulye.

Rengeteg csipas kuldott szerencsetlen hd iranyaba 7-10 kozott ticketet, amit aztan ebredes, kave, pisi,kaka, cigi szunet utan cancel , mert rajott, hogy o volt a bena, de leginkabb "megjavult" es orommel kozolte, hogy lehet zarni es koszoni szepen.

Masreszt, meg milyen hely az, hogy nincs frontend az adminok elott ?

Szemelyesen felhasznaloval beszelni, nemhogy nem kellett, hanem meg volt tiltva, telefonon sem, szigoruan ticket rendszer, amirol nincs ticket az nem letezik. Mindez 10 eve is mar. HD majd intezi es szelektalja.

Fejlesztok tamogatasa ugyan nyug, de szeretjuk ha nem nyavognak ezert csinaljuk.

Kedvesen. Nem otromban orra ala dorgolve, hogy megint te javitottad a vackat.

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

Ilyen irányelveknek akkor van bármi értelme, ha megvan ennek az ellenoldali megfelelője is:

-Az IT-s nem -feltétlen- olyan biorobot mint Te, ne tekints rá úgy mint egy rabszolgára, akinek az a dolga, hogy helyetted csinálja meg az Outlook kinézetének átállítását

-Ha az IT-s megkér arra, hogy hivd fel/adj fel jegyet XY-nak, hogy megoldják a problémádat, akkor ne sértődj meg és ne könyveld el az IT-st hülyének, aki nem képes megoldani a problémádat (mert pl nem az a process, nincs hozzá jogosultsága...stb)

-Ne várj proaktivitást IT részről, ha te sem vagy az (nem jelzed a hibákat, csak puffogsz magadban, hogy "ez is szar, az is fosh", senki se fogja megszerelni neked)

-Technológiai fejlesztéseket, funkcióbővítéseket/változtatásokat ne azzal próbálj meg elgáncsolni, hogy "de hát 10 éve igy használjuk ezt és ezt, továbbra is jó igy"

-Attól, hogy valaki az IT osztályon dolgozik, még nem biztos hogy meg kell/tudja oldani a problémádat

 

Fejlesztőknek:

-Ha nem mondod az igényeket, nem lesz kiszolgálva

-Ne próbálj meg üzemeltetői tudás nélkül beleokoskodni a rendszergazda munkájába

-Ne tekintsd biorobotnak a root-ot, miközben nem vagy képes felfogni pl a Jump server fogalmát, vagy nem tudsz magadtól felrakni egy csomagot kézzel, vagy elcsodálkozol azon, hogy a görgővel kattintva egy linkre automatikusan új lapon nyilik meg a háttérben

-Ne hazudj a rootnak, mert úgyis látja a logból, hogy te voltál "Nem csináltam semmit, aztán egyszer csak megállt minden"

 

És még sorolhatnám, csak nincs időm pötyögni :D Ezek csak az elmúlt 2 hét saját példái voltak.

Hivatásos pitiáner - Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @

Amikor felhívnak azzal, hogy "segíts, mert bekockásodott a word", akkor higgadtan kell odamenni, becsukni az Excell-t, és nyitni egy Word-öt. (true story)

Nagy Péter

És akkor amikor beszóltam általánosban, hogy az az izé füzet franciatéglalaprácsos, na azt nem pozitívan értékelte a tanerő. :D

"A fejlesztők és a Jóisten versenyben vannak. Az előbbiek egyre hülyebiztosabb szerkezeteket csinálnak, a Jóisten meg egyre hülyébb embereket. És hát a Jóisten áll nyerésre." By:nalaca001 valahol máshol

A szakáll, és a torzonborz külső nem kötelező.

  • Kötelezően dokumentált, kihirdetett backup stratégia, naprakész, biztonságos backup, rendszeres restore teszt.
  • Az egyes userek jogosultságai nem ad-hoc módon, vagy puszira, hanem a jól definiált feletteseinek valamelyikének írásos kérése alapján adatik meg.
  • Az egyes felhasználók hozzáférései naprakészen nyilván vannak tartva.
  • A hw eszközök nyilván vannak tartva, személyhez, vagy csoporthoz vannak rendelve.
  • A VM-ek description-je ki van töltve, különös tekintettel ip-re, HA igényre, és létrehozóra, gazdira. Ebből következően a dokumentálatlan, és/vagy gazdátlan VM kérdés nélkül destroy-ra megy.
  • Nincs olyan, hogy "légyszi, gyorsan fű alatt"!
  • Mindenki a saját portáján sepreget. ;)

Még biztos lenne ötletem, de hirtelen ennyi...

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

Nagyon szép lista. Csak userek ne legyenek a cégnél!

Menj el dolgozni bármelyik külföldi otromba multi budapesti shared service center-ébe (ssc), és láss csodát: ezeket egyiknél se tartják be. Az összes nagy IT-s multi már évekkel ezelőtt kiszervezte a drága IT üzemeltetést az anyaországból keletre. Ha értelmesek voltak, akkor csak a vadkeleti Magyarországig / Romániáig jutottak. Ha nem, akkor ment Bangaloru-ba a szakértelem. Igen, drága az IT, mert bár ugyan ebből élt meg évtizedekig a cég, de a CIO meg a részvényesek miatt most már olcsóbban kéne lehetőleg ugyanaz vagy jobb minőségű munka. Hát az nem jön össze. Senkinek nem sikerült még az elmúlt 15 évben. Akkor viszont szomcsi, de a fentebb általad írt katonás fegyelemről mind lehet lemondani. Hallgatólagosan le is mondtak.

Papíron van rend és fegyelem, ill. ha interjún rákérdezel a leendő főnöködnél, akkor természetesen minden processz szerint szép és jó lesz, mindenki 1 nagy család, és segíti egymást támogatva ezen a "customer journey" nevű faszságon amit valami markeringes fasz talált ki valahol a hülye amerikában. A valóságban pedig tökéletesen cégkultúrafüggő, hogy a folyton követelődző ügyfeleknek a seggét szónélkül kell kinyalni, és megcsinálod neki a szabályokkal ellentétes bármit is kérnek sos. Különben 10 perc késleltetéssel rohannak panaszkodni az itteni középvezetődhöz. Aki jó vezető módjára mindig az ügyfélnek ad igazat, és úgyis meg kell csinálnod, bármilyen faszság amit akarnak, ráadásul akkor már ő is tud róla és beáll a sorba baszogatni ő is vele.

Emiatt egész éves agyatlan tűzoltás megy, mert a puszira jogosultságosztások és inventory mismatch-ek aztán fél év alatt rádőlnek az emberre, és annak a kigányolása köti le utána több csapat energiáit hetekig hónapokig. A normál ügymeneti teendők mellett ofcourse. Minden második sos követelőzés vmi helyi főfasz csicskásától jön, mert 5 perc múlva kezdődik és nemérdekel de addigra működjön, wc-re se menj ki amíg be nem fejezted. Nyilván időhiányában nem lehet a direkt-használhatatlan belső tool-okon mind pepecselősen végigmenni. Marad a kerülőút mert közben ott topognak a nyakadban. Mivel pedig a helyi vezetőség is lefekszik a veryimportant ügyfelek minden ticket-nélküli sos changefaszságának, a papíron lefektetett elvekkel azonnal szembemennek ők maguk is. Innentől kezdve az alvégen szopóktól hogy is lehetne konzekvens működést elvárni?

Szóval csak ennyit a user jogosultságok nyilvántartott osztogatásáról, hw inventory uptodate-n tartásáról, VM-ek aktualizált IP inventory-járól, és a többi nemes ötletről. Csak user ne legyen a rendszerben, mert ledől az IT elefántcsont tornya.

Nem értek egyet.

Itt is ez volt, amit írtál. Aztán jött egy új IT igazgató, aki engem is felvett. Meg még jópár embert. 1-1,5 évig azt takarítottuk amit leírtál. De már jó ideje a működésünk közelíti azokat amiket leírtam. Természetesen nem pontosan, nincsenek csodák. ;) De működik.

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

a folyton követelődző ügyfeleknek a seggét szónélkül kell kinyalni, és megcsinálod neki a szabályokkal ellentétes bármit is kérnek sos.

a direkt-használhatatlan belső tool-ok

a helyi vezetőség is lefekszik a veryimportant ügyfelek minden ticket-nélküli sos changefaszságának

Szintén zenész "IBMer"?

Nem kötelező a több napos csapatépítő "ki kit dug meg" tréningeken részt venni. Vagy ha igen, akkor legalább egy ki legyen este a szobában!

Nem letezik "szar az egesz", probaljon meg a user is arra gondolni, minel jobban specifikalja a hibat, annal konnyebb lesz megoldani.
btw, szerencsere itt a cegnel nagyon ritkan kell visszakerdeznem, pedig 400+ user van (es nem helpdeskes vagyok, hozzam csak ritkan jonnek userek, pl. kozos meghajtora visszaallitani egy filet, spamszuro megfogta a levelet, stb)

Az elotet nagyon jo dolog, elozo cegnel nem volt, igy ha pl.valami gond volt az egyik hosting szerverrel (mittomen, mysql tulterheles vagy barmi), folyamatosan kapkodtam a telefont es kozben probaltam helyrerakni. Nem volt jo mulatsag

http://www.micros~1
Rekurzió: lásd rekurzió.

Hasznos tanács az új rendszergazdának: nem szégyen a munka, és nem azért vettük fel, hogy egész nap facebookozzon és közben youtube videókat nézzen.

Hónapokig tart egy új ember felvétele, hónapokig a kiképzése, és ha ezek után kiderül, hogy nem szeret dolgozni, akkor kicsit morcos vagyok.

Az utolsó négy társammal hasonlóan jártam, hiába csináltatok a jelöltekkel egy elég nehéz gyakorlati tesztet, az nem derül ki a beszélgetések alatt, hogy egy tróger, vagy remekül tudják magukat álcázni :-)

Azt találtuk ki a főnökömmel , hogy egy helpdeskes srácot fogok helyette betanítani adminkodni, mert ő már bizonyított, nem fél a munkától, és lenne is kedve feljebb lépni.

Irányelv: a rendszergazda munkájának elsősorban a céges érdekeket kell szolgálnia, és csak másodsorban jöhet a saját szépérzék kielégítése. A csapatjáték fontosabb, mint az abszolút jóságba vetett hit.

Ha a fejlesztő kér egy root jogot, akkor lehet, hogy tényleg kell a céges szolgáltatás létrehozásához/fenntartásához (ilyenkor ne azt nézd, hogy a _fejlesztőnek_ kell a jog, hanem azt, hogy a _szolgáltatáshoz_ kell a jog). Vagy Te akarod a csak-root-joggal-futó izéit meg bigyóit telepíteni Githubról? Naugye.

Ha a sales-es azt mondja, hogy neki Google Drive kell, akkor ne akarj VPN-en át elérhető SFTP szervert adni neki, mert ezzel lehet, hogy elfelezed a hatékonyságát. Ha meg feleannyit ad el, akkor nem lesz fizuemelés, nemhogy félévente, de ritkábban se.

Ha az architekt azt mondja, hogy kell még két szerver mindkét gépteremben, annak ellenére, hogy a létező két nyolc processzormagos szerver csak 12.5%-on ketyeg, akkor akár igaza is lehet. Simán lehet, hogy a hülye applikáció csak egy szálon képes futni és ezen nem lehet változtatni, tehát a teljesítmény növeléséhez több gép kell. Meg a redundancia se árt. Ja, és ha mondja, hogy backup ezekről nem kell, abban is lehet, hogy igaza van. Van olyan szolgáltatás, amely esetén ha restore van, akkor már elbukott a cég, ami nyújtja.

Ha az UX-es kolléga azt mondja, hogy jobb lenne az OK gomb zölden, mint pirosan a csodamonitoringszoftver felületén, akkor lehet, hogy meg kéne oldani a dolgot. Tudtad, hogy az emberi hibákat sokkal hatékonyabban lehet jó eszközökkel kivédeni, mint amennyire esélyes okosabb/ügyesebb embereket keresni?

Éles szolgáltatáshoz githubról direktben izé-bigyót telepíteni... Tudom, hogy fejlesztőéknél a holnaputáni "valakimárcsináltolyat" tökéletes alap egy munka elvégzésére, de amíg az adott gép stabil és biztonságos működéséért nem a fejlesztő felel, addig neki csak annyit kell tudnia, hogy milyen futtatókörnyezet van az élesben, illetve a uat-on, és max. ez utóbbira felküldött motyók mehetnek a helyi(!) tárolóból (anno DSL-nek hívtál ITIL-ül, ha jól rémlik) az éles környezetbe. Per definitem _éles_ rendszerhez _fejlesztői_ sapkában senki nem piszkálhat hozzá. Ha _support_ sapkában van, akkor is csak a meglévő állapotot vizsgálhatja, módosításra _nincs_ joga, sem adat, sem kód/szoftverkörnyezet szintjén. Legalábbis jobb helyen...

"Ha az architekt azt mondja,..." - ezzel döntően egyet tudok érteni: legfeljebb az "üljünk össze, és beszéljük meg az üzemeltetési terület kifogásait" legyen ott mellette.

A másik kettőre 100%-ban bólogatok :-)

Picit messzebb a témától, de 2019-ben nincs realitása a Hiteles Szoftvertárnak meg a többi hasonló csecsebecsének egy általános/átlagos cégnél. (Ha pl. műtőrobotokat csinál a cég, az egy másik helyzet, de kevés ilyen cég van, átlagos meg sok.) Egyszerűen túl sokba kerül a fenntartása, túl sok munkát kellene belefektetni, és ezek a jelenlegi helyzetben egyszerűen nem térülnek meg sosem. Teljesen racionális döntés futni annak a kockázatát, hogy 1) becsuk a GitHub 2) a GitHubra felrakott KedvencJavascriptLoggingLibrary projekt bankkártyaszám-lopó kiegészítéseket tartalmaz, ahhoz képest, hogy csinálsz egy DSL-t, amibe tényleg átnézve a kódokat, kontrolláltan juttatod be a programokat, modulokat, mindeneket.

Ez egy nagyon jó cikk: https://medium.com/hackernoon/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5 De azért nem pánikol mindenki ezen, mert _általában_ nem történik ilyesmi.

(Egyébként ezzel analóg a háborúra készülés. Lehet építeni bunkert, meg májkrémkonzverv-hegyeket raktározni benne - meg lehet arra építeni, hogy úgyse lesz háború. Az utóbbi nagyon sokkal olcsóbb és ha nincs háború, akkor egyértelműen jobb stratégia - cserébe orbitális szívás, ha mégis van háború. A haszon várható értéke attól függ, hogy milyen valószínűséggel lesz háború, ezt kell jól megtippelni...)

Még egy: nem vagyok benne biztos, hogy a GitHub-on lévő kód megbízhatósága alacsonyabb, mint a "felelős dolgozó" által a DSL-be behozott kód megbízhatósága. A GitHub-on lévő kódot többen nézegetik általában, mint azt, hogy mit rak a kódba a belsős kolléga...

A github-ról, vagy épp a piripocsbete.uw.hu weboldalról lerágatott szemét egyre megy - nem garantált, hogy az fog az élesbe is felkerülni, ami a teszten/uat-on már jól muzsikált. A fejlesztő csomagolja a produktuma mellé, mert honnan a francból gondolja pl. azt, hogy a github vagy bármilyen más külső erőforrás elérhető a prod, vagy akár az uat rendszer felől, másrészt meg utólag hiába pingvinezik, hogy "deamikorőnézteakkorilyetnemcsinált", az éles környezetben a kód és az az által oda rángatott minden komponens működéséért bizony ő kell, hogy feleljen.

A DSL-t egyébként ilyen környezetben "fordítva" építik: a prod-ba ment kód kerül elrakásra, rigorózusabb/paranoidabb esetben időbélyegezve, aláírva.

Az és úgy kerül élesbe, ahogy a fejlesztő team átadta: kód+telepítési leírás alapján. A kód része _nem lehet_ olyan, hogy "töltsd le a foo.bar.baz/latest/kodfuggoseg.akarmi csomagtot", mert akkor nem garantálható, hogy az megy élesbe, ami az UAT-on már bizonyított. Ha az UAT-ban ezeknek megfelelve sikeresen települ a motyó, _és_ az UAT teszteken átmegy, akkor az UAT tesztelést végző terület "bólintása" után mehet élesbe.

Ugyanezért az UAT-ra kiment OS frissítések azok, amik az élesbe kimehetnek, nem pedig azok, amik az éles frissítésének az időpontjában elérhető legfrissebbek.

Nem kell kézzel csomagolgatnia - UAT-ra átadás az UAT-os deployment pipeline elejére rakja a motyót, UAT-os admin megnyomja, hogy menjen, uat-on userek nyomkodják a motyót, ha rábólintanak, akkor az,a mi az uat-ra kiment, az mehet az éles rendszerre telepíthető cuccok közé.

Ettől még egy változáslistát, illetve telepítés során elvégzendő speciális tennivalókat tartalmazó doksit mindenképp kell a fejlesztőnek adnia (pl. az app1, app2 telepítése után a dbscript3-at meg kell futtatni, utána jöhet az app4 és 5) - leírva azt, ami a normál telepítési folyamattól eltérést jelent, valamint szintén leírva azt, hogy van-e adatszerkezeti változás (és ha igen, micsoda?), van-e alkalmazáson belül új/módosult jogosultság kialakítva (ha igen micsoda és mi a célja, stb.) - szóval dokumentálás az minenképp szükséges - egyszerűbb esetben annyi, hogy "nyomd meg a jenkins-ben a megfelelő verzióra a gombot" - bonyibb esetvben meg picit több, még akkor is, ha mind jenkins-es gombnyomogatásról szól.

Meg a lónak a fa...

 

Ha a fejlesztő kér egy root jogot, akkor lehet, hogy tényleg kell a céges szolgáltatás létrehozásához/fenntartásához (ilyenkor ne azt nézd, hogy a _fejlesztőnek_ kell a jog, hanem azt, hogy a _szolgáltatáshoz_ kell a jog). Vagy Te akarod a csak-root-joggal-futó izéit meg bigyóit telepíteni Githubról? Naugye.

Vagy én üzemeltetek, vagy más. De amíg én tartom a hátamat a rendszer/szolgáltatás működéséért addig abba más ne kotorjon bele.
Aztán majd ha valamit szétbarmol, akkor meg persze én csináljam meg, lehetőleg 0 másodperc alatt, ugye?
A banki hozzáférésemet meg a lőfegyveremet ne adjam oda, csak mert szerinte arra is szüksége van?

Ha a sales-es azt mondja, hogy neki Google Drive kell, akkor ne akarj VPN-en át elérhető SFTP szervert adni neki, mert ezzel lehet, hogy elfelezed a hatékonyságát. Ha meg feleannyit ad el, akkor nem lesz fizuemelés, nemhogy félévente, de ritkábban se.

Ó, csodás lehet olyan helyen dolgozni, ahol a software-környezet összeállítását a sales végzi. Gondolom, ha a vírusirtó lassítja a gépét, akkor azt szedjük le róla, és akkor majd gyorsabban dolgozik, több üzletet hoz, örö é bódottá...
Meg gondolom, ha éppen rájön, hogy neki kurvára jobban menne a munka az XY-Salesmaster 5.0-val, akkor szedjük le gyorsan a torrentről, és pakoljuk fel azonnal, ne tartsuk fel minden aggályoskodással...

Látom sikerült érzelmeket indukálom a hozzászólásommal, nagyon jó :-D

 

Szóval: a szolgáltatásért NEM a rendszergazda a felelős. Nem Neked kell a hátadat tartanod érte, hogy működjön. Nektek, a fejlesztővel együtt kell tartanotok a hátatokat (meg ha van még hat ember, aki részt vesz a folyamatban, akkor nyolcatoknak együtt).

Ha saját magadnak építgeted a szuper környezetet,de mást nem engedsz hozzá, az rossz. Egyrészt ha rád esik a műhold, akkor rohadt nagy baj van. És nem, sajnos ezen a dokumentáció sem segít. Bármilyen jól dokumentált rendszert sokkal lassabban lehet megismerni, mint amit már a napi használat alatt megismertél. Másrészt hiába a rendszergazda szemmel szuper könyezet, ha nem termel pénzt a cégnek, ami a fizetésedet fizeti.

(Egyébként ebben az is benne van, hogy ha a fejlesztő kódjában látod, hogy mit cseszett el nagyon, arról szólsz neki, vagy kijavítod. Pull request, rányomja az okét, kész.)

 

A másik részére pedig: a sales-es igenis jobban tudja, hogy a sales tevékenységhez milyen software-környezet kell, mint a rendszergazda. Illegális dolgokat nyilván ne csináljon neki senki, de a Google Drive nem illegális, és tényleg láttam olyat, ahol kimutathatóan több lett a sales eredménye attól, hogy megkapta az általa választott megoldást (ott konkrétan Dropboxot, de ez mindegy) a céges vacak helyett.

És ahogy az előbb is: nyilván itt megfontolás kérdése a dolog. De ha jön egy ilyen request, hogy kell a GDrive, akkor ne az legyen a válasz, hogy "NEM!!!", meg hogy "NEM LEHET, MERT (mindegymi)", hanem egy megfontolás, hogy hogy lehetne megoldani jól.

Szóval: a szolgáltatásért NEM a rendszergazda a felelős. Nem Neked kell a hátadat tartanod érte, hogy működjön. Nektek, a fejlesztővel együtt kell tartanotok a hátatokat (meg ha van még hat ember, aki részt vesz a folyamatban, akkor nyolcatoknak együtt).

Hát, amerre én jártam, ott ha az éles rendszer leállt, azért jellemzően az üzemeltető nemes szerveit kezdték el megtaposni. És ha gond van, akkor baromira senkit nem érdekel, hogy én írtam az rm -rf xzy/* helyett rm -rf xyz /*  -ot, vagy valaki, akit odaengedtem...

Egyébként normális emberekkel működő üzemeltetés-fejlesztés esetén ez szerintem jó esetben úgy van, hogy jön a fejlesztő, hogy szerinte ezt meg ezt kellene csinálni adminként, én meg végiggondolom, és megmondom, hogy miért/miért ne, illetve hogy milyen olyan mellékhatásai lesznek/lehetnek a dolognak, amire ő nem gondolt. Aztán ha találtunk egy olyan megoldást, ami mindkettőnknek megfelelőnek tűnik, akkor én belépek, és én megcsinálom. Ha meg nem jutunk közös nevezőre (nem túl gyakori, de azért megesik), akkor egy szinttel feljebb passzoljuk a döntést. Hasonlóképpen, ha azt látom, hogy pl. fekszik a vas a kódjától, és úgy gondolom, hogy a logokból látom, mi a hiba, akkor sem én piszkálok bele a kódba, hanem megyek, és szólok neki, hogy figyu, szerintem ez a hiba, és szerintem ezt lehetne vele csinálni, de nyilván te tudod jobban, szóval nézz rá, és ha kell még valami infó akkor szólj...

A másik témában pedig ez nem az üzemeltetés, és nem is a sales dolga. Messze fölöttük álló döntésnek kellene lenni annak, hogy saját adatokat tartunk-e házon kívül, és ha igen, akkor azt milyen szolgáltatónál, milyen feltételek mellet stb. Az meg egy másik kérdés, hogy nem szívesen melóznék olyan helyen, ahol a munkavállaló privát GDrive fiókjában tárolunk üzleti/üzemeltetési/ügyfél/bármi adatokat... Sőt, olyan hely is van, ahol ezért az ügyfelek helyből felmondanák a szerződést.

Nalunk egeszen jol mukodik. Nyilvan vannak meg kisebb surlodasok, de az irany jo, es a szervezeti felepites is tamogatja a dolgot (csapatba rakott sysadminok akar team levelen is, ha szukseges).

Erdekes modon a legtobb vita sysadmin-sysadmin vonalon latszik kialakulni, amennyiben is a kozvetlenul velunk dolgozo kollegak atlatjak a problemat, es csapattagnak erzik magukat, addig az alap infraert felelos csopot meg szerintuk tul sok jogot tart meg maganak, akar az ok, akar a fejlesztok karara :) Mondjuk itt is fejlodunk mar, de ez talan inkabb annak koszonheto, hogy ugy erzem ez az elso ceg, ami tenyleg ugy nez ki, hogy teljesen agilisen mukodik.

Amugy nyilvan jo a hangulat, csak meg sajnos nem minden tokeletes :)

Akkor az valszin policy szinten szabályzott és by default van mindenkinek, központilag. :) Szóval a kósza ötletes mindenféle telepítésekkel van a probléma, hogy azt is bemossuk a "legyél szolgáltatásorientált" c. történetbe. Pont a hasonló felhős filetároló és társaikkal kell marhára óvatosnak lenni szerintem és még a biznisz verziót is ésszel bevezetni.

Egyaltalan nem biztos. Hogy szuletik a policy? Ugy, hogy van pl. a fent amlitett SFTP over VPN "szolgaltatasa" az IT-nak, ami egy hulladek, mert az ugyfel nem fer hozza, accountot kell neki adni, ki kell nyitni a tuzfalat az ugyfelnel, stb. Erre jon a sales, hogy bakker, at kell kuldeni az ajanlatot, specifikaciot, akarmi, ne adj Isten kozosen kell dolgozni rajta, meg lehetoleg legyen verziozott. Ez btw egy teljesen legitim keres. Ket opciod van.

  1. Elkuldod az anyjaba, o majd bepanaszol a fonoknel, es rad force-olnak valami hulyeseget (pl. lakossagi dropbox)
  2. Konstruktivan allsz hozza, es kitalaltok valamilyen hivatalos megoldast, pl. hogy a sales department kapjon business GDrive-ot, ami best effort supported, tehat ne ott tarolja elete munkajat, hanem hasznalja amire valo: fajlok kuldozgetesere es egyideju szerkesztesre az ugyfellel.

Azt kene megerteni, hogy az IT egy tamogato terulet. Azert koltenek ra, hogy mukodni tudjon a ceg. A sokat fikazott sales meg core business, azert van, hogy te honap vegen kapj fizetest. Nem vagytok ala-fole rendeltsegi viszonyban, az IT nem egy hatosag a cegen belul, ugyhogy tessek ertelmes, felnott emberek modjara egyuttmukodni.

Már több hasonló topic-ban jeleztem, hogy az együttműködés definiatíve kétirányú dolog. Én egyedül nem működhetek együtt. Ennek úgy kell kinéznie, hogy vmely részleg jelez egy igényt. Ha nem értem minek az neki, akkor megkérdezem, és értelmesen elmagyarázza mit akar. Megmondom mit lehet. Ő megmondja, hogy az nem jó, vagy nem elég, és miért nem. Alkudozni kezdünk, mindenki enged egy kicsit, megvalósul aminek kell, és mindenki boldog. Vagy ha sehogy sem tudunk megegyezni, eszkaláljuk a kérdést, esetleg összeírjuk hogy mit kéne venni hozzá (ha ezen akad meg a vita), és úgy eszkaláljuk a kérdést.

Az is lehet, hogy ha nem szimplán az igénnyel jelentkezik, hanem megfogalmazza a célt amit el szeretne érni, akkor htékonyabban segíthetek. Ez ugyanis gyakori hiba, hogy a megkeresés egy szimpla igénnyel történik, aminek a céljához "semmi közöm".

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

ez nagyon igy van... tobb helyen is lattam hasonlo szitut:

ms exchange szerver, win fileszerver, minden csak 2-3 faktoros vpn-en elerheto a ceges domainbe leptetett geprol.

usernek nem tetszik, hogy otthonrol, a macbookjarol, tabletjerol stb nem tud dolgozni. es ez nem is feltetlen a sales-es, lehet akar a ceo is...

innentol a forgatokonyvek:

- user nem dolgozik, es kozli a fonokevel, hogy "szar a szerver"

- user regisztral "lakossagi" gmail cimet es dropboxot, atiranyitja oda a ceges mailt es filejait. es dolgozik, az adatai meg ki tudja hol...

Abszolut támogatunk mindenkit, de a nyakló nélküli és légbőlkapott ötleteket azért ne kelljen már bokacsattogtatva hajbókolva azonnal és főleg gondolkodás nélkül puff gyorsan megcsinálni. A konstruktiv hozzaallassal sincs gond, de amikor ugrál a fejeden, hogy uristen tegnapra, akkor nehéz átültetni bármit is legalább kezdeti jelleggel vmi poliszi szerűbe. Mindezt a GDPR és adatkezelési szabályzat és társaival súlyosbítva.

Ahogy írtam, egy FelhőDrájv ellen sem vagyok, sőt, tök jók, de hát észnélkül azért ne.

Zizi a devops-evangelista manager :-D Nézz utána, hogy a fejlesztés és a support, ha kiszervezett tevékenység, akkor hogy is viszonyul egymáshoz, és milyen jogok járhatnak az egyikkel, és milyenek a másikkal :-P (Láttam ezen "pofozkodni" céget és külső fejlesztőket)  Na ezt belső fejlesztésre is erősen ajánlott betartani - még akor is, ha néha a hatékonyság első ránézésre szuboptimális is. A lényeg, hogy a _fejlesztő_ és a _támogató_ sapkát szét kell választani. Te fejlesztőt írtál, annak _nem_ kell bejárás az éles környezetbe. A támogatónak éles suport igény felmerülésekor igen, korlátozott jogokkal (hozzá tartozó alkalmazás naplóállományai, szükség esetén beállításai, esetleg kapcsolódó rendszernaplók - mindezekre olvasási jog, semmi más. Mondj egy olyan támogatói feladatot, ami normális change managementtel működő helyen ennél több jogot igéányel a _támogató_ funkciót ellátó személy részére. Nem, "az alkalmazás debug módra kapcsolása" nem ilyen.

A sales/üzlet elvadultabbnál elvadultabb igényeit meg egyszerűen szűrni kell, és egyeztetni, hogy pontosan milyen feladatot szeretne a delikvens megoldani, és arra adni neki egy általa is elfogadható, és desktop support terület által is vállalható megoldást. Az esetek döntő hányadában ez valamilyen kompromiszzum lesz, az biztos, de a lényeg tényleg az, hogy a kategórikus "nem", mint válasz, az gyakorlatilag soha nem fogadható el.
 

Példa arra, amikor a felsoroltaknál több jog kell: "Fogamunk sincs, hogy mi a baj, de NEM MŰKÖDIK!!!". :-)

Sokan, sok esetben ragaszkodnak az ilyen elkülönített, silós működéshez. Van a cégnél hálózatos meg linuxos meg alkalmazásos meg fejlesztő/támogató, és mind azt állítják, hogy a területükön minden a legnagyobb rendben van - csak éppen a szolgáltatás nem működik. Ilyen esetekben nagyon sokat tud segíteni, ha valaki bele tud nyúlni egynél több terület dolgaiba.

(Egy egészen konkrét példa, kb. egy hónappal ezelőttről: AWS-es infrát üzemeltetek éppen az adott sapkámban, máshoz elvileg nincs közöm. 40.000 request/sec felett elhasal a szolgáltatás, 503 gateway timeout, miegyebek. Ami látszik, hogy az adatbázis sok-sok CPU-ja mind 100%-on jár. A megoldás az, hogy a webshop szoftver egyik moduljában, ahol Elasticsearch indexet hoz létre a replika shardok száma konstans nullának van megadva. Sok sikert ez kideríteni anélkül, hogy kb. minden komponens minden részéhez hozzáférsz.)

Mihez kell több jog ilyen esetben, nem értem... Ha az alkalmazása bacik rendesen naplózni, ha az alkalmazás technikai userének a dolgaihoz r/o joggal hozzáférve ezeket nem tudja kideríteni, akkor ott más probléma is van.
Szerintem keverednek a fogalmak, illetve egyszerűsítésekkel élsz. Fejlesztő számomra az, aki specifikáció alapján az alkalmazás elkészítésében (kód elkövetés) vesz részt, feladata annyi, hogy az elvárt funkcionalitást lehetőleg határidőre és nem ismert hibáktól lehetőleg mentesen leszállítsa. Nem feladata az alkalmazás éles működését vizsgálni, abban anomáliákat keresni, bugokat vadászni éles környezetben.
Neki tehát semmi keresnivalója nincs az éles rendszerben.
A másik a támogatói szerepkör (aki sok esetben maga a kód "elkövetője"? azaz a fejlesztő), akinek jellemzően nem az a feladata, hogy speckót olvasson és kódot írjon belőle, hanem az, hogy ismerje a futó alkalmazást, annak működését, logikai és belső felépítését, valamint célszerűen a kódbázisát is, hogyha az alkalmazással probléma adódik, akkor a hibakereséshez, a felmerült probléma ideiglenes vagy végleges megoldásához javaslatot tudjon tenni, meg tudja találni a hiba feltételezhető okát.
Ehhez valóban szükséges egy korlátozott hozzáférés az éles rendszer(ek)hez. Korlátozáson azt értem, hogy az általa támogatott szolgáltatás komponenseinek a naplóihoz, beállításaihoz read-only hozzáféréssel kell, hogy rendelkezzen. De ez még mindig nem uid=0 szintű teljes hozzáférés.
Gondolj bele: van egy szerber, azon fut csilióegy darab WildFly instance, mindegyik egy-egy önálló alkalmazás. Szükséges-e az 23. alkalmazás támogatójának a többi alkalmazás beállításait megismerni? Szükséges-e az azok által használt datasource-ok hozzáférési adatait megismerni? Szükséges-e egy adatbázis, mint alkalmazáshoz kapcsolódó komponensnél sysdba-szintű jog akkor, amikor az a DB az adott alkalmazáson kívül csillió+1 másikat is kiszolgál, vagy elég egy, amivel az alkalmazás sémájához r/o hozzáfér?
Volt olyan élesbe menetel küszöbén álló motyó, amit a fejlesztő támogatásával (azaz "támogatói" szerepkkörben került a képbe a fejlesztő) közösen raktunk össze - Ő már csinált ilyet a saját fejlesztői  környezetben, én meg tudtam nézni az scb-n, hogy mit csinál(t) :-)
 

" Nem feladata az alkalmazás éles működését vizsgálni, abban anomáliákat keresni, bugokat vadászni éles környezetben. "

Aha, és kinek feladata? Üzemeltetőnek? Honnan lenne meg a kompetenciája hozzá, főleg úgy, hogy sokszor még a business requirementtel sincs tisztában?

 

" amikor az a DB az adott alkalmazáson kívül csillió+1 másikat is kiszolgál "

Kapok egy random db hibát a logba. Ha nem látom, hogy mi történik a DB szerveren, honnan szüljem meg, hogy most amiatt van gebasz, mert a az én alkalmazásom szar vagy azért, mert valamelyik másik a 200 microservice közül? Főleg, ha azok még kommunikálnak is egymással és egy-egy folyamat több servicet is érint?

A fejlesztőnek nem feladata, arra való a támogatói szerepkör. A kettő lehet egy és ugyanaz az ember is, de szerepkörileg nem azonosak. "Kapok egy random db hibát a logba." - Marhára nincs közöd ahhoz, hogy az adott DB-szerveren az alkalmazásuser(ek) hatókörén túl mi történik, milyen adatok mozognak, milyen folyamatok vannak. Alkalmazást támogatsz (támogatói, nem fejlesztői sapka megint!), nem DBA vagy. Ha a motyód nem képes korrekten, supportáláshoz elegendő mértékben logolni, akkor javítsd ki, hogy tudjon. Vagy te saját magad tanulj meg kérdezni a DBA-szerepkört betöltő személytől, hogy ugyan, mi történt akkor, amikor a motyód képes volt "gond van a db-kapcsolattal" szintű hibát betolni a logba.

Csak én tartom furának azt az elképzelést, hogy csináljak valamit, majd anélkül, hogy halovány lila fingom lenne, hogy ki, milyen környezetbe és hogyan fog kikerülni, futni elvárja bárki is, hogy menjen? :)

Pont az ilyen senki nem lát semmitből van az, hogy hetekig tud pattogni a különféle részlegek közt a hiba.

Jó, akkor fordítsuk meg a dolgot: adott egy microservice architektúra, amiből a csapatom csinál 2-3 db-ot (+ a tooljaikat), meg van mondjuk három környezet (DEV, UAT, PROD). Minden cloudban, infrastructure-as-a-code van, bár az, hogy cloud, igazából lényegtelen. Aztán van, hogy vannak igények, amik miatt hozzá kell nyúlni az infrához, pl. self-hosted DB-ből átállunk a cloud provider DB-jére és mivel én jobban tudom, hogy mi kell az alkalmazásnak, ezért én csinálom meg a DB-hez tartozó terraformban meg ansibleben a szükséges dolgokat. (Hogy miért van mindkettő, az most lényegtelen). Vagy az alkalmazásomnak skálázódnia kell bizonyos követelmények mellett, ott szintén beállítom a dolgokat. Vagy a composeba a traefik szabályokat, akármi. Ahhoz, hogy akár csak DEV-re ki tudjon menni a cucc és ott működni tudjon, ahhoz ezeket mind be kell állítani, méghozzá nekem.

Ok, telepíteni és módosítani tényleg csak a DEV-en tudok és ott is a master ágra csak az  pull request tud bemenni, amit az infrás csapat is jóváhagyott a code reviewen, UAT-ra meg PROD-ra már ők tesznek ki dolgokat. Viszont, ha szigorúan nézzük a "fejlesztő csak ne pofázzon bele, hogy mi legyen" című dolgot, akkor már ezeket sem csinálhatnám meg, hanem egy "adminhoz" kellene fohászkodnom, hogy csinálja meg.

Az, hogy te írod a kódot/konfigot, ami majd az élesben dolgozik, az nem azonos azzal, hogy rw/admin/root hozzáférésed van a prod környezethez. A "fejlesztő"-n én nem a kifejezetten kódhegesztő dolgozót értem, hanem azt a team-et, akik az alkalmazás(oka)t kód/base konfig/infrastruktúratervezés szinten összerakják - az üzlettel, DBA-kkal, infrastruktúra-üzemeltetőkkel egyeztetve, természetesen. Azaz "belepofázhat", de mindenképp egyeztetés/megállapodás eredménye kell, hogy legyen az, ami az éles infrát érinti,mint változtatás.

Aztakurva...

Hát jó. Ha ott tartunk, hogy a cég bármely részlegének alközlegény-hettese megmondhatja hogyan kell végeznem a munkámat, akkor engedtessék meg, hogy jó szándékú tanáccsal ellássam a fejlesztőket.

  1. A memória nem végtelen, és nem a mennyből jön mint valami manna. Manapság már tényleg nem kell KB-okért kell harcolni, de igenis lehet, és kell kódot optimalizálni. Lehet nekiállni!
  2. Ha 24 CPU magot adok, mert annyit kértél, akkor tessék használni! Nem fintorogni kell, hogy multithread-re írni nehéz, hanem megcsinálni, és pláne nem még két 24magos gépet kérni, mert az elsőt sem tudja rendesen tekerni.

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

Azure-ba feleslegesen beraknak 10 szervert, legyen mondjuk vmi compute-optimized csilliárd vCPUs vas. Annak a havidíja mondjuk 2ezer dodó/gép. Év végéig az lesz mondjuk extra $240 ezer. Szerencsés esetben az Azure költséghelye ugyanaz az IT részleg lesz, ahol te is melózól. Ergó a te csapatod pénzügyi teljesítményét rontja le a pazarlás, és évvégén emiatt kisebb lesz a bónuszpersely. Szóval igen, ha nem is a havi fizudból, de kimutathatóan kevesebb lóvét kapsz majd pulykapénzként.

Ne mondd, h. az MS-nél nem hasonlóan fizettek titeket is a spórolás jegyében!?

Szerencsés esetben az Azure költséghelye ugyanaz az IT részleg lesz, ahol te is melózól.

Hogy mi? :D

Ha az XY cost center igenyli a "csilliárd vCPUs" gepet, akkor az XY cost centerre lesz beterhelve a koltsege. Hogy mashogy lehet meg csinalni?

Ahahahahaha. :) Nálunk a nyomtatók és Office365 meg ilyesmik is "ájtiköccség" volt, aztán jött a sokba kerültök, persze mert magunknak bérlünk 5 nyomtatót poénból, meg soksok Office licenszet, így megy egy ez. :) Nem mondom, hogy megnyugtat, hogy máshol is előfordulhat ilyen.

Nem az nem. :) Egyébként már a saját dugájába dőlt a történet, nem érint ez már. Itt sokkal inkább az motiválta a "köccséghejet", hogy bárhol lehet, csak ne náluk, hát akkor legyen az ájtin, mégiscsak egy nyomtató vagy licenszdíj... Teljesen mind1, az idő és élet próbáját nem állták ki. :)

Nem, azt nem mondhatja meg, hogy hogy végezd a munkádat, de azt megmondhatja, hogy mi az igénye, neked meg illik erre odafigyelni.

A válaszodban rögtön azzal jöttél, hogy alapvető hülyeségeket kérnek a kollégák. Ez egy normális helyen nem így van.

1. Simán lehet, hogy a kódot már nem költséghatékony tovább optimalizálni, mert az optimalizálást végző tesztelő/fejlesztő/manager fizetésének kifizetése + az általuk nem új feature-ökbe feketett munka hiányából származó veszteség többe kerül, mint egy új 24 processzoros gép.

2. Ha olyan remekül értesz a multithreadinghez, a fejlesztő meg nem, akkor miért nem magyarázod el neki, hogy mit csináljon jobban? Ezzel együtt sokkal jobban tolnátok együtt a cég szekerét, mint hogy egymásra fújtok.

A dolognak több oldala van - egyedileg kell vizsgálni az összes esetet, mert nagyon nem mindegy, hogy a valós üzleti adatok mennyisége nőtt meg, és azért kell több memória a motyónak, vagy épp azért, mert leak-el mint'állat, és csak így lehet "megúszni a hét végi "szokásos" app restart-ig. Előbbi esetben nincs kérdés a meóriával kapcsolatban, utóbbi esetben viszont verni kell a tamtamot a memleak kikalapálásáért - viszont mivel az üzletnek mennie kell, így oda kell adni azt a redvás +nGiB RAM-ot az alkalmazásnak.

Az egy/többszálú működés, illetve a jól skálázódik-e n magra kérdéskör _nem_ üzemeltetői kompetencia. Üzemeltetőként csak arra lehet ráhatása az embernek, hogy jelzi azt, hogy az adott alkalmazás legfeljebb n magot hajt ki a huszoncsillióból (statisztikákkal alátámasztva), és ilyen szempontbl az üzem nem látja értelmét további magokat allokálni a motyó alá. De megint csak vezető szinten kell, hogy eldőljön, hogy mi az optimálisabb: több magra is jól skálázódóra átírni a kódot, vagy venni egy másik vasat, és annak a működést finanszírozni - az alkalmazás több gépen egyidőben történö párhuzamos futtatásra való alkalmassága esetén. Mert ha csak egy példányban futhat az "egész univerzumban", akkor a nagyobb/gyorsabb processzor csak rövid távon fog megoldást adni - utána megint szembe fog jönni a skálázódási korlát.

Simán lehet, hogy a kódot már nem költséghatékony tovább optimalizálni, mert az optimalizálást végző tesztelő/fejlesztő/manager fizetésének kifizetése + az általuk nem új feature-ökbe feketett munka hiányából származó veszteség többe kerül, mint egy új 24 processzoros gép.

Sokszor hallottam korábbi melóhelyen ezt a kifogást a gondolkodás ellen.

Két kérdésem van:

  1. Mennyi szervert kell venni, és üzemeltetni (feleslegesen, mert ugyebár optimalizálni is lehetne), ahhoz, hogy a fejlesztőnek mégis megérje gondolkodni?
  2. Mennyire jövőálló az a kód, amit nem éri meg optomalizálni, csak a vasat tólják alá nyakló nélkül.

Nincs szar kód, csak gyenge hw... értemén...

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

Miért kellene egy kódnak jövőállónak lennie? (Itt a jövőállóságon azt értem, hogy X év múlva is használni fogják, ahol mondjuk X>3 - és nem azt értem, hogy a jelenlegi X felhasználó/tranzakció/akármin tízszeresét is ki kell, hogy szolgálja). Az IT rohadt gyorsan változik, az IT-s assetek (pl. kód) értéke iszonyú gyorsan amortizálódik, nincs értelme az időben jövőálló kódnak.

Ezt lehet nem szeretni, nyugodtan.

Ezt lehet nem szeretni, nyugodtan.

Köszönöm, hogy megengeded, élek a lehetőséggel. :)

Megjegyzem, szerintem annak akinek van mivel, annak elvi kötelessége gondolkodni, és az optímális működésre törekedni. Akinek meg nincs ehhez muníció annak jól jöhet, hogy paradox módon pont az órabére miatt nem kell gondolkodnia.

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

Nagyon egyszeru, egy fejleszto berkoltseggel, irodaval, geppel, ingyen kaveval, stb. also hangon 8-10k per ora. Sot. Es nyilvan ha optimalizalasrol beszelnuk, akkor nem a legolcsobb, leghulyebb fogja csinalni. Az a kerdes, hogy ha X ora munkaval Y forintot lehet lefaragni a hardverkoltsegen, akkor 10000*X < Y, vagy nem. Nyilvan ez egy leegyszerusitett pelda, de a lenyeg atjon.

Nincs olyan, hogy "optimalis mukodes". Optimalizalni valamire lehet, csak az egyik opcio a hardverigeny csokkentese. Ugyanilyen jo cel lehet az is, hogy konnyen karbantarthato legyen a kod, vagy gyorsan lehessen valtoztatni rajta, vagy hibaturo legyen a mukodes, vagy olcso legyen hozza a fejleszto, stb. 

  1. Ha már egyszer 8-10k órabére van a fejlesztőnek, igenis elvárható hogy gondolkodjon érte. Nagyon perverz dolognak tartom azt, hogy az az ember akit az esze miatt túlfizetnek, az pont a túlméretezett órabére miatt ne legyen hajlandó gondolkodni.
  2. Elszomorítónak tartom, hogy az üzemeltető munkáját konstanskét kezeli mindenki, mintha mintha mindegy lenne hogy 2, vagy 200 servert üzemeltetünk. Hiszen "ez csak üzemeltetés".

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

Ha már egyszer 8-10k órabére van a fejlesztőnek, igenis elvárható hogy gondolkodjon érte.

De gondolkodhat olyanon is, amibol utana a kovetkezo honapban is lesz penz fizetest osztani, es igy tovabb a vegtelensegig. :) Nem azt mondom, hogy tilos optimalizalni, hanem meg kell nezni, hogy mivel jarunk jobban. Meg hogy mire optimalizalunk, ez valahogy mindig kimarad a kepletbol.

Elszomorítónak tartom, hogy az üzemeltető munkáját konstanskét kezeli mindenki, mintha mintha mindegy lenne hogy 2, vagy 200 servert üzemeltetünk

Mar ne haragudj, de szerintem senki nem mondott olyan egbekialto ostobasagot, hogy mindegy. Ha "optimalizalassal" a gepigeny 99%-kal csokkentheto (hogy mi? :D), akkor igen, optimalizalni kell. Nezzunk inkabb realisztikusabb peldat, neked, mint uzemelteto mekkora plusz terhet jelent, ha egy 32 giga RAM-os VM kap meg 32 gigat? Ha a fizikai gepek darabszamaval egyenesen aranyos az uzemelteteshez szukseges embernapok szama, akkor valami nagyon nagyon rosszul mukodik.

Ezen szálban fentebb plusz gépről volt szó.

Nyilván, ha a fejlesztő kódja nem fér bele a 32 giga RAM-ba (szerintem ez sem mindig normális), akkor a VM kap még. De erre vonatkozóan írtam, hogy a RAM nem végtelen, és nem a mennyből jön mint valami manna. A gondolkodás alól szerintem akkor sincs kibúvó. Pláne nem a kiemelkedő órabér, amit a fejlesztő elméletileg a gondolkodási képességéért kap.

Nem kell egyetértenünk. Elfogadom a véleményedet. De kérlek próbáld te is megérteni az enyémet.

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

Ertem amit mondasz, en arra probaltalak ravezetni, amit Zizi nalam frappansabban megfogalmazott lentebb:

Az a baj ezzel az érveléssel, hogy az "optimális" szót arra használod, hogy "neked tetsző", pedig a kettő nem feltétlenül ugyanaz.

Optimalizalni sok dologra lehet. Valamikor az a fontos, hogy egy fix hardveren elfusson a cucc, valamikor pedig egy masik cel az adott, es a hardver meretezese rugalmas. Ez a masik cel lehet az, hogy konnyen ertheto legyen a kod (ertsd: a logika), vagy hogy hamarabb lepjunk piacra a termekkel, mint a versenytars.

Nekem nincs fix hw. Nekem erőforrás van, amit szolgáltatásokhoz allokálok. Ez az erőforrás nem végtelen. (Mintha már mondtam volna...) Persze mindig lehet még több servert venni. De ha az az indoklás, hogy "csak a fejlesztőnek gondolkodni ne kelljen", az nálam lecsap egy biztosítékot.

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

Ha az erőforrásigényben azt látod, hogy valami 1-2-x hónap múlva el fog fogyni, akkor a főnököd felé jelzed a problémát, hogy vagy kell még vasat venni/bővíteni (annak minen következményével, pl. leállás, plusz sw költség, stb.), vagy optimalizálnak a kódon, illetve alakítanak az igényeken, hogy "beleférjen" a jelenleg rendelkezésre álló erőforrásokba az elvárt szolgáltatás.
Ha van közvetlen "beszélgetés" az erőforrástervezés/üzemeltetés/fejlesztés között, akkor meg direktben jelezheted, hogy x erőforrás használatával kapcsolatban optimalizálás/átalakítás szükséges. Ha még javaslatot is tudzs adni, hogy milyen irányban lehetne lépni, az bónuszpontot ér :-)

A történet nem arról szól, hogy a fejlesztő (senior fejlesztő nyilván) nem tudná optimalizálni a kódot, ha akarná. Sokkal inkább arról van szó, hogy 10 feature-rel el vannak maradva,

amit ki kell találni, le kell fejleszteni, van 5 másik dolog, amit neki kellene pocolnia, közben meg a junior fejlesztőket is kellene mentorálni, meg végtelen mennyiségű meetingen ülnie.

Egy ilyen helyzetben az, hogy mondjuk pár hetet elszórakozzon az optimalizációval, egyszerűen nem fér bele. Nem csak azért, mert a fizetése több, mint amennyibe esetleg a szerver

kerülne, hanem az az érték, amit az alatt a pár hét alatt előállít (az ő hozzáadott munkája miatt elkészült featureök) az nagyságrenddel több, mint amennyibe akármilyen gép is kerülne.

Értem.

És az a bizonyos 10 feature szintén olyan, hogy optimális, hatékony működésért gondolkodni nem éri meg. Működjön ASAP. És vissza is értünk az eredeti kérdéshez. Ami szavaid szerint önmagát sokszorozza. Így az átgondolt, hatékony kód végérvényesen ki van zárva.

Fasza.

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

Szerintem szét kell szedni a problémát. Az egyik, hogy átgondolt legyen a rendszer, alapvetően architekturális szinten, hogy képes legyen skálázódni (akár nagyobb vassal, akár több vassal). Ezt általában sikerül

megugrani. A másik, hogy a lassan futó kódrészletek ki legyenek mérve, és optimalizálva legyenek. Ez az, amire általában nincs idő, amennyiben nem embedded fejlesztésről van szó. Erre, mint fent is írták, akkor fog sor kerülni, amikor az üzleti oldal ezt betervezi. Valójában a hw költségek a fejlesztői bérekhez és az általuk előállított értékhez képest elhanyagolhatóak, de van egy olyan szint, ahol már esetleg érdemes ezzel foglalkozni.

A működjön ASAP igény az nem a fejlesztőktől jön, hanem a biznisztől, és valójában jogos: ha mondjuk elkészül a feature, és be lehet húzni egy 50 milliós bizniszt vele, akkor ki a csodát érdekel egy 100 ezres ram modul. Ennyi az eszkortlányok órabére...

 ki a csodát érdekel egy 100 ezres ram modul. 

Amit be kell építeni egy serverbe. Amit üzemeltetni kell. Amihez hozzá kell hangolni a db-t, esetleg php-t, vagy a különböző service-ket, hogy ne legyen felesleges.

De az ehhez ellőtt üzemeltetői órák ára sosincs a pakliban.

Nyilván azért, mert az üzemeltető bére nincs úgy túlméretezve mint a programozóé.

Félreértés ne essék, nem sajnálom a programozó bérét. Csak úgy gondolom, hogy azt a pénzt az eszéért kapja, pont mint én az enyémet. De tőlem elvárják hogy gondolkodjak érte - jogosan -, a programozó meg ne gondolkodjon, mert nem éri meg. Agyvérzés...

Ezekből arra következtetek, hogy ha az üzemeltetők úgy keresnének mint egy programozó, nekik is tiltaná a management hogy rendesen üzemeltessenek, mert drága. (Ez hova vezetne?)

Addig viszont amíg a programozó (túl) vastagon van megfizetve, addig nekünk üzemeltetőknek kell megoldani minden problémát, amit a fejlesztésnek nem ért meg megelőzni.

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

Valahogy igy. Egy ido utan annyira fel tud duzzadni a kornyezet, hogy kezd fajni az uzemeltetes koltsege. Olyankor jonnek az olyan uzleti igenyek, hogy pl. elso korben akkor -300 VM, -4TB RAM, jo? Bocs nem tudjuk. Me' nem? Es jonnek az idegorlo meetingek, a magyarazkodas hogy miert jutottunk el idaig. Tolem kerded? Ne mar :)

En lassan-lassan elfogadom hogy uzleti dontes optimalizacio helyett erobol megoldani sokmindent. Csak ennek a hatranyai fullra az uzemeltetesen csapodnak le, illetve ennek is megvan a maga koltsege (amiert nem nalunk kellene sirni).

echo crash > /dev/kmem

Az elmúlt 8 évben tucatjával csináltam ehhez hasonló optimalizálásokat.

Minimális rutinnal rá lehet jönni, hogy hogy lehet pillanatok alatt elvenni az élét a hasonló idegőrlésnek - fel kell írni, hogy ki-mikor-mit-miért kért erőforrást, aztán be lehet mutatni a táblázatot, amikor kell. Ezzel a magyarázkodás rész megoldva.

A másik részére meg annyit, hogy a tapasztalataim alapján az eseteknek kb. 90%-ában simán visszanyesve az erőforrásokat nem változik semmi, ezt egy jó monitoring ki tudja mutatni. A maradékból mondjuk 9%-ban ugyanez van, csak még pluszban szervezni is kell egy kicsit, pl. hogy két dolog ne történjen egyszerre. A maradék 1%-ban kódot kell optimalizálni. :-)

1, Kérd meg az árát a munkádnak. Most ott tartunk, hogy meg lehet tenni, mert annyira nincs ember. (én ebben az évben 2x váltottam. nem véletlenül.)

2, Az, hogy valamit erőből van melóból oldunk meg, az legtöbbször üzleti oldalon dől el, valamilyen követelmény formájában. Az üzletet - amíg nem fáj - nem érdekli, hogy hogyan kerül az adott probléma megoldásra, őket az érdekli, hogy legyen meg a termék, amit már eladtak az ügyfélnek, pedig még ki sincs fejlesztve.

3, Senki nem mondja, hogy ne gondolkodjon a fejlesztő. De a fejlesztőnek egy adott üzleti környezetben kell döntést hoznia. Megoldom gyorsan, vagy megoldom jól. Ha ez utóbbit választom, akkor vajon határidőre elkészülünk? Sokszor nem a válasz.

4, Rendes üzemeltetés: az üzemeltetés is drága. A HW az olcsó, egy adott méretig. A legtöbb termék nem éri el ezt a méretet. Ha igen, akkor újratervezés van, és majd szépen behúzzák az optimalizálást, mint feladatot. Aminek lehet, hogy újraírás a következménye. Miért nem írták meg elsőre optimálisra? Mert mondjuk még nem látták át az egész domain-t, amiben dolgoznak, a terhelést, ami valójában éri az adott feature-t, a technológiát (pl. új könyvtár) és annak határait/korlátait. Ha mindezeket figyelembe vesszük, lehet, hogy éppen az volt a jó megoldás, hogy adtak egy gyors megoldást, aztán majd az új információk és a tapasztalat birtokában újraírják.

Hát benned nagyon sok keserűség van, az látszik... :-(

Az üzemeltetők és a fejlesztők bére között általában valóban van különbség, nem is kicsi, de egy tényleg jó üzemeltető simán kereshet annyit, mint egy jó fejlesztő.

Megint előjött ugyanaz, amit már írtam korábban. Azt írod: "tőlem elvárják, hogy gondolkodjak érte" + "a programozó meg ne gondolkodjon" - nos, a programozótól is elvárják a gondolkodást, csak nem azon kell gondolkodnia, amin Te szeretnéd, hogy gondolkodjon, mert a dolog üzleti részéhez nálad jobban értők azt látják, hogy mással több értéket teremthet. Tök egyszerű matek, ha 100 ezer Ft a RAM, 100 ezer Ft, hogy az üzemeltető csinálja vele, amit csinálni kell, és 250 ezer Ft lenne a fejlesztő bére, hogy ne kelljen RAM meg csinálás, akkor kijön, hogy a fejlesztő ne csináljon ezzel semmit.

Ez egy ilyen viszonylag kegyetlen világ.

Hát benned nagyon sok keserűség van, az látszik

Szerencsére nincs. De volt, és régi sebeket tépett fel az a fenti mondása a kollégának, hogy inkább hw-t kell venni, hogy annak akit az eszéért fizetnek ne kelljen gondolkodnia.

Régi helyen többször láttam, hogy az üzemeltetést szidták a lassú funkció miatt. Mikor trace-elve, naplókkal, mért értékekkel elmagyaráztuk hol szar a kód, azt mondta a fejlesztő, hogy neki ezt majd két nap javítani. Olcsóbb a CPU meg RAM.

Értem az üzleti részt, de nekem úgy tűnik hogy az üzleti logika mögé a lustaság, és munkakerülés szépen elrejthető. És sajnos láttam fejlesztőt aki élt ezzel a lehetőséggel, és pont ezen zászló alatt szidta az üzemeltetést.

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

Nyilván azért, mert az üzemeltető bére nincs úgy túlméretezve mint a programozóé.

#define uzemelteto

A vilagon kb. az osszes pozicio az uzemeltetotol a metrovezetoig ugy mukodik, hogy eloszor sokan csinaljak, keves penzert, aztan jon valami atalakulas, ami miatt kevesebb, de specializaltabb emberre van szukseg. Abban a cegben, ahol a 100 rugos extra RAM-hoz szamottevo eroforrasba kerul "hangolni a db-t, esetleg php-t", ott sok ember fog manualis munkat vegezni, es keveset kapnak. Ezzel szemben ha atnezel a google-os threadbe, akkor az ott dolgozo SRE-k tizedannyian sincsenek a szerverpark meretehez kepest, mint egy atlag kkv-ban, viszont vastagon tobbet is keresnek.

Kár kiragadni a kontextusból, magát a jelenséget mutatta be. Szerencsére egy 100e-s RAM modul vagy proci vagy bármi manapság azért nem issue sehol, ahol meg igen, azok magukra vessenek tényleg. Az remek szokott lenni, amikor a bemondott bővítés bekerül a gépbe, az üzemeltetői vélemény ellenére, és persze kiderül, hogy tényleg alig volt érdemi hatása. Arról a jelenségről van szó, hogy a fejlesztési vagy bármilyen oldalról jön egy igény, amihez vagy mondanak nagyjábóli hw-t vagy nem. Ez ennek megfelelően elhelyezésre/kialakításra kerül, működik stb. Aztán jön egy fordulópont, amikor az üzemeltetési oldal terhessé válik, azaz a szaraszerver effektus. Eközben az igazság az, hogy finoman szólva is nagyvonalúan bántak az amúgy mindenképp korlátos erőforrással és próbálják az üzemeltetésre tolni, hogy "oldjátokmeg".

Ha az üzemeltetés a fejlesztőre visszamutat, akkor jön a "legyél együttműködő", "a userért vagy" c. duma, de közben látványosan a kód rossz valahol. A másik, hogy felvillantod az infra bővítést, amikor jön a "már eddig is nagyon sokba került" c. műsor... A kedvencem az "értések meg, nagyonagyon drága a fejlesztői idő", aha, akkor mi a ....ért nem úgy dolgozol, mint aki sokat kap a munkájáért? Nekünk mindent meg kell érteni, de a másik oldalnak nem? Most együttműködőnek csak nekünk kell lenni, ami igazából azt jelenti, hogy bokacsattogósan fülünkfarkunk behúzva "csináljunk valamit"? Természetesen soksok üzemeltetői órába, ami ugye ingyen van, kerül az utánajárás, hibakeresés, logok és tesztek prezentációja egy-egy ilyen esetben, egészen onnan, hogy "hát izé, még nem sikerült a MyISAM-ról lejönnötök?". Ez a LAMP-os történettől független, simán minden vonalon tudnak hasonló szinten produkálni.

A másik kedvencem, amikor egy random appot akarnak futtatni, felpattintják, hiszen az ilyen kis pattintósm gyakorlatilag az üzemeltetés semmit sem tud erről, nem kérdezték meg érdemben. Ha a random app különleges igényű, akkor jön a kamillázás. Kiderülnek a hw követelmények, aminek igazából megfelel a mostani környezet is, de mégis az elmondás szerint nagyonlassú... mi a javaslat... hát mi... Indulna az órákig tartó teszt és keresgélési fázis, de persze ilyenkor hirtelen nagyondrága, nem tudjuk kifizetni, hát akkor most hogy van ez?

Még mindig nem érted. Idézem: "Ha be lehet húzni vele egy 50.000.000-ós üzletet vele, akkor ki a fenét érdekel egy 100.00-es ram modul" Ezt úgy értsed, hogy azt is leszarják, ha beépítéssel, szakállas üzemeltetővel és a neki szánt játszós géppel ez az ár 1.000.000, akkor is megéri vastagon, tehát leszarják. Na most az sem érdekel senkit, ha Jóska üzemeltető egy újabb vasat kap a keze alá, majd kevesebbet piszkálja az orrát. Mindenesetre engedd el azt a buta gondolatot, hogy egy üzemeltetőnek ugyanannyit fognak fizetni, mint egy komplex feladatok ellátására alkalmas, jól képzett, tapasztalt (több, mint) programozónak. Szép is lenne!

Fentebb ejelztem, hogy nem vagyok irigy. Nem érdekel a fejlesztő órabére, ahogy a takarítóé sem, függetlenül attól, hogy az én béremnél több-e, és mennyivel. Én egy minimális szakmai igényességet várnék el attól, aki munkát végez, bármi is a munkája.

De ha már képességekről beszélünk, akkor engedd meg, hogy emlékeztesselek, hogy neked addig jó, amíg az üzemeltető

piszkálja az orrát

továbbá jelzem, hogy egy server- vagy hálózat üzemeltető is

komplex feladatok ellátására alkalmas, jól képzett, tapasztalt

szakember. Eddigi hozzászólásaimban figyeltem arra, hogy a fejlesztő munkáját ne degradáljam, és ne éreztessem valótlanul, hogy limitáltan intelligens. Mert a fejlesztő szerintem okos ember. Ezzel szemben itt most nem túl burkoltan érezteted, hogy az üzemeltetés, ló*szt nem csinál, nem ért semmihez, a munkája kb. betatanított segédmunka. Tisztelettel kérlek, hogy ezt gondold át, és a "komplex feladatok ellátására alkalmas, jól képzett,tapasztalt" jelzőt ne sajátítsd ki a programozókra.

Megjegyezném azt is, hogy az optimális, jó kóddal szemben, tisztán pillanatnyi profit alapon utasítani a programozót a szar kód készítésére erős rövidlátásra vall, ahol az a rövid látás is meglehetősen szűk látókörű.

Nem baj ha ezt nem érted. Nem is kell, csak le kell tolni minden problémát az üzemeltetésre, 'oszt eziskész!...

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

Egy rakás olyan dolog van az IT-ban, amiről tudjuk jó "elméletileg jobb", de a gyakorlatban nem működik valamiért. A mikrokernel, a RISC utasításkészlet, az optimalizált kód, a test-driven development mind ilyen. De az élet más területein is, pl. a frissen facsart narancslé egyértelműen jobb, mint a dobozos, mégis van dobozos is. Egy csomó esetben ezek a gyakorlatban nem működnek, sokszor az emberi gyarlóság miatt.

Ezekre írtam korábban, hogy lehet nem szeretni, meg lehet bosszankodni, de ettől nem nagyon változik semmi, legfeljebb cudarabbul érzed magad. :-(

Értem. De a nekem tetsző nem biztos hogy rossz. ;)

A management számára gyakran nem szempont hogy a motyó üzemeltethető legyen. Adott esetben költöztethető, 1-2 perc alatt restore-olható.. stb. Egy szempont van: a fejlesztő drágán gondolkodik. Szokjon le róla!

Az üzmeltetés meg teszi a dolgát (bármit is dob a sors), hiszen azért fizetik.

Nem vagyok biztos benne, hogy érted mire gondolok, de azért bízom benne. ;)

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

A management számára [...] Egy szempont van: a fejlesztő drágán gondolkodik a profit

FTFY :) Abba az iranyba fog menni a tervezes, amerre kevesebb a koltseg. Ha a hardver olcso, akkor azt vesznek, ha a fejleszto, akkor azt. Ennyi. Ebbol csak a fejlesztok es az uzemeltetok csinalnak ideologiai kerdest, mert erintettek benne.

+1, tapasztalatom szerint hosszabb tavon olcsobb (profitabilisabb, ha ugy tetszik) rendesen-igenyesen-koltseghatekonyan osszerakni valamit, mint a "jovanazugy, sietes van, majd occsositunk / reszelunk rajta kesobb" hozzaallas. De ahogyan fentebb irta a kollega, ez altalaban nem DEV vagy OPS hataskor.
Sales mestereim tanitasait kezdem a magameva tenni: 5PM, laptop lecsuk, uzleti dontes hogy nem maradok +10 percet se, kivedeni egy nagyobb borulast. Mindennek ara van.

echo crash > /dev/kmem

Az üzemeltetés tudja a tényleges erőforráshasználatot és annak a trendjeit, nem az üzlet, úgyhogy a tervezés ilyen alapjaihoz szükséges információkat ott kell összeszedni, illetve ott kell döntéselőkészítéshez megfelelő mennyiségű és minőségű inputot adni.

+1

Csak nem szabad meglepődni azon, ha pl. kijön, hogy nem éri meg évi 100 millió Ft-ot megspórolni (!!!), mert (és itt jöhet bármi, pl. jó magyar szokásnak megfelelően az országos politika). Akit ez zavar, az dolgozzon külföldre, ott is ilyen, csak nem tudsz róla annyit :-)

Pontosan! Egy inputot ad az üzemeltetés a döntéshez, egyébként a munkaideje 98%-ban üzemeltet. Ennyi és nem több tartozik rá. Hazudhat is, de az tuti bukta lesz. A döntést megkérdőjelezni nem dolga. A dolga a döntés tudomásulvétele, mivel a többi inputról halvány lila fingja sincsen. Kezdjük el megérteni, hogy az üzemeltetés nem a piramis csúcsán van, hanem a talpa annak. Az egyik, még csak nem is az egész.

Mókás, hogy egyes adminok még mindig azt hiszik, hogy mások vannak ő érte és nem ő van az userekért, customerekért, szolgáltatásért.

Az IT olyan, mint a takarító a cégnél: önmagában zéró hasznot termel, ellenben szükséges.

Ha nem tetszik, rossz szakmát választottál.

Szerintem ha a fejleszto is a szolgaltatasert van, akkor az IT adminok is. Ha egy bloatware fostomlot gyart egy fejleszto/csapat, akkor az senkiert nincs, csak a munkaido veget varja. Ugyan ez vonatkozik a sysadminok kezzel osszehakolt cuccaira. Viszont ha minosegileg normalisat gyart mindketto akkor nincs konfliktus.

Amugy mind a fejleszto es admin is tud negativ hasznot termelni. Ha fos a kodminoseg, akkor az nem haszon hanem frusztracio inkabb minden oldalrol. 

“Ugyan ez vonatkozik a sysadminok kezzel osszehakolt cuccaira.”

Akadjunk mar le errol, teljesen nyilvanvalo, hogy nem minden automatizalt az uzemeltetes soran sem, nem minden egyes parameterezest script-ek vegeznek es nem minden deploy-t vezerel a-z-ig az Ansible, ne tegyunk ugy, mintha igy lenne, vagy akar csak, hogy efele haladnank, mert baromira nem ez a realitas, legfeljebb 5-fos startup-oknal, de meg ott is ketlem. Tobbezer fos multinal meg az abszolut science fiction, es igeny sincs ra.

baromira nem ez a realitas, legfeljebb 5-fos startup-oknal, de meg ott is ketlem. Tobbezer fos multinal meg az abszolut science fiction, es igeny sincs ra.

Hat igeny pedig lenne ra, de en amugy pont az ellenkezojet lattam eddig (talan szerencsesen valasztottam munkahelyeket), de mindenhol az volt a cel, hogy minimalisra csokkentsuk a kezzel buheralast. Startup kkv, ahol mondjuk nincs ember, es Az Egyeduli Informatikus ket tonercsere kozott lefuttat egy deploymentet, ott esetleg.

En is sok mindent automatizalok (tobb mint 100 szerver jut ram egyedul, mashogy nem is menne ertekmesen), de messze nincs szo arrol, hogy minden automatizalva lenne es be sem kell egyesevel lepni a szerverekre, mert dehogyisnem kell, akar csak egy-egy egyedi parameter hangolasa, vagy hasonlo miatt, teljesen elkepzelhetetlen a teljesen automatizalt uzemeltetetes. 

A teljes automatizmus talan tenyleg messze van, de torekves mindenkeppen van ra, hogy ilyen "egyedi parameterhangolas" minel kevesebb legyen. Vagy akar nulla. 

A kommentem lenyege inkabb az volt, hogy pont a multiknal van igeny a standardizalt mukodesre, ha egy kkv-nel van 1 db mindenes szerver, azt nyilvan nem Terraformmal konfiguraljak. :)

A Terraform nyilvan csak egy pelda volt, nem az volt benne a lenyeg.

ahol csak Linux szerverbol van 800

Az eleg keves, ott meg lehet egyedi szkriptekkel szorakozni. :D Viccet felreteve, az egyedi dolgokkal az a baj, hogy nagyon konnyu elcsabulni, mert latszolag konnyebb latvanyos dolgokat csinalni, mintha egy de facto ipari sztenderd dolgot kell megreszelni hozza, de hozzutavon konnyen lehet belole egy hatalmas katyvasz, amihez csilliokba kerul embereket foglalkoztatni.

Ja, dolgozni én is dolgozom, csak most ilyen békés üzemeltetős-infrastuktúrás-devopsozós pozícióban, ahol csak meg kell csinálni a dolgokat, nem kell fújni semmit. (Na jó, szólni kell, ha valami viccesen nagy csacsiságot akar valamelyik főnök.) Nyugisabb, mint hitelintézetek migrációjához fújni a fújandót :-)

0. First rule of fight club: vagyis, hogy ezeket az irányelveket nem valami sötét szekrénybe kell berakni, hanem:

 - ismerje mindenki (ne szó szerint, hanem a gyakorlati alkalmazást, kirívó gyakorlati példákkal lehet egy emlékezetes 15-20perces alkotást kreálni kezdésnek, aztán rendszeresen emlegetni, ha épp alkalmazásra kerül belőle valami..)

 - rendszeresen felülvizsgálni :) és finomítani

__

az se árt, ha a megfogalmazáskor a hogyanok mellé a miértek is összegyűjtésre kerülnek, segít a felülvizsgálatkor :)

 - azt meg mondani se kell, hogy ha semmi gyakorlati alkalmazása nincs akkor tökéletesen fölösleges a szájtépés róla, sőt káros, mert csak legyinteni fognak rá az emberek..

Láthatóan gyűrűzik a vita a téma körül, hogy a sysadminok, üzemeltetők, fejlesztők körbe pisált területére márpedig más nem mehet be körbe pisálni. A szélszes meg örüljön, hogy luk van a seggén és kussoljon, ha a sok szir-szar miatt, amit soha nem használ, de a gépére felnyomják image-ből, mert így több idő marad a doom-ra, lassú a gépe. Pedig hát az van, hogy alapvetően igaz ez mind, egészen addig, amíg elő nem kerülnek azok az esetek, amiket csak az élet tud produkálni és igenis a szélszes gépét rendbe kell tenni, mert mégiscsak csinál valamit az a hülye, a fejlesztőt a prod-ba be köll engedni pláne havária helyzetben és hát igen, van, amikor a fejlesztő megmondhatja, hogy hogyan köll üzemeltetni a szart, amit oda tesz az üzemeltetők elé. Eszi, nem eszi, nem kap mást. Én megéltem a totális anarchiát is ebben a témakörben, majd a ló másik oldalára átesett állapotot, amikor írásban kellett engedélyt kérni, hogy havária esetén beavatkozzak - ebből lett két bankszünnap, három állástalan rendszergazda - és láttam azt, amikor gondolkodó emberek csoportja ült be a fenti feladatkörökbe és tudták rugalmasan kezelni a helyzeteket. Ez utóbbi maga a menyország. 

a hűtőben mindig legyen megfelelő mennyiségű sör !

HUP te Zsiga !