Wie legen Sie Monitoring-Kennzahlen für Unternehmens-Mac-CI fest? Abnahme-Checkliste 2026

Legen Sie vor der Kennzahlenauswahl fest, welche konkrete iOS-Pipeline als Produktionsbeleg dient. Verwenden Sie einen normalen erfolgreichen Lauf und einen kontrolliert fehlgeschlagenen Lauf. Beide müssen vom eingereihten Auftrag bis zum Ergebnisprotokoll nachvollziehbar sein. Eine Dashboard-Anzeige, die nur „grün“ meldet, reicht dafür nicht.

Notieren Sie für beide Läufe Workflow-Lauf, Auftrag, Runner und Host. Verknüpfen Sie die Einträge über stabile Kennungen oder eindeutig abgelegte Verweise. Entscheidend ist nicht, ob Sie jedes Signal in einem einzigen Dashboard sehen. Entscheidend ist, ob die diensthabende Person ohne manuelle Rätselarbeit von einem Alarm zum passenden Auftrag und dessen Diagnosebelegen gelangt.

Die Zustände liegen auf verschiedenen Ebenen:

• Host: Ist der Mac erreichbar und kann er die benötigten Dienste erreichen?
• Runner: Ist der Runner registriert und für einen Auftrag verfügbar oder bereits beschäftigt?
• Auftrag: Wurde die Arbeit eingeplant, gestartet, beendet, abgebrochen oder als fehlgeschlagen markiert?
• Build: Welche Phase scheiterte, und welches Ergebnis hat Xcode protokolliert?
• Reaktion: Wurde ein zuständiges Team informiert, und lässt sich die Wiederherstellung belegen?

Verwechseln Sie diese Ebenen nicht. Ein Mac kann erreichbar sein, während der Runner gestoppt ist. Ein Runner kann online sein, ohne für die Labels eines Workflows infrage zu kommen. Ein Auftrag kann erfolgreich beendet sein, obwohl ein nachgelagerter Freigabeschritt noch fehlt. Monitoring muss deshalb seinen Geltungsbereich klar benennen: Es belegt den beobachteten Zustand, nicht automatisch die vollständige Veröffentlichungsfreigabe.

Der Runner-Status beantwortet, ob GitHub den Runner als online oder offline führt. Das zusätzliche Merkmal busy beschreibt, ob er gerade einen Auftrag ausführt. Die GitHub-Dokumentation zur Überwachung und Fehlerbehebung behandelt Runner-Status und Diagnose getrennt. Ihre Abnahme sollte das ebenfalls tun.

Prüfen Sie den Runner nicht nur in der Oberfläche. Vergleichen Sie die angezeigten Angaben mit den verfügbaren API-Feldern für selbst gehostete Runner. Halten Sie fest, welche Werte Sie erfassen und wie häufig Ihr Monitoring sie abruft. Ein abgerufener API-Zustand ist eine Momentaufnahme. Er sagt nicht, ob ein Workflow später korrekt geroutet wird oder ein Auftrag erfolgreich endet.

Kontrollieren Sie beim Routing die Labels, die der Workflow verlangt, und die Labels, die dem Runner zugewiesen sind. Prüfen Sie außerdem, ob der Runner für den richtigen Geltungsbereich registriert ist und die Workflow-Bedingungen den Auftrag tatsächlich starten lassen. Nutzen Sie die API für Workflow-Läufe und die API für Workflow-Aufträge, um Lauf- und Auftragszustände separat zu betrachten. So sehen Sie, ob ein Auftrag bereits angelegt, noch wartend oder einem ausführenden Runner zugeordnet ist.

Ein Status ist nur dann ein brauchbares Signal, wenn klar ist, welche Ebene er beschreibt. Benennen Sie in Dashboard und Alarmtext ausdrücklich Host, Runner, Auftrag oder Build; verwenden Sie „gesund“ nicht als Sammelbegriff für alle vier Zustände.

Für die Build-Überwachung reichen aggregierte Erfolgs- und Fehlerquoten nicht aus. Erfassen Sie den Status jedes Laufs, seine Start- und Endzeit sowie die betroffenen Aufträge. Ergänzen Sie die Phasenprotokolle, damit sich ein Fehler einer konkreten Stelle zuordnen lässt, etwa Abhängigkeitsauflösung, Kompilierung, Test oder Signierung. Welche Phasen relevant sind, hängt von Ihrer Pipeline ab.

Die Lauf- und Auftragszustände aus dem vorherigen Abschnitt bilden zusammen mit den GitHub-Workflow-Protokollen die Diagnosekette. Erfassen Sie mindestens den Verweis auf den Lauf und den Auftrag, das Endergebnis und den verfügbaren Protokollpfad. Wo Ihre Pipeline Phasen nicht ausdrücklich als eigene Aufträge abbildet, definieren Sie eine verlässliche Markierung im Protokoll oder Build-Schritt.

Dauer und Fehlerrate als Verlaufssignale

Behandeln Sie Build-Dauer und Fehlerrate als Trends, nicht als universelle Grenzwerte. Bilden Sie eine Baseline aus Ihrer eigenen Pipeline-Historie und vergleichen Sie ähnliche Workloads. Ein Testlauf mit anderer Abhängigkeitsauflösung, ein geänderter Testumfang oder ein absichtlich abgebrochener Auftrag darf nicht unbemerkt mit einem regulären Release-Build vermischt werden.

Definieren Sie, welche Veränderung eine Untersuchung auslöst und wer sie übernimmt. Ein auffälliger Trend ist zunächst ein Hinweis, keine Ursache. Verbinden Sie deshalb Kennzahl und Laufkennung mit den Phasenprotokollen. Ohne diesen Zusammenhang kann die Person im Bereitschaftsdienst zwar erkennen, dass sich Werte verändern, aber nicht, welcher Auftrag die Abweichung ausgelöst hat.

Die Host-Überwachung sollte CPU, Arbeitsspeicher, verfügbaren Speicherplatz und Netzwerkzugriff enthalten. Ergänzen Sie den Zustand der für Builds erforderlichen Xcode-Version und weiterer Werkzeuge. Wählen Sie diese Werte nicht nach einem pauschalen Schwellenwert. Fragen Sie zunächst: Hat ein entsprechender Messwert bereits einen realen Build-Fehler erklärt, und ist der Messwert im Alarmzeitraum dem betroffenen Host zugeordnet?

Für den Arbeitsspeicher können Sie sich an der Darstellung und Begriffsverwendung des Apple-Leitfadens zur Speicheranzeige in der Aktivitätsanzeige orientieren. Legen Sie intern fest, welche Messgröße Sie übernehmen und wie lange Sie sie speichern. Eine Zahl ohne Zeitbezug und Hostkennung ist für die spätere Fehlersuche wenig aussagekräftig.

Auch ein voller Datenträger ist nicht nur eine Host-Kennzahl. Er kann Protokollablage, temporäre Build-Dateien und Ergebnisbelege betreffen. Erfassen Sie daher verfügbaren Speicherplatz zusammen mit dem Host und prüfen Sie, ob der Alarm auf betroffene Build-Artefakte verweist. Für Netzwerkzugriff sollten Sie den tatsächlich erforderlichen Pfad prüfen, etwa den Zugriff auf benötigte Quell- oder Paketdienste. Ein allgemeiner Erreichbarkeitstest beweist nicht, dass jeder Build-Endpunkt verfügbar ist.

Halten Sie fest, wann ein Wert gemessen wurde, woher er stammt und welchem Lauf er zugeordnet werden kann. Stellen Sie sicher, dass die Host-Zeit und der Zeitstempel des CI-Systems genügend Kontext für einen Abgleich liefern. Wenn Zeitangaben nicht zuverlässig vergleichbar sind, dokumentieren Sie die bekannte Abweichung und stützen Sie die Zuordnung zusätzlich auf Lauf- und Auftragskennungen. So verhindern Sie, dass zeitlich benachbarte Ereignisse fälschlich als Ursache behandelt werden.

Bei einem Xcode-Fehler müssen Sie nicht nur wissen, dass der Auftrag fehlgeschlagen ist. Sie müssen den passenden Lauf, den Auftrag, den Host, die Phasenprotokolle und das Ergebnis wiederfinden. Apple beschreibt, wie Tests ausgeführt und Ergebnisse interpretiert werden, einschließlich der Arbeit mit Xcode-Ergebnissen in der Dokumentation zu Tests und Testergebnissen. Die Referenz zu Xcode-Befehlszeilenwerkzeugen hilft bei der Prüfung des verwendeten Kommandozeilenaufrufs.

Behandeln Sie das Xcode-Ergebnispaket, häufig als xcresult bezeichnet, als eigenen Diagnosebeleg. Prüfen Sie, ob es nach einem fehlgeschlagenen Lauf erzeugt, aufbewahrt und anhand der Auftragskennung wiedergefunden wird. Ein erfolgreicher Export ist nicht dasselbe wie eine lesbare, korrekt zugeordnete Ablage. Lassen Sie deshalb eine Person, die nicht am Testaufbau beteiligt war, den Beleg über den dokumentierten Weg abrufen.

Die Runner-Diagnose ist davon getrennt zu betrachten. GitHub beschreibt Diagnoseprotokolle für Runner und Aufträge in seiner Anleitung zu Runner-Überwachung und Fehlerbehebung. Prüfen Sie, ob Ihre Aufbewahrung diese Protokolle einschließt und ob Zugriffsrechte, Speicherort und Suchweg dokumentiert sind. Legen Sie in Ihrem Datenschutz- und Aufbewahrungskonzept fest, welche Protokolldaten personenbezogene oder vertrauliche Informationen enthalten können. Begrenzen Sie Zugriffe nach Aufgabenbereich und halten Sie die für Ihr Unternehmen geltenden DSGVO-Vorgaben ein.

Der praktische Test ist einfach zu beschreiben: Suchen Sie ausgehend von einem fehlgeschlagenen Auftrag die zugehörigen Runner- und Job-Protokolle sowie das Xcode-Ergebnispaket. Gelingt das nur mit einer lokalen Sitzung oder durch Nachfrage bei der Person, die den Build gestartet hat, ist die Diagnosekette noch nicht abnahmefähig. Halten Sie auch fest, wenn ein Artefakt erwartungsgemäß nicht erzeugt wurde. Ein klar ausgewiesener fehlender Beleg ist besser als ein scheinbar vollständiger Datensatz mit falscher Zuordnung.

Ein Alarm ist erst dann geprüft, wenn seine Empfänger, sein Inhalt und die nächste Handlung getestet wurden. Wählen Sie repräsentative Fälle: Runner offline, fehlgeschlagener Auftrag, knapp werdender Speicherplatz und fehlender Build-Beleg. Sie müssen nicht jeden Fall durch einen echten Produktionsausfall erzeugen. Verwenden Sie einen kontrollierten Testlauf oder eine sichere Simulation, sofern sie denselben Erkennungs- und Benachrichtigungsweg prüft.

Gehen Sie für jeden Fall in dieser Reihenfolge vor:

1. Auslöser festlegen. Beschreiben Sie, welches konkrete Signal den Alarm erzeugen soll und welche Ebene es betrifft.
2. Testfall ausführen. Erzeugen Sie einen kontrollierten Zustand, der keine Produktionsdaten gefährdet.
3. Benachrichtigung bestätigen. Prüfen Sie, ob die zuständige Bereitschaft die Meldung erhält und ob der Alarm eindeutig ist.
4. Zuordnung nachvollziehen. Öffnen Sie den verknüpften Host, Runner, Lauf, Auftrag und die verfügbaren Diagnosebelege.
5. Runbook anwenden. Lassen Sie die zuständige Person den dokumentierten nächsten Schritt durchführen und protokollieren.
6. Wiederherstellung belegen. Bestätigen Sie, dass der Runner oder die Pipeline wieder verwendbar ist und ein Folgeauftrag nachvollziehbare Ergebnisse liefert.
7. Lücke dokumentieren. Halten Sie fehlende Felder, unzuständige Empfänger, nicht erreichbare Protokolle und unklare Rückkehrkriterien fest.

Bewerten Sie danach die Abnahme in drei Stufen. Freigabe: Die relevanten Signale sind dem richtigen Host und Auftrag zugeordnet, und die Alarmreaktion ist belegt. Freigabe mit Frist: Eine begrenzte Lücke ist dokumentiert, verantwortet und mit einem Termin sowie einem Ersatzverfahren versehen. Keine Produktionsfreigabe: Ein kritischer Fehler bleibt unzugeordnet, die zuständige Person wird nicht erreicht oder die Wiederherstellung lässt sich nicht verifizieren.

Monitoring ersetzt weder Datensicherung noch Wiederanlaufplanung. Es ersetzt auch keine Freigabeentscheidung für eine Veröffentlichung. Prüfen Sie diese Verfahren separat und verlinken Sie sie in Ihrem Runbook, statt aus einem grünen Dashboard eine umfassende Betriebssicherheit abzuleiten.

Häufige Fragen aus der Abnahme

Runner online, aber kein Auftrag

Prüfen Sie zuerst, ob der Runner tatsächlich beschäftigt ist oder nur erreichbar erscheint. Vergleichen Sie anschließend die für den Auftrag erforderlichen Labels mit den Runner-Labels, den Geltungsbereich des Runners sowie Bedingungen und Routingregeln des Workflows. Kontrollieren Sie die Warteschlange und den Workflow-Lauf. Ein Online-Status allein bestätigt weder passende Zuweisung noch erfolgreiche Ausführung.

Zustände eines Mac-Build-Hosts

Erfassen Sie getrennt die Erreichbarkeit des Hosts, CPU- und Arbeitsspeicherauslastung, verfügbaren Speicherplatz und Netzwerkzugriff. Ergänzen Sie den Zustand des Runners, Warteschlangen- und Auftragsstatus, Build-Ergebnis und relevante Xcode-Umgebung. Wählen Sie Schwellenwerte anhand eigener Verlaufsmessungen und konkreter Fehlerbilder, statt allgemeine Werte ungeprüft als Produktionsgrenze zu übernehmen.

Xcode-Fehler und Ergebnisprotokoll

Speichern Sie Workflow-Laufkennung, Auftragskennung, Runner- beziehungsweise Hostkennung und den Pfad des erzeugten Xcode-Ergebnispakets gemeinsam mit dem Build-Datensatz. Prüfen Sie dann, ob der Ergebnisbeleg nach einem Fehler tatsächlich aufbewahrt und anhand dieser Kennungen wiedergefunden wird. Ein vorhandenes Protokoll ohne Zuordnung zum Auftrag verkürzt die Fehlersuche nicht zuverlässig.

Aussagekraft eines Mac-CI-Alarms

Lösen Sie im Abnahmetest kontrolliert einen repräsentativen Alarm aus, etwa durch einen absichtlich fehlgeschlagenen Testlauf oder einen simulierten Verlust der Runner-Verbindung. Prüfen Sie, ob die richtige Person benachrichtigt wird, der Alarm Host und Auftrag nennt und die Runbook-Schritte zu einem nachvollziehbaren Wiederherstellungsbeleg führen. Dokumentieren Sie auch Alarme, die ausbleiben oder nicht zugeordnet werden können.

Wenn Sie bestehende Rechner für CI verwenden, vermeiden Sie zwar zunächst eine zusätzliche Beschaffung. Dafür müssen Sie aber Verfügbarkeit, Wartung, Aktualisierung, Zugriffssteuerung und Wiederanlauf selbst organisieren. Ein eigener Mac-Bestand bindet Kapital und verursacht Aufwand für Einrichtung und Betrieb; ungenutzte Kapazität lässt sich nicht ohne Weiteres an wechselnde Build-Last anpassen. Eine allgemeine virtuelle Maschine ist wiederum kein Ersatz, wenn Ihre Pipeline eine reale macOS- und Xcode-Umgebung benötigt.

Für einen stabilen, dauerhaft stark ausgelasteten Betrieb oder Anforderungen an physische Anschlüsse kann ein eigener Mac die sinnvollere Wahl sein. Wenn Sie dagegen einen zeitlich begrenzten Test, zusätzliche CI-Kapazität oder eine Pilotphase benötigen, kann ein gemieteter Mac die Beschaffung eines weiteren Geräts vermeiden. Vergleichen Sie beide Wege anhand derselben Abnahmekriterien: Host- und Runner-Zuordnung, Zugriffsschutz, Diagnosebelege, Wiederherstellung und tatsächlicher Betriebsaufwand. Ohne bestätigte Anbieter- und Leistungsdaten sollten Sie keinen Kostenvorteil oder Verfügbarkeitswert voraussetzen.

CALMVPS bietet den Zugang zu einem entfernten Mac als Mietmodell. Prüfen Sie vor einer Pilotphase, ob die gewünschte Laufzeit und der vorgesehene Zugriff zu Ihrem Test passen; die Preisübersicht von CALMVPS dient dazu, die verfügbaren Mietoptionen vorab zu bewerten. Wenn Sie bereits eine konkrete Pilotbereitstellung planen, können Sie außerdem die Bestellmöglichkeiten für einen CALMVPS-Mac prüfen. Starten Sie nicht mit einer Produktionsmigration. Nehmen Sie zuerst eine echte Pipeline mit den hier beschriebenen Belegen ab und entscheiden Sie anschließend, ob ein zusätzlicher Mac-Knoten Ihre Betriebsanforderungen erfüllt.