Opsworld-2016-主题介绍

少于 1 分钟阅读

Contact me

或者用邮件交流 jacky.wucheng@foxmail.com

0.你在本次Ops World上分享的题目、大纲及摘要是什么?

我本次分享的题目是《运维的数据银行-构建企业的CMDB》,主要会分为下面两大块来讲

  1. 资源管理系统,包括建模,流程控制,自动化等内容
  2. 服务管理系统,包括架构和核心原理的简介

其中一些比较通用的部分,我们打算在未来的几个季度开源。

1.如果重新选择,你是否还会选择做运维,运维你认为是能够做到多大年龄的职业,关于运维职业规划,你有什么建议?

我的答案是:运维这个岗位一定会经历,但是不会一直停留在这里。 首先我自己是运维起步,在网易做过IDC运维,后来在新浪做系统运维和业务运维,然后转应用研发和系统研发及其管理工作,目前在汽车之家做研发管理工作,我希望将自己的视野拓展的更广一些,能够跟一群志同道合的人做一些更大的事情。

另外我认为,在运维这个岗位上应该是年龄越大、级别越高越吃香,各种业务场景应对和故障处理经验是需要时间来积累的。而且运维这个岗位也有从基础到资深的垂直发展通道,越往上全局观越重要、积累越难,含金量就越高。

最后,我认为不懂开发的运维会在职业发展道路上遇到很大的瓶颈,我建议运维在开发技能方面也要跟上技术趋势。都说Devops,我认为真正从运维转过来的Devops才最懂自己,最能解决好自身的问题,从纯开发转过来的Devops总是缺少很多背景知识的积累,解决起运维问题来不是那么贴心。

2.能否给广大运维推荐基本你认为非常不错的书籍,并给下理由?

如果说到“术”的方面,如工具类的书籍(如Puppet/Salt之类),我认为最好的资料是官方英文文档,里面基本都有从浅到深的各种资料,猛喝咖啡熟读文档,会受益匪浅。

如果说到“道”的方面,我个人比较喜欢这方面的书籍,如唐文的《海量运维、运营规划之道》、 贝特西·拜尔等人合著的《SRE:Google运维解密》、等等,这些书能告诉你国内外的运维行业是由哪些知识块构成的,每个垂直领域内有哪些先进思路,帮你打开视野的同时指明了方向,然后想要深入下去的话,靠官方文档、实践、交流、加时间,相信一定能够成功。

3.你认为运维除了技术能力之外,最重要的能力是什么?

除了技术能力之外,我觉得最重要的能力是“时间管理能力”和“沟通能力”。“沟通能力”大家了解的很多,我就不多说了。

说到“时间管理”,我认为其实通常所说的“时间管理”并不仅局限在“时间”上,更合适地说应该是“事务管理”,如果手上事务繁杂是一个常态的话,这个能力尤其重要。 这里推荐几本好书:Thomas的《时间管理:给系统管理员》,戴维·艾伦的《尽管去做: 无压工作的艺术》,先读完这本书再去用GTD,尤其推荐《管理3.0 : 培养和提升敏捷领导力》能为你的对内管理和对外管理视野带来很大的提升。

4.在运维自动化方面,能否分享下实践经验?

这个话题太大了,很难在几句话里说清楚。我分享一下自己总结出来的几个基本原则

  1. 有管理层的高度支持,否则各方资源的协调问题会成为项目的致命因素,若很不幸,请尽快逃离。
  2. 标准化是前提,若很不幸,请尽快逃离。
  3. 控制需求的质量,过滤掉未想清楚的需求,否则所有人会疲于奔命并且毫无所成。
  4. 抽象建模,将业务场景转化为程序实现模型,考虑边界问题,进行取舍,没有一个方案是万能的。
  5. 控制开发节奏,Roadmap清晰,否则团队会心散,失去方向。
  6. 开发迭代,注重规范,摒弃散漫,人员团结有向心力,
  7. 注重验收和推广,否则就会有始无终。

5.容器越来越普及,你们有没有在生产环境开始部署容器,有没有实践经验分享?

暂时没有实践,但是团队在做技术储备,明年有项目规划。

6.随着云计算时代的到来,像DBA等许多传统的运维岗位可能会被取代,你如何看待云对运维的冲击?

我认为云对中低层级的运维冲击很大,自动化将取代他们的工作内容。但是行业依然需要高级别的运维,深知该岗位需要面对的问题,深知行业解决之道,通晓原理和架构,甚至有的还能上手改代码给公司或者外部社区提交Patch,参与到全球化的开源社区里,去贡献,去布道,这样的运维岗位可能不适用“运维”这个名词,不过这样的人是市场中的金子。

7.你对DevOps如何理解,你们是如何实践DevOps的?

我认为经历过运维工作的DevOps才是根正苗红,最理想的情况是,对运维进行培训成为DevOps,自己开发东西自己使用,自产自销的模型能将团队带入良性循环,带来很可观的滚雪球效应。据我目前视野所及,国外的SRE、国内的腾讯的运维,他们实践地比较好,值得我们借鉴。我们自己这块的实践还不够,需要继续努力。

8.随着互联网的发展,许多行业都在拥抱互联网,对运维解决方案的需求也越来越强烈,目前有许多运维大牛出来创业,提供运维解决方案,你对运维创业如何看?

运维工作涵盖了很大的一个体系,每个公司的运维场景和人员的工作模式都存在着各种习惯和风格差别。提出一个运维解决方案,用标准化的思路去解释和解决这个体系中的问题,我觉得标准化技术手段和标准化该岗位人员的工作流行为模式会成为这个解决方案在实施时遇到的最大困难之一,可能为了落地这个方案要换掉一批运维人员,或者该方案被抵制。

同时我对运维以解决方案的创业模式非常期待,希望能够早日看到行业里的成果。

9.在运维体系建设方面有没有经验分享,如果从头开始建设运维体系,你认为需要重点关注的点有哪些?

我个人认为最重要的方面还在于“人”

  1. 人是所有事件中最核心的因素,提高用人标准,进行末位淘汰。
  2. 初期可以采用Op团队产生需求给Dev团队开发实现的模式,后期需要重点组建Devops团队。将Dev转化为Devops和将Op培训为Devops并举,Devops同时背负运维和开发的OKR,形成自产自销的工作模式,不适者淘汰。
  3. 重规范、重契约精神,大于面子和交情。
  4. 权利和责任并举,职责明确落在单个人身上,不多人共担,不模棱两可。

只有找到高素质的人,组建高标准的团队,他们才能在规范的制定和执行,工具的研发和推广,团队文化的建设和推广等方面通力合作,不遗余力地去落实。 至于规范,研发,文化方面的建设每一个都是很大的话题,这里就不展开了。

10.关于运维工具的选择,你倾向于什么情况下选择开源工具,什么情况下自研,为什么?

我偏向于选择”开源工具+二次开发“的模式。

如果开源工具满足以下几个原则我会选择,否则会选择自研:

  1. 非常适合当下的问题场景
  2. 扩展性好,定制开发灵活
  3. 原理清晰,文档丰富
  4. 有强大的社区或者商业公司支持