配置即代码 IN ACTION

Jenkins提供的可视化操作界面,为初学者提供了方便。但如果要频繁的创建、配置任务,通过界面操作,效率总是太低,不如脚本来得快捷。

最近在为一些运维项目搭建部署流水线,每个项目都需要十几个jenkins任务,有的甚至更多。如果通过界面一个个去配置,也挺繁琐的。按照SRE的原则,重复的配置工作属于琐事的范畴,应该尽量避免。

再者,按照配置即代码的原则,配置信息也需要纳入版本管理。而通过UI配置的jenkins任务,所有的信息都在服务器上,不好做版本管理。

本文主要是对最近工作的一个总结,主要解决2个问题:

  • 利用命令行工具创建jenkins任务。
  • 通过pipeline实现配置版本化管理。

利用命令行工具创建jenkins任务

打开“系统管理”->“Jenkins命令行接口”,如下图: 通过UI完成的操作,很多也能通过命令行来做,如任务/视图的增删改、任务运行等等。

  1. 下载jenkins-cli.jar到本地,确保本地环境安装了jdk。

  2. 准备任务模板文件, create-job命令需要一个xml文件,先通过UI界面创建一个示例任务job-template,把主目录/jobs/job-template/config.xml文件复制出来,作为模板文件。主目录具体的路径可通过“系统管理”->“系统设施”里查看。

  3. 修改模板文件并创建任务 修改xml中相关的值,如git地址,部署目录等。然后利用以下命令创建任务: java -jar jenkins-cli.jar -auth user:pass -s http://jenkins-server:port/jenkins/ create-job job-name < job-name.xml 其中: user:pass: 登录jenkins的账号密码 job-name:待创建任务的名称 job-name.xml:根据模板修改的xml文件

不足之处:

  • 项目的部署流程要求与示例任务相似,不然xml修改起来比较麻烦。
  • xml文件不利于后期的更新维护。

利用pipeline实现配置即代码

pipeline实现了部署流程和job的解耦,把配置信息放到一个叫jenkinsfile的文件里。 jenkinsfile放到版本库中统一管理。任务运行时,jenkins从scm获取最新的jenkinsfile文件,然后按照配置的内容运行相关命令,比如构建,打包等等。

这样,各项目的任务xml文件就变得相当简单,唯一需要修改的就剩下jenkinsfile的scm地址了:

如何创建pipelne请参考相关的文档,这里提供一个jenkinsfile的示例:

pipeline {
  agent any 

  stages {
    // 准备阶段,从git拉取代码
    stage("Preparation") {
      steps {
        git 'https://project-git-address.git'
      }
    }
    // 编译,打包阶段,利用mvn命令生成部署包
    // $profile为参数,从命令行传入
    stage("Build") {
      steps {
        sh "mvn clean package -P$profile"
      }
    }
    // 部署阶段:在远程deploy sever上执行deploy.sh脚本,
    // deploy.sh位于/root目录下。
    //脚本功能是从jenkins server获取jar包,然后部署到指定目录,并启动服务
    stage("Deploy") {
      steps {
        script {
           def remote = [:]
            remote.name = deploy server name'
            remote.user = 'root'
            remote.host = "deploy server ip"
            remote.port = 22
            //服务器是采用私钥登录的,这里需提供私钥文件
            remote.identityFile = '/root/.ssh/xxx.private'
            //如果采用账号登录,则提供登录账号信息
            //remote.account = 'root'
            //remote.password = 'xxxxx'
            remote.allowAnyHosts = true
            sshCommand remote: remote, command: "deploy.sh"
        }
            
      }
    }
  }
}

配置完成后,可通过以下命令运行该任务:

java -jar jenkins-cli.jar -auth user:pass -s http://jenkins-address/jenkins build *job-name*  -s -v -p profile=dev|prod
  • 如果觉得密码采用明文不安全,也可用jenkins生成的token代替。
  • -p key=value [-p key2=value2],如果任务有参数,可以通过这种形式输入。
Read More

拆书凤凰项目- 部署管道

经历了几个通宵,凤凰项目终于上线了,但部署的问题依然很严重,上周的一个变更部署,又花了一个通宵。总结会上,埃里克指出了问题的所在:虽然已经改善了工作流,但批量规模太大,部署涉及到太多方面,引发计划外的修复。需要建立起从IT运维部返回至开发部的不间断的反馈回路,在初始阶段就筹划产品的质量。

“如果每九个月才能打一发炮弹,就永远射不中你们瞄准的目标。别再去想那些内战时期的大炮了,想想高射机枪吧”。埃里克继续说道,“在任何一个工作系统里,理论上的理想状态是单一工作流,这样能让生产能力最大化,同时让变化幅度最小化。通过持续不断地降低批量规模,就能达到这种状态。”

开发总监克里斯说,连一个次要的漏洞修复部署都问题重重,我们无法承受每月一次的发布。我建议改成二个月发布一次。

这遭到了CEO斯蒂夫的反对,离购物季还不到30天时间了,由于延迟了很多的功能,预期的销售收益没有实现。我们没有时间了。

比尔理解克里斯的想法,要让笨重的凤凰项目起飞,的确不太可能。为了实现预期销售目标,比尔提议,组建一支特别行动队(Special Weapons and Tactics team,简称SWAT),叫他们去弄清楚,哪些功能可以帮助我们尽快达到收入目标。时间不多了,所以我们得谨慎选择功能。我们要告诉他们,为了完成这项工作,他们可以打破各种规则。这个建议得到了大家的认同。

究竟如何降低批量规模,实现快速的部署?比尔心里还是没谱,只好再次求教埃里克。埃里克又把比尔带到了MRP-8工厂,指着地面上的一长列设备说,那里的两道工序(喷涂、烘干)曾经是工作流的瓶颈,由于每项工作的准备时间很长,只好依靠巨大的批量规模来满足需求,把尽可能多的部件塞入烘房。但却无法满足客户的需求,即使客户愿意加钱,我们也无能为力。我们明白要提高生产力,必须降低批量规模,但每个人都说那是不可能的。

丰田公司的“快速换模”,为我们提供了思路。我们改良了流程,把四个工作中心合而为一,排除了三十多个容易出错的人工步骤,使整个工作周期完全实现了自动化,形成了单一工作流,并且去掉了所有的准备时间。生产能力一飞冲天。

“现在,轮到你了。”,埃里克指着比尔说,“你得想出办法来降低转换时间,让部署周期时间加快。”

“要怎么做?”,比尔还是一头雾水。

“把布伦特派到特别行动队中,和克里斯一起想想办法,如何才能保证在敏捷开发流程的每一个阶段,不仅有可推出的代码,还能具备能够部署这些代码的工作环境!”。埃里克严厉的说,“只要开发部和运维部协同工作,连同QA和业务部门一起,这个‘超级部落’就能够成就各种不可思议之事。”

“你们需要创建‘部署管道’,那是从代码签入到投产的整个价值流。那不是一种技术,而是生产。你们应该对所有东西都进行版本控制。所有东西,不只是代码,而是创建环境所需的每一样东西。然后,你们应该把整个环境创建流程自动化。在部署管道中创建测试和生产环境,然后彻底按照要求往里面部署代码。那样你们才能缩短准备时间并排除故障,才能随时跟上开发部的各种工作节奏。”

回到团队,比尔表达了埃里克1天10个部署的要求,每个人都觉得那是天方夜谭。问题出在哪里呢?为了弄明白部署流程,大家把部署所涉及的所有步骤都列在了白板上。从代码提交开始,也就是说整个流程包括了开发,测试以及运维的工作。流程优化必须从整个价值链出发,局部的优化没有意义。

比尔望着白板上几十个方框,让他联想到了工厂的工作中心,这不就是工厂的流水线吗?IT工作本质上和工厂是一样的,就是要打造一条价值流。这大概就是埃里克所说的部署管道吧。

现在,这条管道还体现不出价值,基本上每个环节都存在问题。但团队已经找到了思路,利用精益的方法,结合布兰特之前写的一些自动化脚本,自动化部署也不是那么遥不可及了。

Read More

如何拥抱“you build it ,you run it”

21世纪初期,亚马逊的应用臃肿不堪,经常导致服务不可用,贝索斯受够了这一切,强行规定应用必须通过web service接口来交互。同时推行新的准则“谁构建,谁运行”,团队的职责不仅仅是构建应用,还得让它在生产环境中跑起来,而不是像过去那样,把应用扔给其他团队。

亚马逊很快让应用扩展来支持快速的增长,在这个过程构建了AWS。 其他的公司纷纷想仿效亚马逊的成功。

亚马逊通过应用快速的规模化来支撑业务的发展,在这过程中打造出了一套web service服务(AWS)。其他公司也想复制它的成功,但这并不件容易的事。你需要面临组织架构需要大幅的调整,用户需求延迟交付,团队重组等等问题。但回报也是明显的,团队会比以前更快的实现交付。

那么,组织如何来拥抱“谁构建,谁运行”呢?

“谁动了我的奶酪?”:组织架构变更

构建云应用的第一步就是创建跨部门,多功能产品团队。没有专门的角色区分开发,测试,运维,系统管理员,dba等,但这些技能产品团队必须全部拥有。团队之间的依赖往往让人头痛,想象一下,团队完成了所有的工作,准备发布了,却发现数据库的脚本还需要数据团队来验证运行,你除了干等,别无它法。多功能团队消除了这样的瓶颈,团队成员可以自己来验证脚本,而无需依赖数据团队。

那是好事情,发布devops年度报告的团队研究表明,如果由外部团队来审查代码质量,还不如不审查。因为没有带来任何的质量改进。 一种有效的审查方式是结对审查,会带来更好的交付质量。因此,审查团队需要和产品团队更紧密的合作,变成团队的一员,这样的审查才能带来效果。

不要拖延客户的功能

Zynga是一家社交游戏公司,它的产品Farmville在facebook上发展非常迅速。但公司没有专注于快速满足用户需求,反而选择完善基础IT架构。放弃使用AWS,选择构建自己的云。最终没有成功,又重新选择了AWS。 但公司失去在手机端爆发性增长的最时机。

打造面向产品团队的组织并不意味着要从头开始构建基础云架构。 首先,用web service来构建云应用被证明是可行的,云服务更关注如何为软件提供良好的运行环境,而不是软件本身。其次,产品团队可以专注于产品本身,加快了创新的速度。 聚焦于用户需求而不是内部需求导致用户功能能快速的交付。

当你的巨无霸应用还要增加功能时,试着单独构建这部分功能,并且提供web service接口。巨无霸应用通过接口来调用功能。通过这种方式,使得你关注与你所擅长的:构建应用。应用运行的环境则交给云平台去处理。不要试图自己去搭建云平台,那样会耽搁用户功能的交付,用户会不满,从而影响你的商业目标。

改变是可怕的

让组织能持续产生有效改变的的唯一办法是让改变本身变得有吸引力。 改变是必须的,问题不是如何来改变,而是让团队想要改变。答案很简单:奖励那些投入并且驱动改变的。那些拒绝改变或者旁观的人最终会看到成效并做出选择。

为了成功,你需要一个变更催化剂。 所以,只要团队采用新的方式构建,交付应用的,立即给与奖励。当人们看到奖励了,偷懒的人会跟进。

但是,这不是可持续的方法。团队需要明白他们能做的更好,更快。 那就是自我实现,这是一个更有效的奖励系统。当团队看到自己的产品发布越来越快,并且更少的故障,他们会全身心的采用“谁构建,谁运行”原则。

亚马逊在2000年早期就采用了“谁构建,谁运行”的哲学。从那时开始,公司内部经历了组织架构的调整,面对延迟交付的无谓的害怕,让成员相信拥抱变化。 一旦你像amazon一样学会了有效处理这些问题,你会更容易的转向云应用,并且获得更多的回报。

In the early 2000s Jeff Bezos mandated that all applications at Amazon offer web services that other applications could use to access data and functionality. At the time, Amazon was struggling with a ponderous, unwieldy group of applications. Downtime was an issue, and Bezos had had enough.

Amazon not only rapidly scaled its applications to support growth, it accidentally built Amazon Web Services (AWS) along the way. It’s no surprise that other companies want to duplicate its success.

But it’s hard. You will dramatically change your org chart, run the risk of delaying functionality that customers are demanding, and say goodbye to many employees who don’t get onboard. The reward is clear, however: Your team will be able to deliver improvements faster than ever.

Here’s how to embrace “you build it, you run it” in your organization.

‘Who moved my cheese?’: Changing your org chart

The first step in building cloud applications is creating cross-functional product teams. No longer do you have dev, test, ops, system administrators, and DBAs. You have product teams that encompass those roles and skills.

One of the most frustrating aspects of application release is waiting on external teams to complete tasks that are blocking you. Cross-functional teams eliminate this bottleneck. For example, instead of waiting days or weeks for an external data services team to review an SQL script for execution, the product team can review and execute the SQL script themselves. Goodbye, waiting.

That’s a good thing. The research team behind the State of DevOps report found that companies with zero review prior to application pushes had the same IT performance as companies that had external teams reviewing change. That’s right: External reviews make no difference. The one type of review that did predict software delivery performance was peer review of changes. Thus, if you have a peer-review process, you will have better software-delivery performance.

That’s scary for the teams that perform those reviews. But if you move those reviews into the product team, your company will have better software delivery. Thus, the team members currently performing reviews must work closer with the product teams and become members of those product teams.

Don’t delay customer functionality

We have all seen companies that focus on internal infrastructure at the expense of customer functionality. Zynga was a classic example of how IT decisions can wreck a company. During the explosive growth of its Farmville app on Facebook, it decided to leave AWS and create its own cloud. Not only did it fail, eventually returning to AWS, but it missed out on the explosion in mobile gaming.

Moving to a product-team-oriented organization is not the same as building your own cloud infrastructure from scratch. First, it’s proven that using web services for cloud applications works. Contrast that to Zynga, which worked on how it hosted its software instead of on the software itself. Second, product teams accelerate the rate of innovation in a company. A focus on customer demand over internal demands results in better customer functionality that’s delivered faster.

You can test this yourself. Find a new bit of functionality you want to add to your monolithic application and build it separately, exposing data and functionality via a web service. Then have your monolithic application call the interface to use the functionality. Finally, improve it.

By measuring how each step takes, you’ll prove to others that you can deliver customer functionality faster. In the end, focus on what you are good at: building your application. There are plenty of good cloud computing options out there to house your app. Don’t make the mistake of trying to build one yourself. If you do, functionality will surely be delayed, your customers will not be happy, and your top line will suffer greatly.

Change is scary

The only way to see long-lasting, impactful change in an organization is to make change appealing. But change you must. The question is not how to change, but how to convince your team that it wants to change. The answer is simple: Reward those who engage and drive change. Those who fight change or sit on the sidelines will ultimately see the results and choose appropriately.

To succeed, you needed a change catalyst. So identify teams that are adapting to this new way of building and delivering applications and reward them immediately and loudly. As people see the rewards, the laggards will follow.

However, tha’s not sustainable over the long term. Employees need to see that they can perform their jobs better and faster. That’s self-actualization, which is a far more efficient reward system. As employees see that their own projects get released faster and with less hassle, they will whole-heartedly adopt the “You build it, you run it” mandate.

Amazon shifted to a “You build it, you run it” philosophy in the early 2,000s. Since then, it has struggled internally with changing its org chart, addressing unfounded fears of delaying customer functionality, and convincing employees to embrace the change. But as with Amazon, once you are able to manage these issues effectively, your move to cloud applications will be far easier, and much more rewarding.

Read More

you build it, you run it

“you build it, you run it”,构建代码的人,还得负责让代码在在生产环境中跑起来。相比我在之前一篇博文中提到的“eat your dog food”,职责范围又扩大了。开发人员不满了,代码是我写的没错,咱得分工啊,测试负责测试,运维负责部署,我都要参与,还能不能安静的写代码了?

这个观点不是运维或测试人员提出来的,所以不存在推卸责任的问题。这话是Werner Vogels说的,Werner何许人也,Amazon首席CTO。CTO代表着开发方,提出这样的观点,说明技术团队在整个软件价值链交付过程中的重要地位。在我看来,技术团队的职责不仅向后延伸,还得向前扩展,参与到前期需求的分析中。针对目前很多开发团队渐渐沦为设计团队的实现工具,我感到很是心痛。

这句话如果仅从字面上来理解,很容易让人误解,特别是还在采用传统接力棒模式的团队。

价值是衡量工作成果的唯一标准,代码如果没有部署到生产环境中,对用户提供价值。那就是一堆代码而已,没有任何意义。能否快速的部署,也是衡量代码质量的标准。在本地一切正常的代码,部署到正式环境,就会有出现问题,这样的场景大家都不陌生。对于上线系统的问题,开发人员是最清楚的,解决起来也最迅速,却在被排除在过程之外。势必降低价值交付的质量。

别让反馈环断了。

基础设施即代码

Read More

拆书《凤凰项目》

凤凰项目这本书几年前就看过了,当时是当小说来看的。如今虽然还记得大概的故事情节,很多的细节已经忘却。最近又拿来重新读,本想把书全部看完之后再来写总结,按照目前的进度是来不及了。只好中止阅读,先把看过的内容做个总结。按计划是上周要完成的,这几天脑袋晕晕的,无法静下心来,一直拖到了现在。

背景 正如我上一篇文章讲的,所谓的变革,一定是到了山穷水尽的地步,不得已采取的方法。这本书也不例外,作者一开始就表明了无极限公司面临的困境:CEO辞去董事职务,股票暴跌;公司期待“凤凰项目”来提高竞争力,恢复盈利能力,但几年来项目一再延期,上线遥遥无期。董事会决定再给6个月的时间,如果再无显著改善,公司将面临拆分重组。那意味着大批的人将失去工作。

见面礼 主人公比尔临危受命,虽然很不情愿,还是被CEO说服,担任IT部门的副总裁。比尔最重要的任务就是让凤凰项目尽早上线,其他项目都得为凤凰让路。

比尔新官上任,第一个见面礼是工资系统崩溃了,而且必须在晚上5点之前解决。虽然折腾到半夜才把问题解决,但错过了时间窗口,第二天公司就上了头条。这次事故暴露出的问题是变更流程缺乏。IT部门制定了变更流程,但从来没有人遵守。不但开发人员随意变更生产系统,就是自己部门内部人员,对变革流程都有很大的分歧。比尔的第一个改善就从变更流程开始。

凤凰登场 凤凰项目开发部门抱怨IT部门没能及时配置好测试环境,向高层汇报,说IT在拖整个项目的后腿。会议上开发主管声称下周就可以部署上线。在IT看来,目前连测试环境都没开始部署,下周要上线简直是天方夜谭。同时指责开发提交的产品性能连要求的一半都没有,IT不得不部署更多,性能更高的机器来弥补性能缺陷,这又导致工作量的增加。会议上,双方你来我往,互不相让。不幸的是,为了让项目尽快上线,扭转公司困境,CEO站在了开发这边,决定下周5部署上线。

火上浇油 为了应付外部审计,审计人员列出了厚达200页的问题,将近1000条。并要求下周给出整改方案。IT部门已经忙的焦头烂额,谁还能抽出空来应付审计?讨论中,比尔发现居然没人说的清楚IT到底有多少工作,很多工作都没有记录在纸面上,都在大伙的脑袋中。天哪,如果连自己部门有哪些工作都不清楚,凭什么去向领导要求援助呢?比尔要求马上整理一份工作清单出来。幸运的是,比尔的左膀右臂开始相互合作了,两人一起合计着如何来整理这份清单。这是一个好的开始。

变更流程改进 第一次的变更管理会没有一个人参加,比尔只得动用行政命令,在周五重新组织变更会议,缺席人员将受到行政处罚。周五的会议上,大家纷纷吐槽现有的变更流程,看来要按照现有流程是无法展开工作了。比尔拿出一堆卡片,让大家把变更写在卡片上,然后贴到画着日程表的白板上。一开始大伙有点蒙,这是什么玩意?有用吗?但还是有好奇的人把自己的变更贴在白板上,随后大伙也纷纷开始效仿。2个小时的会议,虽然只通过了5个变更,但重要的是,大家开始开始积极的参与讨论,讨论变更的风险,讨论变更是否必要等等。当各部门开始沟通了,我相信问题已经解决了一半。

导师降临 其貌不扬的往往都是高手,这点东西方认知还是一致的。未来的董事会成员埃里克要见比尔,比尔一开始把他当成送甜甜圈的服务员,和他聊起了自己和夫人是多么喜欢这家店的甜甜圈。等埃里克表明身份后,场面显得有点尴尬。

埃里克听了比尔关于如何改善IT效能的想法后,说你还没弄清楚什么叫工作,又怎能提高IT的效能?这让比尔很不爽,接着埃里克又拿工厂做比喻,向比尔灌输了在制品(WIP),瓶颈,三步工作法等概念,最后又让比尔回去找出四种类型的工作。比尔觉得IT工作不能和工厂类比,埃里克的话虽然记在心里,却也不以为然。

确立变更优先级 实施变更看板以来,不仅墙上贴满了卡片,会议桌上也小山似的堆了起来。要在变更会议上评审这堆卡片,估计得花几天时间。为了提高效率,团队调整了变更流程,首先按照优先级对变更进行分类。常规性的变更,因为经常在操作,基本无风险,无需讨论可以直接通过。高风险的变更通知业务部门,并告知相关的风险,由他们决定是否实施变更。中等风险的变更需要通知可能受影响的人,并得到他们的认可。由于事先准备充分,变更评审会议变得极为高效。白板的引入,让变更变得透明,透明又促进了沟通,协作。新式的变更流程让各部门都参与进来。合作,已经从IT部门内扩散到部门外。

未完待续………

优化瓶颈 变更流程跨出了良好的一步,Patti花了很多的精力整理变更卡片,却发现计划本周完成的工作实际只完成了40%,其他的不得不拖到下周。而下周有 会有更多新的变更。进多出少,Patti意识到自己将被卡片淹没了。这样的场景让Bill联想到了工厂的生产场景,大量的半成品堆积在车间。原因都是一样的,是瓶颈制约整个流程。这个瓶颈就是brent。优化瓶颈,首先得知道哪些工作会流向瓶颈。Bill让Patti把涌向布伦特的变更任务先揽下来,过滤处理,并在变更卡片上表示出来,甚至可以要求在所有新卡片上都标注这一信息。等我们知道和布伦特相关的变更是什么、有多少,就把结果反馈给你,还要确定它们的优先级。

风暴来临

计划5:30开始部署,4:30还没有通过关键节点测试,而开发已经下班回家了,只好全部叫回来修复问题。没人告知防火墙还需要开放端口,导致前端无法访问数据库。总之,快到晚上8点了,情况还是一团糟。 bill叫来了wes和patti,同时把负责测试的william也一起叫上,讨论当前的情况。 开发版本提交太快了,往往上一个版本还没测试完毕,下一个版本就来了。而且为了防止弄坏别的东西,提交的都是增量更新包。现在已经没有一个稳定的发布版本了。明天8点门店营业之前,恐怕无法让凤凰正常运转起来。 凤凰好歹上线了,但系统无法和门店pos机对接,所有的交易都得手工完成,财务部门不得不抽调大批人手来处理。系统还有泄露银行卡号的风险。性能问题严重,不得不隔几个小时重启。直到周一晚上,门口终于可以使用收银机了。虽然只是个临时解决方案,至少没有了信用卡号泄露的风险。

鉴于这次凤凰上线的失败,让董事会很是脑怒,CEO把责任都推给了开发部和IT部,计划拆分公司,并外包I T业务,这意味着很多人包括bill自己都将失业。

开发部的chris和bill一起吃了顿饭,现在火收到他们上了,他们得想想如何来应对,饭桌上,两人谈了各自的难处,开发部疲于应对各种问题,没有时间开发功能,项目部署需要的时间越来越长,技术日新月异,让人有点跟不上了。 chris说的代码完成时间,sarah认为上线时间,导致目前这样的局面。chris对此感到抱歉,应该听取william的意见,推迟上线时间。 最后,两人达成统一战线,共同对付sarah。

变更流程取得了一定的效果,有两个团队的变更都涉及同一个数据库,变更流程让他们看到了潜在的冲突病很好的解决了。因为凤凰上线导致几百个变更延迟,引出第四种工作:计划外工作。

优化瓶颈,没有围绕瓶颈做的优化都是幻觉。找出IT运维和工厂之间的对应关系。 不要让约束点迁就别的资源。 不惜一切代价消灭计划外工作 相比于向系统中投入更多的工作,,将无用的工作剔除出系统更加重要。为此,你应该知道,与实现企业目标息息相关的是什么,不论它是项目、运营、战略、法律法规合规、安全性,还是其他别的什么。” 他继续说:“记住,重要的是结果——而非过程、管理,或者你完成了哪些工作。” “别心烦意乱的。等你知道了怎样有效控制发往布伦特的工作量,就给我打电话

发票系统故障,盲目的行动可能导致更大的错误。这次重点在分析故障原因,没有许可,不允许对系统做任何的操作。晚上9点多了,问题原因还是没有找到,ceo坐不住了,让bill赶紧叫上所有人,行动起来,而不是像现在干等着分析结果。bill坚持认为他的作风是正确的,和ceo大吵一通,一怒之下,辞职不干了。

场外会议 如何建立团队信任,展现脆弱的一面。 当每个人都讲了自己的经历,bill甚至流泪了。生活中每个人都有自己的不如意,在会上分享,让大家相互间更好的了解。 ceo谈到IT的人不懂得如何去承诺,安排给IT的工作总是延误。chris认为自己总是完成了工作,wes马上反驳,如果是这样,凤凰也不会搞的一团糟了吧。chris红着脸说,代码确实按计划完成了。bill插嘴道,我们对完成的定义理解不一样。开发部总是没有吧运维工作考虑进去,或者即使考虑进去了,也耗尽了所有的时间,没有留下空间给运维。chris也承认这一点,并说我们有一大堆程序等着部署,我们的工作都被部署工作延误了。 bill谈了下目前运维的工作,除了35个业务项目,还有75个运维项目,有几千个变更需要实施,同时又有很多的计划外工作,大多是由于脆弱的应用程序故障造成的,包括凤凰。基于目前的工作量,大大超出了人力负荷。

IT运维部和开发部在两周内不再接受新项目,并且除了与凤凰相关的工作之外,停止IT运维 部的其他所有工作。

你其实是在构建一份资源清单。也就是材料清单以及所需工作中 心和工艺的清单。一旦有了这个,再加上工作订单和你的资源,你最终就能够理解你的生产能力和需求是 什么。这将让你最终明白,是否可以接受一个新工作并对其作出实际安排

改进的内容几乎是无关紧要的,关键是你要不断改进

研究表明,每天训练五分钟比每周开展一次为期三小时的训练更有效。如果你想 要营造一种真正的改进文化,就必须把那些习惯建立起来。”

通过监控项目,减少问题流向brent的可能性。 弄清楚整个工作流程,哪些工作的是安全的,哪些需要经过约束点。以此作为安排工作的依据。

“在我们离开之前,把你的注意力从工作中心转到工作中心之间的那些空间上。 与控制工作发布同等重要的是管理好工作交接。一个给定资源的等待时间,是那个资源忙碌时间的百分比除以空闲时间的百分比。因此,如果一个资源使用了50%,等待时间就是50/50,或者说1个单位。如果这个 资源使用了90%,那么等待时间就是90/10,或者说9倍时长。那么如果这个资源使用了99%呢?” 尽管还不太理解其中的关联,我还是在心里计算着:99/1。我说:“九十九。” “正确。”他说,“当一个资源使用了99%,那么等待时间就是该资源使用50%时的99倍。”

‘第二工作法’的一个关键部分是让等待时间可视化

Read More