Кто отвечает за поддержку IIS для веб-приложений?

IIS / Web Applications была сложной проблемой в магазинах, в которых я работал в течение долгого времени.

С одной стороны, IIS - это сервис, встроенный в сервер (по большому счету), и обычно администраторы сервера несут ответственность за его обслуживание и настройку. Когда возникает проблема, они знают, что должно произойти, или, по крайней мере, могут поставить диагноз до точки, где они говорят: «Что-то не так с веб-приложением», и пусть разработчик отлаживает свой код.

Однако каждое веб-приложение на сервере уникально и имеет много нюансов, которые могут быть сложными в зависимости от рассматриваемых проблем.

С другой стороны, каждое веб-приложение уникально во многих отношениях и имело определенные проблемы, с которыми необходимо иметь дело, и разработчик - это человек, который больше всего знает о приложении. Если файл web.config необходимо изменить для отладки или IIS начинает испытывать горе с веб-приложением, разработчик должен знать, в чем заключается проблема, и исправлять ее соответствующим образом либо из-за IIS, либо из-за самого приложения.

Однако предоставление разработчику возможности самостоятельно настраивать IIS становится серьезной проблемой, поскольку некоторые параметры / оптимизации могут серьезно повлиять на производительность и стабильность сервера.

Так где же баланс? Должны ли администраторы сервера быть гуру IIS и решать все эти проблемы, а я просто отправляю файлы сайта через развертывание, или же разработчик должен взять на себя ответственность за проблемы с сервером и IIS и решить их соответствующим образом?

Похоже, что вам действительно нужен человек с опытом по обе стороны забора.

По моему опыту (с небольшими компаниями), персонал IT / sysadmin не имеет ни времени, ни интереса, ни знаний, связанных с веб-приложением, чтобы правильно поддерживать настройки IIS. Они дойдут до операционной системы и передадут IIS мне, разработчику.

Очевидно, мне нужно быть «больше, чем просто программистом», чтобы сделать эту работу правильно; Я должен знать о проблемах системного уровня (безопасность и еще много чего). Я занимаюсь низкоуровневым управлением системами в течение многих лет, поэтому я уверен в решении этой задачи (на самом деле, я многому научил профессиональных сисадминов за эти годы). Однако не у каждого разработчика есть такая возможность.

Тем не менее, из того, что я видел, больше разработчиков с навыками sysadmin, чем сисадминов с навыками разработки (webapp).

Как всегда, YMMV.

Лично я бы не хотел, чтобы разработчик связывался с IIS, особенно если это означало, что это может вызвать проблемы с другим приложением, когда другой разработчик вынужден устранять неполадки.

Если есть проблемы с IIS, обратитесь к SysAdmin, а если есть проблема с конкретным приложением, отправьте его обратно разработчику. Если у разработчика есть проблема, сообщите об этом Сисадмину, который затем может попытаться принять обоснованное решение относительно того, вносить ли какие-либо изменения, и выяснить, как это повлияет на всех.

Мы (системные администраторы) относимся к нашим разработчикам так же, как и к сторонним поставщикам - когда они хотят, чтобы мы развернули приложение, они должны предоставить документацию, если они ожидают, что она будет поддерживаться. Это включает в себя общие процедуры устранения неполадок и путь повышения поддержки (требования к времени безотказной работы в сочетании с задокументированной ответственностью разработчика в случае неприемлемого сбоя).

Он явно не черно-белый, но он сделал многое, чтобы ослабить напряжение между разработчиками и администраторами. Разработчики теперь понимают, что они должны предоставлять программное обеспечение качества, обратно пропорционального их готовности к постатейной работе в нерабочее время, и теперь разработчики имеют инструменты и документы, которые можно просмотреть, не чувствуя себя на крючке для инструментов, которые они не создавали.

Таким образом, в вашем сценарии это означало бы, что разработчики создают свое приложение на своем собственном сервере IIS, а затем предоставляют программное обеспечение и документацию для установки администраторами на производственном сервере.

Должны ли администраторы сервера быть гуру IIS и решать все эти проблемы, а я просто отправляю файлы сайта через развертывание, или же разработчик должен взять на себя ответственность за проблемы с сервером и IIS и решить их соответствующим образом?

Ответ: найдите одного человека и назначьте его «WSA» (администратор веб-сервера) . Они могут быть администратором или разработчиком; это действительно не имеет значения. Но им нужно погрузиться в оба аспекта работы, а остальная часть команды (с обеих сторон) должна уважать их опыт.

Это ничем не отличается от того, как администраторы базируются между IT / dev. Учитывая важность веб-серверов в организации, имеющей веб-продукт, я считаю, что это важная и часто упускаемая из виду роль.

Поскольку сеть еще молода (по сравнению с базами данных), трудно набрать этого человека. Скорее всего, вам нужно вырастить / подготовить кого-то к роли.

С такими новыми утилитами, как Web Deployment Tool (который станет стандартным встроенным способом публикации веб-приложений, начиная с Visual Studio 2010), Microsoft, похоже, движется по пути, позволяющему разработчикам или, по крайней мере, инженерам-установщикам выбирать такие вещи, как настройки IIS ( сертификаты, настройки пула приложений и т. д.). Они встроены в установочный пакет msdeploy и автоматически применяются к серверу IIS при развертывании пакета на серверах.

Похоже, разумный компромисс. Разработчики не занимаются ручной настройкой параметров на действующих производственных серверах, а системные администраторы не должны обладать знаниями, специфичными для веб-приложений. И все же желаемые настройки IIS четко видны системным администраторам, которые хотят понять, что произойдет до установки пакета.