低代码是炒作还是趋势？

1 监控的5个维度

监控的核心目标，是快速发现“异常”。那如何定位异常呢?是不是低于我们设置的阈值的，都是异常?如果要是这么定义的话，你会发现，报警非常多，应接不暇。

要定义异常，就要考虑一个问题：兼容系统的弹性，也就是系统要有一定的容错能力和自愈能力，不然就会非常脆弱和敏感。因此，我对“异常”的定义，是：在服务(体验)、数据、资金3个方面中至少1个方面出现了损失 或 错误。我认为，一个系统，如果在下面3个方面没有出现问题，那么即使中间过程出现了偏差，或者没有按既定路径达到最终结果，我也认为没有出现“异常”(这也是一种弹性)：

• 在服务方面没有异常(我把服务错误造成的用户体验，也认为是服务异常)。
• 在数据上没有出错(我把订单超时等体验，也认为是数据出现了偏差)。
• 在资金上没有资损(走了兜底逻辑，且按照业务可接受的预定范围兜底造成的损失，不算资损，如兜底运费)。

所以监控一个系统是否具有健壮性(即：弹性(Resilient)，这一点在后面【弹性建设】中详细论述)，就要从这3个最终目标去实现，为了达到这3个目标，我们可以从 系统自身、服务接口、业务特征、数据、资金对账 5个维度保障监控的准确性。

下图详细解释了这5个维度：
 

疑惑3：稳定性似乎总是新人的垃圾场

虽然前文中说过，对于团队而言，最好不要让新人从事稳定性工作，但是稳定性毕竟是很多希望“专注工作”的开发人员不愿意做的，这个时候，团队leader很容易做出让一个刚进入团队的人从事稳定性工作，毕竟其他核心开发岗位的人似乎对团队更加重要，也不能调开去从事这种“重要不紧急”的工作，不是吗?

所以这个时候，新人被安排了稳定性工作，也是敢怒不敢言，充满抱怨的做已经约定好的工作，或者浑浑噩噩的划划水，只在需要“应急”的时候出现一下。

这个现状要解决，就要涉及到一个人的“被认可度”，也是我们经常说一个人的价值(在个人自我感知上，我们认为这是“成就感”)，很多人可能觉得一个人是因为有价值，才会被认可。而我认为，一个人是因为被认可，才会觉得自己有价值，这样才会产生做一件事情的成就感。

毕竟，能一开始就找到自己喜欢并且愿意去创造价值的事情，是很少的。大多数人是在不情不愿的去做自己并不知道方向也无所谓成败的事情。这个时候，是做的事情被认可，让自己感觉有价值，产生兴趣，而不是反过来，爱一行做一行是幸运的，做一行爱一行是勇敢的。

那么对于稳定性的新人，如果你“被安排”从事了稳定性，那么首先要注意下面3个点：

• 对于稳定性新人，一定要优先考虑如何响应问题，而不是如何解决问题。
• 稳定性从来都不是简单的，他的关键，是要做细，这需要细心和耐心。
• 稳定性不是一个人的事情，要团结团队内的同学，上下游的同学。

在有了上面3点心理建设之后，要开始在自己的心里，构建3张图，3张表：

(1)3张图

• 系统间依赖图(也包括业务时序，熟悉业务流程)，参考5.4节系统依赖梳理方法。
• 流量地图(知道上下游系统，团队内系统的流量关系和流量水位，也同时把控系统架构)，参考5.3节流量地图。
• 系统保障图(知道稳定性保障的步骤和打法)，参考5.2节作战地图。

(2)3张表

• 机器资源表(做到占用多少资源，了然于胸，团队需要时能拿得出来)，参考第4章资源管控。
• 异常场景应急表(出现问题时知道怎么应对，演练知道哪里容易出问题)，参考3.2节故障场景梳理。
• 业务近30日单量表(知道哪些业务影响大，哪些业务是重点)，参考6.1节黄金链路治理。

心中3张图，3张表，可以让自己心中有数，不会抓瞎，这就像林彪在《怎样当好一个师长》一文中写的那样，心里要有个“活地图”。这样，一个新人才能快速熟悉起团队的业务和系统，明白风险在哪里，要往哪里打。才能让自己的工作变得被认可，直击痛点，有价值。

二 监控

再牛的SRE，也不可能对整个复杂系统了如指掌，也不可能做到对每次变更和发布，都在掌控之内，所以对于SRE人员来说，就必须要有一双敏锐的“眼睛”，这双“眼睛”，无论是要快速响应，还是要发现风险，都能快速发现问题，这就是“监控”。

从运维意义上讲，“发现问题”的描述 和 “监控”的实现之间的对应关系如下

（编辑：吉安站长网）

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