Хто відповідає за підтримку IIS для веб-додатків?

IIS / Веб-додатки були складним питанням у магазинах, в яких я працював з часом.

З одного боку, IIS - це сервіс, вбудований у сервер (загалом) і, як правило, відповідає адміністраторам сервера за підтримку та налаштування. Коли виникає проблема, вони знають, що має статися, або можуть принаймні поставити діагноз до моменту, коли вони говорять: "Щось не так із веб-додатком", і розробник налагоджує свій код.

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

З іншого боку, кожен веб-додаток багато в чому унікальний і мав конкретні проблеми, які потрібно вирішити, а розробник - це людина, яка найбільше знає про додаток. Якщо файл web.config потрібно модифікувати для налагодження, або IIS починає надавати горе веб-додатку, розробник повинен знати, де лежить проблема, і виправити це відповідно через IIS або саму програму.

Однак, дозволити розробнику самостійно заходити та налаштовуватися на IIS стає серйозною проблемою, оскільки деякі налаштування / оптимізації можуть серйозно погіршити продуктивність та стабільність сервера.

То де лежить рівновага? Чи повинні адміністратори сервера бути гуруми IIS і вирішувати всі ці проблеми, і я просто надсилаю файли сайту за допомогою розгортання, або розробник повинен взяти на себе відповідальність за проблеми сервера та IIS і вирішити їх відповідно?

Звучить як те, що вам справді потрібно, - це хтось, хто має досвід з обох боків огорожі.

З мого досвіду (з компаніями меншого розміру), персонал IT / sysadmin не має часу, інтересів або знань, пов'язаних з webapp, щоб правильно підтримувати налаштування IIS. Вони візьмуть речі до операційної системи і передадуть IIS мені, розробнику.

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

І все-таки, з того, що я бачив, є більше розробників з навичками sysadmin, ніж є sysadmin з (webapp) навичками розвитку.

Як завжди, YMMV.

Я особисто не хотів би, щоб розробник возився з IIS, особливо якщо це означало, що це може спричинити проблеми з іншим додатком, коли інший розробник потребує зйомки, увімкнення та вмикання.

Якщо є проблеми IIS, попросіть SysAdmin вивчити це, а якщо є проблема з певним додатком, відправте його назад до розробника. Якщо у розробника є проблема, донесіть її до SysAdmin, який може спробувати прийняти обгрунтоване рішення щодо того, чи потрібно вносити будь-які зміни та з'ясувати, як це вплине на всіх.

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

Це, очевидно, не чорно-біле, але зроблено багато, щоб полегшити напругу між дияволами та адміністраторами. Тепер розробники усвідомлюють, що вони повинні надати програмне забезпечення якості, обернено пропорційне їхньому бажанню пройти тематичну обробку через години, і у розробників зараз є інструменти та документи, які можна пройти, не відчуваючи гачка інструментів, які вони не створили.

Отже, у вашому сценарії це означатиме, що розробники створюють свою програму на власному сервері IIS, а потім надають програмне забезпечення та документацію для адміністраторів для встановлення на виробничому сервері.

Чи повинні адміністратори сервера бути гуруми IIS і вирішувати всі ці проблеми, і я просто надсилаю файли сайту за допомогою розгортання, або розробник повинен взяти на себе відповідальність за проблеми сервера та IIS і вирішити їх відповідно?

Відповідь: знайдіть одну людину і помажте їм "WSA" (адміністратор веб-сервера) . Вони можуть бути адміністратором або розробником; це насправді не має значення. Але їм потрібно зануритися в обидва аспекти роботи, а решта команди (з обох сторін) повинні поважати їхній досвід.

Це не відрізняється від того, як DBA переходити лінію між IT / dev. Зважаючи на важливість веб-серверів в організації з веб-продуктом, я вважаю, що це є критично важливою і часто недооціненою роллю.

Оскільки Інтернет є ще молодим (порівняно з базами даних), важко набрати цю особу. Вам, швидше за все, потрібно буде когось виростити / привчити до ролі.

З новими утилітами, такими як Інструмент веб-розгортання (який стане стандартним вбудованим способом публікації веб-додатків, починаючи з Visual Studio 2010), Microsoft, схоже, веде шлях до того, щоб розробникам або принаймні інженерам-інженерам вибирати такі речі, як налаштування IIS ( certs, налаштування пулу додатків тощо). Вони вбудовуються в інсталяційний пакет msdeploy і автоматично застосовуються до сервера IIS, коли пакет розгортається на сервери.

Здається, це розумний компроміс. Розробники не збираються вручну спілкуватися з налаштуваннями на серверах живого виробництва, а системним адміністраторам не потрібно мати знання, пов’язані з webapp. І все ж бажані налаштування IIS добре помітні для системних адміністраторів, які хочуть зрозуміти, що відбуватиметься до встановлення пакета.