IT-support: När problemet sitter mellan två system, inte i något av dem

När ett IT-problem uppstår är det lätt att leta efter felet i det system som verkar krångla. Men ibland fungerar både systemen var för sig, medan kommunikationen mellan dem har gått snett. Det kan handla om integrationer, API:er, behörigheter, datamappning eller inkompatibla versioner som gör att information inte överförs som den ska. För användaren märks det kanske som ett felmeddelande, en utebliven synkronisering eller data som försvinner på vägen. Just därför kräver den här typen av incidenter ett annat angreppssätt. Med rätt IT-support går det att följa informationsflödet mellan systemen och identifiera var problemet faktiskt uppstår.

När systemen fungerar – men kommunikationen brister

Ett IT-problem behöver inte betyda att ett enskilt system är trasigt. I många verksamheter används flera program som måste utbyta information för att arbetsflödena ska fungera. Ett affärssystem kan exempelvis behöva skicka orderinformation till ett lagerprogram, medan ett ekonomisystem hämtar fakturaunderlag från ett annat system. Om båda applikationerna fungerar korrekt var för sig kan felet ändå uppstå när informationen ska överföras mellan dem. För användaren kan resultatet bli svårt att förstå, eftersom det inte finns någon tydlig komponent som verkar vara trasig. Det är här felsökning mellan systemen blir avgörande.

När gränssnittet blir den svaga länken

Mellan två system finns ofta ett gränssnitt som styr hur information skickas, tas emot och tolkas. Det kan vara ett API, en integrationsplattform, en filöverföring eller någon annan teknisk koppling. Om gränssnittet förändras utan att det andra systemet anpassas kan kommunikationen sluta fungera. Ett system kan exempelvis skicka ett värde i ett format som mottagaren inte längre accepterar. Samtidigt kan båda systemen visa grönt i sina egna statuspaneler. Problemet finns då i själva överföringen, vilket gör att traditionell felsökning som fokuserar på en applikation i taget riskerar att missa orsaken.

IT-support behöver därför undersöka hela informationskedjan. Det innebär att följa vad som händer från det att en användare skapar eller ändrar information tills den ska finnas tillgänglig i nästa system. Loggar, tidsstämplar och felmeddelanden kan visa var flödet avbryts. I vissa fall skickas informationen korrekt men stoppas av en behörighetskontroll. I andra fall kommer den fram, men kan inte behandlas eftersom fälten eller datatyperna inte överensstämmer. Genom att analysera hela kedjan går det att skilja mellan ett faktiskt systemfel och ett integrationsproblem.

Datamappning kan skapa dolda fel

Ett vanligt problem är att två system använder olika benämningar eller strukturer för samma information. Ett system kan exempelvis kalla ett kundnummer för ”customer_id”, medan ett annat förväntar sig ett fält med ett helt annat namn. Integrationen måste då översätta informationen mellan formaten. Om en sådan datamappning är felaktig kan överföringen tekniskt sett lyckas, samtidigt som resultatet blir fel. Det kan leda till tomma fält, felaktiga värden eller poster som inte skapas. Den här typen av problem kräver därför både teknisk förståelse och kunskap om verksamhetens informationsflöden.

Integrationer, API:er och dataflöden som skapar problem

Moderna IT-miljöer består ofta av många olika tjänster som är beroende av varandra. Ett företag kan använda separata system för ekonomi, kundhantering, lager, försäljning, dokumenthantering och kommunikation. För att minska manuellt arbete kopplas systemen samman genom integrationer. När dessa fungerar märker användaren sällan vad som sker i bakgrunden. När kommunikationen däremot bryts kan konsekvenserna snabbt bli märkbara. En order kanske inte registreras i lagersystemet, en kunduppgift kanske inte uppdateras eller en faktura kanske inte får rätt underlag. Då behöver IT-support analysera dataflödet snarare än enbart programmen.

API:er kräver kompatibilitet

API:er fungerar som definierade kontaktpunkter mellan olika system. De anger bland annat vilka anrop som får göras, vilken information som ska skickas och vilket svar som ska returneras. Om ett API uppdateras kan äldre integrationer påverkas, särskilt om fält, autentiseringsmetoder eller regler för datahantering förändras. Ett system kan fortfarande fungera normalt för sina egna användare, medan kommunikationen med ett annat system slutar fungera. Därför är versionshantering och dokumentation viktiga delar av integrationsarbetet. IT-support behöver kunna avgöra om ett fel uppstod efter en förändring och vilka delar av kedjan som berörs.

Vid felsökning är det ofta effektivt att kontrollera dataflödet steg för steg. Exempelvis kan supporten undersöka:

• Om det första systemet faktiskt skickar informationen.

• Om integrationen tar emot informationen utan kommunikationsfel.

• Om autentisering och behörigheter fortfarande fungerar.

• Om informationen följer rätt format och struktur.

• Om mottagande system kan behandla informationen korrekt.

Loggar visar vad användaren inte ser

Användaren ser vanligtvis bara slutresultatet av en misslyckad integration. Ett meddelande som ”något gick fel” säger inte nödvändigtvis var problemet uppstod. I bakgrunden kan det däremot finnas detaljerade loggar som registrerar anrop, svarskoder, tidpunkter och andra tekniska händelser. Genom att jämföra loggar från de berörda systemen kan IT-support följa en specifik transaktion genom hela flödet. Det gör det möjligt att se om informationen aldrig skickades, om den stoppades på vägen eller om mottagaren tog emot den men misslyckades med behandlingen.

En viktig del av arbetet är också att skilja mellan tillfälliga störningar och återkommande integrationsfel. Ett kortvarigt nätverksavbrott kan exempelvis göra att en överföring misslyckas, medan en förändring i ett API kan orsaka samma fel varje gång en viss typ av information skickas. Därför behöver supporten inte bara återställa funktionen utan även identifiera mönstret bakom incidenten. När orsaken dokumenteras blir det lättare att upptäcka liknande händelser senare och att minska tiden för framtida felsökning.

Så kan IT-support hitta felet mellan systemen

När ett problem sitter mellan två system krävs en metodisk felsökningsprocess. Det första steget är att beskriva vad som faktiskt händer, inte bara vilket felmeddelande användaren ser. Supporten behöver exempelvis fastställa vilken information som saknas, när problemet började och vilka arbetsflöden som påverkas. Därefter kan varje steg i kommunikationen kontrolleras separat. På så sätt blir det möjligt att avgöra om felet finns hos avsändaren, i själva integrationen, hos mottagaren eller i någon bakomliggande tjänst som båda systemen är beroende av.

Börja med förändringar och avvikelser

Tidpunkten för ett fel kan ge viktig information. Om kommunikationen fungerade under flera månader och plötsligt slutade fungera kan en förändring ha skett i någon del av miljön. Det kan vara en ny programversion, ändrade säkerhetsregler, uppdaterade API:er, nya certifikat eller justerade behörigheter. Även förändringar som verkar orelaterade kan påverka en integration. Genom att jämföra systemens historik med tidpunkten för incidenten kan IT-support begränsa antalet möjliga orsaker. Det är särskilt viktigt i miljöer där flera leverantörer ansvarar för olika delar av samma tekniska kedja.

Dokumentation spelar samtidigt en central roll. När integrationer saknar tydliga beskrivningar kan det vara svårt att veta vilka system som kommunicerar, vilka datafält som används och vilka beroenden som finns. En strukturerad dokumentation bör därför bland annat beskriva:

• Vilka system som kommunicerar med varandra.

• Vilka gränssnitt och integrationsvägar som används.

• Vilken typ av information som överförs.

• Vilka autentiserings- och behörighetskrav som gäller.

• Vilka system eller tjänster som är beroende av flödet.

Testa kommunikationen utan att störa verksamheten

Felsökning bör så långt som möjligt genomföras på ett kontrollerat sätt. Att göra omfattande ändringar direkt i en produktionsmiljö kan skapa nya problem och göra den ursprungliga orsaken svårare att identifiera. Därför kan IT-support behöva använda testmiljöer, begränsade testdata eller specifika transaktioner för att återskapa felet. När samma beteende kan reproduceras blir det lättare att undersöka en hypotes och verifiera om en viss förändring faktiskt löser problemet. Det minskar också risken för att tillfälliga lösningar maskerar ett mer grundläggande integrationsfel.

När orsaken har identifierats behöver åtgärden dokumenteras och följas upp. Det räcker inte alltid att få kommunikationen att fungera igen. Om problemet berodde på en ändring i ett API, en behörighet eller en datamappning behöver den bakomliggande miljön också anpassas för att minska risken för att samma fel återkommer. På så sätt blir IT-support en del av det långsiktiga arbetet med stabila integrationer, snarare än en funktion som enbart ingriper när användarna redan har drabbats av ett avbrott.