作为一名开发人员，我大部分时间都在考虑代码、UI、数据结构等，但是（我勇敢地承认）在部署之前，我不会考虑我的应用程序对系统管理员和 DBA 的影响应用程序。
首先，我很抱歉。其次，您希望我和与您打交道的其他开发人员有什么不同？哪些事情会让您的生活更轻松、减少问题、鼓励合作并减少崩溃、性能问题和配置噩梦？
小智 34
请记住，您的应用程序的状态可能多于 up 或 down。绘制状态图。大多数应用程序都有如下状态：
想想如果系统在每个状态期间崩溃会发生什么。系统管理员将如何监视和控制状态转换？
小智 17
区分“用户”和 SA。
“用户”需要知道如何使用您的软件。用户不关心诸如如何安装软件之类的事情。
SA 并不关心如何使用您的软件，但需要了解有关如何安装软件的一些关键细节。
分别为每个角色编写文档，包括与每个角色相关的信息。
我的愿望之一是在异常和错误代码中包含正确的消息。对于没有开发过应用程序的人来说，这JimmyNotAtHomeException: it's late!意味着什么是完全不透明的。
但是诸如此类的消息Unable to find jimmy - initial manual call_mother procedure非常有帮助。
沟通，沟通，沟通。系统管理员和开发人员之间的每个问题几乎总是可以追溯到缺乏沟通。如果在项目之前系统管理员（或其代表）和开发人员聚在一起并进行了很好的框架讨论，那么很多问题都可以避免。我无法告诉你有多少事情被搞砸了，因为你在一个盒子上开发每个人，只是看着它在生产过程中燃烧起来，因为应用程序然后被分离到应用程序服务器 + 数据库服务器 + 接口服务器等。感谢提出这个话题。
让我们尽早参与项目。像真正的早期一样，处于功能规范阶段。
其他人提到必须在每台 PC 上手动安装，但同样适用于配置和配置更改。如果您选择在客户端存储连接字符串之类的内容，并且需要定期更新它们，我们可能会想要杀死您。
出于同样的原因，选择可以正确集中管理和配置的技术。确保它与我们使用的任何中央管理工具都能很好地集成。
始终使用最小公分母进行测试。这意味着作为非管理员，在最原始的操作系统上，常用的应用程序套件和浏览器平台。我们不喜欢在最后一刻为所有登陆我们的用户进行必需的浏览器升级。
当事情出错时，不要贸然责怪我们。在我以前的工作中，每次应用程序崩溃时，开发人员都会立即指责我们。“你安装了一个新补丁，你不会升级浏览器，你的安全性太强了”或其他什么。这会产生破坏性的气氛。我们真的站在同一边，我们想和你一起解决这个问题，但在那种情况下我们做不到。
不要精英主义。
“别浪费我的时间，伙计。你只是一个狗般的系统管理员；我编写软件，你只是服务它。所以你就闭嘴，按我说的做，好吗？”
一位开发人员实际上曾对我说过这些话（1）。在电子邮件中。抄送给大型通讯组。其含义很明确：作为开发人员，他是整个软件世界的领主和主人；而我只是一个临时工，负责处理他无法浪费宝贵时间的琐碎任务。当然，这几乎是一个最坏的例子，但你知道，我之前和之后都听到过许多开发人员对该评论的强烈和微弱的回应（2）。
你可能比我赚的钱多（但不要假设！）。但是需要一个团队来构建、操作和维护我们的用户所依赖的系统。最终，我们都为他们服务。
我知道你的工作和技能与我的不同。我尊重你的能力。我希望你能回答我的问题，即使它们在你看来很初级和愚蠢。这份礼遇我会很乐意回馈的！
我不是在疯狂的电力旅行，因为有很多糟糕的（或只是漠不关心的）开发人员在各种论坛上说过和思考过。但是我的顾虑和你的不同，我的问题和建议不是为我的自我服务的。事实上，我的工作是让你看起来更好，让你的应用程序处于最佳运行状态，对所有用户都可用和响应。为此，我必须让网络和系统的其余部分也以最佳状态运行。
我完全知道您过去遇到过愚蠢、权力狂和/或只是懒惰的管理员。我试图不成为一个人，也不想看起来像一个人。如果您为这种可能性留出空间，并在您看到它时承认它，那么我很确定您会得到您需要的东西，而那些其他混蛋仍在为他们的系统管理员是个混蛋而生气。
(1) 他还坚持他的程序（一种编写和管理软件需求的工具）需要域管理员权限才能安装和运行。这是一个重大的安全风险。
(2)我也和很多很棒的开发人员一起工作，他们可以在需要的时候教，在需要的时候学习。
尊重系统管理员有工作要做，让他们做他们的工作。许多公司都有不称职的系统管理员，这通常是不现实的。但是我看到傲慢的开发人员即使在系统管理员证明了他们的能力之后也无视系统小组的建议。
与系统管理员讨论新系统的设计。往往有宝贵的见解。开发人员经常查看与系统管理员的讨论并将初始要求视为“过早优化”。我实际上看到一个开发组的负责人说，与系统管理员和 DBA 讨论新数据库服务器的要求是在浪费他的时间，甚至描述它是写入密集型负载还是读取密集型负载，或者需要多少存储空间。
与系统管理员讨论性能问题。老实说，只有系统管理员才能正确解释系统的性能指标。我见过开发人员决定 Linux 总是泄漏内存，因为“free”报告的空闲内存总是减少，即使在第 10 次解释“free”的输出之后也是如此。
不要在没有与系统管理员讨论的情况下得出结论。我见过开发人员陷入诸如“数据库总是磁盘绑定”（他们甚至不知道 iostat 存在）、“RAID 5 对于事务性工作负载更快”（基于对一个被移动的数据库系统的回忆）之类的理论从一个硬件平台到另一个硬件平台——这是一个读取密集型的工作负载，RAID5 解决方案有更多更快的驱动器分布在更多的控制器上。但他们忘记了这些细节，只记得结论。）
不要在未与系统管理员讨论之前设计系统问题的解决方案。我在一个病态的环境中工作，在这种环境中，开发人员会设计一个解决方案，然后要求一些小的实施帮助。Unix 组的成员除了我自己，Unix 组的负责人和他的老板，都希望将开发人员视为“客户”，而不是试图使整体基础设施功能发挥作用的同事。客户永远是对的意味着不要质疑他们在做什么或为什么。我是唯一一个坚持描述问题以便确定正确解决方案的人。不要以创造这种病态环境的方式行事。它不会带来净收益——相反，系统经理会采取防御措施，每个人都会受苦。
你已经不在学校了。这些是现实世界的系统，它们的运行方式并不理想。例如，并非所有东西都具有零延迟。当系统管理员警告您集群解决方案仅用于政治目的，并且系统增加的复杂性降低了整体可靠性时，请认真对待。您必须针对真实世界的故障模式进行设计，例如，当您丢失通过 TCP 与之通信的服务器时，连接可能不会为您重置。系统管理员了解现实世界的故障模式。
要么听听你的系统管理员告诉你的，要么向管理层抱怨你的系统管理员不称职，需要被解雇。忽略您的系统管理员是没有意义的。
考虑您将如何部署您的应用程序。意识到与您的系统管理员讨论这个问题是有道理的。如果您有 100 台相同的服务器，仅基于单个配置文件不同，您可能需要考虑将这些配置文件的主副本存储在一个中央位置。意识到如果您的应用程序易于重新部署，那么每个人都会变得更好。如果系统出现问题，您愿意在一分钟内重新部署到备用系统，还是等待很长时间修复损坏的系统？如果您可以重新部署您的应用程序，则可以更轻松、更安全地升级操作系统。将来你可能会关心这个。
如果您认为某个问题可能是由操作系统引起的，立即致电系统管理员进行检查是有意义的。但是在粗略的调查没有发现任何问题之后，您有责任解释问题。
了解“响应缓慢”和“根本没有响应”之间存在差异。