SuSEs internes Trouble Ticket System mit DB2

Das STTS-Team bei SuSE, vordere Reihe: Sebastian Wormser, Dirk Lerner, Carsten Groß, Martin Edenhofer, hintere Reihe: Dust Puppy

Hinter den Kulissen von Linux-Unternehmen kann man oft einfallsreiche Lösungen finden. Die Support-Mitarbeiter bei SuSE werden von einem DB2-basierten, selbst entwickelten System untersützt.

Für alle, die es noch nicht wissen: Trouble Ticket-Systeme haben nichts mit falsch ausgestellten oder fehlerhaften Busfahrkarten zu tun. Vielmehr sollen sie Ordnung in den Verfahrensablauf bei Support-Hotlines bringen. Je erklärungsbedürftiger ein Produkt ist, und je größer ein Unternehmen, um so komplexer wird die Situation und um so schwieriger ist sie mit Software von der Stange zu bewältigen.

Die Entwicklung der Support-Infrastruktur bei der SuSE AG ist ein gutes Beispiel für die Skalierung solcher Probleme und ihrer Lösungen. Reichte am Anfang eine ausgefeilte .procmailcrc aus, um per E-Mail eintreffende Klagen und Problemschilderungen zu verteilen, so ist man mittlerweile beim DB2-basierten “SuSE Trouble- Ticket System 3” (STTS3) angelangt.

Gekaufte Software langsam und unflexibel

Zwischenzeitlich versuchten sich die Nürnberger auch mit einer gekauften Software, die sich aber bald als zu wenig flexibel erwies. Vor allem das träge Java-Frontend nervte die Effizienz gewohnten Linuxer im Installations-Support zusehends. Bessere Systeme gab es nicht auf dem Markt und auch nicht als freie Software, deshalb fiel im Sommer `99 die Entscheidung: Wir machen es wieder selber.

Interessant ist dabei die Evolution der Technologien, die man unter das Motto stellen kann: Früher oder später landen alle bei einer relationalen Datenbank. Das erste Trouble Ticket System, dass diesen Namen jedoch noch nicht ganz verdiente, war nichts weiter als eine gut konfigurierte .procmailrc, mit deren Hilfe eingehende Mails kontrolliert an die damals noch überschaubare Zahl von Support-Mitarbeitern weiter verteilt wurde. Dann entschied sich SuSE, Support Center an mehreren Standorten aufzubauen, und es war immer schwerer zu garantieren, dass jede eingehende Anfrage nur von einem einzigen Mitarbeiter, und möglichst auch noch dem geeignetsten, bearbeitet und trotzdem keine vergessen wurde. Dann entstand der Gedanke, das althergebrachte NNTP-Protokoll und INN-Newsserver für diesen Zweck zu benutzen.

Das STTS-Team bei SuSE, vordere Reihe: Sebastian Wormser, Dirk Lerner, Carsten Groß, Martin Edenhofer, hintere Reihe: Dust Puppy

News-Server zweckentfremdet

Somit läuft derzeit ein verteiltes System von je einem News-Server pro Support-Standort, also in Nürnberg, Bremen, und Oakland/Kalifornien. Eine wichtige Bedingung dabei war der Einbau eines Locking-Mechanismus von News-Artikeln, in dem Fall also Anfragen und Antworten darauf. Es muss ja sichergestellt werden, dass eine Anfrage nur jeweils von einem Mitarbeiter beantwortet wird, eine Philosophie, die den klassischen Usenet-News widerspricht. Deshalb haben sich die SuSE-Mitarbeiter etwas Besonderes einfallen lassen: Es gibt im STTS2, so hat man das System getauft, für normale Nutzer unsichtbare News-Artikel, die Steuerinformationen enthalten und für solche Dinge sorgen.

Die Schnittstelle des Systems zum Support-Mitarbeiter ist, wie könnte es anders sein, Web-basiert (mod_perl und Apache). Viele Mitarbeiter sind jedoch mit ihrem Lieblings-Mailprogramm weit schneller, deshalb erlaubt das STTS das “One-Click-Mailing” (SuSE, bitte nicht patentieren lassen!), die Anfrage landet dann in der Mailbox des Bearbeiters.

Schwierig ist es nur, die News-Server ständig in Schuss zu halten. Sie wollen, wie Carsten Groß vom STTS-Team sagte, “gehätschelt und gepflegt werden” und ächzen derzeit weltweit unter 40 000 bis 50 000 Nutzeranfragen pro Quartal. Dazu gesellte sich ein Organisationsproblem: Die bisher geschilderten Verfahren betrafen nur den kostenlosen Installationssupport, im kostenpflichtigen Business-Support arbeitete man nach wie vor noch mit dem kommerziellen Java-Oracle-System. Da SuSE seine Support-Modelle auch gelegentlich mal umstellt, es viele verschiedene Verträge gibt und Business-Kunden ebenfalls gehätschelt und gepflegt sein wollen, sah man dort, bildlich gesprochen, vor lauter Datenbanken die Daten nicht mehr.

Das Command Center von DB2 mit den Tabellen des Trouble Ticket-Systems

Datenbanken machen das Support-Leben leichter

Und hier kommt nun endlich DB2 ins Spiel. Auf einer Floßfahrt kamen Dirk Lerner, Datenbankspezialist und bis dahin vor allem mit Oracle sozialisiert, und Carsten Groß miteinander ins Gespräch. Die anstehenden Aufgaben lagen auf der Hand: Ein einheitliches, sauber strukturiertes Support-System sollte entstehen, mit einem klar definierten Datenmodell und einer performanten Datenbank “ganz unten” und einem ergonomischen, von den Mitarbeitern akzeptierten Interface “ganz oben”. Dazwischen die üblichen Verdächtigen: mod_perl und Apache.

Warum aber nun DB2? Freie Datenbanken schieden zum Zeitpunkt der Planung noch aus. Postgres ließ noch einige Enterprise-Features vermissen und MySQL ist für komplexe Datenmodelle ohnehin nicht geeignet. Oracle stellte sich als zu kostspielig heraus, und auf ADABAS verzichtete man aufgrund des schlechten Perl-Moduls. Sicher werden die besonderen Beziehungen, die Big Blue mit den “grünen Jungs” aus Nürnberg verbinden, bei der Entscheidung für DB2 auch eine Rolle gespielt haben.

DB2 ist laut Dirk Lerner hinsichtlich der Performance etwa mit Oracle zu vergleichen, bringt aber einen besseren Optimizer für Datenbankabfragen mit. “Wir stellen immer wieder fest, dass sich Oracle und DB2 annähnern”, so Lerner. Bei der Implementierung “modischer” Features hält sich IBM gegenüber dem Konkurrenten eher zurück. So ist beispielsweise in Oracle eine eigene Java-Maschine integriert, DB2 hingegen ist noch auf eine JDBC-Schnittstelle zu Java angewiesen. Letztendlich bleibt DB2 so ein gut Teil schlanker. Für das Trouble Ticket System bei SuSE zählen ohnehin andere Tugenden. Die Datenbank wurde dort rein auf Performance optimiert. Deshalb kommen beispielsweise Table Spaces für Daten und Indizes zum Tragen. Das heißt, oft benötigte Tabellen und Indizes erhalten einen eigenen Speicherbereich zugewiesen.

Für Dirk Lerner ist es “zwar einfach, eine Standard-Datenbank zu erstellen, bei Performance-Optimierungen geht es aber dann doch ans Eingemachte.” Konsequenterweise läuft die Datenbank deshalb auch auf Raw Devices und nicht im Linux-Filesystem. Störend sind dabei nur die “normalen” Linux-Systemadministratoren, denen laut Dirk Lerner die Überlegenheit eines RAID1 gegenüber einem RAID5 unter Datenbank-Gesichtspunkten immer wieder schwer zu vermitteln seien.

Auf jeden Fall wird das System, auf Datenbankebene ein kompliziertes Geflecht aus 50 “Entities” (siehe Artikel “Datenbastelstunde”), bereits im Business-Support eingesetzt;, auch im Installations-Support werden die News-Server sicher bald überflüssig.

Es bleibt zu hoffen, dass die SuSE AG sich einen Ruck gibt und das Trouble Ticket System, dann vielleicht auf Basis einer Open-Source-Datenbank wie Postgres, der freien Softwaregemeinde zur Verfügung stellt.

Derartige Support-Systeme werden schließlich immer wichtiger, auch wenn die Anforderungen jedes Mal verschieden sind. Ein quelloffenes, anpassbares System käme da also gerade recht. SuSE-Linux ist nicht das einzige erklärungsbedürftige Produkt auf diesem Planeten. (uwo)