АВАРИЙНОЕ ВОССТАНОВЛЕНИЕ И ТИПОВАЯ ДИАГНОСТИКА CONTROL CENTER Продукт: Control Center Версия: [ТРЕБУЕТ УТОЧНЕНИЯ: VERSION] Тип документа: Аварийный runbook и руководство по диагностике Последнее обновление: 09.09.2026 ЧТО МЫ НАСТРОИМ Документ задает единый порядок действий при потере Web-интерфейса, отказе одного или нескольких узлов, сетевой ошибке, нарушении DNS/NTP, неуспешном обновлении, повреждении/ошибочном удалении данных и отказе Market-модуля. ГЛАВНЫЙ ПРИНЦИП ИНЦИДЕНТА Стабилизировать → сохранить evidence → определить blast radius → остановить дальнейшие mutations → выбрать поддерживаемый recovery path → восстановить → проверить Actual State/Health/Audit. Не начинайте с удаления узла, принудительного создания quorum, ручного редактирования БД или переустановки продукта. Эти действия могут уничтожить наиболее ценные данные для восстановления. ПРЕДВАРИТЕЛЬНЫЕ УСЛОВИЯ ДЛЯ ГОТОВОСТИ К АВАРИИ Требование | Значение Backup | Есть несколько recovery points; restore регулярно тестируется OOB/Console | Доступен хотя бы для критических узлов Runbooks | Документы 05, 06, 10, 11 и 19 доступны оператору Credentials | Emergency/admin access контролируется и проверен DNS/NTP | Есть способ диагностировать независимо от Control Center UI HA | Известны quorum/replication rules [ТРЕБУЕТ УТОЧНЕНИЯ] Audit/Logs | Retention достаточен для расследования Contacts | Определен владелец решения о destructive recovery КЛАССИФИКАЦИЯ ИНЦИДЕНТА Уровень | Пример S1 — Critical | management plane полностью недоступен; возможна потеря данных/quorum S2 — Major | один узел/критичная роль отказали, но управление доступно S3 — Degraded | отдельный модуль/интеграция/часть функций нарушена S4 — Minor | локальная ошибка без влияния на критические функции [ТРЕБУЕТ УТОЧНЕНИЯ: официальный severity catalog и escalation policy]. ПЕРВЫЕ ДЕЙСТВИЯ ПРИ ЛЮБОМ СЕРЬЕЗНОМ ИНЦИДЕНТЕ 1. Зафиксируйте точное время и наблюдаемые симптомы. 2. Остановите новые необязательные Changes/Jobs. 3. Не перезапускайте одновременно несколько узлов. 4. Сохраните Change ID, Job ID, Alert ID и correlation ID, если доступны. 5. Сохраните диагностический bundle/evidence с redaction, если система доступна. 6. Зафиксируйте текущее cluster membership, Health и replication. 7. Если данные могут быть повреждены, минимизируйте writes. 8. Если возможен split-brain, изолируйте конфликтующую сторону до дальнейших действий. 9. Определите последний проверенный backup/recovery point. РАЗДЕЛ 1. WEB UI НЕДОСТУПЕН Симптом: Браузер не открывает Control Center. Шаг 1. Проверка DNS С административной Linux/Unix-системы: ```bash getent hosts ``` Ожидаемый результат: FQDN разрешается в ожидаемый IP. Если DNS неверен: Исправьте DNS/кэш/запись по документу 09. Не меняйте серверную конфигурацию, пока не исключена простая DNS-причина. Шаг 2. Проверка L3 connectivity Если ICMP разрешен: ```bash ping -c 4 ``` Отсутствие ping не доказывает отказ сервиса, если ICMP фильтруется. Шаг 3. Проверка маршрута с узла/административной станции ```bash ip route get ``` Проверьте, что маршрут идет ожидаемым путем. Шаг 4. Проверка через console/OOB На Linux-узле: ```bash ip -br addr ip route timedatectl status df -h ``` Проверьте: - правильный IP; - default route; - заполнение диска; - время; - очевидные сетевые изменения. [ТРЕБУЕТ УТОЧНЕНИЯ: штатные команды проверки Control Center services/health endpoint]. Rollback: Если проблема появилась сразу после network Change — используйте staged auto-rollback либо восстановите предыдущую конфигурацию через OOB, не меняя одновременно другие параметры. РАЗДЕЛ 2. НЕВОЗМОЖЕН ВХОД Проверьте: - используется ли правильный FQDN/TLS endpoint; - не истекла ли сессия; - корректно ли время; - не менялись ли RBAC/bindings; - не выполнялся ли restore/update; - Audit предыдущих изменений доступа. Важно: После первого bootstrap пароль `admin/admin` не должен работать. Не пытайтесь «вернуть» систему к admin/admin. Если потерян последний административный доступ: Используйте только поддерживаемый first-admin/recovery flow. [ТРЕБУЕТ УТОЧНЕНИЯ: точная account recovery procedure]. Не редактируйте users/roles напрямую в БД. РАЗДЕЛ 3. ОТКАЗ ОДНОГО УЗЛА 1. Не удаляйте Offline node. 2. Проверьте, доступен ли он через OOB. 3. Проверьте питание/сеть/ОС. 4. В Control Center проверьте Health, quorum и role placement оставшихся узлов. 5. Определите, продолжают ли работать stateful replicas. 6. Если узел можно вернуть — восстановите его и дождитесь reconciliation/replication catch-up. 7. Если узел физически утрачен — используйте Replacement по документу 06. Риск: Преждевременный decommission усложняет возврат временно недоступного узла и может повлиять на quorum. Проверка после возврата: - membership ожидаемый; - Health = Healthy; - replication догнала; - нет duplicate/replaced identity; - Actual State свежий. РАЗДЕЛ 4. ПОТЕРЯ НЕСКОЛЬКИХ УЗЛОВ / QUORUM ПРЕДУПРЕЖДЕНИЕ: это потенциальный disaster recovery. 1. Остановите автоматические и ручные writes, если consistency неизвестна. 2. Определите реально surviving nodes и их последнюю согласованную state. 3. Изолируйте partitioned/старые узлы, которые могут неожиданно вернуться. 4. Не применяйте неизвестную команду «force quorum». 5. Определите поддерживаемый survivors recovery path. 6. Если надежный consistent survivor set отсутствует — выберите последний проверенный cluster-aware backup. 7. Восстановите кластер по документу 10 и официальной quorum procedure. 8. После восстановления выполните полную reconciliation внешней инфраструктуры. [ТРЕБУЕТ УТОЧНЕНИЯ: exact disaster quorum recovery]. Rollback: При двух расходящихся ветках данных безопасный rollback означает возврат к доказанному consistent recovery point, а не ручное объединение database files. РАЗДЕЛ 5. SPLIT-BRAIN ИЛИ ПОДОЗРЕНИЕ НА НЕГО Признаки: - разные стороны считают себя primary/leader; - независимо принимаются writes; - cluster membership различается; - после network partition появились conflicting records. Действия: 1. немедленно ограничьте новые writes; 2. изолируйте конфликтующие стороны; 3. сохраните evidence обеих сторон; 4. определите authoritative/consistent side согласно официальной модели; 5. используйте поддерживаемый repair/rebuild/recovery; 6. не возвращайте старую сторону в сеть до очистки/repair ее state. РАЗДЕЛ 6. ПОТЕРЯ ДОСТУПА ПОСЛЕ ИЗМЕНЕНИЯ IP/FIREWALL 1. Не выполняйте дополнительные network Changes вслепую. 2. Дождитесь staged auto-rollback, если он активирован. 3. Проверьте через OOB: ```bash ip -br addr ip route ip rule ``` 4. Сравните с pre-change snapshot/планом. 5. Проверьте DNS. 6. Верните только измененный параметр. 7. После восстановления создайте новый staged Change на основе свежего Actual State. Если firewall rule заблокировал management path, верните предыдущее rule через штатный mechanism/OOB. Не отключайте firewall полностью. РАЗДЕЛ 7. DNS FAILURE Проверьте: ```bash getent hosts getent hosts ``` Если IP-доступ есть, а имя не работает: - восстановите authoritative/recursive DNS path; - проверьте TTL/caches; - не меняйте hostname/cluster identity как обходной путь; - после восстановления проверьте Domain Services/Market dependencies. РАЗДЕЛ 8. NTP/TIME FAILURE Проверьте: ```bash timedatectl status timedatectl show -p NTPSynchronized --value ``` Если время не синхронизировано: 1. остановите sensitive identity/cluster changes; 2. восстановите NTP connectivity/configuration; 3. дождитесь нормализации времени поддерживаемым способом; 4. проверьте TLS/Kerberos/session/replication effects. Не выполняйте произвольный большой ручной скачок времени без оценки влияния на production. РАЗДЕЛ 9. ДИСК ЗАПОЛНЕН Проверка Linux: ```bash df -h lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS ``` Не удаляйте неизвестные файлы из внутренних директорий Control Center. Порядок: 1. определите, какой filesystem заполнен; 2. проверьте telemetry/log/backup retention; 3. остановите несущественные объемные Jobs; 4. расширьте storage либо используйте поддерживаемую retention cleanup; 5. проверьте database/service Health; 6. создайте backup после стабилизации. [ТРЕБУЕТ УТОЧНЕНИЯ: safe cleanup/retention commands]. РАЗДЕЛ 10. JOB FAILED / CHANGE PARTIALLY APPLIED 1. Не повторяйте Change немедленно. 2. Откройте Change → Job → evidence. 3. Проверьте Actual State. 4. Определите, какие части уже применились. 5. Выберите retry, compensation или rollback только в поддерживаемом состоянии. 6. После recovery повторно проверьте Actual/Health/Audit. Риск: Повтор без idempotency/context может применить destructive действие второй раз. РАЗДЕЛ 11. FAILED UPDATE 1. Остановите rollout. 2. Для HA не обновляйте следующие узлы. 3. Сохраните update/migration evidence. 4. Проверьте, завершена ли schema migration. 5. Используйте поддерживаемый package rollback только если он совместим со schema. 6. Иначе восстановите pre-update recovery point по документу 10. 7. Проверьте пароль admin, RBAC, modules и cluster state. Не устанавливайте старые binaries поверх новой schema без официальной совместимости. РАЗДЕЛ 12. FAILED RESTORE 1. Не переключайте production traffic на непроверенный restore. 2. Сохраните error/evidence. 3. Проверьте backup integrity и version compatibility. 4. Попробуйте предыдущий verified recovery point, если текущий поврежден. 5. Для HA убедитесь, что старые cluster members изолированы. 6. После успешного restore выполните functional verification до возврата traffic. РАЗДЕЛ 13. ОШИБОЧНО УДАЛЕН ПОЛЬЗОВАТЕЛЬ/РОЛЬ/ДАННЫЕ 1. Остановите зависимые destructive Changes. 2. Найдите Audit event. 3. Определите точное время и affected objects. 4. Используйте selective/object recovery, если поддерживается. 5. Если требуется full restore — оцените потерю всех более новых корректных Changes. 6. Сохраните backup текущего состояния перед full restore. 7. Выполните restore/reconciliation. [ТРЕБУЕТ УТОЧНЕНИЯ: object-level recovery capabilities]. РАЗДЕЛ 14. MARKET MODULE UNHEALTHY 1. Проверьте Core Health — проблема может быть общей. 2. Проверьте module compatibility/version. 3. Проверьте module-specific dependencies: сеть, storage, credentials, DNS/NTP. 4. Найдите последний module Change/Job. 5. Не удаляйте stateful module как первый troubleshooting step. 6. Если update модуля вызвал сбой — остановите rollout и используйте module rollback/restore. 7. После repair выполните функциональную проверку. РАЗДЕЛ 15. DOMAIN SERVICES FAILURE Сначала проверьте DNS и NTP. Не демотируйте/удаляйте последний DC/replica при неизвестной причине. Проверьте: - surviving replicas; - replication Health; - DNS resolution; - client authentication; - backup. При потере нескольких domain replicas используйте module-specific directory recovery, а не ручное копирование базы. РАЗДЕЛ 16. PXE INCIDENT Если клиенты неожиданно начали PXE/reimage: 1. немедленно остановите/ограничьте PXE policy; 2. не выключайте основной DHCP целиком, если проблема только в boot options; 3. проверьте target scope/profile; 4. остановите новые destructive Jobs; 5. зафиксируйте affected endpoints; 6. восстановите endpoint data только из имеющихся backup, если disk already wiped; 7. исправьте profile и повторите pilot. РАЗДЕЛ 17. SOFTWARE AUTOMATION INCIDENT Если mass rollout затронул лишние hosts: 1. остановите последующие batches; 2. сохраните target list/Job IDs; 3. определите, какие hosts реально изменены; 4. не выполняйте rollback на unaffected endpoints; 5. восстановите package/config только на affected scope; 6. выполните re-inventory. РАЗДЕЛ 18. INVENTORY STALE/WRONG Не запускайте remediation на stale/сомнительных данных. 1. остановите compliance remediation; 2. проверьте collection provider/credentials; 3. выполните pilot re-inventory; 4. устраните duplicate identity/normalization issue; 5. только после свежего Actual State возобновите remediation. РАЗДЕЛ 19. СБОР DIAGNOSTIC EVIDENCE Собирайте: - точное время; - affected nodes/resources; - Change/Job/Alert/correlation IDs; - Health/freshness; - network facts; - version/build; - recent configuration changes; - Audit; - redacted logs/support bundle; - backup recovery point ID. Не включайте в отчет реальные пароли, tokens, private keys или не относящиеся к инциденту пользовательские данные. [ТРЕБУЕТ УТОЧНЕНИЯ: exact support bundle generation command/UI]. РАЗДЕЛ 20. ПОСЛЕ ВОССТАНОВЛЕНИЯ Не закрывайте инцидент после одного зеленого индикатора. Проверьте: - Web/API access; - authentication; - RBAC; - nodes Healthy; - Desired/Actual State; - quorum/replication; - DNS/NTP; - network/firewall; - backup subsystem; - Market modules; - monitoring/Alerts; - Audit; - фактическую функцию критических сервисов. Создайте новый backup после подтвержденного стабильного recovery. ПРОВЕРКА ГОТОВНОСТИ К ИНЦИДЕНТАМ - [ ] OOB/console проверен; - [ ] emergency access проверен; - [ ] backup schedule работает; - [ ] restore-test выполнялся; - [ ] recovery point находится вне единственного узла; - [ ] HA failover test выполнен; - [ ] multi-node disaster runbook известен; - [ ] network staged rollback проверен; - [ ] diagnostic bundle умеет redaction; - [ ] Audit retention достаточен; - [ ] Domain/PXE/Automation/Inventory module runbooks доступны; - [ ] оператор знает, где остановить destructive rollout. ТИПОВЫЕ ОШИБКИ Симптом | Возможная причина | Проверка | Решение UI недоступен | DNS/network/service/storage | DNS, route, OOB, Health | устранить первичную причину; network rollback при необходимости Один node Offline | питание/сеть/ОС | OOB/cluster Health | вернуть node или Replacement, не Delete Quorum lost | несколько отказов/partition | surviving membership | изолировать sides; официальный disaster recovery После IP change потерян доступ | address/route/firewall | OOB ip/route | staged rollback/вернуть предыдущую конфигурацию Job Failed partial | действие частично применено | Actual/evidence | compensation/rollback по факту, не blind retry Update failed | migration/compatibility | update evidence | остановить rollout; rollback/restore Данные ошибочно удалены | admin mutation | Audit/recovery point | selective restore или оцененный full restore Market module failed | dependency/version/data issue | Module Health | repair/rollback без преждевременного delete РЕКОМЕНДАЦИИ ДЛЯ PRODUCTION - проводите аварийные drills до реальной аварии; - храните runbooks вне единственной системы, которую они описывают; - всегда знайте последний verified recovery point; - сохраняйте evidence до destructive recovery; - ограничивайте writes при сомнении в consistency; - не форсируйте quorum без официальной процедуры; - используйте поузловой recovery для HA; - после восстановления выполняйте reconciliation и новый backup; - обновляйте runbook после каждого реального инцидента. ИТОГ Аварийное восстановление Control Center строится на сохранении данных и evidence, остановке неконтролируемых изменений, точной классификации отказа и выборе штатного recovery path. Успешный recovery завершается только после проверки доступа, данных, Desired/Actual State, Health, quorum, Market-модулей, Audit и создания нового проверяемого recovery point. ТРЕБУЕТ УТОЧНЕНИЯ ПЕРЕД ПУБЛИКАЦИЕЙ - VERSION; - service/health diagnostic commands; - severity/escalation model; - first-admin recovery; - exact quorum disaster recovery; - supported split-brain repair; - safe storage cleanup commands; - object-level recovery; - module-specific recovery commands; - support bundle generation/redaction; - official incident export/report format; - exact RPO/RTO guarantees by supported profile.