3.2 Решение проблем и критическое мышление

3.2 Решение проблем и критическое мышление #

🎯 Почему навыки решения проблем критичны в DevOps #

DevOps-инженер — это детектив IT-мира. 80% рабочего времени уходит на поиск и решение различных проблем:

  • Приложение внезапно начало тормозить
  • CI/CD pipeline перестал работать
  • Kubernetes pod’ы не запускаются
  • Мониторинг показывает странные метрики

Хороший troubleshooter отличается не знанием всех возможных решений, а системным подходом к поиску причин.

🔍 Методология решения проблем #

1. Правило “Стоп-Подумай-Действуй” #

Пример правильного подхода:

❌ Плохо: Увидел ошибку → сразу начал исправлять

✅ Хорошо: СТОП - не паникуй, оцени ситуацию ПОДУМАЙ - какие могут быть причины ДЕЙСТВУЙ - применяй решения по приоритету

2. Фреймворк CALM #

  • Collect — собрать информацию
  • Analyze — проанализировать данные
  • List — перечислить возможные причины
  • Mitigate — применить решение

3. Принцип Occam’s Razor #

“Простейшее объяснение, как правило, верное”

Пример применения принципа Оккама:

Сервис не отвечает. Что проверить сначала?

❌ Сложно: “Наверное, проблема в Kubernetes networking” ✅ Просто: “А запущен ли сервис вообще?”

Команда для проверки: Проверяем статус подов приложения

Ага, pod’ов нет. Не надо копать глубоко - сначала разберемся, почему не запускается

🛠️ Техники Troubleshooting #

Метод “Разделяй и властвуй” #

Пример применения метода:

Проблема: “Пользователи не могут зайти на сайт”

Разбиваем на уровни:

  • DNS - резолвится ли домен?
  • Network - доходят ли пакеты до сервера?
  • Load Balancer - проксирует ли трафик?
  • Web Server - отвечает ли nginx/apache?
  • Application - работает ли код приложения?
  • Database - подключается ли к БД?

Проверяем каждый уровень отдельно

Пример диагностики сетевой проблемы #

Пошаговая диагностика:

  1. Проверяем DNS: Используем команды nslookup и dig для проверки разрешения доменного имени

  2. Проверяем доступность хоста: Используем ping и traceroute для проверки сетевой связи

  3. Проверяем конкретный порт: Проверяем доступность порта 80 с помощью telnet или netcat

  4. Проверяем что слушает порт: Используем netstat или ss для проверки слушающих портов

  5. Проверяем процессы: Проверяем статус процессов nginx и системных сервисов

  6. Проверяем логи: Анализируем логи ошибок nginx и системные логи

Логический подход к Kubernetes проблемам #

Алгоритм диагностики неработающего Pod:

  1. Проверяем статус: Получаем список pod’ов и детальное описание проблемного pod’а

  2. События кластера: Просматриваем последние события в кластере

  3. Логи контейнера: Проверяем логи текущего и предыдущего контейнера

  4. Ресурсы: Проверяем использование ресурсов pod’а и доступность ресурсов на ноде

  5. Конфигурация: Проверяем конфигурацию deployment и configmap

Типичные причины проблем:

  • Неправильный образ (ImagePullBackOff)
  • Нехватка ресурсов (Pending)
  • Неправильная конфигурация (CrashLoopBackOff)
  • Проблемы с правами (Permission denied)

🧠 Root Cause Analysis (RCA) #

Метод “5 Whys” (5 Почему) #

Пример применения метода “5 Почему”:

Проблема: Веб-сайт недоступен

  1. Почему сайт недоступен? → Веб-сервер не отвечает

  2. Почему веб-сервер не отвечает? → Закончилась память на сервере

  3. Почему закончилась память? → Приложение потребляет слишком много RAM

  4. Почему приложение потребляет много памяти? → Memory leak в коде обработки изображений

  5. Почему возникает memory leak? → Не закрываются file handles после обработки

ROOT CAUSE: Некорректная работа с файлами в коде

ACTION: Исправить код + добавить мониторинг памяти

Fishbone Diagram (Диаграмма Ишикавы) #

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

Категория People (Люди):

  • Нет опыта у команды
  • Нехватка времени на оптимизацию

Категория Environment (Окружение):

  • Старое железо
  • Плохой интернет-канал
  • Высокая нагрузка

Категория Process (Процессы):

  • Нет мониторинга производительности
  • Плохой процесс deployment

Категория Technology (Технологии):

  • Неоптимизированные запросы к базе данных
  • Отсутствие кеширования
  • Большой размер изображений

Каждая категория помогает найти потенциальные причины проблемы

Post-Mortem Template # 

# Post-Mortem: Недоступность API 15.01.2024

## Summary
15 января с 14:00 до 16:30 MSK API был недоступен для 100% пользователей

## Impact
- Затронуто: 10,000 пользователей
- Потеря выручки: ~$5,000
- Репутационный ущерб: 50+ жалоб в поддержку

## Root Cause
Memory leak в микросервисе user-service v2.1.0, приводящий к OOM kill

## Timeline
- 13:45 - Deploy user-service v2.1.0
- 14:00 - Первые ошибки 500 в API
- 14:05 - Алерт High Error Rate
- 14:10 - Началось расследование
- 14:30 - Обнаружен высокий memory usage
- 15:00 - Rollback на v2.0.5
- 15:30 - Сервис восстановлен
- 16:30 - Подтверждена полная работоспособность

## What Went Wrong
1. Не было проведено нагрузочное тестирование v2.1.0
2. Алерты на memory usage настроены неправильно  
3. Процедура rollback заняла слишком много времени

## What Went Right  
1. Проблема была быстро локализована
2. Команда отработала слаженно
3. Коммуникация с пользователями была своевременной

## Action Items
- [ ] Добавить memory profiling в CI/CD (Иван, до 20.01)
- [ ] Настроить алерты на 80% memory usage (Мария, до 18.01)  
- [ ] Автоматизировать rollback процедуру (Алексей, до 25.01)
- [ ] Провести post-mortem review с командой (до 17.01)

## Lessons Learned
- Memory testing критически важен для production деплоя
- Алерты должны срабатывать ДО возникновения проблемы
- One-click rollback экономит часы downtime

🔬 Системное мышление #

Понимание взаимосвязей # 

Системное vs Линейное мышление:

Линейное: A → B → C
"Упал сервер → приложение не работает"

Системное: A ↔ B ↔ C
           ↕   ↕   ↕  
           D ↔ E ↔ F

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

Анализ петель обратной связи #

Пример проблемы с производительностью:

Отрицательная обратная связь (самокоррекция): Высокая нагрузка → Auto Scaling → Больше серверов → Нагрузка распределилась → Стабильность

Положительная обратная связь (деградация): Медленные запросы → Накапливаются соединения → БД перегружается → Еще медленнее → Ошибки таймаута → Повторные запросы → Еще больше нагрузки → Полный отказ

Holistic подход к проблемам # 

При решении проблемы учитывайте:

Technical Layer:
├── Infrastructure (servers, network, storage)
├── Platform (OS, containers, orchestration)  
├── Application (code, dependencies, configuration)
└── Data (databases, caches, queues)

Process Layer:
├── Deployment procedures
├── Monitoring and alerting
├── Incident response
└── Change management

People Layer:
├── Team communication
├── Knowledge sharing
├── Training and skills
└── Stress and workload

⚡ Работа под давлением #

Тактики сохранения ясности мышления #

1. Incident Commander подход # 

Когда все горит:

1. Назначить Incident Commander (IC)
2. IC управляет процессом, не занимается техническими деталями
3. Делегировать задачи: "Алексей - проверь БД, Мария - логи приложения"
4. Регулярные статус-апдейты каждые 15 минут
5. Документировать все действия в реальном времени

2. Приоритизация действий # 

Матрица Impact vs Effort:

High Impact, Low Effort (DO FIRST):
- Restart сервиса
- Rollback на предыдущую версию
- Переключение на backup систему

High Impact, High Effort (PLAN):
- Рефакторинг архитектуры
- Миграция данных
- Обновление инфраструктуры

Low Impact, Low Effort (DO LATER):
- Мелкие багфиксы
- Обновление документации

Low Impact, High Effort (DON'T DO):
- Преждевременная оптимизация
- Ненужные фичи

3. Communication под стрессом # 

# Пример коммуникации в кризис

❌ Плохо:
"Что-то сломалось, разбираемся"

✅ Хорошо:
"🔴 INCIDENT: API недоступен с 14:00
📊 Impact: 100% пользователей
👨‍💻 Investigating: команда разработки
⏱️ ETA: статус-апдейт через 15 минут
🔗 Status page: status.company.com"

Updates каждые 15 минут:
"🔍 Update: Найдена причина - memory leak в user-service
🛠️ Action: Выполняем rollback на v2.0.5
⏱️ ETA: 10 минут до восстановления"

🧪 Эксперименты и гипотезы #

Научный подход к troubleshooting #

Пример: Медленная загрузка страницы

1. Формулируем гипотезу

  • Предположение: “Медленные SQL запросы из-за отсутствия индексов”

2. Планируем эксперимент

  • Что измерять: время выполнения SQL запросов
  • Как измерять: включить slow query log
  • Ожидаемый результат: запросы длительностью более 1 секунды без индексов
  • Длительность: 30 минут мониторинга

3. Проводим эксперимент

  • Включаем логирование медленных запросов
  • Собираем метрики в течение 30 минут

4. Анализируем результаты

  • Если среднее время выполнения > 1.0 секунды:
    • Гипотеза подтверждена
    • Применяем исправление: создаем индекс на поле email в таблице users
  • Если время выполнения в норме:
    • Гипотеза не подтверждена
    • Следующая гипотеза: “Проблема в N+1 запросах”

5. Измеряем эффект

  • Проверяем улучшение производительности после применения исправления

A/B тестирование для инфраструктуры # 

# Пример: Тестирование новой версии load balancer'а

# Канарейка развертывание
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: nginx-rollout
spec:
  replicas: 10
  strategy:
    canary:
      steps:
      - setWeight: 10    # 10% трафика на новую версию
      - pause: {duration: 5m}
      - setWeight: 30    # 30% если метрики хорошие
      - pause: {duration: 10m}
      - setWeight: 100   # 100% если все OK
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.21-alpine  # новая версия

📊 Метрики для измерения качества решения проблем #

MTTR (Mean Time To Recovery) # 

# Время от обнаружения до решения проблемы
incidents = [
    {"detected": "2024-01-15 14:00", "resolved": "2024-01-15 14:30"},  # 30 min
    {"detected": "2024-01-20 09:15", "resolved": "2024-01-20 10:45"},  # 90 min
    {"detected": "2024-01-25 16:20", "resolved": "2024-01-25 16:35"}   # 15 min
]

average_mttr = (30 + 90 + 15) / 3 = 45 minutes

# Цель: снизить MTTR с 45 до 20 минут

First Call Resolution Rate # 

Показатель качества troubleshooting:

FCR = (Количество проблем, решенных с первого раза) / (Общее количество проблем)

Хороший FCR > 80%
Отличный FCR > 90%

Knowledge Base Utilization # 

Метрики эффективности знаний:

1. Время поиска решения:
   - С документацией: 5 минут
   - Без документации: 30 минут

2. Повторяемость проблем:
   - Документированные: 5% повторов
   - Недокументированные: 40% повторов

3. Onboarding новых инженеров:
   - С good docs: 2 недели до продуктивности
   - Без docs: 6 недель

🎯 Практические упражнения #

Упражнение 1: Диагностика production инцидента # 

Сценарий:
Понедельник 9:00 утра. Пользователи жалуются на медленную работу сайта.
Мониторинг показывает:
- Response time вырос с 200ms до 5s
- Error rate 15% (обычно 0.1%)
- CPU usage 30% (нормально)
- Memory usage 60% (нормально)
- Database connections: 95/100 (обычно 20/100)

Задача: 
1. Составьте план диагностики (первые 3 шага)
2. Определите 3 наиболее вероятные причины
3. Опишите как проверить каждую гипотезу

Упражнение 2: Root Cause Analysis # 

Инцидент:
CI/CD pipeline перестал работать после обновления Jenkins.
Симптомы:
- Build jobs зависают на этапе "Docker build"
- Docker daemon отвечает на ping
- Manual docker build работает
- В логах Jenkins ошибка: "Cannot connect to Docker daemon"

Задача: Проведите RCA методом "5 Why"

Упражнение 3: Системное мышление # 

Ситуация:
После оптимизации базы данных производительность сайта ухудшилась.
Парадокс: запросы к БД стали быстрее, но общий response time увеличился.

Задача: Найдите системные взаимосвязи, которые могут объяснить этот парадокс

🛠️ Инструменты для troubleshooting #

Системная диагностика # 

# Комплексная диагностика Linux системы
#!/bin/bash

echo "=== System Health Check ==="

# CPU
echo "CPU Usage:"
top -bn1 | grep "Cpu(s)" | awk '{print $2}' | awk -F'%' '{print "User: " $1 "%"}'

# Memory
echo -e "\nMemory Usage:"
free -h | grep -E "Mem|Swap"

# Disk
echo -e "\nDisk Usage:"
df -h | grep -vE '^Filesystem|tmpfs|cdrom'

# Network
echo -e "\nNetwork Connections:"
ss -tuln | wc -l
echo "Active connections: $(ss -tuln | wc -l)"

# Services
echo -e "\nCritical Services:"
for service in nginx mysql postgresql redis; do
    if systemctl is-active --quiet $service; then
        echo "$service: ✅ running"
    else
        echo "$service: ❌ stopped"
    fi
done

# Load Average
echo -e "\nLoad Average:"
uptime

Application Performance Monitoring #

Стратегия мониторинга производительности приложений:

Автоматическое логирование выполнения функций:

  • Цель: отслеживание времени выполнения и ошибок в критических функциях
  • Механизм: использование декораторов или middleware для автоматического логирования

Что отслеживать:

  1. Время выполнения функции

    • Фиксировать начало и конец выполнения
    • Логировать общую длительность операции

  2. Успешное выполнение

    • Записывать в лог информацию об успешном завершении
    • Указывать имя функции и время выполнения

  3. Обработка ошибок

    • Логировать ошибки с указанием времени до сбоя
    • Сохранять детали исключения для дальнейшего анализа
    • Пробрасывать исключение дальше для корректной обработки

Пример применения:

  • Медленные запросы к базе данных
  • API вызовы к внешним сервисам
  • Ресурсоемкие вычисления
  • Критические бизнес-операции

🎯 Заключение #

Навыки решения проблем — это суперсила DevOps инженера. Ключевые принципы:

✅ Системный подход — понимайте взаимосвязи
✅ Структурированный процесс — не действуйте хаотично
✅ Документируйте решения — помогите будущему себе
✅ Используйте научный метод — гипотезы и эксперименты
✅ Учитесь на каждом инциденте — проводите post-mortem
✅ Сохраняйте спокойствие — паника мешает мышлению

Помните: Лучший troubleshooter не тот, кто знает все решения, а тот, кто умеет быстро найти причину любой проблемы.

Следующий раздел: 3.3 Управление временем и приоритетами