Загрузка данных

Ниже — вариант выполнения заданий. В реальном анализе формулировки уточняются по логам, метрикам и данным мониторинга.

Часть 1. Алгоритмы анализа ошибок

Задание 1. Метод «5 Почему»

Сценарий А: «Неверное имя пользователя или пароль»

Почему пользователи не могут войти?
→ Система отклоняет учётные данные как неверные.

Почему система отклоняет учётные данные?
→ Введённый пароль не совпадает с хэшем пароля в БД/AD.

Почему пароль не совпадает?
→ Пользователи вводят старый пароль.

Почему пользователи вводят старый пароль?
→ Пароли были централизованно изменены/сброшены, но пользователи не получили уведомление.

Почему пользователи не получили уведомление?
→ Нет регламента оповещения и проверки после массового изменения политики аутентификации.

Корневая причина: отсутствие change management и уведомления пользователей при массовом изменении учётных данных.
Решение: уведомить пользователей, выдать временные пароли/инструкцию сброса, добавить обязательное оповещение и проверку на тестовой группе перед массовым изменением.

Сценарий Б: «500 Internal Server Error» при оформлении заказа

Почему возникает ошибка 500?
→ В сервисе заказов возникает необработанное исключение.

Почему возникает необработанное исключение?
→ NullReferenceException при расчёте доставки/создании заказа.

Почему возникает NullReferenceException?
→ В заказе отсутствует обязательное поле, например адрес или способ доставки.

Почему поле отсутствует?
→ API и фронтенд принимают неполные данные, валидация не срабатывает.

Почему валидация не срабатывает?
→ Требования и тесты не покрывали этот кейс; нет обязательной серверной проверки входных данных.

Корневая причина: отсутствие входной валидации и обработки ошибок при оформлении заказа.
Решение: добавить серверную и клиентскую валидацию, проверки на null, глобальный обработчик ошибок, автотесты и мониторинг.

---

Задание 2. Диаграмма Исикавы

Проблема: «За последнюю неделю время отклика системы выросло с 0.5 до 3.5 секунд».

Категория Возможные причины
Люди (People) Рост нагрузки из-за маркетинговой рассылки; ошибки при релизе; недостаточная квалификация; отсутствие дежурного
Процессы (Process) Неоптимизированные запросы; нет code review; нет нагрузочного тестирования; частые релизы без rollback
Оборудование (Equipment) Нехватка CPU/RAM; медленные диски; износ серверов; перегрузка виртуальной машины
Материалы (Materials) Рост объёма БД; большие логи; неоптимизированные изображения/файлы; тяжёлые ответы API
Среда (Environment) Рост числа пользователей; сетевые задержки; внешние API; «шумные соседи» в виртуализации
Управление (Management) Нет SLA и мониторинга; нет capacity planning; не выделен бюджет; нет регламента реагирования

Текстовый вид:

```text
Люди                    Процессы                    Оборудование
   |                       |                           |
   |-- Рост нагрузки       |-- Нет оптимизации          |-- Нехватка CPU/RAM
   |-- Ошибки релиза       |-- Нет load-тестов          |-- Медленные диски
   |-- Нет дежурного       |-- Нет code review          |-- Перегрузка ВМ
   |                       |                           |
   +-----------------------|---------------------------+
                           |
                    ПРОБЛЕМА: Время отклика
                     выросло с 0.5 до 3.5 сек
                           |
   +-----------------------|---------------------------+
   |                       |                           |
   |-- Рост БД             |-- Рост пользователей       |-- Нет SLA/мониторинга
   |-- Большие логи        |-- Сетевые задержки         |-- Нет capacity planning
   |-- Тяжёлые файлы       |-- Внешние API              |-- Нет бюджета
   |                       |                           |
Материалы               Среда                       Управление
```

---

Задание 3. Метод Pareto

Исходные данные: всего 140 инцидентов.

Тип ошибки Кол-во % от общего Накопленный %
Ошибка подключения к БД 45 32,14% 32,14%
Таймаут при загрузке страницы 30 21,43% 53,57%
Ошибка интеграции с API 20 14,29% 67,86%
NullReferenceException 12 8,57% 76,43%
Другое 10 7,14% 83,57%
Ошибка валидации данных 8 5,71% 89,29%
Ошибка сессии (истекла) 7 5,00% 94,29%
Недостаточно прав доступа 5 3,57% 97,86%
Повреждение данных 3 2,14% 100,00%
Итого 140 100% 

Какие типы ошибок составляют 80% всех инцидентов?
→ Ошибка подключения к БД, таймаут при загрузке страницы, ошибка интеграции с API, NullReferenceException, «Другое». Суммарно они дают 117 инцидентов = 83,57%.

На какие типы ошибок следует направить усилия в первую очередь?
→ В первую очередь: ошибка подключения к БД и таймаут при загрузке страницы, затем ошибка интеграции с API.

Меры для двух самых частых типов ошибок:

1. Ошибка подключения к БД: увеличить/настроить пул соединений, найти утечки соединений, оптимизировать запросы, настроить retry/circuit breaker, мониторить БД и диск.
2. Таймаут при загрузке страницы: профилирование, индексы, кэширование, CDN, асинхронные операции, балансировка нагрузки, контроль SLA по времени ответа.

---

Часть 2. Практическое применение алгоритмов анализа

Задание 4. Комплексный анализ ошибки (RCA)

Классификация ошибки:

· Тип: Конфигурационная / эксплуатационная.
· Компонент: SQL Server, БД PortalDB, диск C:, пул JDBC-соединений.
· Критичность: Critical.
· Влияние на пользователей: 250 заявок за 45 минут, вход в корпоративный портал невозможен, бизнес-процессы остановлены.

Метод «5 Почему»:

1. Почему пользователи не могли войти?
      → Приложение не могло получить соединение с БД, возникал JDBC timeout.
2. Почему приложение не могло получить соединение?
      → Пул соединений исчерпался, БД была недоступна/не отвечала.
3. Почему БД была недоступна?
      → SQL Server не мог корректно работать с PortalDB: журнал транзакций заполнен.
4. Почему журнал транзакций заполнен?
      → Диск C: был заполнен на 99%, журнал не мог расти и не очищался.
5. Почему диск был заполнен и не очищался?
      → Не было мониторинга свободного места, автоматического обслуживания журналов БД и контроля роста логов.

Корневая причина: отсутствие мониторинга и регламента обслуживания дискового пространства и журналов БД, что привело к заполнению диска, остановке БД и недоступности портала.

Краткосрочное решение:
→ В 14:50 очистили логи БД и дисковое пространство, освободили место, проверили/перезапустили сервисы. Система восстановлена в 15:08.

Долгосрочное решение:
→ Настроить мониторинг диска и журналов с алертами на 80%/90%; автоматические бэкапы и очистку/truncate журналов; ротацию логов; расширение диска; capacity planning; health-check БД и пула соединений; runbook для дежурных; регулярные нагрузочные тесты.

Оценка RTO и RPO:

· RTO системы: 4 часа. Фактическое время простоя: 45 минут.
    → Соблюдено.
· RPO системы: 15 минут. Потери данных: 35 минут.
    → Не соблюдено.

---

Задание 5. Дерево решений для ошибки «Приложение не открывается»

```text
Приложение не открывается
├── Ошибка у одного пользователя?
│   ├── Да → локальная проблема
│   │   ├── Проверить права доступа
│   │   │   ├── Нет прав → выдать права / обратиться к администратору
│   │   │   └── Права есть → перейти к сети
│   │   ├── Проверить сетевое подключение / VPN
│   │   │   ├── Нет сети/VPN → восстановить подключение
│   │   │   └── Сеть есть → перейти к браузеру/клиенту
│   │   ├── Проверить кэш, cookies, версию браузера
│   │   │   ├── Ошибка исчезла → очистить кэш, обновить браузер
│   │   │   └── Не исчезла → переустановить клиент/проверить устройство
│   │   └── Собрать логи клиента, скриншот, время ошибки
│   └── Нет → ошибка у всех пользователей
│       ├── Проверить доступность сервера
│       │   ├── Сервер жив?
│       │   │   ├── Нет → восстановить сервер/ВМ
│       │   │   └── Да → проверить службы приложения
│       │   │       ├── Служба остановлена → запустить
│       │   │       └── Служба работает → проверить БД
│       │   └── Сеть работает?
│       │       ├── Нет → восстановить сеть/DNS/балансировщик
│       │       └── Да → проверить БД
│       ├── Проверить БД
│       │   ├── БД недоступна → восстановить / переключить на реплику
│       │   ├── Диск или журнал заполнен → очистить / расширить
│       │   └── БД доступна → проверить пул соединений
│       └── Проверить обновления и конфигурацию
│           ├── Было обновление сегодня?
│           │   ├── Да → откатить обновление / исправить конфиг
│           │   └── Нет → проверить логи, метрики, последние изменения
│           └── Проверить внешние зависимости/API
└── Не удалось классифицировать → эскалация, сбор логов, запуск RCA
```

---

Задание 6. Анализ ошибок в логах

Типы ошибок и количество:

Тип Количество
Pool empty. Unable to fetch a connection in 30 seconds 3
NullReferenceException 3
Connection timeout. Unable to acquire JDBC Connection 3
WARNING: Disk space: 15% remaining on drive C: 1

Итого: 9 ERROR и 1 WARNING.

Самая частая ошибка:
→ Три ошибки встречаются по 3 раза: Pool empty, NullReferenceException, Connection timeout. Если считать только ERROR, они делят первое место.

Самая критичная ошибка:
→ Pool empty / Connection timeout — они блокируют работу с БД и делают приложение недоступным.

Есть ли предупреждение?
→ Да: Disk space: 15% remaining on drive C:.

Какая ошибка, скорее всего, является корневой причиной для остальных?
→ Нехватка дискового пространства и связанная с ней недоступность/перегрузка БД.
Обоснование: warning о диске, затем Connection timeout, Pool empty, а NullReferenceException выглядит как вторичное следствие неполученного соединения или некорректной обработки ошибки.

Решение для самой частой ошибки / группы ошибок:
→ Освободить диск и обслужить журналы БД; проверить доступность SQL Server; увеличить/настроить пул соединений; устранить утечки соединений; настроить таймауты, retry и circuit breaker; добавить мониторинг диска, БД и пула соединений; исправить обработку NullReferenceException, чтобы ошибка не скрывала первопричину.