作为一名开发人员，我大部分时间都在思考代码，用户界面，数据结构等等，但是（我勇敢地承认）我不倾向于考虑我的应用程序对系统pipe理员和数据库pipe理员的影响，直到部署该应用程序。
首先，我很抱歉。 其次，你希望我和其他开发者打交道的方式有什么不同？ 什么事情会让你的生活更轻松，减less问题，鼓励合作，减less崩溃，性能问题和configuration噩梦？
请记住，您的应用程序可能具有比上或下更多的状态。 画一张状态图。 大多数应用程序具有类似于
想想如果在每个状态下系统崩溃会发生什么。 系统pipe理员将如何监视和控制状态转换？
区分“用户”与SA。
“用户”需要知道如何使用您的软件。 用户不关心如何安装软件。
SA不关心如何使用您的软件，但需要知道一些关于如何安装软件的关键细节。
为每个angular色分别编写文档，包括每个angular色的相关信息。
我的愿望之一是在exception和错误代码中包含正确的消息。 对于没有开发应用程序的人来说，这是完全不透明的JimmyNotAtHomeException: it's late! 手段。
但是一个消息，如Unable to find jimmy - initial manual call_mother procedure是非常有帮助的。
沟通，沟通，沟通。 系统pipe理员和开发人员之间的每一个问题几乎都可以追溯到缺乏沟通。 如果在项目开始之前，系统pipe理员（或其代表）和开发者聚在一起并进行了很好的框架讨论，那么可以避免许多问题。 我不能告诉你有多less事情被搞砸了，因为你在开发的一个盒子里开发每一个人，只是看着它在火中熄灭，因为应用程序然后被分离到应用服务器+数据库服务器+接口服务器等。为了使这个话题成为可能
在项目早期就介入我们。 早在function规格阶段就像真正的真实一样。
其他人提到必须在每台PC上手动安装，但同样适用于configuration和configuration更改。 如果你select存储连接string客户端，并需要定期更新它们， 我们可能会想杀了你 。
select可以正确集中pipe理和configuration的技术，基于同样的原因。 确保它与我们使用的任何中央pipe理工具完美集成。
请始终使用最低公分母进行testing。 这意味着作为一个非pipe理员，在最原始的操作系统上，常用的应用程序套件和浏览器平台。 我们不喜欢为所有用户提供所需的浏览器升级在最后一刻降落在我们身上。
当事情出错的时候别怪我们。 在我以前的工作中，每次应用程序崩溃时，开发人员都会立即指责我们。 “你安装了一个新的补丁，你不会升级浏览器，你的安全太紧了”或其他什么。 这产生了破坏性的气氛。 我们真的是在同一方面，我们想和你一起解决，但是我们不能在这种情况下。
不要成为精英主义者。
“不要浪费我的时间，哥们，你只是一个dogbody系统pipe理员， 我写这个软件， 你只是提供服务，所以只需要关心你的小问题，照我说的行事，好吗？
一位开发者实际上曾经对我说过这些话（1）。 在电子邮件。 抄送给一个大型分销集团。 其含义是明确的：作为开发者，他是整个软件世界的主人和主人; 而我只不过是一个被雇用的日工，他所处理的任务太微不足道了，以至于浪费宝贵的时间。 当然，这是一个几乎是最糟糕的例子，但是你知道，在（2）之前和之后，我都听到过许多开发者对这个评论的回应。
你可能比我赚更多的钱（但不要假设！）。 但是需要一个团队来构build，操作和维护我们用户所依赖的系统。 最终我们都为他们服务。
我知道你的工作和你的技能不同于我的。 我尊重你的能力。 我希望你能回答我的问题，即使他们看起来对你来说基本愚蠢。 我会高兴地回到这个礼节！
我不是疯狂的权力之旅，因为许多不好的（或者根本不在意的）开发者曾经在各种论坛上发表过言论和想法。 但是我的担忧与你们的不同，我的问题和build议并没有为我的自我服务。 事实上，我的工作就是让您的应用程序处于最佳运行状态，让所有用户都可以使用，并让您看起来更好。 要做到这一点，我必须保持networking和系统的其他部分也以最佳状态运行。
我完全意识到，过去你已经陷入了愚蠢，疯狂，和/或简单的懒惰的pipe理员。 我不想成为一个人，而不是看起来像一个。 如果你留下这个可能性的空间，并且在看到它的时候承认它，我敢肯定你会得到你需要的东西，而其他的混蛋们仍然在为他们的系统pipe理员混淆不清。
（1）他还坚持说，他的程序（用于编写和pipe理软件需求的工具）需要域pipe理员权限来安装和运行。 这是一个重大的安全风险。
（2）我也曾经和很多很棒的开发人员一起工作，他们可以在必要时进行教学，并在必要时进行学习。
尊重系统pipe理员有工作要做，让他们做好工作。 很多公司有无能的系统pipe理员，这往往是不现实的。 但是，即使在系统pipe理员已经certificate他们的能力之后，我也看到傲慢的开发者忽视了系统组的build议。
用系统pipe理员讨论一个新系统的devise。 往往有宝贵的见解。 开发人员通常会与系统pipe理员进行讨论，并提出最初的要求作为“不成熟的优化”。 实际上，我看到一个开发小组的负责人说，用系统pipe理员和数据库pipe理员讨论对新的数据库服务器的需求，甚至是描述是写入密集型还是读取密集型负载，需要多less存储空间。
与系统pipe理员讨论性能问题。 老实说，只有系统pipe理员能够正确地解释系统的性能指标。 我曾经看到开发者决定Linux总是泄漏内存，因为“free”报告的空闲内存总是减less，即使在第10次输出“free”之后也是如此。
不要在没有与系统pipe理员讨论的情况下得出结论。 我曾经看到开发人员被卡在“数据库总是磁盘绑定”（他们不知道iostat甚至存在）这样的理论上，“RAID5对于事务性工作负载更快”（基于对被移动的一个数据库系统的回忆从一个硬件平台到另一个硬件平台 – 这是一个读取密集型工作负载，RAID5解决scheme有更多更快的驱动器分布在更多的控制器上，但他们忘记了这些细节，只记得结论。
不要与系统pipe理员讨论系统问题的解决scheme。 我曾经在一个病态的环境中工作，开发人员会devise一个解决scheme，并寻求小的实施帮助。 除了我自己，Unix团队负责人和他的老板之外，Unix团队的成员都希望把开发者当作“客户”，而不是把同事当作一个整体的基础设施function。 客户永远是对的意思是不要质疑他们在做什么或为什么。 我是唯一一个坚持要解决问题的人，才能确定正确的解决办法。 不要以创造这样的病理环境的方式行事。 这不会带来净效益 – 相反，系统pipe理员将采取防御行动，每个人都会受到影响。
你不在学校了 这些是现实世界的系统，它们不以理想的方式行事。 例如，并非所有东西都有零延迟。 当系统pipe理员警告说，聚类解决scheme只是出于政治目的，系统的复杂性降低整体可靠性时，要认真对待。 您必须devise真实的故障模式，例如，当您通过TCP丢失与之通话的服务器时，连接可能不会被重置。 系统pipe理员了解真实世界的故障模式。
要么听你的系统pipe理员告诉你什么，要么向pipe理层抱怨你的系统pipe理员是无能的，需要被解雇。 忽略你的系统pipe理员是没有意义的。
考虑你将如何部署你的应用程序。 意识到与你的系统pipe理员讨论这个问题是有道理的。 如果有100台相同的服务器，只有一个configuration文件不同，则可能需要考虑将这些configuration文件的主副本存储在中央位置。 如果您的应用程序易于重新部署，则意识到每个人都有多好。 如果一个系统出现问题，你宁愿在一分钟之内重新部署一个备用，或等待几年，而破损的修复？ 如果您可以重新部署应用程序，则可以更轻松，更安全地升级操作系统。 你将来可能会关心这个。
如果你有一个问题，你认为可能是由于操作系统，这是有道理的立即调用系统pipe理员检查出来。 但是粗略的调查没有任何结果，你有责任解释这个问题。
了解“慢慢回应”和“完全不回应”是有区别的。
以可预测的方式configuration和布局，并以可预测的方式更改您正在开发的操作系统（en）。 这意味着一切。 例如：OpenLDAP有一个奇怪的方式做日志级别; 某些IMAP服务器甚至没有configuration文件，但必须具有编译的选项; 一些软件包希望他们的东西在一个特定的目录path，这不可避免地会打破特定操作系统的约定。 这些东西在我平常的configuration中都像疣一样突出。
这是一个通用的规则，但不要以为你是特殊的，因此有幸打破软件包通常在你的平台上工作的一般惯例，除非你的软件有一个固有的充分理由需要它。 “我强烈地感到这应该是这样”不足以打破每个人的平常设置; 它必须成为你的软件试图执行的function的一个原因。
当应用程序涉及服务器间通信时，请在devise阶段至less包含一个系统pipe理员。 此外，明确的文件依赖于其他服务：SQL，SMTP，HTTP等…不要让我们猜你在做什么，或者我们无法帮助你，当有什么不像你所期望的。
请以自动化的方式将您的软件部署到数十个或数百个系统上。 如果一个组织需要一个软件包，系统pipe理员几乎肯定没有时间在每个盒子上手动安装它。 如果一个文件需要有许可信息，logging如何提供它将是一个很大的好处。
Adobe一直以来都有一些与之合作的安装人员 ， 请高于这个目标！
从第一天开始考虑扩展。 系统pipe理员可以通过在性能问题上投掷金钱/硬件来创造奇迹，但是有时候这些都不会有帮助 – 尤其是考虑locking – 有时候你不能自己摆脱locking问题。 感谢您的询问:)
哦，尽可能地尝试64位，multithreading:)
运营devise。
除了这里的一切…
虽然不切实际，但如果开发人员被迫在生产系统pipe理员或数据库pipe理员angular色中工作，然后再放到世界上，这将是有帮助的。
我处理的很多专门的应用程序都不知道在托pipe环境中安装，还是犯下数据库devise的暴行。
1）详细logging错误的日志文件。 或像ELMAH一样的错误跟踪系统。
2）安装，实施和SA指南的详细文档。
3）加上上面提到的其他惊人的SA。 🙂
这就是我现在所能想到的。
这本书释放它！ 有一个很好的select恐怖故事在生产中可能出错。 阅读它可以为devise和操作提供灵感/想法。 （这是由Michael Nygard撰写的，他曾在开发和运营方面工作过。）
根据我的经验，最大的不同之处在于开发人员会从第1天开始考虑部署。只要在生产/客户环境中开始构思新function，就要考虑如何将其部署到环境，以及如何运行。
一旦进入发展过程，现在还不算太迟，但是他们可以花费一些时间才能把视angular转移到很远的地步; 他们并没有意识到他们是如何抽象地查看代码库，直到被迫与之对抗。 在他们的心目中，这只是一个“组件”。 特别感兴趣的是如何将其部署到预先存在的环境中，运行软件的以前版本（或旧版本）。 部署讨论可能会对体系结构如何调整以适应新function产生重大影响。
我还没有看到的东西是可configuration的。 如果您有一个使用任何configuration文件的应用程序，使一切都可configuration。
在我的公司，我写了一个简单的应用程序，可以导出一个输出数据库。 下一个星期我正在改写它，以允许一小部分被closures。 从那以后，我每个星期都不得不重写部分，重build它只是为了改变一个小的特性。 我只是几乎没有添加一个XMLconfiguration文件，现在更容易重新部署。
我喜欢configuration文件。
我希望开发人员能够更好地与质量保证任务分离。 我认为当开发人员能够为他/她正在开发的项目创build一些unit testing用例时，它是非常好的，但如果这些testing被传递给QA，那将会很好。 事实上，当开发人员对QA工程师给予一点帮助时，它是非常好的，因为它最终有益于DEV。
确保它是可支持的：除了这里提到的所有其他的东西，看看这个post在SO – https://stackoverflow.com/questions/205374/what-are-the-core-elements-to-include-in-support-文档/