凤凰项目(Phoenix Project)精要 - 3 - 随笔
![凤凰项目(Phoenix Project)精要 - 3 - 随笔](https://static001.geekbang.org/infoq/36/36f5130a69d7e12d814992470f1ead1a.jpeg)
C-1
用更少的资源完成更多的业绩,既要保持竞争力,又要削减成本
IT 运维管理:足够的资历
创建最有组织、最值得信赖的团队
思考自己刚才了解到了什么
注意力集中
公司必须获得盈利能力
团队具备兑现承诺的能力
来自高级管理层稳定、持久的支持
足够的预算与人力资源
保持必要的“沉默”,避免做出更多愚蠢的承诺
负责任的公司要“照顾”好自己的员工
缺乏竞争力是阻碍事项达成的大敌
下属
你最希望我做什么?
最不希望我做什么?
可以失败,但至少不是重蹈覆辙的那种
管理者需要这样的一个人
可靠的、不怕告诉坏消息的人
自己可以信任的人去做正确的事
始终保持头脑清醒
大家觉得你可靠、务实,而且愿意表达真实想法
管理者希望
IT 系统运行可靠有效,为业务部门提供保障
减少日常运维中的故障,让开发和业务部门集中精力去实现和产出
C-2
说服他人的能力
关键的联系信息
流程图 ---》 信息流
时间的安排与把控
敏感数据
任何进展的状态更新与周知
IT 运维部门的关键流程和工具,内外部协作和沟通机制
本性难移
深思熟虑、善于分析、条理分明、客观冷静,对流程和步骤一丝不苟 --》 流程和秩序的执行者和维护者
开放式办公区域的对团队协作和个体效能的优劣影响
关注的焦点 ---》本质问题
谨慎承诺,技术不能解决所有问题
“甩锅”的能力 ---》逃脱各种应负的责任
倾听、收集和对比关键相关人的看法
问题处理
以前是否遇到过类似的问题
易出错又危险的环节和操作
问题发生前的调整和改动,是否产生重大影响
备用方案
外部因素:厂商、外包、。。。
最坏的打算
业务部门如何看待这个问题
“掘地三尺”探寻根因,对问题真正了解多少
问题解决的沟通协调机制、流程规范
问题严重等级的划分:服务中断
确定各相关事件的准确时间节点
C-3
断定故障原因的依据?为什么认定它没有引发故障?这个变更经过测试吗?
操作过程是否按照技术日志(步骤)在执行,符合预期结果?
对于跨大版本、长久时间间隔的升级,是否足够测试?
实施的维护窗口是否满足“变更和回退”的要求?
重要线索的获取途径?问题的关键?
严格控制紧急变更:紧急需求往往潜藏“紧急的烂摊子”
任何变更都必须遵循规定的程序和流程,未通知其他人的情况下展开变更,会带来极大的麻烦
找到关键相关人、盘问、弄清楚他们做了什么?梳理清楚故障的来龙去脉?
同样的错误不允许再犯
公司的组织架构
实用有效的变更系统、流程和工具:审批、授权、跟踪
变更管理经理:更好地了解情况,完整地掌握真实情况
并不是每个人只要把自己的工作完成就可以获得团体性的结果!
没闲工夫每出一次状况就详查一番基础性的信息!
准确的时间节点 --》 易于获知事件的前因后果
C-4
日常沟通事项的快速处理:邮件、即时通讯工具等,固定处理时间段,优先级
“所有事情都那么重要”这不可能,也不应该!!!
“交接环节” ---》相关人,一定要形成书面材料,明确所有关键项信息!!!
没有 IT 部门的参与,大部分业务项目将无法完成!
项目管理与 IT 部门的协作:有条不紊、客观冷静、富有责任感
干练的管理者
更短的时间、更少的经费去完成并交付更多的产品 ---》 可能性?
阶段的关键路径和关键人力资源,此阶段的主要任务?
不能再用“常规做生意的思路”来行事,来处理非常规问题,始料未及的突发事件。
尽管做了充分的思想准备,但还是会感到怒火中烧。
盛气凌人、几乎都是在指责他人的工作渎职和能力不足。
“办公室政治”,虽然不喜欢,但也只能接收现实。
“甩包袱”是人性的常规操作。
不要对任何建议抱有不切实际的“期待”。
管控情绪,不要轻易“拍案而起”。
在“落地实现”的过程中,会发现每个层面都会遇到问题。
要想打破“恶性循环”,就必须从源头上解决问题,才能不再疲于奔命。
催促他人被动去使用流程和工具,得到的结果可能只有抱怨和接口。
采用 ITIL(IT 基础架构库,包含很多 IT 实践和流程)而不有效落地,最终只能得到一套无人遵守的纸面好流程和工具
有效落地,意味着必须自上而下地贯彻执行
任何规避变更管理制度的相关人都将受到纪律处分
CAB 会议:变更审计委员会,每周召开一次
流程设计不能坐而论道,而是需要真正去干实事 ---》 实用的流程
为问题解决提出解决方案,而不是成为问题的一部分,我能相信你吗?
如果手下的主要管理人员似乎斗得不可开交,要付出怎样的努力才能和平共处呢?
C-5
推脱问题,将球扔到对方半场,只是极为短暂的临时办法
如何建立一种互相尊重的工作关系?
他人的事项追踪路径?
内部审计与外部审计 ---》 发现和评估形势的严重性
账号权限管理 --》 权责分离的要求
怀疑他的立场与倾向
大部分的报告其实都“大而无用”
关键在于,我们在有限的时间内可以做什么,以及哪些系统是真正涵盖的?
会议的目的:形成共识,达成一致意见和行动,明确下一步的工作
办事节奏
如果离开某个人,团队就干不成事,那就遇到大问题了
真正地理解各种应用和组件如何在业务整体层面协同工作 --》 技术性全局视角
弄清楚究竟需要哪些资源?如何一次性申请充足资源?凭证?
承担的义务与所拥有的资源
花时间培训和帮助新人,新进人员不会产生效益,而是记过 3~6 月才能完全发挥作用
工作清单是怎样的?没有记录在案的工作是什么?为什么?
清单机制:应用系统项目、基础架构项目等等,清单会有多少个?会有多长?该怎么做才能列出?
对工作需求、优先等级、工作进度、可用资源、工作量估算的把控 ---》 与工作职责相对应
弄不清楚现有的任务,就无法有效增加和开展新任务!
一个简短的文字说明,描述工作是什么,以及完成这些工作需要多长时间?
合理争取和安排更多的资源
紧要任务总是在不断累加,导致原有的任务不断往后推,直到所有人都在大喊大叫,我们必须直到没有完成某项工作的真实原因!!!
关键人工作清单:简明扼要地列出所有工作任务、正在做什么,以及要花多长时间来完成这些任务
通过工作清单能够明确查人力资源的消耗和需要的人手
C-6
分析当前的形势,而不是一味地应对突发情况
开展访谈 --》 收集数据 --》 做分析
15 分钟访谈:以结构式交谈获取必要信息
人力资源在项目上的分配,各自的任务和工作余量
知道真相总好过一无所知
项目类型:内部项目、事故及故障修复工作、审计合规修复
关键系统缺少高可用和冗余的情况下运行,是可以避免的隐患。
预防性维护
确保将关键人力资源的精力能够投入到关键项目上,而不是在无关紧要的小事上
如何才能改变“游戏规则”,并获取足够的人力资源,以便恰如其分地完成所有事项呢?
“活跃气氛,激励他人”,固执己见式的争吵只会一事无成
强化变更控制,一套可持续的流程和工具
变更计划的制定者、将要实施变更的系统、一句话概述,弄清楚“变更”的定义
现在建立一个有效系统之前,不断尝试,运用所有资源达成目标
需要一些实用的工作方法来稳妥地计划、沟通和实施,不改进方法就无法取得效果,对经验和技巧都有要求
面对现实,没人会真正遵守一套低效的流程
阻止员工去做理所应当的事,将毁掉热情与支持
C-7
工作视图:每周、每日
避免被卷入“政治旋涡”
目前为止,你的印象如何?如果想让一切重回正轨,你有什么计划?
“实事求是”,摸情况,工作流程与边界
改进流程,从“救火模式”中解脱出来
只有掌握了战术,才能实现战略目标
你面临更严峻的问题,而这个问题与你所说的“效率”和“流程”毫无关系
当前的问题是,你显然并不真正理解“工作”是什么?
你对“工作”的定义是什么?是否达到了可以解决实际问题所需要的理解程度? ---》对于整体组织层面的,而不是个人或管理者层面的
是否真实见过“工作”是如何产生、跟踪、完成、提交和统计的?
如果你没有真实见过与体会,那就没法去管理,更不要说组织、排序以及确保足额配备完成工作所需的资源了
在你对工作的内涵有更好的理解之前,任何关于控制工作的讨论都是“偏离方向”的
“夏虫不可语冰”
“工厂流水线的半成品、库存”现象与影响
半成品(WIP)是导致长期交付问题、质量问题和优先级不断调整的根源之一,是效率的隐性杀手
最关键的机制之一:工作任务和原材料的发布,否则无法控制半成品 ---》 工作导入量
有科学依据的管理运动:约束理论(TOC)、精益生产、全面质量管理
不应该根据第一个“工序或步骤”的效率来安排工作,而是根据瓶颈资源所能完成工作的速度。
在瓶颈之外的任何地方做改进都是假象,都是徒劳的!
IT 是知识工作,很难以完全统一的工作标准、流程说明以及“严明纪律”来条框和涵盖。
如何确保形成一条迅速、可预测、持续不断的计划内工作流,从而交付价值同时尽可能降低计划外工作的影响与破坏?
稳定的、可预期的、安全的 IT 服务,为全局性的目标服务,而不是为某个部门的目标服务
三步工作法
理解工作,建立快速工作流,衔接客户
缩短和放大反馈环路,在源头上解决问题,避免返工
建立文化,鼓励探索,吸取教训,反复实践
C-8
不断提醒自己,成败取决于如何沟通好这一切
对真正的工作需求和效能做分析评估,把工作的传递途径可视化
在相对完整知情的情况下,决定何人应该在何时开展何种工作
该做的终究都得做,谁都一样!生活是艰难的,工作也是如此!没有借口,硬上也要上!
关键人力资源缺少、基础架构脆弱、改进措施见效缓慢,是原因也是问题!
基准问题测试 --》 清楚差距与缺陷
工作不是变魔术,会有惊艳的呈现,而是要预演最坏的情况
需要有人在“头脑发热时浇冷水”,恢复一些理性思考
同理心,换位思考,以同感,求共识,获支持
80/20 法则:重点关注最有风险的变更,必须由 CAB 审核批准(每周一次的 CAB 会议,确切的议事规则与流程)
变更种类和等级,风险性与流程环节相匹配
把全局性、体系化效能问题的所有责任都压在某一方是毫无道理的
数据性支持:变更的时间、成功率、相关联的故障时间 --》业务部门在更全面掌握信息的情况下做出变更的决定
标准变更(低风险):已经多次成功实施的变更,只需要提前批准就行
复杂的中等变更是否恰当地通知了所有可能受到影响的人,并获得实施许可
高风险的变更,密切关注问题趋势
流程创建和落地阶段,更应关心流程的完整性、规范性和相关方的参与面
不准出现未经授权的变更,也不准出现未公开的变更
变更冲突以及可用资源矛盾,“拥挤的空域耿一凡发生撞击事故” --》“交通管制员”必须更清楚了解情况、维持秩序
C-9
变更影响:明确哪些可能导致服务中断,会造成严重级别的事故
不能凭感觉做事,不能主观猜测和臆断
控制情绪:掩盖怒容,防止出现鲁莽的言辞和行为,陷入疯狂的状态
作为事故的处理负责人,必须首先弄清楚相关事件,尤其是相关变更的时间线
为基础性原则坚持态度,不软化
定时组织的排查故障的实战演练
合理解决问题的习惯
应急处置会议之前,从时间线上搞清楚问题的发展过程
对整体产生重要影响的工作,都是凸显协作效能的
类型工作: 业务项目、内部 IT 项目、变更
变更和项目的关系是什么?同等重要吗?这些变更都是从哪里冒出来的?
实施变更的必要性,是否支持具体项目?
从端到端的整体业务实现流程的全局视角来审视和思考
C-10
最重要的任务纲要
如何规避变更风险,不再为部署变更日而提心吊胆?
从哪种角度去理解和解释为什么有些事情未能完成?
进度报告、更新后的完成时间节点、资源需求
观察并寻求理解
如果一个员工“专业又聪明”“在具体事项上又显得无可或缺”,那么他大概率已经成为了一个整体效能的“瓶颈点”
看起来他确实是在全心投入地解决 IT 问题,但实质上已成为某些人的“私交性办公同事”,高管的“私人助理”
“唯一一个知道问题在哪里的人”,也可能是无效忙碌的人,没有发挥关键性作用
“他把知识和信息当成了一种权力,不愿意分享,也确实让他成为了几乎难以取代的人”
“他解决了其他人无法处理的问题,引以自豪,但却使整个系统变得更加愚笨”
如何才能改正大家直接来“指派和干预”某个人工作内容和顺序的坏习惯???
必须改变工作流,流程是用来保护人和工作状态、提升整体效能的!!!
记录和分享,不能反复解决同一个问题,也便于日后分析
任何情况下,都不准做哪些无法在事后记录的事项
解决一个问题,知识库里就应该多一篇关于如何解决某个疑难杂症的文章,而且能够实施修复的人会越来越多。
为了摆脱困境,必要时采取一些极端措施
定义“关键人”的新流程、新职责,周知并“警告”相关人遵守
为什么他们认为自己的项目、自己的任务如此重要?
如何鼓励相关人遵守新的流程? 加强学习、分享成就、维护名誉?
必须把知识全都交到真正从事这项工作的人手上,如果他们无法心领神会,那么就是责任心和技术能力出问题了。
必须让从事工作的人明白他们究竟在干些什么,而不是让更多人去囤积知识。
设法降低对“固定人”的依赖
C-11
变更日程表
为什么变更没有完成?
是谁批准了所有这些工作进入了系统?
如何对汹涌而来的工作说“不”?是否应该接受这些工作?又凭什么做出了决定?
我们需要更好地理解,什么工作将会成为“关键人”的头号任务?
确定事项的优先级、分类?确定相关的变更是什么、有多少?
C-12
代码在测试环境下通过各项关键检测
软件缺陷报告
配置和设置的一致性:测试环境与生产环境
如何配置齐备的端到端测试环境?
必要时,对团队和流程进行全面的管理检查
了解关键人对目前形势的看法?从你的角度看,事情进展得怎么样?
找些彻底了解那些事情的人,问问他们的想法?
弄清楚我们自己应该置身何处?现在的方位又是怎样的?
完善的软件版本:版本编号?软件包管理?
测试流程的可控性:终止 或 回退 ?对于临时加入内容的应对?
流程的“单向性”:无论是提交新代码、例行发布、文档记录,都只能是“单一入口”的!!!
试运行的进展情况 --》明确风险与隐患、获得建议、进行讨论
是否充分理解变更的可能带来的副作用和风险?
“谁”是这场自杀式混乱的始作俑者???
事已至此,事态愈发不可收拾,糟糕程度不断突破原本的底线。此刻,别无选择,只能最后一搏,阻止这疯狂的行为!
需要对形势有一个全面的了解:其他相关事项的进展如何?
相关人都发一份摘要,尽可能地概述发生的事情,并就如何快速获取指示,形成共识和一致行动。
面对现实,这是一场持久战。
数据修改:审计轨迹、恰当地管制,保证数据的完整性和安全性
C-13
履行职责,意味着有问题时,挺身而出,首当其冲;面对结果时,难辞其咎,对成败负责!
你对整件事该负怎样的责任? 没有人能够代替你思考和下决定!
要怎样才能摆脱困境、恢复正常的业务运营?
找到那个行事可靠、认真负责的人!
提交的代码必须对应某个特性或缺陷编号,没有标注的都要退回
限制所有影响性能的代码变更
很想看看他们是怎么干的,暂且观其后效,再下定论。
演练业务流程,了解运作情况,理解问题的严重性
尽我所能,当别人能够通情达理确实相信我们已经没有余力的时候,心理上其实得到了一些认可。
技术资源库 --》 专家组???
C-14
解决方案 --》带着实际解决方案(即使是临时性的)来汇报和沟通
有些时候,有些场合,说出真实想法可能会招来斥责
项目的梦魇:最后一刻变化的需求
从 IT 角度去说服业务部门去做正确的事情越来越难,谁都不愿意为不确定结果的代价买单。
对重大事项的可行性调查
敏锐的直觉 --》判断是否可以相信人???
什么样的改变?IT 行业技术日新月异,变化之快几乎很难让人跟上了,每隔几年要学的东西都几近疯狂。
一个人可以有几次做到把自己原有的知识全部抛下,去迎合最新的趋势?
最有可能搞死你的不是前期投入和搭建,而是后续永无休止的后台运行和维护。
工程师一直疲于应付各种故障和日常事项,根本无暇顾及根本性的改善与提升。
为满足多种业务和功能需求的实现和进度,正迫使我们去走“短平快”的捷径,但这些捷径正逐步导致日益恶化的整体效能。
迟来的真相总比永远被蒙蔽好,说真话总是“很艰难”。
做好应对被动地“背黑锅”的准备,总会有些人会想法设法把所有责任都推给我们
“稀奇古怪的政治手腕”
“宁愿虽败犹荣也不会坐以待毙”
与关键相关人至少保持每周一次的沟通:聚餐、聊天、碰一下想法,想一想得做些什么?
鼓励每个人都去露下脸,体会参与感!
建立人情往来,哪怕只有半小时。
C-15
什么是“最重要的人”? --> 工作上?生活上?
无论工作怎样,都应必须保持生活上的正常状态!
倾听来自家人的声音,不要对工作太过全神贯注,更不要陷入“心力交瘁”的状态
成为极少数能够兼顾家庭和事业平衡的人:养家的人(养家糊口)、家长、伴侣、突发事件的应对者
不得不日复一日地应付各种不可能完成的疯狂要求,这值得吗?
更糟糕的是,要面对很多让你厌恶甚至憎恨的“疯子”和“精致利己主义者”
别太有“圣人心”,我们做好本职工作便是责任心,至于拯救团队和整个公司。。。别想太多
预防措施:很少能明确知道究竟避开了哪些灾难?
问题故障:无视它们的存在是没法蒙混过关的
临时性的工作:计划外的工作,最具破坏性的一类工作,“救火的事情”
计划外工作阻碍了其他类型工作的完成:业务项目、内部项目以及变更的有序进行
计划外工作的破坏性以及可避免的本质
计划外工作是恢复性工作,几乎总是让你远离目标,知道你的计划外工作从何而来尤为重要!!!
想方设法采取一切必要步骤,阻止大家去做错误的工作,更确切地说,计划外的工作
计划外工作会让你丧失开展计划内工作的能力,必须不惜代价地根除计划外工作的最大源头!!!
可视化工作管理工具:着手稳定工作环境、营造工作氛围、建立快速工作流
管控“约束点”,提高流量,约束点可能很大程度上未被充分利用
约束点(瓶颈),决定了整个系统的产出
如果没有还清技术债务,那么随着时间推移,你遇到的问题和计划外工作量一定会不断增加。
别对你无法控制的事情怨天尤人。在其位,谋其政。
聚焦步骤
确认约束点:对非约束点的任何改进都只是幻觉
利用约束点:永远不要让约束点迁就别的资源而干等着,专注计划内事项
把约束点置于次要地位:弄明白如何根据约束点来设定工作节奏,怎样有效控制约束点的工作量
非功能性需求:稳定性、安全性、可扩展性、可维护性、可操作性、持续性
那个最了解技术债务欠在哪里和如何构建代码的人,应该发挥真正的关键作用。
区分与业务相关或无关的工作,将无用的工作剔除系统更为重要
你应该知道,与实现企业目标息息相关的是什么 ---》 重要的是结果,而非过程、管理,或者你完成了哪些工作。
C-16
重大故障:叙述整个事件,说明过去 72 小时里的全部变更,理清故障的时间线并推理可能的原因.
未经批准,什么都不准碰
不要各种猜测,而是基于事实的推理,将时间线和数据汇总起来,进入深入的调查
事故调查应该井然有序,有条不紊,拿出防止再发生类似情况的办法
开展全员一系列全员参与的模拟事故呼叫,排演新的处理步骤
事故处理过程中的定时状态报告,了解进展情况
面对不确定因素,理清利害关系,妄下结论会将事情弄得更糟糕 --》现在最重要的是我们得了解全局
能告诉我你在想什么吗?局面在我掌控之中,你现在还需要什么?
公开透明:为团队成员开放接触上级和业务部门的渠道,是存在一定风险的
摆脱对某个人的强依赖
充分训练如何处理服务中断,考虑情况的复杂程度和不确定因素
和二级下属直接交换意见? --》沟通的顺序和渠道?
版权声明: 本文为 InfoQ 作者【Anliven】的原创文章。
原文链接:【http://xie.infoq.cn/article/7cf98798f4f57c5187dce5d9c】。文章转载请联系作者。
评论