Guten Tag in die Runde -
das Thema ist vielleicht für die heutige Zeit und Admins etwas altbacken, ich frage halt doch mal nach:
Mit der Übernahme meines jetzigen Arbeitsbereiches sind relative viele Aufgaben auf mich zugekommen. Dies bedingt einen schnellen Wechsel zwischen unterschiedlichen Aufgaben und Tätigkeitsbereichen sowie Standorten. Prinzipiell geht es eigentlich um die Nach- bzw. Rückverfolgbarkeit meiner Tätigkeiten speziell an Rechner- und Serversystemen, um nach einer Unterbrechung der Arbeiten diese mit Statuskenntnis der letzen Arbeiten und Systemzustandes fortsetzen zu können.
Hat jemand also eine Form von Serverlogbuch-Software o.ä. im Einsatz, in der man die üblichen Daten eintragen kann wie Datum, Uhrzeit, System usw. und wo auch detailliert der jeweilige Service-/Supporteinsatz dokumentiert werden kann? Optimal wäre natürlich eine Datenbank mit Suchfunktion damit man ein sich wiederholendes Problem identifizieren bzw. schon gefundenen Lösungen aufrufen/finden kann.
Klar kann man das auch über eine Calc-Liste oder eine Writer-Dokument führen, aber da artet die Suche nach bereits gefundenen Lösungen schnell mal in Roman-lesen aus.
Danke.
Grüße
H. Schaffrik
Bereichsleiter IT Ev. Schulverein im LK Bautzen e.V.
Hallo!
Wir nutzen zu Dokumentation sämtlicher Einstellungen am System ein intern laufendes DokuWiki mit ein paar Zusatzplugins. Funktioniert einwandfrei.
Viele Grüße
Michael
Kannst Du mir bitte sagen, auf welches Wiki ihr euch da verlasst und welche Zusatz-Plugins? Die Idee hatte ich auch schon, bin dann aber beim raussuchen einer Variante wieder abgebrochen …
Zuletzt noch als Design das Template bootstrap3 wählen und alles sieht top aus.
Jetzt müsste sich eigentlich Gerd (@gpeter) zu Wort melden und etwas zu dem Plugin „Indexmenu“ sagen! Wenn man das vor vornerein konsequent anlegt (mit Ordnern und einer Dokumentenstruktur), findet man später alles super wieder.
Aber auch das „To-Do“-Plugin verwende ich für wiederkehrende Aufgaben sehr oft. Damit kann man ganz simpel Punkte abhaken, die man bereits erledigt hat … fand ich ebenfalls extrem hilfreich.
Ein weiterer riesiger Vorteil: Es sind ja alles nur winzige Textdateien (mit Markup-Language), die man schnell hin- und herschieben und sogar komplett so wie sie sind an andere Leute weitergeben kann. Zudem hat man durch den Wiki-Ansatz ganz automatisch eine History früherer Versionen seiner Logbücher parat.
Bei uns ist das jedenfalls nicht mehr weg zu denken
Ja, DokWiki. einer der Gründe war irgendwann der Vorteil von reinen Textdateien und der damit verbundenen Sicherheit: „egal was mit DokuWiki passiert, du kommst immer wieder an deine Daten rann“
Das sich im Backup, zB .tgz weiter fortsetzt usw.
Zum IndexMenü empfehle ich in der Tat das zu beginn ausgiebig auszuprobieren und Seiten auch mal zu löschen und wo anders neu anzulegen u.a. um zu erfahren wie sich das auf die IndexMenü Struktur auswirkt …
Ich pflege (auch) hier eine etwas aufwendigere doppelte Übersicht:
die automatisch per Indexmenü erzeugte
und eine händisch erzeugte Kategorisch unterteilte Haupsteite in der unterhalb der Haupkategorien die Haptebenen alle per Hand zusätzlich alphabetisch sortiert aufgelistet sind, die mit den sechs „=“ Zeichen in der Überschrift
hat den Vorteil, dass ich neben dem Suchindex auch so und direkt alles wiederfinde und besser erinnere usw.
Diesen Satz habe ich jetzt erst gelesen:
Also für’s Protokollieren verwenden wir DokuWiki nicht. Hier stehen überwiegend unsere (statischen) Dokus drin. Und ich schreibe mir meine eigenen HowTo’s da rein für wiederholende Aufgaben (Systemupgrades, System neu Aufsetzen oder Samba ADDC) und konzentriere Suchergebnisse zu einem bestimmten Thema usw. usw…
oder zum Teil auch Abläufe die irgendwann mal von Ansible übernommen werden sollen, wenn wir das am Start haben.
Für obige zeitbasierte Protokollierung ist ein Wiki (glaube ich) nicht gut geeignet. Da halte ich in der Tat eine Tabellenkalkulation für besser geeignet, weil du hier ja auch Fristen und Warnungen (bzw. Farben) automatisieren kannst „Ohh die letzten Updates sind ja schon länger als 72 h her …“
Ich habe das mal versucht per Asset Manangemant Software abzubilden, vor allem mit dem sehr mächtigen und gut gepflegten Werkzeug GLPI. (unter anderem ein Artikel aus der IT-administrator)
Die ersten versuche mit GLPI waren faszinierend, sobald ich dann eigene Anpassungen vornehmen wollte war eigentlich sofort „Ende-Gelände“. Out-of-the-Box ging da gar nix (nicht für mich zumindest).
Es gibt weder ein wirklich hilfreiche deutschsprachige oder englischsprachige Community noch sonstige Wikis Dokus oder gar Bücher dazu. Wenn dann in französich - und (sorry Arnaud) das tue ich mir nicht an
Eine weitere aus deutschland kommende sehr gute Lösung ist i-doit.com,
Was für mich hierbei nicht gepasst hat: die freie community Lösung ist stark beschnitten bekommt kein Support und die supportete kostenpflichtige ist gleich so teuer, dass (für mich und meine Kunden: Schulen!) unbezahlbar, (auch die rabbattierten Versionen für Schulen)
@all
Dann erst mal vielen Dank für die ausführliche Information.
Das Wiki werde ich wohl so einführen und pflegen, auch wenn es meiner ersten Intention zum Thema - das führen eines Server-Logbuches und protokollieren der aktuellen Arbeiten - nicht entspricht. Als Wissensspeicher und schriftlichen Fixierung von Anleitungen für die IT scheint es mir aber gut geeignet zu sein.
GLPI und o-doit kenne ich gar nicht - ich schaue es mir mal an.
Das ist ein Desktop-Wiki. Sind alles Textdateien, die z.B. auf einem gemeinsamen Share liegen können oder besser: man legt ein git repository an. Zim kann selber commits machen. In Zim gibt es auch ein Kalender-Journal und vieles mehr.
Ein Vorteil gegenüber einer Webvariante ist, dass Scripte, die in der Doku, also auf dem PC an dem man sitzt, liegen, auch gleich dort ausgeführt werden können. Bzw. beigefügte Dateien direkt geändert werden können.
geht in eine etwas andere Richtung, erfüllt aber auf den ersten Blick die gewünschten Anforderungen: wir nutzen (auch) dafür Redmine.
Tatsächlich haben wir angefangen, es zu nutzen, weil wir mal aufschreiben wollten, was diese ganze Arbeit an Zeit frisst. Und da man dort für Aufgaben Tickets anlegt und in den Tickets dann den Zeitbedarf (voraussichtlich und tatsächlich) einträgt, war das genau richtig.
Zu jedem Projekt kann man auch ein (MarkDown-)Wiki einrichten - da haben wir alles verewigt, was mehr als einmal relevant sein könnte, Anleitungen, Codeschnipsel, Besonderheiten einzelner PCs, …
Später haben wir dieses Ticketsystem dann an den LDAP/AD angebunden und es für die gesamte Schule geöffnet. Es gibt inzwischen auch mehrere Projekte (Endgeräte/Hardware/Imageverwaltung/…), um die Tickets zu sortieren. Mir hilft es bei er Systematisierung der Image-Pflege, für die Kolleginnen und Kollegen ersetzt es die Zettelwirtschaft bei irgendwelchen Hardware-Problemen… Und das Wiki ist für mich und meine Kollegen der zentrale Wissensspeicher in Sachen Schulnetz.
Das ist natürlich mehr als ein digitaler Zettelkasten, vielleicht aber trotzdem einen Gedanken wert.
Viele Grüße
Thomas
PS: Man kann in Redmine auch eigene Felder definieren und damit (in der Einrichtung etwas umständlich, aber wenn es einmal läuft, zuverlässig) richtige Online-Forumulare erstellen. So werden bei nus inzwischen Neuzu- und Abgänge erfasst: das Sekretariat legt in einem privaten Projekt ein Ticket an, füllt die Felder entsprechend aus, darüber werden alle Beteiligten (Bibliothek, Schulnetz, …) benachrichtigt und erledigen den zugehörigen Kram. Das ersetzt die frühere Laufzettellösung, die wiederum gelbe Zettelchen ersetzt hat, die sich von Postfach zu Postfach quälten…
ein ähnliches IT-System und Vorgehen mit gleichen Funktionalitäten haben wir hier auf Basis von GitLab etabliert. Die Ultimate-Variante gibt es für den Education-Bereich kostenlos. Die Bedingung „Classroom or research use only“ kann man vielleicht weit auslegen.
Also wir nutzen als Ticketsystem Zammad. Das kann inzwischen auch ziemlich gute Zeiterfassung.
Könnte vielleicht für den Anwendungsfall auch etwas sein.
Gibts eigentlich für Ubuntu nicht etwas ala „admin diary“?
@Tw33ki
Danke für die Rückmeldung … Zamad haben wir uns auch schon bei der Suche nach einem Ticketsystem angesehen, aufgrund vorliegender Negativ-Berichte jedoch vorerst wieder verworfen. Wie sind eure Erfahrungen damit?
Meinst du, ob wir das Zammad an LDAP o.Ä. angeschlossen haben?
Wir jetzt nicht, hab das aber bei einem Kunden gemacht. Muss man halt im LDAP-Modul von Zammad die Rollen richtig vergeben, dann ist das sicher kein Problem.
Ja, das meinte ich. Das klingt ja erst mal nicht schlecht … wir führen gerade Linuxmuster ein und und ich benötige definitiv ein Ticketsystem für die Lehrer. Wäre schön, wenn das gleich mit der derselben Nutzerkennung gehen würde … sonst gibt es wieder bloß Ablehnung.
Danke für die Info.