Answers:
请记住，您的应用程序可能具有比启动或关闭更多的状态。画一个状态图。大多数应用程序的状态如下：
想一想如果系统在每个状态下崩溃都会发生什么。系统管理员将如何监视和控制状态转换？
从SA区分“用户”。
“用户”需要知道如何使用您的软件。用户不在乎诸如如何安装软件之类的东西。
SA不在乎如何使用您的软件，但需要了解有关如何安装软件的一些关键详细信息。
为每个角色分别编写文档，包括与每个角色相关的信息。
让我们尽早参与该项目。就像真实的真实早期一样，在功能规格阶段。
其他人提到必须在每台PC上手动安装，但是同样适用于config和config更改。如果您选择在客户端存储诸如连接字符串之类的内容，并且需要定期更新它们，我们可能会想要杀死您。
出于同样的原因，选择可以适当地集中管理和配置的技术。确保它与我们使用的任何中央管理工具良好集成。
始终使用最低公分母进行测试。这意味着作为非管理员，在最原始的操作系统上，通常会使用应用程序套件和浏览器平台。我们不希望在最后一刻让所有用户都需要升级浏览器。
事情出了问题时不要责怪我们。在我以前的工作中，每当一个应用程序崩溃时，开发人员都会立即将矛头指向我们。“您安装了新补丁，不会升级浏览器，安全性太严格了”或其他。这产生了破坏性的气氛。的确，我们站在同一边，我们希望与您一起修复它，但在这种情况下我们不能这样做。
不要成为精英。
“别浪费我的时间，伙计。你只是一个笨拙的系统管理员；我写的是软件，而你只是为它服务。
开发人员实际上曾经对我说过这些话（1）。在电子邮件中。CC到一个大型通讯组。含义很明显：作为一名开发人员，他是整个软件领域的主人和主人。而我只是一个临时工，被雇用来处理琐碎的工作，以至于他无法浪费自己的宝贵时间。当然，这是一个几乎最坏的例子，但是您知道，在（2）之前和之后，我听到过许多开发人员对此种评论的强烈和微弱的回响。
您可能比我赚更多钱（但不要以为然！）。但是需要一个团队来构建，操作和维护我们用户依赖的系统。最终，我们都为他们服务。
我知道您的工作和技能与我的不同。我尊重你的能力。我希望您即使在您看来基本而又愚蠢的时候也能回答我的问题。我会很乐意回报这个礼貌！
我并没有疯狂地旅行，因为许多坏的（或干脆不关心的）开发人员已经在各种论坛上发表了自己的看法和思想。但是我的担忧与您的有所不同，我的问题和建议也无助于我的自我。确实，我的工作是通过使应用程序始终处于最佳运行状态，可用并响应所有用户的方式来使您看起来更好。为此，我必须使其余的网络和系统也保持最佳状态。
我完全知道您过去曾经遇到过愚蠢，权力疯狂和/或只是普通的懒惰管理员。我试图不成为一个，也不像一个。如果您为这种可能性留出空间，并在看到它时确认它，那么我可以肯定，您会得到所需的东西，而其他混蛋仍然对他们的系统管理员是个混蛋感到困惑。
（1）他还坚持认为他的程序（一种用于编写和管理软件需求的工具）需要具有域管理员权限才能安装和运行。这是主要的安全风险。
（2）我还与许多出色的开发人员合作，他们可以在必要时教书，并在必要时学习。
尊重系统管理员的工作，让他们完成工作。许多公司的系统管理员都不称职，这通常是不现实的。但是我已经看到，即使系统管理员已经证明了他们的能力，傲慢的开发人员也会忽略系统组的建议。
与sysadmins讨论新系统的设计。通常会有宝贵的见解。开发人员经常查看与系统管理员的讨论，并以“过早优化”作为初始要求。我实际上看到一个开发小组的负责人说，浪费他的时间与sysadmin和DBA一起讨论对新数据库服务器的要求，甚至描述它是写密集型负载还是读密集型负载，或者需要多少存储空间。
与系统管理员讨论性能问题。老实说，只有系统管理员才能正确解释系统上的性能指标。我已经看到开发人员认为Linux总是会泄漏内存，因为“ free”报告的可用内存总是会减少，即使在解释了“ free”的输出的第10次之后。
不与系统管理员讨论就不要下结论。我已经看到开发人员陷入了诸如“数据库总是磁盘绑定”（他们甚至不知道iostat）之类的理论，“ RAID 5对于事务性工作负载而言更快”（基于对移动的一个数据库系统的回忆）从一个硬件平台到另一个硬件平台-这是一个读取密集型工作负载，RAID5解决方案在更多控制器上分布了越来越多的驱动器。但是他们忘记了这些细节，只记得结论了。）
在没有与系统管理员讨论的情况下，请不要为系统问题设计解决方案。我在一个病态的环境中工作，开发人员将设计一个解决方案，并要求提供小的实施帮助。Unix小组的负责人和我自己之外的Unix小组的成员以及他的老板，都希望将开发人员视为“客户”，而不是试图使整体基础架构功能正常发挥作用的同事。客户永远是对的，这意味着不质疑他们在做什么或为什么做。我是唯一坚持要描述问题以便能够确定正确解决方案的人。不要以会造成这种病理环境的方式行事。这并不会带来净收益-相反，系统经理将采取防御行动，所有人都会受苦。
你再也不上学了 这些是现实世界的系统，它们无法以理想的方式运行。例如，并非所有内容都具有零延迟。当系统管理员警告您群集解决方案仅出于政治目的，并且系统增加的复杂性降低了整体可靠性时，请认真对待。您必须针对实际的故障模式进行设计，例如，当您丢失要通过TCP与之通信的服务器时，该连接可能不会为您重置。系统管理员了解实际的故障模式。
听您的系统管理员告诉您的内容，或者向管理层投诉您的系统管理员不称职，需要被解雇。忽略系统管理员没有任何意义。
考虑如何部署应用程序。意识到与您的系统管理员进行讨论是有意义的。如果您有100台相同但仅基于单个配置文件而不同的服务器，则可能需要考虑将这些配置文件的主副本存储在中央位置。如果您的应用程序易于重新部署，请认识到每个人的情况要好得多。如果系统出现问题，您是希望在一分钟内将其重新部署为备用设备，还是等待一段时间才能修复损坏的系统？如果您可以重新部署应用程序，则可以更轻松，安全地升级操作系统。您将来可能会在意。
如果您认为可能是操作系统引起的问题，请立即致电sysadmin以进行检查。但是，经过粗略的调查没有发现任何问题之后，您有责任解释该问题。
了解“响应缓慢”和“根本不响应”之间存在区别。
当应用程序涉及服务器间通信时，请在设计阶段至少包括一名sysadmin。另外，清楚地记录对其他服务的依赖关系：SQL，SMTP，HTTP等...不要让我们猜测您的工作，或者当某些事情无法按预期工作时我们无法为您提供帮助。
除了这里的其他一切...
以我的经验，最大的影响是开发人员从第一天开始就考虑部署。一旦您开始在生产/客户环境中构思新功能，就开始考虑如何将其部署到生产/客户环境中。环境及其运行方式。
一旦他们进入开发过程，还不算太晚，但是可能需要一些时间才能将观点转移到这么远。他们直到意识到被迫面对代码库时才意识到自己查看代码库的抽象程度。在他们看来，这只是一个“组成部分”。特别令人感兴趣的是如何将其部署到先前存在的环境中，并运行该软件的先前（或更旧的！）版本。部署讨论可能会对如何调整体系结构以适应新功能产生重大影响。
确保它是可支持的：除了这里提到的所有其他内容外，请查看SO上的这篇文章-https: //stackoverflow.com/questions/205374/what-are-the-core-elements-to-include-in-support-文档/