Boldog pénteket mindenkinek! Barátaim, ma folytatjuk a kurzusnak szentelt kiadványsorozatot , mert a tanfolyam új csoportjában a jövő hét végén indulnak az órák. Szóval, kezdjük!
A megfigyelés az éppen. Ez ismert tény. Indítsa el a Nagios-t, futtassa az NRPE-t a távoli rendszeren, konfigurálja a Nagios-t az NRPE 5666-os TCP-portján, és máris van felügyelet.
Annyira egyszerű, hogy nem is érdekes. Most már rendelkezik alapvető mérőszámokkal a CPU-időre, a lemezalrendszerre és a RAM-ra vonatkozóan, amelyeket alapértelmezés szerint biztosít a Nagios és az NRPE. De ez valójában nem „monitoring”, mint olyan. Ez csak a kezdet.
(Általában telepítik a PNP4Nagiost, az RRDtool-t és a Thrukot, beállítják az értesítéseket a Slackben, és egyenesen a nagiosexchange-hez mennek, de ezt most hagyjuk).
Jó megfigyelés valójában meglehetősen összetett, valóban ismernie kell a megfigyelt alkalmazás belső tulajdonságait.
Nehéz az ellenőrzés?
Bármely szerver, legyen az Linux vagy Windows, értelemszerűen szolgál valami célt. Apache, Samba, Tomcat, fájltároló, LDAP – ezek 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ódokon szerezhet olyan mutatókat, KPI-ket (kulcsteljesítménymutatók), amelyek érdekesek az Ön számára, amikor a szerver terhelés alatt áll.
A fotó szerzője on
(Bárcsak neonkék színűek lennének a műszerfalaim - álmodozóan sóhajtva -... hmm...)
Minden szolgáltatásokat nyújtó szoftvernek rendelkeznie kell egy olyan mechanizmussal, amely mérőszámokat gyűjt. Az Apache-nak van egy modulja mod-status, megjeleníti a szerver állapotoldalát. Az Nginxnek van - stub_status. A Tomcat rendelkezik JMX vagy egyéni webalkalmazásokkal, amelyek a legfontosabb mutatókat jelenítik meg. A MySQL-nek van egy "show global status" parancsa stb.
Miért nem építenek be a fejlesztők hasonló mechanizmusokat az általuk létrehozott alkalmazásokba?
Csak a fejlesztők csinálják ezt?
A mérőszámok beágyazásával szembeni közömbösség nem korlátozódik a fejlesztőkre. Olyan cégeknél dolgoztam, ahol Tomcat használatával fejlesztettek alkalmazásokat, és nem adtak meg semmilyen saját mérőszámot, semmilyen szolgáltatási tevékenység naplóját, kivéve az általános Tomcat hibanaplókat. Egyes fejlesztők sok naplót generálnak, amelyek semmit sem jelentenek a rendszergazdának, aki nem szerencsés, ha hajnali 3:15-kor elolvassa azokat.
A fotó szerzője on
Az ilyen termékek forgalomba hozatalát lehetővé tevő rendszermérnököknek is vállalniuk kell némi felelősséget a kialakult helyzetért. Kevés rendszermérnöknek van ideje vagy törődése, hogy megpróbáljon értelmes mérőszámokat kinyerni a naplókból anélkül, hogy a mérőszámok kontextusa és az alkalmazási tevékenység fényében értelmezhető lenne. Vannak, akik nem értik, hogyan profitálhatnak belőle, kivéve a "valami jelenleg (vagy hamarosan) rossz lesz" jelzőket.
A mérőszámok szükségességével kapcsolatos gondolkodásmódváltásnak nemcsak a fejlesztők, hanem a rendszermérnökök körében is meg kell történnie.
Bármely rendszermérnök számára, akinek nemcsak reagálnia kell a kritikus eseményekre, hanem gondoskodnia kell arról is, hogy azok ne forduljanak elő, általában a mérőszámok hiánya akadályozza ezt.
A rendszermérnökök azonban általában nem trükköznek a kóddal, hogy pénzt keressenek a cégüknek. Olyan vezető fejlesztőkre van szükségük, akik megértik a rendszermérnök felelősségének fontosságát a problémák azonosításában, a teljesítményproblémák tudatosításában és hasonlókban.
Ez a devops dolog
A devops mentalitás a fejlesztési (dev) és a műveleti (ops) gondolkodás közötti szinergiát írja le. Minden olyan cégnek, amely azt állítja, hogy "devops-ot csinál":
- olyan dolgokat mondanak, amiket valószínűleg nem (utalva a The Princess Bride mémre – „Nem hiszem, hogy azt jelenti, amit te gondolsz!”)
- Ösztönözze a folyamatos termékfejlesztési hozzáállást.
Nem fejleszthetsz egy terméket, és tudod, hogy továbbfejlesztették, ha nem tudod, hogyan működik jelenleg. Nem tudhatod, hogyan működik egy termék, ha nem ismered az összetevői működését, a szolgáltatásokat, amelyektől függ, a fő fájdalompontjait és szűk keresztmetszeteit.
Ha nem figyeli az esetleges szűk keresztmetszeteket, nem fogja tudni követni az Öt Miért technikát a Halotthalál megírásakor. Nem fog tudni mindent egy képernyőre helyezni, hogy lássa, hogyan működik egy termék, vagy nem tudja, hogyan néz ki „normálisan és boldogan”.
Váltás balra, BALRA, MONDTAM LEEEE-
Számomra a Devops egyik alapelve a balra váltás. A balra eltolás ebben az összefüggésben a lehetőség eltolását jelenti (nincs felelősség, de csak képességek), hogy olyan dolgokat hajtson végre, amelyek a rendszermérnökök számára általában fontosak, például teljesítménymutatók létrehozása, naplók hatékonyabb használata stb., a Szoftverszállítási életciklus bal oldalán.
A fotó szerzője on
A szoftverfejlesztőknek tudniuk kell használni és ismerniük a vállalat által használt monitorozási eszközöket a monitorozás minden formája, mérőszáma, naplózása, felügyeleti felülete és ami a legfontosabb, nézze meg, hogyan működik termékük a termelésben. Nem lehet rávenni a fejlesztőket arra, hogy erőfeszítéseket és időt fektessenek a monitorozásba, amíg nem látják a mutatókat, és nem tudják befolyásolni, hogyan néznek ki, hogyan mutatja be a terméktulajdonos a műszaki igazgatónak a következő tájékoztatón stb.
Röviden szólva
- Vezesd a lovad a vízhez. Mutasd meg a fejlesztőknek, hogy mekkora problémát tudnak elkerülni maguknak, segíts nekik azonosítani a megfelelő KPI-ket és mérőszámokat alkalmazásaikhoz, hogy kevesebbet kiabáljon a terméktulajdonos, akivel a CTO kiabál. Vigye őket a fénybe, finoman és nyugodtan. Ha ez nem működik, megvesztegetheti, fenyegetheti és rábírja őket vagy a termék tulajdonosát, hogy a lehető leggyorsabban alkalmazzák ezeket a mutatókat az alkalmazásokból, majd rajzolja meg a diagramokat. Ez nehéz lesz, mivel nem tekintik prioritásnak, és a termék ütemtervében számos bevételtermelő projekt lesz függőben. Ezért szüksége lesz egy üzleti esetre, amely igazolja a felügyelet termékbe történő bevezetésével töltött időt és költséget.
- Segítsen a rendszermérnököknek jó éjszakai alvásban. Mutasd meg nekik, hogy jó dolog egy „engedjük ki” ellenőrzőlista használata minden kiadott termékhez. Ha pedig gondoskodik arról, hogy minden éles alkalmazást lefedjenek a mérőszámok, akkor a fejlesztők láthatják, mi és hol történik a hiba, így jobban alhat éjszaka. Azonban minden fejlesztő, terméktulajdonos vagy műszaki igazgató irritálásának és frusztrálásának megfelelő módja a kitartás és az ellenállás. Ez a viselkedés hatással lesz bármely termék megjelenési dátumára, ha ismét az utolsó pillanatig vár, ezért váltson ismét balra, és a lehető leghamarabb tegye bele ezeket a problémákat a projekttervébe. Ha szükséges, induljon terméktalálkozókra. Viseljen hamis bajuszt és filcet vagy ilyesmit, soha nem fog elbukni. Közölje aggodalmait, mutasson egyértelmű előnyöket, és evangelizáljon.
- Győződjön meg arról, hogy mind a fejlesztés (dev), mind a műveletek (ops) megértik a termékmutatók vörös zónába kerülésének jelentését és következményeit. Ne hagyja az Ops-t a termék állapotának egyedüli őrzőjének, ügyeljen arra, hogy a fejlesztők is részt vegyenek benne (#productsquads).
- A naplók nagyszerűek, de a mutatók is. Kombinálja őket, és ne hagyja, hogy a rönkök szemétté váljanak a haszontalanság hatalmas lángoló labdájába. Magyarázd el és mutasd meg a fejlesztőknek, hogy miért nem érti senki más a naplóikat, mutasd meg nekik, milyen hajnali 3:15-kor haszontalan naplókat nézni.
A fotó szerzője on
Ez minden. A jövő héten új anyag jelenik meg. Ha szeretne többet megtudni a kurzusról, szeretettel várjuk , amelyre hétfőn kerül sor. Most pedig hagyományosan várjuk észrevételeiket.
Forrás: will.com