一、 IT运维的问题

故事的开头，整个IT陷入一片僵局中，运维内部被海量变更需求埋没，更加严重的是他们被各种突发故障所折磨。新上任的比尔如何解决这些问题呢？

二、变更可视化

在突发故障这个问题上，以及我自己的认同，一定是由变更引起，或者说是由未被有效管理的变更引起。于是，比尔马上对 ITIL change 流程做了梳理。

这不是流程问题，而是流程、工具与人的实现问题。再好的流程经理如果给不出一套人人爱用的工具，那么一切都是白搭。“本来只需花 5min 的操作，却要花1小时录入各种字段，那套工具根本不可用”。大道至简，最简单的解决方式是忽略那些细节。

管理者要看到的是变更、变更间关系、以及变更影响，看得见的变更能让故障的恢复加速 200%。而对于一线运维人员，没人愿意被与事情本身无关的工具所束缚。

最后的解决方式是看板，将运维变更做成了看板，并且依据变更的特性区分不同的颜色，用小便贴纸贴在了墙上。

一般公司在 ITIL 上建立了完善的流程，这一点比主人公所在公司的“荒野”情形要好多了，但这里有一个问题，我们并没有让所有的人都看到你有多少变更。

比尔用看板的方式，以最简的方式解决了变更可视化的问题。About us，我想这种方式是否适合我们，这是增加了工作量，还是加快了我们的处理速度，是否添加一个看板就行了，还是我们要继续咱们的流程工具呢？

原来的流程工具最大的长处是保证变更质量，每一个变更步骤都要求按照规范与标准执行，变更被拆分成了细粒度，如果将其替换为看板，其结果又会如何呢？

依据公司的规模选择合适的变更管理工具，总的目的是让风险可控，无论是看板还是 ITIL ，或者是面对面的站会。

三、 资源约束点

资源约束点，在所有变更的路径上都会遇到约束点，他可能是人，也可能是一个必须串行处理的节点。

在小说中，一名称为布伦特的高级工程师成为了约束点，任何关键任务中他都必不可少，这其中的原因被推测为人性的安全感，他掌握了其他人不知道的配置信息，或者他本身很强大，强大到他的工作其他人无法处理。

在运维团队，后者存在的可能性并不高，特别是以技术为导向的团队。除了人以外，不可见的配置管理，不完善的运维对象都将成为约束点，我的团队中就遇到过因为防火墙的拓扑不清晰导致效率缓慢的。

如何打破约束点？激励团队开放与分享，打破人性弱点才是关键。 “每解决一个问题，我们知识库的内容就多出一篇文章，而解决此问题的人愈加之多”，“让服务尽可能的自助，而不是重复性的无效沟通”。

在一个开放、共享的组织中人员时间都花在刀刃上，团队的强大才能解放个人，个人才能拥有更多成长空间

四、安全审计

书中的大型企业，安全审计部门关注着漏洞、补丁、缺陷，他们会要求运维部门无时无刻的升级、修复，之后造成一波又一波的异常故障。

除此之外，安全审计还会购买一些稀奇古怪的东西，这就是他们的 KPI，或者说他们必须这么做。

还好，书中的安全人员和我遇到或经历的一样，他们也和公司发展大方向，和运维团队站在了一起，他们不再是公司发展的阻碍，但其他公司可不会这样吧？

五、DevOps 运维自动化

在变更可视化、消除资源约束以及打破安全的折磨之后，比尔最后一步是运维自动化，标准化业务逻辑交付过程，通过自动化的方式开放给开发人员，在这里有一本《持续交付》的专著供我们参考。

DevOps 是一种文化认同，如同 Automation Infrastructure 一样，去年我们花费了大量精力在运维自动化上，但对整体效率的提升并不明显。

到现在终于明白自动化仅仅是局限在专业组内，同时没有打通管理工具，也没有任何管理逻辑，简而言之，消耗时间的地方不在运维任务执行上，而是人与人之间的沟通（标准规范、信息录入、逻辑判断等）。

六、关于三步工作法

书中的三步工作法，如此之简单。

1.    标准化

2.    持续优化

3.    将其转变成一种文化

over，但又如何执行呢？书中并没有给出答案。

七、 运维的四种工作

1.    业务项目

2.    运维项目

3.    突发事件

4.    项目转变的变更（众神的大师兄原创）

一、 IT运维的问题

故事的开头，整个IT陷入一片僵局中，运维内部被海量变更需求埋没，更加严重的是他们被各种突发故障所折磨。新上任的比尔如何解决这些问题呢？

二、变更可视化

在突发故障这个问题上，以及我自己的认同，一定是由变更引起，或者说是由未被有效管理的变更引起。于是，比尔马上对 ITIL change 流程做了梳理。

这不是流程问题，而是流程、工具与人的实现问题。再好的流程经理如果给不出一套人人爱用的工具，那么一切都是白搭。“本来只需花 5min 的操作，却要花1小时录入各种字段，那套工具根本不可用”。大道至简，最简单的解决方式是忽略那些细节。

管理者要看到的是变更、变更间关系、以及变更影响，看得见的变更能让故障的恢复加速 200%。而对于一线运维人员，没人愿意被与事情本身无关的工具所束缚。

最后的解决方式是看板，将运维变更做成了看板，并且依据变更的特性区分不同的颜色，用小便贴纸贴在了墙上。

一般公司在 ITIL 上建立了完善的流程，这一点比主人公所在公司的“荒野”情形要好多了，但这里有一个问题，我们并没有让所有的人都看到你有多少变更。

比尔用看板的方式，以最简的方式解决了变更可视化的问题。About us，我想这种方式是否适合我们，这是增加了工作量，还是加快了我们的处理速度，是否添加一个看板就行了，还是我们要继续咱们的流程工具呢？

原来的流程工具最大的长处是保证变更质量，每一个变更步骤都要求按照规范与标准执行，变更被拆分成了细粒度，如果将其替换为看板，其结果又会如何呢？

依据公司的规模选择合适的变更管理工具，总的目的是让风险可控，无论是看板还是 ITIL ，或者是面对面的站会。

三、 资源约束点

资源约束点，在所有变更的路径上都会遇到约束点，他可能是人，也可能是一个必须串行处理的节点。

在小说中，一名称为布伦特的高级工程师成为了约束点，任何关键任务中他都必不可少，这其中的原因被推测为人性的安全感，他掌握了其他人不知道的配置信息，或者他本身很强大，强大到他的工作其他人无法处理。

在运维团队，后者存在的可能性并不高，特别是以技术为导向的团队。除了人以外，不可见的配置管理，不完善的运维对象都将成为约束点，我的团队中就遇到过因为防火墙的拓扑不清晰导致效率缓慢的。

如何打破约束点？激励团队开放与分享，打破人性弱点才是关键。 “每解决一个问题，我们知识库的内容就多出一篇文章，而解决此问题的人愈加之多”，“让服务尽可能的自助，而不是重复性的无效沟通”。

在一个开放、共享的组织中人员时间都花在刀刃上，团队的强大才能解放个人，个人才能拥有更多成长空间

四、安全审计

书中的大型企业，安全审计部门关注着漏洞、补丁、缺陷，他们会要求运维部门无时无刻的升级、修复，之后造成一波又一波的异常故障。

除此之外，安全审计还会购买一些稀奇古怪的东西，这就是他们的 KPI，或者说他们必须这么做。

还好，书中的安全人员和我遇到或经历的一样，他们也和公司发展大方向，和运维团队站在了一起，他们不再是公司发展的阻碍，但其他公司可不会这样吧？

五、DevOps 运维自动化

在变更可视化、消除资源约束以及打破安全的折磨之后，比尔最后一步是运维自动化，标准化业务逻辑交付过程，通过自动化的方式开放给开发人员，在这里有一本《持续交付》的专著供我们参考。

DevOps 是一种文化认同，如同 Automation Infrastructure 一样，去年我们花费了大量精力在运维自动化上，但对整体效率的提升并不明显。

到现在终于明白自动化仅仅是局限在专业组内，同时没有打通管理工具，也没有任何管理逻辑，简而言之，消耗时间的地方不在运维任务执行上，而是人与人之间的沟通（标准规范、信息录入、逻辑判断等）。

六、关于三步工作法

书中的三步工作法，如此之简单。

1.    标准化

2.    持续优化

3.    将其转变成一种文化

over，但又如何执行呢？书中并没有给出答案。

七、 运维的四种工作

1.    业务项目

2.    运维项目

3.    突发事件

4.    项目转变的变更（众神的大师兄原创）