Vad integrationsövervakning måste upptäcka
En vanlig tisdag tar en webbutik emot 400 beställningar. Systemintegrationen som för över dem till affärssystemet levererar 380 och avvisar 20, eftersom en ny rabattkod skapade ett fält som affärssystemet inte accepterade.
Ingenting låg nere. Ingen varning utlöstes. Lagret plockar det de kan se, ekonomiavdelningen rapporterar det som nått huvudboken, och 20 kunder väntar på bekräftelser som aldrig kommer. Alla system var online under hela tiden, vilket är anledningen till att drifttid är fel sak att hålla koll på.
- Poster som mottagarsystemet avvisat: en beställning eller produkt som nekats på grund av valideringsfel, vilket är ett affärsmässigt fel snarare än ett tekniskt
- Volymer som minskat utan att stanna av: ett flöde som normalt hanterar 400 beställningar men bara hanterar 380, vilket ser ut att fungera men inte gör det
- Data som kommit fram men är felaktig: ett fält som mappats felaktigt efter en ändring i någon av ändarna, vilket gör att mottagarsystemet accepterar ett värde det inte borde
- Flöden som aldrig kördes: ett schemalagt jobb som inte startade, vilket inte ger upphov till något fel eftersom ingenting hände
- Data som kom fram för sent: ett lagersaldo som når butiken efter att någon redan sålt den sista enheten
Den fjärde punkten är den som de flesta övervakningssystem missar. Ett jobb som aldrig körs skickar ingen signal, så det är bara något som bevakar dess frånvaro som kommer att märka det.
Varför förblir systemintegrationsfel osynliga?
Den främsta anledningen är att det inte finns någonstans att övervaka från. När en systemintegration byggs direkt mellan två applikationer känner den bara till sitt eget tillstånd och inget annat. Ett företag som kör fyrtio sådana har fyrtio separata ställen att titta på och ingen vy som täcker dem alla. Det är en av de dolda kostnaderna för punkt-till-punkt-integration, och den syns sällan i byggkalkylen.
Bekräftelser är också missvisande. När ett mottagande system svarar med ett lyckat meddelande betyder det oftast bara att meddelandet togs emot, inte att posten bearbetades korrekt. En post kan alltså markeras som levererad utan att för den skull existera i någon användbar form i andra änden.
Den tredje anledningen är ägarskap. Teamet som kör affärssystemet övervakar affärssystemet. E-handelsteamet övervakar butiken. Kopplingen mellan dem tillhör den som byggde den, och den personen kanske har slutat. Det glappet är där felen varar längst, eftersom det inte finns någon som ansvarar för den kontrollpanelen.
Ett tyst fel är alltså inte bara oupptäckt. Det är oupptäckt på den enda plats där ingen letar.
Vad bristfällig integrationsövervakning kostar
Kostnaden beror på hur länge ett fel pågår innan någon märker det.
- Kunder som larmar: den första rapporten kommer från någon vars beställning inte har kommit fram, vilket är det dyraste sättet att få reda på det
- Eftersläpningar som ingen ser växa: ett avbrott i tre dagar innebär tre dagars poster som måste bearbetas på nytt
- Beslut fattade på ofullständiga data: en rapport eller en lagerpåfyllning som körs mot ett dataset där allt som det trasiga flödet skulle ha hanterat saknas
- Diagnos som mäts i dagar: utan loggar över vad som flyttats och när, innebär felsökning att man måste kontrollera varje system i tur och ordning
- Förlorat förtroende inom verksamheten: efter ett enda tyst fel börjar manuella kontroller dyka upp vid sidan av automatiseringen
Den sista punkten lever kvar efter incidenten. Allt annat åtgärdas, men den manuella kontrollen blir kvar.
Varför integrationsövervakning är en annan fråga än drifttid
Infrastrukturövervakning handlar om huruvida system är tillgängliga och svarar. Det är en relevant fråga, och den fångar upp avbrott som man ändå hade märkt av.
Integrationsövervakning handlar om något annat. Nådde dagens order fram till affärssystemet? Tillämpades varje prisändring? Nådde varje leveransbekräftelse marknadsplatsen i tid? Det är frågor om data snarare än tillgänglighet, och en miljö kan klara det första testet men misslyckas med alla tre.
Att besvara dem innebär att veta vad som borde ha hänt, inte bara vad som faktiskt hände. Ett system som rapporterar fel kan inte berätta om 20 order som borde ha anlänt men inte gjorde det, eftersom inget fel uppstod. Övervakning som känner till det normala flödet kan flagga för avvikelser direkt. Det är en annan disciplin än övervakning och loggning som en säkerhets- och granskningsfunktion.
Tre metoder är vanliga, och alla har sina blinda fläckar. Infrastrukturverktyg bevakar tillgänglighet och vet ingenting om huruvida en post har accepterats. Loggning inuti varje anslutning fungerar bara för just den anslutningen. Att vänta på klagomål är standard, och det är anledningen till att tysta fel kan pågå i dagar.
Hur gör en integrationsplattform flöden observerbara?
En integrationsplattform (iPaaS) kopplar samman system via en central hubb istället för att länka varje par direkt. Varje system ansluter till integrationsplattformen en gång. Den flyttar sedan data mellan dem, omformar den på vägen och levererar det format som varje destination förväntar sig.
Att centralisera anslutningarna är det som gör övervakning möjlig. Varje flöde passerar nu genom en och samma plats, så det finns äntligen en punkt att övervaka ifrån. Integrationsplattformen hanterar redan varje meddelande, så att registrera vad det innehöll, vart det tog vägen och om destinationen accepterade det kostar inget extra.
Alumio är en integrationsplattform byggd på den principen, med synlighet inbyggd i lagret snarare än tillagd i efterhand. Inom Alumio-plattformen tar detta fyra former.
- Synlighet på meddelandenivå: inspektionsverktyget i Alumio visar innehållet i enskilda meddelanden och var varje meddelande stannade, så att felsökningen baseras på bevis snarare än gissningar
- Misslyckanden som görs om, sedan eskaleras: tillfälliga fel åtgärdas automatiskt genom omförsök, och ihållande fel skickar en varning, så att korta avbrott löser sig själva medan verkliga problem får uppmärksamhet
- Lagras istället för att gå förlorade: en inbyggd lagring köar poster som destinationen inte kunde ta emot, så att ingenting går förlorat medan problemet åtgärdas och korrigerade poster kan skickas i efterhand
- En vy över alla flöden: instrumentpaneler, detaljerade loggar och granskningsspår som täcker alla integrationer istället för att varje anslutning rapporterar separat
Vissa företag kräver detta i förskott. Heusinkveld, en nederländsk tillverkare av simracing-hårdvara som säljer via återförsäljare och sin egen WooCommerce-webbshop, ställde tre krav när de bytte till Odoo som sitt affärssystem. De behövde koppla webbshoppen till det nya affärssystemet, kontroll över vilka produkter och lagernivåer som synkroniserades, samt anpassade övervakningslarm. I samarbete med Odoo- och iPaaS-specialisten BlueZebra implementerade de integrationsplattformen Alumio för att uppfylla alla tre. Övervakning inkluderades i projektets omfattning från början istället för att läggas till som en korrigering efter det första felet.
Att upptäcka felet är bara halva jobbet. När något har gått fel visar inspektionsverktyget data för varje steg i flödet. Det steg som gick fel är synligt direkt, istället för att behöva pusslas ihop från loggfiler. Planerat underhåll kan schemaläggas så att förväntade driftstopp inte utlöser larm, vilket är det som gör att team slutar ignorera dem.
Eftersom denna insyn är en inbyggd del av själva integrationsplattformen är en ny integration observerbar från den dag den tas i drift.
Vad integrationsövervakning ger verksamheten
Övervakning ses ofta som en administrativ uppgift, vilket gör att den specificeras först efter att integrationerna har byggts och finansierats sist. Dess verkliga effekt ligger i hur mycket ett företag är villigt att automatisera.
Tre roller bär konsekvenserna. IT-chefen får förklara ett fel utan att ha någon historik över vad som skickats. Kundtjänstchefen får höra om det först och har inget att berätta för kunden. Operationschefen behåller en manuell kontroll vid sidan av automatiseringen, vilket innebär att processen aldrig blev helt automatiserad, bara dubblerad.
Förtroende är det som tar bort behovet av manuell kontroll. Fel upptäcks av ett larm istället för av en kund, och diagnosen tar minuter eftersom meddelandehistoriken redan finns där. En integrationsplattform gör detta till normen för ett nytt flöde istället för ett projekt som följer i efterhand.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
