应用运维三部曲，就是告诉你应用运维就该这么干！前端
在平常的工做中，应用运维是否以为本身很苦逼。好比说：mysql
是否是要值夜班？是web
是否是要不断应对需求？是redis
是否是就是一个服务器者和应用发布者？是sql
是否是要接受开发对咱们不懂技术的质疑？是mongodb
曾经有个研发想转运维，问是否要值夜班，若是是夜班的话，我就不转了。其实还真说明了一个事实，你作得好研发，还真不必定能作好运维哈。数据库
那咱们一块儿来探讨一下如何作好应用运维，完全改变以上你们对你错误的定位和认知，我把它称之为运维三部曲：api
在任何一个互联网的企业中，遵循这三部走策略，必定能够把应用运维有条理的作好（传统企业不敢说）。另外辅助工具化和数据化的运维平台支撑，应用运维就如虎添翼，会大大影响三部走的进程。但在本篇文章不去谈自动化和数据化运维如何作，主要是谈标准化、服务化和无状态化三步走的应用运维路径，看是如何实现，且一步一步的影响应用运维的，也能够看出对应用运维的一些要求。如下是其详要的论述：服务器
第一步：标准化
网络
标准化是应用运维强势走出运维，面向研发的第一步。一个应用运维，若是没有把标准化理解到位，我以为是不合格的，会给后续的运维带来不少问题，包括成本的上升、价值的体现等等。那标准化运维到底包含哪些？我以为能够小到一个进程的运行属主，也能够大到系统架构或者机房部署架构等等。此时照样能够用分层体系来进行细分，识别标准化运维到底要作什么？
一、基础设施标准化
和应用相关的有服务器、虚拟化、OS、机房部署、公有云等等。
服务器能够按照本身的服务类型选择几个标准类型，好比说CPU计算性（内存能够小一些）、内存性（把内存加大）、数据库型三种。在涉及到hadoop运算的企业中，能够配置多硬盘的服务器，好比说内置12块1T no raid的硬盘机器。这种标准化选型没有坏处，特别是规模愈来愈大的时候，会逐渐看到这种标准化带来的好处。第1、变动成本不断下降。硬件垂直扩展的方式，在规模下运维没法应对；第2、对业务架构造成反向的推进力，根据机型分布本身的服务组件。
虚拟化。并非每家公司均可以玩得起IAAS云，特别是基于Openstack，要投入大量研发和运维资源，可是对于任何公司来讲，不管大与小，均可以采用虚拟化的技术。不管是操做系统级别的Kvm、Esxi和Xen，仍是轻量级虚拟化Docker，都值得去尝试使用。虚拟化能够解决资源复用问题，突破OS的资源限制（好比说文件句柄）、资源收缩或回收等等，在web类的服务中，更须要去尝试。前期不导入的话，在后期随着业务规模愈来愈大的时候，虚拟化的导入难度会增长。
OS。在OS层面上，其实就是选择好你的操做系统和内核版本，不要任意的选型，也不要太相信操做系统版本更新带来的优化效果。注意别用32位的操做系统便可。其余的优化更多的交给应用优化好了，带来的效果更好、成本更低。
机房部署。这个要结合业务来看，选择几个稳定的机房就行了（通常都是两个）。以前在一家公司，网站类的服务分布在多个机房中，维护很是麻烦，任何一个机房的故障都会有业务的影响，最后所有收拢到两个机房中，运维复杂度大大下降。核心业务作双机房部署，非核心机房单机房部署，经过代理提供非核心链路出口的服务便可。
公有云。我把公有云也做为一种标准的基础设施，云由于其弹性能力确保了资源的获取能力。公有云能够完全的解放底层运维的依赖，让研发均可以作运维，虽然看似资源成本高了一点，但它给你争取的业务时间和运维成本呢？
二、应用环境标准化
这块很是简单，必定要对程序的应用部署环境作标准化约束。程序运行的属主、程序运行的目录甚至是配置文件的规范、log目录等等。以前在【多玩 YY 事业部 软件包 规范V0.1】中作过详细的标准化规范约束，详细目录以下，供参考：
这块对后续的工具建设要求有很大的影响，特别是发布工具、自动发现工具等等。一个标准化的环境，让后续的系统平台复杂度会大大下降，由于你无需处理那么多进程属主的问题，你也不须要考虑程序运行目录的问题，你可使用标准化的监控对应用进行监控，你能够编写脚本自动化发现服务器上运行的服务等等。若是配置文件是标准的状况下，甚至能够自动化生成业务拓扑等等。
所以我建议这个地方运维必定要创建一个标准规范，是真正的业务运维的根本。而让研发或者运维规范的全部基础就是生产环境必须严格控制在运维手中，不要让研发接触到生产环境，而且最后是平台化，这样还能够进一步约束运维。
三、组件标准化
在任何一个业务架构中，都能抽离出须要的组件类型，好比说cache组件、数据库mysql、文件存储、web组件等等。这个地方必定须要一个标准化的选型，和服务器同样。特别是对于大规模的研发组织来讲，这个标准化就更重要，直接影响了运维的成本、研发的效率甚至是产品的质量。
在YY接触过一个项目组，研发按照本身的喜爱，选择了cassandra、mongodb、mysql、redis四种存储，全部的好与很差，都是从本身的角度描述（忌讳啊），最后这个产品的结果是质量问题频出、没法快速迭代、运维还没法管理。
现实中会常常碰到研发就会根据本身的喜爱来进行选型，怎么办？第1、运维须要客观的说出会遇到的问题和风险；第2、我采用的方法就是交给研发本身运维，由于不在标准化运维体系以内，最后谁痛谁知道。
创建标准化的组件选型，就是让业务技术架构到最后就如同搭积木同样。
四、业务架构标准化
在统一的架构规范之下作研发约束比那些任意选择架构的要好得多。但是在现实的状况下，听从统一的架构约束是多么困难的事情。由于人的问题，到最后对架构的理解必然是不统一的，后果就是各出奇招，怎么方便怎么来，怎么爽怎么来。简单来讲，运维须要和研发设定一个标准化架构类型，让你们统一遵照，见过有些研发写的前端程序居然不能接入LVS作负载均衡，这明显是无架构约束。有了统一的架构标准，目标是冲着架构的可运维性而去的，这个时候会反向对研发程序提出要求。此时运维能够列出不少架构设计原则和要求，如负载均衡、动静分离、读写分离、容灾容错等等，特别是基于前面提到的标准组件。
五、协议标准化
在一个小的业务系统中，能够统一采用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完成了整个工做，正在持续的演习验证之中。通过此次的专项改造以后，你们都对本身的业务有了更充足的信心，再也不依赖机房、再也不依赖网络、再也不依赖数据库的底层同步、再也不依赖人的运维处理等等。
其实在这条主线上，应用运维有不少东西能够作的，不只仅考验运维在运维侧的能力要求，同时也考验运维在技术侧的架构能力。是否感受运维无所不能？不是，我历来没这么说过。我相反更提倡运维和研发、测试、产品更全力的合做，没有一我的或者一个团队能完成以上我说的一切；另外你们须要共享责任，不要囿于团队的利益，把责任抛给别人，把利益留给本身，这是不利于以上事务的推动。
在三部走的路上，运维的能力是随之成长的，业务的可运维性也是随之提高的，提供给用户的服务质量也是愈来愈好的。此时我想说：
是否是要值夜班？是，但咱们能够改变。
是否是要不断应对需求？是，但咱们能够改变。
是否是就是一个服务器者和应用发布者？是，但咱们能够改变。
是否是要接受开发对咱们不懂技术的质疑？是，但咱们能够改变。