Что делать если весь сервер упал?

Действия при падении сервера: Incident Response

Это не просто техническая проблема

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

Фаза 1: Немедленное реагирование (первые 5 минут)

Шаг 1 — Остановить кровотечение

# Думай как инженер в боевых условиях:
import logging

class IncidentResponse:
    def immediate_actions(self):
        actions = [
            "1. Подтвердить факт падения (не паника)",
            "2. Уведомить team lead / DevOps",
            "3. Запустить мониторинг для деградации",
            "4. Начать логирование инцидента"
        ]
        return actions

# Не делай:
bad_things = [
    "Паниковать и сразу перезагружать",
    "Скрывать информацию от остальной команды",
    "Делать необдуманные изменения в production",
    "Работать в одиночку без координации"
]

Шаг 2 — Быстро собрать информацию

# Ключевые вопросы:
diagnostics = {
    "scope": [
        "Весь сервер или конкретный сервис?",
        "Какие пользователи затронуты?",
        "Как долго это продолжается?"
    ],
    "symptoms": [
        "Высокий CPU/Memory?",
        "Ошибки в логах?",
        "Network issues?",
        "Database unavailable?"
    ],
    "recent_changes": [
        "Было ли развёртывание в последнее время?",
        "Какие изменения были сделаны?",
        "Может ли это вызвать проблему?"
    ]
}

# Команды для диагностики:
diagnostic_commands = {
    "system": "top, vmstat, iostat",
    "processes": "ps aux, systemctl status",
    "network": "netstat, tcpdump",
    "logs": "journalctl, tail -f /var/log/",
    "docker": "docker ps, docker logs",
    "kubernetes": "kubectl get pods, kubectl describe node"
}

Фаза 2: Восстановление сервиса (5-30 минут)

Вариант A — Перезагрузка (если ничего не помогает)

def graceful_restart():
    """
    Перезагрузка с минимизацией потерь данных
    """
    steps = [
        "1. Остановить приём нового трафика (load balancer)",
        "2. Graceful shutdown: дать запросам 30-60 сек на завершение",
        "3. Записать состояние в лог/метрики",
        "4. Перезагрузить сервис / сервер",
        "5. Проверить, что сервис запустился корректно",
        "6. Постепенно включить трафик (canary deployment)"
    ]
    return steps

# В коде должно быть:
if __name__ == "__main__":
    import signal
    
    def handle_shutdown(signum, frame):
        print("Graceful shutdown...")
        # Закончить текущие операции
        close_database_connections()
        stop_worker_threads()
        # Записать метрики
        log_shutdown_event()
        exit(0)
    
    signal.signal(signal.SIGTERM, handle_shutdown)

Вариант B — Выявить и исправить проблему

# Типичные причины падения:
common_causes = {
    "out_of_memory": {
        "symptoms": "OOMKiller в логах",
        "fix": "Увеличить лимиты памяти или найти утечку",
        "diagnosis": "cat /var/log/kern.log | grep OOM"
    },
    "disk_full": {
        "symptoms": "Нет места на диске",
        "fix": "Очистить логи/temp файлы",
        "diagnosis": "df -h, du -sh /var/log"
    },
    "high_load": {
        "symptoms": "CPU 100%, долгие запросы",
        "fix": "Оптимизировать запросы или масштабировать",
        "diagnosis": "top, slow query logs"
    },
    "database_issues": {
        "symptoms": "Connection timeout",
        "fix": "Переподключиться, перезагрузить БД",
        "diagnosis": "psql, mysql -u root"
    },
    "recent_deployment": {
        "symptoms": "Падение после deploy",
        "fix": "Откатить предыдущую версию",
        "diagnosis": "Проверить git log, docker images"
    }
}

Фаза 3: Откат (если необходимо)

# Откат последнего развёртывания:
rollback_strategy = """
1. Определить, какую версию катить (предыдущую stable)
2. Остановить текущее приложение
3. Развернуть старую версию
4. Проверить логи и метрики
5. Уведомить команду о причине отката
"""

# Команды откат (зависит от инфраструктуры):
rollback_commands = {
    "docker": "docker pull my-app:v1.2.3 && docker run...",
    "kubernetes": "kubectl rollout undo deployment/my-app",
    "git": "git revert HEAD, make deploy"
}

Фаза 4: Мониторинг и Stabilization (30+ минут)

import time
from monitoring import check_health

def stabilize_and_monitor():
    """Убедиться, что система стабильна"""
    
    monitoring_checks = [
        ("Response time", lambda: check_response_time() < 200),
        ("Error rate", lambda: get_error_rate() < 1),
        ("Database connections", lambda: get_conn_count() < max_conns),
        ("Memory usage", lambda: get_memory_percent() < 80),
        ("CPU usage", lambda: get_cpu_percent() < 70),
    ]
    
    for check_name, check_func in monitoring_checks:
        for attempt in range(10):  # 10 минут
            if check_func():
                print(f"✓ {check_name}: OK")
                break
            else:
                print(f"✗ {check_name}: Still failing, waiting...")
                time.sleep(60)

Фаза 5: Post-mortem (после стабилизации)

class PostMortem:
    """Анализ того, что произошло"""
    
    def analyze(self):
        questions = {
            "what_happened": "Какая была root cause?",
            "why_it_happened": "Почему это не было предусмотрено?",
            "impact": "Какой был downtime? Сколько пользователей затронуто?",
            "detection_time": "Когда мы это обнаружили? Почему не раньше?",
            "response_time": "Как быстро мы отреагировали?"
        }
        
    def improvements(self):
        """Как предотвратить в будущем"""
        return [
            "Добавить лучше мониторинг",
            "Настроить alerts",
            "Улучшить graceful degradation",
            "Добавить circuit breakers",
            "Улучшить documentation",
            "Провести training по incident response"
        ]

Пример правильного ответа на интервью

Вариант 1 — систематический подход:

"Первое — это не паниковать, а быстро определить масштаб проблемы. Я бы:

1. Уведомил team lead и DevOps
2. Проверил логи и метрики, чтобы понять, что произошло
3. Проверил недавние изменения — может, это связано с последним deployment?
4. Если это из-за deploy, откатил бы предыдущую версию
5. Параллельно начал диагностику root cause
6. После восстановления провел бы post-mortem, чтобы предотвратить повторение

Ключ — это координация с командой и систематический подход, а не попытки делать всё в одиночку."

Вариант 2 — если спрашивают про техническую часть:

"Это зависит от того, что упало. Я проверил бы:

• CPU/Memory (top, vmstat)
• Disk space (df -h)
• Логи приложения (journalctl, docker logs)
• Базу данных (есть ли соединения?)
• Сетевые проблемы (netstat, ping)

Если это из-за недавнего deploy, откатил бы. Если это утечка памяти, нужно отследить, откуда. Главное — работать систематично, а не хаотично."

Выводы

1. Не паниковать — паника приводит к ошибкам
2. Коммуникация — сразу уведомить team
3. Систематическая диагностика — логи, метрики, recent changes
4. Быстро восстановить — даже если не знаешь root cause
5. Анализ и улучшения — post-mortem для предотвращения
6. Мониторинг — должна быть система, которая уведомит раньше
7. Документация — должны быть runbooks для типичных проблем