敏捷运维

序言

    表面上都是自由的，实际上四周围墙，无法跨越；表面上都有很多选择，实际上没得选。

      成功是一种考验，失败也是，原因能想出来吗？

     敏捷运维，敏捷开发，在各种压力进行运维，有一定的适合场景，你知道么？

风言风语

    运维到底根据什么样的节奏走？是快一点好还是慢一点好，效率优先？……是稳一点好还是直接上比较好，稳定优先？……是有规划好还是出问题再说，质量优先？……大部分人说，我三者都要，就像CAP 理论，你不可能同时获得三个，只能在这三个要素之间取得平衡。

    今天主要探讨一下，运维到底做什么？运维的日常应该根据什么来驱动。

1 问题驱动

    有的人发现了问题，就去解决问题，有的人发现了问题，能把问题作为一个切入点，去深度的治理应用，治理环境，让业务可靠性提高一个量级。

    能提问题的人太多了，但是能提出一个好问题的人永远是高手。好的工具能让人事半功倍，好的工具人也是，好的问题依旧可以……

    问题驱动做的比较好的估计是问题的终结者，但是如果每天都是充斥着告警，问题数量众多，那么必然造成精力不足，陷入问题的泥沼中，看起来做了很多，实际上都是小的问题，这种情况下，一般都是解决了一百个问题，但是一个没处理好，运维全剧终。

  有菜B，终止服务……

   不同的问题要善于分类，重复的问题用工具解决，实在没有工具，用俩脚本解决，不能改变产品，就只能改变使用产品的方式，减少问题，自动化解决问题，重复的问题自动解。

    善用工具，节省在琐事上耗费的时间，偶尔思考一下，这些屁事的意义是让你成长还是在浪费你的时间……

2 利益驱动

    运维居然也有利益？运维本质上是一种服务，要么是为项目客户服务，要么是为了公司服务。

    所谓的利益驱动，不过是看投资收益比，做什么事情利益大，就往什么上面冲。     有的客户喜欢看人加班，那就死命加班，有的领导喜欢听拍马屁，那就好好拍马屁，总之，他们摸清楚了人的喜好，懂得人性，知道别人喜欢什么，深的此神韵。     利益可以再次分类一下，例如有的是占领影响力，最后是客户的枕边人，有的是加薪，做一系列的动作最后为这个做好铺垫，毕竟价值证明了存在感。     还是比较佩服这种人，不同的场景，不同的话术，屁事没做，一说话让人感觉他做了很多，受了很多委屈，付出了很多努力……沟通的艺术。     客户喜欢什么，那就做什么……冲冲冲，最怕的是不懂的客户，然后一通指挥，不知道要去向哪里，不知道未来在何方……不懂装懂最为致命，其实有好处也有坏处，好处是让你去追踪细节，坏处是浪费时间在次要的问题上。 3 理论驱动

   为什么要学习理论？学理论多累，要付出几倍的时间和精力。

    很多理论到最后，操作就几个命令，很容易学，毕竟依样画葫芦还是很简单的，那这种嗟来之食不是也蛮爽的么，直接摘胜利的果实。     学习理论是让自己知道可能遇到的问题，是让自己准备好随时遇见不可预知的问题，是让自己知道这个东西的极限，重要的是让自己知道，的确，到最后都是几个简单的命令，但是对于复杂多变问题的还原求解，就需要深刻的理论基础。     学习理论是为了应用理论，用不上的理论都是废话，所以学习的时候，应该问问自己，这玩意儿以后怎么会碰到，碰到了怎么解，如何提前防范这种问题。     学习理论是为了更好的规划，因为规划做的好，没运维什么事儿。

    迷茫时，可以多读书，找到理论的支撑，找到灵魂的方向；工具人当久了，也可以读读书，找点灵感，去寻求多一点挑战，找寻不一样的思路。

4 业务驱动 

   业务在不停的发展，不同的业务阶段需要不同的技能，就像敏捷运维这种，在业务初期可以随便玩，各种折腾，天天升级，但是业务上线后，还是使用SRE这套更好。

    业务在变，从而需要的技能不一样，就像数据库，初期都是各种DDL，中期都是各种性能优化，后期可能是清理数据，分库分表。     业务在动，心也在动，初期一般都很难，没人没时间没资源，但是，总是会好的……

    业务上线之后，事情就会少很多了，其实偶尔也不会少，但是环境的熟悉度，架构的熟悉度，操作的熟悉度会降低很多事情的复杂度，一件复杂的事情，如果分解下来，也不过是一些标准的SOP交付步骤，还是比较简单的。

5 故障驱动

    一周三个故障，估计也会让你心烦气躁，特别是一些比较诡异的故障，排查原因总是比较难的。

    故障数量越多，说明前期工作做的越差，救火英雄总是这个时候出场，也给技术一个展现的舞台。

    故障驱动，多了大家就重视了，慢慢就有流程规章制度的约束了，前期都是野蛮生长，慢慢的就是自费武功。

    故障出场的时机，一般也是比较紧迫的场景下，无规范无纪律，等故障多了，慢慢的就行成了流程，慢慢的大家就能兴平气和的看待如何运维，慢慢的大家就知道可维护性很重要。

    随着时间，故障的严重后果会让大家成长。。。慢慢的打造监控系统，也让大家束缚的越来越舒服。

6 谣言驱动

    造谣一张嘴，辟谣跑断腿。

    每次出现故障的时候，总有那么几个人张嘴就来个原因，甩锅一流，很奇怪的是造谣不需要证据，而背锅的那个要给出证据证明自己的清白之躯。。。

    要证明清白，其实略微有点难，你要从报错反推出别人干了啥，例如别人重新发布了服务，例如微服务架构中有服务的循坏依赖，例如各个服务是跨机房的，例如服务有大量JVM fullGC，例如同城容灾机房中的网络抖动。。。。你要去查看服务追踪，你要分析服务占用的资源，你要去日志，你要看记录，你要看各种慢sql。

    要证明清白，其实很难，你要找到关键的证据能证明清白，例如资源变化曲线，例如某服务的fullgc监控，这种大家都能接受的，而他们不接受推理，不接受基本原理的解释。。。例如平常服务好好的，为啥突然就报错了。。。例如这个sql平时不是慢sql，怎么突然就变慢了。。。原因有很多，你要确定以及肯定。

    有的时候，证明清白变成了一件很重的工作，当然这个排查的过程中，也能扫点很多雷，各种各样的问题会解决掉。。。只是耗费精力，本来不属于你的工作，然后顺理成章的成了你工作的一部分。

7 责任驱动

    责任驱动，这个就很有意思了，如果沾边了那么就属于你的责任范围内，这种会涉及到很多层面的知识和能力。

    责任驱动，即使不在自己的职责范围内，但是也会去协助排查，这种有点像使命感，解决问题成为了终章。

    责任驱动最大的问题在于时间分配，因为很多东西都要花费时间去查，精力是有限的。

    运维人都需要有一个驱动力，无论在什么场景下，总要有一个驱动力去驱动自己学习知识，解决问题，而不同的驱动力则适合不同的场景，没有所谓的对与错，没有所谓的好与坏，只有适合与不适合。

    成也萧何，败也萧何，有的东西是双刃剑，不要执着在一件事上，要多看几件事，要多看点时间，多联想相关的细节。。。这样才能看出来到底是能力导致的，还是运气导致的。

    很多事情，你会慢慢发现，它不是一蹴而就的，有很多发生之前的细节你未关注，那么错在你本身呢？还是错在于其他？分辨对与错有的时候也不是很重要。

    敏捷运维最大的痛点在于每个人都说敏捷，但是没有人说出了事怎么办？没有人说我们允许犯错，错误率是多少。。。他们不但要敏捷，而且要周全，这TM就很难了。。。我TM想锤死他。

    谁能告诉我，最强的运维是什么样的？？？在最短的时间内解决问题故障告警，这是至刚的拳法。。。运维最忌心浮气躁，运维的最高境界是让系统自动达到预期状态，从而你要了解宇宙苍生。