Sat 23 April 2016
简介《凤凰项目—一个IT运维的传奇故事》由Gene Lee等三位运维领域的大牛编写而成。讲述无极限汽车零件公司如何在痛苦中通过团队的努力,共同实践三步工作法实现浴火重生的故事,三位作者现在都是公司管理层,所以书中既有运维工程师微观视角,也有管理者的宏观视角。 Ruddy Lee老师说他跟工程师打赌,工程师一般都翻不到36也就不读了,原因是大家都有阅读焦虑症,日记小说般的结构无法快速的找到技术重点。我也觉得工程师很难读完第一部分,原因是工程师大多会恨得牙痒痒,把书撕了!里边有太多我们曾经经历过的场景,那些让我们痛不欲生的经历。 整本小说的主人公叫做比尔,担任运维总监的角色,比尔通过自己的努力,让运维部、开发部、测试部、业务部门联合起来,为公司实现了业务的成功。所以小说的视角主要是在运维领域。 在任命比尔担任IT运维负责人(运维总监)之后,CEO提出的期望:IT系统运行可靠高效,为业务部门提供保障,尽量减少运维中的故障,让业务部门集中精力完成凤凰项目运维分工 分布式技术运营:Wes IT服务支持:Patti IT故障接口人 升级电脑、更换电话号码 部署新程序 混乱的IT部门推行秩序的角色 第一部分:人间炼狱我将第一部分命名为:人间炼狱。这个阶段里,运维故障天天有,争吵、指责、敌对充斥着每天的工作。 根据时间线,我整理了如下的问题: 1. 公司整体问题
2. 运维管理问题
3. 运维问题1. 计划外工作
主人公临危受命,第一个要解决的问题就是工资核算系统的故障,这次经历让比尔认识到运维团队现在乱的像一锅粥。重点内容如下图所示: 重点问题:没有实质上的变更管理,运维工作处于失控状态
紧接着,比尔就遇到了第二个问题,疲于奔命,到处救火,这就是很多运维团队的真实写照。这件事之后,主人公尝试向CEO申请更多的资源,希望将重点放在凤凰项目上,得到的答案是没有资源,所有任务都要完成。 重点问题:运维团队超负荷工作,没有资源,尤其是关键资源一直处于饱和状态。作为运维总监,比尔对团队的工作内容与状态一无所知
重点问题:此次事故充分暴露了运维团队缺乏事故处理机制与预案,团队缺乏信任,推卸责任严重。过度依赖关键资源
重点问题:IT设备采购周期太长
这是直接导致主人公和CEO闹翻,最终辞职的一次事故,发生在凤凰上线部署之后。这次事故也让无极限遭受极大损失。 重点问题:CEO无视运维的基本规律,擅自干涉运维工程师的工作,逼迫工程师瞎忙碌
2. 凤凰项目凤凰项目是这个公司的希望,更是一场灾难,在小说第二部分甚至得出结论,凤凰项目就不该被批准。 重点问题:这是我见过的最有代表性的项目,艺术源于生活而高于生活,凤凰项目基本集齐了所有我们遇见的项目问题,延期,质量低下,着急上线,环境不一致,未经测试,互相指责,工期不考虑测试与部署。差点就召唤出神龙了,具体请看图 3.运维流程过于复杂陈旧无人遵守流程:申请生产环境变更到实施的周期太长 4. 黑锅王往来邮件必称“由于IT故障” 5. 关键资源瓶颈
4. 团队管理与协作问题1.运维团队重点问题:
2. 开发团队重点问题:研发过程依然是没有价值可言的,业务人员缺乏IT常识是致命的,从这可以看出整个公司几乎不存在协作氛围,团队之间缺乏基本的信任和依赖
3. 安全团队安全团队最大的问题就是没有整体思维,只关注安全问题,忽略整体利益
5. 思考和改进关于运维的四类工作的划分:
金句:
第二部分:改邪归正我将第二部分命名为:改邪归正。在这个阶段里,运维、开发、测试、安全团队携手合作,将凤凰平稳向前推进。这部分更重要的一点是,IT团队对业务目标的理解以及IT系统与业务目标的对应关系有了深刻的认识。什么系统更重要,为什么要上线监控系统的背后逻辑是公司的业务目标。 寻找改变的方向:凤凰失败后的对话破冰会议
如何提高流量:项目冻结后的对话
基于约束点的优先级排序:项目解决准备运维的本质:帮助业务实现成功和COO的对话,让比尔了解了运维的本质,任何的决定都是围绕业务的成功,比尔需要弄清楚哪些业务对应着哪些IT系统,哪些很重要,怎么和业务协作来优化运维管理。 了解运维到底在如何支撑业务运维与业务的融合运维团队对公司的业务目标达成一致,关键业务以及对应的IT系统,主要风险,对应的改进措施 第三部分:涅槃重生我将第三部分总结为“涅槃重生”,我想这也就是作者将书名叫做凤凰项目的原因,在这个阶段,比尔带领研发团队、运维团队、测试团队和业务团队一起快速交付了独角兽项目。为公司实现了盈利,赢得了竞争。
如图所示,针对自己项目的详细分析,完成价值流图梳理和设计,可以帮助我们识别主要问题环境,优化价值流速
后记三步工作法第一步:帮助我们理解在工作从开发部移向IT运维部时该如何建立快速工作流,因为那就是业务部门与客户之间的衔接第一工作法是关于从开发到技术运营,再到客户的整个自左向右的工作流。为了使流量最大化,我们需要小的批量规模和工作间隔,绝不让缺陷流向下游工作中心,并且不断为了整体目标(相对于开发功能完成率、测试发现/修复比例或运维有效性等局部目标)进行优化。 实践:持续构建、持续集成、持续部署,按需创建环境、限制半成品,构建起能够顺利变更的安全系统和组织。 第二步:告诉我们如何缩短及放大反馈环路,从而在源头上解决质量问题,避免返工第二工作法是关于价值流各阶段自右向左的快速持续反馈流,方法其效益以确保防治问题再次发生,或者更快地发现和修复问题。这样,我们就能在所需之处获取或嵌入知识,从源头上保证质量。实践:
第三步:告诉我们如何建立一种文化,既能鼓励探索,从失败中吸取教训,又能理解反复的实践是精通工作的先决条件第三工作法是关于创造公司文化,该文化可带动两中风气的形成:
实践:
四种工作类型业务项目IT内部项目
这些项目通常分散管理,没有集中跟踪,有具体预算所有者负责,DevOps需要对IT内部项目进行管理 变更变更一般是由业务项目和IT内部项目这两种工作类型引起,一般会在问题跟踪系统中进行管理,在价值流的两个部分,开发和运维中分别管理变更会引起工作交接的问题 计划外工作或救火工作关键方法与实践三步工作法Kanban价值流图龙井的思考
比尔是公司的老员工,对公司有责任感,对公司员工有感情,否则在如此内忧外患,谁还愿意苦苦支撑。在凤凰项目部署前的最后时刻,依然不抛弃不放弃的劝说CEO、业务总监推迟发布
|
|