运维杂谈

前几天和一个朋友聊天，谈到运维的方方面面。简要记录如下：

1、关于运维愿景

建立标准化的运维体系，打造透明化的综合运维服务平台。

2、关于运维团队和个人的定位

我一直把运维团队的定位是在技术服务团队，个人也要朝着技术服务的方向去发展。单纯的服务定位对整个团队的发展不是非常有利，会逐渐沦为救火队员和保姆的角色，有点高级人员干着低级的活的感觉。

3、关于运维团队和个人的价值

这个价值是随着运维的阶段变化而变化的,我之前在一篇文章中阐述了我的观点，我把运维分成几个阶段-----单机运维、组件化运维、服务化运维、云化运维，在每一个阶段都有他各自的特点。但是对于运维人来说，有些特点是非常需要关注的：

A、 开放无边界的思维模式

B、 构建业务和技术能力象限模型

C、 激情和热爱

D、 运维团队需要提供运维服务包的能力，不是碎片化的服务。

4、关于运维组织结构

技术和服务的团队定位，需要有不同的团队构成。

在YY的运维团队划分是：一线运维、应用运维（业务运维）、平台运维（网络、系统运维、数据库）、运维开发（运维监控和工具开发两个方向）、IT运维、应用运维、安全运维。

在腾讯部门运维团队：分成三个中心：

运维中心：前端运维、中间层运维、数据层运维、基础运维、运维开发

运营分析中心：面向产品的运营分析和数据挖掘、面向技术的运维数据分析（没有挖掘）

基础架构中心：负责公共组件的开发

运维组织结构的核心原则：在业务的快速发展和变化之下，运维能力保证能够与之很好的匹配。

5、关于运维团队建设

结合技术+服务的方向，建设相应的运维梯队（高级、中级、基础），高级运维人员是有着丰富经验的运维人员，非常了解业务和技术架构，并且能够提出未来的优化方向，有人才培养的动力和欲望；中级人员，在一定程度上能够带领基础运维人员很好去执行运维的优化，需要有很强的执行力，有进一步成长的欲望；基础运维人员，一般是工作经验不丰富的，比如说应届生。

运维团队的文化建设非常重要，需要一个轻松的文化氛围，实时的工作认可，无边界的积极主动沟通氛围。

运维团队管理人员，要坚持走动式管理，而非报告式，运维人员很忙，很难让他们把屁股从凳子上移开，跟你做一次完整的工作汇报，需要运维领导主动去找他们沟通了解工作情况。

6、关于ITIL

ITIL是一种流程化的最佳实践，能够让我们很好的认识各自的职责划分，在运维的早起阶段需要去强力执行，并使之固化。在ITIL中有11个流程外加一个服务台，11个流程我们并不需要全部去执行。最重要的几个就是发布变更流程、配置管理、事件、问题、可用性、容量(能力)、连续性等等。每个流程又有着不同的目标，可以按照不同的运维阶段来实现不同的流程。

7、关于D/O分离

早起提倡D/O分离是有必要的，对于清晰的职责界定有很好的驱动作用。在团队发展成熟期，不需要去提倡D/O分离，更需要强调技术驱动的DevOPs文化。

8、关于运维标准化（非常重要）

没有什么比运维标准化带来的基础架构简化更重要的了。从网络、到服务器选型、到操作系统os我们都需要有一套标准化的基础设施方案；到应用层，我们需要对服务的开发、测试、部署、监控需要有标准化的方案；在存储层，一定要按照应用的特点，选择相应的存储方案，比如说fastdfs解决文件存储、mysql解决持久化存储、redis解决高访问存储，这块不能选择过多的存储，比如说mogondb，越多的存储带来的运维压力越大。

一句话：运维的标准化直接决定了运维成本的高低，也决定了运维方案切换的代价。

9、关于服务框架

分成三个层次：网络框架（用统一的网络模型）、协议框架（统一的协议很重要）、服务管理框架、集群服务管理。这是服务的标准化框架，实现的层次越高带来的收益越高，运维的管理成本就越低。前三点看到的还是单个服务，能够对自己的服务生命周期负责。而最后一点，我们看到的是一个集群化的服务管理功能，能够有统一的名字服务管理，统一的容灾和容错方案。

10、 关于持续集成框架

持续集成框架，业界有一些开源的方案，其实如果可以，运维可以和开发一起来构建整个持续集成环境，从源代码管理、编译、测试（单元、自动化）、发布和部署、到监控整体价值链来看待，这个非常有意义。

11、 关于发布管理

好的发布管理是敏捷迭代的基础，发布管理一般分成网站类业务发布和daemon程序发布，daemon程序发布更复杂一些，需要考虑关联配置的发布，后续的发布监控等等。

12、 关于透明化服务

透明化的服务，其实是屏蔽了服务的细节，标准化服务输入因素比如说业务的访问模型、访问压力等等，并给出标准化的运维方案。

透明化的服务包括两部分，一部分是线下服务，比如说设备提供，iptable配置等等，这个可以运维自身优化提供webConsole来解决，类似amazon的OPWorks方案；一部分是线上服务，这部分需要和开发一起配合解决，特别是在自研服务上，线上服务透明化最直接的理解就是位置无关性，比如说zk构建的nameserver。如果在已有框架中有了名字服务中心，但无高可用的情况下，可以把先前的名字服务变成zk代理的角色，逐渐去状态花，高可用一致性的统一名字服务交给zk来完成就好。

13、 关于运维平台

运维之心---------CMDB

运维之眼---------监控平台

运维之剑---------自动化平台

运维之尺----------运维分析平台（用户测速、内部服务性能分析）

运维之核----------标准化组件

14、 关于运维的主要能力要求

A、系统性思考的能力（流程、规范、技术）

B、应对突发事件的能力（防患于未燃）

C、技术架构的透视能力（端到端监控）

D、平台建设能力（自动化平台）

E、规划能力，阶段性的去看未来要做什么

F、持续的推动能力，跨团队合作事务很多，这块很重要

15、 关于运维规划体系

A、 运维规范体系

B、 运维监控体系

C、 运维工具体系

D、 运维度量体系

16、 关于金融运维和互联网运维的区别

金融运维是规范式的，互联网运维是开放式、激情式的；金融运维的难点是对于商业产品的把控能力；互联网运维的难点是敏捷业务驱动下如何做出好吃的运维大杂烩。

17、 关于运维商业产品

在互联网行业，采用商业产品必然是不合适的，有成本的因素，有需求满足的因素，有平台开放的因素等等，但是商业产品反过来对于运维的借鉴意义是很大的。在商业产品中，我们能看到他的多平台的适配能力，多对象的监控覆盖能力，成熟的产品设计，稳定的产品表现等等。