架构设计从这 5 点考虑，能帮后期运维很大忙！

[neteaseim]

1.良好的系统架构是顺利开展运维工作的前提

在做系统架构设计时需要充分考虑功能模块的耦合性，尽量做到业务功能的独立解耦，降低互相之间的依赖；最差的情况就是所有的服务功能集中在一个进程中，一个挂，全部挂，一个升级全部受影响，这种系统设计对运维工作来说就是灾难；做好功能模块的划分和隔离，可以降低故障的影响范围，在升级等日常运维工作中也可以做更好的规划；

2.架构设计时将 HA 作为必须满足的非功能性指标

任何一个系统都会存在故障的可能，程序猿写的代码即时再好也有出 bug 的时候，即时程序不出 bug ，也还是逃不过机器宕机后者断电断网等各种意外情况的发生；所以设计者需要善于找到系统中存在的单点，并解决这些单点；高可用的特性并不是说要求程序一定不能挂，而是说从架构上允许故障的发生，任何一个节点的故障只能影响系统的整体处理性能，但是不会造成业务不可用；具体来说，如果是 Web 类的应用，可以使用 Nginx 等反向代理工具来搭建多个后端的业务集群，并在出口上做 Keepalived 等高可用的方案，对于一般的应用，设计时需要保证多实例可同时服务，多实例功能相互对等，任何一个实例的停服，其业务请求可以被其他实例来分担；做好了 HA 架构，我们在运维工作时才能更加从容，因为当运维报警发生时，我们知道当前业务处理能力虽然下降了，但是整个业务并不是不可用的状态，对用户来说不会产生直接的影响，运维人员可以从容得恢复故障节点即可；同时良好的 HA 架构也有助于业务扩张时的增强系统扩展性；

3.业务系统给运维系统提供更加友好的接口

运维平台的一个重要工作是从业务系统中提取到准确的指标，并针对这些指标来做线上的监控和预警；更加了解业务系统的还是开发人员，而非运维人员，所以开发人员需要在设计功能时同时兼顾到运维的需求，充分设计哪些指标需要被暴露出来，常见的比如当前系统的 TPS(每秒的处理能力)， MRT(平均响应时间），系统的能力上限等，再结合如 JVM 内存使用情况， GC 情况等基础数据，运维平台就能做出更加合理的监控支持，有了这些监控数据之后再制定更加科学的预警，可以在故障实际发生之前就做出预警（比如 TPS 达到系统容量的 80%了），让运维人员提前做出扩容等应对，而不是等到功能不可用了才报警；从技术实现上来说，业务系统向外暴露接口的方式就非常多了，比如 JAVA 程序可以通过 JMX 来实现，通用的进程可以使用隐藏的 Http 接口等方式来实现；如果运维平台使用的是 Ganglia 等开源平台，也可以使用对应的客户端 Agent 来向运维平台暴露数据；

4.规范的日志输出

很多开发者在实现业务系统的时候往往会忽略日志的作用，或者只把日志当做偶尔查查问问的工具，日志的输出内容往往是只有人来读取的非格式化内容；其实除了定位问题之外，日志还可以帮助我们做更多的事情，我们可以设计一个程序友好的日志格式，比如输出 JSON 格式的日志来记录每个业务请求的执行情况，如请求参数，处理时间和响应码，失败信息等；有了规范的日志之后，可以通过脚本的方式将日志中的信息提取成指标输入到运维平台中，可以对业务系统当前处理的成功率，响应时间等做更加细粒度监控和报警；

5.善于利用功能测试框架

很多公司对开发人员的代码质量要求都很高，会要求在 QA 测试之前做到单元测试等工作，有些 QA 部门也会利用一些标准化的工具对线上流程做回归测试，比如 Junit 或者 TestNG 等；其实我们也可以充分利用这些资源来做线上的运维监控；我们退一万步来说，如果一个系统没有任何运维预警，那么如果线上发现问题的会是谁？这一定是用户，那么能不能有一个机器人用户来帮我们提前发现问题呢？这里我们就可以利用功能测试的成果了，将用作线上回归的 TestNG 代码用程序自动化的方式定期执行起来，并解析执行的结果，如果回归测试失败就立刻发报警出来，这种看起来很土的方法在实际操作中

[isCyan]

1. 节点发错了
2. 此图片来自微信公众平台