Wie prüfen Sie das SLA eines Mac-CI-Dienstes? Einkaufscheckliste für Unternehmen 2026

Der Mac ist per SSH erreichbar, aber der Build-Runner nimmt keine Aufträge an oder liefert kein verwendbares Artefakt.

Schnellste Lösung: Bewerten Sie ein Mac-CI-Service-SLA nicht allein nach einer Host-Verfügbarkeitszahl. Nehmen Sie eine vereinbarte CI-Aufgabe als Prüfgegenstand und regeln Sie Messfenster, Ausfallbeginn, Ausnahmen, Reaktion, Wiederherstellung und Nachweise im Vertrag. Zielwerte legt das Unternehmen gemeinsam mit dem Dienstleister passend zu den Geschäftsanforderungen fest; allgemeingültige Zahlen gibt es dafür nicht.

Dieser Leitfaden richtet sich an IT- und Einkaufsverantwortliche, die Dienstzusagen vergleichbar und unterschriftsreif machen müssen.
Plattformverantwortliche erfahren, weshalb ein erreichbarer Mac noch keinen erfolgreichen Build belegt.
Technische Leitungen können prüfen, ob Wiederherstellungspflichten und Veröffentlichungsrisiken klar verteilt sind.

CI-Aufgabenerfolg statt erreichbarem Mac

Für die Verfügbarkeit zählt nicht nur, ob sich eine Verbindung zum Mac herstellen lässt. Maßgeblich ist, ob der vereinbarte CI-Ablauf gestartet wird, die relevanten Schritte durchläuft und ein nutzbares Ergebnis bereitstellt. Ein erreichbarer Host kann gleichzeitig einen nicht verfügbaren Runner, eine fehlerhafte Xcode-Umgebung oder einen blockierten Artefakt-Upload haben.

Die Messung sollte eine repräsentative, vorher festgelegte Aufgabe abbilden. Das kann beispielsweise ein kontrollierter Build mit klar definiertem Repository, Schema, Abhängigkeiten und Artefaktziel sein. Entscheidend ist, dass alle Vertragsparteien wissen, welche Schritte zum Erfolg gehören und welche Voraussetzungen außerhalb des Dienstes liegen.

Die Begriffe sollten im Vertrag auseinandergehalten werden. Ein SLI ist die gemessene Kennzahl, ein SLO das vereinbarte interne Ziel und ein SLA die formelle Vereinbarung mit Folgen bei Nichterfüllung. Die SRE-Definitionen zu SLI, SLO und SLA helfen, diese Ebenen nicht zu vermischen. Ein Zielwert ohne Messregel ist noch keine prüfbare Zusage.

Für einen iOS-Build muss außerdem beschrieben sein, woran „erfolgreich“ erkennbar ist. Ein Prozess kann den Build-Schritt abschließen, während Signierung, Export oder Übergabe des Artefakts fehlschlägt. Die Xcode-Befehlszeilenreferenz dokumentiert die verfügbaren Werkzeuge; sie definiert jedoch nicht, welche Schritte der konkrete Dienstleister vertraglich schuldet.

Vor der Abnahme sollte das Team daher eine Aufgabe festlegen, die sich wiederholbar ausführen und eindeutig auswerten lässt. Benennen Sie auch Fehler, die nicht als Dienststörung gelten sollen, etwa ein fehlerhafter Commit oder ein nicht erreichbarer externer Dienst, sofern diese Abgrenzung tatsächlich vereinbart ist. Sonst bleibt im Störungsfall offen, ob ein fehlgeschlagener Lauf auf die Infrastruktur oder auf die Anwendung zurückgeht.

Ein beispielhafter Prüfaufruf kann den Build-Vorgang sichtbar machen:

xcodebuild -scheme App -destination 'generic/platform=iOS' build

Das folgende Schema ist ein Protokollierungsvorschlag, keine Zusage über einen konkreten Dienst:

Auftrag: kontrollierter Build
Runner: registriert
Build: erfolgreich
Artefakt: vorhanden und abrufbar
Fehlerursache: keine
Zeitstempelquelle: vereinbart

Die Dokumentation zu Workflow-Protokollen zeigt, wie Job-Ausgaben zur Fehlerzuordnung herangezogen werden können. Für die Abnahme sollte das Team zusätzlich die Definition des erwarteten Artefakts festhalten: Name, Ablageort, Zugriffsberechtigung und erfolgreicher Abruf. Ohne diese Kriterien kann ein grüner Build-Status mehr versprechen, als tatsächlich ausgeliefert wurde.

Achtung: Ein Health-Endpunkt, eine SSH-Verbindung oder ein geöffnetes VNC-Fenster belegt nur einen Teil des Dienstes. Wird daraus im Vertrag „verfügbar“ abgeleitet, bleiben Runner, Build und Artefaktübergabe möglicherweise ungeprüft.

Verfügbarkeit mit Nenner und Störungsgrenze definieren

Eine Verfügbarkeitsangabe ist erst vergleichbar, wenn feststeht, was gezählt wird. Im Vertrag sollten Messobjekt, Beobachtungszeitraum, Auswertung und Beginn sowie Ende eines Ausfalls beschrieben sein. Sonst kann eine Prozentangabe auf Host-Pings beruhen, während das Entwicklerteam tatsächlich Build-Aufträge bewertet.

Für die Berechnung muss der Nenner eindeutig sein. Werden vereinbarte Zeitfenster betrachtet, einzelne Build-Aufträge oder Zeitabschnitte, in denen ein Prüfjob hätte laufen sollen? Legen Sie außerdem fest, wie fehlende Messdaten behandelt werden. Wenn der Monitor ausfällt, ist das nicht automatisch ein Nachweis, dass der Dienst verfügbar war. Ebenso wenig beweist ein fehlgeschlagener Lauf automatisch eine Störung des Mac-Dienstes.

Die Dienstdefinition kann an der tatsächlichen Nutzererfahrung ausgerichtet werden. Die SRE-Empfehlungen zu serviceorientierten Zielen erläutern, weshalb ein Serviceziel an dem gemessen werden sollte, was Nutzerinnen und Nutzer als Funktion wahrnehmen. Auf einen Mac-Build übertragen heißt das: Die Messung muss die vertraglich vereinbarte Build-Aufgabe abbilden, nicht bloß einen technischen Teilzustand.

Legen Sie die Beweismittel fest, bevor ein Vorfall eintritt. Dazu können Runner-Protokolle, Build-Ausgaben, Dienststatusmeldungen und Zeitstempel aus einer gemeinsam anerkannten Quelle gehören. Vereinbaren Sie, wer Protokolle exportiert, welche Informationen aus Datenschutz- und Sicherheitsgründen geschwärzt werden dürfen und wie widersprüchliche Zeitangaben geprüft werden. So lässt sich der Ausfall später rekonstruieren, ohne vertrauliche Quelltexte unnötig offenzulegen.

Für Beschaffung und Betrieb sind insbesondere diese Fragen relevant:

• Welche Aufgabe oder Komponente wird als Messobjekt verwendet?
• Welches Zeitfenster fließt in die Auswertung ein?
• Ab welchem beobachtbaren Ereignis beginnt der Ausfall?
• Welche Messquelle gilt im Streitfall als maßgeblich?
• Wie werden fehlende, verspätete oder widersprüchliche Daten behandelt?
• Wann gilt die Funktion wieder als hergestellt: bei erreichbarem Host, angenommenem Auftrag oder erfolgreichem Build?

Bei einer Mac-Build-Server-Beschaffung reicht es deshalb nicht, ein SLA mit einer isolierten Zahl einzuholen. Das Angebot muss erklären, ob die Zahl den Rechnerzustand oder die nutzbare CI-Funktion betrifft. Für einen Vergleich verschiedener Anbieter sollten alle Angebote dieselbe Aufgabenbeschreibung und dieselben Ausschlüsse verwenden.

Reaktion und Wiederherstellung getrennt vereinbaren

Ein schneller Eingang einer Meldung ist nicht dasselbe wie ein behobener Vorfall. Vertrag und Betriebshandbuch sollten unterscheiden, wann die Meldung bestätigt, wann die Untersuchung begonnen, wann der Fernzugriff wiederhergestellt und wann die Build-Fähigkeit nachgewiesen wurde. Falls eine Veröffentlichung betroffen ist, kann zusätzlich eine gemeinsame Prüfung des Übergabe-Artefakts erforderlich sein.

Diese Zustände benötigen jeweils ein überprüfbares Ereignis. „Bestätigung“ kann beispielsweise eine dokumentierte Annahme des Vorfalls sein. „Wiederhergestellt“ sollte dagegen an einer vereinbarten Funktion hängen, etwa daran, dass ein kontrollierter Auftrag wieder angenommen und abgeschlossen wird. Die Formulierungen sind Beispiele für eine Vertragsdefinition, keine Aussage über bestehende Leistungen eines bestimmten Anbieters.

Auch die Ereignisklassifizierung braucht klare Kriterien. Wenn eine unterbrochene Produktionsfreigabe anders behandelt werden soll als eine vorübergehende Störung eines Testjobs, müssen Auswirkung und Priorität im Voraus beschrieben sein. Regeln Sie außerdem den Benachrichtigungskanal, die zuständige Kontaktrolle, die Übergabe bei Schicht- oder Zuständigkeitswechseln sowie den Eskalationsweg, wenn die erste Reaktion keine Diagnose ergibt.

Die SRE-Leitlinien zur Ereignisverwaltung beschreiben, weshalb Rollen und Übergaben Teil der Vorfallsteuerung sind. Die Anleitung zur Vorbereitung einer Ereignisreaktion behandelt zudem die erforderliche Koordination. Für die Beschaffung folgt daraus: Fragen Sie nicht nur nach einer Reaktionszusage, sondern auch nach Zuständigkeit, Statusmeldungen und dem Verfahren bis zum bestätigten Ende des Vorfalls.

Halten Sie im Vertrag die Grenzen zwischen Dienstleister und Kundenteam fest. Wer prüft Zugangsdaten? Wer entscheidet, ob eine Umgehungslösung eingesetzt wird? Wer bestätigt, dass die Wiederherstellung für die betroffene Pipeline ausreicht? Ohne benannte Verantwortliche kann eine technische Verbesserung vorliegen, während der Release-Prozess weiterhin blockiert bleibt.

Die Überwachung selbst sollte ebenfalls eingeordnet werden. Hinweise zur Überwachung und Fehlerdiagnose selbstverwalteter Runner machen deutlich, dass Registrierung, Erreichbarkeit und tatsächliche Ausführung unterschiedliche Diagnosepunkte sind. Daraus lässt sich keine Zusage eines Mac-CI-Dienstes ableiten. Es ist vielmehr ein Grund, im Abnahmeverfahren genau zu benennen, welche dieser Zustände der Dienstleister beobachten und melden muss.

Wartung, Neustart und Umgebungsänderung abgrenzen

Geplante Wartung und reguläre Fehler sind nicht automatisch gleich zu behandeln. Der Vertrag muss jedoch angeben, welche Wartungsarbeiten aus der Verfügbarkeitsmessung herausfallen, wie sie angekündigt werden und ob betroffene CI-Aufgaben währenddessen eingeschränkt sind. Eine pauschale Ausnahme für „Wartung“ lässt offen, ob auch kurzfristige Neustarts oder Änderungen an der Build-Umgebung darunterfallen.

Prüfen Sie die Regeln für macOS-Aktualisierungen, Neustarts, Xcode-Wechsel, Änderungen an Runner-Konfigurationen und Rücksetzungen. Für jede Ausnahme sollte feststehen, welcher Umfang gilt, wer die Änderung freigibt und wie sie protokolliert wird. Wird die Umgebung geändert, braucht das Team außerdem einen Abnahmepunkt: Ein kontrollierter Build muss nach der Änderung wieder die vereinbarten Kriterien erfüllen.

Die Ausnahme sollte nicht dazu führen, dass die Verantwortung für den Rückweg verschwimmt. Wenn ein Update einen Build beeinträchtigt, muss feststehen, wer die Änderung untersucht, wer über einen Rollback entscheidet und wer nach dem Eingriff die Funktion bestätigt. Vereinbaren Sie außerdem, wie ein notwendiger Notfallneustart dokumentiert wird und wie das Team über Auswirkungen auf laufende Aufträge informiert wird.

Die Vertragsprüfung sollte Wartungsregeln nicht mit der eigenen Release-Planung verwechseln. Selbst wenn eine Maßnahme formal aus der Verfügbarkeitsberechnung ausgenommen ist, kann sie eine wichtige Freigabe unterbrechen. Das Plattformteam sollte daher Wartungsfenster mit internen Veröffentlichungsfristen abgleichen und für kritische Builds einen Ausweichweg dokumentieren. Der Dienstvertrag allein ersetzt diese Betriebsentscheidung nicht.

Bei Remote-Mac-Dienstverfügbarkeit ist auch zu prüfen, ob Änderungen an der Entwicklungsumgebung angekündigt und nachvollziehbar sind. Eine Umgebung kann aus Sicht des Host-Betriebs verfügbar sein, während ein geändertes Werkzeug oder eine fehlende Abhängigkeit die vereinbarte Aufgabe verhindert. Definieren Sie deshalb, welche Änderungen als normale Pflege gelten und welche eine erneute Build-Abnahme erfordern.

Entschädigung, Ausweichweg und Betriebsrisiko auseinanderhalten

Eine Gutschrift oder andere vertragliche Abhilfe kann einen Verstoß gegen die Vereinbarung adressieren. Sie stellt aber nicht automatisch eine blockierte Veröffentlichung wieder her. Prüfen Sie, ob die Abhilfe an eine klar definierte Messung gebunden ist, wie sie beantragt wird, welche Unterlagen benötigt werden und wer die Entscheidung darüber trifft. Gibt es keine explizite Klausel, sollte das nicht als stillschweigende Zusage interpretiert werden.

Das Unternehmen benötigt unabhängig davon einen Betriebsplan. Legen Sie fest, welche Builds auf einen zweiten Pfad verschoben werden können, welche Signaturmaterialien dafür verfügbar sein müssen und wie verhindert wird, dass ein Ausweichlauf mit veralteten Abhängigkeiten oder einer abweichenden Umgebung ein falsches Ergebnis liefert. Bei einer Veröffentlichung ist zudem zu klären, wer den Ersatzlauf freigibt und wie sein Artefakt mit dem ursprünglichen Auftrag abgeglichen wird.

Diese Fragen sind besonders wichtig, wenn ein Team von einem einzigen Mac-Build-Pfad abhängt. Ein Vertragsanspruch kann nachträglich eine wirtschaftliche Abhilfe schaffen; er senkt für sich genommen nicht die operative Abhängigkeit. Die Wiederherstellungsübung muss daher auch interne Zugänge, Zuständigkeiten, Signierprozesse und die Prüfung des gelieferten Ergebnisses einbeziehen.

Die Entscheidung über den Ausweichweg hängt vom Einsatz ab. Ein zweiter Mac kann für kritische Veröffentlichungsaufgaben sinnvoll sein, während ein weniger dringlicher Prüfjob zunächst warten kann. Es gibt dafür keinen universellen Aufbau, der unabhängig von Release-Rhythmus und Sicherheitsvorgaben passt. Beurteilen Sie die Folgen eines Ausfalls anhand Ihrer eigenen Abläufe, statt eine fremde SLA-Zielzahl als vermeintlichen Standard zu übernehmen.

Nachweise vor der Unterschrift zusammenführen

Eine belastbare Beschaffung endet nicht mit dem Vergleich von Vertragsüberschriften. Das Unternehmen sollte die genaue SLA-Fassung, die Messdefinition, eine Beispielauswertung, das Verfahren zur Vorfallmeldung, die Wartungsregeln und ein nachvollziehbares Build-Abnahmeprotokoll zusammentragen. Für jedes Dokument sollte feststehen, ob es verbindlicher Vertragsteil, technische Anlage oder unverbindliche Betriebshilfe ist.

Prüfen Sie vor der Freigabe, ob ein Teammitglied den Ablauf anhand der Unterlagen rekonstruieren könnte: Welcher Testauftrag gilt? Woher stammen die Zeiten? Welche Fehlersignale werden gesammelt? Wer klassifiziert einen Vorfall? Wann ist die Aufgabe wiederhergestellt? Ein Text, der diese Fragen nur mit „nach Möglichkeit“ oder „im Rahmen des Zumutbaren“ beantwortet, bietet wenig Grundlage für einen reproduzierbaren Abgleich.

Arbeitsabläufe sollten außerdem sichere Protokollierung unterstützen. Build-Logs können vertrauliche Pfade, interne Projektnamen oder andere schützenswerte Angaben enthalten. Legen Sie deshalb Zugriff, Aufbewahrung und zulässige Weitergabe fest und gleichen Sie die Verarbeitung mit den Datenschutz- und Sicherheitsanforderungen des Unternehmens ab. In der DSGVO-relevanten Prüfung zählen nicht nur Speicherort und Zugriff, sondern auch die Frage, welche Inhalte der Nachweis für den Vorfall tatsächlich benötigt.

Für die Bewertung von Artefakten ist eine klare Übergabe nötig. Die Dokumentation zur Speicherung und Weitergabe von Workflow-Artefakten erläutert einen konkreten Mechanismus für Artefakte. Sie ist kein Nachweis dafür, dass ein bestimmter Mac-CI-Dienst diese Funktion oder eine bestimmte Aufbewahrung anbietet. Im Vertrag müssen Speichermedium, Abrufbarkeit, Zugriffsrechte und Aufbewahrung daher separat geprüft werden.

Die folgende Entscheidungshilfe trennt Freigabe von Nachbesserung:

• Wenn die CI-Aufgabe samt Erfolgskriterien messbar ist und Ausfallbeginn, Ausfallende sowie Datenquelle feststehen, dann kann das Team die vereinbarten Zielwerte anhand eigener Release-Anforderungen verhandeln.
• Wenn nur ein Host-Ping oder Fernzugriff als Verfügbarkeit gilt, dann sollte die Definition um Runner-Annahme, Build-Abschluss und erforderliche Artefaktübergabe ergänzt werden.
• Wenn Reaktionsmeldung und technische Wiederherstellung nicht getrennt beschrieben sind, dann sind Statusstufen, Verantwortliche und Eskalationsweg vor der Unterschrift festzulegen.
• Wenn Wartungsausnahmen oder Update-Folgen unklar bleiben, dann sollte die Beschaffung eine präzise Abgrenzung einschließlich Benachrichtigung und Abnahme verlangen.
• Wenn Messwerte, Fehlerprotokolle oder Ansprechpartner fehlen, dann ist die Freigabe bis zur Vorlage prüfbarer Nachweise zurückzustellen.

Für einen Einkauf eines Mac-Build-Servers sollte jede offene Zeile entweder eine benannte Ergänzung im Vertrag oder eine dokumentierte Risikoentscheidung erhalten. Ist die Messung nicht reproduzierbar, bleiben Ausnahmen weit gefasst oder hat die Wiederherstellung keinen Verantwortlichen, ist eine vertagte Freigabe sachgerechter als eine Unterschrift auf Basis einer bloßen Verfügbarkeitszahl.

Vom bestehenden Aufbau zur passenden Mac-Lösung

Ein vorhandener Aufbau mit selbst betriebenem Rechner oder allgemeiner Cloud-Infrastruktur kann sinnvoll sein. Je nach Modell entstehen jedoch eigene Beschaffungs- und Wartungsaufgaben, die Verfügbarkeit der benötigten Mac-Hardware muss intern abgesichert werden, und Fernzugriff allein belegt noch keinen erfolgreichen CI-Auftrag. Prüfen Sie diese Punkte gegen Ihre tatsächlichen Personalkosten, Sicherheitsvorgaben und Release-Risiken, statt die Alternativen pauschal als günstiger oder zuverlässiger einzustufen.

Eine gemietete Remote-Mac-Umgebung kann für Teams interessant sein, die zunächst Kapazität oder einen separaten Prüfpfad benötigen, ohne sofort zusätzliche Hardware zu beschaffen. Sie eignet sich nicht automatisch für jeden Dauerbetrieb: Bei konstant hoher Last, strengen physischen Anschlussanforderungen oder nicht verhandelbaren internen Betriebsregeln kann ein eigener Rechner oder eine hybride Lösung besser passen. Für einen neutralen Kostenvergleich lassen sich die Mietpreisinformationen für Mac mini neben Beschaffungs-, Betriebs- und Ausweichkosten stellen; daraus folgt keine Aussage über ein bestimmtes SLA.

Vor der Unterschrift sollte das Einkaufsteam die Prüfpunkte dieses Leitfadens auf den konkreten Vertrag anwenden. Wenn ein Remote-Mac für die Build- und Release-Last grundsätzlich infrage kommt, kann SFTPMAC als mögliche Mietoption in die Prüfung aufgenommen werden. Maßgeblich bleiben die tatsächlich vorliegenden Vertragsbedingungen, die nachgewiesenen Abläufe und ein erfolgreicher Build-Abnahmetest; Informationen zu verfügbaren Angeboten finden Sie auf der SFTPMAC-Übersichtsseite.