Инструкция по реагированию на инциденты

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

Инцидент можно считать устранённым, когда влияние на клиентов понятно, несвязанные изменения остановлены, фактическое состояние владельца среды выполнения согласовано с желаемым, а восстановление подтверждено через пользовательский путь. Зелёный Dashboard сам по себе не доказывает восстановление.

Первые пять минут

1. Запишите время начала, затронутый клиентский путь и недавние изменения.
2. Проверьте состояние Gateway, PostgreSQL, Redis и Relay.
3. Определите область влияния: контур управления, Ingress, одна нода, одна рабочая нагрузка или общая зависимость.
4. Остановите несвязанные изменения.
5. Если влияние на клиентов подтверждено, включите режим обслуживания или создайте сообщение об инциденте на странице статуса.

Relay недоступен

Сигнал: ноды перестали обновлять состояние, поддерживаемые туннельные пути не работают или 9443/tcp недоступен. Вероятный владелец находится на уровне службы Relay, её базы данных, идентичности или сети. Откройте страницу Relay, проверьте службу и её журналы, том идентичности, доступность базы данных, версию образа и публичный 9443/tcp; сопоставьте время сбоя со связанными Tasks и изменениями.

Исправляйте только подтверждённый слой и повторно проверяйте подключение нод. Не передавайте порт приложению и не обходите авторизацию новой публичной службой приёма соединений. Подробный порядок: Relay Pool и порты и сеть.

Нода недоступна

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

Восстановите подтверждённую зависимость и дождитесь свежего состояния ноды. Не изменяйте ресурсы на основании устаревшего инвентаря. Подробный порядок: Ноды: роли и установка и обновления и автономная работа.

Неудачный релиз

Сигнал: после выпуска внешний запрос, проверка состояния или функция приложения перестали работать. Вероятный владелец — Deployment, Tag Pages либо образ Container, а не автоматически Ingress или нода. Откройте страницу ресурса и связанную Task, проверьте журналы, историю операций, активный слот, целевой Tag или фактический дайджест образа и подтвердите ошибку через клиентский путь.

Для Deployments вернитесь к предыдущему работоспособному слоту. Для Pages переместите Tag. Для Containers, собранных из Git, повторно разверните последний одобренный дайджест. Сохраните журналы и историю операций до отката, затем снова проверьте клиентский путь. Подробный порядок: Deployments или Pages.

Сбой привязки базы данных

Сигнал: приложение не выполняет запрос через управляемую привязку. Возможный владелец находится на пути Relay, одной из двух нод, движка базы данных, службы приёма соединений целевого демона, субъекта движка или конфигурации приложения. На странице привязки проверьте желаемое и сообщённое состояния, связанную Task и журналы; затем состояние базы данных, обеих нод, Relay, службы приёма соединений и субъекта движка.

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

Завершение инцидента

Подтвердите восстановление с внешнего клиента, намеренно отключите режим обслуживания, задокументируйте первопричину и пробел обнаружения и создайте последующую работу для каждой временной меры.

Плоскость управления недоступна

Сигнал: Console или API Gateway недоступны либо не могут прочитать постоянное состояние. Вероятный владелец — процесс или Container Gateway, PostgreSQL, Redis, постоянный том, диск либо миграция. На хосте Gateway проверьте процесс или Container, состояние зависимостей, давление на диск, миграции и журналы приложения. До попытки создать заменяющий экземпляр сохраните существующие ключи шифрования и базу данных.

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

Сразу определите, доступен ли Relay. Пока Relay работает, уже применённые конфигурации nginx, Containers, базы данных и разрешённые существующие приватные потоки могут продолжать работу, а новые изменения и решения об авторизации будут ждать Gateway. Если единственный Relay расположен на отказавшем хосте Gateway, Secure Links и сеансы управляемых нод также теряют транспорт. Обычные локальные рабочие нагрузки могут продолжать работу, но сохранение потоков через Relay не гарантируется. Независимые внешние Relay уменьшают общий риск только тогда, когда ноды действительно могут до них подключиться и использовать их.

Сначала определите затронутые пути по разделу Доступность, совместимость и пределы. Перед заменой экземпляра или изменением постоянного состояния следуйте разделу Обновления, резервное копирование и восстановление.

Сбой Ingress

Сигнал: внешний клиент не проходит один из слоёв DNS, сети, TLS, nginx, Route или целевой службы. Следуйте Диагностике Ingress, начиная с первого неуспешного слоя. На странице Domain или Route проверьте состояние, связанную Task и журналы применения nginx, а внешний запрос используйте как итоговое свидетельство.

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

Операция рабочей нагрузки зависла

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

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

База данных недоступна

Сигнал: не проходит проверка движка, прямое подключение, управляемая привязка или запрос приложения. Эти симптомы относятся к разным владельцам: ноде баз данных и Container движка, хранилище, опубликованный адрес, путь Relay, целевой ноде Docker, служба приёма соединений демона, идентичность привязки либо приложение. На соответствующих страницах базы данных и привязки проверьте состояние ресурсов и Tasks, затем Container движка, образ или подключение хранилища, снимок мониторинга, путь Relay, обе ноды, службу приёма соединений и конфигурацию приложения.

Не удаляйте базу данных или субъект движка в качестве диагностического шага. Сохраните хранилище и историю операций, устраните подтверждённый слой и повторите только узкое неудачное согласование состояния.

Коммуникация и свидетельства

Ведите единую временную шкалу инцидента: время UTC, затронутые ресурсы, видимое пользователям влияние, изменения, идентификаторы Tasks и запросов, решения и результаты проверок. Публичные обновления должны описывать влияние и ход восстановления, не раскрывая топологию и сведения безопасности.

Барьер восстановления

Для восстановления требуется:

• клиентский путь работает из-за пределов управляемой сети;
• желаемое состояние Gateway совпадает с текущим состоянием владельца;
• оповещения закрываются по правильной причине;
• состояние ожидающих операций и доставок понятно;
• временная публикация или обходы удалены;
• для каждого оставшегося риска назначены владелец и срок.

Модель решений для incident lead

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

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

Таблица свидетельств для оператора

Свидетельство	Зачем нужно
Внешние DNS, TLS и ответ приложения	Подтверждает реальное влияние на клиентов
Состояние Gateway, PostgreSQL, Redis и Relay	Разделяет сбой контура управления и контура данных
Время последней связи ноды, состояние возможностей и журналы демона	Определяет владельца среды выполнения и устаревший инвентарь
Идентификаторы Task, операции и запроса	Предотвращает дублирующие или неоднозначные изменения
Последняя одобренная версия и дайджест артефакта	Даёт известную цель отката
Состояние резервных копий баз данных и томов	Определяет безопасные варианты восстановления

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