Oct 3

vim 配置 不指定

djangowang , 10:02 , 工作相关 » 其他 , 评论(0) , 引用(0) , 阅读(145) , Via 本站原创
vim配置


set number
set expandtab
set tabstop=8
set shiftwidth=4
set softtabstop=4
set autoindent
set fenc=utf-8
set guioptions-=r
set guioptions-=L
set guioptions-=b
set background=dark
set fenc=utf-8
set paste

Sep 30
点击在新窗口中浏览此图片

点击在新窗口中浏览此图片
Aug 23
开篇

这篇文章是对之前几篇文章的一个续,主要介绍项目开发过程中发生的问题并以案例的方式介绍。

前两篇文章
Docker2.0 项目过程总结  http://blog.puppeter.com/read.php?52
Docker3.0 项目过程总结 http://blog.puppeter.com/read.php?56

你真的了解你的用户么?
一个项目能够成功需要看是否了解用户的真实的需求,但很多时候与用户沟通发现用户是不知道自己想要什么的,所以这里就要收集很多数据帮用户来排序与选择并最终给他一个选择题。以下是一个未了解用户真实需求的案例。
年中公司团建内部小鲜肉(kanesong)组织了一个泰国团,我个人是非常想去泰国的因为确实没有去过也很感兴趣泰国的美食,但从以往经历上看这团并不好组织所以也协助小鲜肉在拉人。 这里我提前设想了一下尽量的让泰国团能够真的筹集到人数成团的方法。
首先私下问了一些比较熟悉的朋友筹集首批用户而首批用户以女生为重点用户,因为女的多了男的才会有去的心思即便不去也可能会帮我们吆喝。人数很快筹到了13个人差2个人就可以成团了,但心里知道很多已经入团的人仍然处于犹豫期的未必会去,所以要了解大家真实的需求是什么好趁热打铁,我们收集了大家的想法与需求后经过汇总分类后如下:
1. 我想去泰国,但之前去过所以只想去指定的地点与路线,譬如芭提雅;
2. 我想去泰国,但是需要了解最终的团费是多少。而最终的团费和出团时间出团人数都是有关系的没有最终成团前这问题很难回答;
3. 我想去泰国,但只在6月中旬有时间;
4. 我想去泰国,去哪无所谓,主要是能吃到地道泰国美食,看到真正的泰国人妖;
5. 只要泰国能在短时间成团我就去;
6. 没说肯定去,也没说肯定不去。
从需求看上去真的是众口难调,但仔细思考问题也不大我想如果能满足这类人群中的大多数的需求那少数部分也就不成为问题了。我们边收集想法边推广,以以上需求的角度,以团内都是美女的角度,通过秘书与大家口口相传希望能筹集到最后的最少两个人,不过随着时间的渡过发现很多已经入团的同学没有了耐心已经有开始有退群的打算了,我都是先说等有新人进来再退但很无奈人就是凑不齐。 一天同组同学老司机(brinkmai)组织了一个休闲的广东省内团(http://blog.puppeter.com/read.php?59)开始我并不太看好,因为我觉得大家都是年轻人年轻的时候就应该能走多远就走多远多看一下外面的世界, 而吃惊的是两周后听说人数已经筹够达到出团的要求。 brinkmai也在邀请我来这团,其实我本想的是如果泰国不成团我就参加数据组同事组的台湾团,不过发现很多组内的同学都参与了,从更多与组内同学沟通的机会上看最终我还是选择了这个团,当我进入这团的RTX群后人数慢慢攀升到了30人这也给我了很大的触动,为什么泰国团组建就这么难而广东省内肇庆团就这样容易,分析后发现团内老员工占比比较多,大家主要还是借此机会能够得到充分的休息,所以用户最真是的需求是实惠休闲,当能聚类出这类用户的需求的情况下组织一个团成功率就会高很多,虽然不能满足每一位团友的需求但已经抓住了主体用户的需求组织起来也就没那么了。




Docker3.0的过去、现在和将来
开篇中提到的是一个生活的案例,可以看到在组团前我们是有意识通过历史经验来提升组团的成功概率的,工作中做项目也一样如何让做的项目能够成功? 这就需要考虑的维度更多一些。下面来介绍一下Docker3.0项目(Docker3.0是我们开发的一个内部系统版本代号)我主要通过时间维度来介绍一下此项目的过去、现在和将来,并介绍在每个环节中遇到的问题与思考。

“过去”
1. SNG运维场景;
2. 容器在场景下的需求分析。

1. SNG运维场景:
我个人觉得我们运维了业界最复杂的系统,复杂的原因产品线多、产品历史悠久譬如qq、qzone,腾讯成立于1998.11.11到2018.11.11日正好20周年,qq也从花季雨季步入小青年,qq和qzone是我们业务的主干为了不断满足用户的需求我们在主干上也不断迭代新的产品特性,但也有很多产品特性随着时间被主流的用户遗忘而变为了长尾业务,而这些业务都在我们的服务范畴内复杂程度可想而知。我们在运维这样复杂的系统同时也需要与时俱进不断跟上技术的革新,譬如Docker容器很火在公司内部其他BG如游戏王者荣耀都在应用,容器在技术上实现了弹性伸缩节约我们的成本也统一了“交付物”,在业务层面助力了王者荣耀的快速发展,所以我们有理由相信我们SNG也是可以用的。经过与同事的讨论与之前的运维经验,我们分析出玩容器在SNG可以分为4个场景,以下是4个场景的优缺点:
点击在新窗口中浏览此图片      

2. 容器在场景下的需求分析
容器应用场景已经分析出来了,如果站在我的角度出发,我可能先做离线再做在线业务与离线的混部,同时在开发系统过程中我们肯定会发现很多问题通过发现的问题在来迭代下一版本的需求,但主线依然是以上所提的SNG运维场景,所以假如我对SNG运维场景做一个排序的话,我的优先级排序是 1 3 2 4 这样做的方式优点是风险比较低相对容易出成果。但实际执行过程并没有想象的这样简单要综合很多人的意见权衡利弊,以下是前期与中期收集了大家的想法。
大老板: 我们要做容器、 不追求上量但能力一定要达到,希望我们做的不要比其他BG差;
中老板: 支持容器机器,底线是稳定与易用可推广,建议与织云体验融合可以无感知的推广与上量;
小老板: 系统一定要做出亮点。通过实现弹性伸缩,解决效率问题的同时也解决了我们成本问题。
经过各种权衡最终我们选择了在线业务的弹性伸缩(4)是四个场景中最难的一个场景,有时老板思路占比重会大一些。
确认应用场景后内部对开发形式又有一些争论:
开发同学1(t3): 建议使用lighthouse(内部开发系统代号),因为lxc(全称Linux Container)通过lighthouse管理对它做简单的改造就可以支持Docker的管理,无需重复照轮子。
开发同学2(t2): 是否使用lighthouse无所谓,但没有使用过python心里没底,希望开发同学1更多支持与帮助, 不过经过最终的权衡选择了重新开发。
我个人观点: 开发1与2的同学观点都对我们在做系统的时候要尽量避免的重复造轮子,但也要尊重每个人的选择让每个人在项目中得到收获与成长,而后者的权重通常要高于前者。

“现在”
时间到了年中,现状我们已经开发出了弹性扩容的系统灰度了很少一部分业务但并没有上量,从技术角度看此系统是成功的达到了预期效果,但从上量角度看还短期达不到还需要很多细节打磨。 一天坐公交偶遇一个老同事目前已经是一家创业公司的技术骨干,我们聊起了我做的Docker3.0项目,他其中一句话印象令我十分深刻,他说在腾讯内部开发的系统没有规模上量是有问题的。实际上从KPI角度看在年中没有上量也是有问题的,我复盘了一下整个过程个人总结有以下几点:

1. 缺少对用户需求的理解:
从“过去”这环节中大家可以看到我们前期分析了SNG的容器应用场景,在分析的过程中也与负责业务与开发天天打交道的业务运维进行了沟通分析了痛点这里要说一下强调一下“痛点“这词,在聊得过程中我个人感觉有时确实用户是不知道自己想要什么的,只能描述出业务特性比较复杂开发与运维“交付物”不明确等,如果可以通过镜像来实现开发与运维的“交付物”,通过容器来实现弹性伸缩是可以解决我们的效率问题降低运营的成本。而我们忽略了最真实的使用用户是开发,同时也没有一套简易的UI来描述开发后的用户体验而开始开工建设系统,最后导致系统建设出来但最终的使用用户反馈新系统学习成本比较高推动困难。 所以最开始如果我们做的是离线系统,通过此目标建设系统在后续做在线与离线系统混部的环节能给开发提前演示效果,有可能会比当前状态推动会更容易一些。

2. 没有遵循目标最小化原则:
其中目标最小化原则是以最小的代价来满足用户需求,再通过用户的反馈不断的迭代新的需求;以下这张截图很形象的说明了目标或产品最小化原则,这思路也是来自《精益创业》 一书中提出了“精益创业”(Lean Startup)的理念。

点击在新窗口中浏览此图片

而现状是(如截图no like this)确实初期定的目标有些高,短时间推动上量很多细节需要打磨,譬如页面的用户体验、对用户无感知和与旧运营系统融合等等。而目标较高在KPI的背景下短期没有过多收益会有很多流言蜚语影响大家的心态;

3. 没有推动上量的手段:
通常在内部开发的系统推动上量有几种方式:
1. 确实解决用户痛点,对整体(成本、质量、效率和安全)有明显受益;
2. 至高向下推,由leader或者更高职位的领导帮推动。 举个例子譬如安全,如果服务器不做安全加固短期可能没事,但万一出现安全漏洞服务器又没有加固就会导致数据泄露风险。而在没有安全漏洞的情况下,推动别人去做一些安全加固没有至高向下推是比较难推进的;
3. 通过其他手段譬如卡资源来推动本项目。 这里我们也没有做到,虽然我们组名叫计算资源组,但资源并不归我们负责用户上下线也不走计算资源组。2015年是节约成本年,很多产品业务快速发展拿不到资源,通过资源来卡业务是一个没有办法的办法,因为当时运营系统效率达不到弹性伸缩。但目前是17年业务手中不缺少资源,所以很难推动。
而目前1-3情况都不具备,没有一个很好的推动上量手段。

“将来”
0.  邮件记录每一个环节:
前期的需求分析、规划、里程碑、短期目标、中长期目标、参与人员和每次例会的内容都要记录邮件并定期输出,防止沟通不清楚和信息不对称导致项目出现的风险。

1. 不断的复盘与总结过程中发现的问题:
在“现在”这环节中,我们对项目的过往进行分析与总结,做项目还是要充分了解用户的需求,如果在用户说不清楚需求的情况下要拆分场景用产品最小化原则来建设系统,通过建设系统是否解决用户的痛点或是系统运营中的过程数据发现的细节问题来不断迭代下一版本,并在之前拆分的主线上慢慢前行同时还要不断的复盘过程中发现的问题并一一解决才做出一个好的系统。

2. 别迷信权威:
在项目开发很多思路来源于书本上的方法论,但书本上的知识方法论在项目过程中应用并落地还真不容易,所以不能不学这些方法论但又不能过于相信所有的方法论。

3. 尽量发现每个人的长处:
在项目过程中确实发现每个人性格是不一样的,所以在做项目的过程中根据性格特征每个人也有着自己的长处,有的同学不善于沟通但写代码很强,有的同学文档写的不错,有的同学推动能力很强,在做相同项目过程中发现每个人的长处可以让大家有成就感的同时推动最终项目的成功。



总结
本文标题是如何做一个项目,从本文第一个案例与第二个案例中看做的项目都不是十分的完美,大家看完可能觉得有些标题党的感觉所以这里介绍的并不是如何做一个成功的项目,而是在做项目过程中通过案例方式如如何将风险降到最低同时又能权衡利弊让大家受益最大化。当然在做项目过程中也有很多拿不准的东西以下留了一些过程中遇到的问题,如果是你应该如何应对也欢迎与我沟通讨论邮箱:8851970@qq.com 。 最后,引用爱迪生的一句话  "天才都是百分之九十九的汗水加百分之一的灵感。后面是那百分之一要比百分之九十九重要的多" 。

讨论的问题
0. 如果根据自己历史的项目经验觉得当前的方案是对的而老板又不这样认为应该怎么处理?
1. 项目开发过程中肯定会遇到很多细节的问题,当遇到细节问题争执不下时(在方案没有最终落地前,两方争执结论都是无懈可击的)这时找leader又两面为难不给最终建议,这时你应该怎么做?
2. 项目过程一但版本封板不准许增加需求,而产品为应对市场需求又怎需要增加一些需求导致版本期限延期,应该怎么处理?

Apr 14
作者:研究僧
文章地址:http://blog.puppeter.com/read.php?56

开篇
       我们在2015年中的时候就在做Docker1.0(琥珀 http://blog.puppeter.com/read.php?4),当时主要针对离线场景。到2016年初 Docker1.0(琥珀)已经小有规模,同时也解决了很多生产环境的问题,而得到大家的认可。在2016年3月份中心内部开始讨论要做在线Docker版本,而这只是需求并不是目标。所以我们从需求角度出发设定了目标,当时针对中间层(spp ,内部组建工具)业务进行了调研,设定目标是做在线业务的弹性伸缩,主要是通过Docker来解决资源的快速扭转,这样大家使用机器时一方面可以更方便地获得,另一方面可以减少人为参与上下线,将有限的人力用到更重要的工作中,使大家能快速学习与成长。
点击在新窗口中浏览此图片
  上面的这幅漫画很生动地描写了我们当时的心情(因为整个项目的难点不是技术,而是如何改变用户习惯与思路), 围绕这一小目标从2016.3.31发出第一封Docker邮件到目前已经有一年多了,经历了多次的PK,从技术选型、是否使用开源、人力的配备、项目的优先级等内部讨论,到为什么搞了这么久没有上量、Docker搞了这么多版本是否有意义、Docker的长期目标是什么、是否可以保持现有织云体验等外部质疑。我总感觉项目走在十字路口,选每条路可能都是对的,但每一条路都未必是捷径,总是在被挑战中。这里我不得不承认确实理想很丰满,现实很骨感,我们在谈理想时总想着要把我们的运营系统往前再走一小步,而落地到现实时,往往需要更多的时间、人力、每个人的情怀、领导的支持、需要顶住外界压力、寻找更多合作团队一起努力才能达到目标。 本邮件主要总结我们在项目运作中遇到的问题、对项目的疑问、我们的思路等。


0)如何开发一个项目
    因为我个人并不是专业的项目经理,所以项目开发的过程也是我学习的过程。我也在思考如何能把整个项目做的更好,能尽快达到短期小目标。前期我参考了软件工程的方法论需求分析、概要设计、详细设计、测试、维护和用户手册等,但感觉不是特别适用于互联网的项目管理。譬如软件工程中的详细设计基本拿到文档就可以开发写程序,而目前我们还做不到这样的详细设计,所以只能部分借鉴。后期我参考了《打造Facebook》一书其中的一章,个人感觉还是比较适用的,但在原有的基础上我也补充了一下本项目开发过程中的案例。
点击在新窗口中浏览此图片

1)描绘远景,设立目标
描绘远景,设置短期、中期和长期目标,这样在不同的时间需要的伙伴与切入点才一目了然。以下是我们项目的一个基本项目流程图(图2):
点击在新窗口中浏览此图片
图2 Docker项目流程图


2)头痛的需求分析
在收集想法,排查优先级的过程中我们也出现了一些问题。
前期我们会找很多业务运维与开发同事进行需求分析,分析的问题是用户从不同的角度结合自己业务来向我们提出需求,就导致了平台满足A用户就满足不了B用户的问题。
收集同事们的开发观点如下:
1. A开发,希望通过Docker能管理从开发->测试->上线到持续集成的整个流程。
2. B开发,希望能用开源工具譬如k8s来管理Docker,这样更符合业界玩法。
3. C开发,只要系统稳定能提供资源,使用什么都无所谓。
4. D开发......
收集同事们的运维观点如下:
1. A运维,希望保证与现网体验一致。
2. B运维,希望可以实现弹性伸缩,解决快速扭转设备及成本问题。
3. C运维,希望能实现弹性伸缩,解决人力参与问题。
4. D运维,因为其他BG都在搞混合部署,我们也不能落后,希望通过k8s把业务管理起来。
5. E运维 .....
以上是真实的前期需求分析,有意思的是这里有的问题是互斥的,具有代表的譬如A运维与B\C运维的需求,保持一致是保持完全一致还是部分一致莫衷一是。这种情况下,就还需要分析老系统为什么不能实现弹性伸缩,分析出老系统本身确实无法实现弹性伸缩,新系统又想要和老系统保持体验一致,这就是互斥的问题。上面只是我们遇到的一个问题,类似的情况还很多。这种感觉有点像做数独游戏(见图3),业务主要关注横向相加的结果,而我们还需从全局出发关注横向纵向的安排。所以分析下来有时会有点头痛,无法完全按照大家观点来开发又需要权衡大家的观点与意见,同时又要尽量反馈大家我们这样做的原因,所以有的时候系统开发出来,再找之前的用户时,会被吐槽并不是其想要的需求。

3) 总结版本控制的三个优点:
1. 方便总结与回顾。
记录每个版本的细节可以更好的回顾总结项目中遇到的问题、难点和后续优化空间等,为未来开发项目沉淀一些经验。
2. Deadline(截止时间)才是最大生产力。
每个版本都有版本的启动时间与截止时间且都由个人自己评估确定。我们工程师一般情况下每天或多或少会被一些紧急不重要的事打断,而项目在组内又有很多交集,如何确保合理安排项目时间交集部分减少不表要的等待时间管理,事物优先级排序就很重要,有了Deadline就是最大的生产力。
3. 版本一旦确定不接受其他任何需求。
特别在开发与外界交集比较多的项目过程中时间难以把控,只能是尽量的协调控制外部交集的时间点所以一旦需求确定,哪怕加一个很小的需求,项目之间有依赖关系都可能会导致项目的延期或项目质量的下降。关于时间评估这里有一个经验值,在开发与外界交集比较多的项目过程中,尽量是自己评估时间的1.5倍到2.5倍间,具体视情况而定。

4) 是否采用开源工具
我们现在采用了自研的方式来管理我们的Docker容器,但在开发的过程中也不断有同学推荐开源的工具,譬如messos\swarm和k8s等这些工具都非常优秀且有着庞大的用户人群和市场空间,我了解到的很多创业公司都有在应用,个人觉得这些工具的设计思路非常先进有很多借鉴的意义,更重要的是他就像一种行业的协议,特别在与其他公司交流时虽然公司的业务不同,但用了相同的协议这样交流起来更顺畅同时收益也更大。个人并不排斥开源工具甚至更推荐用谈理想没有问题,但现实把这些工具在内部落地就很困难,总结原因有以下两点:
1. 因为部门大、产品多、产品历史背景长、复杂接口调用、高于一切的安全管控和与老运营系统兼容等,在落地的过程中都需要考虑周全,而开源工具内部落地遇到这些问题不免需要进行二次的开发能力、这种能力不是一个人而是一个组都需要具备的,特别在海量运维场景下不同产品有自己的业务特性,开源组件未必满足业务特性,导致异常查找成本会很高。还有在看到其他的部门在使开源工具为符合内部业务情况下进行大量二次开发,当业界升级工具时又需要持续迭代等头痛问题。
2. 引入开源工具譬如k8s需要开启NAT功能而内部系统都是定制的为了安全关闭了部分功能的情况下又要打开,又要保障系统安全这两个问题是需要慎重思考与权衡的。
所以按短期目标来看,我们还是使用了自研的方式来管理我们的Docker容器,长期看开源工具已经在我们的蓝图中。

5)  原生Docker思路在内部应用未必是对的
Docker 官方文档强调(build - ship - run) 其中:
build: 构建镜像,把整体环境软件依赖包和操作系统用户态构建成镜像,更新配置通过版本区分镜像。而构建镜像方式又分为两种:
           1. 直接将软件包安装到已经生成的Docker中来打包构建;
           2. 通过Dcokerfile来构建镜像
           这两种方式我们都有应用,其中1对应Docker2.0 ,2 对应Docker3.0
ship: 通过docker register 来分发构建好的镜像。
run : 只要kernel支持,上层使用标准的协议镜像,就可以运行在各种环境下,迁移非常方便。
问题出在升级镜像版本时需要重启镜像,这种方式有优势也有缺点,看在什么场景下:
优点:
1.在并行开发环境下,通常最头痛的问题就是环境不一致引发的线上故障。 而在Docker场景下开发只需要关注镜像版本,运维只要关注资源利用率,OD分离互补干扰,解决资源利用率同时也解决环境的问题;
2.现网环境一致实现标准化,有了标准化就可以实现自动化;
3.镜像生命周期短,每次更新版本镜像需要重启镜像,如果程序质量有问题,譬如运行时间长oom ,进程不释放fd 导致磁盘满情况都能很好的解决。
缺点:
海量运维场景下,线上环境频繁的变更,Docker生命周期短频繁重启不现实。当然Docker在这方面也是有考虑的,譬如分层文件系统的引入,但分层文件系统有128层限制,且目前测试情况看到40多层性能出现下降,而负责的业务在部分场景下可能1小时内发布频率就超过128层限制,所以这种方案是有问题的。
在开始我一直认为推动我们的系统往前走一小步,让频繁变更的业务适应Docker比较短的生命周期是正确的,但实践证明海量运维场景下Docker原生思路中的优点在我们验证下是不可以的,因为业务分层运维、配置频繁变更、运维的生态系统不完善都是问题。 或许在不久的将来,整体运维观念改变,运维架构上有更方便的调度系统与服务发现功能的背景下,使用Docker原生思路才是对的。

6)规范”如果没有工具的辅助就相当没有规范
我们为什么要制定规范,因为规范是标准化的前题,而自动化又是基于标准化基础之上,所以我们要制定规范。但问题来了有规范就一定可以实现标准化自动化? 这个真的不一定。生活中法律是一种规范,如果一个美女穿着很暴露的衣服走在夜晚12点后的街道小巷,即便有法律这种规范遇到色狼的风险也是很高的,如何避免呢? 提高法律的惩罚力度? 我觉得会有点效果但治标不治本,这时美女要尽量不穿着暴露的衣服,尽量不要在夜晚12点后出门,即便出门也不要走街道小巷,才会大大降低遇色狼的风险概率。做系统与架构也一样,通过规范来让系统标准化收效不大,规范与法律相比并没有更多的处罚力度,这就直接导致了规范不到位,标准化没有里程碑,自动化遥遥无期。
我曾想借鉴一下业界譬如某阿是否也遇到过我们目前面临的问题,他们是如何解决的?是否可以借鉴。一次机会听某阿朋友分享容器其中也提到了规范,某阿一直想试着梳理规范流程因为某阿也分很多bg(business group)不同bg运营的业务不同人也不同导致规范也不同,在一个公司体系下业务有可能会被轮换,不同业务轮转到不同的规范下又要保持业务正常运行短期只能加人,长期需要梳理规范,分享的嘉宾也说曾多年试图将这里的规范梳理统一但是发现比较难,推动成本也比较高,所以这里container(集装箱)是解决的方案之一,试想一下集装箱的发明正式把很多不标准的东西变成了标准尺寸,这样在码头才可以通过工具自动的搬运这些集装箱提升人们的效率。而先有了规范再通过工具去约定,这样才能达到我们预期的效果。


待续。。。。。。。。。。。
Feb 26
以下是转自我同事(dorisbhwang)的一片文章,凤凰项目读后感在发此博客前我本人还没有看,但在看了她读后感后更有兴趣来读一读这本书。



凤凰涅槃,浴火重生
正文之前,一个职场老司机的困惑…..
作为一个在职场上混迹长达14年的老司机,从制造业的咨询顾问转变为互联网行业运维质量管理人员(QA),对于我来说可谓是破釜沉舟,从零开始。理想是丰满的,现实是残酷的,投入到具体的运维质量管理工作后,发现我无法再以这么多年沉淀的方法论,以体系化、职业化的姿态来开展工作,尤其是对互联网行业运维体系的生疏,技术上的空白,简直就是致命的…
在困惑无助的瓶颈期,偶然机会运维界男神梁爷推荐看《凤凰项目》这本书,凤凰二字不禁让我想到了凤凰涅磐,浴火重生,自己此时需要的不就是重生吗?既然从零开始,放手一搏,学习吧!
言归正准,此书与各种介绍技术或方法论的书不同,以一个故事的形式讲述了一个IT项目从即将“流产“、IT运维部门面临被拆分的囧境到逐步的通过一系列举措取得项目成功并实现业务价值的过程,浅显易懂,结合自己曾经经历的“难产”的项目(广东电信管线投资管理系统建设项目、HW配置器项目、HW PIA项目),仿佛身临其境,触动了身体上的多根神经,将触动我的几点总结下:

1、  变更管理
提到“变更”,我为之色变,变更无处不在,毫不夸张的说,我曾经被“变更”伤的很深,这是个忧伤的往事,此处省去一万字…首先为愿意正视在变更上存在的问题,并且愿意去为改变这种现状做出努力的管理者或决策者致敬,书中IT运维总裁比尔如是乎,接任总裁一职后,意识到IT变更中的问题,马上对变更流程做了梳理,
采取了如下的措施:
1)  梳理什么是变更,明确变更的范围(这与我想做的工作不谋而合)
附书中定义:变更就是对应用程序、数据库、操作系统、网络或硬件进行的物理、逻辑或虚拟操作,并且这样的操作可能对相关服务产生影响。
2)  执行变更审核流程,加大变更门槛,适当控制变更节奏;
说到这点,不得不提任何流程及工具的推行都会遇到各种阻碍,有些员工乃至管理者甚至可能认为引入流程阻碍了效率,如果再碰到了不好用的工具,那简直炸天了,所以引入流程和推行工具之前必须根据实际情况做深入的调研,多方面平衡,力求流程简化,工作易用,当然这事说起来容易,做起来难,也只能是智者见智了。
3)  变更可视化
做好变更记录,明确变更计划的制定者、变更对象、变更内容;
做好变更计划安排,发布审批通过的变更执行的日程表。
这一点其实没什么好说的,既定的工作如果都不做好安排,随着性子想怎么玩就怎么玩,活该你一天到晚忙到死,还没干成几件事情。
总之,我们避免不了变更,但我们要想办法避免紧急变更。
说到此处,我脑中呈现了一个变更管理的框架:
点击在新窗口中浏览此图片
首先从业务层面要确定变更的痛点,想要如何管理,以上内容不需要面面俱到,可以根据痛点有重点的进行梳理,如果有条件,落地到工具中自然更好。

2、  工作类型梳理
记得我当初刚接手运维部门的QA工作之后,为深入了解运维工作,曾问过几个运维同事的日常工作分类和职责是什么,小伙伴们给的答案居然是含糊不清的,我不知道他们是真的不清楚,还是不善于总结说不出来,抑或是不想告诉我,囧…书中对IT运维部门的工作类型分为:业务项目、IT运维项目、变更及计划外的工作。人的精力是有限的,当各类工作一窝蜂的摆到眼前,谁也不能面面俱到,必要时必须要有取舍,确定不同时期的重心工作,正确的时间做正确的事情。结合实际的工作,身边运维同学对于业务项目和IT运维项目这两类一般能按照项目节奏按部就班的走,但一旦引入了变更和计划外的工作,往往会打乱既定的计划,承诺给业务部门的服务无法完成,所以工作的安排要留一定的buffer,以支持没完没了的变更和计划外的工作(如业务各种突发事件,各类运营系统的bug) 。希望这个工作类型的划分也能够触动身边运维同学的神经。

3、  开发运维模式下的实践
1)标准化
“IT工作不仅是无形的,因此更难追踪,而且可能出错的地方也要多得多。“
因此为了避免出错,需要更严格和守纪律,把运营环境标准化,并把这些标准应用于开发和运维的日常使用。写到这里,情不自禁叹口气,这是我目前的重点工作,曾经为这个目标迷茫过、困惑过,此书看完,坚定了我做运营标准化工作的决心。
2)持续优化
作为质量部过程改进中心的一员,持续优化天然是QA的职责,如何防止问题再次发生,一旦发生了问题如何更快的发现和修复问题,建立完善的问题管理机制的重要性由此可见。
3)营造一种工作文化
鼓励探索和尝试,从失败中吸取教训,反复实践,至于如何落实,我想是团队管理者仁者见仁智者见智了。  

4、  工作约束点
在书中,一个运维工程师是工作约束点,任何工作少了他都无法正常开展…我表示无语,居然会有这样的事发生!在我的经历中,某个人成为工作瓶颈的情况真不多见,不会说少了哪个人天能塌下来。我想团队分工、团队共享和人力储备这些是人员管理的根本吧(纯属个人意见)。 诚然,除了人这个因素,工作中会有各种障碍,反思下我们是否主动识别过约束点,如数据质量差、信息不同步、流程混乱等,识别到之后是否尝试去打破它?至于How,以后再深入学习探讨吧(偷个懒)。

Ok, 到这心得就完了,对于如何继续开展接下来的运营质量工作,我经历了从混沌状态到逐步清晰的过程,可谓是“凤凰浴火,涅槃重生”,路漫漫其修远兮,希望通过我的努力,能够看到质量上的不断的改进和优化,哪怕是一点点。



分页: 2/6 第一页 上页 1 2 3 4 5 6 下页 最后页 [ 显示模式: 摘要 | 列表 ]