Die fachlichen Inhalte liegen als Dateien unter content/ und werden beim Start eingelesen, geprueft und in den Speicher geladen. - Inhaltslader mit Zod-Schemata und Querverweispruefung - Fehlermeldungen nennen Datei und Zeile, gesammelt statt beim ersten Fehler geworfen; die Anwendung startet bei Fehlern nicht - npm run inhalte:pruefen prueft ohne Start - Handout-Ansicht mit festem Aufbau, Uebersicht nach Themenbloecken - Volltextsuche mit Gewichtung und Trefferausschnitt - Gelesen-Markierung je Handout - Glossar mit Suche und automatischer Verlinkung in den Handouts - Beispielinhalte: 4 Wochen, 12 Handouts, 24 Merkkarten, 4 Aufgaben, 4 Checklisten, 2 Lernzielkontrollen, 24 Glossareintraege - rahmenplan.yaml aus FIAusbV 2020 und KMK-Rahmenlehrplan, mit Fundstellen - gray-matter entfernt, YAML-Kopf wird selbst herausgeloest - npm run screenshots nimmt die Bilder fuer die Anleitung auf - 39 neue Tests, insgesamt 68 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2.7 KiB
2.7 KiB
id, titel, block, woche, worum, rahmenplan, lernfeld, merksatz, karten
| id | titel | block | woche | worum | rahmenplan | lernfeld | merksatz | karten | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| A1 | Ein Ticket schreiben, das keine Rückfrage auslöst | arbeitsalltag | 1 | Ein gutes Ticket beantwortet vorab die drei Fragen, die sonst als Rückfrage zurückkommen. |
|
LF6 | Wer, was, seit wann – und was schon versucht wurde. Alles andere ist Beiwerk. |
|
Das Wesentliche
- Ein Ticket pro Problem. Zwei Störungen in einem Ticket führen dazu, dass eine davon beim Schließen untergeht.
- Betreff wie eine Schlagzeile: Gerät oder Dienst, Fehlerbild, Zeitpunkt. Der Betreff muss für sich allein verständlich sein – in der Übersicht sieht man nichts anderes.
- Fehlermeldungen im Wortlaut, abgetippt oder als Bildschirmfoto, nicht sinngemäß. „Irgendwas mit Netzwerk" kostet später eine halbe Stunde.
- Was schon versucht wurde, gehört hinein. Sonst macht es der Nächste noch einmal.
- Erreichbarkeit und Dringlichkeit notieren: Wann ist die Person am Platz? Blockiert die Störung die Arbeit oder ist sie lästig?
- Beim Schließen schreibst du auf, was die Ursache war und was du getan hast – nicht „erledigt". Das Ticket ist die Dokumentation, und zwar die einzige.
Übersicht
| Feld | Schlecht | Gut |
|---|---|---|
| Betreff | Drucker geht nicht | Kyocera Flur 2 – Aufträge bleiben in Warteschlange, seit 08:00 |
| Beschreibung | Fehler beim Drucken | Meldung „Der Spooler-Dienst wird nicht ausgeführt", betrifft alle Nutzer in Halle 2 |
| Bereits versucht | (leer) | Neustart des Clients, Drucker aus- und eingeschaltet |
| Abschluss | erledigt | Warteschlange geleert, Spooler-Dienst neu gestartet; Ursache war ein hängender Auftrag von PC-042 |
Prüfungsfrage
Frage: Nennen Sie drei Angaben, die eine Störungsmeldung enthalten muss, damit sie ohne Rückfrage bearbeitet werden kann, und begründen Sie jeweils kurz.
Antwort: (1) Betroffenes System oder Gerät – sonst ist unklar, wo gesucht werden muss. (2) Beobachtetes Verhalten samt Fehlermeldung im Wortlaut – erlaubt die Eingrenzung ohne Rückfrage. (3) Zeitpunkt des ersten Auftretens – erlaubt den Abgleich mit Änderungen und Protokolldateien. Zusätzlich sinnvoll: bereits durchgeführte Maßnahmen und die Erreichbarkeit des Melders.