Schéine Freideg jiddereen! Frënn, haut fuere mir weider mat der Serie vu Publikatiounen, déi dem Cours gewidmet sinn , well d'Coursen am neie Grupp fir de Cours fänken um Enn vun der nächster Woch. Also, loosst eis ufänken!
Iwwerwachung ass einfach. Dëst ass e bekannte Fakt. Bréngt Nagios op, lafen NRPE um Fernsystem, konfiguréieren Nagios op NRPE TCP Hafen 5666 an Dir hutt Iwwerwaachung.
Et ass sou einfach datt et net interessant ass. Elo hutt Dir Basis Metriken fir CPU Zäit, Disk Subsystem, RAM, als Standard op Nagios an NRPE geliwwert. Awer dëst ass net tatsächlech "Iwwerwaachung" als solch. Dëst ass just den Ufank.
(Normalerweis installéiere se PNP4Nagios, RRDtool an Thruk, setzen Notifikatiounen am Slack op a ginn direkt op nagiosexchange, awer loosst eis dat elo ausloossen).
Gutt Iwwerwaachung ass tatsächlech zimmlech komplex, Dir musst wierklech d'Innere vun der Applikatioun kennen déi Dir iwwerwaacht.
Ass d'Iwwerwaachung schwéier?
All Server, sief et Linux oder Windows, wäert per Definitioun en Zweck déngen. Apache, Samba, Tomcat, Dateilagerung, LDAP - all dës Servicer si méi oder manner eenzegaarteg an engem oder méi Hisiichte. Jiddereen huet seng eege Funktioun, seng eege Charakteristiken. Et gi verschidde Weeër fir Metriken, KPIs (Schlësselleistungsindikatoren) ze kréien, déi fir Iech interessant sinn wann de Server ënner Laascht ass.
Auteur vun der Foto op
(Ech wënschen meng Dashboards neonblo wieren - dreemend dreemen -... hmm...)
All Software déi Servicer ubitt muss e Mechanismus hunn fir Metriken ze sammelen. Apache huet e Modul mod-status, weist d'Serverstatus Säit. Nginx huet - stub_status. Tomcat huet JMX oder personaliséiert Webapplikatiounen déi Schlësselmetriken weisen. MySQL huet e Kommando "Globalstatus weisen" etc.
Also firwat bauen d'Entwéckler net ähnlech Mechanismen an d'Applikatiounen déi se kreéieren?
Sinn nëmmen Entwéckler dat maachen?
E gewëssen Niveau vun Gläichgëltegkeet zu Metriken Embedding ass net limitéiert op Entwéckler. Ech hunn an Firmen geschafft wou se Uwendungen mat Tomcat entwéckelt hunn an keng vun hiren eegene Metriken ubidden, keng Logbicher vun Serviceaktivitéit, ausser allgemeng Tomcat Fehlerprotokoller. E puer Entwéckler generéieren vill Logbicher, déi näischt fir de Systemadministrator bedeiten, deen onglécklech genuch ass fir se um 3:15 moies ze liesen.
Auteur vun der Foto op
Systemingenieuren, déi et erlaben esou Produkter ze verëffentlechen, mussen och eng Verantwortung fir d'Situatioun droen. Puer Systemingenieuren hunn d'Zäit oder d'Betreiung fir sënnvoll Metriken aus Logbicher ze extrahieren, ouni de Kontext vun dëse Metriken an d'Fäegkeet se am Liicht vun der Applikatiounsaktivitéit ze interpretéieren. E puer verstinn net wéi se dovu profitéiere kënnen, anescht wéi "eppes ass am Moment (oder wäert geschwënn) falsch sinn" Indikatoren.
Eng Ännerung am Denken iwwer de Bedierfnes fir Metriken muss net nëmmen ënner Entwéckler geschéien, awer och bei Systemingenieuren.
Fir all Systemingenieur deen net nëmmen op kritesch Eventer muss reagéieren, awer och sécherstellen datt se net geschéien, ass de Mangel u Metriken normalerweis eng Barrière fir dat ze maachen.
Wéi och ëmmer, Systemingenieuren denken normalerweis net mam Code fir Sue fir hir Firma ze maachen. Si brauche Lead Entwéckler déi d'Wichtegkeet vun der Verantwortung vum Systemingenieur verstoen fir Probleemer z'identifizéieren, d'Sensibiliséierung vu Performanceprobleemer an dergläiche ze erhéijen.
Dëst devops Saach
D'Devops Mentalitéit beschreift d'Synergie tëscht Entwécklung (Dev) an Operatiounen (Ops) Denken. All Firma déi behaapt "devops ze maachen" muss:
- Saachen ze soen déi se wahrscheinlech net maachen (bezunn op The Princess Bride meme - "Ech denken net datt et heescht wat Dir mengt et heescht!")
- Encouragéiert eng Haltung vu kontinuéierlecher Produktverbesserung.
Dir kënnt e Produkt net verbesseren a wësst datt et verbessert gouf wann Dir net wësst wéi et am Moment funktionnéiert. Dir kënnt net wësse wéi e Produkt funktionnéiert wann Dir net versteet wéi seng Komponenten funktionnéieren, d'Servicer vun deem et hänkt, seng Haaptschmerzpunkten a Flaschenhals.
Wann Dir net no potenzielle Flaschenhals kuckt, kënnt Dir d'Fënnef Whys Technik net verfollegen wann Dir e Postmortem schreift. Dir kënnt net alles op engem Écran setzen fir ze kucken wéi e Produkt funktionnéiert oder wësse wéi et ausgesäit "normal a glécklech".
Schéckt lénks, Lénks, ech sot LEEEE-
Fir mech ass ee vun de Schlësselprinzipien vun Devops "Shift left". Verréckelung lénks an dësem Kontext bedeit d'Méiglechkeet ze verréckelen (keng Verantwortung, awer nëmmen Fäegkeeten) fir Saachen ze maachen, déi Systemingenieuren normalerweis këmmeren, wéi zB Leeschtungsmetriken erstellen, Logbicher méi effizient benotzen, etc., lénks am Software Delivery Life Cycle.
Auteur vun der Foto op
Software Entwéckler musse fäeg sinn d'Iwwerwaachungsinstrumenter ze benotzen an ze kennen déi d'Firma benotzt fir d'Iwwerwaachung an all senge Formen, Metriken, Logbicher, Iwwerwaachungsinterfaces an, am wichtegsten, auszeféieren. kucken wéi hire Produkt an der Produktioun funktionnéiert. Dir kënnt d'Entwéckler net kréien fir Effort an Zäit an der Iwwerwaachung ze investéieren bis se d'Metriken gesinn an beaflosse wéi se ausgesinn, wéi de Produktbesëtzer se dem CTO bei der nächster Briefing presentéiert, etc.
Kuerz gesot
- Féiert Äert Päerd an d'Waasser. Weist d'Entwéckler wéi vill Ierger si fir sech selwer vermeiden kënnen, hëlleft hinnen déi richteg KPIs a Metriken fir hir Uwendungen z'identifizéieren, sou datt et manner Gejäiz vum Produktbesëtzer gëtt, deen vum CTO gejaut gëtt. Bréngt se an d'Liicht, sanft a roueg. Wann dat net funktionnéiert, da bestiech, menacéiert a rufft entweder se oder de Produktbesëtzer fir dës Metriken aus den Uwendungen sou séier wéi méiglech ze kréien, an dann d'Diagrammer zeechnen. Dëst wäert schwiereg sinn well et net als Prioritéit gesi gëtt an de Produktroadmap wäert vill Recetten generéierende Projeten amgaang sinn. Dofir braucht Dir e Business Case fir d'Zäit an d'Käschte fir d'Iwwerwaachung an d'Produkt ëmzesetzen ze justifiéieren.
- Hëlleft Systemingenieuren e gudde Schlof ze kréien. Weist hinnen datt d'Benotzung vun enger "Let's release" Checklëscht fir all Produkt dat verëffentlecht gëtt eng gutt Saach ass. A sécherzestellen datt all Uwendungen an der Produktioun mat Metriken ofgedeckt sinn, hëlleft Iech an der Nuecht besser ze schlofen andeems d'Entwéckler et erlaben ze gesinn wat falsch leeft a wou. Wéi och ëmmer, de richtege Wee fir all Entwéckler, Produktbesëtzer oder CTO ze irritéieren an ze frustréieren ass ze bestoen a widderstoen. Dëst Verhalen beaflosst de Verëffentlechungsdatum vun all Produkt wann Dir erëm bis déi lescht Minutt waart, also réckelt erëm lénks a gitt dës Themen sou séier wéi méiglech an Äre Projetsplang. Wann néideg, maacht Äre Wee op Produktversammlungen. Drot e gefälschte Moustache a Filz oder eppes, et wäert ni versoen. Kommunizéieren Är Bedenken, weisen kloer Virdeeler, an evangeliséieren.
- Vergewëssert Iech datt béid Entwécklung (Dev) an Operatiounen (Ops) d'Bedeitung an d'Konsequenz vu Produktmetriken verstinn an déi rout Zone bewegen. Loosst den Ops net als eenzegen Erzéiungsberechtegten vun der Produktgesondheet, gitt sécher datt d'Entwéckler och involvéiert sinn (#productsquads).
- Logbicher sinn eng super Saach, awer och Metriken. Kombinéiert se a loosst Är Logbicher net Dreck ginn an engem risege flamenden Ball vun Onnëtzlosegkeet. Erkläert a weist d'Entwéckler firwat keen aneren hir Logbicher versteet, weist hinnen wéi et ass fir onnëtze Logbicher um 3:15 moies ze kucken.
Auteur vun der Foto op
Dat ass alles. Neit Material gëtt d'nächst Woch verëffentlecht. Wann Dir wëllt méi iwwer de Cours gewuer ginn, invitéiere mir Iech op , déi e Méindeg stattfënnt. An elo waarden mir traditionell op Är Kommentaren.
Source: will.com