Как проверить SLA сервиса Mac CI? Чек-лист корпоративных закупок 2026

В терминологии SRE различают три понятия: SLI — измеряемый показатель, SLO — целевой уровень, SLA — договорное обязательство, связанное с последствиями его нарушения (определения SLI, SLO и SLA). Для проверки SLA сервиса Mac CI этого различия недостаточно: не принимайте решение по одной цифре доступности хоста. Требуйте, чтобы договор описывал запуск и завершение согласованной CI-задачи, правила учёта простоя, ответственность за восстановление и проверяемые доказательства. Целевые значения определяются вашими требованиями и условиями договора — универсальные проценты или сроки здесь неприменимы.

Кому пригодится: IT- и закупочным руководителям, которым нужно сравнить условия и подписать измеримые критерии приёмки.
Владельцам платформ: чтобы отличать доступность узла от успешной сборки.
Техническим директорам: чтобы оценить ответственность за сбой и риск для релиза.

Доступность Mac CI: хост или выполненная задача

Для бизнеса показатель доступности должен отражать не только возможность подключиться к Mac. Проверяйте, способен ли исполнитель CI принять задачу, выполнить нужную сборку и передать ожидаемый результат. Если договор измеряет лишь доступность SSH, VNC или панели управления, он может считать услугу доступной даже при неработающем Runner или сломанной сборочной среде.

Зафиксируйте проверочную задачу, которая представляет реальный сценарий команды. Определите исходный код или тестовый проект, схему сборки, необходимые зависимости, ожидаемый статус и способ проверки полученного артефакта. Если для разных типов задач существуют отдельные пулы или этапы, согласуйте, какой именно контур включён в обязательство. Успешное подключение к машине не подтверждает работоспособность каждого из них.

В качестве индикатора используйте согласованную цепочку, а не один системный сигнал. Например: задача поставлена в очередь; Runner её принял; вызов Xcode завершился успешно; полученный артефакт доступен для дальнейшей проверки. Документация инструментов командной строки Xcode описывает средства, которыми можно вызывать сборочные операции. Однако наличие команды или её успешный запуск не доказывают, что вся услуга соответствует вашим требованиям: это решают состав задания и критерии приёмки.

Доступность Mac CI следует считать по онлайн-хосту или по успешной сборке? Если закупаемая услуга нужна именно для CI/CD, основным критерием должна быть возможность выполнить согласованную задачу. Онлайн-хост полезен как дополнительный показатель диагностики, но сам по себе не подтверждает готовность сборочной цепочки.

Не подменяйте пользовательский результат внутренней метрикой. В руководстве SRE о сервисных целях рекомендуют строить показатели с учётом опыта потребителя (практики определения сервисных целей). Для команды это означает, что критерий должен описывать наблюдаемое поведение задачи, а не только состояние процесса, который её обслуживает.

Границы простоя и договорная формула

Одного целевого показателя мало. В договоре должны быть названы объект измерения, окно учёта, события начала и окончания простоя, источник времени и правила обработки плановых работ. Иначе стороны могут опираться на разные расчёты, даже если используют одинаковое слово «доступность».

Согласуйте, какая неисправность запускает отсчёт: не отвечает узел, не принимает задачи Runner, не проходит контрольная сборка либо нарушена передача результата. Уточните, как учитываются частичные отказы. Если сборка не работает у одного проекта, но выполняется у другого, это может быть неисправность конкретной конфигурации, всего пула или клиентского проекта. В договоре нужно определить, кто классифицирует событие и какие данные подтверждают такое решение.

Для расчёта пригодна согласованная формула вида: доступное время за период, делённое на учитываемое время периода. Но сначала стороны должны определить, какие интервалы входят в каждую величину. Не включайте и не исключайте плановое обслуживание автоматически: порядок должен быть прямо оговорён. Не закрепляйте процент, пока не установлены методика подсчёта и связь показателя с бизнес-потребностью.

Для проверки сохраняйте журнал CI-задач, события Runner, сообщения об инцидентах и подтверждения получения артефакта. Журналы запусков помогают связать статус задачи с её фактическими этапами (документация о журналах выполнения рабочих процессов). Данные о состоянии и диагностике самоуправляемых Runner также помогают выявлять, где именно прервалась цепочка (руководство по мониторингу и диагностике Runner). Это документация о механизмах конкретной системы, а не подтверждение условий любого сервиса Mac CI.

Когда начинается отсчёт после отказа Mac-сборщика? Ответ следует записать в договоре как событие, которое можно независимо подтвердить. Например, стороны могут выбрать первое зарегистрированное нарушение контрольного задания либо согласованное уведомление о подтверждённом отказе. Важно указать, чей журнал считается источником, как сопоставляются временные метки и что происходит, если системы фиксируют разные моменты.

Реакция на инцидент и восстановление сборки

Фраза «поддержка ответит на обращение» не равна обязательству восстановить CI. Разделите процесс на отдельные состояния: обращение зарегистрировано; инцидент подтверждён; начато устранение; удалённый доступ восстановлен; контрольная сборка снова проходит; результат проверен командой. Договор может устанавливать разные правила для каждого состояния — главное, не называть их одним словом «реакция».

Укажите, кто классифицирует серьёзность инцидента, каким каналом направляется уведомление, кто принимает ответственность при передаче между командами и куда эскалировать нерешённую проблему. Требуйте описать и сценарий, при котором доступ к Mac работает, но CI-задачи остаются в очереди или падают на подготовке окружения. Для выпуска приложения такой отказ может быть важнее временной недоступности удалённого экрана.

Практики управления инцидентами рекомендуют заранее определить роли и передачу ответственности (руководство по управлению инцидентами). Материалы по подготовке к реагированию также подчёркивают важность согласованных процедур и совместной работы (руководство по подготовке к реагированию). Используйте эти принципы как основу для обсуждения процесса, но не переносите чужие сроки реакции или восстановления в свой договор.

Согласуйте, как подтверждается восстановление: повторяется контрольная задача, проверяется артефакт, а ответственная сторона фиксирует результат. Если восстановлен только доступ, а сборка ещё не проходит, нельзя закрывать инцидент как восстановленный для целей CI. Привяжите закрытие к критерию, который соответствует рабочей нагрузке команды, а не к удобству отчётности поставщика.

Обслуживание, обновления и изменения среды

Плановые работы не должны быть зоной неясности. Проверьте, какие работы считаются обслуживанием, как направляется уведомление, где публикуются записи и как период учитывается при расчёте. Если исключение сформулировано как «любые технические работы», оно может охватывать широкий перечень причин, не связанных с согласованным обслуживанием.

Отдельно разберите перезагрузку, обновление macOS, смену версии Xcode, изменение зависимостей и откат конфигурации. Для каждого случая задайте вопросы: кто согласует изменение; как проверяется влияние на задачу; кто выполняет обратный переход, если приёмка не пройдена; какие журналы сохраняются. Требование должно описывать и порядок исключения времени из расчёта, и техническую ответственность за возврат рабочего состояния.

Если обновление изменило результат контрольной сборки, запись «работы завершены» не является доказательством восстановления. Зафиксируйте версию среды и результат повторной приёмки.

Приёмка изменений особенно важна для команд, использующих фиксированные версии инструментов, приватные зависимости или собственные сценарии подписи. Для них новая среда может быть доступна для входа, но непригодна для релиза. Обсудите заранее, какие части конфигурации находятся под контролем команды, а какие меняются в рамках услуги, и кто подтверждает совместимость перед рабочим запуском.

Доказательства, компенсация и условия закупки

Соберите доказательства до подписания, а не после первого сбоя. В комплект входят проект формулировок SLA, примеры журналов состояния, схема уведомления об инцидентах, правила планового обслуживания и пример успешной приёмки реальной сборки. Для артефактов важно подтвердить не только сам факт выполнения задачи, но и способ доступа к результату: документация о сохранении и передаче артефактов рабочих процессов описывает этот механизм для соответствующего инструментария.

Компенсация за нарушение договора не заменяет резервный маршрут сборки. Уточните, как подаётся заявление, какие сведения прикладываются и кто рассматривает обращение. Не предполагайте наличие конкретной скидки, зачёта или выплаты, пока соответствующее условие не найдено в действующей редакции договора.

Параллельно зафиксируйте операционный план команды: как защитить окно выпуска; где выполнить критичную сборку при недоступности основного узла; как восстановить доступ к необходимым сертификатам и зависимостям; кто проверяет альтернативный результат. Это не попытка переложить обязательства сервиса на клиента, а защита бизнеса от риска, который денежное возмещение не устраняет.

Для оценки поставщика сопоставляйте не обещания в презентации, а документы и подтверждения. Например, при рассмотрении условий аренды Mac mini отдельно запросите договорные условия именно для нужной нагрузки: доступность удалённого доступа не следует трактовать как SLA сборочной задачи. Условия конкретной услуги должны подтверждаться её собственными документами.

Условия выбора и решение о подписании

Используйте условные развилки до согласования закупки:

• Если SLA измеряет согласованную сборочную задачу, задаёт события начала и окончания простоя и называет источник доказательств, то передавайте документ на проверку юристу и владельцу CI. Иначе верните договор на уточнение метрики.
• Если в нём разнесены подтверждение инцидента, начало работ и восстановление успешной сборки, то сопоставьте роли и каналы эскалации с внутренним регламентом. Если речь только о сроке ответа на обращение, запросите отдельное условие о восстановлении.
• Если исключения для обновлений и обслуживания ограничены, уведомляются и оставляют проверяемую запись, то проверьте их на тестовом сценарии. При расплывчатой формулировке попросите уточнить пределы и приёмку после изменения.
• Если журналов достаточно, чтобы независимо восстановить ход события и подтвердить результат, то сохраните их формат как часть пакета закупки. Если доказательства доступны только одной стороне или не связаны с задачей, считайте критерий непроверяемым.
• Если остаётся неясной ответственность за публикацию, подпись или восстановление критичного контура, то не закрывайте риск обещанием компенсации: закрепите ответственного и резервный маршрут либо отложите закупку.

Для сравнения предложений удобно вынести в одну таблицу не только значение показателя, но и методику, исключения и источник данных. Не считайте разные SLA сопоставимыми, пока не совпали определение контрольной задачи, правила простоя и процедура подтверждения результата.

Итоговый пакет перед подписью должен содержать согласованный текст SLA, контактные и эскалационные правила, описание обслуживания, образцы журналов и запись приёмочного запуска. Если подрядчик не может подтвердить заявленный критерий на тестовой задаче или не называет ответственного за восстановление CI, это основание для дополнительного условия или паузы в закупке — не повод самостоятельно додумывать обещание.

При сравнении с покупкой Mac для команды учитывайте не только стоимость оборудования: на стороне самостоятельной инфраструктуры остаются ввод в эксплуатацию, обслуживание, замена узлов и организация резервного контура. Удалённый Mac не снимает необходимости проверять договор и строить план восстановления, но позволяет рассматривать инфраструктуру по мере необходимости, без покупки отдельного хоста для каждого временного сценария. Если команде подходит именно такой формат, перед оценкой удалённого Mac для сборочной нагрузки сопоставьте ваши критерии с документами услуги и страницей SFTPMAC; обещания о доступности и восстановлении следует принимать только в той мере, в какой они прямо подтверждены договором.