WebアプリのIIS）を維持する責任があるのは誰ですか？
IIS/Webアプリケーションは、私が長年働いてきたショップでは難しい問題でした。
一方では、IISは（全体として）サーバーに組み込まれているサービスであり、通常、サーバー管理者が保守と構成を行う責任があります。問題が発生した場合、彼らは何が起こる必要があるかを知っているか、少なくとも「Webアプリに問題があります」と言うところまで診断し、開発者にコードをデバッグさせることができます。
ただし、サーバー上の各Webアプリケーションは一意であり、目前の問題に基づいて複雑になる可能性のある多くのニュアンスがあります。
一方、各Webアプリケーションは多くの点で固有であり、対処する必要のある特定の問題があり、開発者はアプリケーションについて最もよく知っている人です。デバッグのためにweb.configファイルを変更する必要がある場合、またはIISがWebアプリケーションに悲しみを与え始めた場合、開発者は問題がどこにあるかを知り、それに応じてIISまたはアプリケーション自体。
ただし、一部の設定/最適化はサーバーのパフォーマンスと安定性を著しく損なう可能性があるため、開発者が自分でIISを使用して微調整できるようにすることは深刻な問題になります。
では、バランスはどこにあるのでしょうか？サーバー管理者がIISの達人であり、これらすべての問題を処理し、展開時にサイトファイルを送信するだけの場合、または開発者がサーバーとIISの問題に責任を負い、対処する必要がある場合それに応じてそれら？
あなたが本当に必要としているのは、フェンスの両側に専門知識を持っている人のように聞こえます。
私の経験では（小規模な企業で）、IT /システム管理者のスタッフには、IISセットアップを適切に維持するための時間、関心、またはWebアプリ固有の知識がありません。オペレーティングシステムに関しては、開発者である私にIIS）を渡します。
明らかに、これを適切に機能させるには、「単なるコーダー以上のもの」である必要があります。システムレベルの問題（セキュリティなど）に注意する必要があります。私は何年もの間低レベルのシステム管理を行ってきたので、この種のタスクに自信があります（実際、私はプロのシステム管理者に何年にもわたっていくつかのことを教えてきました）。ただし、すべての開発者がこの機能を備えているわけではありません。
それでも、私が見たところ、sysadminスキルを持つ開発者の方が多く、（webapp）開発スキルを持つsysadminがいます。
いつものように、YMMV。
サーバー管理者がIISの達人であり、これらすべての問題を処理し、展開時にサイトファイルを送信するだけの場合、または開発者がサーバーとIISの問題に責任を負い、対処する必要がある場合それに応じてそれら？
回答：1人を見つけて通知します"WSA"（Webサーバー管理者）。彼らは管理者または開発者である可能性があります。それは本当に問題ではありません。しかし、彼らは仕事の両方の側面に没頭する必要があり、チームの他のメンバー（両側）は彼らの専門知識を尊重する必要があります。
これは、DBAがITと開発の境界線にまたがる方法と同じです。 Webベースの製品を使用している組織におけるWebサーバーの重要性を考えると、これは重要であり、見過ごされがちな役割だと思います。
ウェブは（データベースと比較して）まだ若いので、この個人を採用するのは難しいです。あなたはおそらく誰かをその役割に成長/手入れする必要があるでしょう。
私は個人的に、開発者がIISをいじり回したくないと思います。特に、別の開発者が何度もトラブルシューティングを行う必要がある別のアプリケーションで問題が発生する可能性がある場合はそうです。
IISの問題がある場合は、SysAdminに調査を依頼し、特定のアプリに問題がある場合は、開発者に返送してください。開発者に問題がある場合は、問題を提起してください。 SysAdminは、変更を加えるかどうかについて情報に基づいた決定を下し、それがすべての人にどのように影響するかを理解することができます。
私たち（システム管理者）は、サードパーティベンダーと同じように開発者を扱います。アプリのデプロイを希望する場合、サポートが必要な場合はドキュメントを提供する必要があります。これには、一般的なトラブルシューティングルーチンとサポートエスカレーションパス（許容できない停止の場合の文書化された開発者の責任と組み合わされたアップタイム要件）が含まれます。
明らかに白黒ではありませんが、開発者と管理者の間の緊張を和らげるために多くのことが行われています。開発者は、時間外にページングされる意欲に反比例する品質のソフトウェアを提供する必要があることを認識し、開発者は、作成しなかったツールのフックを感じることなく、ツールとドキュメントを実行できるようになりました。
したがって、シナリオでは、開発者が独自のIISサーバーでアプリを作成し、管理者が本番サーバーにインストールするためのソフトウェアとドキュメントを提供することを意味します。
Web Deployment Tool （Visual Studio 2010以降のWebアプリを公開するための標準の組み込み方法になる）のような新しいユーティリティにより、Microsoftは開発者または少なくともインストールを許可する方向に進んでいるようです。エンジニアはIIS設定（証明書、アプリプール設定など）などを選択します。これらはmsdeployインストールパッケージに組み込まれ、IISサーバーに自動的に適用されます。パッケージはサーバーに展開されます。
合理的な妥協のようです。開発者は本番サーバーの設定を手動でいじくり回す必要はなく、システム管理者はWebアプリ固有の知識を持っている必要はありません。それでも、パッケージがインストールされる前に何が起こるかを理解したいシステム管理者には、必要なIIS設定がはっきりと表示されます。