1、 新版本向下兼容
应用系统升级方案中必须考虑向下兼容能力；无法完全向下兼容的应用升级过程，在联调、预发布及正式上线过程中会引起已有业务服务的不可用应用系统向下兼容的评估点包括但不仅限于：接口、方法、入参、返回值及服务方法等。
2、 应用发布前×××能报告
新应用系统上线，或经过重大改造的应用系统在正式发布前，需要在线下环境进行的性能测试，并提供一个完整的性能报告。对于在性能报告的可疑点，要逐项排除后才能发布上线。
性能报告要包含应用系统改造前后在同等业务压力下（QPS/TPS）的性能表现，包含但不仅限于系统的Load高峰、内存/CPU使用率、Full GC次数及时长、接口/页面相应时间、网络流量、磁盘IO等。对于新上系统，可横向比较类似系统的相关参数表现。对于性能测试，必须要找到 “性能拐点”并提供完整的数据。简单的说，在上线之前要清楚这个应用系统在多大的压力之下会引发“雪崩效应”，即应用性能表现过了临界点后急剧下降。
3、 采用统一框架及技术
尽量利用公司（集团）已有的统一框架和技术，这一点对于一些新同学，容易受“锤子理论”的影响，因为对某一软件的熟悉（原来公司用的或开源社区的），相对于现在公司已有的框架/技术的复杂性（不熟悉），而考虑引入使用前者；而这样做实际上在后期的运维以及技术持续更新方面会带来很大的问题。如果同一种框架或技术，在公司（集团）目前已有好几个，这时要与框架或技术的主要负责人沟通清楚，了解今后的发展方向（也许其中一种技术已内部确认将会逐步淘汰），然后选定一种今后比较长时间内会持续发展的框架/技术。
4、 启动时间及启动依赖的控制
应用系统的启动时间要控制在一个比较合理的时间，如JAVA应用要求120秒之内甚至更短完成启动并开放服务；启动时间过长不仅影响日常工作效率，而且延缓故障处理时间，甚至导致故障处理过程中的一些误判。
应用系统的启动，不应该依赖于外部的环境，包括但不仅限于外部网站监测、特定的网络配置、其他应用系统等等。
5、 WEB前台可查看对应机器
所有用户可以接触到的WEB页面，需要在底部模板上保留白色文字显示的机器名与时间戳、版本号，以方便故障时问题定位和排查。
6、 支持CMS公告管理
所有用户可以接触到的WEB页面，需要在头部支持CMS系统中公告内容管理功能。在需要的时候，我们会发布相关公告可以更新在相关页面头部位置。同时，要求该页面的正常显示不依赖于CMS系统。
7、 充分利用缓存及CDN技术
应用系统在设计阶段，结合实际的业务模型，将数据访问热点采用缓存技术实现，将静态内容（静态图片、CSS、JS等）采用CDN技术实现。充分且合理的利用缓存及CDN技术，能让应用系统更加从容的应对业务突增的要求。
8、 规范的日志及可监控性
一方面根据现有的研发日志规范来输出格式合理的必要日志，同时要从业务的角度或故障排查的角度出发要求日志的可读性强。特别提醒的是日志详尽程度的控制重要性，因为应用监控（业务监控）都是基于这些输出日志进行实时（准实时）的分析，过于详尽的日志信息对于应用监控的处理能力会带来很大的压力。
9、 兼容现有的基础资源体系
对于任何基础技术和系统软件升级，如WEB服务、中间件、消息中心，缓存系统、文件系统、虚拟机、操作系统等，原则上不应该影响使用其的应用服务，所有应用系统必须考虑兼容现有的基础软件和基础资源体系。
10、 设计时就考虑扩展性
应用系统设计时，根据DID（Design-Implement-Deployment）规则，明确的可扩展性目标。在传统行业，一般情况按实际需求容量的10倍设计，3倍实现，1.5倍部署。而在互联网公司，可参考100倍设计，10倍实现，3倍部署的规模来实施。具体情况可有所调整，但设计初期就要考虑可扩展性。
11、 外部交互通过网关
主站统一规划几个对外交互的网关，网关系统在防止恶意访问、外界安全接入、对外容量及性能SLA保障、接口参数规范等方面重点审核并保障。外部交互的网关开设公网地址，其他合作方及BU的系统交互也通过公网来进行访问。不能绕过既定的网关，而直接开设ACL进行系统间的互通访问。
12、 幂等性控制
所有应用系统在设计和实现时，都必须包含幂等性控制要求，并在单元测试阶段通过白盒测试验证。幂等性控制包括但不限于：用户重复提交，网络层报文重发，消息中心消息重发，调度中心多次调度，第三方合作机构报文重发等场景。
13、 故障隔离和服务降级
故障隔离和服务降级的目的是以牺牲部分业务功能或者牺牲部分客户业务为代价，保障更关键的业务或客户群体服务质量。故障隔离和服务降级是应用系统调用其他系统出现系统/组件故障后，对有故障的系统/组件进行隔离或自身服务进行降级，防止故障的蔓延。
在故障隔离和服务降级设计时，需要梳理应用系统所调用（依赖）的各个组件，做各种“假设场景分析”并设定应对策略。故障隔离和服务降级，可以是人工触发的，也可以由系统做事中自动判定和自动执行。
14、 访问控制
应用系统在提供服务调用的时候，必须给出本系统服务的访问控制策略，如最大的访问能力、服务响应时长，以及超过该服务能力时的处理策略。调用方可根据上下游应用系统的访问控制策略做好自己的故障隔离和服务降级措施。
15、 内部调用采用异步方式
众所周知，多个应用系统串联在一起的同步调用对性能、容量、可靠性都是极大的风险。当调用链条中的任意一环出现故障或缓慢，都会造成上下游其他系统处理缓慢（每一环存在大量的线程等待）或者处理失败。而内部调用采用异步方式，相当于上下游系统之间都进行了缓冲。有效控制了单机故障的影响，以及单个应用处理缓慢的连锁反应。
16、 避免硬编码
各种硬编码出现在代码里，导致后续变更的业务影响难以评估到位，进而引发故障不在少数。硬编码包括但不限于：IP地址、主机设备名称、带机房信息的应用域名等等。对于一些特别的安全要求，如与银行系统的互联，要求以IP白名单的方式而不能信任域名访问，可将该IP放置在配置文件中，而非写到编译的代码之中。
17、 系统分级和治理
当某个应用系统发生故障时，根据业务重要程度和业务影响面这2个维度进行组合的4种情况对应用系统进行分级。不同等级的应用系统实施不同运维策略，如线下测试策略、应用发布策略、容量管理策略、监控报警策略、服务降级策略等。
18、 主动的健康检查
随着生产系统规模的变大，单台应用系统因各种问题导致既定的服务异常变得司空见惯。主动健康检查的意义在于用户发现之前（或在发生异常后的极端时间之内）将异常的单台应用系统剔除所在的集群，保障整体的可用性和良好的用户体验。主动健康检查不仅仅是网络层（4层）的检查，重点还在于应用层（7层）的检查，检查方法可通过负载均衡设备、应用框架模块等。值得提醒的是主动健康检查的的判定和剔除算法，非常有讲究，稍微有点不合理都有可能导致检查失效或应用集群雪崩效应的发生。
原文链接：https://www.sohu.com/a/200349166_487482