首先，停止编写糟糕的代码

不幸的是，很少有开发人员熟悉MITER Corporation的常见软件问题的Common Weakness Enumeration列表。 CWE是一个引人入胜且有价值的资源，不仅对于软件安全社区，而且对于更广泛的开发社区。 仔细阅读CWE，令人失望地看到软件中有多少常见问题，导致严重安全漏洞的问题以及其他严重问题是由草率的编码引起的：没有遗漏需求，没有弄错设计或弄乱了接口，但简单，基本，愚蠢的构造错误。 CWE充满错误，例如：空指针，缺少初始化，资源泄漏，字符串处理错误，算术错误，违反边界，错误处理错误，启用调试代码以及​​特定于语言和特定于框架的错误和不良做法–理解，不正确地使用框架和API。 好的，还有一些更细微的问题，特别是并发性问题，尽管我们现在应该合理地期望开发人员理解并遵循多线程规则，以避免竞争条件和死锁。

此类问题的解决方案很简单，尽管需要纪律处分：

• 雇用优秀的开发人员，并给他们足够的时间来做好工作，包括时间进行审查和重构。
• 确保开发团队已接受有关基础知识的培训，以确保他们了解语言和框架。
• 定期检查代码（如果需要，可以进行配对编程），以确保准确性和安全性。
• 使用静态分析工具查找常见的编码错误和错误模式。

失败设计

将会发生故障：确保您的设计能够预见并处理故障。 识别故障，包含，重试，恢复，重新启动。 控制故障，确保故障不会级联。 故障保险。 寻找最简单的HA设计替代方案：您是否需要企业范围内的群集或基于虚拟同步的消息传递，还是可以依靠具有快速故障转移功能的更简单的活动/备用阴影？

使用设计审查来找出潜在的故障并寻找降低风险，防止故障或恢复的方法。 微软的《缺陷预防实践指南》虽然有时是学术性的，但它很好地概述了故障模式和后果分析 （FMEA），类似于安全威胁建模的结构化设计审查和风险发现方法，重点是确定潜在的故障原因，然后在解决方案之外进行设计，或降低其风险（影响或可能性）。

康奈尔大学工程学院在其有关产品和服务设计的系统方法的新在线教育计划中，还包括一门有关风险管理和故障模式分析的课程。

把事情简单化

攻击复杂性：在可能的情况下，使用Occam的Razor并在设计，构造或实施中选择最简单的路径。 简化您的技术堆栈，折叠堆栈，最小化层和服务器的数量。

使用静态分析来衡量代码复杂性（循环复杂性或其他）和趋势：代码随着时间的推移变得越来越复杂。 复杂性与质量（和安全性）问题之间存在关联。 识别过于复杂的代码，寻找简化方法，并在短期内增加测试范围。

测试...测试...测试...。

可靠性测试不仅限于单元测试，功能和回归测试，集成，可用性和UAT。 您需要测试所有可以想到或可以承受的一切。

软件可靠性工程 （SRE）背后的一个关键思想是确定产品最重要和最常用的方案，并以尽可能接近实际条件的方式测试系统的使用方式：规模，配置，数据，工作量和使用模式。 这为您提供了更好的机会来发现和解决实际问题。

我们做出的最好的投资之一是构建一个参考测试环境，该环境应尽可能大，并且尽可能接近生产部署配置。 这使我们能够对生产或类似生产的工作负载进行代表性的系统测试，以及可变负载和压力测试，运营模拟和试验。

压力测试尤为重要：确定系统的实际性能极限，将系统推向设计极限，甚至超出设计极限，查找瓶颈和饱和点，并发问题（竞争条件和死锁），以及观察负载情况下系统的故障。 看着系统在极端负载下崩溃，可以让您深入了解体系结构，设计和实现方面的弱点。

对构建可靠软件至关重要的其他类型的测试：

• 回归测试–特别依靠强大的自动化测试安全网来确保可以安全地进行更改。
• 多用户模拟–非结构化或松散的组探索性测试会话。
• 故障处理和故障转移测试–创建受控的故障条件，并检查故障检测和故障处理机制是否正常运行。
• 进行浸泡测试（长时间测试标准工作负载）和加速测试（以实际负载条件的x倍进行测试），以查看中断，更改和泄漏的原因。
• 破坏性测试–从攻击者的角度出发，有目的地着手攻击系统并导致异常和故障。 了解如何破解软件 。
• 模糊测试：对接口的简单，暴力的自动攻击，这是一种对可靠性和安全性很有价值的测试技术。 阅读乔纳森·科尔（Jonathan Kohl） 关于模糊测试的文章 。

与OP一起进入战the

让开发团队，特别是您的高级技术主管，与操作人员紧密合作：了解操作的挑战，他们面临的风险，完成工作所必须采取的步骤。 他们需要什么信息来进行故障排除以调查问题？ 错误消息是否清楚，您是否记录了足够的有用信息？ 启动，关闭，恢复和重新启动有多么容易–步骤越多，问题就越多。 使操作难以出错：添加检查和余额。 一起进行部署，配置和升级：在开发中看似简单的事情在现实世界中可能会遇到问题。

内置运行状况检查–确定系统处于运行状况一致的简单方法，可在启动之前，恢复/重新启动之后，升级之后使用。 确保操作对系统状态，检测，日志，警报具有可见性–确保操作人员知道发生了什么以及为什么。

当您在生产中遇到故障时，与操作团队一起完成“ 根本原因分析” ，这是一种结构化调查，在该调查中，团队将搜索导致故障的直接因素，并定义纠正和预防措施。 深入挖掘，查看过去的直接原因，不断询问原因。 问：这是如何通过您的检查，审查和测试的？ 产品需要改变什么？ 以其发展的方式？ 以哪种方式实施？ 经营了吗

并确保您遵循纠正措施计划。 正确管理的RCA是用于组织学习和改进的强大工具：它迫使您思考，一起工作，从而产生责任感和透明度。

变化是不好的。 但是改变是好的

您无需成为ITIL的专家，但是如果您与开发或支持企业软件有任何关系，请至少花一天时间阅读Visible Ops 。 IT操作管理的简要概述说明了如何获得对操作环境的控制。 关键消息是：

变更管理不善是导致故障的唯一主要原因：80％的IT系统中断是由运营人员或开发人员的不良变更引起的。 恢复时间（MTTR）的80％用于确定更改内容。

结果是：对变更的控制不仅可以提高可靠性，还可以使系统的运行成本更低，更安全。

变更可能是好的：只要变更是渐进的，受控的，精心管理的，并得到良好工具和实践的支持。 当包含变更范围时，更容易动手，查看和测试。 而且，由于经常更换，每个人都知道演习–团队了解问题，并且在遇到任何问题时会更好地做好准备。

实施变更控制和发布管理实践。 包括回退计划，回滚计划和测试。 在设计和实现中考虑兼容性。 创建清单，评论。

安全第一

可靠的软件（例如安全软件）不是免费提供的，尤其是在需要进行更改的情况下，需要添加更多控件的前期。 您必须有管理和客户支持。 您需要改变团队的思维方式：使用风险管理来驱动优先级，确定设计，实施和计划。 让您最好的人了解并作出承诺：其余的将接follow而至。

当然要记住，有限制，需要权衡：我们大多数人不是在为航天飞机构建软件 。 史蒂夫·麦康奈尔（Steve McConnell） 在“最高质量的软件质量”中指出，开发质量更高，更可靠的软件的开发团队实际上交付速度更快，最高效率是在发布产品之前消除95％的缺陷。 但是，当您接近曲线的尽头时，您会到达收益Swift减少的地步，尝试使用100％无缺陷的软件，这会大大增加成本和进度。

定时装箱是一种控制范围和成本的有效技术：在困难的时间内尽力而为。 遵循日本的制造原则，请确保团队中的任何人都可以拉线并推迟发布或取消功能，因为该功能不稳定。

对于开发人员和管理人员来说，缩短质量实践，将功能交付置于可靠性之前，尤其是在压力之下，这是多么的令人震惊，几乎令人恐惧。 确保在整个组织范围内建立支持，建立将可靠性放在首位的文化。 像任何更改一样，这将需要耐心，投入和不懈的后续行动。

• 为什么自动化测试可以提高您的开发速度
• 代码质量对客户很重要。 很多
• 针对用户和新采用者的敏捷软件开发建议
• 使用FindBugs产生更少的错误代码
• 从敏捷开发中省钱
• 生存在荒野西部开发过程中的9条提示
• 每个程序员都应该知道的事情
• 不执行代码审查？ 你的借口是什么