IIS / веб-приложения были сложной проблемой в магазинах, в которых я работал в течение долгого времени.
С одной стороны, IIS - это служба, встроенная в сервер (в целом), и за ее обслуживание и настройку обычно несут ответственность администраторы сервера. Когда возникает проблема, они знают, что должно произойти, или, по крайней мере, могут диагностировать до точки, где они говорят: «Что-то не так с веб-приложением», и заставляют разработчика отладить их код.
Однако каждое веб-приложение на сервере уникально и имеет множество нюансов, которые могут быть сложными в зависимости от имеющихся проблем.
С другой стороны, каждое веб-приложение уникально во многих отношениях и имеет определенные проблемы, которые необходимо решить, а разработчик - это человек, который знает о приложении больше всего. Если файл web.config необходимо изменить для отладки или IIS начинает огорчать веб-приложение, разработчик должен знать, в чем заключается проблема, и исправить ее соответствующим образом либо из-за IIS, либо из-за самого приложения.
Однако предоставление разработчикам возможности самостоятельно настраивать IIS становится серьезной проблемой, потому что некоторые настройки / оптимизации могут серьезно ухудшить производительность и стабильность сервера.
Так в чем же баланс? Должны ли администраторы сервера быть гуру IIS и обрабатывать все эти проблемы, а я просто отправляю файлы сайта после развертывания, или разработчик должен взять на себя ответственность за сервер и проблемы IIS и решить их соответствующим образом?
Похоже, что вам действительно нужен кто-то с опытом по обе стороны забора.
По моему опыту (с небольшими компаниями), у ИТ / системного администратора нет времени, интереса или специфических знаний для веб-приложений, чтобы правильно поддерживать настройки IIS. Они дойдут до операционной системы и передадут IIS мне, разработчику.
Очевидно, мне нужно быть «больше, чем просто программистом», чтобы все работало правильно; Я должен знать о проблемах системного уровня (безопасность и прочее). Я много лет занимаюсь низкоуровневым системным управлением, поэтому я уверен в решении такого рода задач (на самом деле, за эти годы я научил профессиональных системных администраторов некоторым вещам). Однако не у каждого разработчика есть такая возможность.
Тем не менее, судя по тому, что я видел, разработчиков с навыками системного администратора больше, чем сисадминов с навыками разработки (webapp).
Как всегда, YMMV.
Лично я бы не хотел, чтобы разработчик возился с IIS, особенно если это означало, что это может вызвать проблемы с другим приложением, когда другому разработчику придется устранять неполадки, и так далее.
Если есть проблемы с IIS, попросите системного администратора изучить это, а если есть проблема с конкретным приложением, отправьте его обратно разработчику. Если у разработчика есть проблема, сообщите об этом системному администратору, который затем может попытаться принять обоснованное решение о том, вносить ли какие-либо изменения, и выяснить, как это повлияет на всех.
Мы (системные администраторы) относимся к нашим разработчикам так же, как к сторонним поставщикам - когда они хотят, чтобы мы развернули приложение, они должны предоставить документацию, если они ожидают, что оно будет поддерживаться. Это включает в себя стандартные процедуры устранения неполадок и путь эскалации поддержки (требования к времени безотказной работы в сочетании с задокументированной ответственностью разработчика в случае неприемлемого отключения).
Очевидно, что он не черно-белый, но он очень сильно помогает ослабить напряженность между разработчиками и администраторами. Теперь разработчики понимают, что они должны предоставлять программное обеспечение, качество которого обратно пропорционально их готовности быть загруженным в нерабочее время, и теперь у разработчиков есть инструменты и документы, которые можно использовать, не чувствуя себя на крючке для инструментов, которые они не создавали.
Итак, в вашем сценарии это будет означать, что разработчики создают свое приложение на собственном сервере IIS, а затем предоставляют программное обеспечение и документацию администраторам для установки на производственном сервере.
Должны ли администраторы сервера быть гуру IIS и обрабатывать все эти проблемы, а я просто отправляю файлы сайта после развертывания, или разработчик должен взять на себя ответственность за сервер и проблемы IIS и решить их соответствующим образом?
Ответ: найти одна персона и анонсировать их "WSA" (администратор веб-сервера). Они могли быть админом или разработчик; это действительно не имеет значения. Но им необходимо погрузиться в оба аспекта работы, а остальная часть команды (с обеих сторон) должна уважать их опыт.
Это ничем не отличается от того, как администраторы баз данных занимают грань между ИТ и разработчиками. Учитывая важность веб-серверов в организации с веб-продуктом, я думаю, что это важная роль, которую часто упускают из виду.
Поскольку Интернет еще молод (по сравнению с базами данных), этого человека трудно нанять. Скорее всего, вам нужно будет вырастить / подготовить кого-то к роли.
С новыми утилитами, такими как Инструмент веб-развертывания (который станет стандартным встроенным способом публикации веб-приложений, начиная с Visual Studio 2010), Microsoft, похоже, движется по пути, позволяя разработчикам или, по крайней мере, инженерам по установке выбирать такие вещи, как настройки IIS (сертификаты, настройки пула приложений и т. д.) . Они встраиваются в установочный пакет msdeploy и автоматически применяются к серверу IIS при развертывании пакета на серверах.
Кажется разумным компромиссом. Разработчики не вручную изменяют настройки на действующих производственных серверах, а системные администраторы не должны обладать знаниями, специфичными для веб-приложений. И все же желаемые настройки IIS четко видны системным администраторам, которые хотят понять, что произойдет до установки пакета.