🏠 Домашнее задание — Учебный проект

К оглавлению урока

⚡ Суть задания

Написать отчёт «post mortem» по выполненной на уроке работе.

Три обязательных раздела:

  1. Причины инцидента
  2. Предпринятые шаги для восстановления и результаты
  3. Рекомендации по предотвращению

Вес: 60% итоговой оценки модуля.

Условие задания (из LMS)

Написать отчет «post mortem» по выполненной на уроке работе. В контексте инцидента, «post mortem» означает процесс анализа и оценки инцидента после того, как проблема была решена и работоспособность веб-сервиса восстановлена. Этот процесс направлен на изучение причин инцидента, выявление ошибок или недочетов, которые привели к сбою, и разработку мер для предотвращения подобных инцидентов в будущем.

В рамках учебного «post mortem» могут быть рассмотрены следующие вопросы и аспекты:

  • Причины инцидента
  • Предпринятые шаги для восстановления сервиса и устранения проблемы и полученные результаты
  • Формулирование рекомендаций и предложений по улучшению процессов

Вес задания: Учебный проект = 60% итоговой оценки модуля
Срок сдачи: до воскресенья недели выполнения проекта

Шаблон структуры post mortem отчёта

Post Mortem Report: Восстановление веб-сервера Apache/MediaWiki Дата инцидента: [дата занятия] Автор: [ваше имя] Статус: Resolved ═══════════════════════════════════════════════ 1. ПРИЧИНЫ ИНЦИДЕНТА ═══════════════════════════════════════════════ [Опишите, что привело к сбою] Первопричина (root cause): - ... Сопутствующие факторы: - ... ═══════════════════════════════════════════════ 2. ХРОНОЛОГИЯ И ШАГИ ВОССТАНОВЛЕНИЯ ═══════════════════════════════════════════════ Шаг 1: [название] → [результат] Шаг 2: [название] → [результат] ... ═══════════════════════════════════════════════ 3. РЕКОМЕНДАЦИИ ПО ПРЕДОТВРАЩЕНИЮ ═══════════════════════════════════════════════ Мониторинг: - ... Автоматизация: - ... Процессы: - ...

Пошаговое решение проекта (для самопроверки)

Используйте этот раздел для проверки своего понимания происходившего на уроке. Это основа для вашего post mortem отчёта.

Описание инцидента

  • Затронутая система: веб-сервер Apache httpd + MediaWiki на EC2 (Amazon Linux 2)
  • Симптом: сайт http://18.192.103.67/ недоступен
  • Первопричина: /var/log/httpd/access_log достиг 7 ГБ и заполнил диск на 100%

Шаг 1: Проверить сайт

Открыть http://18.192.103.67/ в браузере — соединение не устанавливается. Это подтверждает, что сервис недоступен.

Шаг 2: Подключиться по SSH

ssh -i ich.pem ec2-user@18.192.103.67

Перед подключением убедиться в правильных правах ключа: chmod 400 ich.pem

Шаг 3: Проверить статус httpd

sudo service httpd status

Результат: Active: inactive (dead) — сервис остановлен.

Шаг 4: Запустить httpd

sudo service httpd start

Шаг 5: Проверить статус после запуска

sudo service httpd status

Результат: Active: active (running) — сервис запущен.

Шаг 6: Попытаться скопировать LocalSettings.php → ошибка

cp /home/ec2-user/LocalSettings\ \(5\).php \
   /var/www/html/mediawiki/LocalSettings.php

Результат: cp: failed to extend '...': No space left on device
Вывод: диск заполнен, операции с файлами невозможны.

Шаг 7: Проверить error_log

cat /var/log/httpd/error_log | tail -20

Причина: (28)No space left on device: AH00646: Error writing to logs/access_log

Шаг 8: Диагностика дискового пространства

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p1   10G   10G     0 100% /

Диск заполнен на 100%, свободного места нет.

Шаг 9: Найти большие файлы

find / -type f -size +100M -exec du -h {} +
7.0G    /var/log/httpd/access_log
185M    /var/log/httpd/log_20240402.tar.gz
108M    /usr/lib/locale/locale-archive

Виновник: access_log — 7 ГБ. Это журнал запросов Apache, который рос без ограничений.

Шаг 10: Очистить access_log

sudo truncate -s 0 /var/log/httpd/access_log

Команда устанавливает размер файла в 0 байт, не удаляя сам файл (что важно — Apache продолжает писать в тот же файл).

Шаг 11: Проверить освободившееся место

df -h

Теперь Use% значительно ниже 100% — место освободилось.

Шаг 12: Скопировать LocalSettings.php (повторная попытка)

cp /home/ec2-user/LocalSettings\ \(5\).php \
   /var/www/html/mediawiki/LocalSettings.php

Теперь копирование должно пройти успешно.

Шаг 13: Исправить $wgServer в конфигурации

grep "wgServer" /var/www/html/mediawiki/LocalSettings.php
$wgServer = "https://18.153.51.162";

IP не совпадает с реальным адресом сервера. Исправить через vi:

vi /var/www/html/mediawiki/LocalSettings.php

В vi: :%s/18.153.51.162/18.192.103.67/g → Enter → :wq

После этого сайт должен открываться в браузере.

Шаг 14: Исправить некорректное задание cron у root

sudo crontab -l

Найдено задание:

* * * * * tar -czf /var/log/httpd/log_$(date +\%Y\%m\%d).tar.gz -C /var/log/httpd .

Проблемы этого задания:

  • * * * * * — каждую минуту (избыточно)
  • Архив создаётся в /var/log/httpd/ — той же папке, что и логи — архивирует сам себя

Исправить: sudo crontab -e — заменить задание на 0 0 * * * /home/ec2-user/backup_logs.sh

Шаг 15: Создать скрипт backup_logs.sh и добавить в crontab

# /home/ec2-user/backup_logs.sh
#!/bin/bash
LOG_DIR="/var/log/httpd"
LOG_FILE="access_log"
BACKUP_DIR="/var/log/httpd/backups"
DATE=$(date +%Y%m%d)
ARCHIVE="$BACKUP_DIR/$LOG_FILE-$DATE.tar.gz"

mkdir -p "$BACKUP_DIR"

# Архивировать лог-файл
tar -czf "$ARCHIVE" -C "$LOG_DIR" "$LOG_FILE"

# Очистить лог после архивации
truncate -s 0 "$LOG_DIR/$LOG_FILE"

# Удалить архивы старше 3 дней (хранить не более 3 копий)
find "$BACKUP_DIR" -type f -name "$LOG_FILE-*.tar.gz" -mtime +3 -exec rm {} \;
chmod +x /home/ec2-user/backup_logs.sh
crontab -e

Добавить:

0 0 * * * /home/ec2-user/backup_logs.sh

Итог: что было восстановлено

  • Перезапущен веб-сервис Apache httpd
  • Очищено дисковое пространство (access_log 7 ГБ → 0)
  • Восстановлен конфигурационный файл LocalSettings.php
  • Исправлена ошибка в $wgServer (неверный IP)
  • Исправлено некорректное задание cron root
  • Создан скрипт автоматической ротации логов с ограничением в 3 копии

Пример заполненного post mortem отчёта

Используйте как ориентир, но пишите своими словами.

Post Mortem Report: Восстановление веб-сервера Apache/MediaWiki

Дата: [дата занятия] | Автор: [ваше имя] | Статус: Resolved

1. Причины инцидента

Первопричина: файл /var/log/httpd/access_log достиг размера 7 ГБ, заполнив диск (10 ГБ) на 100%. Это привело к невозможности записи любых данных на диск, включая временные файлы оболочки, из-за чего Apache httpd не смог запуститься.

Сопутствующий фактор: некорректное задание cron у root (* * * * *) архивировало директорию /var/log/httpd/ в неё же, создавая архивы, которые также занимали пространство и попадали в следующие архивы.

Дополнительно: файл настроек LocalSettings.php отсутствовал в /var/www/html/mediawiki/, а резервная копия содержала устаревший IP в параметре $wgServer.

2. Шаги восстановления и результаты

  1. SSH-подключение к серверу → успешно
  2. sudo service httpd start → сервис запущен
  3. Диагностика: df -h показал 100% использования диска
  4. Поиск большого файла: find / -type f -size +100M -exec du -h {} + → access_log 7.0G
  5. sudo truncate -s 0 /var/log/httpd/access_log → диск освобождён
  6. Копирование LocalSettings.php → успешно
  7. Исправление $wgServer через vi → сайт заработал
  8. Исправление cron + создание backup_logs.sh → автоматическая ротация настроена

3. Рекомендации по предотвращению

  • Мониторинг диска: настроить alert при использовании более 80% (например, через cron-скрипт с df -h и отправкой email)
  • Ротация логов: настроить logrotate для автоматической ротации Apache-логов
  • Резервные копии конфигов: хранить актуальную копию LocalSettings.php в git-репозитории с правильным IP
  • Проверка cron: регулярно выполнять crontab -l для проверки заданий; тестировать скрипты вручную перед добавлением в cron

Как сдать задание

  1. Написать отчёт в виде текстового файла или документа
  2. Загрузить в LMS через кнопку «Добавить ответ на задание»
  3. Срок: до воскресенья недели проекта

Связанные разделы этого урока:

  • Теория — концепция и среда проекта
  • Примеры — пошаговый разбор команд
  • Решения — полные решения с объяснением