Csak, hogy értsd a kontextust: a thread indító rantelésből (64giga ramot evő java service), azt nyilván feltételezem, hogy a kollégaúrnak ahhoz azért van elég infója a fejlesztőktől, hogy legalább funkcionálisan képes legyen elindítani a szolgáltatást. Vagyis van egy működő állapota, ami nem optimális. Innentől kezdve, ha tudna mérni és adatot gyűjteni a rendszerről amíg az működik, máris tudna egy jó kezdő közelítést arra, hogy miket állítson be JVM heap paramétereknek. Azért ez egy sokkal konkrétabb szituáció, mint amiről teljesen általánosan írsz. Nem az általános megállapításaiddal vitatkozom.
Tekintve, hogy ráadásul OOM killert emleget, nekem erős a gyanúm, hogy egyáltalán nincs bekorlátozva a heap használat és a JVM esetleg defaultból valami teljesen elszállt limitet választott (régebben konténerekben futtatott java process-ek jellemzően nem tudták megállapítani, hogy mennyi memóriájuk van és addig növelték a heap-et, amíg az oprendszer hard limitjebe bele nem futottak). Simán el tudom képzelni, hogy ha kezdetnek felparaméterezné [amennyi ram van a gépben] / 2-re (a GC átmenetileg szeret valamennyi extra ramot használni a heap limit fölött), akkor hirtelen elkezdene lényegesen kulturáltabban viselkedni a service-e. Az OOM-et biztosan elkerülné. Ettől még kifogyhat a memóriából a JVM, ettől még lehet tényleg memory leak, saját maga házon belül dobhat OutOfMemoryError exceptiont, de erről már lehet heap dumpot készíteni. Innentől máris van valami, amit oda lehet adni a fejlesztőknek.
Aztán, hogy ő most olyan cégben dolgozik-e ahol vevők lesznek erre és a bug reportját odaadják fejlesztőnek, avagy olyanban, ahol "kuss és nyomogasd a restartot" van, az már egy következő kérdés.
Én az ő szavaiból eléggé úgy éreztem, hogy azt képzeli, hogy a fejlesztőknek "illett volna" maguktól rájönni és megtalálni a hibát. Nem kíván ő nekik debuggolni vagy bármi módon segíteni - legalábbis a szóhasználata nagyon erre utal. Persze, illene a fejlesztőknek kiszűrni a hibákat, erre való a tesztelés, csak az olyan tesztelést még nem találták fel, aminek tökéletes a coverage-e és nem csúszik át rajta semmi hiba (biztonságkritikus rendszerek fejlesztői mit meg nem adnának érte...). Ennek híján viszont az ops-osnak igenis meg kell próbálnia együttműködő partnerként viselkednie a fejlesztők fele, próbálni segíteni nekik megfogni a hibákat, ha már prodba kicsúsztak. Kb mindenki jól jár vele.
Nyilván az együttműködés ideális esete, ha a management eleve úgy szervezi a folyamatokat, hogy ez működjön. Ha a management nem szervezi, akkor még mindig meg lehet próbálni alulról építkezve. Hátha bejön. Hátha a management csak nem ismerte fel, hogy ez mennyire szükséges, de ha látják, hogy működik nem állnak az útjába. Aztán, ha az derül ki, hogy a management kifejezetten akadályozza (pl úgy érzi, hogy belezavarsz, lelassítod az ő feature fejlesztési törekvéseit), akkor menni kell onnan. Kb ennyi.