IT运营的过程

分别为计算机普及阶段、网络建设阶段、IDC(数据中心)建设阶段、云服务发展阶段

互联网技术是指在计算机技术的基础上开发建立的一种信息技术。互联网技术通过计算机网络的广域网使不同的设备相互连接，加快信息的传输速度和拓宽信息的获取渠道，促进各种不同的软件应用的开发，改变了人们的生活和学习方式。互联网技术的普遍应用，是进入信息社会的标志。

《凤凰项目》是一本由基恩·金 (Gene Kim) / 凯文·贝尔 (Kevin B著作，人民邮电出版社出版的平装图书，本书定价：CNY 4900，页数：362，文章吧我精心整理的一些读者的读后感，希望对大家能有帮助。

《凤凰项目》读后感(一)：一直在寻找的WOW

这本书把我一直在寻找的一种工作方法，嵌入到了小说里面写出来。看到是一个字，爽

但我一直忙于工作的时候。总会有一个想法在脑海里回荡，总觉得这，不是个办法，但又不知道怎么办。看了这本书，他仿佛像一个明灯，点亮了我前进的道路。

他从一个宏观的角度来去看待整个开发测试和部署运维整个流程。一直以来我都觉得，进行更高维度的系统化思维才是正确的，但是没有机会和办法在实践中运用起来获得经验 看这本书，就像看一本，射雕英雄传。

但是从我的经验来看，一个思想要推广很难，首先你要让整个团队取得共识，还要排除政治上的敌人。

总之，这本书是一个好书。道理要放在故事中才能够让人更容易接受，并且，能把道理成功的放到故事中也是非常厉害的。看这本书是一种享受。

《凤凰项目》读后感(二)：如果你找不到《丰田管理》这本书……

它在这里：//bookdouban/subject/3871227/

并且它也不叫什么鬼《丰田管理》。它叫Toyota Kata好吗？“Kata”不知道吗？还搞个什么“改进型”，吓死我了好吗？

我们干这行的都管Kata叫“招式”好吗？

这就是个典型例证，折射出整本书翻译中的外行。你找俩会编程的人来翻译行吗？你找个负责点的编辑行嘛？就算你这些都不做，我的天，人家原书引用了几十本书，你能把参考文献列表留住吗？能吗？你把参考文献列表给删了，又把书名一通乱译，我得费多大劲才能找到里面提到的书你知道吗？

你真当我是来看小说的吗？

当然我不会因为这点小毛病就贬低这本书本身。书还是五星。不过我还是这么说：中国绝大多数的翻译作品，译者加上编辑一起，其作用就是让中国读者能花几十元人民币买到本来价值几十美元的书，并且尽他们的最大努力损害书的价值，使中国读者少占一点便宜。

《凤凰项目》读后感(三)：聚焦最大的瓶颈

烂摊子，没人没钱，怎么办？怎么用有限的人力显著地提高系统的质量？一个物理学家提出了一个简单理论：TOC

TOC（Theory of constraints），我更喜欢称之为瓶颈理论：任何系统至少存在一个制约因素/瓶颈，系统最终的产出受限于系统内部最薄弱的环节。要想显著提高系统的产出，就必须找到系统最大的瓶颈解决掉。所以，持续优化过程就是：

(1) 先找最大的瓶颈。

(2) 最高优先级地解决掉这个瓶颈。

(3) 然后再找新的瓶颈，重复上述步骤。

这个过程渗透着3个问题：应该在什么环节改善？改善应该带来什么成果？怎样推行改善？

我在百度工作的时候，大家都把自己的工作内容用便利贴粘到画板上，每项任务都需要提交申请，通过在画板上的需求栏、执行栏、完成栏之间移动便签纸呈现项目各个环节的状态，不仅让团队成员参与其中，还能清晰地展现出哪个环节最容易成为瓶颈。

书本上提到的三步工作法，按我工作经验理解就是：

(1) 确保工作流水线不要中断。比如，需求、开发、测试、小流量实验以及推全这些环节中有一个中断了，那就降低了整体的效率。

(2) 出现问题，就要找到问题的源头，从根源上解决掉。比如，线上出BUG，根源很可能是系统code混乱到需要重构，不只是测试的问题。

(3) 持续地尝试改进系统，不要把全部人力用在功能开发上，留有20%人力改进非功能性需求。

《凤凰项目》读后感(四)：企业IT结构

虽然是讲一本运维的书，但是从整个书中可以看到整个企业的IT架构。

掌握整个企业流程，而非盲人摸象

作为一名技术人员，无论开发和运维，多多少少都会有一些极客思维，沉浸在技术的世界里。随处可见的产品和开发之间的矛盾就可见一斑。一个专业的技术人员应该自变为上帝视角，看到整个企业的流程，从订单到销售，再到生产，采购，财务等等，只有真正理解一个公司是如何运营的，才能真正理解技术是如何为企业服务的，才能真正做出契合用户的软件。如果仅凭个人的臆想，去设计功能，如此做出的软件基本上都是不堪入目。

迅速的从0到1，而非制造很多的05

书中反复讲到半成品，对比软件也是如此。相信很多人都在企业中看到，很多软件做到一半不做了，或者是快要推向市场时，总是不稳定，之后就无人问津！这就是一直在忙碌的制造05，从没有一个真正的1。半成品是无法推向市场的，无法实现营收，这就产生了极大的资源浪费。 对比与一个人的工作也是如此，如果你手中有10件工作，你针对10件工作都完成了50%，这在上级看来，你是没有任何进展。而如果你聪明的完成了5件工作，这才是真正的完成了50%！！所以在任何时候，请专心制造1，而非很多个05

开发到运维的一体化

运维和开发是息息相关的。中国的很多企业，运维基本都是由开发人员 去做的。证明运维在很多的企业是依附于开发的，这就导致很多开发人员一个错误的观念，运维相对于开发是不重要的。当然不要认为运维的技术含量小，因为你接触的运维不是真正的运维。运维是可大可小的，真正好的运维，能帮助开发省掉50%以上的工作。从自动化部署Jekins到Docker，再到zookeeper都有运维的影子。

部门间永远有冲突，分清是恶意还是无意

开发是一个需要团队通力合作才能成功的一件事，所以作为开发，基本上见识不到所谓的办公室政治。而一旦需要和别的部门进行合作，无论是较远的销售部，还是较近的运维部，一定会有冲突，这种冲突不一定会上升到办公室政治的地步，但是用冲突来定义是OK的。一旦遇到冲突，我们要首先定义，冲突是不是恶意。多数冲突而言，大家都是站在自己的立场上想做好这件事情，这种大家只要平心静气去解决就好！但是如果是恶意的推诿责任等等，那就需要你用自己的智慧去打赢这场战争，有人的地方就有江湖，不能指望自己在一片和谐的职场里步步高升！ 自然，很多时候，办公室政治不一定是拔刀相向的冲突，还有可能是冲你微笑的甜言蜜语。

技术储备

这是一个很虚无缥缈的话题，书中也可能根本没有提到。作为技术人员或者运维人员，在如今的时代里，技术储备都是不可或缺的。如果一个运维不能了解技术，就根本不知道如果做出更为人性化的自动化运维，慢慢沦落为一个网管。如果一个技术不了解运维，那么就没办法提前设计架构，做出来的软件就不能自动化处理，这是另一个悲剧。 所以，无论作为哪一方面的从业人员，都要慢慢加强自己的技术储备，一旦放弃学习，一定会慢慢被这个时代所抛弃，特别是IT行业。

关于“布伦特”

布伦特是一个技术大咖，各种人员有问题都会找布伦特，布伦特也总能解决问题，所以越来越多的问题积攒在布伦特身上。 在管理层的角度而言，布伦特确实不应该存在，因为他是部门效益的短板，太多问题只能依靠他。但对于个人而言，这是在某一阶段的好事，只有当你做到能“挟持”整个部门利益的时候，作为员工，算是半个成功了。当你到达如此地步，就要想想如何更近一步，如何脱离重复性的工作，让自己更近一步了。 很多技术性人员到达这一步就止步不前了，很遗憾。更多的技术人员是还没到达这一步，就天天想入非非了，这更悲哀。

《凤凰项目》读后感(五)：运维的蜕变，很有参考意义。

阅读本书的过程，让我感觉和阅读《三体》三部曲一样，前面有些平淡无奇，但是随着故事的发展，越看越兴奋，兴奋之后则是陷入深思。

这是一本少有的写到运维的小说，而且不缺技术，相反，涉及到技术的范围还很广。

本书的前一段内容我感同身受，各种各样的紧急工作、混乱的IT变更，而Bill来自的地方，则有着自己建立的IT变更管理，井然有序。或许所有的IT在前期的阶段基本上都面领着这样的问题。

而后来，面临着公司即将被拆分，IT业务被外包的局面，在Eric的指点下，Bill将运维、开发、业务聚集到一起，通力合作。感觉这种方式有着敏捷、DevOps的因子。

每一次变更成功，每一次故障的避免，都让我欣喜若狂，仿佛就是身边的事情。

尤其是看到Bill和Kris开始合作后，其实心中除了兴奋，还有一丝羡慕。

得知DevOps的概念时，大概是13年初（源自于《DevOps的各个阶段》）吧。当时网络上不少人都在高呼运维要下岗了，认识的一些运维攻城狮都人人自危。但是这么多年了，至少在我司中，干运维的还在干运维，基本没啥变化。搞软件开发的倒是自己做了些运维的工作——没办法，现在内部支持也要费用，能省点儿是点儿。

ill自始自终都是作为一个副总裁，在自上而下的推动整个故事的发展。他为什么没有在原有的部门就将变更管理推广出来呢？自上而下很重要。

虽然没有ITIL工具的管理，仅仅利用看板，就能将如此多的变更管理得井然有序。而现实中，管理员们懒到极点，一个字段都不愿意填写，更别说写纸条了。

这么多年了，开发和运维从来没有通力合作过，往往是交接，而且只有交接，开发只是为用户服务，压根不考虑运维的事情，毕竟，考虑到安全、易运维的问题都会增加成本——又开始吐槽了。

或许本书中，开发、运维同属一个公司，有着共同的目标，而现实中的我们，只有盈利才是共同的目标，其他的——考虑那么多作甚？

《凤凰项目》读后感(六)：不只是DevOps

作为一个程序员，DevOps这个词并不陌生。2011年底我就看了《持续交付》，当时给我的震动很大。在AppAnnie我看到了持续交付是如何变为现实的，我觉得这是个非常棒的过程。

这本书的价值绝对不是在主角们做到了一天部署十次，而是在这之前的n章之中他们的痛苦和煎熬。一个烂摊子，一堆破事儿，没人没钱，怎么办？怎么限制工作量？怎么保护最能干的员工？最重要的是，怎么缩短交付周期，提高交付质量？

ill在书的前半部分进展很慢，后半部分慢慢加快。他们在前半部分做了很多探索性的工作，很多尝试。每当我在看到Bill和他的两个下属开会讨论某个问题的时候，我都会停下来问问自己，这时候应该怎么办？DevOps虽然是终极的解决方案和目标，但是我们需要一步一步踏踏实实的向这个目标前进，步子迈得太大只会扯着蛋。仔细思考一下故事中的每个问题，每次会议，对自己都是一种锻炼。在真正的日常工作中，没人会像Eric一样给你耐心的提示。这本书就是我们每个人的Eric，而凤凰项目之于我们的日常工作的情况差别，就好像制造业生产线和凤凰项目的差别一样巨大。虽然情况千差万别，但是我们要做的就是从凤凰项目这样的案例之中找到像“三步工作法”或是“四种工作内容”这样的东西，来给自己启发。

《凤凰项目》读后感(七)：做好运维有方法

比尔临危受命，被CEO任命为IT运维部副总裁，并要求一定要完成凤凰项目。刚上任因为历史遗留问题工作上总是出现各种各样严重问题，然后他就想办法改变这种现状。做凤凰项目过程中，CEO不让招人、不花钱买设备，业务部门又步步紧逼，强制让项目时间提前上线，结果损失严重。在比尔迷茫时遇到一位世外高人艾瑞克，艾瑞克给他指导方向，教他三部工作法，四类工作类型等等。功夫不负有心人，经过艰难的改进、创新，最终完成了凤凰项目，创造了奇迹，并受到了CEO的赏识。

这本书作者写的很精彩，看到书中的一些场景，让我想起了往昔的苦逼岁月。刚开始做运维工作时，开发、业务那边很强势，自己很憋屈，比如：制定好的规则和流程形同虚设；新项目上线总是等到最后一刻才告知；生产环境有问题总说是运维问题，因为在他们本机测试是正常的；部署文档及其简单，不知所以然因此，书中比尔每当遇到抓狂的问题时，我感同身受。里面的解决方法部分是我已经做过的，很认同，同时也学习了很多。

列几点书中的精彩部分。

1、约束点，即瓶颈。

布伦特是个技术牛人，很多问题只能他来解决。当出现计划外意外问题时，救火工作会占用他大量时间，因此计划内的工作常常耽误。

如何解决约束点问题？

第一步，确认约束点。假如约束点找错了，无论做什么都无济于事。对非约束点的任何改进都只是幻觉。

第二步，利用约束点，就是确保不让约束点浪费任何时间。永远不要让约束点迁就别的资源而干等着，而是应该专注于IT运维部对当前所需完成工作中优先级最高的那一项。计划外工作会让你丧失开展计划内工作的能力，因此必须不惜一切代价去消灭计划外工作，墨菲法则确实存在，因此总会有计划外工作，但你必须高效的处理它们。

第三步，把约束点置于次要地位。队伍里最慢的A君决定了整支队伍的行军速度，为了防止队伍拉大距离，要把A君调到队伍的最前面。A君是约束点，要保证其他人的速度和他的速度一致。根据约束点来控制工作节奏。

第四步，相比于向系统中投入更多的工作，将无用的工作剔出系统更为重要。

第五步，增加节点，经过更多的环节流向约束点。

2、三步工作法

第一工作法，从开发部移向IT运维部时该如何建立快速工作流。做法：用持续交付。

第二工作法，如何缩短及放大反馈环路，从而在源头上解决质量问题，避免返工。

做法：在部署管道中失败就停止；日复一日的持续改进日常工作；在开发和运维之间建立共同的目标和共同解决问题的机制；让每个人都知道，代码和环境是否在按照设定的运行，以及是否达到了客户的目标。

第三工作法：如何建立一种文化，既能鼓励探索、从失败中吸取教训，又能理解反复的实践是精通工作的先决条件。

3、四类工作类型：

1 业务项目,开发部所做的公司项目。

2 IT内部项目，为了业务项目而产生的运维内部项目，如部署自动化、监控。

3 变更，经常由上述两种类型引起，会出现问题，交接工作时问题最多。

4 计划外工作或救火工作，包括 *** 作事故和 *** 作问题，通常由上述三种类型的工作导致，而且往往以牺牲其他计划内工作为代价。

4、看板方法

看板方法它是工作任务的可视化管理，每项任务处于何种状态（“待办”、“在办”、“已办”）一目了然。如果在看板图上，就要迅速完成。

半成品（即在办状态）是个隐形杀手，要减少半成品。（半成品是引起长期 货期限问题、质量问题以及导致督办员每天都得调整优先级的根源之一）

5、资源忙碌百分比

资源忙碌百分比

图标显示，等待时间是工作中心中某个资源忙碌程度的函数。艾瑞克用这张图表来说明为什么布伦特的30分钟简单变更要耗费几个星期才能完成。原因很显然，作为所有工作的瓶颈，布伦特的使用率一直是100%甚至超过100%，因此，每次交给他的工作都只能在队列里苦等，如果不进行加速或升级处理，就永远不会完成。不知道这幅图的来历，有人认为这幅图是李特尔法则的简化版本。

书中强调了持续交付的重要性，比尔团队因为实现了它并创造了好几个项目的奇迹。它不是小说里随便写写凭空想象出来的，而是真实情况的体现，的确很有效果。如今在运维的世界里DevOps很流行，它是持续交付的实现并延伸。我们强调重复的 *** 作用机器来实现，每次相同的 *** 作必然得到同一个结果，不出现任何意外。在处理重复无聊的事情上，机器确实比人靠谱多了。

是一本好书，推荐给所有的IT从业者，相信读完它你会有很多收获。

《凤凰项目》读后感(八)：交付价值的it

凤凰项目确实是和《目标》一样的传奇故事。最近两年一直在思考Devops、持续交付、微服务，其实本质的思想，是回归常识的约束理论，虽然康威定律指出了现象，但是要怎么做，还需要高德拉特博士的思考方式。

正好在作者写这本书那年，没有任何先入之见时候看到目标和约束理论。之后一直用这种简单自然的思想观察世界、指导实践，看到凤凰项目，确定了正是“胖胖的小男孩贺比”作为主线在推动着从自动化构建到持续集成、容器这些技术和思想的演进。到现在devops已经是不需要争议的竞争优势，各种工具已经成熟，因为这个过程而产生的工具和方法已经像空气一样自然，思想却很少被提及。

正好2009年，还看过尼古拉斯卡尔的IT不再重要，云计算的到来，开发运维成本越来越低，企业可以更专注于业务。IT不再重要，因为每一个公司都在成为科技企业，IT已经是企业价值链的重要一环，不在是鼓励的解决局部的问题，局部改善只能让问题更糟，只有针对瓶颈整体优化，为最终用户交付价值。才是devops的意义。至于怎么做，当然不是工具或者方法的简单应用，只有像大野耐一教我们的那样，现场管理，这个是没有银d的

《凤凰项目》读后感(九)：与其说是关于DevOps的书，不如说是关于管理的书

IT很重要

这是此书要传递的一个重要信息。在快速更新和需要提高247服务的今天，运维的确变得比以往更重要。但哪个角色又不是呢？设计部门常抱怨自己的想法得不到实现，QA抱怨常常背黑锅听说过没见过的DevOps提倡的打破Dev和Ops之间的壁垒，在此书中体现的并不多。略翻了下《SRE: Google运维解密》，似乎也是主要讲运维团队。开发团队去哪儿啦？其实小团队中，开发基本把运维的事就包了。把部署作为代码的一部分，尽可能自动化，根据运维状况进行调优，迅速更新和排错，都要求IT人员和开发人员的深度参与。所谓的壁垒，是否就是这些角色不在同一团队引起的？

TOC

这才是本书的重点。以最有价值的目标为导向，找到核心问题和瓶颈问题并解决。其实换一个部门，略微修改下，估计也会把这个故事讲下去。

部门合作

这似乎是这个项目中的最大屏障，包括一些办公室政治。当然在现实中，这也往往是事实。所以很多经理主管不得不花很多精力在这些看起来不直接产生价值的会议，争吵和手段上。

对于生产的方法论很多，继流行日本的理论后，估计来自于中国的实践理论在将来也会推广。关于部门合作方面，华为的执行力就值得学习。

外场会议

书中的CEO在多数时候并没突出表现。然而举行外场会议，承认自己的错误并及时修正，而且知道创建一个相互信任的团队的重要性。就这两点来看，的确是有领导才能。要知道，绝大多数领导是做不到这点的。这个做法，是来自于书中推荐的《团队协作的五大障碍》

布伦特

主角的名字还不如这个印象深。因为被提及的太多。一个IT工程师，扫地僧似的存在，自由电子般的问题终结者，“一个优秀的工程师胜过100个平庸工程师”说的就是这样的人。他们往往也成了瓶颈。

从组织来讲，这就是典型的项目被人绑架。实际中，也有很多类似的优秀工程师，但没达到传奇的地步，因为老是困于一个项目，从而也逐渐平庸起来，离开自己的项目会做的就很少。成了人被项目绑架。

改变这种最后双输的情况，需要魄力和一点冒险精神，因为人们总是倾向保险的做法和安于现状。

另外更重要的是，能识别布伦特和用好这样的人。

《凤凰项目》读后感(十)：这是一本项目管理的书，跟DevOps没什么关系

1 - As titled

2- 翻译很烂，常常需要根据中文来猜英文，往往联系上下文觉得终于明白了是什么意思的时候有一张“翻译，你出来我们俩聊聊，我保证不打死你”的冲动

3- 故事其实就是记录一个传统的运营团队如何转变成为一个agile的团队，并在struggle中如何琢磨出了一套适合自己的agile的工具，对于参加过这么多次agiletraining的我来说，这些理念实在太小儿科，有时候读着读着会自己笑出来，觉得在浪费时间，

4- 小说其实写的很啰嗦，神一样的Eric在现实生活中不会存在，其实换个角度，他更像一个agile的coach，目前的市场上，agile已经是一个很成熟的体系，市面上各种coach，training， 以及书籍，完全不用像书中描述的那样通过一个又一个的mess来琢磨出一套agile的工具集，所以对于大多说的IT从业者来说，直接去读一本agile的书，或许收获会更大。

5- ‘比一名开发人员更危险的就是开发人员和信息安全部门的人联手。这样的组合把给我们添乱的动机、手段和机会都弄齐全了’ 黑的漂亮

6- 四类工作 ： 业务项目，内部项目，变更，以及计划外工作。我虽然没有完全明白他所谓的变更，但是我同意这种分类方法，我觉得变更这个事情或许会更加针对DevOps一些，而对于一个普通的project team来说，更多的是剩下三种类型的工作

IT 的管理者很清楚的知道，在不远的未来信息化将成为业务的运营中心，问题是信息化自身又该如何运营管理。

IT 团队需要了解业务部门的需求，然后设计并开发一个个的信息系统。这些信息系统就像工厂里的生产线一样，将生产出真正对业务有所帮助的数据和信息。

IT 的管理者就像是这个工厂的厂长，需要能够敏锐的 发现 业务需求，经过系统化的 设计 并且有效的 协调 人员去实施。此外，还需要高效率的运维 保障 已上线的信息系统稳定运行。

这些要求可不少，IT管理工作看起来就像是在运营一个工厂，并且在这个信息化正在逐步走向成熟的年代，可以说每一个IT管理者都是一个创业者。

管理IT，就像管理一家企业或医院一样，没有什么本质的区别。需要面对的都是那些像幽灵一样，隐藏在各个环节中的问题。我们不太可能真的去一个一个的解决这些看起来千头万绪的问题，因为这些问题很有可能是环环相扣的。

但很快会发现，肯定有那么几个问题是元凶，是导致这千头万绪的根源，只要解决这几个问题，剩下的症状就会自然的全部消失。而问题的关键是，你怎么找到这些根源。

即使问题再难缠，只要能够摆在面前，相信总有办法解决。但是这些问题总是像丛林中的幽灵一样，若隐若现，躲闪在丛林之间。

这些问题似乎就在那里，又若隐若现，有时还会投鼠忌器，所以请允许我用幽灵来形容这些管理上的问题。但是这个世界上肯定不存在幽灵，其实是我们对整体工作的认知不够系统化，所以才给了幽灵们能够躲藏，能够隐蔽的角落。为了找到这些“幽灵”，IT管理者们需要一个系统化的方式。需要一个系统化的方式去认知IT管理工作，否则幽灵们就会出现。

曾经信息化技术有着一些神秘 的技术色彩，甚至对很多人来说还有一些魔法般的神奇。但是，现在这些都不重要了，因为人们不再关心是你怎么实现的，而是关心你究竟能给我带来了什么。

之所以没有像吉普赛人的巫术一样消失，是因为信息化技术真的能够给人们带来价值，要么是提高了业务的效率，要么是减少了浪费。所以，IT为什么存在？答案只有一个，就是为业务创造价值。

IT 的运营是一个为业务创造价值的过程，这个增值的过程是IT团队一系列的输入、转换和输出的行动集合。每个行动都对业务客户产生增值行为，从而最终为业务客户创造价值。

让我们用这样一个脉络去认知IT的运营过程，方向是：首先得了解为谁创造价值。输出是：价值是承载在输出上。过程是：输出是被怎样一个过程创造出来的。输入是：需要输入什么样的原料才能满足过程。所需要的资源是：像生产过程一样，IT的运营过程同样需要投入资源。要遵守的规则是：在这个过程中，需要遵守的规则有哪些。

                           

方向：IT的运营是一个为业务创造价值的过程，重复一下，是 为业务创造价值 。所以，现在创造价值的方向就非常清晰了，要以业务客户为核心。有两点具体的体现：第一是增值的过程是以业务的需求为源头，进行设计和规划。第二是对IT工作的测量指标有很多，但是最高级别测量是客户的满意度。

价值和输出：所谓“输出”指的是增值过程最终输出的产品或服务，而价值一定是被输出承载的。价值一定是摸得着，看得见的，就像人们认宝马的汽车 *** 控性很好的时候，宝马公司的价值是依托于该公司最终提供给你的宝马汽车之上。信息化的价值是通过为业务部门提供了一个一个的信息系统以及服务而体现的。

过程： 为客户创造最终价值的，不是一个活动，也不是一个流程，而是由各个流程组合在一起的整体价值链。 例如、需求分析、审批、设计、开发、测试、部署。又如、申告记录、分派、处理、满意度调查。

输入：根据输出和价值的要求，IT团队需要外部提供什么样的资源输入。

资源：IT的增值过程需要投入直接的资源，包括：人、资金、软件、硬件、数据。当这些资源不足的时候，则直接体现为增值活动的产能不足。

规则：在很多行业中都有相应的规则要求，例如、银监会对商业银行的IT管理要求、保监会对保险公司的IT管理要求。对于这些政策性的管理规则，等于是给IT管理工作圈定了一个范围，任何设计和规划不能超越这个范围。

需求就像原材料一样，不断的被分析、被加工，直到最后形成服务提供给业务客户为止。IT团队可根据价值链，对各项作业进行计划和管控，同时价值链也是生命周期的档案链，是信息传递及追溯的基本逻辑。此外，IT管理者可根据价值链，分析引起交付质量波动的各项作业，并分析其上下环节的原因。

我为什么要在这里特别放一个章节来描述价值，因为我们后续谈的所有内容都是围绕价值创造来开展的。最怕的是过于专注于方法和过程，而忘记了最根本的核心问题--为业务创造价值。IT团队是以流程的方式利用资源，为客户提供服务，从而创造价值。因此流程只是创造价值的方式，但是在不清晰价值的时候，设计流程等于是一种盲目行为。

从客户的角度看，IT服务的价值有两部分组成：效用（Utility）和保障（Warranty）。任意一个都可以增加客户获得的价值，但两个都是必要条件，两个都不能单独构成充分条件。

价值的源泉：效用

效用（Utility）是一个经济学名词，任何产品和服务的价值首先取决于满足用户的期望程度，而用户的期望往往是模糊的，无法直接度量，所以只能间接的衡量由欲望产生的现象。在经济学中以一个人为了实现或满足他的愿望而愿意付出的价格来衡量效用（Utility），所以效用是价值的源泉。

如果把效用简单的进行叙述就是，某个服务或产品使得业务客户在使用后，能够减少多少以前的负面状况，或增加多少正面的状况。

我们可以用这样的逻辑尝试去叙述：利用了……功 能，解除了……谁的，……什么，使得…谁节省了，或增加了……什么。例如、利用数据化的管理，解除了文档无法统计的限制，使客户得到了有效的统计信息，也节省了得到信息的时间。

这就像我们后面要说到的需求管理中“用户故事”一样，用户故事是力求通过简短的语言是从用户的角度来来解读和描述用户渴望得到一些功能。所遵循的逻辑是：As a, Iwant to, so that也就是作为一个<角色>, 我想要<活动>, 以便于<商业价值>。

价值的基础：保障

信息系统发挥效益是建立在其稳定运行的基础上，需要其五个方面的保障： 可用性的保障 、 容量和性能的保障 、安全性的保障、连续性的保障、服务响应时间的保障。

根据最终交付的价值，IT团队的主要工作有两个方面，一是对信息系统的运维保障，二是通过建设和优化信息系统，为业务创造效用。

如果说这两个工作是有着根本的区别，那就是在对外界变化的影响上。运维保障工作受到外界的变化影响小，而为业务创造效用的工作相对受到外界的变化影响大。

运维保障工作的目标不会总是发生变化，也不需要频繁的去和客户讨论目标的变化。IT团队不会天天跑去问客户，你看今天咱们这个信息系统要保障到什么程度？消防队不需要天天问市民，如果今天你家发生火灾我们几分钟到场合适。对信息系统的保障要求对于各个行业来说虽然不一样，成本也不一样。但是，有一点是一样的，就是一旦确定了保障的目标以后，该目标不会频繁的发生变化。那么，我们可以确定为运维保障的目标是基本稳定的。既然目标已经确定，那么重要的是两点，一是如何达到目标，二是如何更加合理的利用资源，更加高效的达到目标。精益的运维管理，也就是一套以达到目标为基本要求，如何更加合理的利用软硬件资源，利用人力资源，利用时间的管理机制。 为业务创造效用的工作则是需要更加敏捷的方式，这是因为业务本身需要更加敏捷的响应市场，所以IT也需要更加敏捷的支持业务。这要考验IT的运作能力，虽然从字面上看敏捷有快速的意思，但是仅仅是速度并不等于敏捷。速度再快，最后的输出不满足业务需求，也是白搭。所以首先是把事做对，也就是满足业务需求的高质量交付，然后是把事做快，因为需求也有保鲜期，我们交付的服务如果过于缓慢，可能需求已经发生了变化。

精益思想和敏捷思想，在IT团队的工作中需要有效的结合， 一个成功的组合策略基于将需求模式分为基础需求和波动需求两种需求，也就是“基础需求和波动需求的分离”，一般来说，基础需求是相对稳定的，如业务对可用性和容量的需求或者对服务请求的响应时间，换句话说都是IT团队预先承诺在日常服务范围以内的支持性工作；而波动需求则和新建系统和创新应用联系在一起，这种需求一般不能预测，具有很大的灵活性。 以客户需求作为切入点，在切入点之前交付的是无个性特征的保障性目标，采用精益思想，也就是推动式的精益运维。在切入点以后，要依据客户需求的实际情况而定（未见得是被需求，可能是引领需求），采用敏捷思想。

不同公司界定不同。

有些公司的IT运维是网络管理员，修理下打印机，员工电脑坏了给修理下，公司网络维护，各种公司内部和电子相关的都属于他管理，大部分IT运维指的是这个。

还有些公司的it运维是负责服务器，linux，windows等等各种网站，以及各种应用，比如说qq的服务器，sina，baidu的服务器。都是哈。

行业里有个笑话：越高级的运维越像个隐形人！所以楼主是遇到困惑了，提供自己的能力吧！

说到运维，多半是甲方单位招聘的，乙方一般是研发和实施。项目结束后甲方需要运维。从基层职位看，运维和开发（含产品经理）的分工还是挺大的。

本人做软件开发多年，平时主要考虑功能和非功能的实现，运维负责系统上线后系统的稳定、高效运行。所以在所需技术上也大有不同。

开发重点在各种开发语言、开发框架、持续性集成环境、软件工程、算法以及对应的业务等等，对底层的运行环境 *** 心的不太多，尤其上了云环境之后，越来越少 *** 心负载均衡、高可用这些非功能需求。

运维的重点在于系统运行的各种环境，从机房、网络、存储、物理机、虚拟机这些更基础的架构，到数据库、中间件平台、云平台、大数据平台，偏重的也不是编程，而是对这类平台的使用和管理。

所以开发重建设、运维当然就是维护。所以运维比开发更不受重视也是可以理解的，很难出彩，不出事就是成绩，尽管付出的努力并不少，甚至更多。看过产品运营的人说过一句话“不要管开发做出的是什么垃圾产品，留住客户才是运维关心的“

但是在高层考虑中，尽管运维仍然受重视程度比不上开发，但已经不仅仅是考虑要尽快满足业务需求的问题了。基础架构越来越有话语权。一方面，确实这个是很耗钱的事情（有钱就有话语权）。开发个系统不是有代码就能运行的，养个机房（特别是高端机房），动辄投资也得上亿，上千台服务器也不是那么容易管的，每年的折旧、报废也是钱啊，光电费也够养几个高级RD了。另一方面基础架构，特别云化之后，更是要制约开发使用的语言和程序架构。还有越来越受重视的安全管理，更是巨大的投资，甚至上升到维稳层面。

但是总体来说，运维工程师是IT的后台，IT是一般甲方业务的后台。所以，重要是很重要，但是可能永远不如RD受重视。当然，小部分运维也很受重视，比如制造业，但毕竟是少数。

所以，it运维工程师选择就没有回头路，努力提供自己能力是王道！

以上就是关于it运维平台发展的四个阶段全部的内容，包括:it运维平台发展的四个阶段、凤凰项目读后感精选10篇_读后感_名著读后感、IT运营的过程等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！