Praktijk en practices

Troubleshooting Praktijk en practices

Ruud van Leeuwen

Spreker(s) Datum

: :

6 juni 2013

E-mail

:

[email protected] WWW.TRANSFER-SOLUTIONS.COM

Onderwerpen Tech stack komt aan bod Werkwijzen van troubleshooting

Betrokken partijen en hun rol Praktijkvoorbeelden tonen: complexiteit van de stack belang van juiste logging belang van juist inzicht in applicatie componenten

© COPYRIGHT TRANSFER SOLUTIONS B.V.

Voorbeeld stack

Database en Documenten


Java applicatie

(HTTP) Proxy

Toegang over internet

3

Voorbeeld stack Praktijkvoorbeelden Voorbeeld stack: programmatuur van opslag tot gebruiker Plaatje verzekering klant database (structured data) document repository db-logica java applicatie logica op Applicatie Server reverse proxy


Casus – download bestand Modernisering architectuur: applicatie wijzigt Java4 -> Java7 upgrade (incl libraries)

WebSphere 6 -> GlassFish 3 (AS) Ook Oracle dbms 10g -> Oracle dbms 11g

Vernieuwde omgevingen (virtual hosts) Database en Documenten


Java applicatie

(HTTP) Proxy


5

Probleem wordt gemeld Testfase van een nieuwe release afgerond Acceptatiefase: klant meldt probleem

Download van bestand uit systeem werkt niet



Java applicatie

(HTTP) Proxy


6

Nagaan oorzaak probleem Welke downloads gaan nog wel goed bij klant Welke verschillen TEST  ACCP

Langere download over HTTP Dynamisch aangemaakt bestand

Reverse proxy was wel een component voor ACCP en PROD omgevingen, niet in TEST HTTP headers (keepalive, nocache, request time-out) waren kritiek in deze situatie


7

Oplossing ontwikkelen HTTP headers geregeld vanuit applicatie/AS via reverse-proxy ook mogelijk

Applicatie code herschreven  HTTP headers beter stuurbaar Eisen vanuit compatibiliteit met browser, systeembelasting Database en Documenten


Java applicatie

(HTTP) Proxy


8

Werkwijzen Troubleshooting Ad Hoc problemen: iedere minuut telt, systeem ligt plat Lange termijn problemen workarounds beschikbaar problemen oplossen voor vermindering van beheerskosten robuuster maken van applicatie

Problemen voor zijn door kwaliteit


Werkwijzen Troubleshooting Bronnen van input: Gebruikers met klachten/foutbeschrijvingen-> kwaliteit, Factoren buiten de applicatie (netwerk bij betreffende partij, aangesloten applicaties) Foutmeldingen op OS, DB, AS, reverse proxy niveau.

Zelfgeschreven meldingen binnen programmatuur, of ingebouwde meldingen van Oracle, Java, libraries etc. © COPYRIGHT TRANSFER SOLUTIONS B.V.

Casus – Inlog geweigerd Applicatie kent PROD, ACCP en TEST omgeving Melding: TEST omgeving werkt niet meer, inloggen blijkt onmogelijk Applicatie zelf toont geen ongewenst gedrag in logs


Specifieke Architectuur

Database


Java WebServices

Java applicatie


12

Login pagina wordt correct getoond, echter steeds foutmelding TEST en ACCP maken gebruik van zelfde AS voor de Java WebServices Containers: onafhankelijk draaien

HTTP logs nazoeken op de AS levert op: Request1 komt bij TEST, Request2 komt bij ACCP, Request3 bij TEST Database


Java WebServices

Java applicatie


13

De Oracle OC4J 10g AS: default “load-balancen” in round-robin modus

2 applicaties, zelfde naam, verschillende container Terecht werd dus de log-in afgewezen! Geldig op TEST, ongeldig op ACCP Uitrol van de applicatie: van groot belang om de juiste naam te kiezen


14

Betrokken partijen Input voor troubleshooting kan komen van: Technisch beheer: er zijn fouten opgetreden, die in bepaalde logging of monitoring naar voren komen Gebruikers organisatie: bepaalde zaken lukken niet (meer) of er bestaat een wens tot wijziging waarvoor analyse vereist is Applicatiebeheerders hebben wensen tot onderhoudbaarheid, beheersbaarheid


Analyse van input Expertise binnen het team Terugkoppeling met gebruikers, beheerpartijen

Externe expertise op tijd inschakelen; formuleren kernproblemen Expertise op een deelgebied (specialisme) Expertise overkoepelend (integratie) Bekendheid met applicatie helpt met probleemgebieden / probleemgedrag herkennen


Casus – Data Repair ? Collega (functionele) beheerpartij belt: geen enkele gebruiker kan werken Collega (technische) beheerpartij meldt: bepaalde ochtend verwerking is niet gelukt Database logging wordt aangeleverd Klant verwacht zo spoedig mogelijk een oplossing, iedere minuut telt


Systeem was recent in beheer opgenomen

In productie voor geruime tijd Ochtendverwerking: bedoeld om data te repareren produceerde zelf ongeldige data erger nog, door dit ene ongeldige gegeven klapte de hele verwerking en miste een complete tabel inhoud!



Java applicatie

(HTTP) Proxy


18

Gevonden oplossing Systeem werkend: quick fix Uiteindelijk verwerking herschreven:

Robuust voor een enkel corrupt geval: wel loggen. Bij technische fout, die de hele verwerking stopt: e-mail naar beheer-mail adres Nog sneller op de hoogte


19

Voorbeeld stack – herhaling



Java applicatie

(HTTP) Proxy


20

Niveau’s waarop logging ontstaat Custom logging

DB / AS / proxy Logging van server

Logging van virtual host


21

Fix bepalen Zorg dat je altijd terug kan naar uitgangssituatie (voor als de Fix een ander, groter probleem introduceert) Afhankelijk van urgentie Kies de meest onderhoudbare oplossing


Uitrollen oplossingen Terugkijkend op technologie stack: Db: soms makkelijk, transactie

Java app: testtraject, niet ad-hoc Configuratie AS: afhankelijk van wijziging

Configuratie andere componenten (rechten op doc_repo, HTTP header afhandeling op reverse proxy)


Testen van de fix Uitrol op testomgeving, testers gaan aan de slag Testomgeving == productieomgeving

Anders worden sommige problemen mogelijk niet opgemerkt Maar: licentie/support kosten systemen gevoelige data mag niet gedupliceerd worden kosten/beschikbaarheid hardware bronnen (symbolic links voor doc_repo) kosten van inrichten omgevingen (reverse-proxy)


Vragen Antwoorden

CONSULTING | MANAGED SERVICES | EDUCATION

WWW.TRANSFER-SOLUTIONS.COM © COPYRIGHT TRANSFER SOLUTIONS B.V.

25

Praktijk en practices

Recommend Documents