Na, hát most kb. így érzem magam. Van egy rendszer, "A rendszer", aminek az adminisztrációját már az elődeim is csak örökölték valakitől, aki hírből ismerte azt, aki eredetileg telepítette. Az első volt "A rendszergazda". Azóta, akik voltak, már csak megörökölték és tákolták a rendszert.
Nincs is ezzel probléma, amíg működik. Persze közben olyan apróságok történtek, hogy "A rendszer" eredeti tulajdonosát privatizálták, majd eladták, aztán az új tulajdonos az informatikai üzemeltetést kiadta alvállalkozónak, de saját fejlesztői platformot fenntart. Az alvállalkozó persze egy globális cég, amelyik Magyarországon rendelkezik leányvállalattal, ez pedig kölcsönmunkaerőt is alkalmaz. "A rendszer"en van "Az alkalmazás". A fejlesztőplatform - "A fejlesztők" - "Az alkalmazás" gazdája. "A rendszer"t pedig üzemelteti az alvállalkozó leányvállalata által bérelt kölcsönmunkaerő.
Tudjátok követni? :)
Tegyük fel, hogy van egy néhány száz soros szkript, ami minden 10-15. sorában meghív egy-egy teljesen különböző néhány száz soros szkriptet és esetleg még ez utóbbiak is hasonlóan cselekednek. Kapunk egy szkriptkupacot (beszabehu: a helyesírás ellenőrző szerint van ilyen összetett szó), ami néhány ezer sorból áll. Na, ez csak egy része "Az alkalmazás"nak. Ez a szkriptkupac időzítve fut, minden nap. Persze nem tudjuk, miért "at" -tel vannak időzítve, majd a lefutásuk végén van egy hivatkozás az "at" -re, hogy újraidőzítsék saját magukat. Erre talán célszerűbb lenne a cron, de ilyet nem szabad, mert jön a többi majom és megver azt nem úgy szoktuk...
Megjegyezés: minden "főszkript" külön atjob -bal rendelkezik, külön-külön futnak, de később már csak egyben emlegetem őket..
Aztán "A rendszer"en egyszer csak történik valami. Senki sem tudja, hogy pontosan mi, de szokásjog alapján egy újraindítás megoldja - pedig nem is Windows. Majd jön a meglepetés: az időzített szkriptkupac nem fut automatikusan.
Közelebbről megvizsgálva persze kiderül, hogy a helyzet árnyaltabb, mert a kupac bizony fut, ugyanis regisztrálja adatbázisban egy ennek fenntartott táblában, hogy legutóbb mikor futott, meddig tartott ez és mikor fog legközelebb futni. Újra is időzíti magát a kupac. Meg fut is akkor, amikorra beírja a táblába, hogy ismét fog... és így tovább. Az "at -l" is tanúbizonyságot tesz erről. Ebből logikusan az következik - mivel írtam, az újraidőzítés a szkriptkupac végén van -, hogy lefutottak az utasítások.
A probléma az, hogy a szkripthalmaz nem generálja a tőle elvárt eredményt. De miért? Merül fel a jogos kérdés. A válasz az, hogy fingunk sincs, mert nem készül log. Csak akkor készül log, ha sikeresen végrehajtódott minden, egyébként meg nem. (Unix filozófia inverze Unixon vagy wtf?)
Aztán miért nem lehet ugyan már logot készíteni, kiegészíteni a szkriptet ezzel? - tenné fel a naiv halandó a kérdést. Csak, mert jön a többi majom és megver azt nem úgy szoktuk..
Ki a hibás? Természetesen az üzemeltető alvállalkozó leányvállalata által bérelt kölcsönmunkaerő. "A fejlesztők" nem tudnak semmit, mert hát "nekik nincs is rendszerszintű jogosultságuk, akkor ugyan hogyan??", ők természetesen nem csináltak semmit. "Az alkalmazás" üzemeltetéséről nincs kézikönyv. Soha senki sem írta le, hogy milyen feltételek mellett üzemel, milyen fájlok/könyvtárak megléte, jogosultságok, környezeti változók, stb szükségesek hozzá. Igaz, még csak 18 éve került beszerzésre az alkalmazás, ilyen rövid idő alatt ez nem elvárható.
De még így sem egyértelmű. Mert mi van, ha csak úgy tűnik, hogy lefut a szkript és közben nem, mert nincs joga valamire csak továbblép és újraidőzíti magát? Akkor kinek kell kijavítani a problémát? Persze nem tudják megmondani, hogy mi az a valami, amire hirtelen nem lett joga a szkriptnek. Még csak megerősíteni sem tudják, hogy ezzel van a baj. Ja, azt elfelejtettem, hogy manuálisan indítva zokszó nélkül fut a szkript, állítólag. Csak időzítve nem... állítólag.
De ha nincs hiba logolás, akkor ugyan milyen alapon kérhető számon az üzemeltetőn bármi is? Sőt, ha nincs leírva, hogyan kell üzemeltetni, akkor egyáltalán számon kérhető bármi is? Szokásjog alapján? Ne vicceljünk már...
Ehh... bocs.
Egy kis más, semmi köze az előzőekhez (tévébemondós fordulattal): professzionalizmus Google módra avagy keresd a hibát a képen!
http://pixbin.mmtorrents.hu/pictures/2010-Sep-30/professzionalizmus_pixbin_.png
- subchee blogja
- A hozzászóláshoz be kell jelentkezni
- 1182 megtekintés
Hozzászólások
Ez a gond azzal ha banánért fejlesztenek.
- A hozzászóláshoz be kell jelentkezni
Banánért még csak-csak node gombokért....
--
elhasznalo @ frontend
- A hozzászóláshoz be kell jelentkezni
a
- A hozzászóláshoz be kell jelentkezni
De most senki sem eszik banánt, mert a többiek agyonverik, ha csak eszébe jut.. :(
Gombokat sem láttam, de az egyik szekrényben van egy "szocializmusért" érdemérem egy "kiváló munkás" kitűzővel... ezek is itt maradtak.
- A hozzászóláshoz be kell jelentkezni
Vegre, nem vagyok egyedul.
Nalunk is ugyanez a helyzet, egy teljes rendszer van osszetakolva, amin nem lehet valtoztatni, megerteni meg lehetetlen.
- A hozzászóláshoz be kell jelentkezni
ilyenkor kell elővenni a bpr-t és kihajítani az egészet a fenébe.
- A hozzászóláshoz be kell jelentkezni
Mi nagyon proaktív módon erre tettünk javaslatot a T. ügyfélnek az utóbbi években rendszeresen, minden évben. Természetesen nincs rá pénz, válság van, meg jó ez így.
- A hozzászóláshoz be kell jelentkezni
legyen kinyomtatott, aláírt, archivált dokument arról, hogy te időben szóltál, a többi nem a te problémád.
- A hozzászóláshoz be kell jelentkezni
Van. :)
Ettől függetlenül persze nem lehet annyiban hagyni a dolgot, mert akkor lehúzzák a kusztomer szátiszfeksönt és az nem jó. :)
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
No ticket, no problem?
- A hozzászóláshoz be kell jelentkezni
Valahol azt olvasták (ügyfél) a szerződésben, hogy a helpdesk köteles akkor is újranyitni a ticketet az ügyfél kérésre, ha le van zárva azzal, hogy ügyfél oldali hiba... most ott tartunk, hogy "nem!" - "de!" és ismételgetjük. A helpdesk újranyitja, mert nekik azt mondták és kezdődik elölről minden. :)
- A hozzászóláshoz be kell jelentkezni
A gyakorlatban ez továbbgyűrűzik, és úgy néz ki, hogy:
No ticket, no problem, no resolution, no customer satisfaction, no customer, no money, no job....
Amúgy hogy kicsit ontopic is legyek - nekem is nem tudom már mennyi hasonlót kellett már átnéznem ( HACMP-t próbált már valaki mélyebben megérteni :D ), és nálam az volt a bevett szokás, hogy papíron folyamatosan írtam mi hogy és merre.. Általában pár napos munka után már érteni szoktam mi a fenét csinál az az istenverése...
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..
- A hozzászóláshoz be kell jelentkezni
Erre gondoltam: http://dilbert.com/strips/comic/2008-02-15/
:)
Bár itt gondolom mindenkinek van tapasztalata az ügyfelek csodálatos igényeiről
(legalábbis vannak néhányan ebben a topicban a Nagy Kéktől szerintem)
- A hozzászóláshoz be kell jelentkezni
Most kepzeld el ezt ugy, hogy a nehany ezer soros scriptkupac helyett van egy nehany szaz mbyte-os binaris, ami nem csak siman katyvasz, de aktivan tesz az ellen, hogy megertsek (kamu kodreszletek, onmodosito kod, debugger detection, stb), es megkapod, hogy mivel szorakoztatjak magukat a reverse engineer-ek. :)
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
- A hozzászóláshoz be kell jelentkezni
Egy szkriptkupac kopasz kukac meg két szkriptkupac kopasz kukac az hány szkriptkupac kopasz kukac?!!
- A hozzászóláshoz be kell jelentkezni