《凤凰项目》读后感：IT运维是怎样完美逆袭的？

《《凤凰项目》读后感：IT运维是怎样完美逆袭的？》要点：
本文介绍了《凤凰项目》读后感：IT运维是怎样完美逆袭的？，希望对您有用。如果有疑问，可以联系我们。

前言

读完了《凤凰项目：一个运维的传奇故事》,全书以小说方式叙述了一名新上任的运维 VP 比尔临危受命,解决种种运维问题,顺利完成凤凰项目,实现业务价值,最终公司得到发展,同时也保住了IT不被拆分.

本人经过认真地拜读,对 DevOps 体系有了更深层次的理解,本文将自己的阅读感想和书中涉及的知识内容梳理一遍.

一、 IT运维的问题

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

二、变更可视化

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

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

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

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

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

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

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

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

三、 资源约束点

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

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

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

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

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

四、安全审计

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

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

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

五、DevOps 运维自动化

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

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

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

六、关于三步工作法

书中的三步工作法,如此之简单.

1. 标准化
2. 持续优化
3. 将其转变成一种文化

over,但又如何执行呢?书中并没有给出答案.

七、 运维的四种工作

1. 业务项目
2. 运维项目
3. 突发事件
4. 项目转变的变更

后记

书中运维场景、人物关系冲突都很熟悉,的确是一本好的运维小说,但可惜的是缺少操作性,只能起到“师父领进门修行在个人的用处”.其核心指导思想是“精益”,进一步挖掘,精益来源于汽车制造业——丰田模式.

我所看到的,到目前为止,整个运维领域还没有产生最佳的运维精益实践,而是在各种产品平台以及技术上大比拼.

真正的运维价值是什么?

价值流是什么?

如何保证流动?

如何持续改善?

我想,这又回到了文化的问题,管理的问题.

原文来自微信公众号：高效运维

转载请注明本页网址：
http://www.vephp.com/jiaocheng/4330.html