Введение в ITIL и понятие Инцидента. Инфраструктура существует не сама по себе, она предоставляет бизнесу ИТ-услуги. Для стандартизации эксплуатации IT-систем в мире используется библиотека лучших практик ITIL (Information Technology Infrastructure Library). В рамках процессов ITSM (IT Service Management) важнейшим является Управление инцидентами (Incident Management). Инцидент — это любое незапланированное прерывание работы ИТ-услуги или снижение её качества. Выход из строя блока питания сервера (даже если есть резервный), падение линка на коммутаторе, медленная загрузка базы данных — всё это инциденты. Главная и единственная цель процесса Incident Management — максимально быстро восстановить нормальную работу услуги для пользователей. На этом этапе мы не ищем глубокую причину поломки, мы 'тушим пожар'. Если серверу не хватает памяти и он завис, решением инцидента (Workaround) будет его жесткая перезагрузка, чтобы сервис заработал прямо сейчас.

Жизненный цикл инцидента и SLA. Инцидент проходит строгий путь в системе Service Desk (например, Jira, GLPI, Zammad). 1. Идентификация (пользователь позвонил или сработал алерт Zabbix). 2. Регистрация (создание тикета с обязательным указанием CI - Configuration Item, т.е. конкретного оборудования). 3. Категоризация и Приоритизация. 4. Диагностика. 5. Эскалация (передача сложной задачи от инженера L1 к эксперту L2/L3). 6. Разрешение и Закрытие. Работа системного администратора жестко регламентируется SLA (Service Level Agreement — Соглашение об уровне услуг). Ключевые метрики: TTA (Time to Acknowledge) — время реакции, за которое инженер берет тикет в работу. TTR (Time to Resolve) — время, отведенное на полное решение инцидента. Нарушение TTR ведет к штрафам для IT-отдела или аутсорсинговой компании.

Матрица приоритетов: Влияние (Impact) и Срочность (Urgency). Приоритет инцидента (Priority) никогда не ставится 'на глаз'. Он рассчитывается математически на основе пересечения двух параметров. Влияние (Impact) определяет масштаб проблемы: один пользователь не может распечатать документ (Низкое) или весь филиал отрезан от корпоративной сети (Высокое). Срочность (Urgency) определяет критичность по времени: сломался принтер в бухгалтерии в середине месяца (Низкая) или в день сдачи годового налогового отчета (Высокая). Пересечение Высокого Влияния и Высокой Срочности генерирует инцидент приоритета P1 (Критический). Для P1 инцидентов TTA может составлять 10 минут, а TTR — 2 часа. Типичная ошибка новичка — игнорировать приоритеты и решать задачи в порядке их поступления (FIFO), оставляя лежать 'в очереди' неработающий основной маршрутизатор, пока чинится мышка стажера.

Алгоритмы первичной диагностики (L1): Физический уровень. Диагностика всегда начинается с физического уровня (Layer 1 модели OSI). Около 70% проблем сетевой связности серверов кроются в кабельной инфраструктуре (СКС). Если сервер недоступен, прямой инструкцией (Direct Instruction) к действию является проверка индикации: 1. Проверьте Link/Activity светодиоды (LEDs) на порту коммутатора и сетевой карте сервера. Если диоды не горят — нет физического линка. 2. Проверьте патч-корд. Для медной витой пары (Cat6/Cat6a) частой проблемой является плохой обжим коннектора RJ-45 (перекрестные наводки NEXT). Для оптоволокна — загрязнение торца коннектора LC или деградация SFP-трансивера (пыль вызывает затухание сигнала - Attenuation). 3. Проверьте статус электропитания (горят ли индикаторы на блоках питания, не сработал ли автомат в PDU стойки). Правило: 'Прежде чем лезть в консоль, убедись, что кабель вставлен в розетку'.

Диагностика L2/L3: Коммутация и маршрутизация. Если физический линк есть (диоды горят), переходим на канальный уровень (L2). Если после подключения нового сервера вся сеть легла, а индикаторы на коммутаторах бешено и непрерывно мигают, вы столкнулись с широковещательным штормом (Broadcast Storm). Это сетевая петля, возникшая из-за отключенного протокола STP (Spanning Tree Protocol) или неправильной коммутации. Решение инцидента — физически выдернуть подозрительный кабель, чтобы разорвать петлю. Если серверу просто не выдается IP-адрес по DHCP, частой причиной является отсутствие настройки spanning-tree portfast edge на порту коммутатора доступа. Без нее порт тратит до 30 секунд на стадии Listening и Learning протокола STP, и сервер отваливается по таймауту, не дождавшись IP-адреса. Анализ этих симптомов позволяет закрыть инцидент за минуты.