事关金融安全和行业未来发展

通过这种程度的梳理，SRE以及其掌控的故障应对人员，能够快速的明确发生问题的场景，以及场景下的影响、表现、定位方法、应对策略。当然，如果要把这些场景牢记，做到快速应对，就需要依靠：演练。

3 故障演练

演练对故障应急无比重要，但是，我个人十分反对把演练作为解决一切问题的手段。演练本身，应该是验证可行性和增加成熟度的方式，只能锦上添花，而不能解决问题，真正解决问题的应该是方案本身。

不要进行无场景演练

有些演练，不设置场景，纯粹考察大家的反应，这种演练，上有政策下有对策，表面上是在搞突然袭击，其实已经预设了时间段，预设了参加的域，不太可能做到完全毫无准备，到了演练的时间点，大家可以通过死盯着报警群，调整各种报警阈值的方式，更快的发现问题;而且完全无场景的演练，一般只能演练如fullGC，线程池满，机器load高，接口注入异常，对于一些数据错误，消息丢失，异步任务积压等场景，很难演练。

针对性的，我建议多进行场景演练，各域要提前进行3.2节这种详细的场景梳理，通过场景攻击，提高大家的应对成熟度。事实上，现在横向安全生产团队不对各个业务团队进行场景攻击的原因，也是因为横向安全生产团队自己也不熟悉各个业务团队的业务场景，这个就需要加强对业务场景攻击方式的规范化，横向安全生产团队也要加强机制建设，让纵向业务团队能够产出场景，而不是每次都在线程池、fullGC、磁盘空间这些方面进行攻击。

不要无意义的提速演练

演练本身虽然确实有一个重要目的是提高应对熟练度，但是不同的业务是有区别的，有些业务的发现本身，就不止1分钟(比如某些单据积压场景，消息消费场景)，这些场景，如果不参加评比，或者流于形式了，就会让攻击本身没有意义。

针对性的，我建议各个业务根据各自的特点，定制演练。如：普通电商业务，关注下单成功率，有大量的实时同步调用;新零售业务，关注单据履约效率，有大量的异步调度;每个业务，根据实际场景和业务需要，制定“有各自特色的要求”的演练标准，演练不一定要千篇一律，但是一定要达到业务的需求标准。这样也更加有利于演练场景的落地，有利于蓝军针对性的制定攻击策略。

各个SRE同学，不管大的政策怎么样，还是要关注团队内部的场景本身：

• 对于系统性故障注入(load、cpu、fullGC、线程池等)，直接套用集团的mk注入即可。
• 对于服务型故障注入(下游异常、超时，接口超时、限流)，mk也有比较好的支持。
• 对于订单异常型故障注入，要自主开发较好的错误订单生成工具，注入异常订单，触发故障报警。
• 对于调度、积压型故障注入，要关注schedulex、异步消息的故障注入方式，同时防止积压阻塞正常订单影响真正的线上业务。

同时，在演练前后，要注意跟老板的沟通，要让老板理解到你组织的演练的目标和效果，不然就不是演习，而是演戏了。要和老板的目标契合，在演练过程中，通过演练提高大家对业务场景的理解深度和对问题的应对速度，增加大家的稳定性意识，达到“因事修人”的目的。

4 故障应急过程

如果不幸真的产生了故障，作为SRE，要记得如下信息：

• 冷静。作为SRE，首先不能慌，没有什么比尽快定位和止损更重要的事情。
• 拉电话会议同步给大家信息。记住，在出现故障时，没什么比电话会议更加高效的沟通方式了。
• 参考前面1.4.1节中的SRE人员快速响应流程，在电话会议中同步给大家：
  • 尽快告知当前告警已经有人接手，是谁接手的，表明问题有人在处理了。(这一步叫“响应”)
  • 组织人员，快速定位问题，告知问题初步定位原因(这一步叫“定位”)。
  • 初步影响范围是什么?给出大致数据(这一步方便后面做决策)
  • 有哪些需要老板、产品、业务方决策的?你的建议是什么?(这一步很关键，很多时候是：两害相权取其轻，你的评估和建议，直接影响老板的决策)
  • 当前进展如何，是否已经止血?(这一步是“恢复”，要给出“进展”，让决策者和业务方了解情况)

• 高层次的常识：类比和隐喻，AI：我太难了

  总结来说，常识是人类独有的吗？研究人员认为，并不是，常识是取决于一些基本概念的。比如，眼前的物体是什么？它会占据多大空间？以及因果之间的关系等等。

  而且，这些理解被深深地刻进头脑，并不会随着时间的推移而发生改变。

  然而，动物所表现出来的常识，很可能就包含对奖励的认知。

  「如何构建这样的人工智能技术仍然有待解答。但是我们提倡一种方法，让 RL 智能体通过与丰富的虚拟环境进行扩展交互来获得所需的东西。」

  因此，通过适当的任务训练智能体，很可能就能为AI赋予常识。
  
  

（编辑：吉安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!