Уважайте, что у сисадминов есть работа, и пусть они делают свою работу. У многих компаний есть некомпетентные системные администраторы, и это часто нереально. Но я видел, как высокомерные разработчики игнорировали советы системных групп даже после того, как системные администраторы доказали свою компетентность.
Обсудите проект новой системы с системными администраторами. Часто есть ценное понимание. Разработчики часто смотрят на дискуссии с системными администраторами и называют начальные требования «преждевременной оптимизацией». Я действительно видел, как руководитель группы разработки сказал, что это было пустой тратой его времени - обсуждать требования к новым серверам баз данных с системными администраторами и администраторами баз данных, даже в части описания того, является ли это интенсивной записью или интенсивной операцией чтения, или сколько памяти потребуется.
Обсудите проблемы с производительностью сисадминов. Честно говоря, только системные администраторы способны правильно интерпретировать показатели производительности в системах. Я видел, как разработчики решили, что в Linux всегда происходит утечка памяти, потому что свободная память, сообщаемая «free», всегда уменьшается, даже после 10-го раза объясняется вывод «free».
Не делайте выводов, не обсуждая это с сисадминами. Я видел, как разработчики зацикливались на таких теориях, как «базы данных всегда связаны с дисками» (они не знали, что iostat даже существует), «RAID 5 быстрее для транзакционных рабочих нагрузок» (основываясь на воспоминаниях об одной системе баз данных, которая была перемещена с одной аппаратной платформы на другую - это была интенсивная нагрузка на чтение, в решении RAID5 было больше и более быстрых дисков, распределенных по большему количеству контроллеров. Но они забыли эти детали и только помнили заключение.)
Не разрабатывайте решение системной проблемы, не обсуждая ее с системными администраторами. Я работал в одной патологической среде, где разработчики разработали бы решение и пришли просить небольшой помощи в реализации. Члены группы Unix, кроме меня, глава группы Unix и его начальник, хотели относиться к разработчикам как к «клиентам», а не как к коллегам, пытающимся выполнить общую инфраструктурную функцию. Клиент всегда был прав, а значит не задавался вопросом, что он делает и почему. Я был единственным, кто настаивал на том, чтобы описать проблему, чтобы найти правильное решение. Не действуйте так, чтобы создать патологическую среду, такую как эта. Это не приводит к чистой выгоде - вместо этого системные менеджеры будут действовать защитно, и каждый пострадает.
Ты больше не в школе. Это системы реального мира, и они не действуют идеальным образом. Например, не все имеют нулевую задержку. Если системный администратор предупреждает вас о том, что кластерные решения предназначены только для политических целей, а дополнительная сложность системы снижает общую надежность, принимайте это всерьез. Вы должны спроектировать режимы реального сбоя, например, если вы потеряете сервер, с которым вы разговариваете через TCP, соединение, вероятно, не будет сброшено для вас. Системные администраторы понимают реальные способы отказа.
Либо послушайте, что говорит вам ваш системный администратор, либо пожаловайтесь руководству, что ваши системные администраторы некомпетентны и должны быть уволены. Игнорировать вашего сисадмина не имеет смысла.
Подумайте, как вы будете развертывать свое приложение. Поймите, что обсуждение этого с вашими сисадминами имеет смысл. Если у вас есть 100 одинаковых серверов, которые различаются только в зависимости от одного файла конфигурации, вы можете рассмотреть возможность хранения главных копий этих файлов конфигурации в центральном расположении. Поймите, насколько лучше для всех, если ваше приложение легко переустанавливать. Если есть проблема с системой, вы бы предпочли перенастроить ее менее чем через минуту на запасную или подождать целую вечность, пока сломанная будет починена? Если вы сможете повторно развернуть свое приложение, операционную систему можно будет обновить проще и безопаснее. Вы можете заботиться об этом в будущем.
Если у вас есть проблема, которая, по вашему мнению, может быть связана с ОС, имеет смысл немедленно вызвать системного администратора, чтобы проверить ее. Но после беглого расследования ничего не выявлено, вы обязаны объяснить проблему.
Поймите, что есть разница между «медленно реагировать» и «вообще не отвечать».