El monitoratge està mort? — Visca el seguiment

Des de l'any 2008, la nostra empresa s'ha dedicat principalment a la gestió d'infraestructures i al suport tècnic durant les 400 hores del dia per a projectes web: tenim més de 15 clients, que és al voltant del 15% del comerç electrònic rus. En conseqüència, s'admet una arquitectura molt diversa. Si alguna cosa cau, estem obligats a arreglar-ho en XNUMX minuts. Però per entendre que s'ha produït un accident, cal fer un seguiment del projecte i donar resposta a les incidències. Com fer això?

Crec que hi ha un problema en organitzar un sistema de seguiment adequat. Si no hi hagués hagut problemes, el meu discurs consistiria en una tesi: "Si us plau, instal·leu Prometheus + Grafana i els connectors 1, 2, 3". Malauradament, ja no funciona així. I el principal problema és que tothom continua creient en alguna cosa que existia l'any 2008, pel que fa als components del programari.

Pel que fa a l'organització del sistema de seguiment, m'atreviria a dir que... no existeixen projectes amb un seguiment competent. I la situació és tan dolenta que si alguna cosa cau, hi ha el risc que passi desapercebuda; al cap i a la fi, tothom està segur que "tot està vigilat".
Potser tot està sent controlat. Però com?

Tots ens hem trobat amb una història com la següent: un determinat devops, un determinat administrador està treballant, un equip de desenvolupament ve a ells i els diu: "Estem alliberats, ara monitoritzem". Supervisar què? Com funciona?

D'ACORD. Seguim a l'antiga manera. I ja està canviant, i resulta que vau supervisar el servei A, que es va convertir en el servei B, que interactua amb el servei C. Però l'equip de desenvolupament us diu: "Instal·leu el programari, hauria de supervisar-ho tot!"

Aleshores, què ha canviat? - Tot ha canviat!

2008 Tot està bé

Hi ha un parell de desenvolupadors, un servidor, un servidor de bases de dades. Tot va d'aquí. Tenim informació, instal·lem zabbix, Nagios, cacti. I després establim alertes clares a la CPU, al funcionament del disc i a l'espai del disc. També fem un parell de comprovacions manuals per assegurar-nos que el lloc respon i que les comandes arriben a la base de dades. I això és tot: estem més o menys protegits.

Si comparem la quantitat de treball que l'administrador va fer llavors per proporcionar la supervisió, aleshores el 98% va ser automàtic: la persona que fa la supervisió ha d'entendre com instal·lar Zabbix, com configurar-lo i configurar les alertes. I 2% - per a controls externs: que el lloc respon i fa una sol·licitud a la base de dades, que han arribat noves comandes.

2010 La càrrega està creixent

Estem començant a escalar el web, afegint un motor de cerca. Volem assegurar-nos que el catàleg de productes conté tots els productes. I aquesta cerca de productes funciona. Que la base de dades funciona, que s'estan fent comandes, que el lloc respon externament i respon des de dos servidors i l'usuari no és expulsat del lloc mentre es reequilibra a un altre servidor, etc. Hi ha més entitats.

A més, l'entitat associada a la infraestructura segueix sent la més gran al capdavant del gestor. Encara tinc una idea al cap que la persona que fa el seguiment és la persona que instal·larà zabbix i el podrà configurar.

Però, al mateix temps, es treballa en la realització de comprovacions externes, en la creació d'un conjunt de scripts de consulta de l'indexador de cerca, un conjunt d'scripts per comprovar que la cerca canvia durant el procés d'indexació, un conjunt de scripts que comproven que els béns es transfereixen al servei de lliurament, etc. etcètera.

Nota: vaig escriure "un conjunt de guions" 3 vegades. És a dir, el responsable del seguiment ja no és el que simplement instal·la zabbix. Aquesta és una persona que comença a codificar. Però encara no ha canviat res en la ment de l'equip.

Però el món està canviant, es fa cada cop més complex. S'afegeix una capa de virtualització i diversos sistemes nous. Comencen a interactuar entre ells. Qui va dir "fa olor de microserveis?" Però cada servei encara sembla un lloc web individualment. Podem recórrer-hi i entendre que proporciona la informació necessària i funciona per si sol. I si ets un administrador constantment implicat en un projecte que fa 5-7-10 anys que es desenvolupa, aquest coneixement s'acumula: apareix un nou nivell -te'n vas adonar, apareix un altre nivell- te'n vas adonar...

Però poques vegades ningú acompanya un projecte durant 10 anys.

Currículum del monitoringman

Suposem que heu arribat a una nova empresa que immediatament va contractar 20 desenvolupadors, va escriure 15 microserveis i sou un administrador a qui se li diu: "Crea CI/CD. Si us plau." Has construït CI/CD i de sobte escoltes: "Ens costa treballar amb la producció en un "cub", sense entendre com hi funcionarà l'aplicació. Fes-nos una caixa de sorra al mateix “cub”.
Feu una caixa de sorra en aquest cub. Immediatament us diuen: "Volem una base de dades d'etapa que s'actualitzi cada dia des de la producció, de manera que entenem que funciona a la base de dades, però al mateix temps no es fa malbé la base de dades de producció".

Tu vius en tot això. Queden 2 setmanes per a l'estrena, et diuen: "Ara vigilem tot això..." És a dir. supervisar la infraestructura del clúster, supervisar l'arquitectura del microservei, supervisar el treball amb serveis externs...

I els meus companys es treuen del cap l'esquema habitual i diuen: “Bé, aquí tot està clar! Instal·leu un programa que supervisarà tot això". Sí, sí: Prometheus + Grafana + connectors.
I afegeixen: "Tens dues setmanes, assegura't que tot estigui segur".

En molts projectes que veiem, s'assigna una persona per al seguiment. Imagineu que volem contractar una persona per fer un seguiment durant 2 setmanes, i li escrivim un currículum. Quines habilitats hauria de tenir aquesta persona, tenint en compte tot el que hem dit fins ara?

• Ha d'entendre el seguiment i les especificitats del funcionament de la infraestructura de ferro.
• Ha d'entendre les especificitats de la supervisió de Kubernetes (i tothom vol anar al "cub", perquè podeu abstraure's de tot, amagar-se, perquè l'administrador s'ocuparà de la resta) - ell mateix, la seva infraestructura i entendre com controlar les aplicacions. dins.
• Ha d'entendre que els serveis es comuniquen entre ells de maneres especials i conèixer les especificitats de com interactuen els serveis entre ells. És molt possible veure un projecte on alguns serveis es comuniquen de manera sincrònica, perquè no hi ha una altra manera. Per exemple, el backend passa per REST, mitjançant gRPC al servei de catàleg, rep una llista de productes i la retorna. No pots esperar aquí. I amb altres serveis funciona de manera asíncrona. Transferir la comanda al servei de lliurament, enviar una carta, etc.
  Segurament ja has nedat de tot això? I l'administrador, que ha de controlar-ho, es va confondre encara més.
• Ha de ser capaç de planificar i planificar correctament, a mesura que el treball es fa més i més.
• Per tant, ha de crear una estratègia a partir del servei creat per entendre com controlar-lo específicament. Necessita una comprensió de l'arquitectura del projecte i el seu desenvolupament + una comprensió de les tecnologies utilitzades en el desenvolupament.

Recordem un cas absolutament normal: alguns serveis estan en PHP, alguns serveis estan en Go, alguns serveis estan en JS. D'alguna manera treballen entre ells. D'aquí ve el terme "microservei": hi ha tants sistemes individuals que els desenvolupadors no poden entendre el projecte com un tot. Una part de l'equip escriu serveis en JS que funcionen per si mateixos i no saben com funciona la resta del sistema. L'altra part escriu serveis en Python i no interfereix amb el funcionament d'altres serveis; estan aïllats a la seva pròpia àrea. El tercer és escriure serveis en PHP o una altra cosa.
Totes aquestes 20 persones estan dividides en 15 serveis, i només hi ha un administrador que ha d'entendre tot això. Atura! acabem de dividir el sistema en 15 microserveis perquè 20 persones no poden entendre tot el sistema.

Però s'ha de controlar d'alguna manera...

Quin és el resultat? Com a resultat, hi ha una persona que arriba a tot allò que tot l'equip de desenvolupadors no pot entendre i, alhora, també ha de saber i poder fer el que hem indicat anteriorment: infraestructura de maquinari, infraestructura de Kubernetes, etc.

Què puc dir... Houston, tenim problemes.

El seguiment d'un projecte de programari modern és un projecte de programari en si mateix

A partir de la falsa creença que el monitoratge és programari, desenvolupem una creença en els miracles. Però els miracles, per desgràcia, no succeeixen. No podeu instal·lar zabbix i esperar que tot funcioni. No té sentit instal·lar Grafana i esperar que tot anirà bé. La major part del temps es dedicarà a organitzar comprovacions del funcionament dels serveis i la seva interacció entre ells, comprovant el funcionament dels sistemes externs. De fet, el 90% del temps es dedicarà no a escriure guions, sinó a desenvolupar programari. I hauria de ser gestionat per un equip que entengui el treball del projecte.
Si en aquesta situació es llança una persona a la vigilància, es produirà un desastre. Que és el que passa a tot arreu.

Per exemple, hi ha diversos serveis que es comuniquen entre ells a través de Kafka. La comanda va arribar, vam enviar un missatge sobre la comanda a Kafka. Hi ha un servei que escolta informació sobre la comanda i envia la mercaderia. Hi ha un servei que escolta informació sobre la comanda i envia una carta a l'usuari. I aleshores apareixen un munt de serveis més i ens comencem a confondre.

I si també ho doneu a l'administrador i als desenvolupadors en l'etapa en què queda poc temps abans del llançament, la persona haurà d'entendre tot aquest protocol. Aquells. Un projecte d'aquesta escala requereix una quantitat de temps important, i això s'ha de tenir en compte en el desenvolupament del sistema.
Però molt sovint, sobretot a les startups, veiem com el seguiment es posposa per a més tard. "Ara farem una prova de concepte, la llançarem amb ella, la deixarem caure, estem preparats per sacrificar-nos. I després ho controlarem tot". Quan (o si) el projecte comença a guanyar diners, l'empresa vol afegir encara més funcions, perquè ha començat a funcionar, de manera que s'ha de desplegar encara més! I esteu en el punt en què primer necessiteu controlar tot el que és anterior, que no triga l'1% del temps, sinó molt més. I, per cert, es necessitaran desenvolupadors per a la supervisió i és més fàcil deixar-los treballar amb noves funcions. Com a resultat, s'escriuen noves funcions, tot s'embolica i et trobes en un punt mort sense fi.

Llavors, com fer el seguiment d'un projecte des del principi, i què fer si obteniu un projecte que cal supervisar, però no saps per on començar?

Primer, cal planificar.

Digressió lírica: molt sovint comencen amb el seguiment de la infraestructura. Per exemple, tenim Kubernetes. Comencem instal·lant Prometheus amb Grafana, instal·lant connectors per supervisar el “cub”. No només els desenvolupadors, sinó també els administradors tenen la desafortunada pràctica de: "Instal·larem aquest connector, però probablement el connector sap com fer-ho". A la gent li agrada començar amb les accions senzilles i directes, en lloc de les accions importants. I el seguiment de la infraestructura és fàcil.

Primer, decidiu què i com voleu controlar i, a continuació, seleccioneu una eina, perquè altres persones no poden pensar per vosaltres. I ho haurien de fer? Altres persones pensaven per si mateixes sobre un sistema universal, o no pensaven gens quan es va escriure aquest connector. I el fet que aquest connector tingui 5 mil usuaris no vol dir que sigui de res. Potser et convertiràs en el 5001 simplement perquè abans ja hi havia 5000 persones.

Si comenceu a supervisar la infraestructura i el backend de la vostra aplicació deixa de respondre, tots els usuaris perdran la connexió amb l'aplicació mòbil. Apareixerà un error. Us vindran i us diran "L'aplicació no funciona, què feu aquí?" - "Estem monitoritzant". — "Com controleu si no veieu que l'aplicació no funciona?!"

1. Crec que cal començar el seguiment exactament des del punt d'entrada de l'usuari. Si l'usuari no veu que l'aplicació funciona, això és tot, és un error. I el sistema de seguiment hauria d'avisar-ho primer.
2. I només així podrem controlar la infraestructura. O fer-ho en paral·lel. És més fàcil amb la infraestructura: aquí finalment només podem instal·lar zabbix.
3. I ara cal anar a les arrels de l'aplicació per entendre on les coses no funcionen.

La meva idea principal és que el seguiment ha d'anar paral·lelament al procés de desenvolupament. Si distreu l'equip de supervisió per a altres tasques (creació de CI/CD, sandboxing, reorganització d'infraestructura), la supervisió començarà a retardar-se i és possible que mai no us posareu al dia amb el desenvolupament (o tard o d'hora l'haureu d'aturar).

Tot per nivells

Així és com veig l'organització d'un sistema de seguiment.

1) Nivell d'aplicació:

• supervisió de la lògica de negoci de l'aplicació;
• seguiment de les mètriques de salut dels serveis;
• seguiment de la integració.

2) Nivell d'infraestructura:

• seguiment del nivell d'orquestració;
• monitorització del programari del sistema;
• control del nivell de ferro.

3) De nou el nivell d'aplicació, però com a producte d'enginyeria:

• recollida i seguiment de registres d'aplicacions;
• APM;
• rastreig.

4) Alerta:

• organització d'un sistema d'avís;
• organització d'un sistema de deures;
• organització d'una "base de coneixement" i flux de treball per al processament d'incidències.

És important: arribem a l'alerta no després, sinó de seguida! No cal iniciar el seguiment i "d'alguna manera més tard" esbrinar qui rebrà alertes. Al cap i a la fi, quina és la tasca del seguiment: entendre en quin punt del sistema hi ha alguna cosa que funciona malament i fer-ho saber a les persones adequades. Si deixeu això fins al final, la gent adequada sabrà que alguna cosa va malament només dient "no ens funciona res".

Capa d'aplicació - Monitorització de la lògica empresarial

Aquí estem parlant de comprovar el fet mateix que l'aplicació funciona per a l'usuari.

Aquest nivell s'ha de fer durant la fase de desenvolupament. Per exemple, tenim un Prometheus condicional: va al servidor que fa les comprovacions, treu el punt final i el punt final va i comprova l'API.

Quan sovint se'ls demana que supervisin la pàgina d'inici per assegurar-se que el lloc funciona, els programadors donen un control que es pot treure cada vegada que necessiten per assegurar-se que l'API funciona. I els programadors en aquest moment encara prenen i escriuen /api/test/helloworld
L'única manera d'assegurar-se que tot funciona? - No!

• Crear aquestes comprovacions és essencialment tasca dels desenvolupadors. Les proves unitàries les han d'escriure els programadors que escriuen el codi. Perquè si el filtres a l'administrador, "Amic, aquí hi ha una llista de protocols de l'API per a les 25 funcions, si us plau, supervisa-ho tot!" - no sortirà res.
• Si imprimiu "hola món", ningú no sabrà mai que l'API hauria de funcionar i funciona. Cada canvi d'API ha de comportar un canvi en les comprovacions.
• Si ja teniu aquest problema, atureu les funcions i assigneu desenvolupadors que escriuran aquestes comprovacions, o accepten les pèrdues, accepteu que no es comprova res i fallarà.

Consells tècnics:

• Assegureu-vos d'organitzar un servidor extern per organitzar les comprovacions; heu d'assegurar-vos que el vostre projecte sigui accessible al món exterior.
• Organitzeu les comprovacions a tot el protocol de l'API, no només a punts finals individuals.
• Creeu un punt final de prometheus amb els resultats de la prova.

Capa d'aplicació: monitorització de mètriques de salut

Ara estem parlant de mètriques de salut externa dels serveis.

Vam decidir que controlem tots els "handles" de l'aplicació mitjançant comprovacions externes, que anomenem des d'un sistema de control extern. Però aquestes són les "anilles" que l'usuari "veu". Volem estar segurs que els nostres serveis funcionin. Aquí hi ha una història millor: K8s té controls de salut, de manera que almenys el "cub" en si mateix es pot convèncer que el servei funciona. Però la meitat dels xecs que he vist són la mateixa lletra "hola món". Aquells. Així que tira una vegada després del desplegament, va respondre que tot està bé, això és tot. I el servei, si disposa de la seva pròpia API, té un gran nombre de punts d'entrada per a aquesta mateixa API, que també cal supervisar, perquè volem saber que funciona. I ja ho estem vigilant per dins.

Com implementar-ho correctament tècnicament: cada servei exposa un punt final sobre el seu rendiment actual, i als gràfics de Grafana (o qualsevol altra aplicació) veiem l'estat de tots els serveis.

• Cada canvi d'API ha de comportar un canvi en les comprovacions.
• Creeu un servei nou immediatament amb mètriques de salut.
• Un administrador pot venir als desenvolupadors i demanar-li "afegeix-me un parell de funcions perquè ho entengui tot i afegeixi informació sobre això al meu sistema de supervisió". Però els desenvolupadors solen respondre: "No afegirem res dues setmanes abans del llançament".
  Feu que els gestors de desenvolupament sàpiguen que hi haurà pèrdues així, que també ho sàpiguen els gestors de desenvolupament. Perquè quan tot cau, algú encara trucarà i exigirà controlar el "servei en constant caiguda" (c)
• Per cert, assigneu als desenvolupadors que escriguin complements per a Grafana; això serà una bona ajuda per als administradors.

Capa d'aplicació - Monitorització d'integració

El seguiment de la integració se centra a supervisar les comunicacions entre sistemes crítics per a l'empresa.

Per exemple, hi ha 15 serveis que es comuniquen entre ells. Aquests ja no són llocs separats. Aquells. no podem treure el servei per si sol, obtenir /helloworld i entendre que el servei s'està executant. Com que el servei web de comandes ha d'enviar informació sobre la comanda a l'autobús, des de l'autobús, el servei de magatzem ha de rebre aquest missatge i seguir treballant amb ell. I el servei de distribució de correu electrònic ha de processar-ho d'alguna manera més, etc.

En conseqüència, no podem entendre, analitzant cada servei individual, que tot funcioni. Perquè tenim un cert bus a través del qual tot es comunica i interactua.
Per tant, aquesta etapa hauria de marcar l'etapa de proves de serveis per a la interacció amb altres serveis. És impossible organitzar el seguiment de la comunicació mitjançant el seguiment de l'agent de missatges. Si hi ha un servei que emet dades i un servei que les rep, en el seguiment del corredor només veurem dades que volen d'un costat a l'altre. Fins i tot si d'alguna manera hem aconseguit controlar la interacció d'aquestes dades internament (que un determinat productor publica les dades, algú les llegeix, aquest flux continua dirigint-se a Kafka), això encara no ens donarà informació si un servei envia el missatge en una versió. , però l'altre servei no s'esperava aquesta versió i la va saltar. No ho sabrem, ja que els serveis ens indicaran que tot funciona.

Què us recomano fer:

• Per a la comunicació síncrona: el punt final fa sol·licituds als serveis relacionats. Aquells. agafem aquest punt final, tirem un script dins del servei, que va a tots els punts i diu "Puc tirar-hi, i estirar-hi, puc tirar-hi...".
• Per a la comunicació asíncrona: missatges entrants: el punt final comprova si hi ha missatges de prova al bus i mostra l'estat de processament.
• Per a la comunicació asíncrona: missatges de sortida: el punt final envia missatges de prova al bus.

Com sol passar: tenim un servei que llença dades a l'autobús. Ens apropem a aquest servei i li demanem que ens parli de la seva salut d'integració. I si el servei necessita produir un missatge en algun lloc més llunyà (WebApp), produirà aquest missatge de prova. I si executem un servei al costat del processament de comandes, primer publica el que pot publicar independentment, i si hi ha algunes coses dependents, llavors llegeix un conjunt de missatges de prova des del bus, entén que els pot processar, informar-ne i , si cal, publiqueu-los més, i sobre això diu: tot està bé, estic viu.

Molt sovint escoltem la pregunta "com podem provar això amb dades de combat?" Per exemple, estem parlant del mateix servei de comandes. La comanda envia missatges al magatzem on es cancel·len les mercaderies: no podem provar-ho a les dades de combat, perquè "els meus béns seran cancel·lats!" Solució: planifica tota aquesta prova des del principi. També teniu proves unitàries que fan simulacres. Per tant, fes-ho a un nivell més profund on tinguis un canal de comunicació que no perjudiqui el funcionament del negoci.

Nivell d'infraestructura

El seguiment d'infraestructures és una cosa que durant molt de temps s'ha considerat com a monitoratge en si.

• El seguiment de la infraestructura pot i s'ha de posar en marxa com un procés independent.
• No hauríeu de començar amb la supervisió de la infraestructura en un projecte en execució, fins i tot si realment ho voleu. Això és un dolor per a tots els devops. "Primer supervisaré el clúster, supervisaré la infraestructura", és a dir. En primer lloc, supervisarà el que hi ha a continuació, però no entrarà a l'aplicació. Perquè l'aplicació és una cosa incomprensible per als devops. Se li va filtrar i no entén com funciona. Però entén la infraestructura i comença per ella. Però no, primer sempre cal supervisar l'aplicació.
• No us exagereu amb el nombre d'alertes. Tenint en compte la complexitat dels sistemes moderns, les alertes volen constantment i, d'alguna manera, heu de viure amb aquest munt d'alertes. I la persona de guàrdia, després d'haver mirat un centenar de les properes alertes, decidirà "No hi vull pensar". Les alertes només haurien de notificar coses crítiques.

Nivell d'aplicació com a unitat de negoci

Punts clau:

• ELK. Aquest és l'estàndard de la indústria. Si per algun motiu no esteu agregant registres, comenceu a fer-ho immediatament.
• APM. APM externs com a forma de tancar ràpidament la supervisió d'aplicacions (NewRelic, BlackFire, Datadog). Podeu instal·lar-ho temporalment per, almenys, entendre d'alguna manera què us està passant.
• Traçat. En desenes de microserveis, cal rastrejar-ho tot, perquè la sol·licitud ja no viu per si sola. És molt difícil afegir més tard, per la qual cosa és millor programar immediatament el seguiment en desenvolupament: aquesta és la feina i la utilitat dels desenvolupadors. Si encara no l'heu implementat, implementeu-lo! Vegeu Jaeger/Zipkin

Alerta

• Organització d'un sistema de notificacions: en condicions de seguiment d'un munt de coses, hauria d'haver un sistema unificat d'enviament de notificacions. Pots a Grafana. A Occident, tothom fa servir PagerDuty. Les alertes han de ser clares (per exemple, d'on provenen...). I és recomanable controlar que es rebin les notificacions
• Organització d'un sistema de guàrdia: no s'han d'enviar alertes a tothom (o tothom reaccionarà entre una multitud, o ningú reaccionarà). Els desenvolupadors també han d'estar de vigilància: assegureu-vos de definir àrees de responsabilitat, fer instruccions clares i escriure-hi a qui trucar exactament dilluns i dimecres i a qui trucar dimarts i divendres (en cas contrari, no trucaran a ningú ni tan sols a la cas d'un gran problema: tindran por de despertar-te o molestar-te: la gent generalment no els agrada trucar i despertar a altres persones, especialment a la nit). I expliqueu que demanar ajuda no és un indicador d'incompetència (“Demano ajuda, això vol dir que sóc un mal treballador”), fomenteu les peticions d'ajuda.
• Organització d'una “base de coneixement” i flux de treball per al tractament d'incidències: per a cada incident greu s'ha de planificar una autopsia i, com a mesura temporal, s'han de registrar les accions que resolguin la incidència. I fes una pràctica que les alertes repetides són un pecat; s'han d'arreglar en codi o treball d'infraestructura.

Pila de tecnologia

Imaginem que la nostra pila és la següent:

• recollida de dades - Prometheus + Grafana;
• anàlisi de registre - ELK;
• per a APM o Tracing - Jaeger (Zipkin).

L'elecció de les opcions no és crítica. Perquè si al principi vau entendre com controlar el sistema i vau escriure un pla, llavors comenceu a triar les eines que s'adaptin als vostres requisits. La pregunta és què heu triat controlar en primer lloc. Perquè potser l'eina que vau triar al principi no s'adapta en absolut als vostres requisits.

Alguns punts tècnics que veig a tot arreu últimament:

Prometeu està sent empès dins de Kubernetes: a qui se li va ocórrer?! Si el vostre clúster falla, què fareu? Si teniu un clúster complex a l'interior, hi hauria d'haver algun tipus de sistema de control dins del clúster i un altre a l'exterior, que recopilarà dades des de dins del clúster.

Dins del clúster recollim registres i tota la resta. Però el sistema de control ha d'estar fora. Molt sovint, en un clúster on hi ha Promtheus instal·lat internament, també hi ha sistemes que realitzen comprovacions externes del funcionament del lloc. Què passa si les vostres connexions amb el món exterior han caigut i l'aplicació no funciona? Resulta que tot està bé per dins, però no facilita les coses als usuaris.

Troballes

• El seguiment del desenvolupament no és la instal·lació d'utilitats, sinó el desenvolupament d'un producte de programari. El 98% del seguiment actual és codificació. Codificar serveis, codificar comprovacions externes, comprovar serveis externs i això és tot.
• No perdis el temps dels teus desenvolupadors en la supervisió: pot ocupar fins a un 30% del seu treball, però val la pena.
• Devops, no us preocupeu que no podeu controlar alguna cosa, perquè algunes coses són una manera de pensar completament diferent. No eres programador, i supervisar el treball és exactament la seva feina.
• Si el projecte ja s'està executant i no està supervisat (i sou gestor), assigneu recursos per al seguiment.
• Si el producte ja està en producció i sou un devops al qual se li va dir que "configureu la supervisió", intenteu explicar a la direcció de què vaig escriure tot això.

Aquesta és una versió ampliada de l'informe a la conferència de Saint Highload++.

Si esteu interessats en les meves idees i pensaments sobre això i temes relacionats, aquí podeu fer-ho llegir el canal 🙂

Font: www.habr.com