磐石双体系：腾讯金融运维平台实践-谢海林

彭小阳

作者简介：谢海林，腾讯金融运维平台团队负责人，运营开发专家工程师，腾讯学院中级讲师，从“零”开始打造了金融级高可用磐石运维平台。在腾讯学院大人担任中级讲师，去讲怎么提升技术人员的实力，主要是关于项目管理推动上下游怎么去工作的课程。同时也是CDG运营开发技术通道负责人。

一、项目的背景

今天大家讲很多的体系化，这里面有超过50人团队做这件事情的举手？没有，我们团队十几个人，大概15个人，所以我们也没有这么多人来做这么庞大的事情。
这么大的体系里面，什么东西是最值得我们去做的，这是我们岗位需要思考的，到底是做扩容，还是做监控，还是做容器化？一定要找准点。我主要和大家分享我们是怎么去找这些点，而且做的过程中我们碰到了什么样的问题。

第一，业务现状。腾讯金融经过2014年的红包之战之后，现在也是绝对的海量业务，我形容是海量实时业务永动机；对于实时的流量，在春节大概有10万级的，包括有百万级的入帐，有10万级的支付，每天的量大概也是10亿级别，这是外面可以感知到的支付的情况。内部系统非常多，包括服务器也是好几万台，每天的日志量大概是几千亿到上万亿的级别。
第二，互联网有一个特点，它是在奔跑中去换人。每天这么大的量和级别，变更非常的频繁。我们再来看用户的要求，比如说坐地铁，你不能让我等，我等不了，所以200毫秒以内必须要返回，同时要可用，同时资金有保障，实时要看到资金的水平。比如说在春节发红包那一刻，有的人因为抢了2块钱的红包，他就看他的流水是不是到了，所以对资金的敏感度是非常高的。
第三，什么东西都是不确定的，硬件不可靠，程序有bug，人也不可靠，在这样的场景下，对于运营平台来说，或者是对于做运维的同学来说，平台的要求是什么？我们面对这样的场景应该怎么去做？
当我们碰到这些问题的时候，我们要去定义我们的问题。对老板来说只有一句话，不管怎么干，只要不出事就OK。所以我们的方法也是这样的，全方位兜住不确定性，全方位降低未知风险的影响。因为老板的要求就是这样的，就希望你不出事。那我们怎么做到不出事这件事情呢？我的理解，腾讯支付在过去的四五年时间里面，都是沿着这样的思路去做，去年、今年大家很少看到大批量的微信支付不可用。

二、整体解决方案

我们要解决这样的一件事情，兜住不确定性，我们碰到的最大的问题是什么？

第一，现网变更非常频繁，如何不人为搞出故障？80%的故障是人搞出来的，没有人动的时候系统好好的，人一搞就搞出问题，所以我们变更的时候不搞出人为故障。
第二，故障不可以避免，所以要考虑出现故障的时候，如何快速恢复业务，把影响降到最低。
第三，尽可能发现风险，提前解决那些未来可能导致故障的隐患。
以上是运营平台在现阶段的3个核心问题，有了这3个核心问题，我们怎么做呢？

我们建立了3个针对的场景：
第一，变更是可用性的短板，一定要把变更做好，确保变更对业务的可用性的影响无损；
第二，如果发生故障了，能不能减少故障对业务可用的影响；
第三，持续运营，在日常运营中，能不能持续减少业务可用的隐患。
一切都是为可用性，我们和其他团队有不一样的地方，因为支付的要求非常高，成本不重要，效率不重要，重要的是不要出事，资金安全和系统可用是最重要的事情。
有了整体的解决思路之后，我们就有了整体的解决方案，我们把它叫磐石，希望能够让这个平台稳固得像磐石一样，能够给大家提供不间断的服务。

底下是我们整体的框架，没有必要去看，可以看到中间的3个部分，就是统一变更+故障处理+持续运营，上面是可见的部分，PC端、移动端，中间是3个主要的运维平台，底下是我们的运维能力。我相信这个架构走到哪里都是这样的，稍微有开发追求的，大家都是按照前端、网关、后端、底层，这没有必要去多讲。
接下来，我们讲讲这两个体系里面，到底是怎么去做，碰到了什么问题，如何做到真的高可用。

三、统一变更体系

统一变更，业务无损变更方案，控制变更时不搞出故障。这个过程中我们如何看？这是我们整体的解决方案，说起来很简单。

第一，统一系统化。有没有哪一个部门、哪一个团队真的不再登陆服务器的？我们做了这么多年，现在依然没有杜绝这件事情，依然有人还需要在个别程序上去动服务器，我们在流程化上直接卡住。
第二，统一灰度。无论你做任何一件事情，都要看灰度。
第三，统一回退。在这个过程中有问题，先不考虑原因，快速回退。
第四，发布即神效。我要让我的发布是符合预期的，我们把它叫一致性，发布即生效，我们很多时候在这里会有很多的坑。
第五，所有的发布记录是可追溯的。
所以整个的思想是，灰度放量，控制影响，版本故障，快速回退恢复。这说起来简单，但是做起来没有那么容易。
第一个难点，如何确保变更时现网影响可控？
第二个难点，如何保证和现网一样级别的可用性？支付不挂，我们的平台就不挂，支付挂一半，我们的平台也就挂一半。
统一灰度，我相信很多同学都会去做灰度，我们有什么不一样？我们只有两点不一样，一是做标准的内测环境，这里会做一系列的检查，包括自动化验证、特性版本特性验证，这些是必须在标准环境完成之后才上现网，现网就会有灰度1一直到N权威发布。
这里的发布有什么差异呢？
首先的灰度在不同的业务之间做灰度，比如统一个支付，会先在QQ支付上做，在QQ支付上做完再做微信支付，不是说全部把QQ支付做完再做微信支付。当做第一个业务的时候，第二个业务就做一台，第二个业务就选一边做，每一个步骤，所有的步骤里面，都只动了现网的一边，也就是一半。
这样有什么好处？如果真的发生了问题，没有关系，切过去，这里的前提是业务有切换能力，同时现网的容量要能够满足100%的要求。单边能够支撑100的要求，这是前提，如果没有这个前提去做这个没有意义。

我们做灰度的时候有几个特点：
1.业务按照优先级。QQ支付的量比较小，所以我们就先做QQ支付，再做微信支付，所以业务是按照优先级。
2.流量逐步放量。从第一步开始一直到慢慢开始往上升，升到一定的维度才能放量。这里面难的部分是，你做完一步之后，怎么验证这一步真的就没有问题，现网业务就真的没有影响？这里面非常的复杂，包括自动化验证、智能巡检等等一系列的东西。
3.一个步骤内只动单边。保证左手出问题的时候，能切到右手。
我们在统一灰度变更中有3个兜底能力：
1.流量切换到对端。如果这个真的坏，也没有关系，能够切到对端去。
2.版本回退。这个过程也是有步骤的。
3.版本基线回退。我们建这个能力以来只用过一次，就真的是救命，灰度发现灰到这个地步的时候，回退不了，系统不行了怎么办？刚才说切走，切走还得恢复，所以就用过一次基线回退的能力。

发布即生效的解决方案，这件事情为什么非常重要？发布这件事情说起来简单，但是做起来非常不容易。
我不知道大家出现过这样的问题没有，比如说今天A同学发了一个版本上去，开关没打开，或者是没有生效，或者是没有重启，第二天B发了一个版本，把A的特性打开了，接下来怎么办？回退，回退没效，而且找起来很难，所以我们在发布这里非常重要，我希望我发的这个东西，就能够知道已经生效了。
整个过程怎么做？首先看到前面有流水线中心，然后到发布中心，到发布中心之后首先要做版本准备，版本准备完之后，正常来说流程没有黄色的部分，准备完之后推送，推送完之后本地部署，本地部署完之后做主结（音），然后做合入基线，再做中心基线，一般的逻辑是这样的。
我们在这个过程中做了几件事，每次发版本的时候，都要确认线上的版本是不是上一次发的版本，如果是，证明现在的版本没有被弄过，这能够很好地杜绝因为别人不小心而导致问题。第二个是重启完了之后必须做业务生效和异常检测。这部分主要是通过自动化验证，包括重启生效检查，包括业务巡检（音），都会这个逻辑做。这个逻辑做完之后，最起码保证特性不是先发上去等到一个时间再开，你发这个东西就必须打开，就必须用，否则你不知道线上什么时候生效，所以发完之后就要生效，生效完合入本地，我们一部分是现网跑的，一部分是现网基线目录，合入基线之后，要去做本地合入基线检查，确保本地备份是可以的，然后再去合入远程的基线库，合完之后又得去做一次远程的合入检查，我们把它叫实时核对。
做完这个是不是就够了？不够，我们还做了临线的核对。因为实时流程只能保证每次按这个流程走的时候，那有的人就是缺心眼，把这个地方改了怎么办？虽然很少，但是依然有，因为有的人心急，或者是他的习惯没有改过来，所以有30分钟的回退，保证把现网的IDC的目录、现网基线的目录和发布中心的目录，以及正在运行的版本做离线核对，保证他们是一致的。同时也可以确保，同一个版本在线上，各个色彩之间是确保一致的。
我们在每一次下一个步骤都要确保上一个步骤是正确的，这保证了我们的预期和想法是一致的。在离线的时候，主要是三方对账，保证非正常的流程的一致性，包括漏发、机器故障、手动修改、入侵，这些都能够在异常里面兜住。所以，偷偷改一个东西是改不掉的，这是我们发布的一致性的解决方案。
这个解决方案能够给我们带来非常大的收益，让我们不再出现意料之外的不一致。之前经常出现这个人做了一件事情，别人不知道，给下一个留了一个巨坑，下一个人做的时候不知道你做了这敢事情，所以去检查的时候，发现时间非常久。

接下来再讲一个点，怎么保证高可用。业务上面是分了双城双中心，我们在所有的运营平台里面，特别是对于发布来说，因为发布有时候就是救命的，比如假设深圳那天灾难了，就是要发布去把上海所有的量增起来，就有这样的可能。所以在整个过程中，我们也做了双城双活，我们怎么做的呢？也很简单，从前端到服务层，再到存储层，再到外部的系统都不用说了。
那我们怎么做的呢？
第一，在最外层看话，用“三一云”（音）全部可用，比如OP，在深圳是深圳OP，在上海是上海OP，3个OP是完全可以用，用哪一个都可以。这有点LOW，但是非常有效。
第二，我们在网关做了什么事情呢？我们做了双层的路由，但是本地优先。所有的服务调用的都是本层条块化，服务层的无状态的SQL都是本层据调的，不会跨层。在服务这一层我们做了读写分离，读本地，写第三方，我们的假设前提是，正常情况下是不应该3个城市里面同时出现2个的，所以读写分离，读本地，写第三方。DB这边，我们也有一个DB集群，我们叫MySQL集群，三地两中心的概念。
外部系统，所有的外部系统必须本层依赖，万一第三方有问题，全部降级。我认为是做得比较细致的一件事情，花了大量的时间和精力。

统一变更，变更发生时，确保变更过程安全可控，减少对可用度的影响。我的理解，核心说起来就是3件事：
第一，对等切换，我们在发布过程是灰度，并且是具备兜底能力。
第二，发布即生效，一致性解决方案。
第三，双城双活，在故障的时候，能够就地即用，真正出网络故障的时候，就是救命，就是有用的。
我们解决了人为搞出故障，是不是故障就没有了？一定有。怎么做故障处理体系，快速恢复故障，金地业务影响，这是我们的核心影响，如何去做呢？

四、故障处理体系

我相信所有做运维的同学都知道故障处理就是快，最快速处理故障方式恢复业务，减少业务影响。
我们是这样做的，一个故障发生，有两种可能：

第一，这个故障经常发生，比如说机器挂是经常发生的，这叫高频已知故障；比如说一个IDC网络挂有没有可能？经常出现，所以我们叫高频已知故障，而这部分，我们希望能够做到系统自愈。系统自愈是给到开发的压力，你的系统架构必须去支持自动切换这件事情。
第二，如果高频已知故障可以自动切换，那是不是所有故障都能去中心化？不可能，所以运维要解决的是其他故障类型，以及故障自愈不成功的时候，人为要介入处理故障，我们希望一键故障恢复，一键能够把事情处理好。自动切换解决高频已知故障，人工切换兜底所有故障处理。

在这个解决思路里面，具体去做有一个环，发现故障，定位故障，故障处理，这3个能力是不是每次故障都能很好的应对？推动复盘的方式，把发现、定位、处理的问题逐步完善。最后处理的时候，是不是真的有效？通过演习去解决。我们希望提前规避和快速处理故障。
今天说了很多，包括智能运维相关的事情，难点在什么地方？ 第一，海量数据又快又准；第二，故障发现要又快又准；第三，故障定位怎么做准；第四，故障处理简单有效。
设备在稳这件事情上我们怎么做的？我相信大家有很多的处理办法，包括大数据平台，无非是从采集到接收，再到分析，再到存储，再到提供。而且在数据量也是逐层去降的，这是我们原来很多年都是这么干，因为数据量逐层下降才能完成，如果人说让你用50%的机器去做运营，没有这样的公司，最多是让你有5%的机器来做运维平台。

在这个过程中有一件事情是很难解决的，你作为一个开放的监控平台，有的人就是不守规矩，给你乱报数据，蹭你的数据热点。监控一定有纬度加指标，如果某一个纬度值特别烂，在我们这样的平台下，上10亿级的用户，或者是亿亿的用户，你分分钟就会挂。那怎么办？我们做了一个纬度值的监控，我们通过实时的数据流，一分钟级的反馈，实时数据流能单独统计一条这个纬度值报了多少量，在一分钟内的膨胀数有多少，同时纬度值的膨胀数有多少，如果这个很大就直接干掉，这就是我们的做法，既简单又粗暴，非常的有效。
我们现在就是很简单，单纬度值不能超过5万，超过5万就立马停掉。我们在这个过程中上了之后，发生了非常多次纬度值上报的异常，并且发现了超级纬度值异常的情况。我们作为平台要有平台的原则，就应该大胆跟业务说这样是不合理的。

数据时效性与稳定性平衡方案，监控的数据叫实时的数据库，支付能容忍多长时间发现故障？你们一定要问一下你们的老板，你觉得我们的公司业务能连续多长时间发生故障不发现，这里是矛盾的，为什么矛盾呢？如果你要稳，就一定要多留时间出来。
我们怎么去做的？我们有两个方案，一是可以做新的验证，每一成都去做统计和对账；二是模拟一个用户，就在这里做一个总值，就是0.01分的数据，这个点就打一个自动标签，说这个点就报一个这样的数据，在每一次用的时候，会去看这批数据是不是到了，如果到了就能用，没有到就不能用。
我们在这个方案里面，发现核对的方式准确性高，但影响时效性，跟我们的目标不符；改造成本很大，要修改原来的链路。
这有什么好处？如果我们这一批数据，我们的业务数据，假设一分钟统计、一分钟采集、一分钟入库，然后还分批，可能要变成2分钟，这样的话，一分钟的数据到真的对外提供准确的数据是多少，3分钟过去了，这时候绝大多数都是可以的，所以前台才敢放曲线给大家去看，才敢去告警分析，这是我们之前的做法。 那这样的做法有一个非常大的问题，有的业务就是慢的，上报量就是会长，怎么办？平台做法是一刀切，我们的做法是，我针对于每一个业务，都去做一个定时的自动上报，我认为这个时间上报的数据来了，我就认为这个业务数据准备好了，那应用就可以开始用了。
所以，我们的平均时间，从原来的3分钟到1分30秒，1分30秒的时候大部分的数据都可用了，只有少部分数据不可用，不可用的时候就告诉用户说现在不可用，但是你这90%的数据都可用，而现实的情况是这90%的用户才是我们的核心用户，90%的业务才是我们重要的业务，所以大家的时效性就提高了非常多。
这是我们在时效性做的解决方案，我个人觉得是非常取巧的方，没有多复杂，但是是特别有效去应对了这件事情。我们的运维同学或者是开发同学才不管是运维平台的问题还是时间问题，只管怎么监控平台又出问题了？从来不管，只管怎么监控平台又出现问题了？所以我们通过这个方案解决了用户的问题。
我们也有非常多的做法，因为时间关系，就不去讲。
接下来再来看我们的告警处理。我想做一个小调查，人均一天收到的告警小于10条的请举手？小于50条的举手？大于100条的有没有？我相信还有很多人没有举手，可能是大于500条。
基本上，一个运维人员的极限的处理，一天50条。超过50条，这一定无效。50条如果能够实时看，那我就服了，24小时实时看是不可能的，所以我们的目标是10条。如果一个运维人员1天只收10条告警，还不去看，那说明人有问题，可以处理你。如果超过10条，是平台的问题，是组织的问题，跟你没有关系。如果告警超过50条，老板还要求你每天看，我觉得你可以趁早考虑换个地方，因为你做不到，你肯定做不到，某天背锅一定是你，因为这绝对不可能做到。
所以，告警要么配不全，要么就漏，要么就故障太多，我们有非常多的解决方法，最开始怎么做的？

最开始的人肉时代，人一个、一个配，配完之后发现，A同学和B同学的水平不一样，配出来的结果不一样，专家模板，那有没有效？无效，要想通过模板搞定一件事情是不可能的。
那就到了第二代，通过AIOps方法能代替人去配一个东西，到底是5%告警，还是10%告警，这个很复杂，通过离线学习，包括数据分析等等，做了这些事情有没有效，有效，这个时候人工配置，只需要配置那一步需要告警，算法不用配了，那还要加什么呢？加算法不适应的地方，人工经验敏感度和时间的敏感度上要配一配。

接下来有2.0，2.0是把1.0做成离线的部分做成实时的，我们把算法拿过来，直接嵌入到了云上，所以我们省掉了训练算法的部分，发现有没有效果？还不错。
我们还发现了一些问题，非常明显的故障，为什么要用拉长时间的方式告诉我呢？比如说业务挂了，还等了3分钟才告诉我，等3次识别异常才告诉我，这是否合理？业务觉得合理，业务都挂了，为什么一定要等3分钟才告诉我？这件事情迫于压力变成了一次告警，我稍微波动一下就告警，我晚上还睡不睡觉？对于智能孙发，对于微小波动的话，是很难解决的。微小的波动这么久都不能发现？有的故障持续了一两个月都不能发现，所以这就是我们的挑战。

我们怎么去做这件事情呢？我们在AIOps2.0的基础上做了一个算法，把整个数据异常的判断，单个点的判断变成了影响面积的判断，通过时间和空间来做，如果大的故障就可以很短时间告警，如果失败率标得很高，那一分钟一个点就出来了，如果很低可能稍微长一些。
所以我们要看影响的面积，超过就立马告警，如果没有超过就等一等再告警。这个原理是基于影响来做的。
这样很好的解决了：第一，这个区间的范围放小之后，能减少漏报的可能性；第二，时间范围放大，可以把时间放更长一些，提升准确性。所以，它能够解决大故障很快发现，小故障用是来换准确性。
老板不能要求说什么故障都第一时间发现，所以影响小的故障就是没有那么快时间的发现，就是需要一段时间才能发现，告警的准确性和时效性矛盾得以解决，告警漏报性和准确性矛盾也得以解决。
最后发现，这件事情原来是要配敏感度和时间，现在要知道面积，面积有没有办法算？面积怎么算？刚才是发现故障，故障是有定级标准的，如果你不在这个定级标准里面没有人理你。没有关系，在发生了定级故障，一定要负责任。
我们通过故障处理时间的SLA和故障事故规范管理办法来确定面积，以前你没有告诉我说为什么这个故障没有发现？现在就告诉你必须到了10%的影响才能发现，没关系，这可以，因为这是在故障标准管理规范里面去制定。比如说支付，1千笔以上的影响必须发现，不到1千笔发现那不就很好吗？为什么第一笔的时候就要发现呢，这是不一定的。

做完这件事情是不是就可以了？还不行，为什么？因为我们还有问题。为什么下线了一个集群，一直没有告警？今天业务搞个活动，怎么一天都在告警？业务特性就会带来告警，并且来持续不断，这种要不要告？如果不告，确定不了，告又难受，所以我们又做了一件事情，在刚才的面积算法之上，还加了一个典型的故障处理，典型的业务异常算法。
这些事情是我们根据经验给做出来的，新业务、扩容、缩容、切换场景等，我们一个一个对，如果说满足了这些场景，告警降级，同时在通知里面告知他说可能是因为XX。
最后我们想说，告警发现这件事情，业界做了这么多年，报警一直是没完没了的，因为我们永远做不到一个故障就告一条警。告警发现这件事情的本质到底是什么？是发现故障。我们想的使，如果我的告警每一条都是有效的，我认为告警做到这个水平就够了。这个告警是有人去跟进和处理，不管是不是故障，我认为这个告警就是做得好、做得有效。

我们做了一个告警跟踪，当告警发生完之后，如果是立马要处理的，马上通知人处理，处理完之后业务恢复，告警处理完成。这个时候，人去标识，手动去标注，如果说告警是低应用级，就持续关注，如果说一段时间还没有恢复，就申请到高频告警，如果自动恢复就自动做一个标准。这样有一个好处，你可以很好地去评估告警的准确性，你知道今天发出来的100条告警，到底哪些是有用的，哪些是没用的。
接下来讲告警的定位，定位这件事情很复杂，因为这件事情很难，特别是对复杂业务真的很难。

为什么难？标准长，标准多，链条长，部署复杂，运维系统割裂，我们一路走过来，这些现状都是存在的。那怎么办？过去的告警定位方法，怎么定位？人站在中间，周围给了他一堆的工具，这样走过来之后，告警这件事情极度依赖人。
你会发现，运维人员由此而感到高兴、自豪，他定位出来了，另外一个人没有定位出来，说明这个定位人的水平高。但我觉得这是做运维平台的失误，为什么？因为这样的话就被绑定了，被依赖了，如果这个不在怎么办？
所以我们有了一个思路，我们能否通过一套系统化的方法来解决这件事情，我们把它叫双向分析法。
对一个告警，对一件事情来说，第一是看对外的影响是什么，向上去分析影响；第二是向下分析故障出现在哪里，故障点是哪一个地方坏了，坏了之后就拆掉，所有的分析方面都是以快速止损为目标，向上分析影响的时候，是设计决策，老板怎么处理，是否开大招，我们做运维，特别是腾讯业务体量这么大，就会有大招，实在不行就从深圳切到上海，据向下故障初因是什么，不去分析根本原因，有要知道故障源，知道这个地方坏了，就有办法处理。

在系统故障的时候，系统多处指标异常，到底是哪一个纬度的原因呢？我们的做法很简单，化繁为简。无论你的理念是什么，就分几个层次，几个机房，或者是几个区域，每一个区域、哪一个地方有问题，我们只要找到这个集群就可以，这个集群对应着什么操作，这就是我们定位的逻辑。只有在这样的情况下，才能够很好的处理。我们把非常复杂的图变成了简单的模块和功能。

向上评估怎么做准确？我们只分了3层，底层、中间层和入口层，我们对向上评估的时候就看入口层的影响多大，把入口层全部找到，然后进行数据清洗，清洗完之后留下有影响的一些点是什么？有影响的这些点，把真正对用户有影响的功能遴选出来，并且它的影响是多少？把这些标出来，标出来就知道故障的影响是什么。

我们在故障定位的时候，首先要看故障源是不是准的，我们有没有一招致敌的办法？真的没有。所以我们都是人工判定故障源，这是通过人的经验，比如第一个底层的（英文）比上层高，如果说都报错，底层更有可能是影响源。很多都是有经验的沉淀，这是初步的分级分类，包括网络等，业务方面，也包括银行、商户、可开放的接口，保证向下找故障源是相对靠谱的，也是准的。
其实做法就是专家经验，人工经验+AIOps+开放。这是我做故障定位的思路，向上去分析影响，向下去找到故障源。这是我们真实的例子，收到告警的时候就分析，通过分析之后，一个告警出来之后，知道它的影响和原因是什么。

接下来要处理，怎么让这个处理足够的简单？我们是不是具备的故障处理的能力？我们有一个容灾白皮书，要么切换，要么摘取，从IDC到SET，层次是怎么划分的等等，这个过程说起来容易，但是真的要实施到每一个业务没有这么容易。
比如对于支付的场景来说，加起来有六七十个，建了工具怎么样？还要保证它有效，我们觉得有效的方式就是用，不用肯定就没效，通过演习来保证有效。

支付真的是每一个月做一个机房的全网容灾，机房每半年做一次，开关级的每双周做一次，这里面要投入大量的工具和人力，但是我们认为这件事情是值得的，功在平时，这件事情做了之后，才能保证真的哪一天深圳挂了，敢切到上海。

单个工具去实施之后，有没有办法进一步提效？我们做了运维处理提效的运维管家，这解放运维人员和开发人员，运维这件事情，最痛苦的是心理压力太大，可能不是真的很累，做任何一件事情都很累，运维真的是心累，为什么？看头发就知道。

五、磐石运维未来思考

磐石平台未来的思考是什么？我们过去花了那么长的时间，花了四五年的时间就做这两个体系。

未来的思考，我们要体系化平台构建运维的服务能力。这是我们去年做的整体的规划，整个运营平台，或者是运维这件事，看起来就这么一回事，运维服务交付到底交付什么？比如说交付的是统一值班、持续运营、运运维服务度量、运维交付流水线。
逻辑层也就几个体系，故障处理体系、一变更体系、容量管理平台和SRE开放平台，为什么要开放平台？因为只有开放平台怎么去解决个性化，南京为什么做得好？南京做得好是有原因的，是因为本身业务个性化的异构程度就足够高，所以它必须走开放平台这条路，否则他就死了。
那下一个层是基础设施层，运维配置中心、流程引擎、操作通道、数据通道。我最后是管理设备agent。未来我们在价值维度要多思考：
第一、希望这个平台的能力是具备接入及服务的能力。对于我们的业务，只要进了磐石平台，就应该享受 磐石运维能力交付的能力，这需要我们去结合效能等，我们的基础组件一定要把这些加上来。如果这些东西没有搞好，衔接不上的话，要花大量的时间去补缝隙的地方，所以最好是能在一开始把研发流程、技术组件和平台整合起来，这是最好的。
agent平台，标准和只能让你做80分，你想做到60分以上或者是80分以上，这个平台一定是可以的。
第二，我理解的运维是，你真的有需要做到自动扩容才需要去做，如果你没有需要去做就不用做，支付常年的容量是50%以下，那这做扩容不是扯蛋嘛。选择运维这个行业，选择运营开发这个行业，一定要能够跟你的业务痛点结合起来，找到你业务的痛点价值，才能做好这件事情，如果按照业务界的思路去搭，只能做一两年，做完一两年之后就会死。