Voordat het applicatiesysteem wordt gelanceerd, kunnen defecten en verborgen gevaren sterk worden verminderd door intensief testen, maar omdat de simulatieomgeving van de test niet exact hetzelfde kan zijn als de echte omgeving na de lancering van het systeem, kan het testwerk niet alle scenario's van IT-applicatiesysteemproductie en -werking dekken, en is het moeilijk om het voorkomen van storingen van IT-applicatiesystemen in een specifiek scenario. Omdat het verborgen gevaar van falen onvermijdelijk is, is het heel belangrijk om de fout rustig aan te pakken! Het is het beste om van tevoren te weten, de mogelijke problemen van het IT-applicatiesysteem te voorspellen en maatregelen te nemen wanneer het probleem niet optreedt om de fout in de kiem te elimineren. Hoe ernstig het ook is, we moeten zo snel mogelijk weten welke problemen in het systeem zijn opgetreden en waar ze zich hebben voorgedaan, en ze op tijd aanpakken voordat ze zich verspreiden om te voorkomen dat de situatie escaleert. In werkelijkheid, omdat deze twee punten nog steeds moeilijk te doen zijn, is de druk van bediening en onderhoud ongekend! Als je kijkt naar de huidige ondernemingen met een hoge mate van informatieconstructie zoals banken vertegenwoordigen, wordt bedrijfsontwikkeling steeds afhankelijker van IT, wordt de complexiteit van hun IT-applicaties steeds hoger en wordt de controleerbaarheid steeds slechter. Maar wat een hoofdpijndossier is, is dat in zo'n intensieve achtervolging en onderschepping systeemstoringen toch voorkomen, risico's steeds weer opvlammen, en vaak kleine problemen uiteindelijk uitgroeien tot grote storingen; wat is de reden? Waarom is er altijd een vertraging in de ontdekking? Waarom kunnen verschillende monitoringsmethoden niet meteen afwijkingen detecteren? Het is noodzakelijk dit te ontleden. Wat betreft de belangrijkste aspecten is de computerruimte onderverdeeld in twee categorieën: basisbronnen en IT-applicatiesystemen. We hechten lange tijd veel waarde aan basisvoorzieningen zoals netwerk, host, opslag, temperatuur en luchtvochtigheid van de computerruimte, en de monitoringsmethoden kunnen worden omschreven als "tot de tanden bewapend". Voor de monitoring van IT-applicatiesystemen leveren momenteel binnenlandse en buitenlandse fabrikanten en dienstverleners veel producten of oplossingen; de inhoud van monitoring heeft een eigen focus, uitgebreide analyse; hun praktijk is vooral het observeren van de prestaties van het IT-applicatiesysteem op de basislaag van de bronnen, via netwerkverkeer, systeemprestaties, CPU-bezetting, geheugenbezetting, database-toegang, middlewarestatus en andere indicatoren, gecombineerd met loganalyse, probe-verkenning, simulatie-toegang en proxy-extractie en andere methoden om bepaalde tijdsinformatie van de systeemwerking te verkrijgen. Grofweg beoordelen we de algemene operationele status van een systeem, missen deze producten of oplossingen het continu volgen en monitoren van systeembedieningsdetails, waardoor ze de details van de operationele status van elke module binnen het IT-applicatiesysteem en zelfs de functionele punten onder de module niet kunnen begrijpen; deze details omvatten: Welke transacties verwerkt het systeem? Wat is geslaagd? Wat is problematisch? Wie start de transactie? Wanneer wordt het gelanceerd? Wat voor zaken doe je? Welke module van het systeem is erbij betrokken? Welk functiepunt is verantwoordelijk voor de verwerking? Hoe laat komt de reactie terug? Zijn er prestatie-anomalieën? Als het niet succesvol is, wat is dan de schuld? Ze zijn erg belangrijk om de operationele status van een IT-applicatiesysteem te beoordelen. In de praktijk, aan het begin van de uitval van het IT-applicatiesysteem, wanneer het foutpunt weinig invloed heeft op de basisbronnen of nog niet is verzonden naar de basisbronlaag, of de fout optreedt in de tussenperiode tussen het gebruik van logs, probes, proxies en andere middelen, hoewel het systeemrisico "onderstroom" was, maar vaak kunnen de bestaande monitoringsmethoden geen rol spelen, en de externe presentatie ook "geen abnormaliteit" is. Dit is ook de fundamentele reden waarom foutdetectie achterloopt en moeilijk te hanteren is! Het is duidelijk dat tijdige detectie van systeemstoringen in de "eerste keer" een tekortkoming is van de huidige IT-operatie en onderhoud, en het is van groot belang om IT-operatie en onderhoud te compenseren. Wat is "eerste keer"? Dat wil zeggen, in het proces van een IT-applicatiesysteem dat reageert op toegangsverzoeken, moet het moment dat een transactie faalt of abnormaal plaatsvindt, nauwkeurig worden vastgelegd! Iedereen weet dat vroege detectie op tijd kan worden opgelost, en om de huidige passieve situatie van IT-operaties om te keren en de tekortkomingen in IT-operatie en onderhoud te compenseren, is het noodzakelijk om technisch het probleem van het detecteren van systeemstoringen "meteen" op te lossen. Door vergelijkend onderzoek en de praktijk van de werking van een groot aantal IT-applicatiesystemen is dit idee technisch eigenlijk haalbaar, maar de mensen in het bureau kunnen worden beïnvloed door traagheidsdenken, niet uit de oorspronkelijke denkwijze springen en zelfs denken dat het niet haalbaar is in subjectief bewustzijn, wat resulteert in geen substantiële doorbraak in dit aspect van het werk, en de operationele risico's van IT-toepassingen altijd in een passieve situatie van fragmentarische respons zijn. De sleutel tot het realiseren van de "eerste keer" detectie van systeemstoringen is om "attent te zijn" op het IT-applicatiesysteem, elke beweging te beheersen, specifiek om een diepgaande observatie van de operationele details van het IT-applicatiesysteem uit te voeren en de werking van elke module en elk functioneel punt strikt te monitoren; tegelijkertijd moet deze monitoring continu en ononderbroken zijn, alleen op deze manier zal geen systeemtransactie-afwijkingen worden gemist en de werking van het IT-applicatiesysteem in een beheersbare staat is. Omdat dit proces gedetailleerde informatie over de operationele status van het systeem kan verkrijgen en verzamelen, een zeer waardevol systeemoperatiebestand kan opbouwen door analyse en gebruik, kan het niet alleen een referentie bieden om de kwaliteit van elke module en elk functioneel punt te beoordelen, maar ook een basis bieden voor het analyseren van de ontwikkeling en verandering van de operationele status van het systeem, waardoor het mogelijk wordt de gezondheidstrend van een IT-applicatiesysteem te voorspellen.
|