原创随笔：做应用系统运维有感

工作二十年，至少有一半时间带着运维项目，其实DevOps，开发和运维不分家，实际上开发团队和运维团队都是一起带着了。做应用系统运维算是很有经验了，就找个机会总结一下，分享给各位朋友。运维和运营有所不同，运营一个公司，运营一个团队，这是运营，而运维更多的是对应用系统的运维。

在古代公案小说里，主要角色出场都要有定场诗，要说运维，就写了一首做应用系统运维有感的小诗：

做应用系统运维有感

韩思先生

安全问题零容忍，

回复用户要及时。

搞不定了会上报，

监控预防当回事！

最好的运维是Keep It Silence，意思是用户完全不需要联系运维团队，看起来完全不需要运维团队了，这就是Keep IT Silience。当然了，实际情况呢？简单来说，运维团队把所有的unplanned task都做成了planned task，就在某种程度上实现了Keep IT Silence。如何做到呢？

终端用户使用应用系统，为什么会遇到问题？为什么需要联系运维团队来帮着解决问题？怎么才能做到终端用户不需要联系运维团队就可以很好地在应用系统上完成各种操作呢？

假定开发团队开发的应用系统功能很完善，实现了self-service的应用程序设计的最高境界。那么，为什么用户在使用应用系统过程中还要联系运维团队呢？很简单，应用系统出问题了。怎么才能不让应用系统出问题呢？怎么才能先于终端用户发现问题并解决呢？怎么才能避免问题扩大化而及时处理解决问题呢？其实我们有三条防线：

第一条防线，是accept service，任何对于应用程序的修改，都要经过运维团队的审核，审核不通过是要退回去给开发团队继续完善达到接受标准才能发布一个新的release。这个就是accept service，目的在于保证应用程序的高标准高安全高质量，从源头上控制住不让应用程序出现问题。

第二条防线，是监控，监控的目的在于预防，预防问题出现，如果有问题，那么就使运维团队先于终端用户发现问题，提前解决掉，所谓善战者无赫赫之功，就是这个意思。监控是一个planned task，做好这个task，就能在很大程度上避免出现adhoc的unplanned tasks，从而提高运维服务的质量。

第三条防线，是终端用户发现问题，找到了运维团队，在这个时候，问题已经发生了，最重要的就是及时回应用户，如果是安全问题就要立刻上报（escalation），严重情况下要立刻停止应用程序从而避免出现更大更多的问题。前两条planned task没有做好的话，在这个第三条防线上就会出现不断的unplanned tasks，让运维团队疲于应付，没有办法跳出怪圈，越忙事情越多，事情越多越忙，就没有时间思考为什么会出现这么多问题，为什么不能从根本上来解决问题？此时，必须要采取措施，改变团队的工作模式。

做应用系统运维，一个非常关键的点就是安全问题，道路千万条，安全第一条，安全问题是没有半点可以协商的，原则上就是零容忍，一旦出现安全问题，直接就是 P1 issue，要立刻上报，及时采取措施避免安全问题的影响范围扩大化。

而一旦用户提出问题了，运维团队要及时回复，没有回复用户就会着急，用护着急就会升级问题，升级问题就会给运维团队带来更大压力，在更大压力下运维团队的计划好的工作就会收到影响，直接就是恶性循环了，因此必须要及时回复，从这个恶性循环中挣脱出来，有节奏有计划地为用户解决问题。

搞不定了要上报，这是很显然的，业务不能中断，运维团队搞不定问题了，就要向上寻求帮助，快速解决问题，帮助业务持续进行下去。否则，就是没有尽到责任。

监控预防其实就是把将来可能会发生的unplanned tasks转化为planned tasks来做，这个工作是有计划地在做，而不是出了问题再着急解决，因此要提高监控预防的质量和效率，真正做到防患于未然，以及要先于用户发现问题。要当回事，这是做好应用系统运维的最重要的一个环节。因此，我有一个innovation idea就是smart monitor，智能监控，用来监控服务器和应用系统，用算法来分析各种数据和信息。

故有此文，与君分享。

推荐

韩思工作室

韩思先生，韩世强，在外企工作，英文名或者说德文名是HANS，因此笔名韩思先生。一个职业IT经理人，半个文化人。好读书，好写作，好爬山，现定居大连。从事IT行业近二十年，积累了丰富的IT软件项目实施和管理经验，做过程序猿，产品狗和运营猫，知识面较广，喜欢总结和分享，期待创造社会价值。