生产环境出了问题该怎么办？

每一位研发工程师的职业生涯中或多或少都可能遇到生产环境出了一些问题这样的场景，面对这些问题，有的问题出现一次以后，就再也没有出现过了，有的问题总是不断再出现，前者认真对待每一次生产环境可能的事故，后者比较随意，在职业生涯中两者我均经历过，认真对待每一次事故，坚决避免事故的发生的可能性，态度是可取的；遇到故障，想尽办法排除，排除以后，就不管了，这样的态度是不可取的，同样对于自己而言，也会因此错失一次成长的机会。研发工程师的竞争优势不在于会多少门编程语言以及一个人是多么的全能，而在于如何高效的解决问题以及最大程度避免类似问题的出现。编程语言的学习或者是各式各样框架的掌握，一定的时间就能学会，更何况，编程语言以及框架的共通之处。但适用于个人以及团队的高效解决问题套路以及事后复盘方法论就不那么容易学会了，因为这需要个人以及团队长时间的实践积累作为基础。

一、故障发生时，我们该如何应对？

通常常用的方法套路如下：

• 1.重启和限流。
• 2.回滚操作。
• 3.降级操作。
• 4.紧急更新。

这四点告诉我们，出现故障时，最重要的不是定位故栽，而是尽可能地减少故障的影响范围，以及尽可能快地修复问题。

1.重启和限流

重启一般指重启微服务，严重的时候可能需要重启服务器。
限流一般通过一些中间件来处理，例如基于Nginx相关配置，以及使用Sentinel限流组件控制等。

2.回滚操作

例如现有系统存在数据可能不对这样的问题，为了修复这样的问题，我修改了代码，但编写代码的过程中，可能因为我考虑的情况不够全面，从而造成的报错，报错一般指服务器错误(代指500，通常属于代码性质的错误)，这样的错误会直接造成服务发布以后对应的接口报错，从而导致对应的界面展示不能显示数据，面对这样的错误，通常会立即回滚到原来的版本，先保证能够正常展示对应的数据，然后在此基础上，优化对应的代码，然后经过全面的测试，最后再发布，通常来说发布到生产环境前，需要在预生产环境走一遍。

3.降级操作

某一个功能出现大问题，一时无法修复，可以暂时停止该服务，这个既可以通过网关代理中间件控制，也可以通过前端配置控制。降级的目的在于不要把事态扩大。

4.紧急更新

系统自上线以后，问题不断，但基本上都解决了。有的时候一天发四五个版本，有的时候一周二十几个版本。发布十分频繁，没有一套自动化部署系统，光靠人工打包的话，效率非常低。一般来说，做分布式系统相关的产品，一定是需要一套自动化部署系统来支撑，不然的话，效率很低，问题很多。好在目前相关的开源生态很丰富，类似Jenkins的工具层出不穷，如果Jenkins不满足，也可以通过一些脚本化语言实现自动化部署，总而言之，一定要自动化，减少手动操作的频率。

二、故障发生后，我们该如何改进？

这就涉及到一个对于研发工程师与技术管理者很重要的东西，即故障复盘。

1.那么故障复盘应该包含哪些方面的内容呢？

• (1)故障处理的整个流程(程序日志打印的重要性，日志打印是程序运行的重要细节)。
• (2)故障原因分析(通过日志分析，可能的原因有哪些)。
• (3)多问为什么(基于每个可能的原因，多问为什么，从而定位真正的原因)。
• (4)故障后续整改计划(针对真正的原因，制定整改方案，以避免类似的问题再度发生)。

2.研发工程师写的代码出现故障该不该惩罚呢？

有的人认为，你写的代码，你就应该为此负责任，出现问题，你便是第一责任人。例如A写错了某个功能，就应该惩罚A。对于一些管理者而言图省事，我只关心结果，我不问你为什么会做错。这样的结果导向，利弊均有，对于领导而言，不能事无巨细，事无巨细会使得自己忙得不可开交，从而失去全局的把控，导致一些管理上的失误。但一直秉着结果导向的思路，就是一种“懒惰管理”的体现。作为一名技术管理者，我不仅关心事情做的对不对，同样我也需要关注下属的成长，下属犯错是比较常见的，面对下属的犯错，管理者的态度和处理方式，至关重要，处理的好，会使得团队战斗力的提高，处理的不好，会使得团队战斗力下降，从而造成人员的流失。

有的人认为，不能一刀切。研发工程师写的代码有问题，研发工程师的责任自然免不了，但为什么在测试人员在测试的时候没有测出来呢？不应该把锅推给一个人。但作为管理者更需要关注和思考的是，为什么研发工程师会写错，为什么测试在测试的过程中没有发现。如果不围绕着两点展开思考并提炼出有效的解决方案，下一次还会出现类似的问题。
这就相当于《阿房宫赋》里的一句话“后人哀之，而不鉴之，亦使后人而复哀后人也”。

有的人认为，之所以出现故障，是因为分工问题，例如有的研发工程师手里只需负责一个模块，无论是时间还是精力都能够很好的专注，这样能够有效避免问题的发生，而另外一些研发工程师，每个人平均负责三到五个模块开发，加上时间的紧促，难免会出现一些问题，如果惩罚，岂不是叫这些人寒心，寒心的代价是，大家越来越保守，每个人都不愿意负责太多的事情，你推我，我推你，每天大家啥也不干，天天推诿扯皮，最后的结果是干啥啥不行，扯皮第一名。

三、如何找出问题的本质？

陈皓认为，“一个技术问题，后面隐藏的是工程能力问题，工程能力问题后面隐藏的是管理问题，管理问题后面隐藏的是一个公司文化问题，公司文化的问题则隐藏着创始人的问题。”

陈皓对于如何找出问题的本质，提供了他工作20多年总结出来的三条原则：

• 第一、举一反三解决当下故障。
• 第二、简化复杂、不合理的技术架构、流程和组织。
• 第三、全面改善和优化整个系统，包括组织。

基于这三条原则，我大多实践过，但并不全面。在过去的一年时间里，我通过简化复杂且不合理的技术架构和流程，使得了整个分布式系统研发、测试、问题排查变得更简单。