software serviceability checklist

Az utóbbi néhány évben többnyire úgy hivatkoztak rám, hogy "on site" engineer. Ez annyit jelent, hogy legalább ugyanabban az országban lakok, ahol a felhasználók többsége. Érdekes dolgokat tanultam, de nagyon ne irígyeljetek, mert néha fájt, meg nem ritkán hétvégémbe is került.

Logging

Korábban ennyire nem érdekelt, hogy mit logol a szoftver. Miután elég sok esetben kell túrkálnom az éles rendszerek logját és bosszús, türelmetlen emberek kérdéseire válaszolnom, kicsit kevésbé vagyok már liberális a logolással kapcsolatban.

1. Például ha a felhasználók / kliens alkalmazások hülyeséget csinálnak, legyen ott a logban, hogy milyen bemenő adatokat küldött a felhasználó és hogy feküdt el a feldolgozás
2. Nem rossz például minden a klienseknek adott hibához egy egyedi azonosítót (talán a legkézenfekvőbb egy UUID) rendelni, és azt a logba is megadni, így nem kell annyit keresgetni
3. Nagyon szép és kedves dolog a fejlesztőktől megkönnyíteni a logok gépi feldolgozását, pl CSV formátumban elmondani a mondandónkat
4. Azt a hülyét, aki hangosan üvölti, hogy log aggregálóra semmi szükség nincs, gyorsan kivégezni, a hullát eltüntetni.
5. Még egy technikai apróság, ilyet sokan csinálnak:
   if(LOGGER.isEnabled(LogLevel.INFO)) {
      LOGGER.info("akármi: " + valami.getName().getFirstName())
   }
   Csodálatos, hogy megpróbálod elkerülni, hogy fölöslegesen összeállítson a gép egy stringet. Biztosan valaki észre fogja venni hogy mit megtakarított a cég az áramon. Most viszont a szoftvered a logolás szintjétől függően működik vagy nem. Elég bosszantó, ha hibakeresésnél megváltoztatod a log szintet és ettől bedől a rendszer.

Health-check (alias 'ping')

Ez egy gyakori feature a legtöbb szoftverben, általában egy egyszerű text, html vagy JSON oldal, ami felsorolja

1. a szoftver verziószámát
2. minden backend (adatbázis, rest service, EJB gányolmány, CORBA dinoszaurusz) elérhetőségét - illetve a hiba jellegét ha nem sikerült elérni.
3. vagy ha ilyesmi szükséges: helyi disk space (például a lognak) vagy a szabad memória információk

Ezt sikerült idáig mindenkinek összehoznia, de mit lehet benne elszúrni:

1. ha a ping túlságosan nehéz műveletet akar végrehajtani az adatbázison - nem csak egy select sysdate from dual hanem konkrétan táblák méretét lekérdezni: select count(*) from all_i_have_ever_done;
   Ilyen esetben ahogy nő az adatbázis, az ember többé már nem meri használni a health-check oldalt, mert esetleg az dönti be a rendszert.
2. ha egy backend hibája miatt a ping nem képes továbbhaladni - vagy beblokkol (lásd előző pont) vagy hiba esetén a többi kapcsolatot már nem ellenőrzi. Ez félmunka.

Publikus rendszerek esetében érdemes levédeni a health-check oldalt, különben fantasztikusan hasznos információkat tud adni az illetéktelen érdeklődőknek.

Reverse Onboarding

Általában üzleti rendszereknél van egy bürokratikus procedúra, amikor egy új szoftvernek engedélyt adnak egy másik rendszer vagy infrastruktúra használatára. Ezt hívják onboarding-nak. Ilyenkor az új szoftver fejlesztőinek kell mindenfélét bemutatnia, például a tesztek eredményeit, a várható terhelést, a kapcsolattartó emailcímet, satöbbi.

Van aki furcsán néz rám, amikor megfordítom a dolgot. Ugyanezeket a dolgokat kérjük szépen mi is, feljegyezzük és bármilyen probléma esetén használni fogjuk. Volt aki azt mondta erre hogy "De hát mi vagyunk a világ legnagyobb XYZ rendszere". Klassz. Akkor ezeket már biztosan sokan kérdezték :-)

Ezek az infók nagyon hasznosak lesznek probléma esetén, ezt sajnos szó szerint érdemes a párna alatt tartani.

1. Tervezett Outage esetén hol kapsz értesítést, mennyi idővel előre
2. Nem tervezett kiesés esetén hol kérhetsz segítséget - és ez ne egy személy legyen lehetőleg, mert mindig az lesz az eredmény, hogy pont egy pár hónapja lepattant az ember
3. Ha sikerül ilyesmit kicsikarni az emberekből: átlagos és maximális válaszidők, elérhetőség, satöbbi (SLA technikai részletei)

Dashboards

Nagyon hasznos, ha van valamilyen dashboard / info radiator ahol összegyüjtheti az ember akár a health-check oldalak eredményeit, vagy a log aggregáló riportjait a hibákról, teljesítmény adatokat. Reggelente ez a legizgalmasabb oldal.

JAVA: Exception handling

Ezt sajnos gyakran kell magyaráznom a kollégáknak, de nem az a baj, ha hibát adunk vissza a felhasználónak. Néha a hiba a helyes válasz. Az a baj ha egy infrastruktúra hibát figyelmen kívül hagyunk és például null-t adunk vissza helyette.
Sajnos a checked exceptions egy tragikusan rossz ötlet volt. Eggyel több ok kotlinra váltani.


Ennyi pillanatnyilag. Egy profi supportos biztosan tudna hozzábökni pár dolgot, de én még mindig főleg hegesztésből élek.