Miért nem foglalkoznak a mérnökök az alkalmazások monitorozásával?

Jó pénteket kívánunk mindenkinek! Barátok, ma folytatjuk a tanfolyamról szóló publikációk sorozatát, az új fordítást osztjuk meg veletek. Induljunk., mert a tanfolyam új csoportjának órái már a jövő hét végén kezdődnek. Tehát kezdjük el!

A monitoring egyszerűenez egy jól ismert tény. Indítsa el a Nagios-t, futtassa az NRPE-t a távoli rendszeren, konfigurálja a Nagios-t az NRPE TCP 5666-os portjára, és kész is a monitoring.

Annyira egyszerű, hogy az már unalmas. Most már megvannak a CPU-idő, a tárolórendszer, a RAM alapvető metrikái, amelyek alapértelmezés szerint a Nagios-ba és NRPE-be érkeznek. De valójában ez még nem is "monitoring" önmagában. Ez csak a kezdet.

(Általában PNP4Nagios-t, RRDtoolt és Thruk-ot telepítenek, beállítják az értesítéseket Slack-en, és egyenesen a nagiosexchange-re mennek, de ezt most hagyjuk figyelmen kívül.)

A jó monitoring valójában meglehetősen bonyolult, valóban meg kell ismernie azt az alkalmazást, amelyet figyel.

A monitoring nehéz?

Bármely szerver, legyen az Linux vagy Windows, definíció szerint valamilyen célt szolgál. Apache, Samba, Tomcat, fájl tárolás, LDAP – mindezek a szolgáltatások többé-kevésbé egyediek egy vagy több szempontból. Mindegyiknek megvan a maga funkciója, sajátosságai. Különböző módszerek léteznek a metrikák, KPI-k (kulcsos teljesítménymutatók) megszerzésére, amelyek érdeklik önt, amikor a szerver terhelés alatt áll.

A fotó szerzője Luke Chesser Gyorsan emlékezzünk vissza, hogyan működik a moduláris aritmetika. Az óra már egy ismert koncepció. Az órák használata Unsplash

(szeretném, ha a műszerfalaim neonkék színűek lennének – álmodozva sóhajtva –... hmm...)

Bármely szoftver, amely szolgáltatásokat nyújt, rendelkeznie kell egy mechanizmussal a metrikák gyűjtésére. Az Apache rendelkezik egy mod-statusmodule-lal, amely megjeleníti a szerver állapotoldalát. Az Nginx-nek van stub_status. A Tomcat-nek van JMX-e, vagy speciális webalkalmazásai, amelyek megmutatják a kulcsfontosságú metrikákat. A MySQL-ben van egy "show global status" parancs, stb.
De miért nem építik a fejlesztők az ilyen mechanizmusokat a létrehozott alkalmazásokba?

Csak a fejlesztők csinálják ezt?

A metrikák beépítése iránti bizonyos szintű közömbösség nemcsak a fejlesztőkre korlátozódik. Dolgoztam olyan cégeknél, ahol Tomcat-alapú alkalmazásokat fejlesztettek anélkül, hogy bármilyen metrikát kiadtak volna, semmi szolgáltatási aktivitás logját, csak a Tomcat általános hibalogjait. Néhány fejlesztő bőséges mennyiségű logot generál, amelyek semmit nem jelentenek a szerveradminisztrátornak, akinek szerencsétlenül kell elolvassa azokat hajnali 3:15-kor.

A fotó szerzője Tim Gouw Gyorsan emlékezzünk vissza, hogyan működik a moduláris aritmetika. Az óra már egy ismert koncepció. Az órák használata Unsplash

A rendszerszer mérnökök, akik lehetővé teszik a termékek megjelenését, szintén bizonyos felelősséggel tartoznak a helyzetért. Csak néhány rendszerszer mérnöknek van ideje, és érdekli, hogy megpróbáljon értelmes metrikákat kinyernie a naplókból, a metrikák kontextusa és értelmezésének lehetősége nélkül az alkalmazás aktivitása fényében. Néhányan nem értik, milyen előnyt nyerhetnek ebből, azon kívül, hogy a „jelenleg valami (vagy hamarosan) nem megfelelő” típusú mutatókat látják.

A metrikákkal kapcsolatos gondolkodásmód megváltoztatásának nemcsak a fejlesztők körében kell bekövetkeznie, hanem a rendszerszer mérnökök körében is.

Bármely rendszerszer mérnök számára, aki nemcsak a kritikus eseményekre reagál, hanem garantálni kívánja azok hiányát, a metrikák hiánya általában akadályt jelent.

A rendszerszer mérnökök azonban általában nem foglalkoznak a kóddal, pénzt keresve a vállalatuk számára. Szükségük van vezető fejlesztőkre, akik értik a rendszerszer mérnök felelősségének fontosságát a problémák felfedezésében, a teljesítményt érintő problémák tudatosításában és hasonlókban.

Ez a devops dolog

A devops mentalitás a fejlesztők (dev) és az üzemeltetés (ops) gondolkodásának szinergiáját írja le. Bármely vállalat, amely azt állítja, hogy „devops-t csinál”, annak:

1. azt mondania, hogy valószínűleg nem csinálják (utalás a "A hercegnő menyasszony" című film mémjére – „Nem hiszem, hogy ez azt jelenti, amit gondolsz, hogy ez jelent!”)
2. bátorítani kell a termék folyamatos fejlesztésének pozícióját.

Nem tudod fejleszteni a terméket és tudni, hogy javítottad, ha nem tudod, hogyan működik jelenleg. Nem fogod tudni, hogyan működik a termék, ha nem érted, hogyan működnek annak komponensei, a szolgáltatások, amelyekre épít, a fő fájdalompontjai és szűk keresztmetszetei.
Ha nem figyeled a potenciálisan szűk keresztmetszeteket, nem tudod alkalmazni az „Öt miért” módszert a Postmortem írásakor. Nem tudod egy képernyőre összegyűjteni mindent, hogy lásd, hogyan működik a termék, vagy felfedezd, hogy hogyan néz ki „normálisan és boldogan”.

Balra elmozdulás, BALRA, MONDTAM, BAAAAAAAL!

Számomra a Devops egyik alapelve a „balra elmozdulás” (shift left). A balra elmozdulás ebben a kontextusban a lehetőség elmozdulását jelenti (nem a felelősséget, de lehetőségekkel) elvégezni azt, ami általában a rendszermérnökök feladata, például teljesítménymutatók létrehozása, a naplók hatékonyabb felhasználása stb., a szoftver szállítási életciklus (Software Delivery Life Cycle) bal oldalán.

A fotó szerzője NESA by Makers Gyorsan emlékezzünk vissza, hogyan működik a moduláris aritmetika. Az óra már egy ismert koncepció. Az órák használata Unsplash

A szoftverfejlesztőknek lehetőséget kell kapniuk arra, hogy használják és ismerjék a monitorozási eszközöket, amelyeket a cég alkalmaz, hogy monitorozhassák az összes formáját, mutatóit, naplózását, monitorozási interfészeit, és ami a legfontosabb, figyelemmel kísérni, hogy a termékük hogyan működik a gyakorlatban.Nem kényszerítheti a fejlesztőket arra, hogy energiát és időt fektessenek a monitorozásba, amíg nem láthatják a mutatókat, és nem tudnak hatással lenni arra, hogyan néznek ki, ahogy a termékvezető bemutatja azokat a CTO-nak a következő tájékoztatón stb.

Röviden

1. Vezesse a lovat a vízhez. Mutassa meg a fejlesztőknek, mennyi problémát kerülhetnek el, segítse őket a megfelelő KPI-k és mutatók kiemelésében az alkalmazásaikhoz, hogy kevesebb kiabálás legyen a termékvezetőtől, akire a műszaki igazgató (CTO) kiabál. Hozza a fényre őket, lágyan és nyugodtan. Ha ez nem sikerül, akkor meg kell vesztegetnie, fenyegetnie vagy rábeszélnie vagy őket, vagy a termékvezetőt, hogy minél előbb valósítsák meg ezeknek a mutatóknak az alkalmazásokból való kinyerését, majd ábrákat rajzoljon. Ez nehéz lesz, mivel nem fogják prioritásként kezelni, és a termék ütemtervében sok várakozó projekt lesz, amelyek bevételt hoznak. Ezért gazdasági indoklásra lesz szüksége, hogy megindokolja a monitorozás termékbe való bevezetésére fordított időt és forrást.
2. Segítsen a rendszermérnököknek pihenni. Mutassa meg nekik, hogy a kiadási ellenőrzőlista alkalmazása bármilyen kiadott termék esetén jó dolog. Az, hogy ellenőrizzük, hogy minden alkalmazás a termelésben metrikákkal van lefedve, segíthet abban, hogy nyugodtak legyünk az éjszakai alvásunkkal kapcsolatban, lehetővé téve a fejlesztők számára, hogy lássák, mi működik és mi nem. Mindazonáltal a legjobb módja annak, hogy bosszantsunk és frusztráljunk bármely fejlesztőt, terméktulajdonost és műszaki igazgatót, az, ha folyamatosan akadályozzuk a haladást és ellenállunk. Ez a viselkedés hatással lesz bármely termék kiadási dátumára, ha újra az utolsó percekig várunk, ezért ismét hajtsa végre a balra tolást, és a lehető leghamarabb vonja be ezeket a kérdéseket a projekttervbe. Ha szükséges, férj be a termékhez kapcsolódó találkozókra. Viseljen hamis bajuszt és filcet, vagy valami hasonlót, ez sosem hagy cserben. Beszéljen a problémáiról, mutassa be a nyilvánvaló előnyöket és evangelizáljon.
3. Gondoskodjon arról, hogy mind a fejlesztők (dev), mind az üzemeltetés (ops) megértse a termék metrikáinak 'vörös zónába' való átlépésének jelentőségét és következményeit. Ne hagyja az üzemeltetést a termék működőképességének egyetlen őrének, győződjön meg róla, hogy a fejlesztők is részt vesznek ebben (#productsquads).
4. A logok nagyszerűek, de a metrikák is. Kombinálja őket, és ne engedje, hogy a logjai haszontalan szemétbál álljanak össze egy hatalmas, lángoló felesleges gömbbé. Magyarázza el és mutassa meg a fejlesztőknek, miért nem tud senki más megbirkózni a logjaikkal, és mutassa meg nekik, milyen érzés nézni a haszontalan logokat 3:15-kor.

A fotó szerzője Marko Horvat Gyorsan emlékezzünk vissza, hogyan működik a moduláris aritmetika. Az óra már egy ismert koncepció. Az órák használata Unsplash

Ezzel minden elmondva. Az új anyag a jövő héten jelenik meg. Ha többet szeretne megtudni a tanfolyamról, várjuk Önt a nyílt napra, amely már hétfőn zajlik. Most pedig hagyományosan várjuk a hozzászólásaikat.

Forrás: habr.com