技术项目的极简主义

用最小的成本实践可行性，做最有价值的功能并快速推广

举几个例子，

故障自恢复

由于微服务架构非常复杂，故障快速恢复是业界重点关注的方向即devops。如何做到秒级恢复用户无感知？

对于故障恢复，最直接的方案是重启故障进程微服务，实现功能初始化并快速恢复业务。所以检测进程健康状况的反馈成为重启的关键决策。

那么进程健康状况包括（不限于如下列举的情况）：

• 进程运行状态 - 检测进程状态命令
• tomcat的https异常响应状态码（5XX，如大量TCP连接处于CLOSE_WAIT状态）-访问记录或总线记录
• JVM的OOM - 堆内存信息文件检测
• 线程死锁 - 线程栈死锁检测算法
  如上都给出了可实现的策略，可支撑在未知异常场景下重启进程实现故障快速恢复。

并不是所有的异常都能在设计和编码阶段避免，未知异常还是要以可信可靠及业务零中断为目标，快速识别故障异常并快速恢复，不影响核心业务运行

但上述策略只是基本可行的方案，可快速实践并获得收益，要想实现秒级恢复还需要在方案和细节上结合应用场景持续打磨

故障定界

代码可读性和可扩展性的博弈，用最基础的设计模式写最简洁易懂的代码。但可维护性作为重要指标来衡量代码在应用中的价值收益，代码越好维护，成本就会降低，总体收益就会越大。

可维护性包括两方面，一方面指的是代码的持续演进，另一方面是软件的可维护性，两者相辅相成，代码中后台日志的设计和打印对后期软件的运维有重要影响，日志打印越规范越有利于软件运维。

遇到故障后肯定是要定位原因的，以往都是手工分析日志，云化架构非常复杂，节点多，人工分析日志耗时费力，且重复投入的概率很大，不具备可继承性。

如故障定界多通过搜索日志分析，重复高频故障点可以通过固化的命令组快速排除，证明可行之后进一步扩展为将专家经验结构化（故障树）和工具化，实现可视化界面的故障定界。

效率改进的必经之路：规范流程化 - > 工具化 -> 智能化