Financial Risk and Production Management Philosophy 金融风险和生产运维管理哲学

image.png

金融风险?Financial Risk?

不知道为什么,突然回想起了被Gordon growth model支配的恐惧……

金融风险的核心定义之一,便是所谓的风险并不等同于损失。风险是对不确定性的一种表达,在金融的世界里,风险可能同时代表机会成本和损失概率。这是从统计学意义上,对世界运行的一种重新建模,也重新教育人们从不同的两面去看待这个世界:确定的,和不确定的。

Risk is uncertainty.

风险管理的核心框架,往往包含风险的定义(Define Category),识别(Identification),控制(Mitigation),接受(Accept)等阶段性的过程。而这个生命周期的本质,便是逐渐通过定义好的方法论,发现未知,并将未知转化为已知,从而让不可控变得可控,让不可控变得可以量化,最终让整个企业胸有成竹的过程。

几年前作为敏感岗位被外部审计访谈的时候我记得自己说,对科技部门来说,当风险被揭示出来,风险往往就变成了一个Defect(Only unknowns are risky, others are just defects),未知的往往意味着不可控的,这才是最大的陷阱所在的地方。

同事说,人类对未知充满了恐惧(这是管生产的人说的,想来更恐怖一些)。突然觉得,整个科技行业生产管理的最佳实践的核心奥义,其实就是对一切风险透明化的过程而已。

突然,串起来了。

监控的艺术 Art Of Monitoring

他们谈监控的时候,往往喜欢谈告警——在问题发生的时候,是否能够准确的告知。而事实上,告警往往只是生产监控中,最被动的一环。如果监控中心手里只有告警平台,这将是最绝望的场面——你知道有东西坏了,除此之外你一无所知。

监控设计的核心,在于度量(Measure),好的监控应从度量系统的运行状态开始。状态,容量,性能,这些大抵都能分解为无数的指标及指标的支撑指标;而告警,不过是从这些指标中,提炼出最核心的部分,放上约定的阈值而已。(我反对所有基于Error Message的告警,这是监控设计最后的遮羞布)。

通过明确经过设计的对系统的度量,好的监控的本质,是识别系统运行原理的过程,是将原本黑盒的系统运行状态,放到阳光下,将原本只有系统建设者才知道的未知的细节,固定到不同的指标(Metric)上,并转化为已知的可随时方便查看的触手可得的信息。好的监控,预警只是最基础的能力,预警之后能够提供事故处理过程所有关键的信息,能够让任何人一目了然的见到根因,这才是监控应该产生的价值。

Unkown越少,风险自然越少。

“If you can’t measure it, you can’t manage it.”

Refer 推荐一本:

The Art of Monitoring

处置之刃 Blade of Incident Management

大部分的企业,都有这样一种人。他们啥都不懂,但他们在事故中发号施令,他们可能是Command Center,他们可能是Incident Manager,他们存在的目的只有一个——把事故中的一切透明化,调度资源,明确去向,直到这个故事告一段落。

事故处置的核心,在于用最快的方式,让击鼓传花一样的事故推进的油门落到正确的人手里(好吧,脚下),然后不断的明确下一个ETA(Estimcated Time of Arrival),递归这个过程直到修复。对于事故经理来说,事故的级别(大炸弹还是小炸弹爆炸了)其实并不可怕,一级事故并不会比三级事故更让人无所适从,但倘若事故的处理不知归属,谁应负责并不清晰,需要多少时间尚未可知,哪怕是最轻微的事故也会让人如坐针转。

未知,因为不可控;未知,所以恐惧。

Fear comes from unknown.

你才有问题 Whos Problem

相比较于事故(Incident),问题(Problem)描述的是一种可能产生事故的概率,是一种对于已知风险的量化表达。在生产管理的核心流程中,问题管理才是最直接等同于风险管理的那一个。

问题的识别等同于风险的识别,问题的定级等同于风险的定级,而问题的解决相当于风险的处置,低级别高成本的不可修复问题,等同于残余风险,无非是是否在胃口之内及量化损失能否接受而已。

很多时候,问题看起来像是指责,像是让让人难堪,像是揭出来的别人的伤疤。优秀的企业文化,理应认同问题是改进(Improvement)的起点,识别问题和解决问题应是团队的正向考核的一部分而非相反的。

“The first step in solving any problem is recognizing there is one.”

傻逼才需要准备变更 Everyone Hates Change Management

“优秀的工程师都是裸写代码一次过,傻逼才需要手把手的写文档。”

事实上,这个世界上80%的生产事故来自变更,即便是Google这种SRE鼻祖的地方,太阳之下也并无新鲜事。

变更管理的目标是让工程师疯狂补写文档吗?当然不是。变更管理的目的是让所有将要在生产环境执行的操作,不确定性少一点。这是最直接的对风险的一种厌恶,这也是变更管理的核心要义——把不确定性降到最低

  • 执行的步骤应该是明确的。
  • 执行的结果应该是明确的。
  • 执行的性能应该是明确的。
  • 如果出现意外,这个意外,应该是明确的。
  • 如果出现意外,如何反悔应该是明确的。

如果你曾站在在一个全球服务台的视角,观察过上万个奇形怪状的生产事故,你会惊讶的发现,仅仅是最简单的“重启”造成的事故,都有无数中意料之外的形态。你会惊讶的发现,生产事故发生的概率和工程师的技术能力,从来都没有相关性(解决问题的时效MTTR倒是可能有)。

敬畏生产环境,不要心存侥幸。

风险厌恶人格 Risk Averse

这些年,阴差阳错的考了CFA,FRM这种对工作无用,对人生有益的东西。其中,关于风险的部分确的的确确的重构了我许多底层的人生观,也触发了我对科技管理的很多重新思考。金融风险管理本质上是以概率和数学的视角对未知进行建模,并试图量化的描述(EL,VaR);而科技管理的许多最佳实践,实际上就像一个风险厌恶的家伙,拿着鞭子让人们把所有不可控变得可控,把所有未知的玩意都放到阳光下来解剖(Post Mortem哈哈),然后很变态的打上标签,分门别类进行观察。

我确实是个风险厌恶型人格的家伙。

Built with Hugo
Theme Stack designed by Jimmy