В критической ИС авторизация пользователей была настроена через LDAP/AD-контроллер .100 (основной), с резервным контроллером на случай отказа.

Основной контроллер сняли на ремонт. По замыслу система должна была переключиться на резервный. Но переключения не произошло — и пользователи массово начали жаловаться на невозможность входа.

Подразделение ИС об этом ремонте в подразделении ЦОДа не знало (обычная проблема функциональной модели управления). Просто в один момент массово пошли заявки на невозможность зайти в ИС.

Лично мой алгоритм действий как руководителя ИС: после первых 5 заявок удостоверилась, что ИС работает штатно и ее балансировщик тоже. Посмотрела, какая авторизация в ИС установлена у пользователей, которые не смогли зайти в СЭД. У всех была установлена LDAP/AD-авторизация. Опытным путем удостоверилась, что с парольной авторизацией нормально заходит в ИС. Сказала профильным подразделениям, что LDAP/AD-авторизация не функционирует. Время постановки диагноза от первых заявок - 5 минут. Дальше пошла работа профильных подразделений, заняла около 30 минут.

Что выяснилось при разборе профильного подразделения: 🔹 «Снятый» контроллер фактически продолжал работать и отвечал на запросы по адресу .100. 🔹 На запросы авторизации он отвечал отказом: SEVERE: javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090449, comment: AcceptSecurityContext error, data 51f, v3839] 🔹 error code 49 — это invalidCredentials. То есть сервер жив и осознанно отвергает учётные данные, а не падает и не молчит. 🔹 Механизм failover в ИС был настроен на переключение только при недоступности основного контроллера (нет ответа / timeout / connection refused). Раз сервер отвечал — пусть даже отказом — система считала его живым и на резервный не переключалась. Формально это корректное поведение механизма. 🔹 В результате отказали только пользователи с LDAP/AD-авторизацией. Те, кто входил по локальному паролю, работали нормально.

Корневые причины:

1. Организационная: узел «сняли на ремонт» на словах, но не изолировали фактически — не отключили питание/порт, не заблокировали IP, не сняли DNS-запись. Как признали на разборе: «никто не вспомнил, что 100 в ИСах используется». 2. Отсутствие реестра зависимостей: не было учёта, какие системы ходят на какой LDAP-контроллер. 3. Ограниченность failover: проверка только «доступен/недоступен», без проверки функциональной пригодности (успешный bind тестовой учётки). 4. Мониторинг не поймал: не было алерта на всплеск отказов авторизации (error 49) — о проблеме узнали от пользователей.

Ключевой вывод: Отказ авторизации — это не отказ сервиса. Для механизма переключения LDAP-сервер, отвечающий error 49, выглядит полностью живым. Поэтому «снятый», но не изолированный контроллер может тихо саботировать авторизацию, пока резервный простаивает. Failover должен проверять не только сетевую доступность, но и способность реально аутентифицировать (пробный bind). А вывод любого узла из эксплуатации — сопровождаться блокировкой IP/порта, снятием DNS и уведомлением владельцев ИС.

Чек-лист, который вырос из этого случая:

👉 Реестр зависимостей ИС ↔ LDAP-контроллеры (CMDB). 👉 Регламент вывода узла: уведомление владельцев, блокировка порта 389/636, снятие DNS/A-записи. 👉 Health-check резерва по пробному bind тестовой учётки, а не только по ping/connect. 👉 Алерт на всплеск error 49 в логах приложений. 👉 При выводе — финальная проверка, что на узел больше никто не ходит.

Организационно:

Отдел сопровождения ИС должен получать превентивные предупреждения обо всех работах на инфраструктуре ИС, хотя она и не входит в сферу ответственности подразделения ИС. Чтобы не пришлось без вводных копать, откуда растут ноги у града заявок, которые начинают сыпаться от пользователей ИС.

Таких ситуаций при сопровождении ИС было много. ЦОД, сети или ТЗИ проводили работы, никого не уведомляя, а ТП ИС получал вал заявок и диагностировал без вводных. Часто узкие отделы именно от ТП ИС узнавали о своих проблемах.

#ИС #LDAP #отказоустойчивость #инфраструктура #экспертизаборисовской #управление_ИС