Comments 11
Автор, моё почтение! Это не статья, а настоящий бальзам на душу системного администратора.
Если позволите, добавлю крошечный нюанс из практики: после создания эндпоинта всегда критически важно тестировать его под учетной записью реального пользователя (члена группы Tier1_IIS_Admins), а не под своей админской. Иногда всплывают совершенно неочевидные моменты с правами, которые видны только из по-настоящему «ограниченной» сессии.
В общем, прекрасная работа! Статья ушла в закладки и уже переслана коллегам. Именно такие материалы делают Хабр Хабром. Спасибо!
И всё это ради одной единственной задачи: перезапустить пул приложений в IIS.
А почему не сделать WatchDog, который будет автоматически перезапускать пул в случае чего? Или там всё-таки не одна задача :)
Это же просто пример. Если вы сможете полностью формализовать критерии корректирующего действия, то вмешательство человека и не нужно. Но так, очевидно, не всегда бывает.
Отличный и очень правильный вопрос! Вы абсолютно правы, во многих случаях хороший Watchdog (или современная система мониторинга с автохилингом) — это первая и самая верная линия обороны. Автоматизация мониторинга и восстановления — это основа SRE-подхода, и было бы глупо её игнорировать.
Но, как вы и предположили в конце, «задача» действительно не одна. :)
Перезапуск пула в 3 часа ночи — это просто яркий, узнаваемый «симптом» гораздо более широкой проблемы: необходимости безопасного делегирования ручных операций.
Watchdog сработает, когда пул упал по понятной причине (например, превысил лимиты памяти). А что, если:
Нужно просто проверить статус пула или сервиса, не перезапуская его? (Например, в рамках диагностики перед выкаткой).
Разработчикам нужно выкатить обновление, что требует ручной последовательности: остановить пул, скопировать файлы, запустить пул. Это плановая операция, которую Watchdog делать не должен.
Нужно прочитать определенный лог-файл из папки приложения, не давая при этом доступ ко всей файловой системе сервера.
Приложение не «упало», а «подвисло» в таком состоянии, которое Watchdog не может отловить (например, отвечает на health-check, но не обслуживает пользователей), и требуется ручной
iisresetили перезапуск конкретного пула?Нужно очистить кэш приложения, выполнив специальный скрипт, доступ к которому нужно дать команде поддержки?
В этом и заключается суть JEA. Это не замена системам автоматического восстановления. JEA — это создание безопасного, аудируемого и строго ограниченного «API для людей» на те случаи, когда автоматика бессильна или когда требуется осознанное человеческое вмешательство.
Мы даем инженеру не «ключ от города» (RDP), а только нужный ему «скальпель» (Restart-WebAppPoolSafely, Get-AppLogs, Deploy-NewBuild), чтобы он мог решить одну из этих десятков потенциальных проблем, не создавая при этом дыру в безопасности.
Так что вы попали в самую точку: Watchdog для машин, JEA для людей. Два инструмента для одной большой цели — стабильности и безопасности.
Нужно подходить к проблеме комплексно, а не затыкать вновь появившиеся дыры в ржавом корпусе корабля:
«Нужно проверить статус пула» Это задача мониторинга, а не человека. Сделайте дашборд или алерт — пусть система показывает статус сама. Watchdog не обязан это делать — но и ручной доступ не нужен.
«Нужно выкатить обновление вручную» Это не администрирование — это деплой. Автоматизируйте через CI/CD. Если делаете руками — проблема в процессах, а не в отсутствии JEA. Watchdog тут ни при чём — он не для деплоев.
«Нужно прочитать лог-файл» Логи должны собираться централизованно. Настройте ELK / Loki / Splunk. Если лезете на сервер — у вас нет лог-инфраструктуры. Watchdog не читает логи — и человек не должен.
«Приложение “висит”, но health-check зелёный» Значит, health-check — неправильный. Чините приложение и чеки, а не давайте людям кнопку “перезапустить”. Watchdog должен реагировать на реальные признаки сбоя — научите его.
«Нужно очистить кэш скриптом» Это должно быть автоматом — по расписанию, по API или в пайплайне. Если запускаете вручную — вы создаёте риск и зависимость от человека. Watchdog не для этого — но и JEA не решение, а костыль.
Вы абсолютно правы по существу. Ваша позиция — это «золотой стандарт» SRE и DevOps, к которому должна стремиться любая зрелая IT-организация.
В идеальном мире нет места для ручных операций, описанных в примерах. В реальном мире мы постоянно сталкиваемся с компромиссами, вызванными тремя главными факторами: легаси, ресурсы и стороннее ПО.
Легаси и технический долг. Многие из нас поддерживают критически важные системы, написанные 5, 10, а то и 15 лет назад. У них нет и не будет «правильных» health-check'ов или нативной поддержки экспорта структурированных логов. Переписать их — проект на годы и миллионы. Вывести из эксплуатации — невозможно для бизнеса. Их нужно администрировать здесь и сейчас.
Ресурсные ограничения. Внедрение ELK-стека, построение полноценного CI/CD для сложного продукта или рефакторинг системы мониторинга — это огромная работа. Бизнес не всегда готов выделить на это время и деньги, когда в бэклоге есть критичные для дохода задачи. Возникает классический trade-off.
Стороннее ПО. Мы часто администрируем «черные ящики» — коммерческий софт от вендоров, в который мы не можем вносить изменения. Мы можем только управлять его окружением и выполнять те административные задачи, которые предусмотрел разработчик, и они далеко не всегда автоматизируемы через API.
В этом реальном контексте JEA — это не «костыль», который поощряет плохие практики. Это инструмент управления рисками и прагматичный шаг к повышению безопасности.
Тактический выигрыш: Пока мы планируем стратегический проект по внедрению централизованного логирования (который займет 6 месяцев), JEA позволяет нам сегодня закрыть огромную дыру в безопасности, когда младший инженер ходит на сервер за логами с правами локального администратора.
Безопасный переходный период: Это мост, который позволяет безопасно жить с унаследованной системой, пока на другом берегу строится новая, соответствующая всем канонам DevOps.
Аварийный «стеклянный шкаф»: Даже в самых автоматизированных системах случаются непредвиденные сбои (zero-day, уникальный баг). Вопрос не в том, понадобится ли когда-нибудь ручное вмешательство, а в том, насколько безопасным, аудируемым и строго ограниченным будет этот доступ, когда оно понадобится.
Поэтому я полностью с вами согласен: конечная цель — полная автоматизация и построение отказоустойчивых систем. Но путь к этой цели долог. JEA — это профессиональный инструмент, который позволяет пройти этот путь, не оставляя за спиной открытые двери для атак. Это не «или/или», а «и/и» — мы строим правильные процессы и одновременно используем лучшие инструменты для защиты текущего состояния.
Вопрос ещё в размере инфраструктуры. Зачастую есть 100-200 серверов включая тестовые и достаточно продвинутые пользователи которым нужна кнопка "сделать хорошо быстро". Вышеописанное практически идеально для такого сценария.
Зачастую в таких организациях выглядит всё печально.
Мониторинг и алертинг в процессе осознания.
Централизованное логирование если есть, то в зайчаточном состоянии. Типа есть сервак куда мы складываем избранные события от избранных источников + скрипты по расписанию.
Раскатывать там CI/CD неоправданно сложно → дорого. Размеры парка малы. Если додумались до мысли, что дешевле вместо настроенных образов ОС, держать установщик+конфиг для Terraform|Ansible|PowerShell DSC и вообще раскатывать по сети, то это прям заявка на место гуру.
А так, по моим ощущениям, 99,9% "администраторов" страдают от эффекта утёнка, ноют что в десяточке всё сложно и семёрка закрывает все их потребности, а скрипты для них "ненадёжная штука и ваще чё делать если челик написавший это ушёл и никто больше не знает как там и чо руками надёжнее". Могу как пример привести, что есть ПО в котором если обнаружены подписанные модули в недоверенном расположении, то они автоматом не грузятся и их необходимо при первом запуске помечать как доверенные, но есть возможность указать в установщике доверенное расположение и тогда эти же модули автоматически загрузятся. Как вы думаете, что этим людям удобнее?
Интересно, а почему Ansible, а не тот же PowerShell DSC?
Если коротко, выбор в пользу Ansible — это ставка на универсальность в современных IT-средах.
В то время как PowerShell DSC — это мощный нативный инструмент для Windows, Ansible выбирают, потому что он:
Кросс-платформенный: Одним инструментом можно управлять и Windows, и Linux, и сетевым оборудованием.
Безагентный: Проще в развертывании, так как не требует установки и настройки агента на каждой машине.
Более гибкий: Легко встраивается в CI/CD пайплайны для оркестрации (выполнения шагов по порядку), а не только для поддержания состояния.
В общем, Ansible лучше подходит для гетерогенных (смешанных) инфраструктур и комплексных DevOps-задач.
JEA + PowerShell Remoting: Принцип минимальных привилегий в проде без боли (Windows Server 2019/2022)