【理念篇】应用运维三部曲

应用运维三部曲，就是告诉你应用运维就该这么干！

在日常的工作中，应用运维是否觉得自己很苦逼。比如说：

是不是要值夜班？是

是不是要不断应对需求？是

是不是就是一个服务器者和应用发布者？是

是不是要接受开发对我们不懂技术的质疑？是

曾经有个研发想转运维，问是否要值夜班，如果是夜班的话，我就不转了。其实还真说明了一个事实，你做得好研发，还真不一定能做好运维哈。

那我们一起来探讨一下如何做好应用运维，彻底改变以上大家对你错误的定位和认知，我把它称之为运维三部曲：

在任何一个互联网的企业中，遵循这三部走策略，一定可以把应用运维有条理的做好（传统企业不敢说）。另外辅助工具化和数据化的运维平台支撑，应用运维就如虎添翼，会大大影响三部走的进程。但在本篇文章不去谈自动化和数据化运维如何做，主要是谈标准化、服务化和无状态化三步走的应用运维路径，看是如何实现，且一步一步的影响应用运维的，也可以看出对应用运维的一些要求。以下是其详要的论述：

第一步：标准化

标准化是应用运维强势走出运维，面向研发的第一步。一个应用运维，如果没有把标准化理解到位，我觉得是不合格的，会给后续的运维带来很多问题，包括成本的上升、价值的体现等等。那标准化运维到底包含哪些？我觉得可以小到一个进程的运行属主，也可以大到系统架构或者机房部署架构等等。此时照样可以用分层体系来进行细分，识别标准化运维到底要做什么？

1、基础设施标准化

和应用相关的有服务器、虚拟化、OS、机房部署、公有云等等。

服务器可以按照自己的服务类型选择几个标准类型，比如说CPU计算性（内存可以小一些）、内存性（把内存加大）、数据库型三种。在涉及到hadoop运算的企业中，可以配置多硬盘的服务器，比如说内置12块1T no raid的硬盘机器。这种标准化选型没有坏处，特别是规模越来越大的时候，会逐渐看到这种标准化带来的好处。第一、变更成本不断降低。硬件垂直扩展的方式，在规模下运维无法应对；第二、对业务架构形成反向的推动力，根据机型分布自己的服务组件。

虚拟化。并不是每家公司都可以玩得起IAAS云，特别是基于Openstack，要投入大量研发和运维资源，但是对于任何公司来说，无论大与小，都可以采用虚拟化的技术。无论是操作系统级别的Kvm、Esxi和Xen，还是轻量级虚拟化Docker，都值得去尝试使用。虚拟化可以解决资源复用问题，突破OS的资源限制（比如说文件句柄）、资源收缩或回收等等，在web类的服务中，更需要去尝试。前期不导入的话，在后期随着业务规模越来越大的时候，虚拟化的导入难度会增加。

OS。在OS层面上，其实就是选择好你的操作系统和内核版本，不要任意的选型，也不要太相信操作系统版本更新带来的优化效果。注意别用32位的操作系统即可。其他的优化更多的交给应用优化好了，带来的效果更好、成本更低。

机房部署。这个要结合业务来看，选择几个稳定的机房就好了（一般都是两个）。之前在一家公司，网站类的服务分布在多个机房中，维护非常麻烦，任何一个机房的故障都会有业务的影响，最后全部收拢到两个机房中，运维复杂度大大降低。核心业务做双机房部署，非核心机房单机房部署，通过代理提供非核心链路出口的服务即可。

公有云。我把公有云也作为一种标准的基础设施，云因为其弹性能力确保了资源的获取能力。公有云可以彻底的解放底层运维的依赖，让研发都可以做运维，虽然看似资源成本高了一点，但它给你争取的业务时间和运维成本呢？

2、应用环境标准化

这块非常简单，一定要对程序的应用部署环境做标准化约束。程序运行的属主、程序运行的目录甚至是配置文件的规范、log目录等等。之前在【多玩 YY 事业部 软件包 规范V0.1】中做过详细的标准化规范约束，详细目录如下，供参考：

这块对后续的工具建设要求有很大的影响，特别是发布工具、自动发现工具等等。一个标准化的环境，让后续的系统平台复杂度会大大降低，因为你无需处理那么多进程属主的问题，你也不需要考虑程序运行目录的问题，你可以使用标准化的监控对应用进行监控，你可以编写脚本自动化发现服务器上运行的服务等等。如果配置文件是标准的情况下，甚至可以自动化生成业务拓扑等等。

因此我建议这个地方运维一定要建立一个标准规范，是真正的业务运维的根本。而让研发或者运维规范的所有基础就是生产环境必须严格控制在运维手中，不要让研发接触到生产环境，并且最后是平台化，这样还可以进一步约束运维。

3、组件标准化

在任何一个业务架构中，都能抽离出需要的组件类型，比如说cache组件、数据库mysql、文件存储、web组件等等。这个地方一定需要一个标准化的选型，和服务器一样。特别是对于大规模的研发组织来说，这个标准化就更重要，直接影响了运维的成本、研发的效率甚至是产品的质量。

在YY接触过一个项目组，研发按照自己的喜好，选择了cassandra、mongodb、mysql、redis四种存储，所有的好与不好，都是从自己的角度描述（忌讳啊），最后这个产品的结果是质量问题频出、无法快速迭代、运维还无法管理。

现实中会经常碰到研发就会根据自己的喜好来进行选型，怎么办？第一、运维需要客观的说出会遇到的问题和风险；第二、我采用的方法就是交给研发自己运维，因为不在标准化运维体系之内，最后谁痛谁知道。

建立标准化的组件选型，就是让业务技术架构到最后就如同搭积木一样。

4、业务架构标准化

在统一的架构规范之下做研发约束比那些任意选择架构的要好得多。可是在现实的情况下，遵从统一的架构约束是多么困难的事情。因为人的问题，到最后对架构的理解必然是不统一的，后果就是各出奇招，怎么方便怎么来，怎么爽怎么来。简单来说，运维需要和研发设定一个标准化架构类型，让大家统一遵守，见过有些研发写的前端程序竟然不能接入LVS做负载均衡，这明显是无架构约束。有了统一的架构标准，目标是冲着架构的可运维性而去的，这个时候会反向对研发程序提出要求。此时运维可以列出很多架构设计原则和要求，如负载均衡、动静分离、读写分离、容灾容错等等，特别是基于前面提到的标准组件。

5、协议标准化

在一个小的业务系统中，可以统一采用http协议，随着架构的复杂度越来越高，架构会逐渐分离出接入层和逻辑层，那么接入层和逻辑层之间的访问也建议最好统一协议。基于统一的协议，后续的测试框架都很好实现；基于统一的协议，后续的运维管理、监控也很容易实现。

第二步：服务化

这一部分是对上面的组件化服务进一步升华，也可以把他理解成“架构及服务”。

当我们对组件做了标准化的选型之后，服务能力会从过去的分布式逐渐走向集中管理。就拿图片存储来说，之前各个团队自己实现图片存储，用NFS、ftp的，最后运维推荐fastdfs（我们现在用的是ssdb），但依然存在一个问题，每个运维团队都维护fastdfs还是成本太高，特别是面向业务的一些应用场景需要做重复性开发，比如说图片的多规格处理、图片的压缩等等。此时运维该驱动让这类组件管理公共化，走向集中式，统一实现以上所提到的业务需求。再往前一步，做可视化管理，避免运维在操作系统中进行命令式管理，从而提高维护的效率和质量。

服务公共化之后，运维方面的能力变得更聚焦。之前每个人都需要掌握的能力，后续可以按照技术栈的要求来设置运维角色，最终能把面向业务的运维思路转换到面向技术架构服务的运维思路上，做到和业务无关。这一点对于海量业务来说，非常重要，可以大大减少运维成本和业务的可运维性。

当前在公有云IAAS或者PAAS，这块实现得都非常的好。他们都把技术架构中涉及到的能力统一抽象成服务，提供api的形式供应用使用即可。比如说分布式cache服务，在传统的架构中，大家要么使用mc或者redis，但到公有云平台中，他们提供的分布式cache服务，统一支持mc协议和redis协议，此时公有云不是提供mc或者redis服务组件。对于应用来说，服务能力是透明的，无物理感知的！

在我当前维护的负责业务线中，正推动业务正在往服务公共化转型，比如说把小文件存储接入到图片云系统、memcache

接入到浮云系统、把mysql统一接入到mysql HA系统（已完成）、名字服务中心、httpDNS服务等等。基础组件组还正在实现统一消息发布订阅服务，进一步解耦服务之间的调用关系；另外一个研发小组正在构建统一的业务灰度发布系统，进一步提高系统的灰度发布能力。后续还让页面端的所有服务接入统一防攻击的服务模块中，进一步提高系统的应用层抗攻击能力。

第三步：无状态化

在服务公共化实现之后，此时貌似看到了一个完美的状态，但事实是没有完美。在业务量不断上升、业务变得更加复杂的情况下，技术架构不断在变化，但此时需要有一个技术架构的运维标准---无状态化。什么是无状态化？在服务访问路径中，某个节点（无论是物理的还是逻辑的）异常，用户感知到的服务都是可用的。对其进一步深入解释，物理的节点包含机房、机架、服务器、LVS等等；逻辑节点，比如说某个接口、某个进程或者端口等等；异常，最直接的理解就是不可用；服务可用，无论是服务容错调度还是服务降级，都需要做到对用户来说是可用的。无状态化，也可以进一步细化成一些技术架构要求，比如说服务降级、柔性可用、服务双中心、过载保护等等，根据不同的业务和服务，在这些能力维度上的要求会有些不同。

无状态化对应用运维有了更进一步的精细化要求。首先需要运维对业务和服务进行重要性分级，对于那些核心的业务来说，最重要的就是双中心的要求了，比如说基础用户服务类、支付类、基础平台类等等。对于核心的服务路径，识别出来，做好容灾容错的识别，这个时候需要运维深入了解业务，并结合技术来做综合的判断，游离在业务之外，去设计技术架构是可笑的。

之前我们针对核心业务和服务做了一次单点的梳理，从三个方面入手：单点梳理checklist（节点级）、物理部署和依赖的外部接口。但最后效果不是太好，我个人的总结是因为这块人工梳理的成本太高，并且架构会变化，特别是规模很大的服务来说，这块的梳理更是复杂。不过在这个地方，我保留一个想象力，随着我们的名字服务上线之后，服务之间的调度关系一览无余，我们是否可以搭建类似netflix的“Chaos Monkey”服务来测试我们的服务可用性呢？

最近我们也在某个核心业务上，运维和研发、测试、项目管理组一起启动了个双中心的服务质量优化专项。我们分成了7个维度，如端到端监控、服务降级、数据双中心分布、客户端智能路由、SDK异常处理、过载保护、跨机房流量转发等等。基于这7个维度，我们又分解了17个子项目跟踪，差不多一个Q完成了整个工作，正在持续的演习验证之中。经过这次的专项改造之后，大家都对自己的业务有了更充足的信心，不再依赖机房、不再依赖网络、不再依赖数据库的底层同步、不再依赖人的运维处理等等。

其实在这条主线上，应用运维有很多东西可以做的，不仅仅考验运维在运维侧的能力要求，同时也考验运维在技术侧的架构能力。是否感觉运维无所不能？不是，我从来没这么说过。我相反更提倡运维和研发、测试、产品更全力的合作，没有一个人或者一个团队能完成以上我说的一切；另外大家需要共享责任，不要囿于团队的利益，把责任抛给别人，把利益留给自己，这是不利于以上事务的推进。

在三部走的路上，运维的能力是随之成长的，业务的可运维性也是随之提升的，提供给用户的服务质量也是越来越好的。此时我想说：

是不是要值夜班？是，但我们可以改变。

是不是要不断应对需求？是，但我们可以改变。

是不是就是一个服务器者和应用发布者？是，但我们可以改变。

是不是要接受开发对我们不懂技术的质疑？是，但我们可以改变。

最后感谢下，在UC遇到了很多不错的研发、测试、产品、项目管理、运维的同事，他们给予运维和我个人的合作和支持，让我一年多有机会实践了很多运维的想法，谢谢你们！