本文根据高效运维专家群友文章整理并发布。欢迎关注“高效运维”公众号，以抢先赏阅诚意满满的各种原创文章。
嘉宾简介
王津银
他，曾经从业腾讯、YY、UC等知名互联网公司
他，维护的微信订阅号《互联网运维杂谈》每篇文章都有上万的点击率！
他，在2015年下半年创立优维科技，公司已成立在业界就引起强烈关注！
以下是老王在《运维前线》群分享实录，高效运维公众号授权联合首发!
开场白
其实开始我是想分享名字服务，这样才契合肖大师KVM群的气质，特别是看肖大师的分享，永远都是技术干货满满，不能拖它后腿。
但是肖大师说，不要啦，就想听听运维经历。这么一来，搞得自己跟一个运维典型似的，不过还真是个典型，后面再告诉你们答案。
再次感谢力哥的邀请，进入老王的唠叨时刻，老王隔壁干的事情今天咱不说哈。
老王的经历概述
我自己的几段工作经历如下：
经历发生了一点变化，最近自己创业了，后面再说哈。我把以上经历分成了几个阶段。
每段经历有自己的工作内容和收获。
1、起步阶段（广东普信科技）
第一份工作经历是研究生毕业之后，加入了一家电信服务商做电信系统研发，当时刚好碰到97电信系统迁移到我们开发新一代的boss系统。在这个过程中，自己参与里面一个电信资源管理系统的研发（CMDB比它简单多了），后来稀里糊涂就带团队。在此过程中，也参与过几个地方资源新旧系统的割接实施。这段经历给我带来一些收获：
规范意识。电信系统的研发非常规范，从需求到概要设计，详细设计，数据库设计都一套规范下来，到到现在我设计库表结构时候还带着tb（代表表名）,tf（代表字段名），要知道语句复杂了，这样标准化很容易查找程序问题的。
方法论的培养。方法论很重要，当年给自己影响最大的就是eTOM模型了，还有NGOSS的系统建设方法论，领域驱动设计等等。
这段经历，我把自己当成了一个开发者（其实是伪的），当时就兴致冲冲去腾讯面试，说要做OSS开发，其实到了腾讯之后，才知道我们那个开发不是开发。不过，腾讯，我还是来了！
2、积累阶段（腾讯）
腾讯是我的职业过程最美妙的旅程，从各方面塑造了我，非常感谢腾讯！开始腾讯工作的日子超级苦逼。
刚刚进入腾讯，我天天做发布／自动化构建，它们搞定以后，去做告警值班，然后去做需求。不过每个阶段都是顺应团队的需要。
做发布的时候，希望把发布规范和发布平台建立起来，所以我说我是运维发布做得最好的，手工做，平台发，梳理流程什么的；
然后告警量太大，无法有效收敛，我和我老大两个人轮流值班，确保解决方案集中输出，否则每个人处理告警不能形成解决方案，很快收到成效；
这个阶段迈过去之后，变更需求太多，能否再进一步优化，通过需求里面变更场景来提炼运维平台的建设。很庆幸自己熬过来了。
媳妇熬成婆，终于自己也成了核心员工，核心员工的最大好处就是能接触到更多的项目，可以多了解更多信息。
再后来去接手存储运维组的leader岗位，腾讯一个很好的地方就是在你上leader岗位之前，公司会有一系列的领导力课程带来过度过去，对比说第一家是稀里糊涂。
腾讯的经历收获最大，满满的：
建立了对运维体系的理解。从ITIL到工具化（还不叫平台化），从基础运维到业务运维／存储运维，从职能运维走向应用运维再到职能运维，自己都有幸参与了全部过程。
建立了互联网技术体系的理解。我所在的部门把运维按照架构组划分之后，自己很有幸参与了前端和存储小组的运维，技术栈非常全面，恰好自己也是核心成员，很多核心项目都有参与，所以便有了更多的体悟和技术的理解。
应和优秀的人一起做事。但是我们web运维小组，5个人，战斗力超强，推标准化，做平台，定规范，我记得我11年离开腾讯的时候，交接了服务器接近7K台給他人。现在优维的创始人还是来自于当时的铁三角，信任和配合非常重要的。
苦逼是让你成长的。苦逼是真正的让我们来成长的，有些人把它看成了机会，有些把它看成了折磨。那真实的苦逼之痛，很多经验才真正的进入到心里。谁苦逼，谁解决，就是大成之道！
腾讯让自己对运维了全面的理解，从前端到存储端，从流程到自动化，从工具到平台，从运维到技术研发侧等等。
3、释放阶段（广州YY和UC）
离开腾讯，加入广州YY和后来的UC，当时想把腾讯的运维经验复制到其它公司，很有意思的经历。经常有人说“你在大公司成功不代表是你成功，因为资源太多了”。那咱们就出去瞧瞧！
在YY和UC自己带业务运维和运维研发，所以能够一体化规划设计，落地实施。效率奇高，一般所有的系统就是三个月左右上线（监控除外），比如说CMDB／持续部署／itil流程系统等等。监控涉及到老的监控策略迁移，麻烦些
这个过程也有一些总结和思考：
不要太依赖运维研发。一般公司的运维研发资源很缺乏，有些需求可以在业务运维内部消化，其实很多运维人身上的潜能很大，很容易突破屏障。在YY有个大神，用shell脚本实现了这个持续部署在agent端的逻辑；在UC，有个小伙伴，自己从前端到后段研发持续部署，后来连小组的一个妹子都可以在ELK做一些管理开发了。运维小伙伴们潜能无限！
运维能研发就是核心竞争力。老生常谈了，不谈了，自己去体悟。
一体化的方向思考比单纯的运维建设更重要。把研发／测试和运维结合起来一起思考，然后同步建设运维体系，这个效果比单纯做运维工具平台更有效。所以很多时候运维就需要DevOps的思维，DevOps思维之一就是跨界思维。
名字服务中心。这东西我就是喜欢，在YY没搞定，到UC来，还是把它弄到线上业务去了。
从一开始就研究zk如何做名字服务，还看zk client实现，就是为了实现一个，记得在YY的时候，还在论坛写过一篇文章，如何把单点调度中心daemon透明化的切换到zk上，开发没鸟我，其实我更不爽呢。
后来来UC，我还讲名字服务中心（搞得跟某种情结似的），和一个架构牛人一说，一拍即可，成功了。上次在一个线下沙龙专门分享了这个主题《名字服务的设计与实现》，后来有人说我是做研发，暗喜。自己有时候有点死磕的劲，这种死磕的劲头到创业也是如此。
因此我建议在大公司呆久了，一定要出去走走。
UC是一家很棒的公司，执行力超强，我很喜欢这样的公司。
4、提升阶段（创业阶段）
我把它概括成我现在的优维创业阶段。说说我的创业初衷：就想用互联网运维这套解决方案来替换掉ITIL的IT管理体系，同时缩短传统企业到达互联网运维路径。可能么？不可能么？反正我知道互联网＋业务成功了，那么作为IT支撑的互联网运维也应该是靠谱的。
提升来自于两个方面，首先是行业的，运维苦逼不要的；其次是自己的，运维屌丝不要的，我们就要做一些改变自己和有趣的事情。改变行业其实是整体运维人的事情，我还不敢说哈。
那么我们现在做哪些有趣的事情呢？我们的运维产品只分成两块：自动化（ITOA）和数据化（ITOA），一个a是automation，另外一个a是analytics。自动化聚焦在持续交付，数据化聚焦在分析法（analytics），这块分智能监控和数据分析，而它们的基础就是元数据共享化，姑且称之为CMDB（为啥叫姑且呀）。
今天不分享产品实现和形态了（年后就有SaaS版了），分享几个有趣的事情吧。
一个是产品方面的。我们为了向客户有力的证明，我们提供的平台方案是靠谱的，我们把自身系统架构全部接入了名字服务＋服务染色＋自动化测试，实现了端到端的监控体系。
如果一个互联网产品自身没有做到这点，那么他的产品和方案是没有说服力的。我们希望能传递Best Pracetice給客户，而非仅仅是一个运维平台本身。
一个是理念方面的。我们把运维平台的理念做一次完整的重构，从整个体系到每个产品方向，比如说姑且的 CMDB 我们把其理念和使用场景做了一次完整的重构，把CMDB的资源管理管理分成基础资源管理和业务资源管理，同时找个点结合。
这样就保证了面向资源中心的CMDB和面向业务的CMDB可以独立运行，甚至面向业务的CMDB可以不依赖底层的基础资源CMDB管理。
业务资源管理，我们现在称之为业务信息管理平台（BIM），都不叫CMDB了，免得误导。我们想重定义产品形态！
有趣的东西很多，因为很多过去脑子中的想法一步步变成产品，很多人运维人肯定都想这样，不是么？
在此搞个小广告。欢迎大家加入优维哈，我们在广州和深圳有研发中心随你挑选加入哈，可以一起做更多有趣的事情！
我的运维之路其实挺折腾的，呆过几家公司，只因那“胸中燃烧的梦想”放弃了三次股票（腾讯／YY／UC），真的算是一个＊＊运维典型。
我真的呼吁大家一起参与到互联网运维创业的队伍中来，大把的机会和广阔的天地等着你我发挥，真正树立一个互联网运维的新型IT服务形态－－－IT运营管理。
其实还有很多运维人为了运维都非常努力，在全力组织全球运维大会，提供一个舞台給运维人，非常赞，再次感谢老萧！
欢迎大家前来参加今年3月25-26的全球运维大会·深圳站
http://gops2016-shenzhen.eventdove.com/
我到时候还有一个主题分享：题目为“面向IT高性能的精益运维体系”，这次我把内容重构了，更全景的去看精益运维，从理论／框架／实践／工具／组织等多个角度解读一下。
最后感谢肖总，感谢几个微信群连播的同事们，大家辛苦了！
好消息！福利来了
具体的运维平台从概念／框架／设计到实现，请见老王的PPT《运维时代，全栈DevOps运维平台的设计与实现》
http://pan.baidu.com/s/1bouculx
Q&A
Q1：王总，运维包含的技术太多，太杂，您是如何去学习的？
答：的确技术太多，上次看一个devops技术元素周期表，觉得内容太多了，看着我都有点寒。技术很多，但还是有些方法可以去学习的
第一、运维故障是最好的老师。每次故障发生了，一定不要只是浮于表面的解决，要深层次挖掘原因。
第二、要不断的打开知识谱系。举个例子,大家打开top命令，其实在现实cpu占用那一行有很多cpu的占用指标，系统调用，用户调用，硬中断／软中断。如果你每个知识点走进去，发现很多原理性的东西。
第三、还是要和高手多交流，身边的很多牛人都是很好的学习资源。
第四、业务运维不建议把自己定位成技术达人。人的精力有限，很难在多个维度上达到最优，但你需要知道远离，技术特点等等。
Q2：关于运维团队的建设有什么好的建议么，怎么一步步提升运维的价值的体现？
答： 团队建设方面首先还是要看你的业务规模，基础设施情况，这些都决定了你的运维阶段。然后团队的价值观要有，之前在腾讯提炼的质量／成本／效率／安全很实用，不过你需要在不同的阶段，要对以上指标有不同的理解，什么是运维质量，什么是业务质量，什么是资源成本，什么是业务成本等等。
其实团队建设，还设计梯队建设，还有一个多样化建设，需要有女性伙伴，这个是2015年高性能IT组织里面重点提出来的。
Q3：怎么着手做运维标准化和规划化呢，比如流程规范/配置规划/数据规范等？
答：关于规范化和标准化，他们本身就是可以标准化和规范化，关键是你看到你运维的IT对象层次是什么样子的，从硬件层次／到OS／到组件／到应用部署／到业务调度（多机房部署），都可以找到具体的运维标准化和规范化的落脚点，除非你对他们运维认识还不深刻。
Q4：故障的原因挖出来的大多是痛点（或者技术债），对于这些问题怎么办？
答：第一、绝壁把问题留给人或者流程来解决。很多故障发生了，然后“头疼医头”似的找解决方案，比如说交换机故障了，就让增加交换机的处理效率，从来没想过核心业务和非核心业务分离，然后让核心业务跨机柜部署什么的。
第二、把问题转化成架构优化的绝好机会。其实问题是运维最好的老师，你如果只看到问题的浅层次问题，那看到的是技术债务，你如果看到的是深层次问题，那就是技术优化。哪个架构没有技术债务呢。
第三，问题需要预防，很多最佳的架构实践已经指出，我们充耳不闻，就有点不对了，大家可以看看腾讯的海量服务之道。
Q5：你在考虑运维系统架构是从自上而下还是自下而上出发的，从哪些维度评估你的决定？
答：之前我分享过一篇文章讲运维自动化的，恰好昨天晚上还在回顾这篇文章。我的观点还是明确的，系统整体架构的设计一定是自上而下的，需要顶层设计你的框架和原则，然后系统建设可以自下而上，分而治之，逐步实现。
Q6：在实施过程，当前运维体系是否要推倒重建还是优化整改？
答：其实这和技术架构的观点一样，是持续迭代，不可能过度设计，也无法超前设计，因此运维体系的完整性是随着业务规模的变化而变化的，动态的去看。在腾讯，自动化调度系统织云非常重要，可是我来到UC之后，发现自动化调度系统貌似没什么必要，业务整体扩容和调度很少。场景不同／规模不同／复杂度不同／业务不同等带来的运维体系建设结果都不同。
Q7：怎么着手做运维标准化和规划化呢，比如流程规范/配置规划/数据规范等？
答：流程规范其实结合运维场景是最好的了，比如说持续部署，持续交付等场景。这个场景在运维内其实是可以根据IT维护对象和变更的场景来提炼的。IT维护对象，比如说DNS，就新增，修改，删除等等，很简单的系统实现就可以了。变更的场景就复杂一点，持续部署，有版本升级／发布／回滚等等，
持续交付更是从全业务变更流程来看，这个需要系统固化。