Od roku 2008 se naše společnost zabývá především správou infrastruktury a nepřetržitou technickou podporou webových projektů: máme více než 400 klientů, což je asi 15 % ruského e-commerce. V souladu s tím je podporována velmi různorodá architektura. Pokud něco spadne, jsme povinni to do 15 minut opravit. Ale abyste pochopili, že došlo k nehodě, musíte projekt monitorovat a reagovat na incidenty. Jak to udělat?
Domnívám se, že existuje problém s organizací správného monitorovacího systému. Pokud by nedošlo k žádným potížím, můj projev by sestával z jedné teze: „Nainstalujte si prosím Prometheus + Grafana a pluginy 1, 2, 3.“ Bohužel už to tak nefunguje. A hlavním problémem je, že všichni nadále věří v něco, co existovalo v roce 2008, pokud jde o softwarové komponenty.
Ohledně organizace monitorovacího systému bych si dovolil tvrdit, že... projekty s kompetentním monitorováním neexistují. A situace je tak špatná, že pokud něco spadne, existuje riziko, že to zůstane bez povšimnutí - koneckonců, každý má jistotu, že „vše je monitorováno“.
Možná je vše monitorováno. Ale jak?
Všichni jsme se setkali s příběhem, jako je tento: jistý vývojář, jistý admin pracuje, přijde k nim vývojový tým a říká - "jsme propuštěni, nyní monitor." Monitorovat co? Jak to funguje?
OK. Sledujeme staromódní způsob. A už se to mění a ukázalo se, že jste monitorovali službu A, ze které se stala služba B, která interaguje se službou C. Ale vývojový tým vám řekne: „Nainstalujte software, měl by sledovat vše!“
Co se tedy změnilo? - Vše se změnilo!
2008 Vše je v pořádku
Existuje několik vývojářů, jeden server, jeden databázový server. Všechno to jde odtud. Máme nějaké informace, instalujeme zabbix, Nagios, kaktusy. A pak nastavíme jasná upozornění na CPU, na provoz disku a na místo na disku. Provádíme také několik ručních kontrol, abychom se ujistili, že web odpovídá a objednávky přicházejí do databáze. A je to – jsme víceméně chráněni.
Pokud porovnáme množství práce, kterou administrátor tehdy vykonal při zajištění monitorování, pak 98 % z toho bylo automatických: osoba, která provádí monitorování, musí rozumět tomu, jak nainstalovat Zabbix, jak jej nakonfigurovat a nakonfigurovat výstrahy. A 2 % - pro externí kontroly: že stránka odpovídá a podává požadavek do databáze, že přišly nové objednávky.
2010 Zátěž roste
Začínáme škálovat web, přidáváme vyhledávač. Chceme zajistit, aby produktový katalog obsahoval všechny produkty. A to vyhledávání produktů funguje. Že databáze funguje, že se zadávají objednávky, že web odpovídá externě a odpovídá ze dvou serverů a uživatel není vyhozen z webu, zatímco je přebalancován na jiný server atd. Subjektů je více.
Navíc subjekt spojený s infrastrukturou stále zůstává největší v hlavě manažera. Stále mám v hlavě představu, že osoba, která provádí monitorování, je osoba, která nainstaluje zabbix a bude jej moci nakonfigurovat.
Zároveň se ale objevuje práce na provádění externích kontrol, na vytvoření sady vyhledávacích indexovacích dotazovacích skriptů, sady skriptů pro kontrolu, že se vyhledávání mění během procesu indexování, sady skriptů, které kontrolují, zda je zboží přeneseno do zásilková služba atd. a tak dále.
Poznámka: „Sada skriptů“ jsem napsal 3krát. To znamená, že osoba odpovědná za monitorování již není tím, kdo si zabbix jednoduše nainstaluje. To je člověk, který začíná kódovat. V myslích týmu se ale zatím nic nezměnilo.
Ale svět se mění, je stále složitější. Je přidána virtualizační vrstva a několik nových systémů. Začnou se vzájemně ovlivňovat. Kdo řekl "voní jako mikroslužby?" Každá služba ale stále vypadá jako webová stránka samostatně. Můžeme se na ni obrátit a pochopit, že poskytuje potřebné informace a funguje sama. A pokud jste administrátor neustále zapojený do projektu, který se vyvíjí 5-7-10 let, tyto znalosti se hromadí: objeví se nová úroveň - uvědomili jste si to, objeví se další úroveň - uvědomili jste si to...
Málokdy ale někdo doprovází projekt 10 let.
Monitoringmanův životopis
Předpokládejme, že jste přišli do nového startupu, který okamžitě najal 20 vývojářů, napsal 15 mikroslužeb a jste admin, kterému bylo řečeno: „Build CI/CD. Prosím." Postavili jste CI/CD a najednou slyšíte: „Je pro nás těžké pracovat s produkcí v „kostce“, aniž bychom pochopili, jak v ní bude aplikace fungovat. Udělejte nám pískoviště ve stejné „kostce“.
V této kostce vytvoříte pískoviště. Okamžitě vám řeknou: „Chceme scénickou databázi, která se aktualizuje každý den z produkce, abychom pochopili, že funguje na databázi, ale zároveň nekazí produkční databázi.“
V tom všem žijete. Do vydání zbývají 2 týdny, řeknou vám: „Nyní to všechno sledujeme...“ To znamená. monitorovat infrastrukturu clusteru, monitorovat architekturu mikroslužeb, monitorovat práci s externími službami...
A moji kolegové vytahují z hlavy obvyklé schéma a říkají: „Tak tady je všechno jasné! Nainstalujte si program, který bude toto vše sledovat.“ Ano, ano: Prometheus + Grafana + pluginy.
A dodávají: "Máte dva týdny, ujistěte se, že je vše v bezpečí."
V mnoha projektech, které vidíme, je pro monitorování přidělena jedna osoba. Představte si, že chceme najmout člověka na monitoring na 2 týdny a my mu napíšeme životopis. Jaké dovednosti by tato osoba měla mít, vzhledem ke všemu, co jsme dosud řekli?
- Musí rozumět sledování a specifikům provozu železné infrastruktury.
- Musí rozumět specifikům monitorování Kubernetes (a každý chce jít do „kostky“, protože od všeho můžete abstrahovat, schovávat se, protože se zbytkem se už vypořádá admin) – samotného, jeho infrastruktury a rozumět tomu, jak sledovat aplikace. uvnitř.
- Musí chápat, že služby spolu komunikují zvláštními způsoby, a znát specifika toho, jak služby na sebe vzájemně působí. Je docela dobře možné vidět projekt, kde některé služby komunikují synchronně, protože jiná cesta není. Například backend jde přes REST, přes gRPC do katalogové služby, obdrží seznam produktů a vrátí ho zpět. Tady nemůžeš čekat. A s ostatními službami to funguje asynchronně. Přeneste objednávku doručovací službě, odešlete dopis atd.
Asi už jste z toho všeho plavali? A admin, který to potřebuje sledovat, byl ještě zmatenější. - Musí umět správně plánovat a plánovat – jak práce přibývá.
- Z vytvořené služby si tedy musí vytvořit strategii, aby pochopil, jak ji konkrétně monitorovat. Potřebuje rozumět architektuře projektu a jeho vývoji + rozumět technologiím používaným při vývoji.
Připomeňme si naprosto normální případ: některé služby jsou v PHP, některé služby jsou v Go, některé služby jsou v JS. Nějak spolu fungují. Odtud pochází termín „mikroslužba“: existuje tolik jednotlivých systémů, že vývojáři nemohou pochopit projekt jako celek. Jedna část týmu píše služby v JS, které fungují samy o sobě a neví, jak funguje zbytek systému. Druhá část píše služby v Pythonu a nezasahuje do fungování ostatních služeb, jsou izolovány ve své vlastní oblasti. Třetím je psaní služeb v PHP nebo v něčem jiném.
Všech těchto 20 lidí je rozděleno do 15 služeb a je zde pouze jeden admin, který tomu všemu musí rozumět. Stop! právě jsme rozdělili systém na 15 mikroslužeb, protože 20 lidí nemůže pochopit celý systém.
Ale musí se to nějak hlídat...
jaký je výsledek? Ve výsledku je tu jeden člověk, který přijde se vším, co celý tým vývojářů nemůže pochopit, a zároveň musí také znát a umět to, co jsme naznačili výše – hardwarová infrastruktura, infrastruktura Kubernetes atd.
Co mohu říci... Houstone, máme problémy.
Monitorování moderního softwarového projektu je samo o sobě softwarovým projektem
Z falešného přesvědčení, že monitorování je software, si vypěstujeme víru v zázraky. Ale zázraky se bohužel nedějí. Nemůžete nainstalovat zabbix a očekávat, že vše bude fungovat. Nemá smysl instalovat Grafanu a doufat, že bude vše ok. Většinu času zabere organizování kontrol fungování služeb a jejich vzájemné interakce, kontrola fungování externích systémů. Ve skutečnosti nebude 90 % času věnováno psaní skriptů, ale vývoji softwaru. A měl by to řešit tým, který rozumí práci na projektu.
Pokud je v této situaci jedna osoba vržena do monitorování, dojde ke katastrofě. Což se děje všude.
Existuje například několik služeb, které spolu komunikují prostřednictvím Kafky. Objednávka dorazila, Kafkovi jsme poslali zprávu o objednávce. Existuje služba, která vyslechne informace o objednávce a odešle zboží. Existuje služba, která vyslechne informace o objednávce a odešle uživateli dopis. A pak se objeví spousta dalších služeb a začínáme být zmatení.
A pokud to dáte také adminovi a vývojářům ve fázi, kdy do vydání zbývá krátká doba, bude muset dotyčný celý tento protokol pochopit. Tito. Projekt takového rozsahu zabere značné množství času a to by mělo být zohledněno při vývoji systému.
Velmi často ale zejména u startupů vidíme, jak se monitoring odkládá na později. „Nyní uděláme Proof of Concept, spustíme s ním, necháme ho padnout – jsme připraveni se obětovat. A pak to všechno budeme monitorovat." Když (nebo pokud) projekt začne vydělávat peníze, chce podnik přidat ještě více funkcí – protože začal fungovat, takže je třeba ho dále rozvinout! A jste v bodě, kdy musíte nejprve sledovat vše předchozí, což nezabere 1 % času, ale mnohem více. A mimochodem, pro monitorování budou potřeba vývojáři a je snazší je nechat pracovat na nových funkcích. Výsledkem je, že se píší nové funkce, všechno se posere a vy jste v nekonečné slepé uličce.
Jak tedy monitorovat projekt od začátku a co dělat, když dostanete projekt, který je třeba monitorovat, ale nevíte, kde začít?
Nejprve musíte plánovat.
Lyrická odbočka: velmi často začínají monitorováním infrastruktury. Máme například Kubernetes. Začněme instalací Promethea s Grafanou, instalací pluginů pro sledování „kostky“. Nejen vývojáři, ale i administrátoři mají nešťastnou praxi: „Tento plugin nainstalujeme, ale plugin pravděpodobně ví, jak na to.“ Lidé rádi začínají s jednoduchými a přímočarými, spíše než s důležitými akcemi. A monitorování infrastruktury je snadné.
Nejprve se rozhodněte, co a jak chcete sledovat, a poté vyberte nástroj, protože ostatní lidé nemohou myslet za vás. A měli by? Jiní lidé přemýšleli o univerzálním systému - nebo vůbec nepřemýšleli, když byl tento plugin napsán. A to, že má tento plugin 5 tisíc uživatelů, ještě neznamená, že je k něčemu. Možná se stanete 5001. jednoduše proto, že tam předtím bylo 5000 lidí.
Pokud začnete monitorovat infrastrukturu a backend vaší aplikace přestane reagovat, všichni uživatelé ztratí spojení s mobilní aplikací. Objeví se chyba. Přijdou za vámi a řeknou: "Aplikace nefunguje, co tady děláte?" - "Sledujeme." — „Jak sledujete, když nevidíte, že aplikace nefunguje?!“
- Věřím, že musíte začít sledovat přesně od vstupního bodu uživatele. Pokud uživatel nevidí, že aplikace funguje, je to tak, je to selhání. A na to by měl monitorovací systém upozornit jako první.
- A teprve potom můžeme monitorovat infrastrukturu. Nebo to udělat paralelně. S infrastrukturou je to jednodušší – zde můžeme konečně nainstalovat zabbix.
- A nyní musíte jít ke kořenům aplikace, abyste pochopili, kde věci nefungují.
Moje hlavní myšlenka je, že monitorování by mělo probíhat souběžně s procesem vývoje. Pokud odvedete pozornost monitorovacího týmu pro jiné úkoly (vytváření CI/CD, sandboxing, reorganizace infrastruktury), monitoring se začne zpožďovat a možná už vývoj nikdy nedoženete (nebo ho dříve či později budete muset zastavit).
Vše podle úrovní
Takto vidím organizaci monitorovacího systému.
1) Úroveň aplikace:
- monitorování aplikační obchodní logiky;
- monitorování zdravotních metrik služeb;
- monitorování integrace.
2) Úroveň infrastruktury:
- monitorování úrovně orchestrace;
- monitorování systémového softwaru;
- sledování hladiny železa.
3) Opět aplikační úroveň - ale jako inženýrský produkt:
- shromažďování a monitorování aplikačních protokolů;
- APM;
- trasování.
4) Upozornění:
- organizace varovného systému;
- organizace systému služeb;
- organizace „znalostní základny“ a workflow pro zpracování incidentů.
Je to důležité,: k poplachu se dostaneme ne poté, ale hned! Není třeba spouštět monitorování a „nějak později“ zjistit, kdo bude dostávat upozornění. Ostatně, co je úkolem monitorování: pochopit, kde v systému něco funguje špatně, a dát o tom vědět správným lidem. Pokud si to necháte až na konec, pak ti správní lidé poznají, že se něco nedaří, pouze voláním „nic nám nefunguje“.
Aplikační vrstva - Business Logic Monitoring
Zde se bavíme o kontrole samotného faktu, že aplikace uživateli funguje.
Tato úroveň by měla být provedena během vývojové fáze. Například máme podmíněný Prometheus: jde na server, který provádí kontroly, stahuje koncový bod a koncový bod jde a kontroluje API.
Když je často požadováno, aby monitorovali domovskou stránku, aby se ujistili, že web funguje, programátoři dají kliku, kterou lze vytáhnout pokaždé, když potřebují, aby se ujistili, že API funguje. A programátoři v tuto chvíli stále berou a píší /api/test/helloworld
Jediný způsob, jak zajistit, aby vše fungovalo? - Ne!
- Vytváření takových kontrol je v podstatě úkolem vývojářů. Unit testy by měli psát programátoři, kteří píší kód. Protože pokud to prozradíte adminovi: "Ty vole, tady je seznam protokolů API pro všech 25 funkcí, prosím, sledujte vše!" - nic nevyjde.
- Pokud vytisknete „ahoj světe“, nikdo se nikdy nedozví, že API by mělo fungovat a funguje. Každá změna API musí vést ke změně kontrol.
- Pokud již máte takový problém, zastavte funkce a přidělte vývojáře, kteří budou tyto kontroly psát, nebo přijměte ztráty, přijměte, že nic není kontrolováno a selže.
Technické tipy:
- Nezapomeňte uspořádat externí server pro organizaci kontrol – musíte si být jisti, že váš projekt je přístupný vnějšímu světu.
- Organizujte kontroly napříč celým protokolem API, nejen jednotlivými koncovými body.
- Vytvořte prometheus-endpoint s výsledky testu.
Aplikační vrstva – sledování zdravotních metrik
Nyní hovoříme o externích zdravotních metrikách služeb.
Rozhodli jsme se, že všechny „handle“ aplikace budeme monitorovat pomocí externích kontrol, které voláme z externího monitorovacího systému. Ale to jsou „držadla“, které uživatel „vidí“. Chceme mít jistotu, že naše služby samotné fungují. Zde je lepší příběh: K8s má zdravotní kontroly, takže alespoň samotná „kostka“ může být přesvědčena, že služba funguje. Ale polovina šeků, které jsem viděl, jsou stejné nápisy „ahoj světe“. Tito. Takže po nasazení jednou zatáhne, odpověděl, že vše je v pořádku - to je vše. A služba, pokud poskytuje své vlastní API, má obrovské množství vstupních bodů pro stejné API, které je také potřeba monitorovat, protože chceme vědět, že funguje. A už to sledujeme uvnitř.
Jak to správně technicky implementovat: každá služba odhaluje koncový bod o svém aktuálním výkonu a v grafech Grafany (nebo jakékoli jiné aplikace) vidíme stav všech služeb.
- Každá změna API musí vést ke změně kontrol.
- Okamžitě vytvořte novou službu s metrikami zdraví.
- Administrátor může přijít za vývojáři a zeptat se „přidejte mi pár funkcí, abych všemu rozuměl, a přidejte o tom informace do svého monitorovacího systému“. Ale vývojáři obvykle odpovídají: "Dva týdny před vydáním nic nepřidáme."
Dejte vědět vývojovým manažerům, že k takovým ztrátám dojde, dejte vědět i vedení vývojových manažerů. Protože když všechno spadne, někdo bude stále volat a požadovat sledování „neustále klesající služby“ (c) - Mimochodem, přidělte vývojářům psaní pluginů pro Grafana - to bude dobrá pomoc pro administrátory.
Aplikační vrstva – Monitorování integrace
Integrační monitoring se zaměřuje na monitorování komunikace mezi kritickými obchodními systémy.
Jde například o 15 služeb, které spolu komunikují. Toto již nejsou samostatné stránky. Tito. nemůžeme službu stáhnout sami, získat /helloworld a pochopit, že služba běží. Protože objednávková webová služba musí odeslat informaci o objednávce do autobusu - z autobusu, musí tuto zprávu obdržet skladová služba a dále s ní pracovat. A to musí služba distribuce emailů nějak dále zpracovat atd.
Proto nemůžeme pochopit, šťourat se do každé jednotlivé služby, že to všechno funguje. Protože máme určitou sběrnici, přes kterou vše komunikuje a interaguje.
Proto by tato fáze měla označovat fázi testování služeb pro interakci s jinými službami. Není možné organizovat monitorování komunikace monitorováním zprostředkovatele zpráv. Pokud existuje služba, která data vydává a služba, která je přijímá, při sledování brokera uvidíme pouze data, která létají ze strany na stranu. I když se nám nějakým způsobem podařilo interně sledovat interakci těchto dat - že určitý výrobce data odešle, někdo si je přečte, tento tok jde dál do Kafky - stejně nám to neposkytne informaci, pokud jedna služba odeslala zprávu v jedné verzi , ale druhá služba tuto verzi nečekala a přeskočila ji. Nedozvíme se o tom, protože služby nám řeknou, že vše funguje.
Co doporučuji udělat:
- Pro synchronní komunikaci: koncový bod odesílá požadavky na související služby. Tito. vezmeme tento koncový bod, natáhneme skript do služby, který přejde ke všem bodům a řekne „Můžu tam vytáhnout a vytáhnout tam, můžu tam vytáhnout...“
- Pro asynchronní komunikaci: příchozí zprávy - koncový bod kontroluje sběrnici pro testovací zprávy a zobrazuje stav zpracování.
- Pro asynchronní komunikaci: odchozí zprávy - koncový bod odesílá testovací zprávy na sběrnici.
Jak se obvykle stává: máme službu, která hází data do sběrnice. Přicházíme do této služby a žádáme vás, abyste nám řekli o stavu její integrace. A pokud služba potřebuje vytvořit zprávu někde dále (WebApp), pak vytvoří tuto testovací zprávu. A pokud spustíme službu na straně OrderProcessing, ta nejprve odešle to, co může zveřejnit nezávisle, a pokud existují nějaké závislé věci, pak načte sadu testovacích zpráv ze sběrnice, pochopí, že je může zpracovat, nahlásit a , v případě potřeby je zveřejněte dále a o tom říká - vše je v pořádku, žiji.
Velmi často slýcháme otázku „jak to můžeme otestovat na bojových datech?“ Například mluvíme o stejné objednávkové službě. Objednávka posílá zprávy do skladu, kde je zboží odepsáno: nemůžeme to otestovat na bojových datech, protože „mé zboží bude odepsáno!“ Řešení: Naplánujte si celý tento test hned na začátku. Máte také testy jednotek, které se vysmívají. Udělejte to tedy na hlubší úrovni, kde máte komunikační kanál, který nepoškodí provoz podniku.
Infrastrukturní vrstva
Monitoring infrastruktury je něco, co bylo dlouho považováno za monitorování samotné.
- Monitorování infrastruktury může a mělo by být zahájeno jako samostatný proces.
- Neměli byste začínat s monitorováním infrastruktury na běžícím projektu, i když opravdu chcete. To je bolest pro všechny devopy. „Nejdřív budu monitorovat cluster, budu monitorovat infrastrukturu“ – tzn. Nejprve bude sledovat, co leží níže, ale nepůjde do aplikace. Protože aplikace je pro devopy nepochopitelná věc. Bylo mu to prozrazeno a on nechápe, jak to funguje. A rozumí infrastruktuře a začíná s ní. Ale ne – vždy je potřeba aplikaci nejprve sledovat.
- Nepřehánějte to s počtem upozornění. Vzhledem ke složitosti moderních systémů neustále létají výstrahy a s touto hromadou výstrah se musíte nějak sžít. A volaná osoba, která se podívá na sto dalších výstrah, rozhodne: „Nechci na to myslet.“ Upozornění by měla upozorňovat pouze na kritické věci.
Aplikační úroveň jako obchodní jednotka
Klíčové body:
- ELK. Toto je průmyslový standard. Pokud z nějakého důvodu neshromažďujete protokoly, začněte s tím okamžitě.
- APM. Externí APM jako způsob, jak rychle ukončit monitorování aplikací (NewRelic, BlackFire, Datadog). Tuto věc můžete dočasně nainstalovat, abyste alespoň nějak pochopili, co se s vámi děje.
- Sledování. V desítkách mikroslužeb musíte vše dohledat, protože požadavek už nežije sám. Je velmi obtížné přidat později, takže je lepší okamžitě naplánovat trasování ve vývoji - to je práce a užitečnost vývojářů. Pokud jste to ještě neimplementovali, implementujte to! Viz Jaeger/Zipkin
Upozornění
- Organizace notifikačního systému: v podmínkách sledování hromady věcí by měl existovat jednotný systém pro zasílání notifikací. Můžete v Grafaně. Na Západě všichni používají PagerDuty. Upozornění by měla být jasná (např. odkud přišla...). A je vhodné mít pod kontrolou, že se vůbec oznámení dostávají
- Organizace systému služeb: výstrahy by neměly být zasílány všem (buď budou všichni reagovat v davu, nebo nebude reagovat nikdo). Vývojáři musí být také na pohotovosti: definujte oblasti odpovědnosti, udělejte jasné pokyny a napište do nich, komu přesně volat v pondělí a středu a komu volat v úterý a pátek (jinak nikomu nezavolají ani v v případě velkého problému – budou se bát vás vzbudit nebo rušit: lidé obecně neradi volají a budí jiné lidi, zvláště v noci). A vysvětlete, že žádost o pomoc není ukazatelem neschopnosti („Žádám o pomoc, to znamená, že jsem špatný pracovník“), povzbuzujte žádosti o pomoc.
- Organizace „znalostní základny“ a pracovního postupu pro zpracování incidentu: pro každý vážný incident by měla být naplánována pitva a jako dočasné opatření by měly být zaznamenány akce, které incident vyřeší. A udělejte z praxe, že opakované upozornění je hřích; musí být opraveny v kódu nebo infrastruktuře.
Zásobník technologií
Představme si, že náš zásobník je následující:
- sběr dat - Prometheus + Grafana;
- log analýza - ELK;
- pro APM nebo sledování - Jaeger (Zipkin).
Výběr možností není kritický. Protože pokud jste na začátku pochopili, jak systém monitorovat a sepsali si plán, pak začnete vybírat nástroje podle svých požadavků. Otázkou je, co jste se rozhodli sledovat jako první. Protože možná nástroj, který jste si na začátku vybrali, vůbec nevyhovuje vašim požadavkům.
Několik technických bodů, které v poslední době vidím všude:
Prometheus se tlačí dovnitř Kubernetes - kdo s tím přišel?! Pokud se váš cluster zhroutí, co uděláte? Pokud máte uvnitř složitý cluster, pak by měl být uvnitř clusteru nějaký druh monitorovacího systému a nějaký venku, který bude shromažďovat data zevnitř clusteru.
Uvnitř clusteru sbíráme logy a vše ostatní. Ale monitorovací systém musí být venku. Velmi často v clusteru, kde je interně nainstalován Promtheus, existují také systémy, které provádějí externí kontroly provozu webu. Co když vaše spojení s vnějším světem kleslo a aplikace nefunguje? Ukazuje se, že uvnitř je vše v pořádku, ale uživatelům to nijak neusnadňuje.
Závěry
- Sledováním vývoje není instalace utilit, ale vývoj softwarového produktu. 98 % dnešního sledování je kódování. Kódování ve službách, kódování externích kontrol, kontrola externích služeb a to je vše.
- Neztrácejte čas svých vývojářů sledováním: může jim to zabrat až 30 % práce, ale stojí to za to.
- Devopsi, nebojte se, že nemůžete něco sledovat, protože některé věci jsou úplně jiným způsobem myšlení. Nebyl jste programátor a sledování práce je přesně jejich práce.
- Pokud projekt již běží a není monitorován (a vy jste manažer), přidělte prostředky pro monitorování.
- Pokud je produkt již ve výrobě a jste devops, kterému bylo řečeno, abyste „nastavili monitorování“ - zkuste vysvětlit vedení, o čem jsem to všechno psal.
Toto je rozšířená verze zprávy na konferenci Saint Highload++.
Pokud vás zajímají mé nápady a myšlenky na to a související témata, pak můžete zde ????
Zdroj: www.habr.com