Respete que los administradores de sistemas tienen un trabajo que hacer y déjelos hacer su trabajo. Muchas empresas tienen administradores de sistemas incompetentes y esto a menudo no es realista. Pero he visto a desarrolladores arrogantes ignorar los consejos de los grupos de sistemas incluso después de que los administradores de sistemas hayan demostrado su competencia.
Discuta el diseño de un nuevo sistema con los administradores de sistemas. A menudo hay información valiosa. Los desarrolladores a menudo miran las discusiones con los administradores de sistemas y dan los requisitos iniciales como "optimización prematura". De hecho, vi al jefe de un grupo de desarrollo decir que era una pérdida de tiempo discutir los requisitos para los nuevos servidores de bases de datos con administradores de sistemas y DBA, incluso hasta el punto de describir si se trata de una carga intensiva de escritura o lectura, o cuánto almacenamiento se necesitaría.
Discuta los problemas de rendimiento con los administradores de sistemas. Honestamente, solo los administradores de sistemas son capaces de interpretar adecuadamente las métricas de rendimiento en los sistemas. He visto a los desarrolladores decidir que Linux siempre pierde memoria porque la memoria libre informada por "libre" siempre disminuye, incluso después de la décima vez que se explica la salida de "libre".
No saque conclusiones sin discutirlo con los administradores de sistemas. He visto a los desarrolladores atascarse en teorías como "las bases de datos siempre están vinculadas al disco" (no sabían que incluso existía iostat), "RAID 5 es más rápido para las cargas de trabajo transaccionales" (basado en una recolección de un sistema de base de datos que se movió de una plataforma de hardware a otra: era una carga de trabajo de lectura intensiva, la solución RAID5 tenía unidades más y más rápidas distribuidas en más controladores. Pero olvidaron estos detalles y solo recordaron la conclusión).
No diseñe una solución a un problema de sistemas sin discutirlo con los administradores de sistemas. Trabajé en un entorno patológico donde los desarrolladores diseñarían una solución y vendrían pidiendo asistencia para la implementación. Los miembros del grupo Unix además de mí, el jefe del grupo Unix y su jefe, querían tratar a los desarrolladores como "clientes", no como compañeros de trabajo que intentan hacer que una infraestructura en general funcione. El hecho de que el cliente siempre tuviera razón significaba no cuestionar lo que estaban haciendo o por qué. Yo era el único que insistiría en que se describiera el problema para poder determinar una solución correcta. No actúes de manera que cree entornos patológicos como este. No genera un beneficio neto; en cambio, los administradores de sistemas actuarán a la defensiva y todos sufrirán.
Ya no estás en la escuela. Estos son sistemas del mundo real y no actúan de manera ideal. Por ejemplo, no todo tiene latencia cero. Cuando un administrador de sistemas le advierte que las soluciones de agrupamiento son solo para fines políticos, y la complejidad adicional del sistema disminuye la confiabilidad general, tómelo en serio. Debe diseñar para los modos de falla del mundo real, por ejemplo, cuando pierde el servidor con el que está hablando a través de TCP, la conexión probablemente no se restablecerá. Los administradores de sistemas entienden los modos de falla del mundo real.
Escuche lo que le dice su administrador de sistemas o reclame ante la gerencia que sus administradores de sistemas son incompetentes y deben ser despedidos. Ignorar a su administrador de sistemas no tiene sentido.
Considere cómo desplegará su aplicación. Tenga en cuenta que discutir esto con sus administradores de sistemas tiene sentido. Si tiene 100 servidores idénticos, que difieren solo en un único archivo de configuración, puede considerar almacenar las copias maestras de estos archivos de configuración en una ubicación central. Date cuenta de lo mejor que está todo el mundo si tu aplicación es fácil de volver a implementar. Si hay un problema con un sistema, ¿preferiría volver a implementarlo en menos de un minuto, o esperar durante años mientras se repara el roto? Si puede volver a implementar su aplicación, el sistema operativo puede actualizarse de manera más fácil y segura. Puede que te importe esto en el futuro.
Si tiene un problema que cree que podría deberse al sistema operativo, tiene sentido llamar de inmediato al administrador del sistema para verificarlo. Pero después de que una investigación superficial no revela nada, tiene el deber de explicar el problema.
Comprenda que hay una diferencia entre "responder lentamente" y "no responder en absoluto".